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
yes the roll over done.:)) some conflict was with the declarations and i assigned the HEX value of its setting straitgh away. now i am trying to find if there is any signal that idicating when the counter has rollover but as far now didnt find any.:(Article: 128826
Sky465nm@trline5.org wrote: > So IF you have defined DONE as TOTEM-pole, you must NOT attach a PULL-up. > If you have defined DONE as OPEN-drain, you must attach a PULL-up to 2.5V. I've set "Configuration pin done" to Float and checked "Drive done pin high" as suggested by table 2.6 of ug332. The thing is that I'm not getting CRC errors now, but Done won't go high either. Since this sounded like an entirely new problem I once again started hunting google and found some similar errors where it seemed like the byte order of the programmer was incorrect but nothing definitive. So I'm wondering if I'm interpreting the XSVF file correct. It has a command like this; 0D...data like...800633554CAAFFFF If I understand the docs (xapp503 is helpful, the example implementation of xapp058 as well) correctly, I have to output it as this; FFFFAA4C55330680 with (for example) 06 being "clock out a 0, then 11, then another 5x 0". Also, if the first byte in after a command like 0D says for example 3F and I've got to clock out x bytes + 6 bits, I'm clocking out the x bytes, then 5x a 1, and the last 1 while switching to a new state. Or when the next command is more data (like another 0D command) I just clock out 6x a 1. This last bit would be the '2' in '3'. In iMPACT I program the XC3S400 directly with the .bit file so if the bit file requires any bit/byte flipping I assume iMPACT does it. Is this all correct? It seems to work without an hitch for XSIR commands and the like but I'm worried the bit file shouldn't be flipped like this. Cheers, Mike http://projectvga.orgArticle: 128827
On Feb 6, 7:24=A0pm, John Retta <jre...@rtc-inc.com> wrote: > IMHO under following assumptions, timing sim on placed and routed > gatelevel netlist adds little value with great effort : > [1] Design passes RTL functional sim. > [2] Routed design is well constrained via static > =A0 =A0 =A0timing analysis. > =A0 =A0 =A0Note : Look at static timing analysis tool for > =A0 =A0 =A0ability to flag unconstrained paths. =A0Xilinx > =A0 =A0 =A0trace uses -u option. =A0Then go back and add > =A0 =A0 =A0constraints for any paths which have slipped > =A0 =A0 =A0thru crack, and rerun trace with -u option. > [3] Synchronous design practices have been observed > =A0 =A0 =A0with excruciating care. > <snip> > What type of error would a timing sim catch that > have passed thru the above 3 wickets? > Wicket 1. Inadequate test cases. Not functionally verifying the many different modes of operation. Turn on code coverage for the first time in your life and see how poorly you've been exercising your designs. Then shudder at the thought of turning on those other options that check for condition coverage, etc. Wicket 2. 'Well constrained??' What does that mean? To pass this wicket, incorrectly add a multi-cycle (or false path or ...) timing constraint. What will catch the incorrectly added constraint? Wicket 3. 'Excruciating care??' What does that mean? The dictionary definition of 'excruciating' is extremely painful; causing intense suffering; unbearably distressing; torturing....OK, so you didn't mean *that* definition ;) the next defn. is exceedingly elaborate or intense...in any case, even with such 'care', this does not verify that synchronous design practices have actually been observed. Even if it did, how do you verify that 'excruciating' care has been oberved and not 'pretty good' care? How do you measure the level of care? How do you implement this care procedure? What are the metrics? All three wickets can be passed by those less skilled in design resulting in a design that fails on the bench that 'might' have been caught by running a timing sim (or other methods). For the more skilled, I agree that timing sims are painfully slow and catch virtually no design errors. But the real reason for not catching design errors has to do with the skill of the designer and the quality of the designs that they produce. There is no substitute for skill, but also no really good measure of it either. The less skilled might not really know how 'less' they are and they would probably do well to use many different forms of verification. As they become more skilled, they'll naturally tend to see which methods are helping them find problems and which are a bit of a time waster, but they have to evaluate that themselves. Kevin JenningsArticle: 128828
Gerry <Gerry@hotmail.com> writes: >> In this case the reset port can be omitted, I wanna sythesis this as a >> BRAM on a Xilinx FPGA. Hope that works! > > Well .. unfortuatnely XST tells me that the RAM will be implemented > with LUTS and that I have to describe it in a way that BRAM can be > instatiated, so that initial values can be stored in it... > In which case you have to have the single clock latency that you described - sorry - that's just the way BRAMs work. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 128829
We are want to use a spartan 3E in the very small chip scale package because of space constraints. However the 4 MBit serial prom for this device is almost the same size as the whole fpga. Does anybody know of an alternative which is much smaller? Taco Walstra University of AmsterdamArticle: 128830
> In which case you have to have the single clock latency that you > described - sorry - that's just the way BRAMs work. > Yes, I am now using the Core generator to generate a distributed RAM with latency zero. Will be a little bit more painful, but hope to get it working with initialising it. Obviously the sythesis will take a lot of time and occupy a lot of logic but this I will accept now for a test! Maybe I have to rethink and rewrite the design to be conform with sychronous BRAM!Article: 128831
Hi, I have two questions. ============================================== Marking False paths for timing ignore in a multiple clock design: =============================================== I have a design with three clocks. All clocks are indpendant and are not derived. The data originating in these clock domains cross other clock domains. I have used synchronizers (fast to slow and slow to fast) wherever applicable. However for correct timing analysis and timing closure, I need to identify signals which cross multi clock domain. The design is synthesized for Spartan3 xc3s1000. I am using timing constraints editor to identify such paths and put them in the ucf file with the 'TIG' against them. The way I am doing it is a bit cumbersome. First, I identify all signals(FFs) which are clocked on one clock, make a domain of them. Similarly, I identify all other signals(FFs) which are clocked on other two clocks and make two seperate domains. Identifying the signals is a very tiring process as one has to go through all the RTL files to look for 'always' blocks and the signals in those blocks. Once the domains have been created, the domains are 'Tiged' against each other using the following syntax(an example). TIMESPEC "TS_uC_to_66" = FROM "domain_clk_uC" TO "domain_clk_66" TIG; TIMESPEC "TS_66_to_uC" = FROM "domain_clk_66" TO "domain_clk_uC" TIG; The problem is, this whole process takes allllllooooot of time and prone to errors. Is there a better and fast way to accomplish the same. Do I really need to add all clocked signals? The ucf file generated in this manner takes 7-8 thousand of lines (at least for my design). ============================================== Virtex 2 Pro support in higher versions of ISE: =============================================== I have ML310 board with Virtex 2Pro xc2vp30 on it. ISE 7.1 has the support for the particular family and deivce however, I dont see the same part appearing in ISE 8.1 or ISE 9.2. Has the part been discontinued? If not, how can I add the library for the particular device in ISE 8.1 or ISE 9.2. Thanks in advance FarhanArticle: 128832
Finally I think I might be on the right track with GDB. I found that the following sequence works for me: 1) Download bit stream. 2) Run xmd and download .elf file but not run it. 3) Start GDB over JTAG but with the option Continue set. The default seems to be Run in which case GDB seems to issue the error messages that I saw before. 4) GDB should then run until the first breakpoint. Maybe this is all obvious but it took me a long time to get it right. John RobbinsArticle: 128833
On Feb 7, 8:29 am, taco <trala...@joepie.nl> wrote: > We are want to use a spartan 3E in the very small chip scale package because > of space constraints. However the 4 MBit serial prom for this device is > almost the same size as the whole fpga. Does anybody know of an alternative > which is much smaller? > Taco Walstra > University of Amsterdam 1) Don't know how much this helps, but if you're using the 3S500E and don't fill the part up too much, your bitstream can fit into a 2 Mbit prom if you compress it. Banking on that however can lead to problems if your design expands and the compressed bitstream grows over the 2 Mbit boundary. 2) Do you have some other storage available that could be shared to with the bitstream data? A microcontroller with attached flash? A 120 Gbyte hard drive attached via the host system interface? Or does your FPGA need to come up running without any support from software? 3) Any chance of using a Lattice XP2 in the 132-ball csBGA instead (no external prom required)?Article: 128834
On 7 Feb., 14:29, taco <trala...@joepie.nl> wrote: > We are want to use a spartan 3E in the very small chip scale package because > of space constraints. However the 4 MBit serial prom for this device is > almost the same size as the whole fpga. Does anybody know of an alternative > which is much smaller? > Taco Walstra > University of Amsterdam there are QFN versions of SPI flash available, they much smaller. I also have a desing where SO-8 package is HIGHEST component and almost the same size as QFN132 packaged FPGA. I used SO-8 as it is few cent cheaper than QFN SPI flash. Antti LukatsArticle: 128835
On Feb 7, 2:39 am, shac...@gmail.com wrote: > Hi Kyprianos, > > Your best bet will be to go for EAPR with ISE 9.1i SP2. I do research > in partial reconfiguration and when I was at a Xilinx Partial > Reconfiguration workshop in TU Delft in the Netherlands last year, the > Xilinx presenter alluded to the fact that Virtex-5 FPGAs are being > supported in 9.1i. > > PlanAhead is the front-end to EAPR and ISE, so all it really does it > give you a graphical, user-friendly interface, generate the > constraints files and execute the tools for you rather than using your > own scripts. > > Austin, thanks for your reply and I believe Kyprianos did ask if which > versions of the ISE and EAPR tools support Virtex-5. Apart from that, > I do believe that the old Virtex (first generation) family does have > some problems regarding glitchless reconfiguration? It would be great > to talk to you to obtain more definitive answers from Xilinx! Were you > at TU Delft (FPL2007) last August? > > Cheers, > Shannon > > On Feb 7, 4:25 am, austin <aus...@xilinx.com> wrote: > > > Kyprianos, > > > Have you read: > > >http://www.xilinx.com/products/design_tools/logic_design/advanced/par... > > > ? > > > All Virtex parts (original through V5) "support" partial reconfiguration > > (able to load new partial bitstreams while continuing to run) in > > hardware. Is your question more one of what tools and what is the > > recommended flow? > > > Austin Hi all, Austin and Shannon thank you for the reply. It is clear that Virtex-5 architecture does support partial reconfiguration. My question was more about the tools. Which versions of the ISE and EAPR - as well as of EDK for self-reconfiguration with a uP - are needed to partially reconfigure a Virtex-5? I understand that partial reconfiguration becomes less painfull with the use of PlanAhead. Although someone can proceed without it. In the Xilinx's website, Section "Partial Reconfiguration Early Access software tools for ISE 8.2i SP1" (http://www.xilinx.com/support/ prealounge/protected/archive_82.htm), it is mentioned that "These software tools only support the Virtex(tm)-4, Virtex-II and Virtex-II Pro architectures. They must be installed on top of the ISE(tm) 8.2i sp1 release.". There is nothing reported regarding Virtex-5 and recent versions of ISE, e.g. can 9.1.2i EDK + 9.1i ISE w/ SP3 + EAPR be used to apply self-PR on the Virtex-5? Is there any reference design that I can get? KyprianosArticle: 128836
Shannon, My email is good (austin@xilinx.com). As for 'old' Virtex (220nm), I seem to recall something, but that is ancient history now. If anyone is using Virtex for their research, they should contact the XUP and get some new parts! AustinArticle: 128837
Kyprianos, All I know about software, is that the versions MUST match (IE 9.1 ISE + 9.1 EDK is OK, but 9.1 ISE + 9.2 EDK IS NOT OK!). Yes, Virtex 5 has been out for 18 months now, with the LX, LXT, SXT all in production, so there are even older versions (ie 8.x) that support V5, and hence, partial reconfiguration. I always recommend starting any new project with the latest release of software so as to take advantage of all of the bug fixes (without having to load service packs). The next best choice is to use the immediate previous version, with all service packs. This is just the "way of software" and really has nothing to do with Xilinx: the latest version inevitably has some new bugs, and the immediate previous version is usually the best possible choice for software that has the fewest unknown, or unfixed behaviors. The newest version has all the resources going to fix things in the shortest time. The previous version has had perhaps 100,000 users banging on it for 6 months or more. AustinArticle: 128838
Sorry, but inadequate test cases do not suddenly do better coverage when run in a timing sim vs an RTL sim. When I say well constrained, you give an example of poorly constrained. Quibbling over my use of word excruciating? Oh well. Once again, when I specified a higher level of care on synchronous design practices, the area you question is when these are weakly enforced. The original poster described two places he has worked, one believing in timing sim on FPGA, other bypassing. Really there are two camps of thought. I couched my response with IMHO in two places ... meaning I recognize the fact that there are two camps, and I don't particularly want to spend the rest of my day debating with someone from other camp. Just wanted to clarify what the viewpoint of the "can skip" timing simulation for an FPGA design flow. My last two points in first email were pretty key : - in circuit testing, over temperature, with thorough test cases is an ultimate test for "goodness" whether it be an FPGA or an ASIC. - Cost benefit ratio of gate level sim very high. If I ran into someone in gatelevel sim camp of FPGA, I would explain my points, but not be dogmatic about it. Reality, as long as there is consideration for why certain things are done is really the important issue. -- Regards, John Retta Owner and Designer Retta Technical Consulting Inc. Colorado Based Xilinx Consultant phone : 303.926.0068 email : jretta@rtc-inc.com web : www.rtc-inc.comArticle: 128839
Goli, Thanks for the post. SONET/SDH is not for the faint of heart! I know we have many designs out their with V5 that ARE doing SONET/SDH, but that doesn't mean they are "easy" or do not require some other somewhat difficult circuits/tricks/techniques. The timing issue is one that plagues ALL SONET/SDH solutions, and is in no way unique to Xilinx. I spent 7 years on the ANSI/ATTIS committees that were responsible for synchronization standards of SONET. I at least tried to make it work, in spite of the crazy thinking. If we had it all to do over again, I am sure we would not have created such a synchronous mess: the old asynchronous digital hierarchy worked so well, and was so simple (in retrospect). The very first meeting started with "we shall make it entirely synchronous, because integrated circuits are expensive, difficult to design and make, and we must use the fewest transistors possible." That seems completely stupid today! A good indication why the "old" phone companies became obsolete -- modern market forces and the advancement of technology left them all in the dust (literally). The shared PLL is a "feature" of V5, and as noted, does make the design more difficult, but not impossible. AustinArticle: 128840
>In iMPACT I program the XC3S400 directly with the .bit file so if the >bit file requires any bit/byte flipping I assume iMPACT does it. You can use this software to program .bit files directly from the parallel port: http://svn.wantstofly.org/jtag/trunk/ And this parallel cable hardware: http://www.xilinx.com/support/programr/jtag_cable.pdf At least I know this works.Article: 128841
Mike, I am jumping on this subject now but I may have few words on it. These FPGAs are very easy to configure. They allways work well. There are several simple and common mistakes that can prevent of having it working properly. Maybe you have already passed them but here they are: 1) be sure the BIT file generated has the correct option for innitialization clock source. The default option is the CCLK for Master or Slave Serial mode. When you configure using JTAG you must change it to JTAG CLOCK. The IMPACT tool normally does it for you with a warning when you are going to configure the device. But in some cases it may not do the bit change and the FPGA won't innitialize even if it configures correctly. 2) The DONE pin must have a pull-up. In your schematic it is floating. The internal DONE circuit requires a very fast rising time and the pin must have a strong pull-up externaly. Something like 220 or 330ohms to the 2.5V supply rail (for your FPGA). Sometimes driving the DONE pin HIGH (BIT file option) may help but leaving it floating is not a good design practice. A LED in the DONE pin is always a must because then you can see the FPGA is correctly configured whenever you make a change in the bit file stored in the PlatformFLASH. When the system starts to work don't forget that you will need a power cycle every time you re-write the PlatformFLASH with a new design in order to have it downloaded to the FPGA. It is a common mistake doing the update in the FLASH but forgeting the FPGA will get it only after a reset in the PROGRAM_B pin. You do not need to change the mode pins to gain JTAG control and configuration. You can keep them at 000 (Master Serial) and it will work perfectly. If you had difficulties with JTAG before it was because some hardware problem or because the USB code translation to JTAG tha may not use the proper commands. When you use a Xilinx cable it works. For a reference on how to do the circuitry for the configuration part I would recommend to download the Spartan-3 Demo Board schematic. I believe you can find it at Xilinx or at Digilent website. -AugustoArticle: 128842
AugustoEinsfeldt <aee@terra.com.br> wrote: >1) be sure the BIT file generated has the correct option for.. >2) The DONE pin must have a pull-up. In your schematic it is floating.. >You do not need to change the mode pins to gain JTAG control and.. >For a reference on how to do the circuitry for the configuration part >I would recommend to download the Spartan-3 Demo Board schematic. I >believe you can find it at Xilinx or at Digilent website. http://www.xilinx.com/products/devkits/HW-SPAR3-SK-UNI-G.htm http://www.xilinx.com/support/documentation/boards_and_kits/ug130.pdf Page 57 (of 64), Figure A-4. Correct?Article: 128843
HI all, First , I would like to thank the folks who have helped me to solve my last problem of optimizing my Digital Down Converter design to shrink 400% and fit one Virtex chip. Apparently, all I did was to increase the hardware oversampling of my DAFIR blocks to use less parallel filters which worked like a charm. Thank you. However , I have decided to explore the posibility of using the newer FIR compiler block which uses more DSP48 resources instead of the DAFIR block which may not implement resources that efficiently. However I encountered error while resource estimating on the postmap option. The error reads"Continuous Sample Times not allowed". And yes , I am using a DDC structure of CIC-CFIR-PFIR filters. The error also seems to point to the Comb part of the CIC filter. I would appreciate any comments to inspire any solutions. Thank you.Article: 128844
"maverick" <sheikh.m.farhan@gmail.com> wrote in message news:4f794ccd-3e1a-4276-aba2-5ae760cb3e42@q77g2000hsh.googlegroups.com... > > The problem is, this whole process takes allllllooooot of time and > prone to errors. Is there a better and fast way to accomplish the > same. Do I really need to add all clocked signals? The ucf file > generated in this manner takes 7-8 thousand of lines (at least for my > design). > NET "clk_uC" TNM=FFS "domain_clk_uC"; NET "clk_66" TNM=FFS "domain_clk_66"; I guess you didn't read the constraints guide. What's more worring is that you have so many signals crossing clock domains. You could be headed for a world of hurt. Happy days, Syms.Article: 128845
> ============================================== > Marking False paths for timing ignore in a multiple clock design: > =============================================== NET "clk100MHz" TNM = tnm_100domain; NET "clk200MHz" TNM = tnm_200domain; # cross-clock exceptions - all cross-clock signals are treated as asynchronous. TIMESPEC "TS_crossclk1" = FROM "tnm_100domain" TO "tnm_200domain" TIG; TIMESPEC "TS_crossclk2" = FROM "tnm_200domain" TO "tnm_100domain" TIG;Article: 128846
"Gerry" <Gerry@hotmail.com> wrote in message news:foa6ej$fif$1@aioe.org... > Hi > > I have done some VHDL implementations that were successfully running on an > FPGA. However, I still feel unsecure about what constructs so that the > design is working in the end. I am using XST, they have some modelling > advices for specific constructs. Are there any other sources > that could help me to improve my code? > > Many thanks! This, unfortunately, isn't and easy question to answer in general. There are three classes of un-synthesizable code: 1. Constructs that make no sense for synthesis at all, such as delayed signal assignment or file I/O operations. 2. Constructs that are in theory synthesizable, but which in practice almost certainly aren't, for example transcendental floating point operations. 3. Constructs which should be synthesizable, but which aren't because of the limitations of the tools in use. The grey area is number 3, but, luckily, these days tools are a lot better than they were a few years ago, and from experience there are very few items left in this class for most decent tools (including XST). The simple answer is that if your synthesis tool accepts the code and meets area and timing requirements then your job is done.Article: 128847
Which I/O mode like LVDS_25 etc.. is suitable to interface USB on a Spartan-3 FPGA ..? (I know the single ended signaling within USB). The idea being to eliminate any external usb transceiver.Article: 128848
On Feb 7, 10:32=A0am, John Retta <jre...@rtc-inc.com> wrote: > Sorry, but inadequate test cases do not suddenly do > better coverage when run in a timing sim vs an RTL > sim. > You ended your earlier post by asking for a type of error that a timing sim could catch that could get through the three wickets, that's what I was repsonding to. Wicket 1 was simply "Design passes RTL functional sim". That can be a pretty low bar to hurdle until you start including minimum coverage metrics of some sort to insure that the design is at least being fully exercised. Another way to fail timing sim even with complete code coverage is, lets say the designer uses either enumerated types in a state machine and forgets to include a reset mechanism but the reset state happens to be the first enumerated item. The functional sim passes but does so because it relied on the simulator initialization. Let's say the state machine gets implemented now as 'one-hot' in some device. If that device at power up resets flops to 0 we're in an 'impossible' state if no power up state is guaranteed then the gate sim should have 'X' for the state machine. That's a way to get through wicket #1 and still have an incorrect design. > When I say well constrained, you give an example of > poorly constrained. > No, I gave an example of a design error. Design errors happen all the time, various forms of verification are intended to find those errors but I'm not aware of a tool which will validate that a particular input timing constraint itself is correct or not. That's a way to get through wicket #2 and still have an incorrect design. > Quibbling over my use of word excruciating? =A0 Only in fun, was meant to be taken lightly. > Oh well. > Once again, when I specified a higher level of care on > synchronous design practices, the area you question is > when these are weakly enforced. > I questioned how you validate that the appropriate amount of care has been applied and how one would measure this. Without such unbiased measures, the level of detail that represents appropriate (or excruciating) care means only as much as the person providing the care thinks it might mean. That's a way to get through wicket #3 and still have an incorrect design. > meaning I > recognize the fact that there are two camps, and I > don't particularly want to spend the rest of my day > debating with someone from other camp. =A0 For the record, I'm not in the "timing sim an FPGA" camp. > Just wanted > to clarify what the viewpoint of the "can skip" > timing simulation for an FPGA design flow. > And I was responding to ways that one can clear your wickets with an incorrect design and tried to show that which verification techniques are used can clearly be a function of the skill of the designer. > My last two points in first email were pretty key : > - in circuit testing, over temperature, with thorough > =A0 =A0test cases is an ultimate test for "goodness" whether > =A0 =A0it be an FPGA or an ASIC. > - Cost benefit ratio of gate level sim very high. Agreed. > > If I ran into someone in gatelevel sim camp of FPGA, > I would explain my points, but not be dogmatic about > it. =A0Reality, as long as there is consideration for > why certain things are done is really the important > issue. > Agreed, and all I was really adding is that you can't simply evaluate those considerations without regard to the level of skill of the designer. Kevin JenningsArticle: 128849
On 7 Feb., 18:37, Sky46...@trline5.org wrote: > Which I/O mode like LVDS_25 etc.. is suitable to interface USB on a Spartan-3 > FPGA ..? (I know the single ended signaling within USB). > > The idea being to eliminate any external usb transceiver. bad idea it is possible and has been done, but its not recommended and should not be attempted for any commercial product. 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