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
The Quartus II (2.0 and higher versions) VHDL synthesis engine expects the file containing the VHDL packages to be present in the Project design file list. If your package is in a .vhd file, you can add it to the design file list by using the Project->Add/Remove Files in Project Dialog. For VHDL procesing the order of files in the design file list is important. Usually packages referred to in other VHDL files need to be placed before the file that refers them ( i.e towards the top of the list). Use the Up, Down buttons in the Add/Remove Files Dialog to place the added file properly in the list. - Subroto Datta Altera Corp. creon100@yahoo.com (Sean) wrote in message news:<b97bab2f.0303240642.3016b717@posting.google.com>... > In my current design I have a small VHDL file that is a package > containing some math functions. However, I can't figure out how to > use this in Quartus-II because it doesn't find the library. I've > tried copying the package file into a folder with a library name in > the main quartus library directory, but that doesn't work. I then > tried specifying that folder in the user libraries settings, but it > still didn't find it. At this point I can't synthesize anything since > it can't find this package, does anyone have any suggestions? Thanks.Article: 53851
Lorenzo Lutti wrote:
>
> When I sintesize it, XST removes all of the array elements:
>
> memoria<15><7> and memoria<15><6> are equivalent: (memoria<15><6>) is
> removed.
Unless you have some other process that affects output
port/pin values based on the data in the array, synthesis will
quite correctly strip it all out.
Consider using VHDL simulation before synthesis.
-- Mike
Article: 53852Synplify (or any synthesis tool) cannot really "synthesize" these constructs. The best way to get them is to instantiate them directly in your Verilog RTL source, exactly as you did in the first example (the instantiation of instances U1, U2, U3,...). Synplify will recognize the instantiation of the BUFG, IBUFG and the CLKDLL, and know that they are not to be touched - they will be left as is when the design is synthesized. What you show here (the xc_clockbuftype) is a directive to get synplify to infer the IBUFG for this signal. If you have the syntax correct it will work. However, there is no need to infer the device, when you can specifically instantiate it. input Clk_in; IBUFG (.I(Clk_in), .O(CLK)); I don't think there is any way to infer a DLL, especially one that uses CLK2X as well as CLK0. You can find a list of the cells that can be directly instantiated in $XILINX/src/verilog/unisims This is XILINX's list of cells in Verilog, complete with the port names. Synplify (and _pro), maintain their own internal database, but the module names and ports are identical to Xilinx's version. Be aware that this directory may contain the descriptions for cells in other architectures (i.e. Virtex-II, Virtex-IIpro) - if you try and instantiate a cell that doesn't exist (like, say, DCM in a Virtex-E), synplify will give you an error. Avrum "tote" <tote_last@yahoo.de> wrote in message news:91e0be86.0303250002.4fc43654@posting.google.com... > Ok, thanks. This helps to understand how to use this DLL. This is > exactly what i need. The second clock buffer to use both clocks (CLKB > and CLK2XB) in my design. And this is all working fine in simulation. > > I want to use this on a VirtexE architecture. My problem is, that i > don't know how to synthesize such XILINX cells like CLKDLL with the > SYNPLIFY PRO synthesizer. > In the documentations i just found things like: > > input Clk_in /* synthesis xc_clockbuftype = "IBUFG" */; > > ok, that's s.th. i can use for the two buffers IBUFG and BUFG. I also > found s. th. similar with the BUFGDLL (IBUFG->CLKDLL->BUFG). However, > that's always working with one input signal name, used as the output > name again. I don't understand how to connect more signals between > such XILINX cells with this method using SYNPLIFY. > SYNPLIFY seems not able to just synthesize these things. Or do i have > to add additional XILINX libraries? Anyway, i also can't find any > option for this. > > I do appriciate your help. > > Thorsten > > > > "Avrum" <avrum@sympatico.ca> wrote in message news:<7mJfa.673$lf3.36793@news20.bellglobal.com>... > > Pretty much exactly like that. > > > > However, from your naming convention, you may be confusing which signal to > > use as the main clock to clock logic. The clock that should be fed to the > > flip-flops is the output of the BUFG, in this case, named CLKB, not the > > signal named Clk - this is a local, dedicated connection from the DLL to the > > BUFG. The BUFG component is the main "clock buffer" - conceptually, it > > drives the load of the clock distribution network. > > > > In addition, you need a second BUFG to drive the flops being driven on the > > CLK2x domain. You would need to add > > > > BUFG U4 (.I(CLK2x), .O(CLK2XB)); > > > > Again, remember, CLK2XB is the clock that should be used to drive flops on > > the 2X domain (not CLK2x). > > > > Also, (I don't have the specs in hand, and you don't say which architecture > > you are using), there may be a requirement as to which clock needs to be > > used for the CLKFB of the DLL when you are using both CLK and CLK2X - you > > may need to use the output of the CLK2X BUFG (which I called CLK2XB). > > > > Avrum > > > > "tote" <tote_last@yahoo.de> wrote in message > > news:91e0be86.0303240810.46e23d89@posting.google.com... > > > Hi, > > > > > > in my design i'm using 2 clock signals, CLK and CLK2x. I'm generating > > > these 2 clocks from a "input-clock" with a DLL like: > > > > > > IBUFG U1 (.I(Clk_in), .O(CLKIN)); > > > CLKDLL U2 (.CLKIN(CLKIN), .CLKFB(CLKB), .RST(~nReset1), > > > .CLK0(Clk), .CLK90(), .CLK180(), .CLK270(), > > > .CLK2X(CLK2x), .CLKDV(), .LOCKED(LOCKED)); > > > BUFG U3 (.I(Clk), .O(CLKB)); > > > > > > That's basically how it's described in the xilinx application notes. > > > Working fine for simulation. > > > However, does anybody know, how to write this to synthesize it with > > > synplify pro? > > > > > > Thanx for your help > > > ThorstenArticle: 53853
Ray Andraka <ray@andraka.com> wrote in message news:<3E7CD5DA.A8DA1854@andraka.com>... > Even in that case it would probably be desirable to at least move away from IEEE > floats inside the co processor, as they are a pain to deal with in hardware. > But you are correct, without knowing the bounds of the problem it is very > difficult to recommend an optimal course of action. > > Glen Herrmannsfeldt wrote: > > > > Glen Herrmannsfeldt wrote: > > > > > > > FFT is usually done in floating point, though that isn't required. We > > > > would need to know more about the real goal to answer the question. If > the > > > > goal is to speed up a program that uses an FFT subroutine then it would > need > > > > to be done in a similar data representation. Both floating point > addition > > > > and multiplication are hard to do fast in FPGA's, and division is even > > > > worse. > > > > > > > > "Ray Andraka" <ray@andraka.com> wrote in message > > > news:3E7BD24E.59887520@andraka.com... > > > That may be true for software implementations of the FFT, but not > necessarily > > > for hardware. Depending on the size of the FFT, floating point may not buy > > > anything. For smaller FFT's it is much more economical to work with > wider > > > fixed point to get the needed dynamic range than it is to do floating > point. > > > For larger FFT's, the FFT is generally accomplished using small FFTs > combined > > > using the mixed radix algorithm. In these cases, it often makes sense to > do the > > > small FFTs in fixed point and then normalize and adjust the exponent > between > > > passes. Often a block floating point scheme is sufficient, in which case > the > > > common part of the exponent is stripped off before denormalizing the data > before > > > each path. That common part of the exponent is then used to scale the > final > > > result. > > > > I agree that for specific cases fixed point, even many more bits than most > > often used in software, would be best. > > > > I was considering the case of a hardware coprocessor, maybe on a PCI card, > > that would accelerate the FFT part of an existing program. A Fortran or C > > callable routine would be written that would replace the normal call, pass > > the data to the hardware, and then return the results. One would expect > > very similar results to the software implementation, and so would likely > > require a similar representation. The OP didn't state the requirement very > > well, so it is hard to know which would be better. > > > > -- glen > > -- > --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 Hi Folks, Good to see a very informative discussion. I am just looking in from the side not really wanting to display my ignorance on the topic. However, I am learning. Another thing I was wondering, is that windows seem to be used when designing ffts with conventional dsps. What about in the asic/fpga arena. There doesn't seem to be a lot of mention about them. Is there a reason, or are they used. Maybe I just haven't noticed. Regards from a very interested spectator. BobArticle: 53854
Hi, It seems duplicate registers are being inferred due to your coding style. Use coregen to instantiate a memory component.Inferring memories puts a heavy load on your synthesiser and run-times increase drastically.When you have the luxury of Coregen,why code for a memory.By the way ,can I know what hardware you have in mind? Regards, SANKET. "Lorenzo Lutti" <lorenzo.lutti@DOHtiscalinet.it> wrote in message news:<b5pa6n$ihf$1@fata.cs.interbusiness.it>... > Look at this VHDL code snippet: > > entity txmem is > Port ( CLKIN : in std_logic; > DATAIN : in std_logic; > ENABLE : in std_logic; > CLK : in std_logic; > SOUT : inout std_logic); > end txmem; > > [...] > architecture Behavioral of txmem is > type mem is array (15 downto 0) of std_logic_vector(7 downto 0); > begin > pippo: process( CLKIN, CLK, ENABLE) > [...] > variable memoria: mem; > variable index_write_word: integer := 0; > variable index_write_bit: integer := 0; > begin > if ENABLE='1' then > if CLKIN'event and CLKIN='1' then > case index_write_bit is > when 7 => > memoria(index_write_word)(index_write_bit) := DATAIN; > index_write_bit := 0; > index_write_word := index_write_word+1; > when others => > memoria(index_write_word)(index_write_bit) := DATAIN; > index_write_bit := index_write_bit+1; > end case; > end if; > else > [...] > > > When I sintesize it, XST removes all of the array elements: > > memoria<15><7> and memoria<15><6> are equivalent: (memoria<15><6>) is > removed. > memoria<15><7> and memoria<15><5> are equivalent: (memoria<15><5>) is > removed. > memoria<15><7> and memoria<15><4> are equivalent: (memoria<15><4>) is > removed. > memoria<15><7> and memoria<15><3> are equivalent: (memoria<15><3>) is > removed. > memoria<15><7> and memoria<15><2> are equivalent: (memoria<15><2>) is > removed. > memoria<15><7> and memoria<15><1> are equivalent: (memoria<15><1>) is > removed. > memoria<15><7> and memoria<15><0> are equivalent: (memoria<15><0>) is > removed. > memoria<15><7> and memoria<14><7> are equivalent: (memoria<14><7>) is > removed. > memoria<15><7> and memoria<14><6> are equivalent: (memoria<14><6>) is > removed. > [...] > > Why? > > Thank you in advance!Article: 53855
Uzytkownik "Spam Hater 7" <spam_hater_7@email.com> napisal w wiadomosci news:e9486eb9.0303250937.468bc0b0@posting.google.com... > Hi, > > Yes, it is possible to configure an FPGA so that it will destroy parts of itself. > > Two or more low-Z drivers on an internal bus is one way. > I have heard that some ring oscillators do even better... ChrisArticle: 53856
Hi, I am running ModelSim SE PLUS 5.6a and ModelSimXE-II V5.6a both on a Windows 2000 machine with the following variables set for an ethernet based license----> Variable name :LM_LICENSE_FILE Variable Value:C:\Modeltech_xe\win32xoem\license.dat;C:\MtFlexlm\bin\license.dat This works for sure. Regards, SANKET. kenm@morro.co.uk (Ken Morrow) wrote in message news:<20f8de50.0303231355.40cf7aef@posting.google.com>... > I am currently using ModelSim 5.6e PE on a PC licensed from a dongle. > > Unfortunately, this will only allow one instance of ModelSim to simulate > at a time. This is currently proving a problem as I am running some big sims. > I cannot do any other sims on small blocks for the few hours that my big sims > are running. > > A year or so ago I tried using ModelSim XE along with PE on the same PC, > but never managed to get them both to work at the same time. > > Has anyone tried this recently with any sucess? > > Many Thanks, > > Ken Morrow, > Morrow Electronics Limited.Article: 53857
already5chosen@yahoo.com (Michael S) wrote in message > > > > In the first version, our butterfly adders [and subtractors] > > simply truncated any overflow and when our client began running > > data sets on the design, they immediately complained about the amount of > > distortion produced. We guessed it might be attributed to overflows, > > so we dropped in a limiting adder and were surprised by how much > > this cleaned up the output. > > > > -Tom > > I am much more conservative than you, Tom, in my arithmetical beliefs. > I wouldn't even consider the FFT implementation witch can overflow or > saturate in the middle. I agree letting the butterflies roll over was a mistake, but you still have to make a decision. After each FFT rank you can either clip the result or sign extend the result by 1 and drop the least significant bit. Either way, you loose information. If the spectrum is fairly flat, then it makes sense to clip because the information is kept in the least significant bits. But if you're expecting large spikes in the frequency domain then it is wise to shift and drop the LSB. Choosing which ranks to clip and which ones to shift really depends on the frequency content of the data -- some ranks are more prone to overflow than others. Of course there is a third option: grow the precision by 1 bit for each rank. In this case the only lost incurred is from the twiddle factor multiplication. This is a viable option if the input data has low precision and the FFT is fairly small. But for high precision and large point FFTs, this approach is not practical. Assuming we had infinite logic we could double the precision after each multiply and then add 1 bit for each adder. Then we wouldn't loose anything! ;-) -Tom -- Tom Hawkins tom1@launchbird.com Launchbird Design Systems, Inc. http://www.launchbird.com/Article: 53858
"Spam Hater 7" <spam_hater_7@email.com> wrote in message news:e9486eb9.0303250937.468bc0b0@posting.google.com... > Hi, > > Yes, it is possible to configure an FPGA so that it will destroy parts of itself. > > Two or more low-Z drivers on an internal bus is one way. > > I get a reminder of this at least once a year. > > SH Then, if you're using the Xilinx devices, you must still be using the classic 4000 or Spartan devices. The Virtex(E), Spartan-II(E), Virtex-II all use internal tristate emulation. The datasheets clearly explain that contention will not cause damage - multiple drivers with opposing states will result in a logic low and no drivers will result in a logic high. No damage because it's a logical equivalent without pumping current from one rail to another through two conflicting drivers.Article: 53859
Xilinx FAE from Insight SANKET wrote:
> It seems duplicate registers are being inferred due to your coding
> style.
The style problem is that the output port is never driven.
No output, no gates.
> Use coregen to instantiate a memory component.Inferring memories puts
> a heavy load on your synthesiser and run-times increase
> drastically.When you have the luxury of Coregen,why code for a
> memory.
I can think of three reasons at least:
1. Vendor independent source code.
2. Fast and easy simulation without any vendor libraries.
3. You own all of your source code.
-- Mike Treseler
Article: 53860Hello everybody! The following problems occured when using the Max Plus II software. I program files in VHDL. I did not find out how to successfully assign default values for variables or signals in an architecture part, so that these values are valid when starting the design. I tried out the following construct: ... variable xyz : integer range 0 to 3 := 3; ... But always on start the value of "xyz" is 0. Another problem appeared when attempting to create a user library. I wrote a function. I did it the same way Altera did in their libraries, for example in their ieee-library: I saved the package into one .vhd file and the package body into another one. Both were saved into the path ../vhdl93/ownlib/ . Obviously the library was compiled successfully. In the VHDL-file I wanted to use that function in I declared: Library ieee; use ieee.std_logic_1164.all; library ownlib; use xyz.all; ... But when compiling the file, Altera always printed an error message that said: Can't open VHDL "ownlib". Can anyone explain, how to successfully use my own library? Thanks a lot, Kay HammermuellerArticle: 53861
> johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0303181856.3de89734@posting.google.com>... > > I notice that 1 good die is offset (top right) ie the xy row col > > placement isn't entirely strict for no good obvious reason. > > There is a very obvious and good reason: when a wafer is diced, you > glue it to a membrane and then saw it in both perpendicular directions. > Only then are the individual dice taken off the membrane. > > > If it is indeed the case that wafers can be sawed row by row then > > independantly col by col I can see a 10% yield increase by sliding the > > corner clipped rows sideways a bit. Perhaps that would lead to 10% > > price reduction too! Perhaps a reward or job too! > > No cigar. :-) > > Achim. Of course thats obvious for most smaller & medium size chips where the lost yield would be <1%. But I see no practical reason why for very high value parts ie super size chips, more work couldn't be expended to break off the top & bottom rows and vertical saw the separated rows by hand. Still doesn't explain why 1 die located off xy grid. I assume that was an 8" wafer, so the chips were monsters at 1.5 by 2.3 cm or so. My last monster ASIC was only 1cm on a side. Is it necessary to use the same final process for $10 parts v parts that could be worth several thousand $. I don't think so. That kind of rigid thinking is what forces mask sets & fabs to keep going ever upwards, when some creative thinking will often give a little back. Anyway its not my 10% down the shute.Article: 53862
All, We have performed a study of many drivers in contention on many devices at both room temperature, and at hot temperatures that has lasted 4 years. No damage resulted in 4K devices from this internal contention. As long as the junction temperature is not exceeded from massive numbers in contention,these devices are really hard to break. I mean really hard to break. You see, we don't know what customers will do, so we have to assume every interconnect is at maximum load, maximum frequency, for life. This leads to some pretty conservative design rules. I suggest that if you have suddenly experienced a failure, that is the kind of failure known as "random" and fits well within our FIT rate predictions. As everyone knows, failures do happen, and if the designers, industry and foundries could prevent that from happening, we would all be happier when we have to design fail-safe systems. So, until then, fail safe systems fail, by failing to fail safely. Austin John_H wrote: > "Spam Hater 7" <spam_hater_7@email.com> wrote in message > news:e9486eb9.0303250937.468bc0b0@posting.google.com... > > Hi, > > > > Yes, it is possible to configure an FPGA so that it will destroy parts of > itself. > > > > Two or more low-Z drivers on an internal bus is one way. > > > > I get a reminder of this at least once a year. > > > > SH > > Then, if you're using the Xilinx devices, you must still be using the > classic 4000 or Spartan devices. The Virtex(E), Spartan-II(E), Virtex-II > all use internal tristate emulation. The datasheets clearly explain that > contention will not cause damage - multiple drivers with opposing states > will result in a logic low and no drivers will result in a logic high. No > damage because it's a logical equivalent without pumping current from one > rail to another through two conflicting drivers.Article: 53863
I used both .bit (.rbt file is the ASCII version) and XSVF (Jtag configuration). But I can tell you the easier way will be to implemente a XSVF control (use svf2xsvf.exe translator) via the APP58 from Xilinx. More, the software for your C sofware is ready to use and provided by Xilinx ... And you will be able to programm not only FPGAs, but CPLDs and Xilinx Flash :-) If you want, we have our own modification of the XSVFPlayer in a switch statement format. Laurent Gauch www.amontec.com ANN: we open a free HDL Util library on, just check it http://www.amontec.com/fix/core/amt_hdl_util/amt_hdl_utilindex.htm joan rodo wrote: > Hi Guys > > I'm developing a new board with a spartan II xc2s50 and I want to > integrated the programming of the FPGA in my C software there any routine > that translates from mcs file to a C file. > > Or there are any easy solution for to that. > > Thanks for all. > > > > > > >Article: 53864
http://www02.so-net.ne.jp/~morioka/cqpic.htm Supposedly a PIC16F84 implementation in VHDL. Version 1.00b appears to be downloadable on the site. But when I click the link, I get the following: "Forbidden You don't have permission to access /fb3/morioka/pic100a/cqpic100b.exe on this server." i.e. the standard no-access message. Are others running into this? If so, is there some other location from which I can download? Or is it somehow something in my environment that I need to change in order to download successfully? -- Alex Rast ad.rast.7@nwnotlink.NOSPAM.com (remove d., .7, not, and .NOSPAM to reply)Article: 53865
Hi,
I'm using the Memec/Insight XC2V1K-4 board, trying to synthesise a
moderately "busy" Microblaze system to run at 100MHz.
OPB cores are
2 UartLites
1 timer
1 MemCon
1 IntC
Instruction and data OBP are tied together because I'm exeuting code
from the external SRAM (thus an OPB arbiter is also inferred). In my
UCF file I'm specifiying a clock period of 100Mhz, however P&R is just
failing to meet timing. See extract below:
================================================================================
Timing constraint: TS_sys_clk = PERIOD TIMEGRP "sys_clk" 10 nS HIGH
50.000000 % ;
121741 items analyzed, 7 timing errors detected.
Minimum period is 10.315ns.
--------------------------------------------------------------------------------
Slack: -0.315ns (requirement - (data path - clock skew))
Source: timer/opb_timer_0_i_select_ff_i (FF)
Destination:
timer/opb_timer_0_i_tc_core_i_bus_interface_i_read_reg_ff_i21 (FF)
Requirement: 10.000ns
Data Path Delay: 10.315ns (Levels of Logic = 7)
This is the worst one, but there are two more paths, also relating to
the timer core, that fail timing by a few hundred ps.
A couple of questions then - other than reducing the number of cores on
the board, what can I do to improve the timing performance? I run all
this stuff from the Xygwin command line using the XPS generated
makefiles. Which command line parameter should I change to get P&R to
make greater effort?
Also, I'm a bit concerned about this message at the end of the timing
report:
Data Sheet report:
-----------------
All values displayed in nanoseconds (ns)
Clock to Setup on destination clock sys_clk
---------------+---------+---------+---------+---------+
| Src:Rise| Src:Fall| Src:Rise| Src:Fall|
Source Clock |Dest:Rise|Dest:Rise|Dest:Fall|Dest:Fall|
---------------+---------+---------+---------+---------+
sys_clk | 10.481| | | |
---------------+---------+---------+---------+---------+
WARNING:Timing:2718 - Clock nets using general routing resources were
found in
this design. Clock skew on these resources will not be automatically
addressed during path analysis. Please run trce with the -skew
option in
order to evaluate clock skew and hold violations.
The following clock nets use non-dedicated resources:
conn_0_bram_clk
Why are general routing resources carrying this clock, and how can I
prevent it?
Thanks,
John
Article: 53866John Williams wrote: > Hi, > > I'm using the Memec/Insight XC2V1K-4 board, trying to synthesise a > moderately "busy" Microblaze system to run at 100MHz. > > OPB cores are > > 2 UartLites > 1 timer > 1 MemCon > 1 IntC Sorry, I forgot I also have a 32 bit wide GPIO on there. Total slice usage is about 24% (1277 out of 5120) Thanks, JohnArticle: 53867
This maybe due to platgen inferring the IBUFG without the BUFG. Thus, you only have access to regular routing resources. Call xilinx hotline and ask for soln 16542. Basically, there's 2 ways to tackle this: 1> create a submodule MHS with a top-level HDL that instantiates the BUFG components (soln 16542) or 2> a top-level MHS that instantiates the BUFG component directly in MHS (you'll need to create the MPD definition for the BUFG primitive) You're better off with option 1. But, here's an untested example for option 2: You'll need to introduce UNISIM primitives into the MHS/MPD structure. MHS PORT clk_p = clk_p, DIR=IN BEGIN my_ibuf PORT I = clk_p PORT O = clk_ibufgout END BEGIN my_ibufg PORT I = clk_ibufgout PORT O = CLK_int END # MPD (my_ibufg) BEGIN my_ibufg, IPTYPE=IP, IMP_NETLIST=TRUE PORT I = "", DIR=IN, IOB_STATE=BUF PORT O = "", DIR=OUT END # MPD (my_bufg) BEGIN my_bufg, IPTYPE=IP, IMPNETLIST=TRUE PORT I = "", DIR=IN PORT O = "", DIR=OUT END John Williams wrote: > > John Williams wrote: > > Hi, > > > > I'm using the Memec/Insight XC2V1K-4 board, trying to synthesise a > > moderately "busy" Microblaze system to run at 100MHz. > > > > OPB cores are > > > > 2 UartLites > > 1 timer > > 1 MemCon > > 1 IntC > > Sorry, I forgot I also have a 32 bit wide GPIO on there. Total slice > usage is about 24% (1277 out of 5120) > > Thanks, > > John -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 53868
Unless you are driving lots of tbufs into contention continuously (and even then I doubt it would
hurt), you won't hurt the device. A single contending TBUF just doesn't generate enough heat to damage
the node. It is a moot point for Xilinx Virtex families, as they use a mux arrangement to mimic TBUF
behavior. There is no way to have internal contention inside the device with a valid bitstream. You
could put in a bad bitstream that simultaneously drives routes from more than one point to get
contention, but the tools won't do that by themselves.
It is far easier to pop a device by filling it up with ring oscillators, which essentially gives you
mucho nodes all toggling at very high frequencies. Even then, if your power supply doesn't have the
oomph to supply the required power you still won't make smoke. All of the failures I've seen have
involved abused I/O pads (ESD, prolonged high current contention, overvoltage), not the internals.
Spam Hater 7 wrote:
> Hi,
>
> Yes, it is possible to configure an FPGA so that it will destroy parts of itself.
>
> Two or more low-Z drivers on an internal bus is one way.
>
> I get a reminder of this at least once a year.
>
> SH
>
> Michael Garvie <mmg20@cogs.susx.ac.uk> wrote in message news:<3E7F5476.251F4276@cogs.susx.ac.uk>...
> > Dear All,
> > Do you know of any evidence suggesting a permanent failure mode
> > affecting a local area (CLB or routing) of an FPGA which doesn't go away
> > with reconfiguration or rebooting? Perhaps manufacturing defects only
> > appearing after a year of deployment, damage due to extreme operating
> > conditions or general degradation after decades of deployment?
> >
> > Single Event Latch-Up seems to be extremely uncommon and when it does
> > happen reconfiguration restores correct functionality.
> >
> > Yours Sincerely,
> > Miguel Garvie
--
--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: 53869
We don't infer memories in our designs so that we can explicitly control
implementation as well as placement in the code. That said, we also don't
use the coregen for the same reasons. I think the best way to use the
memories is to instantiate the primitives. If vendor independence really
is an issue, you can put a wrapper around the primitive instance and then
just change that lowest layer. Fact is, vendor independence is costly in
terms of device specific features you give up.
Mike Treseler wrote:
> Xilinx FAE from Insight SANKET wrote:
>
> > It seems duplicate registers are being inferred due to your coding
> > style.
>
> The style problem is that the output port is never driven.
> No output, no gates.
>
> > Use coregen to instantiate a memory component.Inferring memories puts
> > a heavy load on your synthesiser and run-times increase
> > drastically.When you have the luxury of Coregen,why code for a
> > memory.
>
> I can think of three reasons at least:
>
> 1. Vendor independent source code.
> 2. Fast and easy simulation without any vendor libraries.
> 3. You own all of your source code.
>
> -- Mike Treseler
--
--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: 53870
John Williams wrote:
> A couple of questions then - other than reducing the number of cores on
> the board, what can I do to improve the timing performance? I run all
> this stuff from the Xygwin command line using the XPS generated
> makefiles. Which command line parameter should I change to get P&R to
> make greater effort?
To find what par options are, check the manuals or type on a command
prompt:
par
Largest effort is probably this:
par -ol 5 -xe 2
Also might want to try different cost tables. Replace the single par
command with a list like this:
par -ol 5 -xe 2 -t 1 {rest of stuff} <infile.ncd> <outfile1>
par -ol 5 -xe 2 -t 2 {rest of stuff} <infile.ncd> <outfile2>
par -ol 5 -xe 2 -t 3 {rest of stuff} <infile.ncd> <outfile3>
par -ol 5 -xe 2 -t 4 {rest of stuff} <infile.ncd> <outfile4>
par -ol 5 -xe 2 -t 5 {rest of stuff} <infile.ncd> <outfile5>
...
Also, you might want to floorplan the design.
> Also, I'm a bit concerned about this message at the end of the timing
> report:
> WARNING:Timing:2718 - Clock nets using general routing resources were
> found in this design.
> Why are general routing resources carrying this clock, and how can I
> prevent it?
List of possible reasons is fairly long: Wrong signal name used for the
clock signal, gated clock, enable in block ram not correctly identified
by the synthesis tool, ...
Hope this helped.
--
Phil Hays
Article: 53871
Hi Phil,
Phil Hays wrote:
> Largest effort is probably this:
>
> par -ol 5 -xe 2
>
> Also might want to try different cost tables. Replace the single par
> command with a list like this:
>
> par -ol 5 -xe 2 -t 1 {rest of stuff} <infile.ncd> <outfile1>
> par -ol 5 -xe 2 -t 2 {rest of stuff} <infile.ncd> <outfile2>
> par -ol 5 -xe 2 -t 3 {rest of stuff} <infile.ncd> <outfile3>
> par -ol 5 -xe 2 -t 4 {rest of stuff} <infile.ncd> <outfile4>
> par -ol 5 -xe 2 -t 5 {rest of stuff} <infile.ncd> <outfile5>
> ...
>
> Also, you might want to floorplan the design.
Thanks for that. I'll leave floorplanning as a last resort - these
Microblaze designs end up looking pretty hairy.
>>Why are general routing resources carrying this clock, and how can I
>>prevent it?
> List of possible reasons is fairly long: Wrong signal name used for the
> clock signal, gated clock, enable in block ram not correctly identified
> by the synthesis tool, ...
Agreed. What confused me is that all this stuff is done automagically
by the Microblaze/EDK tools.
Thanks again,
John
Article: 53872Paulo Dutra wrote: > This maybe due to platgen inferring the IBUFG without the BUFG. Thus, > you only have access to regular routing resources. > > Call xilinx hotline and ask for soln 16542. > > Basically, there's 2 ways to tackle this: > > 1> create a submodule MHS with a top-level HDL that instantiates > the BUFG components (soln 16542) > > or > > 2> a top-level MHS that instantiates the BUFG component directly > in MHS (you'll need to create the MPD definition for the BUFG primitive) > > You're better off with option 1. But, here's an untested example for option 2: > You'll need to introduce UNISIM primitives into the MHS/MPD structure. Thanks Paulo. Any idea if this is fixed in the next version/service pack of EDK? JohnArticle: 53873
> All of the failures I've seen have involved abused I/O pads (ESD, > prolonged high current contention, overvoltage), not the internals. The old PAM system at DEC/PRL (array of XC3090s) blew up a board when an NFS server glitch trashed a page of the configuration bits. (Checksums are good.) I still have a funny spot on my thumb when I touched a XC3090 that was fighting somebody else over the PCI bus. It was hot enough to burn me but worked again after we power cycled the box. Bus collisions are bad news. I remember killing a system that way. When we got it apart far enough to look around it was pretty obvious where the problem was. One of the fancy 16-bit wide bus driver chips had a crack through the middle. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 53874
geeko wrote: > > hi all > What is the difference between he Typical gates and Maximum System gates > specifications > For Altera EPXA1 these ratings are 100K and 263K respectively what may be > the available gates for programming > regards > geeko I have not looked at the actual terms you are asking about, but my best guess is that one tells you the capacity of the FPGA and the other is a best estimate of how many of those gates are used by a typical design that fits in the part. Of course the number of gates in the design depends entirely on the details of how the design fits the chip. If your design optimally uses the features of the chip you can see a much higher gate count in the same chip as another design which just doesn't make good use of the chip features. So in the real world, gates are not a good way to measure a chip. You will do much better to fit your design to the chip and see how well it fits. Or at least do a preliminary job of estimating by trying to "guesstimate" the details of how your design will fit in the chip. -- 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 FAX
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