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
Philip, 1) 1,2,5 MHz - take your pick. 2) 40 MHz 3) Asynchronous I also have a parallel interface that is clock triggered at 8 MHz and another at 20 MHz. Some interfaces are input, some output, and some bidirectional. Philip Freidin wrote: > 1) What frequency is your serial clock? > 2) What frequency is your master clock? > > 3) Are the related to master clock source or are they > asynchronous to each other? > > If answer 3 is asynchronous, you should look at my last > 3 articles. > > Philip.Article: 37501
I have a question about synthesis and timing reports in Xilinx ISE4.1. I looked at the docs for the UCF file, but didn't find what I was looking for. I want to know how to specify the load capacitance for output pins so that synthesis and timing reports calculate the correct prop delay through the IOB cell. Page 3-31 of the Data Book 2000 shows how to calculate the delay manually, but I need to tell the tool to do it. Thanks, DavidArticle: 37502
"S. Ramirez" wrote: > "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message > news:3C16BA88.96F9E549@algor.co.uk... > > > Don't do it. To be precise it is by far the best practice to make sure > that > > during simulation startup all RAMs are initialised to unknowns since .... > > ... IMO This "feature" is very dangerous and using it will make the code > > highly non-portable. It also encourages s/w engineers to be sloppy & not > > initialise RAMs before using them leading to some really deep and hard to > > trace bugs later on. > > Rick, > What's wrong with initializing RAMs to all zeros? That way, you get a > known simulation, but you also make the SW engineers initialize the RAMs, > since all zeros is mostly useless. At least the hardware will come up in a > known state. > Simon Ramirez, Consultant > Synchronous Design, Inc. > Oviedo, FL USA My argument goes, roughly and in extreme form, like this: ... and some time in the future the product becomes so successful (no Christmas stocking is complete without one) that the design gets ASIC'ed. AFAIK in general ASIC RAMs don't aren't initialisable & don't have a reset pin. This difference fails to get passed on to the s/w team (easy enough to see how this could happen since Hey! its the same chip really). Result: Giant product recall when some piece of s/w that was implicitly relying on the RAMs "powering up to 0" fails in the field. Note that my argument extends to my personal belief, on the same grounds, that the Xilinx "global reset during configuration" feature is equally pernicious. Now if, as a later post suggests, the RAM clear feature is implemented via some user written state-machine then, of course, the argument falls. But IMO this is a waste of h/w resource and adds yet more to the simulation/regression burden.Article: 37503
"Rick Filipkiewicz" <rick@algor.co.uk> wrote in message news:3C17EC87.15A11A13@algor.co.uk... > My argument goes, roughly and in extreme form, like this: > > ... and some time in the future the product becomes so successful (no Christmas > stocking is complete without one) that the design gets ASIC'ed. AFAIK in > general ASIC RAMs don't aren't initialisable & don't have a reset pin. > > This difference fails to get passed on to the s/w team (easy enough to see how > this could happen since Hey! its the same chip really). > > Result: Giant product recall when some piece of s/w that was implicitly relying > on the RAMs "powering up to 0" fails in the field. > > Note that my argument extends to my personal belief, on the same grounds, that > the Xilinx "global reset during configuration" feature is equally pernicious. > > Now if, as a later post suggests, the RAM clear feature is implemented via some > user written state-machine then, of course, the argument falls. But IMO this is > a waste of h/w resource and adds yet more to the simulation/regression burden. I like the way you think, Rick. You've thought of yet another failure mechanism in the crazy world of FPGA to ASIC conversion. I hope that never happens to me and my client companies. Simon Ramirez, Consultant Synchronous Design, Inc. Oviedo, FL USAArticle: 37504
Rick Filipkiewicz wrote: > > "S. Ramirez" wrote: <snip> > > ... and some time in the future the product becomes so successful (no Christmas > stocking is complete without one) that the design gets ASIC'ed. AFAIK in > general ASIC RAMs don't aren't initialisable & don't have a reset pin. If the ASICs are being touted as FPGA replacements, surely this feature must be duplicated, as also should RAM used as ROM instances ? If that means two RAM densities are needed, then so be it. eg I asssume Altera's HardCopy ASIC flow is OK wrt this issue ? -jgArticle: 37505
below that is my sample,is ti ok? /*fifo read enable if fifo NA_Empty_Out fifo empty flag*/ wire NA_Read_Enable=NA_Read; always @(posedge NA_Clock or negedge Rst ) begin if(Rst) NA_Read<=0; else if(!NA_Empty_Out) NA_Read<=1; else NA_Read<=0; end /*counter[2:0] works if read enable.Data was be shifted by counter control*/ always @(posedge NA_Clock or negedge Rst ) begin if(Rst) NA_Count<=0; else if(NA_Read_Enable) NA_Count<=NA_Count+1; else NA_Count<=0; end /*data read out from fifo were allocated is NA_Des_Data0.1.....7 dividually NA_Data_Out[15:0] :fifo data out NA_Des_Data[7:0] [15:0] */ always @(posedge NA_Clock or negedge Rst ) begin if(Rst) begin NA_Des_Data0 <=16'b0; NA_Des_Data1 <=16'b0; NA_Des_Data2 <=16'b0; NA_Des_Data3 <=16'b0; NA_Des_Data4 <=16'b0; NA_Des_Data5 <=16'b0; NA_Des_Data6 <=16'b0; NA_Des_Data7 <=16'b0; end else case(NA_Count) //synopsys parallel_case full_case 3'b000: NA_Des_Data0 <=NA_Data_Out; 3'b001: NA_Des_Data1 <=NA_Data_Out; 3'b010: NA_Des_Data2 <=NA_Data_Out; 3'b011: NA_Des_Data3 <=NA_Data_Out; 3'b100: NA_Des_Data4 <=NA_Data_Out; 3'b101: NA_Des_Data5 <=NA_Data_Out; 3'b110: NA_Des_Data6 <=NA_Data_Out; 3'b111: NA_Des_Data7 <=NA_Data_Out; default : begin NA_Des_Data0 <=16'b0; NA_Des_Data1 <=16'b0; NA_Des_Data2 <=16'b0; NA_Des_Data3 <=16'b0; NA_Des_Data4 <=16'b0; NA_Des_Data5 <=16'b0; NA_Des_Data6 <=16'b0; NA_Des_Data7 <=16'b0; end endcase end Can you help me check it?Article: 37506
The RAM only gets initialized on device configuration, not on a global reset. There is no RAM reset pin. The FPGA RAMs get initialized with something on configuration whether you like it or not. The default, and most common, is all bits zero. If you are concerned with a design that might go to ASIC, shouldn't the software folks be limited in what they can rely on too, after all the hardware side gets all sorts of don't use this and that feature restrictions, no instantiation etc. I don't think it is unreasonable to tell software that they have to assume RAM in not initialized. In my experience, which numbers into the hundreds of FPGA designs, I haven't seen a single case where the design actually went to ASIC, although a decent percentage of the customers naively believe that theirs will and want the FPGA design done generically enough to go directly to ASIC. Of course they also want performance, or they probably wouldn't have called me in the first place. Rick Filipkiewicz wrote: > "S. Ramirez" wrote: > > > "Rick Filipkiewicz" <rick@algor.co.uk> wrote in message > > news:3C16BA88.96F9E549@algor.co.uk... > > > > > Don't do it. To be precise it is by far the best practice to make sure > > that > > > during simulation startup all RAMs are initialised to unknowns since .... > > > ... IMO This "feature" is very dangerous and using it will make the code > > > highly non-portable. It also encourages s/w engineers to be sloppy & not > > > initialise RAMs before using them leading to some really deep and hard to > > > trace bugs later on. > > > > Rick, > > What's wrong with initializing RAMs to all zeros? That way, you get a > > known simulation, but you also make the SW engineers initialize the RAMs, > > since all zeros is mostly useless. At least the hardware will come up in a > > known state. > > Simon Ramirez, Consultant > > Synchronous Design, Inc. > > Oviedo, FL USA > > My argument goes, roughly and in extreme form, like this: > > ... and some time in the future the product becomes so successful (no Christmas > stocking is complete without one) that the design gets ASIC'ed. AFAIK in > general ASIC RAMs don't aren't initialisable & don't have a reset pin. > > This difference fails to get passed on to the s/w team (easy enough to see how > this could happen since Hey! its the same chip really). > > Result: Giant product recall when some piece of s/w that was implicitly relying > on the RAMs "powering up to 0" fails in the field. > > Note that my argument extends to my personal belief, on the same grounds, that > the Xilinx "global reset during configuration" feature is equally pernicious. > > Now if, as a later post suggests, the RAM clear feature is implemented via some > user written state-machine then, of course, the argument falls. But IMO this is > a waste of h/w resource and adds yet more to the simulation/regression burden. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 37507
Eric Smith <eric-no-spam-for-me@brouhaha.com> wrote in message news:<qh3d2gytdo.fsf@ruckus.brouhaha.com>... > "H.L" <alphaboran@yahoo.com> writes: > > but i have another problem now, > > webpack does not support VirtexE XCV600 (goes up to XCV300). My > > implementation will be on a XCV600 FPGA , is there any way to make WEBPACK > > support the above FPGA? > > Yes. By deinstalling Webpack and installing Foundation ISE 4.1. You have selected the wrong design flow. If you choice the EDIF design design flow, then ise won't let you include any vhdl or veriolg. You need to re-create a new project and select the correct design flow.Article: 37508
At those low rates (compared to your master clock), I'd sample it with the master clock. Robert Abiad wrote: > Philip, > > 1) 1,2,5 MHz - take your pick. > > 2) 40 MHz > > 3) Asynchronous > > I also have a parallel interface that is clock triggered at 8 MHz and > another at 20 MHz. > > Some interfaces are input, some output, and some bidirectional. > > Philip Freidin wrote: > > > 1) What frequency is your serial clock? > > 2) What frequency is your master clock? > > > > 3) Are the related to master clock source or are they > > asynchronous to each other? > > > > If answer 3 is asynchronous, you should look at my last > > 3 articles. > > > > Philip. -- --Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.com "They that give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, 1759Article: 37509
Hi, When using webpack 3, I was able to create .svf files for CPLD devices. But now when selecting the "Generate Programming File" and entering the IMPACT window, I can choose between Boundary Scan, Slave Serial and Select Map. I have all these options but all the same the .svf file that is created is not the same as the one created by previous version of Webpack. The current file is only 553kb instead of 867kb. (I have no cable connected to my computer). Please could someone help me choosing the right options for creating a .svf file for xc9500 device programming? I am using a parrallel cable to download the .svf files to the board. Thanks for any hint. GuyArticle: 37510
Eric Smith wrote: > > Peter Alfke <peter.alfke@xilinx.com> writes: > > Virtex BlockRAMs are initialized to all-zeros by default, but can be > > initialized during configuration to any desired data. That makes them > > usable as ROMs. > > Speaking of which, if you want them initialized to zeros, or perhaps to > don't cares, is there a way to omit the BlockRAM config data from the > config PROM in order to use a smaller PROM? > > If you're using a processor to load the FPGA, it could obviously do some > flavor of decompression, but I'm asking about the "dumb" case. > > Speaking of using processors to load FPGAs, has anyone studied how > compressible FPGA config data is? I'd expect in general to find that > higher the device utilization results in less compressible config data, > but even for high utilization I expect the data may still be fairly > compressible. I had found one year ago a paper on configuration compression: "Configuration compression for the Xilinx XC6200 FPGA", Hauck et al., IEEE Transactions of CAD of ICs, Vol. 18, Issue 8, Aug. 1999. pp. 1107-1113. And last year, while I was dealing with floorplaning of an XCV2000E device, I got personal correspondence with Mr. S. Hauck, one of the authors of the paper above. I think he follows this newsgroup and I lost where he is, probably at a university somewhere Washington D.C.? I remember that time he was interested in Virtex architectures as well. I don't know if he has presented paper on configuration of Virtex devices. > If the config data for repetitive structures in the FPGA don't tend > to be byte-aligned in the config stream, a compression algorithm operating > on bytes may not come close to optimum efficiency. UtkuArticle: 37511
I want to use the CoreGen code to my source hdl,can anyone help me? thanksArticle: 37512
:)) ok :) its the most expensive solution but it seems that it's the only one. "Eric Smith" <eric-no-spam-for-me@brouhaha.com> wrote in message news:qh3d2gytdo.fsf@ruckus.brouhaha.com... > "H.L" <alphaboran@yahoo.com> writes: > > but i have another problem now, > > webpack does not support VirtexE XCV600 (goes up to XCV300). My > > implementation will be on a XCV600 FPGA , is there any way to make WEBPACK > > support the above FPGA? > > Yes. By deinstalling Webpack and installing Foundation ISE 4.1.Article: 37513
Can someone pleas point me to inexpensive datapath schematic editor. I have ton of datapath schematics I have to draw for a report. Thanks.Article: 37514
In article <ee73b05.-1@WebX.sUN8CHnE>, ddale <ddale@163.net> writes >I want to use the CoreGen code to >my source hdl,can anyone help me? >thanks Here's a quick sketch, but I guess you'll have to read the manuals and on-line help to get the full details 1) run coregen to generate the block you want This produces a a) VHDL component template b) a VHDL configuration outline c) a component instantiation template to map the underlying Coregen model to your model d) an edf netlist 2) simulation a) compile the corelib library into a library called corelib b) instance the coregen component and wrapper c) fix up the configuration, either by writing a configuration declaration, or by using a configuration specification. Examples of both are given in the template code d) make sure you add the library and use clause for corelib to your code 3) synthesis a) make sure all the non-synthesisable stuff is surrounded by -- synopsys synthesis_off -- synopsys synthesis_on directives b) synthesise your design. This will create an edif netlist with a "black box" for the component instance 4) fitting a) make sure all the edif netlists are in the same directory b) run ISE or whatever and set the project to load in the top level c) run fitting - if the edif netlists are all in the same directory, the coregen netlist should be automatically plugged in That's an outline. The details can be tricky, but the online help is sort of helpful, Alan -- Alan Fitch DOULOS Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom Tel: +44 1425 471223 Email: alan.fitch@doulos.com Fax: +44 1425 471573 Web: http://www.doulos.com ********************************** ** Developing design know-how ** ********************************** This e-mail and any attachments are confidential and Doulos Ltd. reserves all rights of privilege in respect thereof. It is intended for the use of the addressee only. If you are not the intended recipient please delete it from your system, any use, disclosure, or copying of this document is unauthorised. The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 37515
"Guy-Armand" <gkamendje@iaik.at> writes: > Hi, > When using webpack 3, I was able to create .svf files for CPLD devices. But > now when selecting the "Generate Programming File" and entering the IMPACT > window, I can choose between Boundary Scan, Slave Serial and Select Map. I > have all these options but all the same the .svf file that is created is not > the same as the one created by previous version of Webpack. The current file > is only 553kb instead of 867kb. (I have no cable connected to my computer). > Please could someone help me choosing the right options for creating a .svf > file for xc9500 device programming? I am using a parrallel cable to download > the .svf files to the board. > Thanks for any hint. Are the command line tools accessible in webpack 3? If so try to use the command line tools. jtagprog -svf -batch yourfile.cmd And yourfile.cmd contains something like this (top level design name is pld, there is only one part in the scan chain): part XC95144XL:pld program -v pld quit Petter -- ________________________________________________________________________ Petter Gustad 8'h2B | (~8'h2B) - Hamlet in Verilog http://gustad.comArticle: 37516
Guys, I have a question about choosing FPGA board. In an application we have several (>4) models that run in parallel. Each of these models would run in an FPGA (Xilinx Virtex, Virtex E or VII are prefered). Each can be configured by host indepently, and it can communicate with host machine on the fly (DMA communication is prefered). The host machine is Pentium PC with only three PCI slots. In these case we assume there would be two possible choices: One is to use several FPGA PCI cards, each has one FPGA onboard; Another one is to choose one FPGA board that has several FPGA chips. On-board RAM banks are mandatory, and they should be able to be accessed by both the host manchine and FPGAs. Does anybody know any card that can meet the requirements? Thanks a lot in advance. Jianyong ---------- jyniu@acse.shef.ac.uk University of SheffieldArticle: 37517
Check out www.dalanco.com/avr32.htm to see if it will meet your needs. BTW, it can accomodate several sizes of FPGAs. 50K and 400K gates are the standard sizes. Thanks, David Langmann sales@dalanco.com JianYong Niu wrote in message <9va572$9i5$1@hermes.shef.ac.uk>... >Guys, > >I have a question about choosing FPGA board. > >In an application we have several (>4) models that run in parallel. Each of >these models would run in an FPGA (Xilinx Virtex, Virtex E or VII are >prefered). Each can be configured by host indepently, and it can communicate >with host machine on the fly (DMA communication is prefered). The host >machine is Pentium PC with only three PCI slots. > >In these case we assume there would be two possible choices: One is to use >several FPGA PCI cards, each has one FPGA onboard; Another one is to choose >one FPGA board that has several FPGA chips. On-board RAM banks are >mandatory, and they should be able to be accessed by both the host manchine >and FPGAs. > >Does anybody know any card that can meet the requirements? > >Thanks a lot in advance. > >Jianyong >---------- >jyniu@acse.shef.ac.uk >University of Sheffield > >Article: 37519
Hello, Can someone direct me to a good introduction to FPGAs? I was thinking of possibly a printed article with sufficient detail to describe-- in fundamental terms-- how FPGAs work, yet not too technical. Along the lines of what Scientific American Magazine might print. I am not an FPGA designer, nor am I an engineer. I am a science journalist preparing an article about FPGAs for the general public. Thank you, Jason Langkamer-Smith jasonls@msn.comArticle: 37520
Hi Austin About a year ago we had to design an evaluation platform using Virtex-E to source 624Mb/s 28-bit parallel data (2 14-bit buses) to drive our high-speed dual DAC. This was a lot of grief and effort, and had problems with skew on the data bus in spite of using a customised Xilinx-supplied parallel LVDS macro. One necessary feature to remove I/O and track/cable delays (since the DAC had to be the clock master for jitter reasons) was that we took the 312MHz clock out from the DAC as the DLL input clock, then sourced a 312MHz clock from the Virtex (DDR clock synchronised to the data) and looped it into the DAC and back out to the Virtex as the PLL reference clock, so the DLL took out the delays. Will this be possible on the Xilinx LVDS demo board, and when will the board be available? I'm asking this because I know at least one customer is using an Altera Mercury board (also not released yet?) to source data, because there wasn't anything similar available from Xilinx. Does the board use SMA connectors (so we could connect it directly)? Is there any possiblility of a board with wider LVDS output (eg, 32 bit) being made available in the future? Ian Dedic Chief Engineer Mixed Signal Division Advanced Communications Group Fujitsu Microelectronics Austin Lesea <austin.lesea@xilinx.com> wrote in message news:<3C0EC75E.93DEAF72@xilinx.com>... > Brian, > > See below. > > Austin > > Brian Davis wrote: > > > Could you at least confirm or deny the existence, if not > > the customer availability, of the "16 bit LVDS demo board" > > mentioned in the VHDL source files for XAPP-265 ? > > It exists now, and it is being "finished." Marketing Apps will get > really mad at me if I say anything more. And, with good reason, as they > have to bless the pcb, the documentation, and the rest before they go > live with it. > > > > > snippet from top16.vhd: > > -- Top level design for 16 bit Xilinx LVDS demo board version 1 > > > > thanks, > > Brian > > We recognize now that we did not have the all of the necessary > collateral pcb's ready like we did at the launch of Virtex for Virtex > II. > > There are at least 12 pcbs that can be built for any product release, > and we will do a better job in the future.Article: 37521
On Tue, 11 Dec 2001 15:46:13 -0800, Robert Abiad <abiad@ssl.berkeley.deletethis.edu> wrote: >Hi, > >I've recently run into the problem of getting crosstalk onto a clock >input due to a layout problem. I know what to do to fix the layout >problem (thanks to "High Speed Digital Design"), but I'm wondering how >other people deal with crosstalk in their FPGAs. > >Here's my situation: > >I have several serial inputs to my FPGA. What I had been doing was use >the serial clock to clock in the data, then with my master clock, shift >this data into a shift register (this way, I get the data on the proper >clock edge, but use the global clock to guarantee shift register >function). The problem with this is that a glitch on the serial clock >screws everything up. Presumably reducing the crosstalk will eliminate >the glitch, but do those out there also design your serial inputs to >reduce glitch clocking? A way to do this is to require that the serial >clock be at a level for at least 2 master clock edges in order to be >valid (faster master clock). Or is the right approach to just eliminate >the glitching? and >I should have been more clear. I will certainly do what I can to >eliminate the crosstalk (I'm confident I know what is causing it). My >question is whether changing the layout is enough to inspire confidence. > From Philip's response (which looks like a solution), it sounds like >he never trusts that his clocks will be glitch free (is that fair >Philip?). No this is not the case! I always trust my clocks to be glitch free, and do system level design to make sure this is true. Without good quality clocks, everything else is pointless. >In general, do you always design so that external signals do not >directly feed flip-flop clocks (provided that the timing allows this)? The issue comes down to whether the signals are synchronous to a clock or not. If the signal is asynchronous, then a synchronizer is required (as is the case for you in this application). If the signals are synchronous to the clock, then the issue is whether setup and hold times can be met. if they can, then almost always, i bring my signals in through an input flipflop in the IOB. If setup/hold cant be met, then the signal is treated as an asynchronous signal, and a synchronizer must be designed. Obviously at least 1 signal must be feeding the clock pins of the flipflops, or the wouldn't work :-) . I certainly try to minimize how many clocks there are in my design, and stive for just 1. The Xilinx FPGAs all have a CE input that is the intended way of controlling when a flipflop actuall is clocked. So typically, the fastest clock in the system goes to all the flipflops, and things that are to be clocked slower are paced by the CE signals. >I've gotten away with driving FFs with all sorts of external signals >before, but I've only recently been using parts that have edges fast >enough to cause serious crosstalk and fast enough to respond to the >resulting glitches. and >Philip, > >1) 1,2,5 MHz - take your pick. (serial clock freq) > >2) 40 MHz (Master clock freq) > >3) Asynchronous (clock relationship) > >I also have a parallel interface that is clock triggered at 8 MHz and >another at 20 MHz. > >Some interfaces are input, some output, and some bidirectional. So first on the issue of crosstalk on clocks, it is really important that clocks be clean signals. In particular, no glitches, and no nasty signal integrity problems that cause the rising or falling edges to be non-monotonic. One of the most common problems I have seen is poorly routed and/or terminated clocks. The result can be that during the rising edge, the signal either has a plateau, or even a U turn, and then continues to its final value. The U turn can be around the threshold of the receiver, and it ends up seeing the rising edge as two rising edges. Another nasty case is the plateau or U turn occuring during the falling edge. Often a less experienced designer does not look at this falling edge, because all the flipflops are clocked on the rising edge. Unfortunately a U turn during the falling edge looks like a rising edge to the flipflop, and the flop unexpectedly is clocked on the "falling edge". When looking at clock signal integrity, you need at least a 500MHz scope, and really good probing techniques, such as very short ground connections (less than 2 cm) and probing right on the clock pin of the receiving chip. Moving on, you write: >I have several serial inputs to my FPGA. What I had been doing was use >the serial clock to clock in the data, then with my master clock, shift >this data into a shift register (this way, I get the data on the proper >clock edge, but use the global clock to guarantee shift register >function). The problem with this is that a glitch on the serial clock >screws everything up. Presumably reducing the crosstalk will eliminate >the glitch, but do those out there also design your serial inputs to >reduce glitch clocking? A way to do this is to require that the serial >clock be at a level for at least 2 master clock edges in order to be >valid (faster master clock). Or is the right approach to just eliminate >the glitching? As the number of high quality clock nets in an FPGA is limited, your approach of taking the serial input clock and data and synchronizing them to the faster master clock is a good approach. First, you are right that you need to clean up the serial clock arriving at the chip, but your problems may be more than crosstalk. They may also be termination related, as I described above. In your third article you wrote that the serial clock is >1) 1,2,5 MHz - take your pick. and your master clock is >2) 40 MHz so although the clocks are asynchronous, you will get about 4 cycles of your master clock while the serial clock is high, and the same when it is low, if the serial clock is running at 5MHz. Even more cycles if the serial clock is running slower. But even if the serial clock is perfect, you will still have problems that may look like you are getting glitches, because the synchronizer running at 40MHz may go metastable. What you need to do is reduce the probability of this happening to an extremely low probability. You can do this with a multi stage synchronizer, for example a 3 stage shift register. Something like this: 3 bit shift register, D input is you serial clock, shift register clock is 40MHz. Take the shift register output, and when it is 111, synchronously set a flip flop. when it is 000, synchronously reset the flip flop. This is your new synchronized serial clock. Do the same thing to your data. Call this synchronized serial data. Now there is an issue of what the actual data valid before rising edge of the serial clock is. If it is half a cycle of the serial clock period (100ns for the 5 MHz case), then all is easy. If on the other hand, the serial data changes 25ns prior to the serial clock rising, there is a race condition between the two synchronizers. In this case you may want to use the falling edge of the synchronized clock for taking the data. Now the actual serial shifter itself is NOT clocked by the synchronized clock. Rather it is clocked by the 40MHz clock, but only enabled to shift for 1 cycle after the edge you choose to use from the synchronous version of the serial clock. This 1 cycle enable can be generated instead of the synchronous version of the serial clock in exactly the way I suggested in the articles I wrote earlier this month with a title of "Crossing a clock domain" I hope this is enough to get you to a clean solution. Philip Freidin Philip Freidin FliptronicsArticle: 37522
"Petter Gustad" <newsmailcomp1@gustad.com> wrote in message news:m3bsh3bcmp.fsf@scimul.dolphinics.no... > "Guy-Armand" <gkamendje@iaik.at> writes: > > > Hi, > > When using webpack 3, I was able to create .svf files for CPLD devices. But > > now when selecting the "Generate Programming File" and entering the IMPACT > > window, I can choose between Boundary Scan, Slave Serial and Select Map. I > > have all these options but all the same the .svf file that is created is not > > the same as the one created by previous version of Webpack. The current file > > is only 553kb instead of 867kb. (I have no cable connected to my computer). > > Please could someone help me choosing the right options for creating a .svf > > file for xc9500 device programming? I am using a parrallel cable to download > > the .svf files to the board. > > Thanks for any hint. > > Are the command line tools accessible in webpack 3? If so try to use > the command line tools. > > jtagprog -svf -batch yourfile.cmd > > And yourfile.cmd contains something like this (top level design name > is pld, there is only one part in the scan chain): > > part XC95144XL:pld > program -v pld > quit Unfortunately the command line tools are not accessible in webpack 4.1 (I am using 4.1 and not 4.2 as I wrote early). GuyArticle: 37523
Actually you are right if one is using software older than ise4.1. 4.1 has greatly reduced the hassle. now you need the library declaration -- synopsys translate_off Library XilinxCoreLib; -- synopsys translate_on and then declare the component and instantiate as normal. when you create the core a .xoc file will be added to your project and a .vho file will show the appropriate declaration and instantiation code. just cut and paste the appropriate stuff. It is much easier that the old approach. Theron Hicks Alan Fitch wrote: > In article <ee73b05.-1@WebX.sUN8CHnE>, ddale <ddale@163.net> writes > >I want to use the CoreGen code to > >my source hdl,can anyone help me? > >thanks > > Here's a quick sketch, but I guess you'll have to read the manuals and > on-line help to get the full details > > 1) run coregen to generate the block you want > > This produces a > > a) VHDL component template > b) a VHDL configuration outline > c) a component instantiation template to map the underlying Coregen > model to your model > d) an edf netlist > > 2) simulation > a) compile the corelib library into a library called corelib > b) instance the coregen component and wrapper > c) fix up the configuration, either by writing a configuration > declaration, or by using a configuration specification. Examples of both > are given in the template code > d) make sure you add the library and use clause for corelib to your > code > > 3) synthesis > a) make sure all the non-synthesisable stuff is surrounded by > > -- synopsys synthesis_off > -- synopsys synthesis_on > > directives > > b) synthesise your design. This will create an edif netlist with a > "black box" for the component instance > > 4) fitting > a) make sure all the edif netlists are in the same directory > b) run ISE or whatever and set the project to load in the top level > c) run fitting - if the edif netlists are all in the same directory, > the coregen netlist should be automatically plugged in > > That's an outline. The details can be tricky, but the online help is > sort of helpful, > > Alan > -- > Alan Fitch > DOULOS Ltd. > Church Hatch, 22 Market Place, Ringwood, Hampshire BH24 1AW, United Kingdom > Tel: +44 1425 471223 Email: alan.fitch@doulos.com > Fax: +44 1425 471573 Web: http://www.doulos.com > > ********************************** > ** Developing design know-how ** > ********************************** > > This e-mail and any attachments are confidential and Doulos Ltd. reserves > all rights of privilege in respect thereof. It is intended for the use of > the addressee only. If you are not the intended recipient please delete it > from your system, any use, disclosure, or copying of this document is > unauthorised. The contents of this message may contain personal views which > are not the views of Doulos Ltd., unless specifically stated.Article: 37524
I have an application where I want to run a Spartan 2 DLL from a 24.576 Mhz reference. I know the databook says 25 Mhz minimum. I recall seeing some threads here where someone was running one on the bench at like 13 Mhz - apparently there is a good sized guard band built into that spec. I couldn't find any xilinx info on derating this spec based on temperature, etc. from the xilinx web site. How risky would it be to go to production with a design only this far over to the limit? Would someone from xilinx like to comment? -Jeff
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