Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Eric Smith wrote: > What "laws" are those? AFAIK, today's modems are still subject to the > Shannon-Hartley Theorem and the Nyquist Sampling Theorem, which > substantially predate the 1960s. Perhaps these putative "laws" from > the 1960s were promulgated by people with little understanding of > information theory? For those who are historically challenged, and did not live thru the 1960's and 1970's with modems: www.comsoc.org/ci1/private/1999/apr/pdf/Gappmair.pdf Note the conclusions on Page 104: "In the early 80's, however, it was believed that 9600 bit/s would be the ultimate practical limit." In the early 1970's it was considered that 1200 baud would be the limit for single pair dialup, and a bit higher for split conditioned 4 wire data circuits.Article: 101251
Kolja Sulimma wrote: > Jim Granville schrieb: > > >>Most common for human-view applications is PWM or PDM to drive the LED, >>but that can give EMC issues, if you have large LED currents. > > > You can route the current in alternating loops. That should remove > almost all EMC issues. Yes, it can mitigate some of the problems, but it also requires forethought and skill, and probably an EMC test :) 'LED Driver' covers a very wide range of possible loads, so it is not easy to advise the best solution. Between the Digital Switch, and linear drive choices, there is also soft digital drive ( Typically MOSFETS with high value Rg drive ), gives less power loss than pure Linear, but better EMC than pure digital. If the LEDs are a matrix ( moving signs etc ) you can also ease EMC by adding a deadband, and design the drive so only one axis needs to be slow. Mostly, I use PDM (Pulse Density Modulation) a la Rate Multipliers of old. That uses the least CPLD resource. -jgArticle: 101252
Here are the details. The DSP kit should also become 2C70, but the webpage is not updated yet... http://altera.com/products/devkits/altera/kit-video-cyclone2.html Cheers, Karl.Article: 101253
fpga_toys@yahoo.com wrote: > Eric Smith wrote: > >>What "laws" are those? AFAIK, today's modems are still subject to the >>Shannon-Hartley Theorem and the Nyquist Sampling Theorem, which >>substantially predate the 1960s. Perhaps these putative "laws" from >>the 1960s were promulgated by people with little understanding of >>information theory? > > > For those who are historically challenged, and did not live thru the > 1960's and 1970's with modems: > > www.comsoc.org/ci1/private/1999/apr/pdf/Gappmair.pdf > > Note the conclusions on Page 104: > > "In the early 80's, however, it was believed that 9600 bit/s would be > the ultimate practical limit." > > In the early 1970's it was considered that 1200 baud would be the limit > for single pair dialup, and a bit higher for split conditioned 4 wire > data circuits. FWIR, what enabled them to sidestep the apparent limits, was the Group Delay equalisation, and the ability to trade-off Signal/Noise for more apparent bandwidth. [= DSP and better Codecs ] That takes things in rather a different direction than Nyquist/Shannon... This has fed-on into ADSL (which also keeps advancing), and I think 10GBd Ethernet uses the same ideas. -jgArticle: 101254
billu wrote: > Hi There, > > I just generated a Aurora sample design that communicates between 2 > MGT's using Coregenerator. How do I configure two specific MGT's to be > used in the design (say MGT4 & MGT9). I tried to use PACE to assign > I/O's of the Aurora design to the pins on the board. But, the MGT pins > are disabled. (color coded:Brown and the legend:Gigabit serial) How do > I assign the assign the TX signals (TX_N & TX_P) and RX (RX_N & RX_P) > to the MGTs? > > Thx in advance, > Billu Haven't used it for about a year but as I recall, the coregen gui controls some of it and you modify the ucf which coregen generates to do the rest. ColinArticle: 101255
Last time I used it, you had to choose the MGT you want among all the proposed ones ( depending on you FPGA ) by the core generator. The generation of the IP by core generator fills a ucf file for you. Just include the generated ucf content to your design ucf file. "billu" <bkamakot@gmail.com> a écrit dans le message de news: 1146205277.535391.223790@g10g2000cwb.googlegroups.com... > Hi There, > > I just generated a Aurora sample design that communicates between 2 > MGT's using Coregenerator. How do I configure two specific MGT's to be > used in the design (say MGT4 & MGT9). I tried to use PACE to assign > I/O's of the Aurora design to the pins on the board. But, the MGT pins > are disabled. (color coded:Brown and the legend:Gigabit serial) How do > I assign the assign the TX signals (TX_N & TX_P) and RX (RX_N & RX_P) > to the MGTs? > > Thx in advance, > Billu >Article: 101256
Hi Charles,
Thanks for the answers.
<charles.eddleston@gmail.com> wrote in message
news:1146164002.235951.28840@j73g2000cwa.googlegroups.com...
> So the FAE suggested trying to break the problem down to eliminate the
> boot code. To that end, I have taken a short program that prints
> "entering code()" and "exiting code()" and then stops. I boot from
> this code and using the debugger reset. So at this point, none of the
> registers or memory have been setup. I use the debugger to load SDRAM
> 0x2000-0x200C (the first four instructions) and program the PC to
> 0x2000. If I load the design that uses the PLB RAM instead of the OCM
> RAM and load the registers from the last example (none are set up) and
> locations 0x2000-0x200C in SDRAM, I am able to step through all of
> these instructions.
But, if you load the design that uses the OCM RAM and follow the same
procedure, it doesn't work? In that case I agree, it looks like your
bootloader is OK.
Thinking of reasons why the PowerPC might just hang up on you: it's
unlikely, but it could be a Machine check - did you monitor the status of
C405XXXMACHINECHECK?
My next question: what version of EDK are you using, and if it's less than
8.1i, did you see this answer record?
http://www.xilinx.com/xlnx/xil_ans_display.jsp?getPagePath=22179
Admittedly (a) this is the worst-written load of gibberish I've seen in ages
and (b) it doesn't immediately look like it's relevant to you, it does in a
roundabout way give a possible explanation for what you're seeing.
The default settings of the C_APU_CONTROL parameter allow certain extra
instructions, including floating-point instructions, to be decoded and
executed via the APU controller. To cut a long story short, certain invalid
instruction forms may get interpreted as being destined for an external
co-processor, which isn't there and so doesn't respond and thus hangs up the
system. In particular, executing instruction 0xffffffff may have this
effect, which is quite possible if one ends up reading from memory that
isn't really there. And this might happen as the result of an unexpected
interrupt, for example (if you don't have a vector table defined).
It's a long shot, but do check the C_APU_CONTROL parameter on your PowerPC
core. It might not solve your problem, but it might just stop the system
from hanging up and thus let you see what's actually happening to the
registers & program counter.
I'll keep thinking...
-Ben-
Article: 101257
Hello,
I think you can use a 32-bit NCO.You can use the equation fout = (fin *
frequency tuning word)/2^32, since you are using a 32-bit Register.
Consider your example: Input Clock is 100MHz
Output Clock is 200Hz, then the
frequency tuning word comes to around 0x218D. You need to count your
counter till this and the MSB of the counter register is nothing but
the Output Clock i.e 200Hz. This I have tried and works good.
All the Best ,
Regards,
Srikanth
Article: 101258Jon Elson wrote: > > > Roger Bourne wrote: > >> Hello all, >> >> I always wondered the following: >> >> How are constants implemented in an FPGA ? How many can be stored >> without causing bottlenecks (routing issues)? >> A quick scan of a Spartan3 indicated there is no ROM. >> >> > Actually, the LUTs of all FPGAs **ARE** ROMs! They are very SMALL > ROMs, but they are a ROM until you reconfigure the FPGA differently. Jon, this is not quite true (or at least doesn't apply to all Xilinx architectures) in virtex2/pro all LUTs can be loaded (serially in SRL mode) in later architectures some of them (SLICEM) can be used as RAM, more, some of our customers are using this feature, to reload coefficients for filters, or pixels for led displays, or to make "runtime reprogramable gates". More advanced users know that a lut used as logic, still can load bits in SRL mode, to reload the lut, and are taking advantage of this. Aurash > > Jon >Article: 101259
JEDEC defines various classes and termination schemes for HSTL: I unterminated or symmetrically single parallel II source series or symmetrically double parallel III asymmetrically single parallel IV asymmetrically double parallel What I'm missing is an answer to my question: Where to use which termination scheme? In my special case: Connecting one QDR SRAM to a FPGA by HSTL interface, providing different types of signals: differential (clocks), single-ended unidirectional (address, control) and single-ended bidirectional (data). Who can assist? Roland.Article: 101260
On 27 Apr 2006 11:53:22 -0700, "charles.eddleston@gmail.com" <charles.eddleston@gmail.com> wrote: >Yeah, it's been quite puzzling - I had the local Xilinx FAE out here >the other day and we weren't able to get anywhere on it (besides >agreeing that the PLB and OCM busses look like they should). So here >are the answers to your questions, followed by the more recent >developments: >4) Yeah, the link register increments by 4, the PC/CTR registers are >correct and then register 5 is copied into register 6. I don't know >anything about how interrupts work on the PPC, so I'll have to read up >on that. Since Ben mentioned interrupts a couple of times, and you say this, let me point out one "gotcha" ... well it caught me out anyway... The register pointing to the interrupt vector table holds ONLY the 16 MSBs of the vector table address. Thus putting the table at 0xffff4000 (as we did) doesn't work. You'd think the EDK tools might have warned about this, but nooo... they built the code just fine. Then the CPU took its first interrupt, and looked for a vector offset from ffff0000, and couldn't find one. So it took an "illegal instruction" interrupt, and went to ffff0700 to find the handler... Moving the vector table to a 16 byte boundary (ffff0000 in our case) solved the problem. IMO this limitation COULD have been more clearly documented, as well as trapped by the tools... - BrianArticle: 101261
Hello,
Could someone please send me a tri-state bus macro for spartan2 ?
Thanks in advance,
Fabio
Article: 101262On 27 Apr 2006 16:06:53 -0700, gburx@yahoo.com.au wrote: >Hi, > >I've got a little knowledge about fpga's. I've used for fun spartan2 at >school. >I'm interested in embedded systems in view of operating systems. >Which development platform (starter kit) do you suggest for such a >person like me ? > >The nice thing would be to have PCI. Either edge or slot. > >XUP Virtex-2 Development Platform (http://www.digilentinc.com/) - it >cought my attention. >Are there better platforms ? One worth looking at - if you want Spartan-3 and PCI - is the "Raggedstone" from Enterpoint. http://www.enterpoint.co.uk/moelbryn/raggedstone1.html - BrianArticle: 101263
Hi Brian,
"Brian Drummond" <brian_drummond@btconnect.com> wrote in message
news:reu352d73g90urns1j9k3j88ie8ahk0qcm@4ax.com...
> >4) Yeah, the link register increments by 4, the PC/CTR registers are
> >correct and then register 5 is copied into register 6. I don't know
> >anything about how interrupts work on the PPC, so I'll have to read up
> >on that.
> Since Ben mentioned interrupts a couple of times, and you say this, let
> me point out one "gotcha" ... well it caught me out anyway...
>
> The register pointing to the interrupt vector table holds ONLY the 16
> MSBs of the vector table address.
>
> Thus putting the table at 0xffff4000 (as we did) doesn't work. You'd
> think the EDK tools might have warned about this, but nooo... they built
> the code just fine.
> ...
> IMO this limitation COULD have been more clearly documented, as well as
> trapped by the tools...
Good point. As far as documentation goes it took me a while to find where
this is explained (PowerPC Processor Reference Guide, Chapter 7 "Exceptions
and Interrupts", section "Interrupt-Handling Registers", EVPR, page ~204,
and also mentioned in the OS and Libraries Documentation, Standalone PowerPC
BSP section). :-) Do you have a suggestion as to where else you think this
should be mentioned, to make it more obvious?
The EDK tools do the Right Thing when generating the default linker script -
and Base System Builder will notify you if you don't have room for the
vector table in your project due to this limitation (e.g. you have < 64KB of
BRAM). I guess the linker could be modified to check what it's being asked
to do with the "vectors" section and barf (or at least issue a warning) if
the alignment is wrong, but this would be a bit of an ugly "special case"...
Cheers,
-Ben-
Article: 101264Michael Hennebry wrote: > rickman wrote: > > > I am asking that you not wait until a frustrated user reports your > > mistakes. I am asking that you have someone look at what it takes to > > find all the info that an engineer needs to configure these parts and > > make the info consistent and more usable. > > Documentation by the designer is notoriously awful, Wouldn't that depend on the designer??? > but to start with, the designer is who is available. > It takes a truly wonderful designer to put himself in the > position of someone encountering his design for the first time. No, it just takes someone who is familiar with the process of documentation. One of the big problems with documentation is that they let amateurs do it. By amateurs, I mean they teach designers how to design, but not how to document. I have worked places where the documentation was done by a separate group of documentation experts. They did not have the detailed technical knowledge of the designer, but they knew the process and had the designer as a resource to draw on. Other companies are engineering focused and so document from the perspective of an engineer who often, by the time the documentation is being done, is getting tired of the program and doesn't like documentation anyway. The result is a poor document with little peer review (or review by peers who also don't get it). > Just ask the people trying to use my documentation. > Input from frustrated users is necessary. Only necessary if produce poor documentation in the first place. > I don't have the information to know whether the documentation > for this part is as good as it could be given the user input. It is pretty obvious that they dropped the ball in a couple of respects. Even once the document was published, there were calls into support about some of the configuration issues which resulted in an answer record a year ago. Clearly someone at Xilinx knew that there was a shortcoming in the documentation to have produced this. But that shortcoming was never corrected in the data sheet. Lack of internal communication perhaps? One group pointing out a problem and another group in denial? I can't say. I just know I had a very hard time finding all the data on configuring the parts and I am still not sure I have it right.Article: 101265
Uwe Bonnes <bon@hertz.ikp.physik.tu-darmstadt.de> writes: |> > Xilinx, *please* give us 64-bit cable drivers in the next service |> > pack, or at least the next release (8.2i?)! |> |> An easy way to achieve that would be to drop WinDriver and use the standard |> drivers like /dev/parport or USB access by a dedicated driver or by direct |> endpoint access via /proc/bus/usb I second that! There is really no reason any longer to expose users to all the inconvenience of compiling and installing a loadable kernel module (which BTW will invalidate SUSE support), merely to talk to a simple USB programming cable. It is perfectly feasible for a normal user application to talk to usbfs on /proc/bus/usb directly (or via a library such as libusb). (A certain competitor has figured out already a while ago how really easy using an FPGA USB programming cable can be made under Linux: http://www.altera.com/support/software/drivers/dri-usb_b-lnx.html All that is really necessary is that root installs a tiny hotplug-invoked shell script that makes the /proc/bus/usb/ device file writeable for any user once the USB programming cable has been plugged in, and even that script could be included into the next hotplug release.) Apart from the big hassle with the USB platform cable kernel driver, ise8.1i does seem to work reasonably well under SUSE Linux 9.3. Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great BritainArticle: 101266
On 2006-04-27, charles.eddleston@gmail.com <charles.eddleston@gmail.com> wrote: > Yeah, it's been quite puzzling - I had the local Xilinx FAE out here > the other day and we weren't able to get anywhere on it (besides > agreeing that the PLB and OCM busses look like they should). So here > are the answers to your questions, followed by the more recent > developments: I'm out of good ideas but I'm not quite out of ideas :) Perhaps you could use the icread instruction to figure out exactly what the ppc has in its instruction cache at this point. (I seem to remember that you mentioned that caches were enabled in your design.) /AndreasArticle: 101267
Antti wrote: > sorry the title was wrong - its USB Blaster, not Byteblaster of course > > Antti > Or use the Amontec JTAGkey as new USB - JTAG adapter, and write open source software. JTAGkey is already supporting all ARM7 and ARM9 via the OpenOCD jtag server. JTAGkey has the advantage to accept a wide range of JTAG IO voltages from true 5V to 1.4V. We are now working on the support of Altera, Xilinx, Lattice FPGA / CPLD via a powerfull JTAGkey SVF player (should be dispo in the next month). Have a look at JTAGkey : -> http://www.amontec.com/jtagkey.shtml Regards, LaurentArticle: 101268
Roland wrote: > JEDEC defines various classes and termination schemes for HSTL: > I unterminated or symmetrically single parallel > II source series or symmetrically double parallel > III asymmetrically single parallel > IV asymmetrically double parallel > > What I'm missing is an answer to my question: Where to use which > termination scheme? In my special case: Connecting one QDR SRAM to a > FPGA by HSTL interface, providing different types of signals: > differential (clocks), single-ended unidirectional (address, control) > and single-ended bidirectional (data). > > Who can assist? > > Roland. I designed with QDR a while ago. I'm sure that the datasheet is quite specific about the requirements of every pin. In particular the whole point of QDR as opposed to DDR SRAM is that there are no b-directional signals. Also there are no differential clocks. There are, however, clocks that need to be sent in anti-phase with each other but this is for timing/functional reasons not for signal quality reasons. ColinArticle: 101269
unfortunatly FPGA companies do not support 3rd party programming cables :( so as example if you want to evaluate nios or use signalTap then you need altera supported cable AnttiArticle: 101270
Antti wrote: > unfortunatly FPGA companies do not support 3rd party programming cables > :( > > so as example if you want to evaluate nios or use signalTap then you > need altera supported cable > > Antti > Yes you're right. But this could change in a near future ! LaurentArticle: 101271
"Jim Granville" <no.spam@designtools.co.nz> wrote in message news:4451c8ed$1@clear.net.nz... > fpga_toys@yahoo.com wrote: > > > FWIR, what enabled them to sidestep the apparent limits, was the > Group Delay equalisation, and the ability to trade-off Signal/Noise for > more apparent bandwidth. [= DSP and better Codecs ] > > That takes things in rather a different direction than Nyquist/Shannon... > > This has fed-on into ADSL (which also keeps advancing), and I think > 10GBd Ethernet uses the same ideas. > Hi Jim, I learnt from some friends over lunch a while back, better coding helps! Today's DSP power combined with better receivers using Turbo Codes or Low-Density Parity-Check codes approach the Shannon capacity limit very closely. Wikipedia has some stuff about these codes. Cheers, Syms.Article: 101272
I've just jogged my memory some more. For QDR1 memories and 100 and something MHz it made no difference to functional test or looking with a quality scope whether the series resistors in the FPGA was used or not. Colin colin wrote: > Roland wrote: > > JEDEC defines various classes and termination schemes for HSTL: > > I unterminated or symmetrically single parallel > > II source series or symmetrically double parallel > > III asymmetrically single parallel > > IV asymmetrically double parallel > > > > What I'm missing is an answer to my question: Where to use which > > termination scheme? In my special case: Connecting one QDR SRAM to a > > FPGA by HSTL interface, providing different types of signals: > > differential (clocks), single-ended unidirectional (address, control) > > and single-ended bidirectional (data). > > > > Who can assist? > > > > Roland. > > I designed with QDR a while ago. > I'm sure that the datasheet is quite specific about the requirements of > every pin. In particular the whole point of QDR as opposed to DDR SRAM > is that there are no b-directional signals. > Also there are no differential clocks. There are, however, clocks that > need to be sent in anti-phase with each other but this is for > timing/functional reasons not for signal quality reasons. > > ColinArticle: 101273
So I want to program a serial data flash (SDF) using the SPI protocol but my board/software seems to be unhappy with that idea. I am using a USB Platform Cable and I have been using Xilinx's xspi.exe program. I KNOW the documentation says that one needs to use either a PC3 or PC4 cable to do this but you'd figure Xilinx would write something to support their new-fangled USB cable. Does anyone have a method they'd like to share for using the Platform Cable USB to program SPI? Thanks!Article: 101274
not supported, out of luck! Antti
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z