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
Hi I have a board with Spartan-3e-100VQFP FPGA mounted on it. I am using SPI flash (M25p20 ) from ST, to store the configuration bit map. After power-on, the FPGA's starts configuring (INIT-B goes high), then it comes to low. and DONE pin does not go high. All power suplly is correct. CCLK is coming but about 1.3 MHz and other signals like CSO_B,DIN some data is coming. But i am not able to trace why the configuration fails. May I get any help from you guys.. Thanks in advance... bijoyArticle: 99351
"Raymond" <raybakk@yahoo.no> wrote in message news:1143116151.447290.42460@t31g2000cwb.googlegroups.com... > Hi Marco. > > And thanks for answering :) > > I can't find any path options here? (It maybe that I overlook > something). > What should I look for in the configuration settings? > > Is it possible to download a new version of LwIP (like a custom LwIP) > and use that in stead? > By the way, I use lwip 2.00.a > > Raymond > There aren't newer version of lwip. I use a custom version because ll_temac is not supported by xilinx official version 1.00.a and 2.00.a. Which ethernet core are you using? Ethernet and ethernet lite cores are fully supported. In any case it seems a configuration trouble. Check if you have configured every parameter into: Software Platform Setting -> OS and Libraries -> lwip tree (expand it) You can compare all parameters into oslib_rm.pdf If you environment varaible Xilinx_EDK is set to C:\EDK try changing it to C:\EDK\ MarcoArticle: 99352
Sylvain Munaut wrote: > Morten Leikvoll wrote: > > Got a DCM (spartan3), > > CLK1X coming CLK90 pin, thru a BUFG (to get 90deg out of phase from the > > incoming clk) > > CLK2X coming from CLK2X180 pin, thru a BUFG (to get rising edge in phase > > with CLK1X) > > > > How safe is it to sample a signal coming from the CLK1X domain, into the > > CLK2X domain (and maybe back)? > > Does this create a race condition or will this always be safe? (I know it > > isnt when using modelsim, but when implementing?) > > I have problems matching simulation result with real life. > > I did this recently and it worked fine for me, both in real life and in > the simulation (note that in simulation, i generated the clock myself, I > didn't simulate the DCM). I'm working on Virtex4 with ISE7.1 & 8.1 > > When looking at the timing analyzing, I clearly see the path between 1x > and 2x being analyzed, taking the skew and clock uncertainty into account. > > Note that I still tried to minimize the logic between the 1x reg and the > 2x reg, basically I just have a mux so this part can run way faster than > the 200 MHz I ask for ;) To be sure, you can add a maxdelay constraint > in your vhdl file I think and constraint it to be < x% of your clock > period for e.g. that should give you some margin. > > > > Sylvain Maybe I've gotten overly conservative, but I always treat clock boundaries as asynchronous, no matter how closely they may appear to line up on a scope. For example, I worked on a board where the FPGA had control of a off-chip digital signal generator, which produced the clock for the 4th clock domain. (that clock also fed downstream A/D converters, and the controls to the converters had to be synchronous to that clock) Even though the system requirements indicated that the logic should only operate when the external PLL clock was locked to the primary clock, and accuracy could be maintained to within +/-500 ps, I still took all the usual precautions for clock boundaries. Even if I were using to derivative clocks from the same oscillator, I would *STILL* treat them as asynchronous - because they are. Don't count on DCM's to make them "close enough". There are plenty of tricks for crossing clock domains, but you need to know the relative phase relationship of the clocks, the frequency delta, and the latency tolerance of your application.Article: 99353
now i have the complete correct code ( i got that from open cores.org) and i could pin point the errors im uploading the whole code fist let me tell the errors when i compiled the code 1.in mux8 file im getting Warning: ELAB1_0026: mux8.vhd : (87, 0): There is no default binding for component "lut4".(No entity named "lut4" was found). Error: COMP96_0078: mux8.vhd : (84, 22): Unknown identifier "mux8_lut4". Error: COMP96_0133: mux8.vhd : (84, 22): Cannot find object declaration. Error: COMP96_0078: mux8.vhd : (83, 22): Unknown identifier "mux8_lut3". Error: COMP96_0133: mux8.vhd : (83, 22): Cannot find object declaration. Error: COMP96_0078: mux8.vhd : (82, 22): Unknown identifier "mux8_lut2". Error: COMP96_0133: mux8.vhd : (82, 22): Cannot find object declaration. 2.in mux4 file im geting Warning: ELAB1_0026: mux4.vhd : (75, 0): There is no default binding for component "lut4".(No entity named "lut4" was found). Error: COMP96_0078: mux4.vhd : (72, 22): Unknown identifier "mux8_lut2". Error: COMP96_0133: mux4.vhd : (72, 22): Cannot find object declaration. Compile Architecture "RTL" of Entity "MUX4" Compile failure 2 Errors 1 Warnings Analysis time : 0.1 [s] 3.in risc5x_xil as warning: ELAB1_0026: risc5x_xil.vhd : (189, 0): There is no default binding for component "ramb4_s2_s2".(No entity named "ramb4_s2_s2" was found). 4.in add_sub Warning: ELAB1_0026: add_sub.vhd : (76, 0): There is no default binding for component "lut4".(No entity named "lut4" was found). Warning: ELAB1_0026: add_sub.vhd : (90, 0): There is no default binding for component "mult_and".(No entity named "mult_and" was found). Warning: ELAB1_0026: add_sub.vhd : (97, 0): There is no default binding for component "muxcy".(No entity named "muxcy" was found). Warning: ELAB1_0026: add_sub.vhd : (105, 0): There is no default binding for component "xorcy".(No entity named "xorcy" was found). better the whole proram is here u ca run urself and u could debug the errors " http://www.opencores.net/cvsweb.shtml/risc5x/" pls pls pls pls replyArticle: 99354
I wish this was my biggest problem with the ISE :) I would in fact trade each problem I am having for an extra yellow marker. /Mikhail "Dave" <dave.garnett@metapurple.co.uk> wrote in message news:1143044520_1225@sp6iad.superfeed.net... > OK, > > I surrender ! Any idea how I can clear those yellow markers that result from > clicking on an error message, apart from saving and reopening ? > > Dave > >Article: 99355
Hi - The original poster was concerned with Spartan 3, so this is slightly OT, but does anyone have experience with the V4 phase-matched clock dividers (PCMDs)? Is is safe to transfer data between domains clocked by two outputs of a PCMD without resorting to resynchronization? Bob Perlman Cambrian Design WorksArticle: 99356
http://www.fpgajournal.com/articles_2006/20060321_bell.htmArticle: 99357
Bob, We designed the PMCD so that the outputs all all matched within tens of picoseconds across P-V-T. From there, you get onto the BUFGs, and you end up with the usual +/-100ps rule for match between BUFgs. Austin Bob Perlman wrote: > Hi - > > The original poster was concerned with Spartan 3, so this is slightly > OT, but does anyone have experience with the V4 phase-matched clock > dividers (PCMDs)? Is is safe to transfer data between domains clocked > by two outputs of a PCMD without resorting to resynchronization? > > Bob Perlman > Cambrian Design Works >Article: 99358
Brannon,
The most common problem with JTAG is people expect it to work, without
simulating the signal integrity of their implementation.
Bad choice.
Our Rosetta boards have ten devices per board, and ten boards (100
devices). They are arranged in a chain.
We simulated the single card, and the chain, and found we needed to
buffer the clock, but everything else was fine. The first card in the
chain has a wide buffer, that splits out the clock, to drive the ones on
that card, and nine more outputs, one for each additional card.
We do have to make sure we do not do something stupid, and mismatch the
signal lines.
Simulate it first, and then your problems will go away.
Austin
Brannon wrote:
> This post is a bit of a flame, but seriously, JTAG has got to go. The
> signals are weak. The various drivers and controllers for it are weak.
> It causes nonstop headaches for hardware developers and FPGA developers
> alike. It's slow, hardly customizable, hard to use, ultra extremely
> fantastically flaky on every piece of FPGA hardware I've ever used
> (which includes at least a dozen vendors), and ancient technology.
>
> Here is what I want:
>
> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
> three or four. The 200KHz signal dies after eight or nine. This will
> require some strong signals with error correction, but, heck, if a
> basic ethernet layer can do it....
>
> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
> both flaky and redundant. We need some nice protocols, maybe even
> packets with headers, etc.
>
> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
> And put some standard, accessible plugs on there while you're at it.
>
> 4. Standard driver interface. Need I say more? How many of you write
> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
> you all enjoy it too. How about something like this:
>
> mycard = code to locate the right driver and device and open it....
> ioctl(mycard, HOW_MANY_DEVICES, &devices)
> id_struct = new ID_STRUCT[devices]
> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
> for each d in devices {
> if( id_struct[d].devId == Virtex4Id ) {
> targetlist = { d }
> ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
> command_struct.mode = programming
> ioctl(mycard, SEND_COMMAND, &command_struct)
> write(mycard, "c:\my programming file.bit")
> ioctl(mycard, READ_STATUS, &status_struct)
> if( status_struct.mode & programmed) break
> else return failed
> }
> }
> Then we go into a loop for reading and writing debug data, etc.
>
> We could have drivers for a dozen different interfaces including
> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
>
> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
> hat on the "platform" driver and make the thing useful for the parallel
> port as well.
>
> Maybe I'm taking this too far. I just want something that works
> reliably and is not a pain in the ars to use programmatically. Is that
> too much to ask?
>
Article: 99359dotnetters@gmail.com wrote: > We're working with a Xilinx Virtex II Pro board. As a part of our > project, we had to write a hardware stack. After having made it work, > we thought of optimizing the design and hence removed a few states and > reduced the no. of states from 8 to 4. The older code was getting > synthesized in around 20 mins, but the new code takes hours together to > get synthesized, and so does the PAR. But it finally gets synthesized? Break your design into smaller components, synthesize them alone. Try to locate the real source for that problem. RalfArticle: 99360
Looks nice, but... If you could only get them (ST2GX or SC). At least we have shipped all our backlog on xc4vFX devices. Austin John_H wrote: > maxascent wrote: > >> Hi >> >> I was hoping to get some opinions on Lattice FPGAs compared to Xilinx and >> Altera. I see they have a SC device out. How does this compare to similar >> devices from the other two? >> >> Cheers >> >> Jon > > > The SC series is brand new so you might not find anyone with a socket on > their board just yet. It *looks* like a nice family. 3+ Gbit > transsceivers. 90 nm. Many 18kb mems. Oh - no "DSP" units in the SC > family if I recall correctly - they put those in the "volume" parts > instead: the ECP2 family. I like what I see. > > If you have high volume needs and want some hard IP on your board, you > can get their MACO blocks wired up as a teeny asic in your FPGA.Article: 99361
Michael wrote: > Weng Tianxiang wrote: > >>Hi Pablo, >>Thank you for your useful information. >> >>Weng > > > The problem is "System Requirements": "SPARC CPU based system" > Is that for the software development environment?. Seems like the verilog rtl code should be pretty generic. From the description it sounds more like a big compute farm engine rather than something you would put in a fpga for an embedded system. John EatonArticle: 99362
Stephen Williams wrote: > Andreas Ehliar wrote: >> To be honest, at this point I prefer to use XC3SProg >> http://www.rogerstech.force9.co.uk/xc3sprog/index.html >> in Linux. Sure, it is rather slow since it uses the parallel cable IV >> in cable III mode, but it feels much more stable in Linux than impact does. >> > > What I would really like something that can write Xilinx .ACE files. > The impact from Foundation 6.2 is terribly slow, and from Webpack8.1 > is pretty flakey. (It wrote ace files everywhere but where I wanted > them.) > I'll agree that the interface is not particularly intuitive, but the main limitation I see is that the ace files must always be placed two directories deep. I've used Impact from ISE7.1 on Linux regularly, and had no problems at all. I haven't used the 8.1 version much, but a quick test seems to indicate that it works the same. Arrgg... I just noticed that the ipf project files have switched from plain text in version 7.1 to binary in version 8.1. Hey Xilinx, please take a poll of your paying customers. We don't want binary project files!Article: 99363
Look at the -m option for par. The 7.x documentation states that it is not available under windows, so it may be of use when running under Sun Solaris and Linux(? not sure about Linux; check with your local Xilinx FAE and/or their hotline support). -bob p.s. as side note: there are two versions of this -- MPPR (multi-pass place and route) and MNPR (multi-nodal place and route). I believe the latter was "inherited" when Xilinx absorbed NeoCad a number of years ago. fpga_toys@yahoo.com wrote: > Ron wrote: > > I was considering purchasing an AMD64 quad-processor system, but have no > > idea whether any of the FPGA development tool software would take > > advantage of multi-processors (Synplicity for Lattice, Actel, Xilinx, > > etc). Any ideas or recommendations? > > the primary cpu bound process for Xilinx, par, can be run in a > multiprocessor and cluster configuration for converging the best > routing solution sooner. Do a serch for MPPR in your par documentation > or the Xilinx answer base. At least on older ISE 6.x releases under > linux this is VERY useful.Article: 99364
Hello everyone! Any one knows if there are any (even minor) changes that have to be done to xapp765 to make it suitable to be used with ISE/EDK 7.1 and 8.1? Thank you!!!!! JorgeArticle: 99365
Ralf, First of all, thanks a lot. yeah, it finall does get synthesized. But the time differnce is too large. And how do I synthesize the components seperately and then finally "merger" them together? We work in XPS. Is it possible to do it in XPS itself directly? Thanks once again. -- DotNettersArticle: 99366
"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:48fmbiFhpnieU1@individual.net... > Symon schrieb: > > > HMMMM??? SOURCE-Termination for a multidrop CLOCK signal? It may work, but > more due to murphys law than by design . . . > Falk, I thought Murphy's Law describes why things _don't_ work, not why they _do_ work?! :-) The reason you often get some improvement is that the connections at the destination end are close together and, particularly for big BGAs like FPGAs, are at the end of stubs. The source is far away at the end of a cable. > > AC-termination at the end of a clock line is most probably the better way > to go. And don't forget, those parallel port often enough spit out really > ugly signals. So a buffer for the clock line with a schmitt trigger input > and a RC-filter in front pays off. > > Regards > Falk > Of course, but that's a fat lot of help when you're stuck with a board which wasn't designed by someone like you who thought about the SI! The bodge I suggested, together with a bit of simulation experimentation, might just get a board going un-modded. Cheers, Syms.Article: 99367
Hello all, I am planning to introduce a decimation filter in my FPGA design in order to reduce the sample frequency by 8. This has resulted in a 61 tap FIR filter. -It seems awfully large. Basically, I am asking , for an FPGA implementation, what is a REASONNABLE number of taps for a FIR filter? (I am planning to again filter the decimation filter's output with a cascaded structure of 4 2nd order IIR filters. In my opinion it is that cascaded structure which is doing the REAL filtering and it happens to be smaller and more potent. It seems a shame to ruin the compactness of the filter modules with a huge decimation filter. P.S I have yet to implement anything; I am just doing the planning of the required modules for the moment so I may be completly off base in my previous statement) -Roger (Filter parameters, in case they are of interest : Normalized Passband=0.015 Normalized StopBAnd=0.062 60dB stopband attenuation 0.1dB passband ripple Sample frequency=1MHz 10 bits or 16 bits databus, don't know yetArticle: 99368
J o h n _ E a t o n (at) hp . com (no spaces) wrote: > Michael wrote: > >> Weng Tianxiang wrote: >> >>> Hi Pablo, >>> Thank you for your useful information. >>> >>> Weng >> >> >> >> The problem is "System Requirements": "SPARC CPU based system" >> > > Is that for the software development environment?. Seems like the > verilog rtl code should be pretty generic. From the description it > sounds more like a big compute farm engine rather than something > you would put in a fpga for an embedded system. > > > > John Eaton Why not? This would be a great teaching tool for fpga design and/or computer system design courses at college level. ~jzArticle: 99369
Symon schrieb: > Falk, > I thought Murphy's Law describes why things _don't_ work, not why they _do_ > work?! :-) The reason you often get some improvement is that the connections Theory: Nothing works but everone knows why. Practice: Everything works but nobody knows why. Theory + Practice : Nothing works and nobody knows why. ;-) > at the destination end are close together and, particularly for big BGAs > like FPGAs, are at the end of stubs. The source is far away at the end of a > cable. Si. > Of course, but that's a fat lot of help when you're stuck with a board which > wasn't designed by someone like you who thought about the SI! The bodge I > suggested, together with a bit of simulation experimentation, might just > get a board going un-modded. Ok, for a work around this might be a way to go (If all you got is a hammer, everything looks like a nail). But the original complaint/cry/whatever was about a implementation of JTAG from scratch. Regards Falk P.S. One of the problems with JTAG is/was, that people underestimate problems due to the low frequencies involved. And as far as I remember, the are/were some nasty problems with FPGAs for brand . . . because the JTAG inputs (especially the clock) was sensitive to non-perfect transitions, which means you have to treat the almost DC like JTAG like a GBit transmission line. Not nice at all. The suggestion of Austin to do a simulation is in general right, but sounds a little bit strange to me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition time that matters, not frequency). So why is the JTAG (clock) not INTENTINALLY made slower (+ schmitt trigger) to avoid this problems? Nobody needs a 100MHz++ capable JTAG port (today).Article: 99370
One more thing,
We also AC terminate at the endpoints of TMS and TCK.
This was also shown to be necessary in the simulations.
But don't just assume this is the "solution", you must simulate your
pcb, and decide what to do.
Austin
Austin Lesea wrote:
> Brannon,
>
> The most common problem with JTAG is people expect it to work, without
> simulating the signal integrity of their implementation.
>
> Bad choice.
>
> Our Rosetta boards have ten devices per board, and ten boards (100
> devices). They are arranged in a chain.
>
> We simulated the single card, and the chain, and found we needed to
> buffer the clock, but everything else was fine. The first card in the
> chain has a wide buffer, that splits out the clock, to drive the ones on
> that card, and nine more outputs, one for each additional card.
>
> We do have to make sure we do not do something stupid, and mismatch the
> signal lines.
>
> Simulate it first, and then your problems will go away.
>
> Austin
>
> Brannon wrote:
>
>> This post is a bit of a flame, but seriously, JTAG has got to go. The
>> signals are weak. The various drivers and controllers for it are weak.
>> It causes nonstop headaches for hardware developers and FPGA developers
>> alike. It's slow, hardly customizable, hard to use, ultra extremely
>> fantastically flaky on every piece of FPGA hardware I've ever used
>> (which includes at least a dozen vendors), and ancient technology.
>>
>> Here is what I want:
>>
>> 1. Support for a lot of chips, say 2048 of them. JTAG supposedly
>> supports 16 chips. Yeah, right. The 5MHz clock signal dies out after
>> three or four. The 200KHz signal dies after eight or nine. This will
>> require some strong signals with error correction, but, heck, if a
>> basic ethernet layer can do it....
>>
>> 2. Endpoint enabling. The JTAG methods for specifying an endpoint are
>> both flaky and redundant. We need some nice protocols, maybe even
>> packets with headers, etc.
>>
>> 3. Speed. It needs to be as fast as my USB2 cable at a bare minimum.
>> And put some standard, accessible plugs on there while you're at it.
>>
>> 4. Standard driver interface. Need I say more? How many of you write
>> directly to the parallel port? All of you? Uh huh, I knew it. I'm sure
>> you all enjoy it too. How about something like this:
>>
>> mycard = code to locate the right driver and device and open it....
>> ioctl(mycard, HOW_MANY_DEVICES, &devices)
>> id_struct = new ID_STRUCT[devices]
>> ioctl(mycard, IDENTIFY_DEVICES, &id_struct)
>> for each d in devices {
>> if( id_struct[d].devId == Virtex4Id ) {
>> targetlist = { d }
>> ioctl(mycard, SET_TARGET_DEVICES, &targetlist)
>> command_struct.mode = programming
>> ioctl(mycard, SEND_COMMAND, &command_struct)
>> write(mycard, "c:\my programming file.bit")
>> ioctl(mycard, READ_STATUS, &status_struct)
>> if( status_struct.mode & programmed) break
>> else return failed
>> }
>> }
>> Then we go into a loop for reading and writing debug data, etc.
>>
>> We could have drivers for a dozen different interfaces including
>> Firewire, parallel port (urrrg), serial port (double urrrg), etc.
>>
>> Yo Xilinx, let's remove the great mystery from Impact. Let's open the
>> hat on the "platform" driver and make the thing useful for the parallel
>> port as well.
>>
>> Maybe I'm taking this too far. I just want something that works
>> reliably and is not a pain in the ars to use programmatically. Is that
>> too much to ask?
>>
Article: 99371"Roger Bourne" <rover8898@hotmail.com> wrote in message news:1143136101.823610.180860@u72g2000cwu.googlegroups.com... > Hello all, > > I am planning to introduce a decimation filter in my FPGA design in > order to reduce the sample frequency by 8. This has resulted in a 61 > tap FIR filter. -It seems awfully large. Basically, I am asking , for > an FPGA implementation, what is a REASONNABLE number of taps for a FIR > filter? > Roger, Look at making your filter as a series of half-band FIR filters. These are efficient in that every other tap is zero. (Nice and easy to multiply by zero!) Use three, decimating by two at each stage. Your implementation should be a lot more compact. The later stages will probably have more taps, but the sample rate will be reduced, possibly allowing you to use distributed arithmetic. Cheers, Syms.Article: 99372
"Symon" <symon_brewer@hotmail.com> wrote in message news:4422e0f2$0$15787$14726298@news.sunsite.dk... > "Roger Bourne" <rover8898@hotmail.com> wrote in message > news:1143136101.823610.180860@u72g2000cwu.googlegroups.com... >> Hello all, >> >> I am planning to introduce a decimation filter in my FPGA design in >> order to reduce the sample frequency by 8. This has resulted in a 61 >> tap FIR filter. -It seems awfully large. Basically, I am asking , for >> an FPGA implementation, what is a REASONNABLE number of taps for a FIR >> filter? >> > Roger, > Look at making your filter as a series of half-band FIR filters. These are > efficient in that every other tap is zero. (Nice and easy to multiply by > zero!) Use three, decimating by two at each stage. Your implementation > should be a lot more compact. The later stages will probably have more > taps, but the sample rate will be reduced, possibly allowing you to use > distributed arithmetic. > Cheers, Syms. > Also, check out CIC (cascaded integrator comb) filters? Although 8 may not be a high enough decimation factor to make this method worthwhile. Cheers, SymsArticle: 99373
wau! does it mean all FX MGT issues are solved !? that would be good news !! AnttiArticle: 99374
> Nobody needs a 100MHz++ capable JTAG port (today). I could use one... When driving the address and data lines of a processor in order to program a flash memory (because the data on how to do this using the processor internal utilities for that are secret or the processor has none), this can make some reasonable difference in programming times (mainly during prototype testing/bringing up, during production you typically can program some tiny initial boot flash code which will do the rest). But well, I do not argue I could not live without it, it would just be nice to have it. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Falk Brunner wrote: > Symon schrieb: > > > Falk, > > I thought Murphy's Law describes why things _don't_ work, not why they _do_ > > work?! :-) The reason you often get some improvement is that the connections > > Theory: Nothing works but everone knows why. > Practice: Everything works but nobody knows why. > Theory + Practice : Nothing works and nobody knows why. > > ;-) > > > at the destination end are close together and, particularly for big BGAs > > like FPGAs, are at the end of stubs. The source is far away at the end of a > > cable. > > Si. > > > Of course, but that's a fat lot of help when you're stuck with a board which > > wasn't designed by someone like you who thought about the SI! The bodge I > > suggested, together with a bit of simulation experimentation, might just > > get a board going un-modded. > > Ok, for a work around this might be a way to go (If all you got is a > hammer, everything looks like a nail). But the original > complaint/cry/whatever was about a implementation of JTAG from scratch. > > Regards > Falk > > P.S. One of the problems with JTAG is/was, that people underestimate > problems due to the low frequencies involved. And as far as I remember, > the are/were some nasty problems with FPGAs for brand . . . because the > JTAG inputs (especially the clock) was sensitive to non-perfect > transitions, which means you have to treat the almost DC like JTAG like > a GBit transmission line. Not nice at all. The suggestion of Austin to > do a simulation is in general right, but sounds a little bit strange to > me. Simulate a 5 MHz clock signal ?(Yeah yeah, I know, its transition > time that matters, not frequency). So why is the JTAG (clock) not > INTENTINALLY made slower (+ schmitt trigger) to avoid this problems? > Nobody needs a 100MHz++ capable JTAG port (today).
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