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
Madhura <madhura@controlnet.co.in> wrote: > The design is being targetted to VirtexE family. For the gate level simulation, I require VHDL netlist. If I generate that through dc_shell, the INIT generic for the LUT's are not being associated with the LUT's. So it gives warning during the compilation. So the netlist has to be given to FC2 to have these INIT parameters. Now those parameters are associated with the LUT's. But now the warning is given for the RAM's..RAMB4_S*.. The xnf files for these can not be opened for analyze. > can u suggest some solution for this? Hi, you must use the "--synopsys dc_script_begin/end" and "--set_attribute" to generate INIT and RLOC in *.sedif from *.vhd. The "attribute INIT of xyz: label is "ABC";" never work again in dc_shell ---- BrittleArticle: 36751
We have a product under development that will suit. Contact me for more details. John Adair Enterpoint Ltd. Unit 4 Malvern Hills Science Park Geraldine Road Malvern Worcestershire United Kingdom www.enterpoint.co.uk The views expressed in this message are those of the writer and not necessarily those of Enterpoint Ltd.. The use of information in this message is without warranty and persons using the information are advised to make their own checks as to it's validity. No responsibility will be accepted for any incorrect, inaccurate or missleading information supplied. John Jakson <johnjakson@earthlink.net> wrote in message news:38111bbc.0111161334.5a8349bf@posting.google.com... > "Maf" <maf.gg@wanadoo.fr> wrote in message news:<9t010h$1gu$1@wanadoo.fr>... > > Check out www.datacube.com for their MaxRevolution product. > > > > > > David Eadie <david.eadie@cs.tcd.ie> a écrit dans le message : > > a0ce2abd.0111140648.1f92ae6b@posting.google.com... > > > Hi, > > > > > > I'm interested in exploring the image processing potential of using > > > FPGAs within high-speed video cameras. Initially I would like to get > > > an FPGA prototyping/development/evaluation kit working within the PC > > > itself. > > > > > > Features I would like: > > > > > > -PCI-card-based, to allow easy I/O to/from PC memory. > > > -on-card memory to store image data and results. At least 8 MB, > > > preferably more. > > > -Virtex II device (2 million gates, or more). > > > -Some FPGA I/O pins accessible through a header/connector on the > > > PCI-card. > > > > > > Does anyone know if such a card, or similar, exists? > > > Are there any other important features I should look for? > > > > > > Thanks > > > > > > David Eadie, > > > Computer Vision and Robotics Research Group, > > > Dept. of Computer Science, > > > Trinity College Dublin. > > Datacube looks like an interesting solution to video, never heard of > them before. Also right across the Irish sea in Glasgow is Nallatech, > they have a range of high end boards with many PCI fpga video apps off > the shelf. Nots so far away is Alpha Data with similar products in > Edinburgh. Also Sundance in Chesham. There are a couple of other > companies in UK, Germany as well. Search google for "pci fpga boards". > > Also try http://www.optimagic.com/ > & XIlinx 3rd party PCI board lists. > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=protoboards_protobo ards_page > > Regards > > John JaksonArticle: 36752
Burch Electronic Designs announces the new B5-SPARTAN2+ board. A low cost, high performance, easy-to-use board, for prototyping and education. Introductory price: US$149, available now http://www.burched.com.au/bedspartan2.html Features: * 200,000 gates (XC2S200 device) * Works with the free Xilinx WebPACK (tm) software * Header programmable PLL oscillator - select any frequency between 1 - 100MHz * JTAG and serial mode configuration download pod cable, with schmitt buffering * Pod has "lock configuration" switch - your FPGA will not "de-configure" by accident * Array of high and mid frequency decoupling capacitors on underside of board * Multilayer board * Test LED and pushbutton switch * Uses a Plug-On Module concept for system expansion * Low cost * Easy to use * Great for education, or some serious prototyping ! * Ideal for University and Technical College FPGA design courses In stock now. Order form available. 10-pack deals for volume purchases. International orders are very welcome. Best regards Tony Burch http://www.BurchED.com Low cost FPGA boards, for seriously powerful prototyping and education !Article: 36753
It's a common misconception that smaller value decouplers are "better" at high frequencies, in fact it's the inductance that matters. This is indirectly linked to value by physical size, but if you compare 100nF and 10nF in 0805 packages they have the same inductance (HF decoupling performance), and the 100nF will be 10x better at lower frequencies. Yes the self-resonant frequency will be lower, but once inductance takes over the impedance (which is what matters) is the same. It all depends over what frequency range you want to keep the supply impedance low; if you need a wide range things get difficult. And the more different capacitor sizes and values you use, the more the chance of getting nasty resonances between the inductance of one and the capacitance of another. In RF and microwave they don't care about performance below 100's of MHz, so the smallest value capacitor will perform just as well as a larger one and may be better because it's available in a smaller case size. With high-speed digital circuits the lower frequency of the noise can be kHz depending on what processing is going on (for example, at the frame rate in some systems). Adding a small number of lower-value capacitors has little effect, because the most important factor is the total equivalent series inductance. Inter-plane capacitance has negligible inductance, but also pretty small capacitace -- fine at RF frequencies, but less useful in the 10's to 100's of MHz region. We work on design of (among other things) high-speed CMOS DACs, and have to get low supply impedance over a frequency range of kHz to GHz. In the region from a few MHz upwards, the best approach is a large number of physically small high-value surface-mount ceramics (eg. 0805 or smaller, 1uF or greater) which provide charge for both high-speed edges and lower frequencies without any resonances. Plus of course a large value low ESR elctrolytic (eg. 330uF OSCON) to provide the charge below a few MHz. Ian Dedic Chief Engineer Mixed Signal Division Fujitsu Microelectronics Europe "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<9sh63h$1249vl$1@ID-84877.news.dfncis.de>... > "Philippe Robert" <PhilippeR@sundance.com> schrieb im Newsbeitrag > news:3bebb7ef$1@peer1.news.newnet.co.uk... > > Hi there, > > > > I found an application note on the Xilinx website (xapp158) about > decoupling > > capacitors. It is explained that high frequency and mid-frequency > capacitors > > are required. > > > > For the high frequency capacitor, I will use 100nF. It says in that app to > > fit 1 100nF cap per Vcc. (I have counted as Vcc pins Vccio, Vccaux and > > 100nF isnt that good at HIGH frequencys. Remember, the higher the > capacitance, the higher the (parasitic) inductance of a cap. > And since the Virtex-II are damm fast devices, I would use 10nF caps. Not > 10x10nF, but lets say at least 4 10nF caps to decouple the core. Also > remember, the higher the value of a decoupling cap, you can place them more > far away from the VCC pins. Usually, you have a cascade of caps, 10nF, > 100nF, 10uF 1000uF. > > > Vccint pins). I end up with 64 cpas for a XC2V1000-FG456 !! > > Hmm, try redestributiing the capacitance into less caps, but dont forget to > use small ones (10nF or lower) for the "really" high frequencys. In > microwave engineering they use sometimes even 100pF instead of 1nF because > of the lower inductance. > And dont forget a good ground-VCC planes. In your layer stacking, the > GND-VCC planes should be close together, forming a superb high frequncy > capacitor.Article: 36754
Ian, You are a man after my own heart. You seem to actually understand what is going on rather than just having learned a few "rules of thumb". So many people who design power distibution never actually read the capacitor data sheets and have no true understanding of how they work at high frequencies. I agree 100% with everything you said, expecially the part about using a single large value, low ESR device on the board. I have read several people here say that you need multiple tantalums per chip which is nonsense. The only reason (that I know) of placing caps near the load is to minimize the effects of inductance in the power distibution. But since the large, bulk caps have very high inductance relative to the power distribution, there is no need to keep them close to the load. So you can use one large device anywhere on the board. Another point that often escapes designers is that it does not matter if your noise frequecies are above the self resonant point of the cap. At those frequencies the cap is actually an inductor. But as long as the impedance is low, it still acts to decouple the noise. So for high freqs, the only relevant factor is the total impedance to ground. By keeping this impedance low at the frequencies of the noise, you will get good decoupling and a quiet power plane. So lots of MLCC caps are good and more are better. As you say, the value is not so important, moreso the physical size. Ceramic 100 nF, 0603 caps work great and don't clutter up the board with bulk. Ian Dedic wrote: > > It's a common misconception that smaller value decouplers are "better" > at high frequencies, in fact it's the inductance that matters. This is > indirectly linked to value by physical size, but if you compare 100nF > and 10nF in 0805 packages they have the same inductance (HF decoupling > performance), and the 100nF will be 10x better at lower frequencies. > > Yes the self-resonant frequency will be lower, but once inductance > takes over the impedance (which is what matters) is the same. It all > depends over what frequency range you want to keep the supply > impedance low; if you need a wide range things get difficult. And the > more different capacitor sizes and values you use, the more the chance > of getting nasty resonances between the inductance of one and the > capacitance of another. > > In RF and microwave they don't care about performance below 100's of > MHz, so the smallest value capacitor will perform just as well as a > larger one and may be better because it's available in a smaller case > size. With high-speed digital circuits the lower frequency of the > noise can be kHz depending on what processing is going on (for > example, at the frame rate in some systems). > > Adding a small number of lower-value capacitors has little effect, > because the most important factor is the total equivalent series > inductance. Inter-plane capacitance has negligible inductance, but > also pretty small capacitace -- fine at RF frequencies, but less > useful in the 10's to 100's of MHz region. > > We work on design of (among other things) high-speed CMOS DACs, and > have to get low supply impedance over a frequency range of kHz to GHz. > In the region from a few MHz upwards, the best approach is a large > number of physically small high-value surface-mount ceramics (eg. 0805 > or smaller, 1uF or greater) which provide charge for both high-speed > edges and lower frequencies without any resonances. Plus of course a > large value low ESR elctrolytic (eg. 330uF OSCON) to provide the > charge below a few MHz. > > Ian Dedic > > Chief Engineer > Mixed Signal Division > Fujitsu Microelectronics Europe -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 36755
Peter Alfke wrote: > > Lasse Langwadt Christensen wrote: > > > The DLL can correct the duty cycle, so it's a nice 50-50 for the uneven > > dividers, it can also be used to divide a clock or multiply it by two > > > > So I guess you could take a 54MHz use two DLLs to get it to 216MHz and > > then divide that to get all you other frequencies > > > > > > That statment is true for Virtex and Spartan-II. > In the newer Virtex-II the DLL can do more, > it can also, on its frequency synthesis output, > provide any frequency that is M/D time the input frequency. > > M is the multiplier and can be any integer up to 32, > D is the divider and can also be any integer up to 32. > So you can multiply and divide simultaneously. > > You can drive the DLL with 90 MHz, pick M=31 and D=9, and get 310 MHz out. ( > just to illustrate that the output is valid although the multiplication > itself seems to create an excessively high frequency) > And the Virtex-II Digital Clock Manager also has fine-grain phase > adjustment. Clever circuit! > > Peter Alfke Are the DCM on the Virtex II chips fully functional? I have heard through the grapevine that there are problems. I have not heard anything specific, just that I should check with Xilinx before planning to use the DCM. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 36756
This is a very significant issue. I know that Altera boasts of this feature with several of their products. Not only are they pin compatible in the same package, but you can design for a larger FG package and use a smaller one as a subset. So you can build your boards with a wide range of chips which will fit the socket. But if pins are swapped between the different pinouts, it makes it MUCH harder to keep up with the design changes as you use different chips. Is this a problem with other Xilinx families as well? Jonas Weiss wrote: > > I'm working on a design using either two XC2V1000 (FG456 package) or > XC2V3000 (FG676 package). As the board is part of a prototype system we > wanted to start with the small devices and if necessary up grade to the > 3000s later. First we discovered that roughly half of the LVDS channels > can not be used because the differential pairs on one package do not > correspond to the pairs on the other package (what an inconvenience). > Running a place and route yielded that of the pins I thought would > match, there are still pairs with inversed polarity between the > packages...which was confirmed by a look at the data sheet. :-( > Namely: > 3000 1000 > > M22->N K20->P > M21->P K19->N > > N21->P L19->N > N22->N L20->P > > L21->P J19->N > L22->N J20->P > > I remember having seen a nice Xilinx brochure with a transparent print > of one package which fits perfectly over the drawing of the next bigger > package...how misleading. > > If anybody knows of any other hidden obstacles I might struggle over, > any comments will be appreciated very much. > > Thanks > > Jonas -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 36757
Hi, Synplicity´s SynplifyPro does allow you to limit the fan-out by using the "syn_maxfan" attribute. The attribute can be applied to either the complete device (which doesn´t make a lot of sense because you would limit the fan-out for all of the flops) or specific sequential elements which are critical in timing. You could add the attribute to your VHDL or Verilog sources or take advantage of the "drag and drop" capability provided by SynplifyPro. When using this possibility you could "drag and drop" specific registers from SynplifyPro´s graphical editor to the SCOPE constraint editor.Article: 36758
Microfarads = uF .... Will go fix it. There are some shareware programs for evaluating bypass caps. (For those without spice, but hey, Berkeley Spice is free ....). I'll see if I can find the reference... Austin Rick Filipkiewicz wrote: > Austin Lesea wrote: > > > More to consider than just bypassing.... > > > > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=si_pcbcheck > > > > Austin > > > > Nice checklist although the "simulation" rqeuirements presuppose access to a SPICE > engine. Is there a freeware/opensource/public-domain implemetation ? > > Only one quibble on TI (= TextIntegrity): Are you really recommending milliFarad > (e.g. 4.7mF) caps ? Perhaps its a misprint for 4.7MF :-).Article: 36759
Hello, Thanks for your reply. But can you just elaborate the solution. I will tell you my problem in more detail. I am generating the vhdl netlist for gate level simulation from dc_shell. The target library is VirtexE2000-6. But in the vhdl netlist the combinational logic is being inferred by LUT's but the INIT attributes are not associated with them. So the LUT's don't get initilised and the output of the combinational logic is not proper. Can you elaborate on the solution which you are suggesting? Do I need to set the attributes in the vhdl RTL or I have to set them during dc_shell flow? Thanks in advance. MadhuraArticle: 36760
Madhura <madhura@controlnet.co.in> wrote: > Hello, > Thanks for your reply. But can you just elaborate the solution. I will tell you my problem in more detail. > I am generating the vhdl netlist for gate level simulation from dc_shell. The target library is VirtexE2000-6. But in the vhdl netlist the combinational logic is being inferred by LUT's but the INIT attributes are not associated with them. So the LUT's don't get initilised and the output of the combinational logic is not proper. > Can you elaborate on the solution which you are suggesting? > Do I need to set the attributes in the vhdl RTL or I have to set them during dc_shell flow? > Thanks in advance. > Madhura Hi, I am not sure if this is what you want: <---test.vhd begin---> architecture syn of test is ... --synopsys dc_script_begin --set_attribute MY_LUT INIT "CACA" -type string --synopsys dc_script_end ... begin ... MY_LUT: LUT4 --synopsys translate_off generic map (INIT => X"CACA") --synopsys translate_on port map (...) ... end syn; <---test.vhd end---> <---test.sedif begin---> ... (instance MY_LUT (viewRef Netlist_representation (cellRef LUT4 (libraryRef xdc_virtexe_6)) ) (property INIT (string "CACA"))) ) ... <---test.sedif end---> ---- BrittleArticle: 36761
Hello all.
With our ISE tools, we got Modelsim Xilinx edition, but no license.
We installed the free version, it runs fine, also with the Xilinx
components.
My question: what is the difference (what are the nags) between the three
Modelsim versions on the cd:
- full version
- evaluation version
- free version
thanx
cheers,
Seb
Article: 36762Hi Does anyone know where I can get hold of a full-version licence for Modelsim? I only need it for 2 or 3 days. Is there any alternative VHDL simulator like modelsim that is freely available? Thanks AndrewArticle: 36763
Hi. I have seen that the period jitter of DLL of virtex-II device is 150 ps. Can I have any figures about it's cycle-to-cycle jitter ? ThanKXArticle: 36764
Nurit, From any cycle, to the next cycle, the period out of the Virtex II DCM (using the DLL feature) can not change by more than a tap value, plus whatever input jitter may also be present. For Virtex II that is ~ 55ps. The period jitter is measured by accumulating a histogram of > 200,000 periods, and fitting a gaussian curve (left and right tail fitting) to get the peak to peak value. Spectral analysis of the histogram shows that the jitter is random, and has no deterministic component. Thus the input jitter going into the DLL may be added to the internal jitter quadratically to get the output jitter. Clock forwarded interfaces have larger margin as a result, as the cycle to cycle jitter is important as to the sampling of input data by the IOB's. Worst case, the input data sampling instant error is not the peak to peak value, but the cycle to cycle value. This behavior is completely different than than of a PLL, where the PLL usually provides some filtering of high frequency jitter components, and where there is no fixed relationship from an input clock to an output clock as there is in the DLL (PLL cycle to cycle jitter is bounded only by the peak to peak jitter, whereas the DLL cycle to cycle jitter is bounded the delay line tap change). Austin nurit eliram wrote: > Hi. > I have seen that the period jitter of DLL of virtex-II device is 150 ps. > > Can I have any figures about it's cycle-to-cycle jitter ? > > ThanKXArticle: 36765
Russell Shaw wrote: > I traced from the clock input pin to the clock divider, and looked at > the fanout from the last flip-flop. I found there were a few counters > implemented as scattered logic, not being recognized as counter > templates. I found just one or two extra lines in a process can prevent > recognition by the compiler as a counter. I noticed that about Leonardo -- it's VERY picky about what it considers a counter. What's bizarre is that I ran Leonardo on two different machines (one a Sparc running Solaris 7, the other running Solaris 2.5) and I got different results (the 2.5 machine did the right thing for a counter; the S7 machine didn't!) for identical code with identical scripts. I haven't gotten to the bottom of that one yet. Moral: pay attention to the report and log files. -aArticle: 36766
The best comment in this thread so far IMHO. Thanks, Rick. Smaller valued caps can give lower impedances at higher frequencies but if one looks at the datasheets from Kemet or AVX or Vishay, you'll find that lower capacitance values don't necessarily give you (much) better high frequency impedence. A good look at the Z vs F curves will shed some light on how good a cap can be at high frequencies. And just as the bulk, low ESR tantalum caps go, higher value (1uF for instance) capacitors may not have a good enough impedance near 1GHz to deal with those <1nS switching transients. The impedance versus frequency information is sometimes tough to find but it's out there. The LICA array from AVX is one example where the attempt to provide best-of-class high frequency performance is made; the practicality might be limited, though. rickman wrote: > Another point that often escapes designers is that it does not matter if > your noise frequecies are above the self resonant point of the cap. At > those frequencies the cap is actually an inductor. But as long as the > impedance is low, it still acts to decouple the noise. So for high > freqs, the only relevant factor is the total impedance to ground. By > keeping this impedance low at the frequencies of the noise, you will get > good decoupling and a quiet power plane. So lots of MLCC caps are good > and more are better. As you say, the value is not so important, moreso > the physical size. Ceramic 100 nF, 0603 caps work great and don't > clutter up the board with bulk.Article: 36767
khtsoi@cse.cuhk.edu.hk wrote: > > Hi, > > Someone told me that tools from Synplicity is better than the Synopsys > Xilinx combination in FPGA place and route process. Neither Synplify nor Synopsys do place-and-route for Xilinx. > I am sick with the > bad routing design in Alliance3.1i. Also, it takes me more than 1 day > to par a design using only 45% slices of a XCV1000E (on a Sun E4500). Perhaps it's a design issue? -aArticle: 36768
Kris Nichols wrote: > > Brian, > > It turns out that when implementing my design in Xilinx environment, the XST > synthesizer would attempt to reduce logic for optimization purposes. The > synthesizer thought that some of my pins were never used, and indirectly > removed all logic related to my 'input_value' port (without explicitly > stating it had done this). The SDF file produced by Xilinx wouldn't have > any reference to the 'input_value' port pins, so a 'timing' simulation in > ModelSIM would think that this port doesn't exist. So is it safe to say > that the following messages indicate which pins are not implemented: > WARNING : (HDL__0002). Input <name_of_pin> is never used. > WARNING : (HDL__0005). Signal <name_of_pin> is assigned but never used. > Is there any way (workarounds, etc.) I can use prevent the XST synthesizer > from doing this? Thanks. If the synth tool tells me that it's optimized a net away (esp. pins) that I feel I'll need later, I simply AND all of these "unused" inputs together, and drive the AND out an unused pin. Quick and dirty but it works. -aArticle: 36769
Lasse Langwadt Christensen wrote: > -Lasse > -- Lasse Langwadt Christensen, > -- A Dane in Phoenix, Arizona Wow...summer must've been, um, "interesting" for ya! -andy -- A Jersey boy in Tucson, ArizonaArticle: 36770
If it is taking more than a day to PAR >50% of the slices in an XCV1000E,
you are probably setting the timing constraints too aggressively for your
design (or looking at it the way I would, your design is not a good
implementation for the clock constraints you are using). At that kind of
turn around time, it is highly unlikely that you are doing any floorplanning
either.
Worst case PAR times I'm currently seeing on 92% full 2000E's being clocked
at 160 MHz is on the order of about 2.5 hrs, granted they are floorplanned.
Andy Peters wrote:
> khtsoi@cse.cuhk.edu.hk wrote:
> >
> > Hi,
> >
> > Someone told me that tools from Synplicity is better than the Synopsys
> > Xilinx combination in FPGA place and route process.
>
> Neither Synplify nor Synopsys do place-and-route for Xilinx.
>
> > I am sick with the
> > bad routing design in Alliance3.1i. Also, it takes me more than 1 day
> > to par a design using only 45% slices of a XCV1000E (on a Sun E4500).
>
> Perhaps it's a design issue?
>
> -a
--
--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, 1759
Article: 36771
The jitter you are seeing is most likely due to jitter on your input. Note
that even with a very clean input, you can induce jitter if you have lots of
single ended I/O activity on the same bank as your clock input. I've seen a
case where I got almost 400ps jitter, which it turned out was largely due to
outputs switching on the same bank as the clock input. Apparently the delta
currents can shift around the clock input thresholds a little bit.
nurit eliram wrote:
> Hi.
> I have seen that the period jitter of DLL of virtex-II device is 150 ps.
>
> Can I have any figures about it's cycle-to-cycle jitter ?
>
> ThanKX
--
--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, 1759
Article: 36772Assaf Sarfati wrote: > > Hi everyone, > > I am trying to simulate the gate-level VHDL file generated by Xilinx > P&R tools. My test design is a bunch of counters connected to an > inferred distributed-RAM. The target device is a Virtex-2 chip. > > When I simulate the gate-level VHDL by itself, I get timing violation > warnings (sometimes) when writing to the distributed-RAM; watching the > simulator waveforms, it appears that the clock to the RAM has a 100-pS > phase difference to the counters' clock (the clock is routed as a > global clock net). That sounds like one of Xilinx' bad models. I've looked through the Xilinx functional models, and there's all sorts of things like: foo_i <= foo after 1 ps; and such. I've ranted before: there should be NO timing information in a FUNCTIONAL model. Check the archives of comp.lang.vhdl for more on that subject. Summary: the Xilinx people oughta learn how to write proper models. > When I add the gate-level SDF file to the simulation, all the timing > violation warnings disappear (for all cases: min, max and typ). Right, because the post-route delay information is "real." > Trying to trace the generated VHDL code, I see that signals are routed > through buffer entities, with built-in delays; apparently the VHDL > design itself contains all required delays. Again: why does a functional model have timing info? --aArticle: 36773
Does anyone know of software to convert AHDL to VHDL ? CheersArticle: 36774
"Andrew Gray" <andrewgray@iafrica.com> wrote in message news:3bf946c4.0@news1.mweb.co.za... > Hi > > Does anyone know where I can get hold of a full-version licence for > Modelsim? I only need it for 2 or 3 days. You should be able to get an evaluation license for Modelsim for 20-30 days from their site. > > Is there any alternative VHDL simulator like modelsim that is freely > available? As good as Modelsim, for free, not really. > > Thanks > > Andrew A.S.
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