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
Josh, In addition to what Ray says, are you sure your printed-circuit boards are good? Have you done any sort of signal-integrity simulation on them? Since you indicate that you're changing your clock speeds, what sort of clock generator are you using? Do you have a proper clock-distribution tree on your boards? Please tell me your boards are not wire-wrapped. Just because you run at reduced clock speeds doesn't mean you don't have to worry about edge rates. How about your power-supply distribution? Decoupling? Are your parts socketed? Say, for instance, you worked for a commercial company, and you put an FPGA on a board, and you shipped 100,000 boards. This means that your customer service group would be dealing with 2,000 returned products. Methinks your manager would not only fire you, he'd shoot you in the face with a bazooka*. -andy * Thanks to Bill Cosby for the bazooka line. "B. Joshua Rosen" wrote: > > I've got these figures based on the tests that I have written for an > ASIC emulator company. Each box has hundreds of FPGAs so we would typically > find several bad FPGAs per system. I don't have exact figures for the > Virtex family, although they seem to be better than the 4000 > family, but the 1 in 50 number held for various incarnations of the > 5200 and 4000 series. My tests do not violate any timing restrictions, in fact we > run them at various clock rates and failures happen at the lowest speeds > as well as for the higher speeds. Before adding these tests we would > frequently run into problems with customer patterns, now that's much > much rarer although it can still happen occasionally. Even with about 150 > test patterns we are only getting coverage of 93% of the PIPs, although > the coverage of the PIPs that we actually use is probably closer to 99%. > Xilinx has added tests to their test suites which use the same methodology as > my tests and it does seem that the Virtex parts have a lower fallout than > the older families. I've also used a Xilinx internal tool to determine > what my coverage is. I could be wrong about the chances of a particular > pattern hitting a defect but I'm not wrong about defect rate. With my > test patterns I will generally see 2 or 3 patterns fail on a bad part > out of a suite of approximately 150. However my patterns are designed for > maximum coverage, it's possible that a typical pattern has only a 1 on > 500 chance of seeing the defect as opposed to the 1 in 50 that I see. So > if 1 in 50 parts has a defect and 1 in 500 patterns hits it then you > would see a 1 in 25000 fallout in real systems. If my test patterns are > closer to the real world then the system fallout rate would be 1 in 2500. > Either way the system fallout rate is low enough that you wouldn't notice > it. Also without a test suite like I wrote for the emulator company you > would have no way of knowing that it was the FPGA that caused the > problem, the board will simply be declared a dog and tossed aside on the > dog board pile. > > In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka" > <ray@andraka.com> wrote: > > > Where are you getting these numbers from? My experience with FPGAs over > > the past 13 years and several hundred designs certainly doesn't support > > such numbers. Is it possible you might have been violating timing??? > > What devices were you testing? > > > > "B. Joshua Rosen" wrote: > > > >> Date codes don't matter it's really a random process that causes > >> problems. Having several boards is certainly useful in development but > >> you would probably do that anyway. As I say the chances of actually > >> hitting a problem are low, but if you go through 10 ro 20 spins you > >> will likely have a one in a few hundred chance of hitting a defective > >> switch. > >> > >> Josh > >> > >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" > >> <jim.granville@designtools.co.nz> wrote: > >> > >> > B. Joshua Rosen wrote: > >> >> > >> >> The coverage that the FPGA vendors provide is less than perfect but > >> >> it's good enough for most applications. In my experience, writing > >> >> FPGA test programs for an ASIC emulator manufacturer, about 1 in 50 > >> >> FPGAs have some defect although the chance of any one pattern > >> >> running into that defect is in the neighborhood of 1 in 100. As a > >> >> result the chance that any one pattern will have a problem on any > >> >> particular FPGA is about 1 in 5000. As you raise the number of > >> >> patterns that you run on a particular FPGA the chances that you will > >> >> run into a problem approached the 1 in 50 number. > >> >> > >> >> The way that you test FPGAs is different then the way that you test > >> >> an ASIC. FPGAs are mostly interconnect which makes them harder to > >> >> test. On the other hand because they are soft you can run an > >> >> unlimited number of different test patterns on them, which > >> >> simplifies the problem as compared to an ASIC. If you are concerned > >> >> about shipping an FPGA with a hidden defect then the way that you > >> >> solve it is to run a large number of test patterns on your FPGAs and > >> >> throw out the bad ones. > >> > <snip> > >> > > >> > Very interesting stats. > >> > Besides shipping product, this also has issues for development > >> > itself. > >> > With a 1:50 chance of a defect, it would make sense to have two, > >> > or maybe three, (and probably with different date codes), test boards > >> > that are called on for second opinions when a curly fault arises. > >> > As these boards rack up more 'passes', they increase in value :-) > >> > > >> > Sounds like the tools could benefit from a 'randomise' switch > >> > - or maybe a start-from-other-corner placement alogrithm ? > >> > > >> > -jg > > > > -- > > -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 > > > >Article: 33576
Paul Smart wrote: > Hi Rick, > I have the TestBench product guys at IBM telling me that the output > from the ngd2ver is "behavioral", not "structural". > Paul > > On Fri, 27 Jul 2001 19:17:38 +0100, Rick Filipkiewicz > <rick@algor.co.uk> wrote: > I'm not sure, then, what your guys mean by structural. I always thought it means a huge list of instantiations of models for the ASIC/FPGAs primitive elements. If that's so then that's what NGD2VER produces. I just did a quick grep for ``assign'' & ``always'' and found none.Article: 33577
Dick Ginther <dick.ginther@wavecom.ca> wrote in message news:r3j97.20$7i.589926@tomcat.sk.sympatico.ca... > Hi, > I'm looking for some open source for a i2c bus master...does anyone > know of some? Why? Master behaviour is easy to bit-bash. Slave behaviour is something well worth doing in hardware though...Article: 33578
Yes, there is a difference. I missed the fact that you were using a Virtex2. Virtex only allows 1 output from an SRL16, while virtex2 gives you the selected output plus the last tap so it is easier to cascade them. I am not sure offhand whether the V2 SRL16 blocks the F5 mux or not. The place to look is the FPGA editor if you have any doubts. Huang wrote: > Ray, thanks a lot for your answer. > > What I am trying to do is implementing a circular queque. > The output of cascaded SRL16 will be modified and loaded as input. > > In the Virtex2 handbook chapter2, page 214, a 32bit shift register is implemented as two SELC16E and a MUXF5. Additionally, the verilog template for component instatiation by Xilinx does have a corresponding SRLC32E_MACRO.v, which is synthesisable. > > Is there any difference between Virtex and Virtex2 regarding SRL16? -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33579
Paul Smart wrote: > Thanks to all who responded. The following "threads" of thought have > been discussed (so far): > > ---------- > The output of ngd2ver is considered "behavioral" by at least one ATPG > tool vendor (IBM TestBench product). Some tools can work with > behavioral verilog, some tools cannot work with non-scan architecture. It is behavioral in the sense that you can't go back and run that vhdl through the tools to regenerate the design (wrong library). It doesn't map directly back into the unisim primitives. > > > ---------- > "Timing errors in placed and routed design" > This illustrates why the manufacturer cannot 100% test, as he is not > testing the customers exact placed and routed design. My customer may > see failures in the system. If you have timing errors in the placed and routed design, the static timing analyzer will find them, provided you have sufficiently constrained the design. Places to look out for: multiple or gated clocks, crossing clock domains, clock skew introduced by not using clock nets, set-up and hold (offsets) to I/o pins. If the analyzer shows timing errors, it may work in the lab, but I'll guarantee that if you make enough of them you'll see some of them back from the customer (unless it is a path that you've determined is not a problem, of course) > > > ---------- > "Manufacturers do the testing for you" > Shortcuts *may* be taken by the FPGA manufacturer to reduce the cost > of test, and the customers design can never be 100% tested for (unless > it is one of the test designs, and is a 100% testable design). My > customer may see failures in the system. The reconfigurability of the devices does allow close to 100% testing of the pips, switch boxes and LUTs. Adding scan to the internal logic of the FPGA is expensive and yields very little benefit, as you can (and the manufacturers do) easily use reconfigurability to get at any pip, switchbox, LUT, flip-flop, carry chain element etc in the design. > > > ---------- > "Parts are not 100% testable (absence of scan or other DFT tools)" > " DPM levels" > > My customer is in the following categories: > -Comparatively high volume of FPGA's per board/system > -Comparatively low volume of systems > -Extremely high system reliability requirements Sounds pretty typical... > > > My customer DOES see significant failures in boards/system (100's of > devices per month) Sounds like you have a design problem you haven't properly diagnosed. I'd check very carefully that a) your static timing analysis has full coverage of the design, b) you don't have any timing failures, c) you aren't having a problem with crossing clock domain boundaries improperly, d) your input clocks are clean, e) you've distributed clocks on the clock networks, not on general routing (your aren't gateing clocks, right?), f) your power supplies are solid and properly bypassed, etc. Also, make sure you are using the latest timing files for your timing analysis. Refinements in the characterization have required adjustments to the timing parameters(in both directions). Again, across literally hundreds of designs, I have yet to see a failure caused by a device defect that was not a result of abusing the part (overstressing temp or voltage) or a silicon bug (in which case the error is the same on every device). Could you tell us which devices you have experienced these problems with? Have you isolated the problems to particular structures in the FPGA? I suspect not, rather I am guessing you fail a board, then run a homespun test that also fails so you assume the chip is bad. Is there any way you can post the details of your testing so that others can substantiate or refute your claims? Have the manufacturers of the chips involved had a chance to review your test setup and results? If so what are their comments? > > > They experience DPM from > 300-500 (reasonable) > 1000-5000 (painful) > 5000-10,000 (extreme production impact) > > These failures are uncovered during the thorough board level and > system level testing perfomed during manufacturing. > > DPM in the 1000 to 2000 range are common. > > They have seen as high as 50,000 DPM in an extreme case (design > routing problem (caused by software?) was identified). > > Die steps and new generation devices see higher failure rates > initially, and then scale back over time (product maturity?). > > Many of the failed components cannot be verified as rejects by the > manufacturer (the manufacturers test methods missed the problem). This > applies to both X and A, my customer is a large user of both. > > > ---------- > My ideal first goal would be to have the verilog output from the tools > be directly usable with existing ASIC ATPG tools, specifically those > that can work with non scan designs. It is not a final solution, but > it is a step in the right direction. > > DFT tools for FPGA might be the next step. Given that this problem > does not significantly affect all users of FPGAs, I don't know how > reasonable it is to expect such tools to become a reality in the near > future. > > My end goal is to test and remove as many defects as possible at the > component level, before my customer places them on a board. It remains > to be seen how we will get there. -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33580
These failures occur both on board and on chiptesters. My client has Xilinx prescreen FPGAs on a chiptester using a subset of my test patterns (approximately 40 out of the 150). The fall out rate on the chiptester is consistant to what we were seeing on boards before we were doing prescreening. The screened parts have much lower on board failure rates because the prescreening find about 90% of the bad parts. The full test suite finds the remaining bad parts. The reason for not running the full suite on the tester has to do with test time limitations. I can't post my methodology on the net, it's proprietary to my client. However I have spent time with Xilinx's test group discussing my techniques and they agree that they are sound. More to the point Xilinx is using a similar strategy to test the Virtex parts. To answer your question about variable clock speeds, the clocks are PLL based and designed to be variable. The clock tree's are extremely well controlled and are not the source of any of these internal problems. The systems that these FPGAs are in are million dollar ASIC emulators, they are not garage shop kluges. Also I've been implementing variations of these test patterns for multiple incarnations of the system going back to 1994. The FPGAs that have been used are the 5212, 4013, 4036e, 4062xl and the XCV800. The failure rates have been fairly consistant over the years across the various generations of FPGAs, although I think that the rates are somewhat lower for the Virtex parts. Josh In article <jSj97.8011$bl1.1229433@newsread1.prod.itd.earthlink.net>, "Andy Peters <andy [@] exponentmedia" <".> wrote: > Josh, > > In addition to what Ray says, are you sure your printed-circuit boards > are good? Have you done any sort of signal-integrity simulation on > them? Since you indicate that you're changing your clock speeds, what > sort of clock generator are you using? Do you have a proper > clock-distribution tree on your boards? Please tell me your boards are > not wire-wrapped. > > Just because you run at reduced clock speeds doesn't mean you don't have > to worry about edge rates. > > How about your power-supply distribution? Decoupling? > > Are your parts socketed? > > Say, for instance, you worked for a commercial company, and you put an > FPGA on a board, and you shipped 100,000 boards. This means that your > customer service group would be dealing with 2,000 returned products. > Methinks your manager would not only fire you, he'd shoot you in the > face with a bazooka*. > > -andy > > * Thanks to Bill Cosby for the bazooka line. > > "B. Joshua Rosen" wrote: >> >> I've got these figures based on the tests that I have written for an >> ASIC emulator company. Each box has hundreds of FPGAs so we would >> typically find several bad FPGAs per system. I don't have exact figures >> for the Virtex family, although they seem to be better than the 4000 >> family, but the 1 in 50 number held for various incarnations of the >> 5200 and 4000 series. My tests do not violate any timing restrictions, >> in fact we run them at various clock rates and failures happen at the >> lowest speeds as well as for the higher speeds. Before adding these >> tests we would frequently run into problems with customer patterns, now >> that's much much rarer although it can still happen occasionally. Even >> with about 150 test patterns we are only getting coverage of 93% of the >> PIPs, although the coverage of the PIPs that we actually use is >> probably closer to 99%. Xilinx has added tests to their test suites >> which use the same methodology as my tests and it does seem that the >> Virtex parts have a lower fallout than the older families. I've also >> used a Xilinx internal tool to determine what my coverage is. I could >> be wrong about the chances of a particular pattern hitting a defect but >> I'm not wrong about defect rate. With my test patterns I will generally >> see 2 or 3 patterns fail on a bad part out of a suite of approximately >> 150. However my patterns are designed for maximum coverage, it's >> possible that a typical pattern has only a 1 on 500 chance of seeing >> the defect as opposed to the 1 in 50 that I see. So if 1 in 50 parts >> has a defect and 1 in 500 patterns hits it then you would see a 1 in >> 25000 fallout in real systems. If my test patterns are closer to the >> real world then the system fallout rate would be 1 in 2500. Either way >> the system fallout rate is low enough that you wouldn't notice it. Also >> without a test suite like I wrote for the emulator company you would >> have no way of knowing that it was the FPGA that caused the problem, >> the board will simply be declared a dog and tossed aside on the dog >> board pile. >> >> In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka" >> <ray@andraka.com> wrote: >> >> > Where are you getting these numbers from? My experience with FPGAs >> > over the past 13 years and several hundred designs certainly doesn't >> > support such numbers. Is it possible you might have been violating >> > timing??? What devices were you testing? >> > >> > "B. Joshua Rosen" wrote: >> > >> >> Date codes don't matter it's really a random process that causes >> >> problems. Having several boards is certainly useful in development >> >> but you would probably do that anyway. As I say the chances of >> >> actually hitting a problem are low, but if you go through 10 ro 20 >> >> spins you will likely have a one in a few hundred chance of hitting >> >> a defective switch. >> >> >> >> Josh >> >> >> >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" >> >> <jim.granville@designtools.co.nz> wrote: >> >> >> >> > B. Joshua Rosen wrote: >> >> >> >> >> >> The coverage that the FPGA vendors provide is less than perfect >> >> >> but it's good enough for most applications. In my experience, >> >> >> writing FPGA test programs for an ASIC emulator manufacturer, >> >> >> about 1 in 50 FPGAs have some defect although the chance of any >> >> >> one pattern running into that defect is in the neighborhood of 1 >> >> >> in 100. As a result the chance that any one pattern will have a >> >> >> problem on any particular FPGA is about 1 in 5000. As you raise >> >> >> the number of patterns that you run on a particular FPGA the >> >> >> chances that you will run into a problem approached the 1 in 50 >> >> >> number. >> >> >> >> >> >> The way that you test FPGAs is different then the way that you >> >> >> test an ASIC. FPGAs are mostly interconnect which makes them >> >> >> harder to test. On the other hand because they are soft you can >> >> >> run an unlimited number of different test patterns on them, which >> >> >> simplifies the problem as compared to an ASIC. If you are >> >> >> concerned about shipping an FPGA with a hidden defect then the >> >> >> way that you solve it is to run a large number of test patterns >> >> >> on your FPGAs and throw out the bad ones. >> >> > <snip> >> >> > >> >> > Very interesting stats. >> >> > Besides shipping product, this also has issues for development >> >> > itself. >> >> > With a 1:50 chance of a defect, it would make sense to have two, >> >> > or maybe three, (and probably with different date codes), test >> >> > boards that are called on for second opinions when a curly fault >> >> > arises. >> >> > As these boards rack up more 'passes', they increase in value :-) >> >> > >> >> > Sounds like the tools could benefit from a 'randomise' switch >> >> > - or maybe a start-from-other-corner placement alogrithm ? >> >> > >> >> > -jg >> > >> > -- >> > -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 >> > >> >Article: 33581
But how do you do a normal add while getting access to the right carry bits? John_H wrote: > > You're trying to do all the work for the synthesizer by telling it how to > perform addition. > Let the synthesizer to the addition - you just concentrate on the saturable > aspect. > Leonardo spectrum should get all the carry chains together fine because it > know how to utilize them to add. > > Russell Shaw wrote: > > > Hi all, > > > > I made this saturable adder from converting AHDL code in a previous > > message. > > > > It adds signed HEX numbers together, but doesn't roll-over if there's > > an overflow. > > > > I'm using leonardo-spectrum to generate an edif netlist, which is > > compiled by altera maxplus2. > > > > Where and how, if any, can i add technology-dependent optimizations > > such as carry chains etc? > > > > Also, are there such things as VHDL debuggers where you can single- > > step thru the code and see what all the signals and variables are > > doing? > > > > LIBRARY ieee; > > USE ieee.std_logic_1164.all; > > > > PACKAGE types IS > > subtype word is std_ulogic_vector(3 downto 0); > > END types; > > > > LIBRARY ieee; > > USE ieee.std_logic_1164.all; > > use work.types.all; > > > > ENTITY saturable_adder IS > > port( > > a,b: in word; > > s: out word > > ); > > END adder; > > > > LIBRARY ieee; > > USE ieee.std_logic_1164.all; > > use work.types.all; > > > > ARCHITECTURE total OF saturable_adder IS > > BEGIN > > behav: PROCESS (a,b) is > > variable sum: word; > > variable carry_in,carry_out: std_ulogic; > > constant msb:integer:=word'left; > > > > BEGIN > > carry_in:='0'; > > for ndx in 0 to (word'left-1) loop > > sum(ndx):=a(ndx) xor b(ndx) xor carry_in; > > carry_out:=(a(ndx) and b(ndx)) or (a(ndx) and carry_in) or (b(ndx) > > and carry_in); > > carry_in:=carry_out; > > end loop; > > sum(msb):=a(msb) xor b(msb) xor carry_in; > > if( (a(msb) and b(msb) and not carry_in)='1' ) > > then > > sum:=(others=>'0'); > > sum(msb):='1'; > > elsif( (not a(msb) and not b(msb) and carry_in)='1' ) > > then > > sum:=(others=>'1'); > > sum(msb):='0'; > > end if; > > s<=sum; > > END PROCESS behav; > > END total; > > -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 33582
Hi, Try the one from XESS, kind-of-beginner's guide. HTH, Srini http://www.xess.com/appnotes/webpack-1_5.pdf -- Srinivasan Venkataramanan ASIC Design Engineer Software & Silicon Systems India Pvt. Ltd. (An Intel company) Bangalore, India "Dave Feustel" <dfeustel@mindspring.com> wrote in message news:9k4hdk$a4g$1@slb5.atl.mindspring.net... > I've got Webpack download and installed. > Where can I find tutorials that will show > me how to use the software? > > Thanks, > > Dave Feustel > >Article: 33583
Have a look to: http://www.opencores.org/projects.shtml By Ingmar Dick Ginther schrieb: > Hi, > I'm looking for some open source for a i2c bus master...does anyone > know of some? > Thanks. -- ___________________________________________________________________ Ingmar Hohmann mailto:ih@seh.de SEH Computertechnik GmbH http://www.seh.de Suedring 11 Fax: +49 521 94226 99 D-33647 Bielefeld Phone:+49 521 94226 63 GERMANY __________________________________________________________________Article: 33584
Dick Ginther <dick.ginther@wavecom.ca> wrote in message news:r3j97.20$7i.589926@tomcat.sk.sympatico.ca... > Hi, > I'm looking for some open source for a i2c bus master...does anyone > know of some? Why? Master behaviour is easy to bit-bash. Slave behaviour is something well worth doing in hardware though...Article: 33585
Tomek a écrit : > > Hi > I have a problem. I have XILINX Foundation Software v1.3 . I > have FLEXlm license. I work under Windows NT. > When I want to create ".bit" file I have error: > > map -p xc4005xl-3-pc84 -o map.ncd ../xc4000xl.ngd vgatst.pcf > map: version M1.3.7 > Copyright (c) 1995-1997 Xilinx, Inc. All rights reserved. > > par -w -l 4 -d 0 map.ncd vgatst.ncd vgatst.pcf > PAR: Xilinx Place And Route M1.3.7. > Copyright (c) 1995-1997 Xilinx, Inc. All rights reserved. > > ERROR:baspw:110 - Cannot find Input file "map.ncd". Please > verify that your paths and permissions are properly set for > this file. Hi Are you sure the map.ncd file exists? If the mapper fails it won't generate anything and the placer will give you such an error. Have a look at the mapper report (*.mrp) -- Nicolas MATRINGE IPricot European Headquarters Conception electronique 10-12 Avenue de Verdun Tel +33 1 46 52 53 11 F-92250 LA GARENNE-COLOMBES - FRANCE Fax +33 1 46 52 53 01 http://www.IPricot.com/Article: 33586
A never ending problem! Trying to get RAMs in my design so that there is
not to much vendor specific code.
For Altera I'm using Leonardo and Max+plus, for Xilinx WebPack.
I need a RAM with rgistered rd and wr address and unregistered data (in/out)
ports.
One version works:
Generate a .tdf file with Altera wizard and declare the component in the
VHDL
code. But now I have .tdf files. I want only VHDL.
Second try: Write it in VHDL: (code attached)
The generated code does not use the registers in the Altera EAB. It
generates
DFFs. Not good for the timing and a waste of resource.
Third try: Instantiate Altera lpm-ram in VHDL (attached as aram.vhd):
Leonardo takes it as black box, but generates a long name with all generics
in the modul name for the edf file and Max+plus does not find this modul!
Lot of time wasted till now. Perhaps someone solved this problem allready.
Thanks
Martin
--
Whant to see the evolution of a Java processor?
http://www.jopdesign.com
begin 666 ram.vhd
M+2T-"BTM"7)A;2YV:&0-"BTM#0HM+0EI;G1E<FYA;"!M96UO<GD@9F]R($I/
M4#,-"BTM#0HM+2!N;W<@9F]R(%AI;&EN>"!))W9E('1O('5S92!62$1,(#HM
M*0T*+2T-"@T*3&EB<F%R>2!)145%(#L-"G5S92!)145%+G-T9%]L;V=I8U\Q
M,38T+F%L;" [#0IU<V4@245%12YS=&1?;&]G:6-?87)I=&@N86QL(#L-"G5S
M92!)145%+G-T9%]L;V=I8U]U;G-I9VYE9"YA;&P@.PT*#0IE;G1I='D@<F%M
M(&ES#0IG96YE<FEC("AW:61T:" Z(&EN=&5G97(@.CT@,S([(')E9U]W:61T
M:" Z(&EN=&5G97(@.CT@."D[#0IP;W)T("@-"@ED871A"0DZ(&EN('-T9%]L
M;V=I8U]V96-T;W(H=VED=&@M,2!D;W=N=&\@,"D[#0H)=W)A9&1R97-S"3H@
M:6X@<W1D7VQO9VEC7W9E8W1O<BAR96=?=VED=&@M,2!D;W=N=&\@,"D[#0H)
M<F1A9&1R97-S"3H@:6X@<W1D7VQO9VEC7W9E8W1O<BAR96=?=VED=&@M,2!D
M;W=N=&\@,"D[#0H)=W)E;@D).B!I;B!S=&1?;&]G:6,[#0H)8VQO8VL)"3H@
M:6X@<W1D7VQO9VEC.PT*#0H)<0D)"3H@;W5T('-T9%]L;V=I8U]V96-T;W(H
M=VED=&@M,2!D;W=N=&\@,"D-"BD[#0IE;F0@<F%M(#L-"@T*+2T-"BTM"7)E
M9VES=&5R960@=W)A9&1R97-S+"!W<F5N#0HM+0EU;G)E9VES=&5R960@9&EN
M#0HM+0ER96=I<W1E<F5D(')D861D<F5S<PT*+2T)=6YR96=I<W1E<F5D(&1O
M=70-"BTM#0IA<F-H:71E8W1U<F4@<G1L(&]F(')A;2!I<PT*#0H)='EP92!M
M96U?='EP92!I<R!A<G)A>2 H,"!T;R R-34I(&]F('-T9%]L;V=I8U]V96-T
M;W(H=VED=&@M,2!D;W=N=&\@,"D[#0H-"@ES:6=N86P@;65M( D).B!M96U?
M='EP93L-"@T*"7-I9VYA;"!W<F%D9'().B!S=&1?;&]G:6-?=F5C=&]R*')E
M9U]W:61T:"TQ(&1O=VYT;R P*3L-"@ES:6=N86P@<F1A9&1R"3H@<W1D7VQO
M9VEC7W9E8W1O<BAR96=?=VED=&@M,2!D;W=N=&\@,"D[#0H)<VEG;F%L('=R
M7V5N80DZ('-T9%]L;V=I8SL-"@T*"7-I9VYA;"!D;PD).B!S=&1?;&]G:6-?
M=F5C=&]R*'=I9'1H+3$@9&]W;G1O(# I.PT*#0H-"F)E9VEN#0H-"G!R;V-E
M<W,H8VQO8VLI#0IB96=I;@T*"6EF(')I<VEN9U]E9&=E*&-L;V-K*2!T:&5N
M#0H)"7=R861D<B \/2!W<F%D9')E<W,[#0H)"7=R7V5N82 \/2!W<F5N.PT*
M"0ER9&%D9'(@/#T@<F1A9&1R97-S.PT*"65N9"!I9CL-"F5N9"!P<F]C97-S
M.PT*#0IP<F]C97-S*&1A=&$L('=R7V5N82D-"F)E9VEN#0H):68@*'=R7V5N
M82 ]("<Q)RD@=&AE;@T*"0EM96TH8V]N=E]I;G1E9V5R*'5N<VEG;F5D*'=R
M861D<BDI*2 \/2!D871A.PT*"65N9"!I9B [#0IE;F0@<')O8V5S<SL-"@T*
M"61O(#P](&UE;2AC;VYV7VEN=&5G97(H=6YS:6=N960H<F1A9&1R*2DI.PT*
7"7$@/#T@9&\[#0H-"F5N9"!R=&P[#0H`
`
end
begin 666 aram.vhd
M+2T-"BTM"6%R86TN=FAD#0HM+0T*+2T):6YT97)N86P@;65M;W)Y(&9O<B!*
M3U S#0HM+0E697)S:6]N(&9O<B!!;'1E<F$-"BTM#0HM+0T*#0I,:6)R87)Y
M($E%144@.PT*=7-E($E%144N<W1D7VQO9VEC7S$Q-C0N86QL(#L-"G5S92!)
M145%+G-T9%]L;V=I8U]A<FET:"YA;&P@.PT*=7-E($E%144N<W1D7VQO9VEC
M7W5N<VEG;F5D+F%L;" [#0H-"F5N=&ET>2!R86T@:7,-"F=E;F5R:6,@*'=I
M9'1H(#H@:6YT96=E<B Z/2 S,CL@<F5G7W=I9'1H(#H@:6YT96=E<B Z/2 X
M*3L-"G!O<G0@* T*"61A=&$)"3H@:6X@<W1D7VQO9VEC7W9E8W1O<BAW:61T
M:"TQ(&1O=VYT;R P*3L-"@EW<F%D9')E<W,).B!I;B!S=&1?;&]G:6-?=F5C
M=&]R*')E9U]W:61T:"TQ(&1O=VYT;R P*3L-"@ER9&%D9')E<W,).B!I;B!S
M=&1?;&]G:6-?=F5C=&]R*')E9U]W:61T:"TQ(&1O=VYT;R P*3L-"@EW<F5N
M"0DZ(&EN('-T9%]L;V=I8SL-"@EC;&]C:PD).B!I;B!S=&1?;&]G:6,[#0H-
M"@EQ"0D).B!O=70@<W1D7VQO9VEC7W9E8W1O<BAW:61T:"TQ(&1O=VYT;R P
M*0T**3L-"F5N9"!R86T@.PT*#0HM+0T*+2T)<F5G:7-T97)E9"!W<F%D9')E
M<W,L('=R96X-"BTM"75N<F5G:7-T97)E9"!D:6X-"BTM"7)E9VES=&5R960@
M<F1A9&1R97-S#0HM+0EU;G)E9VES=&5R960@9&]U= T*+2T-"F%R8VAI=&5C
M='5R92!R=&P@;V8@<F%M(&ES#0H-"@E#3TU03TY%3E0@86QT9'!R86T-"@E'
M14Y%4DE#("@-"@D)=VED=&@)"3H@3D%455)!3#L-"@D)=VED=&AA9 D).B!.
M05154D%,.PT*"0EI;F1A=&%?<F5G"0DZ(%-44DE.1SL-"@D)=W)A9&1R97-S
M7W)E9PD).B!35%))3D<[#0H)"7=R8V]N=')O;%]R96<)"3H@4U1224Y'.PT*
M"0ER9&%D9')E<W-?<F5G"0DZ(%-44DE.1SL-"@D)<F1C;VYT<F]L7W)E9PD)
M.B!35%))3D<[#0H)"6]U=&1A=&%?<F5G"0DZ(%-44DE.1SL-"@D):6YD871A
M7V%C;'()"3H@4U1224Y'.PT*"0EW<F%D9')E<W-?86-L<@D).B!35%))3D<[
M#0H)"7=R8V]N=')O;%]A8VQR"0DZ(%-44DE.1SL-"@D)<F1A9&1R97-S7V%C
M;'()"3H@4U1224Y'.PT*"0ER9&-O;G1R;VQ?86-L<@D).B!35%))3D<[#0H)
M"6]U=&1A=&%?86-L<@D).B!35%))3D<[#0H)"6QP;5]F:6QE"0DZ(%-44DE.
M1SL-"@D);'!M7VAI;G0)"3H@4U1224Y'#0H)*3L-"@E03U)4("@-"@D)"7=R
M96X).B!)3B!35$1?3$]'24,@.PT*"0D):6YC;&]C:PDZ($E.(%-41%],3T=)
M0R [#0H)"0EQ"3H@3U54(%-41%],3T=)0U]614-43U(@*#,Q($1/5TY43R P
M*3L-"@D)"61A=&$).B!)3B!35$1?3$]'24-?5D5#5$]2("@S,2!$3U=.5$\@
M,"D[#0H)"0ER9&%D9')E<W,).B!)3B!35$1?3$]'24-?5D5#5$]2("@W($1/
M5TY43R P*3L-"@D)"7=R861D<F5S<PDZ($E.(%-41%],3T=)0U]614-43U(@
M*#<@1$]73E1/(# I#0H)*3L-"@E%3D0@0T]-4$].14Y4.PT*#0HM+0EA='1R
M:6)U=&4@;F]O<'0Z(&)O;VQE86X[#0HM+0EA='1R:6)U=&4@;F]O<'0@;V8@
M86QT9&)R86TZ(&-O;7!O;F5N="!I<R!T<G5E.PT*#0IB96=I;@T*+2T)<2 @
M(" \/2!S=6)?=VER93 H,S$@1$]73E1/(# I.PT*#0H-"@EA;'1D<')A;5]C
M;VUP;VYE;G0@.B!A;'1D<')A;0T*"4=%3D5224,@34%0("@-"@D)5TE$5$@@
M/3X@,S(L#0H)"5=)1%1(040@/3X@."P-"@D)24Y$051!7U)%1R ]/B B54Y2
M14=)4U1%4D5$(BP-"@D)5U)!1$1215-37U)%1R ]/B B24Y#3$]#2R(L#0H)
M"5=20T].5%)/3%]214<@/3X@(DE.0TQ/0TLB+ T*"0E21$%$1%)%4U-?4D5'
M(#T^("))3D-,3T-+(BP-"@D)4D1#3TY44D],7U)%1R ]/B B24Y#3$]#2R(L
M#0H)"4]55$1!5$%?4D5'(#T^(")53E)%1TE35$52140B+ T*"0E)3D1!5$%?
M04-,4B ]/B B3T9&(BP-"@D)5U)!1$1215-37T%#3%(@/3X@(D]&1B(L#0H)
M"5=20T].5%)/3%]!0TQ2(#T^(")/1D8B+ T*"0E21$%$1%)%4U-?04-,4B ]
M/B B3T9&(BP-"@D)4D1#3TY44D],7T%#3%(@/3X@(D]&1B(L#0H)"4]55$1!
M5$%?04-,4B ]/B B3T9&(BP-"@D)3%!-7T9)3$4@/3X@(D,Z+W5S<B]C<'4O
M:F]P,R]R86TN;6EF(BP-"@D)3%!-7TA)3E0@/3X@(E5315]%04(]3TXB#0H)
M*0T*"5!/4E0@34%0("@-"@D)=W)E;B ]/B!W<F5N+ T*"0EI;F-L;V-K(#T^
M(&-L;V-K+ T*"0ED871A(#T^(&1A=&$L#0H)"7)D861D<F5S<R ]/B!R9&%D
M9')E<W,L#0H)"7=R861D<F5S<R ]/B!W<F%D9')E<W,L#0HM+0D)<2 ]/B!S
E=6)?=VER93 -"@D)<2 ]/B!Q#0H)*3L-"@T*96YD(')T;#L-"@``
`
end
Article: 33587Take a look at: http://www.chameleonsystems.com/what/RCP_Product_Brief.pdf Reiner Hartenstein wrote: > Hi, colleague, > > are there multi context FPGAs on the market > having 2 or 4 banks of configuration memory ? > > ReinerArticle: 33588
Can you give us any more detail as to the exact nature of the failures, and any back up you might have to substantiate it? Have you pinpointed the failures to specific nodes in a part, and then verified that that node still fails with a different test circuit designed specifically to exercise the 'bad' node? No trying to be a pain, but I've seen some pretty bad design in very expensive equipment over the years. Seems that the poorer the design, the more likely the designer is to blame the chip. There are an awful lot of mediocre designers out there, and they don't just inhabit garages (in fact, on average I'd venture to say that the small shops tend to crank out better designs...they tend to hire the cream of the crop). The fact that it fails on a chip tester as well as on the board just tells me that there is a problem with design you are putting in the FPGA to test it. Again, if the failure rates were even a 10th of what you are claiming, I would have expected to see a couple over my career, and would have expected a huge outcry here and in the press. "B. Joshua Rosen" wrote: > These failures occur both on board and on chiptesters. My client has > Xilinx prescreen FPGAs on a chiptester using a subset of my test patterns > (approximately 40 out of the 150). The fall out rate on the chiptester is > consistant to what we were seeing on boards before we were doing > prescreening. The screened parts have much lower on board failure rates > because the prescreening find about 90% of the bad parts. The full test > suite finds the remaining bad parts. The reason for not running the full > suite on the tester has to do with test time limitations. > > I can't post my methodology on the net, it's proprietary to my client. > However I have spent time with Xilinx's test group discussing my > techniques and they agree that they are sound. More to the point > Xilinx is using a similar strategy to test the Virtex parts. > > To answer your question about variable clock speeds, the clocks are PLL > based and designed to be variable. The clock tree's are extremely well > controlled and are not the source of any of these internal problems. The > systems that these FPGAs are in are million dollar ASIC emulators, they > are not garage shop kluges. Also I've been implementing variations of > these test patterns for multiple incarnations of the system going back to > 1994. The FPGAs that have been used are the 5212, 4013, 4036e, 4062xl and > the XCV800. The failure rates have been fairly consistant over the years > across the various generations of FPGAs, although I think that the rates > are somewhat lower for the Virtex parts. > > Josh > > In article <jSj97.8011$bl1.1229433@newsread1.prod.itd.earthlink.net>, > "Andy Peters <andy [@] exponentmedia" <".> wrote: > > > Josh, > > > > In addition to what Ray says, are you sure your printed-circuit boards > > are good? Have you done any sort of signal-integrity simulation on > > them? Since you indicate that you're changing your clock speeds, what > > sort of clock generator are you using? Do you have a proper > > clock-distribution tree on your boards? Please tell me your boards are > > not wire-wrapped. > > > > Just because you run at reduced clock speeds doesn't mean you don't have > > to worry about edge rates. > > > > How about your power-supply distribution? Decoupling? > > > > Are your parts socketed? > > > > Say, for instance, you worked for a commercial company, and you put an > > FPGA on a board, and you shipped 100,000 boards. This means that your > > customer service group would be dealing with 2,000 returned products. > > Methinks your manager would not only fire you, he'd shoot you in the > > face with a bazooka*. > > > > -andy > > > > * Thanks to Bill Cosby for the bazooka line. > > > > "B. Joshua Rosen" wrote: > >> > >> I've got these figures based on the tests that I have written for an > >> ASIC emulator company. Each box has hundreds of FPGAs so we would > >> typically find several bad FPGAs per system. I don't have exact figures > >> for the Virtex family, although they seem to be better than the 4000 > >> family, but the 1 in 50 number held for various incarnations of the > >> 5200 and 4000 series. My tests do not violate any timing restrictions, > >> in fact we run them at various clock rates and failures happen at the > >> lowest speeds as well as for the higher speeds. Before adding these > >> tests we would frequently run into problems with customer patterns, now > >> that's much much rarer although it can still happen occasionally. Even > >> with about 150 test patterns we are only getting coverage of 93% of the > >> PIPs, although the coverage of the PIPs that we actually use is > >> probably closer to 99%. Xilinx has added tests to their test suites > >> which use the same methodology as my tests and it does seem that the > >> Virtex parts have a lower fallout than the older families. I've also > >> used a Xilinx internal tool to determine what my coverage is. I could > >> be wrong about the chances of a particular pattern hitting a defect but > >> I'm not wrong about defect rate. With my test patterns I will generally > >> see 2 or 3 patterns fail on a bad part out of a suite of approximately > >> 150. However my patterns are designed for maximum coverage, it's > >> possible that a typical pattern has only a 1 on 500 chance of seeing > >> the defect as opposed to the 1 in 50 that I see. So if 1 in 50 parts > >> has a defect and 1 in 500 patterns hits it then you would see a 1 in > >> 25000 fallout in real systems. If my test patterns are closer to the > >> real world then the system fallout rate would be 1 in 2500. Either way > >> the system fallout rate is low enough that you wouldn't notice it. Also > >> without a test suite like I wrote for the emulator company you would > >> have no way of knowing that it was the FPGA that caused the problem, > >> the board will simply be declared a dog and tossed aside on the dog > >> board pile. > >> > >> In article <3B649C58.D09F96FC@andraka.com>, "Ray Andraka" > >> <ray@andraka.com> wrote: > >> > >> > Where are you getting these numbers from? My experience with FPGAs > >> > over the past 13 years and several hundred designs certainly doesn't > >> > support such numbers. Is it possible you might have been violating > >> > timing??? What devices were you testing? > >> > > >> > "B. Joshua Rosen" wrote: > >> > > >> >> Date codes don't matter it's really a random process that causes > >> >> problems. Having several boards is certainly useful in development > >> >> but you would probably do that anyway. As I say the chances of > >> >> actually hitting a problem are low, but if you go through 10 ro 20 > >> >> spins you will likely have a one in a few hundred chance of hitting > >> >> a defective switch. > >> >> > >> >> Josh > >> >> > >> >> In article <3B6477B1.575B@designtools.co.nz>, "Jim Granville" > >> >> <jim.granville@designtools.co.nz> wrote: > >> >> > >> >> > B. Joshua Rosen wrote: > >> >> >> > >> >> >> The coverage that the FPGA vendors provide is less than perfect > >> >> >> but it's good enough for most applications. In my experience, > >> >> >> writing FPGA test programs for an ASIC emulator manufacturer, > >> >> >> about 1 in 50 FPGAs have some defect although the chance of any > >> >> >> one pattern running into that defect is in the neighborhood of 1 > >> >> >> in 100. As a result the chance that any one pattern will have a > >> >> >> problem on any particular FPGA is about 1 in 5000. As you raise > >> >> >> the number of patterns that you run on a particular FPGA the > >> >> >> chances that you will run into a problem approached the 1 in 50 > >> >> >> number. > >> >> >> > >> >> >> The way that you test FPGAs is different then the way that you > >> >> >> test an ASIC. FPGAs are mostly interconnect which makes them > >> >> >> harder to test. On the other hand because they are soft you can > >> >> >> run an unlimited number of different test patterns on them, which > >> >> >> simplifies the problem as compared to an ASIC. If you are > >> >> >> concerned about shipping an FPGA with a hidden defect then the > >> >> >> way that you solve it is to run a large number of test patterns > >> >> >> on your FPGAs and throw out the bad ones. > >> >> > <snip> > >> >> > > >> >> > Very interesting stats. > >> >> > Besides shipping product, this also has issues for development > >> >> > itself. > >> >> > With a 1:50 chance of a defect, it would make sense to have two, > >> >> > or maybe three, (and probably with different date codes), test > >> >> > boards that are called on for second opinions when a curly fault > >> >> > arises. > >> >> > As these boards rack up more 'passes', they increase in value :-) > >> >> > > >> >> > Sounds like the tools could benefit from a 'randomise' switch > >> >> > - or maybe a start-from-other-corner placement alogrithm ? > >> >> > > >> >> > -jg > >> > > >> > -- > >> > -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 > >> > > >> > -- -Ray Andraka, P.E. President, the Andraka Consulting Group, Inc. 401/884-7930 Fax 401/884-7950 email ray@andraka.com http://www.andraka.comArticle: 33589
Sorry, just an administrative question. Could someone please tell me how to manually adjust the user info that appears at the bottom right-hand corner of a schematic diagram in the Xilinx Foundation software? AdrianArticle: 33590
For a saturating adder, sign extend the inputs by one bit more than you need for
your output, then if the top two output bits don't match you substitute the
overflow value. The Xilinx 4K was neat because with the carry chain in front of
the logic, you could include the mux in the adder logic to get the whole thing in
1 lut per bit. Here is an RTL version that avoids having to construct the whole
thing. I just typed this out, and it has not been tested so use at your own
risk. Incidently, there are times when a structural construction is
advantageous: it allows you to put placement in your code, and can also be used
to enforce a specific structure. The synthesis tools do fine with basic adders,
subtractors and counters. They can be more troublesome when you try to add
functions (for example an adder/subtractor with one input gated), in that the
synthesis may not turn out the optimal solution.
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity sat_add is
port(
a: in std_logic_vector;
b: in std_logic_vector;
s: out std_logic_vector);
constant width:natural:=s'length;
end sat_add;
architecture rtl of sat_add is
signal aext:signed(width downto 0);
signal bext:signed(width downto 0);
signal lcl_sum:std_logic_vector(width downto 0);
signal limit:std_logic_vector(width-1 downto 0);
begin
aext<= resize(signed(a),width+1);
bext<=resize(signed(b),width+1);
lcl_sum<= std_logic_vector(aext+bext);
limit<= (others=> lcl_sum(width);
s<= lcl_sum(width-1 downto 0) when lcl_sum(width)=lcl_sum_width-1 else limit;
end rtl;
Russell Shaw wrote:
> But how do you do a normal add while getting access to the right
> carry bits?
>
> John_H wrote:
> >
> > You're trying to do all the work for the synthesizer by telling it how to
> > perform addition.
> > Let the synthesizer to the addition - you just concentrate on the saturable
> > aspect.
> > Leonardo spectrum should get all the carry chains together fine because it
> > know how to utilize them to add.
> >
> > Russell Shaw wrote:
> >
> > > Hi all,
> > >
> > > I made this saturable adder from converting AHDL code in a previous
> > > message.
> > >
> > > It adds signed HEX numbers together, but doesn't roll-over if there's
> > > an overflow.
> > >
> > > I'm using leonardo-spectrum to generate an edif netlist, which is
> > > compiled by altera maxplus2.
> > >
> > > Where and how, if any, can i add technology-dependent optimizations
> > > such as carry chains etc?
> > >
> > > Also, are there such things as VHDL debuggers where you can single-
> > > step thru the code and see what all the signals and variables are
> > > doing?
> > >
> > > LIBRARY ieee;
> > > USE ieee.std_logic_1164.all;
> > >
> > > PACKAGE types IS
> > > subtype word is std_ulogic_vector(3 downto 0);
> > > END types;
> > >
> > > LIBRARY ieee;
> > > USE ieee.std_logic_1164.all;
> > > use work.types.all;
> > >
> > > ENTITY saturable_adder IS
> > > port(
> > > a,b: in word;
> > > s: out word
> > > );
> > > END adder;
> > >
> > > LIBRARY ieee;
> > > USE ieee.std_logic_1164.all;
> > > use work.types.all;
> > >
> > > ARCHITECTURE total OF saturable_adder IS
> > > BEGIN
> > > behav: PROCESS (a,b) is
> > > variable sum: word;
> > > variable carry_in,carry_out: std_ulogic;
> > > constant msb:integer:=word'left;
> > >
> > > BEGIN
> > > carry_in:='0';
> > > for ndx in 0 to (word'left-1) loop
> > > sum(ndx):=a(ndx) xor b(ndx) xor carry_in;
> > > carry_out:=(a(ndx) and b(ndx)) or (a(ndx) and carry_in) or (b(ndx)
> > > and carry_in);
> > > carry_in:=carry_out;
> > > end loop;
> > > sum(msb):=a(msb) xor b(msb) xor carry_in;
> > > if( (a(msb) and b(msb) and not carry_in)='1' )
> > > then
> > > sum:=(others=>'0');
> > > sum(msb):='1';
> > > elsif( (not a(msb) and not b(msb) and carry_in)='1' )
> > > then
> > > sum:=(others=>'1');
> > > sum(msb):='0';
> > > end if;
> > > s<=sum;
> > > END PROCESS behav;
> > > END total;
> > >
>
> --
> ___ ___
> / /\ / /\
> / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\
> /__/ / Victoria, Australia, Down-Under /__/\/\/
> \ \ / http://home.iprimus.com.au/rjshaw \ \/\/
> \__\/ \__\/
--
-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
Article: 33591
After some more try I got it. It was wrong to use altdpram.
Using lpm_ram_dp instead solves the problem.
Now I got rid of those .tdf files and ready to move to Xilinx...
But, oach: I read in the data sheet that it's not possible to use
the block RAM with unregistered din or unregistered rdaddress!
So I've to change my whole design :-(
Martin
--
Whant to see the evolution of a Java processor?
http://www.jopdesign.com
The solution to Altera rams in Leonardo:
--
-- aram.vhd
--
-- internal memory for JOP3
-- Version for Altera
--
--
Library IEEE ;
use IEEE.std_logic_1164.all ;
use IEEE.std_logic_arith.all ;
use IEEE.std_logic_unsigned.all ;
entity ram is
generic (width : integer := 32; addr_width : integer := 8);
port (
data : in std_logic_vector(width-1 downto 0);
wraddress : in std_logic_vector(addr_width-1 downto 0);
rdaddress : in std_logic_vector(addr_width-1 downto 0);
wren : in std_logic;
clock : in std_logic;
q : out std_logic_vector(width-1 downto 0)
);
end ram ;
--
-- registered wraddress, wren
-- unregistered din
-- registered rdaddress
-- unregistered dout
--
architecture rtl of ram is
COMPONENT lpm_ram_dp
GENERIC (LPM_WIDTH: POSITIVE;
LPM_WIDTHAD: POSITIVE;
LPM_NUMWORDS: NATURAL := 0;
LPM_TYPE: STRING := "LPM_RAM_DP";
LPM_INDATA: STRING := "REGISTERED";
LPM_OUTDATA: STRING := "REGISTERED";
LPM_RDADDRESS_CONTROL: STRING := "REGISTERED";
LPM_WRADDRESS_CONTROL: STRING := "REGISTERED";
LPM_FILE: STRING := "UNUSED";
LPM_HINT: STRING := "UNUSED"
);
PORT (rdaddress, wraddress: IN STD_LOGIC_VECTOR(LPM_WIDTHAD-1 DOWNTO 0);
rdclock, wrclock: IN STD_LOGIC := '1';
rden, rdclken, wrclken: IN STD_LOGIC := '1';
wren: IN STD_LOGIC;
data: IN STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0);
q: OUT STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0));
END COMPONENT;
begin
cmp_ram: component lpm_ram_dp
generic map (
LPM_WIDTH => width,
LPM_WIDTHAD => addr_width,
LPM_NUMWORDS => 2**addr_width,
LPM_TYPE => "LPM_RAM_DP",
LPM_INDATA => "UNREGISTERED",
LPM_OUTDATA => "UNREGISTERED",
LPM_RDADDRESS_CONTROL => "REGISTERED",
LPM_WRADDRESS_CONTROL => "REGISTERED",
LPM_FILE => "C:/usr/cpu/jop3/ram.mif",
LPM_HINT => "USE_EAB=ON")
port map (
rdaddress => rdaddress,
wraddress => wraddress,
data => data,
rdclock => clock,
wrclock => clock,
wren => wren,
q => q
);
end rtl;
Article: 33592
"Dave Feustel" <dfeustel@mindspring.com> writes:
> PACT offers 80 Pentium4s on a 100Mhz chip
No they don't. The thing would need a power station to run it for starters.
They have something capable of a number of calculations per second
which might be equivalent to what 80 P4s could be kept busy doing.
Same sort of thing as Xilinx's 800 GigaFlop (or something like that)
Virtex configuration.
Jon
Article: 33593Ray I shouldn't dignify this with a response since you are clearly talking about a subject that you know nothing about. However for everyone elses benefit I'll give more detail about the nature of the failures that we see. We run these tests on approximately 30,000 FPGAs a year. Prior to prescreening we were seeing a fall out rate of about 1 in 50. The reports that we get back form Xilinx on the screened parts are consistant with that number. The nature of the failure is that a bad part will fail 2 or 3 patterns out of a total of about 150. We can't identify a particular node because the tests are designed to give a go/no go answer. However we can generally determine which half of the FPGA failed because all of the tests are part of a pair, each member testing approximately 50% of the CLBs. It's clear that the defects are very small, maybe as small as a single gate. Bad parts mostly work, i.e. out of 150 patterns they will pass 147 or 148. The clock speed range is 12Mhz to 30Mhz. The designs are completely syncronous and there are no gated clocks. Parts that fail will generally fail at all clock speeds so you can see it's not a timing problem. It should be obvious that a design that can't run at 12Mhz on one part is unlikely to run at 30Mhz on the remaining 400 parts in the system, but of course they do run on the remaining parts because there are no timing problems in the designs. The reason that you haven't seen these problems is because you aren't looking. We only knew that there was a problem because we were getting reports from the field about failures. The nature of ASIC emulators makes it's possible to identify the source of a problem by shuffling the patterns between different FPGAs. The field guys were then able to identify the bad FPGAs. After we realized that there was a problem we developed these test patterns. Now field failures are much much less frequent, although they aren't zero because our coverage isn't 100%. n article <3B66ABD1.D878B8B7@andraka.com>, "Ray Andraka" <ray@andraka.com> wrote: > Can you give us any more detail as to the exact nature of the failures, > and any back up you might have to substantiate it? Have you pinpointed > the failures to specific nodes in a part, and then verified that that > node still fails with a different test circuit designed specifically to > exercise the 'bad' node? No trying to be a pain, but I've seen some > pretty bad design in very expensive equipment over the years. Seems > that the poorer the design, the more likely the designer is to blame the > chip. There are an awful lot of mediocre designers out there, and they > don't just inhabit garages (in fact, on average I'd venture to say that > the small shops tend to crank out better designs...they tend to hire the > cream of the crop). The fact that it fails on a chip tester as well as > on the board just tells me that there is a problem with design you are > putting in the FPGA to test it. Again, if the failure rates were even a > 10th of what you are claiming, I would have expected to see a couple > over my career, and would have expected a huge outcry here and in the > press. > > "B. Joshua Rosen" wrote: > >Article: 33594
In article <996585039.510644@turtle.ru.ac.za>, g9731642@campus.ru.ac.za says... > Sorry, just an administrative question. Could someone please tell me how to > manually adjust the user info that appears at the bottom right-hand corner > of a schematic diagram in the Xilinx Foundation software? > > Adrian > > Under File -> Edit Table Entry .. -- Falser Klaus R&D Electronics Department Company : Durst Phototechnik AG Vittorio Veneto Str. 59 I-39042 Brixen Voice : +0472/810235 : +0472/810111 FAX : +0472/830980 Email : kfalser@IHATESPAMdurst.itArticle: 33595
Rick Collins wrote: > cyber_spook wrote: > > > > Hi, > > > > Rick Filipkiewicz wrote: > > > > > My conclusion from this small sample is that the P&R tool speed is > > > dominated by memory performance. > > > > With this type of application (memory hugary!) the speed of the CPU is only > > any good when it has the data to process. In other words a 450, 600 or 1.4 > > will just spend most of its time sitting on its "bum" waiting for memory. > > > > This was proven when Cambridge Uni fitted 4Gb of SRAM (not DRAM) to a 40Mhz > > 386DX - Was the fastest thing you have ever seen!! > > > > Cyber_Spook_Man > > I find this hard to believe. I don't doubt that the general rule for > memory is faster is better. But I don't think a 40 MHz 386 will outrun a > 1 GHz anything just because the 386 is running in zero wait state > memory. I also find it hard to believe you can fit 4 Gb of SRAM to a > processor without slowing down the SRAM. That is a lot of memory, about > 512 chips (assuming the Gb means gigabits, not gigabytes)!!! > Sorry - was not compairing a 386 to a 1Ghz PC of today, Its just that Cambridge produced a machine that ran faster than anything else around - was for simulation software or somthing?Article: 33596
"Dick Ginther" <dick.ginther@wavecom.ca> wrote in message news:<r3j97.20$7i.589926@tomcat.sk.sympatico.ca>... > Hi, > I'm looking for some open source for a i2c bus master...does anyone > know of some? > Thanks. Xilinx XAPP333: CoolRunner XPLA3 I2C Bus Controller Implementation http://www.xilinx.com/xapp/xapp333.pdf ???Article: 33597
This is a multi-part message in MIME format. --------------701C5CCA47202106778BECF1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Check out the I2C Xilinx reference design: http://www.xilinx.com/xapp/xapp333.pdf Ingmar Hohmann wrote: > Have a look to: > > http://www.opencores.org/projects.shtml > > By Ingmar > > Dick Ginther schrieb: > > > Hi, > > I'm looking for some open source for a i2c bus master...does anyone > > know of some? > > Thanks. > > -- > ___________________________________________________________________ > > Ingmar Hohmann mailto:ih@seh.de > SEH Computertechnik GmbH http://www.seh.de > Suedring 11 Fax: +49 521 94226 99 > D-33647 Bielefeld Phone:+49 521 94226 63 > GERMANY > __________________________________________________________________ --------------701C5CCA47202106778BECF1 Content-Type: text/x-vcard; charset=us-ascii; name="jennifer.jenkins.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Jennifer Jenkins Content-Disposition: attachment; filename="jennifer.jenkins.vcf" begin:vcard n:Jenkins;Jennifer tel;fax:(505) 858-3106 tel;work:(505) 798-4813 x-mozilla-html:FALSE url:http://www.xilinx.com org:Xilinx CoolRunner CPLDs;<br><img src="http://www.xilinx.com/images/xlogoc.gif" alt="Xilinx"> adr:;;7801 Jefferson St. NE;Albuquerque;New Mexico;87109; version:2.1 email;internet:Jennifer.Jenkins@xilinx.com title:Applications Engineer fn:Jennifer Jenkins end:vcard --------------701C5CCA47202106778BECF1--Article: 33598
The Virtex BlockRAM operates synchronously, even in read mode. It thus differs from a traditional old RAM where the read operation used to be combinatorial. So you need a read clock for Virtex BlockRAMs, but you also get all the advantages of fully synchronous operation. For example, you can use the output data as the next address, without incurring a race condition. Note that the read-while-you write operation has only one flavor in Virtex and Virtex-E ( you always see at the read port the data you just wrote), but in Virtex-II you have three choices ( by configuration): 1. Read before write, i.e. read the old content that is now being overwritten 2. Write before read, i.e. read the new data ( like in Virtex and Virtex-E) 3. Don't change the data output, i.e. keep it constant until you do a real read operation. Herzlich willkommen bei Xilinx ! Peter Alfke, Xilinx Applications ============================== Martin Schoeberl wrote: > After some more try I got it. It was wrong to use altdpram. > Using lpm_ram_dp instead solves the problem. > Now I got rid of those .tdf files and ready to move to Xilinx... > But, oach: I read in the data sheet that it's not possible to use > the block RAM with unregistered din or unregistered rdaddress! > So I've to change my whole design :-( > > Martin > -- > Whant to see the evolution of a Java processor? > > http://www.jopdesign.com > > The solution to Altera rams in Leonardo: > > -- > -- aram.vhd > -- > -- internal memory for JOP3 > -- Version for Altera > -- > -- > > Library IEEE ; > use IEEE.std_logic_1164.all ; > use IEEE.std_logic_arith.all ; > use IEEE.std_logic_unsigned.all ; > > entity ram is > generic (width : integer := 32; addr_width : integer := 8); > port ( > data : in std_logic_vector(width-1 downto 0); > wraddress : in std_logic_vector(addr_width-1 downto 0); > rdaddress : in std_logic_vector(addr_width-1 downto 0); > wren : in std_logic; > clock : in std_logic; > > q : out std_logic_vector(width-1 downto 0) > ); > end ram ; > > -- > -- registered wraddress, wren > -- unregistered din > -- registered rdaddress > -- unregistered dout > -- > architecture rtl of ram is > > COMPONENT lpm_ram_dp > GENERIC (LPM_WIDTH: POSITIVE; > LPM_WIDTHAD: POSITIVE; > LPM_NUMWORDS: NATURAL := 0; > LPM_TYPE: STRING := "LPM_RAM_DP"; > LPM_INDATA: STRING := "REGISTERED"; > LPM_OUTDATA: STRING := "REGISTERED"; > LPM_RDADDRESS_CONTROL: STRING := "REGISTERED"; > LPM_WRADDRESS_CONTROL: STRING := "REGISTERED"; > LPM_FILE: STRING := "UNUSED"; > LPM_HINT: STRING := "UNUSED" > ); > PORT (rdaddress, wraddress: IN STD_LOGIC_VECTOR(LPM_WIDTHAD-1 DOWNTO 0); > rdclock, wrclock: IN STD_LOGIC := '1'; > rden, rdclken, wrclken: IN STD_LOGIC := '1'; > wren: IN STD_LOGIC; > data: IN STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0); > q: OUT STD_LOGIC_VECTOR(LPM_WIDTH-1 DOWNTO 0)); > END COMPONENT; > > begin > > cmp_ram: component lpm_ram_dp > generic map ( > LPM_WIDTH => width, > LPM_WIDTHAD => addr_width, > LPM_NUMWORDS => 2**addr_width, > LPM_TYPE => "LPM_RAM_DP", > LPM_INDATA => "UNREGISTERED", > LPM_OUTDATA => "UNREGISTERED", > LPM_RDADDRESS_CONTROL => "REGISTERED", > LPM_WRADDRESS_CONTROL => "REGISTERED", > LPM_FILE => "C:/usr/cpu/jop3/ram.mif", > LPM_HINT => "USE_EAB=ON") > port map ( > rdaddress => rdaddress, > wraddress => wraddress, > data => data, > rdclock => clock, > wrclock => clock, > wren => wren, > q => q > ); > > end rtl;Article: 33599
heya, This year, I got my Bachelor in computer science. i wanted to undertake a PhD in the fielld of FPGA, but i have been refused even that i have my degree with a mark of 65%. when i asked the boss there, he told me this is a computer engineering department and not computer science, i can't accepet you even if you got 90%!!!! i have decided to join a software company, but still wondering on what he means, what is the differences between computer science and computer engineering ? Edgar 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