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
Ditto for EDK. My experience is that you can only use JTAG for 1 thing at a time (when using Xilinx applications). Trevor "yttrium" <yttrium@telenet.be> wrote in message news:8mm3h.6751$Pr5.6212@blueberry.telenet-ops.be... > John Adair wrote: >> One thing to check is that Impact is not open when using Chipscope. I >> have seen cases of Impact affecting chipscope operation. >> >> John Adair >> Enterpoint Ltd. >>Article: 112226
Todd, I have tried a lot of solutions... 1) Using the opencores core embedded inside Altera (Cyclone I) with NIOS and a purchsed stack. The preformance was dreadful. Now, this was about 5 years ago now, so things must be better. The fastest we could ever get the pig to sustain was something around 20 mbits/second. 2) External PCI-based chip with a PCI bridge implemented in the FPGA using embedded Linux. This was a real fast and "sexy" solution. We were seeing sustained rates around 78 mbits/sec. 3) Virtex 4 with the embedded hard core macro using embedded Linux. Sweet, but we had to write a driver. Performance was awsome but it took a while to get working due to the software writing exercise. 4) We used an external Ethernet to USB adaptor (bought at Fry's) with a Linux driver. Then we stuck a USB core in the Xilinx and ran embedded Linux. This was done to prove that we didn't need PCI (solution 2). The nice part about this solution was the guaranteed bandwidth allocation. 5) We used the Rabbit silicon as well. It was real nice - the crap just worked with no fuss. As for the interconnect with the DSP ... I would ask if the algorithms can be implemented in the FPGA's directly. I am not a DSP expert, but both Xilinx and Altera are winning a lot of traditional DSP designs these days. The DSP guys that I know all love the FPGA's. As for chosing a vendor - they both have workable solutions. If you have a good FAE supporting you for Altera - stick with them. I have done several SOC-type designs from each family and every single one of them had "wierd" problems related to the tools - without good support I'd have been dead meat. Just glance at all the compiler/fitter/mapper problems posted here. As much as they try for it not to happen ... we end up holding the bag. Trevor "Todd" <tschoepflin@gmail.com> wrote in message news:1162255661.055244.134860@e64g2000cwd.googlegroups.com... > Hi all > > I'm a design engineer trying to evaluate the large number of > possibilities for adding Ethernet to our embedded system. > > So far I've been very impressed by the Altera Cyclone II with NIOS II > and free lightweight TCP/IP stack. Adding Ethernet appears to amount > to the Cyclone II and a MAC+PHY chip like LAN91C111 (or equivalent). > > Anyone have experience with using the Cyclone II merely for Ethernet? > Should I try to put the MAC inside the FPGA and just use an external > PHY? > > Any recommendations for a communication protocol between the FPGA and > my DSP? SPI seems the most obvious choice for reasonably high > bandwidth (>6 Mbps). Right now my DSP runs from a 1.5 Mbps UART so > mimicking this data flow would save me a bunch of assembly code > changes. However, I'd like to send more data back to the host so could > use upwards of 6 Mbps. > > Also, I'm interested in general recommendations for System on a > Programmable Chip (SOPC), which Altera is obviously highly interested > in advancing. It seems very attractive since I could eventually get > rid of the DSP by simply creating a second NIOS II processor within the > FPGA and porting my assembly code to C. The upgrade path is > straightforward and indefinite since Altera will keep coming up with > even better FPGAs. Any caveats or warnings? Lastly, are there major > reasons I should be considering Xilinx instead? > > Thanks in advance for the help! > -Todd >Article: 112227
I have actually built one out of a chain of inverters before and I would say a few things... 1) It was cool, but the frequency was all over the place. 2) As the manufacturing process changed so did my circuit's operation. It made it real hard to support over the 5 years the product was shipping. I think we saved $0.80 per board, but spent $200K over 5 years recertifying the products due to die changes. Trevor "Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1162270545.016307.190650@m73g2000cwd.googlegroups.com... > Sorry, I was lazy and anwered what the clock would be, if there were > one. In fact, there is no internal clock, unless you build one out of a > chain of inverter/noninverters. > Get a crystal oscillator, they are cheap and good! > Peter Alfke >Article: 112228
Here's a couple of other possibilities ... JTAG termination (pull-up's), JTAG connections (TDO connected to another TDO for instance), and my favorite ... does the chip have power? One other thing I once saw - there was a version of Actel APA parts that you could buy that required them to be programmed with a stand-alone programmer before they would program in-system. As I recall they were pre-set at the factory to disable JTAG access. I think Actel changed the default about 18 months ago, so unless the parts are old that wouldn't be it. As Alan mentioned, though - usually it means a trace has been broken from the chip to the header connector. Trevor "Alan Myler" <amyler@eircom.net> wrote in message news:4541C774.1040907@eircom.net... > kypilop wrote: > >> I have flashpro-lite programmer of actel. But, in use, very >> uncomportable because i don't know how to solve the error..... Any one >> have the error books? >> This is the errors i faced... >> >> programmer 'FPL31LPT1' : Scan Chain... >> Error: programmer 'FPL31LPT1' : Signal Integrity Failure >> Integrity Check Pattern Not Found. >> Integrity Check Pattern : >> 550FAAF000FF0000FFFF >> IrScan Error. >> TDO stuck at 0 >> Chain Analysis Failed. >> Error: programmer 'FPL31LPT1' : Data Bit length : 8272 >> Error: programmer 'FPL31LPT1' : Compare Data : >> 0000............................00000 >> Error: programmer 'FPL31LPT1' : Scan Chain FAILED. >> Error: Failed to run programming. >> >> Well.... Do you know what is the problem and solution? Plz, let me know >> your experiences... >> > > > I've had similar symptoms with Flashpro (not -Lite) when the APA was > dead or when there was a physical disconnect on the board between the > Flashpro header and the JTAG pins on the APA (error in pcb schematic). > > Can you try another board? > > >Article: 112229
I have yet to have success in 20 years of programmable design using a programmable part to do much with clocks and not make my life heck! The only solution I found that always works as I expect is to externally generate a clock, feed that into the FPGA, use a DCM (or PLL) to lock onto the clock if they run fast enough and run everything in the FPGA off that clock! As for 500MHz - wow. I am just starting a 250 MHz design and I was worried. Trevor > > Regardless of the issue of utilising 100% of the IO pins, the onboard > clock multiplexers do a lot of the heavy lifting for you. I would suggest > multiplexing ordinary IO rather than the clocks. > > On using 100% of IO - in a practical design where space (and cost) are at > a premium, I will use a device that has *what I need* and no more. Now I > know that means it's tough to reconfigure and add signals, to say nothing > of looking at the internal state by toggling lines appropriately (although > that can be done if you're sneaky enough about it), but in a shipping > design I need to look at cost - and IO pins (because they enlarge the > package) are a very high cost on an FPGA. > > I have a design in development right now where I am at the limit of IO > pins on an FPGA and I am not going to add a separate device (except > perhaps a single SPI IO device - cheap enough, but there are other > issues), nor move to a larger FPGA (because I have to move to a larger > core to get more IO in this particular family). > > Using 2 smaller devices may or may not be appropriate - if you need _lots_ > of IO and a small amount of logic it might work, but there's still power > to be run, interfaces to be set up etc., and then when adding the cost of > configuration devices (and you have to put those down if the resources in > the FPGA are required for a processor at boot time) it's easily possible > to exceed the cost of a large FPGA with two small ones, to say nothing of > footprints (config devices are in god-awfully large packages). > > So it's not an easy question to answer, but there _are_ times it's > perfectly reasonable to have used 100% of FPGA IO pins. > > Cheers > > PeteSArticle: 112230
Matthew, I have a guy that I use on these types of jobs, but he is in California. We have done many multi-processor designs to fit in small space that he has layed out. He has also done work all the way up to 5 GHz (although he's not really an RF guy). The only complaint I have is that he always under-estimates the layout time (he will tell you 4 weeks for the board you described. I'll tell you he'll take double that). In the end, the board will be beautiful looking, he will have hand-routed all of the nets you marked as critical, and he will probably catch a few errors you made. Along the way he will probably frustrate you - I long ago just started to double all of his estimates (so that I don't lose sleep). In 10 years he has never failed to deliver a quality product. As for travelling ... if you insist, he'll probably go on a "kick-off" or "review" basis, but he won't do on-site work. Just tell him I told you to call ... his company is CADWORKS (949-461-9211). I couldn't recommed anyone more. Trevor "Matthew Hicks" <mdhicks2@uiuc.edu> wrote in message news:eh5qr4$5v1$1@news.ks.uiuc.edu... > My research group is building a mezzanine card that contains a lot of > critical nets. We have four 500MHz DSPs and a V2P FPGA all connected > together in a network. Each DSP also has access to SDRAM. Can anyone > suggest a PCB design house that would route the board for us, someone used > to dealing with signal integrity of many high-speed digital signals in > smaller form factors? If at all possible, we would prefer someone in > Illinois or a consultant that could come to Illinois. > > > ---Matthew Hicks >Article: 112231
I am working on a design that takes a source-synchronous LVDS bus (8 data bits + clock, SDR) at a high speed (250MHz) as the input off a cable. I will be using the XC4VLX15 part. I read in the databook about the IDELAY/IDELAYCTRL operation that can be used to account for package and routing skews. What I don't quite understand is the calibration process. I understand the timing (64 taps @ 78.125Mhz with non-accumulating error) and how an n-tap delay line works. I just don't understand how to calibrate a signal dynamically without an input signal being present. Since my data and clock source is external (and I have no idea when data will start) I don't understand how the calibration can take place. When the cable is idle, the clock line will toggle, but the data lines will all be static. (I do see that an idle pattern of FF-00-FF-00... could be handy). When the cable is not connected though everything will be 0 - even the clock. The other option seems to be the fixed delay approach - then I just need to use the static timing analyzer to account for the flight time and routing delays so that they all "line-up" right on the balls. The datasheet claims a maximum flight-time skew of 80ps for any pin in the device (+/- 1 on the tap count). Then, I just need to look up the PAD --> IDELAY.D, divide by 78ps and add 1 for each of the 8 data bits. Am I missing something? I can't tell you how many times in my life I wished I could slide the clock or data to account for internal chip routing delays. Especially on pad to pad delay paths that went through a flip-flop. This seems too good to be true - so I must be missing something. Trevor CoolidgeArticle: 112232
While I see that you found a solution by recompiling faster, I have a few "time-honored" solutions to this problem as well (Usually reserved for expensive, low volume systems that need to ship today (to get a paycheck next month)). 1) Check your input voltage for the power supply pins. Sometimes people will use a LPF on the power supplies, but the series resistance (probably not a precision resistor) tollerance may result in the power being within spec, but lower than normal. I like using an adjustable LDO to drive each FPGA power group (especially Vint). The other nice thing about that approach is that you can "tweak" up the power supply to the upper limit by piggybacking a parallel resistor on the ADJ pin. So, for instance instead of riding at 2.5V nominal you can make it 2.6V. The higher supply rail will help compensate for the temperature slow-down. 2) Use the static timing analyzer to look at the slowest paths. Then see if errors in these paths are a likely cause of the symptoms you are seeing. Usually they are and the recompile solution may work. Unfortunately in a lot of production systems recompiling results in a whole lot of requalification effort. In that event, trimming noted above is usually easier. 3) Get some air movement going. It doesn't take much air movement at all to make the junction temperature significantly lower. Touching it with your hand may not be a great test. If the device has a very higher thermal resistance, you won't feel anything, but it'll be cooking inside. (I saw a VAX catch fire this way many years ago ... and it was still booting). Trevor "Thomas Reinemann" <tom.reinemann@gmx.net> wrote in message news:1163529222.557776.216940@k70g2000cwa.googlegroups.com... Hi, we are running in trouble with our curent design for a Xilinx Spartan 3 xc3s1500. It does signal processing and it seems that sample got lost with increasing temperature. Immediately after power on all works well, some minutes later, if final temperatures is reach, some samples are missed. I hadn't a thermometer ready, but I can always touch the FPGA for a long time, it may be 50°C. It runs with a clock of 76.8 MHz, PAR states a maximum frequency of 78.777MHz, and logic utilization is about 60%. One board works as expected and two other show the explained effect, the boards have the same layout but are made by different manufacturers. At least the not working are lead free. Just now, we had a discusion to the influence of temperature to propagation delay. I don't believe that it influences clock lines and other logic resources in a (big) different way. Is It true or not? I read the thread "Propagation delay sensitivity to temperature, voltage, and manufacturing", but the answers are very related to DCMs. TomArticle: 112233
nospam schrieb: > Al <alessandro.basili@cern.ch> wrote: > > >>Hi to everyone, >>I'm developing some electronics to make a time measurement with a >>resolution of 25 ps. I'm using a dedicated ASIC to do so > > > Let me guess an Acam part? Could also be from MSC in Darmstadt, but as he has a CERN email address I am sure he is using the HPTDC developed at CERN. The HPTDC homepage has vanished, but we use it in one of our TDC boards: http://cronologic.de/products/time_measurement/hptdc/ >>Can anyone say something about this? Does it sound reasonable? Slow input slopes create crosstalk in the HPTDC. Therefore it makes sense to have extremely fast LVDS input buffers in front of the chip anyway. If you use buffers with enable (or an AND-gate) you can control that from the FPGA to mask the signals. No need to route the signals through the FPGA. You can contact us directly if you have more detailed questions regarding the HPTDC and FPGAs. Kolja SulimmaArticle: 112234
PeteS schrieb: > I have seen a single via add 50ps of deterministic jitter on fast > signals (edge rate about 10^4V/us) on FR4-13. I have no idea what PCB > material you are using or intend to use, but keep this in mind. This applies for serial datastreams were reflections from previous edges add jitter to the following edges. In time measurement applications the edges are extremly rare. Before the next edge any reflections will long have settles. Therefore you do not care about any pulse form modification as long as it is deterministic. Kolja SulimmaArticle: 112235
Trevor Coolidge wrote: > I have yet to have success in 20 years of programmable design using a > programmable part to do much with clocks and not make my life heck! The > only solution I found that always works as I expect is to externally > generate a clock, feed that into the FPGA, use a DCM (or PLL) to lock onto > the clock if they run fast enough and run everything in the FPGA off that > clock! > > As for 500MHz - wow. I am just starting a 250 MHz design and I was worried. > > Trevor > > > > >> Regardless of the issue of utilising 100% of the IO pins, the onboard >> clock multiplexers do a lot of the heavy lifting for you. I would suggest >> multiplexing ordinary IO rather than the clocks. >> >> On using 100% of IO - in a practical design where space (and cost) are at >> a premium, I will use a device that has *what I need* and no more. Now I >> know that means it's tough to reconfigure and add signals, to say nothing >> of looking at the internal state by toggling lines appropriately (although >> that can be done if you're sneaky enough about it), but in a shipping >> design I need to look at cost - and IO pins (because they enlarge the >> package) are a very high cost on an FPGA. >> >> I have a design in development right now where I am at the limit of IO >> pins on an FPGA and I am not going to add a separate device (except >> perhaps a single SPI IO device - cheap enough, but there are other >> issues), nor move to a larger FPGA (because I have to move to a larger >> core to get more IO in this particular family). >> >> Using 2 smaller devices may or may not be appropriate - if you need _lots_ >> of IO and a small amount of logic it might work, but there's still power >> to be run, interfaces to be set up etc., and then when adding the cost of >> configuration devices (and you have to put those down if the resources in >> the FPGA are required for a processor at boot time) it's easily possible >> to exceed the cost of a large FPGA with two small ones, to say nothing of >> footprints (config devices are in god-awfully large packages). >> >> So it's not an easy question to answer, but there _are_ times it's >> perfectly reasonable to have used 100% of FPGA IO pins. >> >> Cheers >> >> PeteS > > My toughest challenges in programmable logic (and I've been doing it a long time too) have been going across clock domains where the dataflow is bidirectional, and things are quite fast. FPGAs will add some jitter and it's difficult to know the exact amount (there's a very recent thread about this) and it depends on the loading of the clocks amongst other things. I try to separate functional blocks and clock the minimum number of FFs with any one clock, but I still get the occasional problem. Cheers PeteSArticle: 112236
I am new in this field and I have been working with ISE Xilinx tool. When I want to create a testbench waveform I have to insert several values, two of them are: Input setup time & Output valid delay. I do not understand them: 1. What do they mean?. Are they related to external devices?. 2. How can I know which values they have?. Thank you!. JajoArticle: 112237
Jim Granville schrieb: > Antti wrote: > > Thomas Entner schrieb: > > > > > >>Hi Antti, > >> > >>are you using "Smart Compilation" ? > >> > >>Plain Quartus: If you have a design compiled with "Smart Compilation" > >>enabled, and then change just a memory-content-file and restart compilation, > >>a magic "MIF/HEX Updater" (or similar) appears after the Fitter-process > >>(which is skipped by smart compilation) and does what you want. I suppose > >>this is also doable on the command-line. But don't ask me about the > >>NIOS-tool-flow, you know, I am using ERIC5 ;-) > >> > >>Thomas > >> > > > > Thomas, > > I dont want smart recompile! I want NO COMPILE. > > > > Compile once. > > > > Merge new ELF file into the SOF file n - times. > > I think Antti is after a solution that does not need Full Quratus, > but is just a 'insert code' step. > As he says, simple enough, and surprising it is not there > aready. > > There must be many teams, where the software is separate from the > FPGA development, and it is both quicker and safer to avoid > any rebuild of the FPGA. > > Maintenance/version control, is another area where this > ability gets important. > > Could you not find the portion of Quartus that Jesse mentioned ? > Amongst the choices, he said: > " you can even update your .sof file very quickly with onchip ram > contents without risk of triggering an entire > re-compile. I cannot recall the exact syntax of the command but I > believe the compilation step is the Quartus Assembler (quartus_asm)" > > - and hopefully, that command line is both a small EXE, and not > needing a license install :) > > -jg Jim, you are right I am looking for a solution that can update the generated .SOF file with the content of software object without *any* FPGA toolflow except "SOF patching". Of course it has to work without the need of license for a given part - the SOF is generated with licensed tools, afterwards only GNU GCC compiler and sofpatcher are used. I just generated 29 .BIT files for all known Virtex-4 device-package combinations - now the MicroFpga user can just run GCC and he has working FPGA bit file even for Virtex LX200 or FX140, without the need to have FPGA toolchain license to those devices or MicroBlaze EDK license ! just for info generating 29 (actually 29+3) BIT files for ALL V-4 device-packages did complete in just about 5 hours. Not so bad at all, I was calculating with more compile times. AnttiArticle: 112238
Trevor Coolidge schrieb: > I am working on a design that takes a source-synchronous LVDS bus (8 data > bits + clock, SDR) at a high speed (250MHz) as the input off a cable. I > will be using the XC4VLX15 part. I read in the databook about the > IDELAY/IDELAYCTRL operation that can be used to account for package and > routing skews. What I don't quite understand is the calibration process. I > understand the timing (64 taps @ 78.125Mhz with non-accumulating error) and > how an n-tap delay line works. I just don't understand how to calibrate a > signal dynamically without an input signal being present. Since my data and > clock source is external (and I have no idea when data will start) I don't > understand how the calibration can take place. When the cable is idle, the > clock line will toggle, but the data lines will all be static. (I do see > that an idle pattern of FF-00-FF-00... could be handy). When the cable is > not connected though everything will be 0 - even the clock. > The other option seems to be the fixed delay approach - then I just need > to use the static timing analyzer to account for the flight time and routing > delays so that they all "line-up" right on the balls. The datasheet claims > a maximum flight-time skew of 80ps for any pin in the device (+/- 1 on the > tap count). Then, I just need to look up the PAD --> IDELAY.D, divide by > 78ps and add 1 for each of the 8 data bits. Am I missing something? > > I can't tell you how many times in my life I wished I could slide the > clock or data to account for internal chip routing delays. Especially on > pad to pad delay paths that went through a flip-flop. > > This seems too good to be true - so I must be missing something. > > Trevor Coolidge Hi Trevor, the IDELAY calibrates against 200MHz clock. there is no need to have any of the IOs toggling or having any signal, all you need is 200MHz reference clock. In early xilinx docs this 200MHz was required to come directly from external source, but later it was relaxed so it is allowed to generat the 200MHz using a DCM. AnttiArticle: 112239
Hello, You can do a pseudo "No-recompile" in the altera flow by doing back-annotation on your design. This will allow you to store the full PAR results of your design, quite similar to the XDL format. This is available on the command-line as quartus_cdb design_name --back_annotate=lab (get back mapping / placing in the ".qsf", IIRC) quartus_cdb design_name --back_annotate=routing (get back routing in a ".rcf" file) Then recompile by specifying to use these constraints files. This is done in the qsf file by specifying: set_global_assignment -name ROUTING_BACK_ANNOTATION_MODE NORMAL set_global_assignment -name ROUTING_BACK_ANNOTATION_FILE design_name.rcf However, I have only tried this on very small designs, but I think this may be effective on bigger ones too. I'm interested in your results if you go this way ! (and i'll investigate precise RAM init in the sof soon). JBArticle: 112240
jbnote schrieb: > Hello, > > You can do a pseudo "No-recompile" in the altera flow by doing > back-annotation on your design. This will allow you to store the full > PAR results of your design, quite similar to the XDL format. This is > available on the command-line as > > quartus_cdb design_name --back_annotate=lab (get back mapping / placing > in the ".qsf", IIRC) > quartus_cdb design_name --back_annotate=routing (get back routing in a > ".rcf" file) > > Then recompile by specifying to use these constraints files. This is > done in the qsf file by specifying: > set_global_assignment -name ROUTING_BACK_ANNOTATION_MODE NORMAL > set_global_assignment -name ROUTING_BACK_ANNOTATION_FILE > design_name.rcf > > However, I have only tried this on very small designs, but I think this > may be effective on bigger ones too. I'm interested in your results if > you go this way ! (and i'll investigate precise RAM init in the sof > soon). > > JB hi JB, this is something that is really interesting for some purposes, but currently I really am looking for solution to have NO compile, only sof and elf merging... here is dump of the SOF parser: Version: Quartus II Compiler Version 6.0 Build 202 06/20/2006 Service Pack 1 SJ Full Version Device: EP1C6Q240C6 OCP: (V6AF7P00A2;V6AF7PBCEC;V6AF7PBCE1;) Option 18: FF00FFFF Option :19 (?) 16 Option :17 (logic) 139900 Option :21 (ram) 433 Option 29: 20006E00,CF19B6F1 CRC16: FE54 AnttiArticle: 112241
Hi!, Could anybody explain me these concepts and their differences?. And what is done in foundation ISE tool of xilinx?. Thanx JajoArticle: 112242
Symon, Well, yes they are differential across the chip. And, what they accomplish is less jitter than if they had been single ended. It is quite a battle: voltage goes down, distances get longer (for smaller wires), more stuff is switching, etc. Gains made may not appear to be substantial, yet without them, the result would have been far worse (no small gain, but a huge loss of performance). Austin Symon wrote: > "Austin Lesea" <austin@xilinx.com> wrote in message > news:ejkus8$kkk1@cnn.xsj.xilinx.com... > >>>So, that's a cool thing. Did you guys do any measurements on the jitter >>>performance of this? I.e. how much jitter is added to a differential data >>>signal coming out of an IOB clocked by a BUFIO driven from a differential >>>clock coming to the FPGA 'Clock Capable' pins.? >> >>Yes, we have performed a great deal of characterization. And the clock >>capable pins, or even a plain IOB has no real difference in jitter >>performance. >> > > Hi Austin, > Thanks for getting back! Your reply surprised me; I now wonder just what > does the diff clock routing bring to the party if not better jitter > performance? BTW, are the regular global clock networks differential? > Thanks, Syms. > >Article: 112243
Thank you for the clarification. "Antti" <Antti.Lukats@xilant.com> wrote in message news:1163855682.873228.289260@e3g2000cwe.googlegroups.com... > > Trevor Coolidge schrieb: > >> I am working on a design that takes a source-synchronous LVDS bus (8 data >> bits + clock, SDR) at a high speed (250MHz) as the input off a cable. I >> will be using the XC4VLX15 part. I read in the databook about the >> IDELAY/IDELAYCTRL operation that can be used to account for package and >> routing skews. What I don't quite understand is the calibration process. >> I >> understand the timing (64 taps @ 78.125Mhz with non-accumulating error) >> and >> how an n-tap delay line works. I just don't understand how to calibrate >> a >> signal dynamically without an input signal being present. Since my data >> and >> clock source is external (and I have no idea when data will start) I >> don't >> understand how the calibration can take place. When the cable is idle, >> the >> clock line will toggle, but the data lines will all be static. (I do see >> that an idle pattern of FF-00-FF-00... could be handy). When the cable >> is >> not connected though everything will be 0 - even the clock. >> The other option seems to be the fixed delay approach - then I just >> need >> to use the static timing analyzer to account for the flight time and >> routing >> delays so that they all "line-up" right on the balls. The datasheet >> claims >> a maximum flight-time skew of 80ps for any pin in the device (+/- 1 on >> the >> tap count). Then, I just need to look up the PAD --> IDELAY.D, divide by >> 78ps and add 1 for each of the 8 data bits. Am I missing something? >> >> I can't tell you how many times in my life I wished I could slide the >> clock or data to account for internal chip routing delays. Especially on >> pad to pad delay paths that went through a flip-flop. >> >> This seems too good to be true - so I must be missing something. >> >> Trevor Coolidge > > Hi Trevor, > > the IDELAY calibrates against 200MHz clock. > there is no need to have any of the IOs toggling or having any signal, > all you need is 200MHz reference clock. In early xilinx docs this > 200MHz was required to come directly from external source, but later > it was relaxed so it is allowed to generat the 200MHz using a DCM. > > Antti >Article: 112244
Jajo, They are related to external connections. The setup time is asking "How long before your clock source is the data guaranteed to be valid". The output valid delay time is asking "How long after your input signals does it take for your output to be valid". The testbench waveform can use a complete system timing model to generate a valid simulation for post-routed designs. Assuming you are just getting started ... set them to 0 (ideal) for now. It will allow you to get your logic correct. Then once your device targeting is done you can deal with the timing issues. (Since you don't know what they are you are probably not even really targeting a device yet). Trevor "jajo" <jmunir@gmail.com> wrote in message news:1163851939.665330.300000@h48g2000cwc.googlegroups.com... >I am new in this field and I have been working with ISE Xilinx tool. > When I want to create a testbench waveform I have to insert several > values, two of them are: Input setup time & Output valid delay. I do > not understand them: > > 1. What do they mean?. Are they related to external devices?. > 2. How can I know which values they have?. > > > Thank you!. > > Jajo >Article: 112245
Al, My experience is that FPGA's definitely add jitter. The amount added depends on the device loading. I spent some time using test equipment to measure induced jitter. My observed numbers were no where near the 15pS you have quoted. The best I could ever discern was around 100pS. This was done about 1.5 years ago, so the technology has changed. I read an approach on this board where someone suggested using a Virtex 4, with multiple inputs simultanously compared and a calibration procedure to lower the signal uncertainty. Trevor "Al" <alessandro.basili@cern.ch> wrote in message news:ejkk93$1cb$1@cernne03.cern.ch... > Hi to everyone, > I'm developing some electronics to make a time measurement with a > resolution of 25 ps. I'm using a dedicated ASIC to do so but I'm giving > the signals to the ASIC through an FPGA. > The way is very simple, basically I have some signals coming to my fpga > which I will mask with some combinatorial logic and a configurable > register so that I can allow some measurements or some others. The output > of this "masking" will go to the ASIC. > They assert (and here is the question) that a clocked device as an FPGA > may add some jitter to the signals due to the substrate current overload > (for the presence of the clock) that will lead to some 15 ps jitter over > the signals. I don't know how they could resolve this value but I'm > assuming they were telling the truth about numbers (at least, while I have > some doubts about explanation of those numbers). > Can anyone say something about this? Does it sound reasonable? > > Al > > -- > Alessandro Basili > CERN, PH/UGC > Hardware DesignerArticle: 112246
According to the Virtex 4 data sheet, the setup/hold window widens considerably when using non-zero IDELAY delay (either in a normal input block or as part of ISERDES)... For example, for a -10 part, DDR mode, setup 8.84, hold -6.51 (p28 of data sheet) gives a minimum data valid window (assuming perfect clk alignment,no jitter, etc) of 2.23ns, meaning the clk frequency for DDR data must be much less than 224MHz... seemingly somewhat less than might be implied from Table 15. These setup and hold are defined for "D pin" with respect to "CLK". Assuming that "D pin" refers to the D pin top left of Fig 8.1, p352 of Virtex 4 user guide, this seems meaningless if the IDELAY is used to delay the data (e.g to compensate for skew of the bus on the PCB). Should these values be shifted according to the delay applied by the IDELAY, or do they in fact these values apply to D and CLK of the register flip flops themselves AFTER the IDELAY - e.g as shown IFF1 etc towards the right of Fig 7.1 p309? I would be grateful for any clarification as I can't work it out from the datasheet! Many thanks TomArticle: 112247
John Adair wrote: > Even if you implement Cardbus (essentially PCI) rather than > PCMCIA(essentially ISA) you won't get continuous 33MHz transfer other > than short periods of time. ExpressCard format can go this fast > providing the architecture behind it can support that data rate. Hi John, I didn't heard about this standard before. It's compatible with most PCMCIA interfaces available on laptops ? There is somewhere a documentation available ? thx, Vasile > > John Adair > Enterpoint Ltd. - Home of Tarfesock1. The Cardbus FPGA Development > Board. > > vasile wrote: > > Hi everybody, > > > > A part of a project I'm designing is a PCMCIA bus card with a 32 bit > > data system bus. > > The system included in the card has a multicore DSP, an ARM processor, > > some NOR FLASH, SDRAM memory and a FPGA. > > The FPGA is used for the PCMCIA interface to the system bus and some > > high speed math as a companion for DSP. The purpose of the whole PCMCIA > > interface is to transfer some data from the SDRAM into PC, in real time > > at 33Mhz clock rate. The card data system bus is running at 133MHz. > > > > How you'll chose the design for the best card bus interface, knowing > > there are some fast processes on the internal bus: > > > > a. using the FPGA as a slave memory selected by the DSP and > > implementing a FIFO inside the FPGA . An interrupt request will notice > > the PC to start download data and empty the FIFO. > > b. using DMA control over the system bus from the FPGA (FPGA as master, > > DSP as slave) > > c. other (please detail) > > > > thank you, > > VasileArticle: 112248
vasile wrote: > I didn't heard about this standard before. It's compatible with most > PCMCIA interfaces It's unrelated to PCMCIA and is completely incompatible, having a different connector. A few recent laptops support it, and it will probably (eventually) replace PCMCIA. In the meantime we have the joy of "legacy-free"!Article: 112249
On 2006-11-18 07:11:36 -0700, "Antti" <Antti.Lukats@xilant.com> said: > here is dump of the SOF parser: > > Version: Quartus II Compiler Version 6.0 Build 202 06/20/2006 Service > Pack 1 SJ Full Version > Device: EP1C6Q240C6 > OCP: (V6AF7P00A2;V6AF7PBCEC;V6AF7PBCE1;) > Option 18: FF00FFFF > Option :19 (?) 16 > Option :17 (logic) 139900 > Option :21 (ram) 433 Option 29: 20006E00,CF19B6F1 > CRC16: FE54 > > Antti I suspect that there is another layer of parsing involved. Here's what I'm getting from a relatively complex model that we are using: Quartus II Compiler Version 5.0 Build 171 11/03/2005 Service Pack 2 SJ Full Version Device: EP2S60F1020C3 OCP: (V6AF7PBCEC;V6AF7PBCE1;) Option 18: FF00FFFF OPT:19 16 1073124: 00 00 00 00 20 00 20 00 - 00 00 01 00 FF FF FF FF .... . ......... OPT:17 1923240 1073124: 00 00 00 00 00 00 DC C4 - EA 00 01 00 00 00 00 00 ................ OPT:21 6928 1073124: 00 00 00 00 00 00 1C D8 - 00 00 01 00 00 00 00 81 ................ Option 23: 2 CRC16: 83F8 ok However, thanks for the start. Now, to dig into the RAM DaR
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