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
Hi, I'm migrating a Virtex-E design with the Xilinx PCI core into a Virtex2 device. I'm using the newest Virtex2 PCI core (V.3.0.069) and am running into a mapper problem. The mapper errors out with the following message: Release 3.3.08i - Map D.27 Copyright (c) 1995-2000 Xilinx, Inc. All rights reserved. Using target part "2v1000bg575-4". Reading NGD file "sib_top.ngd"... Processing FMAPs... Removing unused or disabled logic... Running cover... ERROR:MapLib:270 - Virtex PCILOGIC macro PCILOGIC symbol "PCI_CORE/PCI_LC/OUT_CE/MAGICBOX" (output signal=PCI_CORE/PCI_LC/OUT_CE/HARD_CE) is an invalid component in Virtex2 architecture. Errors found during the mapping phase. Output files will not be written. The HARD_CE signal lives in the pci_lc_i.v and .ngo files. What is the solution for this? Thanks, Doug WilsonArticle: 33601
Ouch, Joshua. You just insulted one of the ikons of this newsgroup. That's a double no-no: First, we try to be polite here Secondly, we all have a tremendous respect for Ray Andraka and don't tolerate him being insulted. Go and wash your mouth. With soap... Peter Alfke "B. Joshua Rosen" wrote: > Ray 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: 33602
Hello Noddy, That option can be found under "File --> Table Setup". Best regards, Kamal Patel Noddy wrote: > 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: 33603
Whoops, I guess that should have been addressed to you Adrian not "Noddy". My apologies. -Kamal Noddy wrote: > 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: 33604
I simply want to use the Length Count value within the bitstream to
determine exactly how many bits need to be clocked in to fully program
the device. I've thoroughly searched this group and Xilinx support
for a clear explanation of the Length Count field, but I have yet to
find a satisfactory explanation on the true meaning of Length Count.
For an XCS30XL running in Slave Serial mode, BitGen calculates a
Length Count value of 249161. This value places the "end" of the
bitstream 2 bits beyond the Postamble. I would expect Length Count to
be either 249159 (number of bits from start to end of Postamble) or
249163 (add 4 bits for Start-Up phase). What is the purpose of this 2
bit difference?
There is a support question (Answer Record #7912) that explains
how the Length Count is calculated by BitGen, but it raises even more
questions. It states that the Length Count value = (PROM size - 7).
Why subtract 7? Why derive Length Count from the PROM size at all
(the PROM size includes an unknown quantity of fill bits!)? The
calculation presented does indeed match my bitstream file contents.
However, since the Length Count value does not have any useful
relationship to the actual number of configuration bits (due to the
unknown number of fill bits), it cannot be used by a microprocessor to
clock in the correct number of bits! The only solution that I see is
to add some arbitrary number (7 would probably make the most sense) to
Length Count to ensure that "enough" bits are clocked in. This seems
like such a hack.
Does anybody know why Xilinx doesn't simply set Length Count equal
to the exact number of bits necessary to completely program the
device? Or 4 more (for the Start-Up phase)? This would seem to make
so much more sense!
Article: 33605Hi Doug, You need to make a change to your cfg.v or cfg.vhd file. Specifically, you need to set bit 251 (towards the end of the file) to logic one instead of logic zero. The implementation guide shipped with the product discusses the implementation of the output datapath clock enables in the core. This is in the "Family Specific Considerations" chapter. There are two options for the output clock enable, one is generated by LUTs and the other by the PCILOGIC. Which one is used is selected by bit 251 of the configuration file. In Virtex and Virtex-E, either option is appropriate. For high speed operation you will find that the PCILOGIC is a better choice. However, there are only two PCILOGICs per device, one on the left side and one on the right. For example, if you wanted four cores in a V2000E device, only two of them could use the PCILOGICs and the other two would have to use the LUT option... In Virtex-II, only the LUT option is appropriate because the same PCILOGIC resource does not exist in this architecture. Hope this helps, Eric Doug Wilson wrote: > > Hi, > > I'm migrating a Virtex-E design with the Xilinx PCI core into > a Virtex2 device. I'm using the newest Virtex2 PCI core (V.3.0.069) > and am running into a mapper problem. The mapper errors out with > the following message: > > Release 3.3.08i - Map D.27 Copyright (c) 1995-2000 Xilinx, Inc. > Using target part "2v1000bg575-4". Reading NGD file "sib_top.ngd"... > Processing FMAPs... > Removing unused or disabled logic... > Running cover... > ERROR:MapLib:270 - Virtex PCILOGIC macro PCILOGIC symbol > "PCI_CORE/PCI_LC/OUT_CE/MAGICBOX" (output signal=PCI_CORE/PCI_LC/OUT_CE/HARD_CE) > is an invalid component in Virtex2 architecture. > Errors found during the mapping phase. Output files will not be written.Article: 33606
Hello, I am having trouble programming an Altera EPC16 via JTAG. Has anyone successfully programmed this part yet? Details: Using Quartus II version 1.0 Service Pack 2 Trying the program the EPC16 using Quartus via a ByteBlasterMV (JTAG mode) Using a .pof file generated by Quartus (converted .sof file to .pof) Part is wired per Figure 11 of the EPC16 datasheet. Symptoms: In the programmer, I can Examine and Blank Check the part correctly, but when I select Program, the message "Programming failed" is generated and the status bar does not move from 0%. Any help / info would be appreciated. Thanks, Mike Mellone m-mellone@raytheon.comArticle: 33607
Hi all, does anyone have more detailed information than those available on A´s website about their MPLD service? Rumours are welcome as well... I would like to know something more about this, such as: - Time schedule for this service - Price informations - Minimum ordering quantity - Will there be conversions from Apex devices or is A waiting for their new Apex II....? - Did anyone try this service? - Is there really no need to provide test vectors (the website says) - What strategy could be behind this service? What target market A want to cover with MPLD? -- Thanks! cu AxelArticle: 33608
Martin Schoeberl wrote:
>
> 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.
>
Something like code below should work for leo.
--Mike Treseler
-------------------------------------------------------------------------------
-- Exemplar Infers lpm_ram_dq synchronous ram from this code
-- No exemplar libraries required, generic size
-- M. Treseler 6-13-2001
-------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity sync_ram is
generic (width : natural := 16;
add_length : natural := 3
);
port ( clk : in std_logic;
data : in std_logic_vector(width-1 downto 0);
address : in std_logic_vector(add_length-1 downto 0);
we : in std_logic;
q : out std_logic_vector(width-1 downto 0)
);
end sync_ram;
architecture synth of sync_ram is
constant mem_size : natural := 2**add_length;
type mem_type is array (mem_size-1 downto 0) of
std_logic_vector (width-1 downto 0);
signal mem : mem_type;
signal address_q : std_logic_vector (add_length-1 downto 0);
begin
ram_write : process (clk)
begin
if clk'event and clk = '1' then
always_adr_sync : address_q <= address;
maybe_write : if we = '1' then
mem(to_integer(unsigned(address))) <= data;
end if;
end if;
end process ram_write;
always_ram_read:
q <= mem(to_integer(unsigned(address_q)));
end architecture synth;
Article: 33609"B. Joshua Rosen" wrote: > > Ray 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%. Josh, First, I still think if we saw error counts as high as you describe, there'd be an uproar. Second, JUST BECAUSE THE SYSTEM IS DESIGNED TO RUN AT "ONLY" 30 MHZ DOES NOT MEAN YOU DO NOT HAVE A SIGNAL-INTEGRITY PROBLEM. Read the Johnson book. It's the edge rates that get you, not the clock speed. Third, to repeat, perhaps you do have a PCB design problem. If you've got "lots" of FPGAs talking to each other, I hope you've thought about chip-to-chip routing, clock-tree distribution (skew between FPGA clocks will eat your setup time for lunch), all that good stuff. If you've got a large board (and sounds like you do), and your clock is distributed from one corner, you could have problems if you haven't made sure all clock line lengths are equal. -andyArticle: 33610
pound_euro@altavista.com (edgar) writes: > 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, He means that you have to put up with typical bullshit rules that educational institutions like to use to hassle you. In this case it probably means that you have to at least have a minor in EE. But I'm just guessing. If they can't be flexible enough to allow you some alternate way to qualify, it's not clear that you would want to attend that institution anyhow. > what is the differences between computer science and computer > engineering ? I'm not sure in terms of formal definitions, but typically CE involves more EE work.Article: 33611
Not to worry, I've taken much worse. I'm trying to be open here, as Joshua has clearly seen some sort of problem (be it a silicon problem or a design problem). I'm interested in his input, and specifically the conditions under which he sees these failures. I haven't seen failures to date, and based on his claimed failure levels, the density of my typical designs, and the number of designs in the field, I would expect to have seen at least a few. I am sure some defects do get out the door, but based on my experience, I suspect the frequency of occurence is nowhere near as high as he asserts. Perhaps he is using a feature in the FPGA I don't use much (like tbufs for example), or perhaps he is causing the errors with his method...for example a column containing an SRL16 and CLB RAM cannot be read back while the chip is being clocked even if the WE for that element is low because of a silicon bug that can cause a the configuration to be locally corrupted (this isn't well documented, but it is a problem we've encountered during radiation testing and that has been confirmed by xilinx). Maybe he is using the DLL for both 1x and 2x clocks and transferring the data between the domains on the same aligned edge (data book says that's OK, but we've seen problems where unequal loading of the clock trees has introduced enough skew to make a direct transfer between the clock0 and clk2x domains unreliable--and that does not change with clock frequency but will work in some parts and not in others and will work at some locations but not others on the chip). Since he is unwilling to share his test method and does not know the details of the failure mode, we can't evaluate the basis of his claim and we can't learn from his experience. It would be nice if he could be more specific as to the exact nature of the problem so that others can benefit from his experience. Unfortunately, it appears that he does not have enough curiousity, know-how and/or expertise to narrow down the specific failure(s) once they were discovered. It may be tedious work, but the end result is usually very beneficial for a) providing constructive feedback to the manufacturer and b) learning what to avoid in your designs to avoid the failure even if the parts are defective. Yelling to the world "these parts really bite" without some back up or at least some specifics serves no purpose whatsoever, and in fact can have a very poisoning effect. Peter Alfke wrote: > Ouch, Joshua. > You just insulted one of the ikons of this newsgroup. > That's a double no-no: > First, we try to be polite here > Secondly, we all have a tremendous respect for Ray Andraka and don't tolerate > him being insulted. > Go and wash your mouth. With soap... > > Peter Alfke > > "B. Joshua Rosen" wrote: > > > Ray 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: > > > > > > -- -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: 33612
edgar wrote: > 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 Computer science = a discipline invented in the 1970s to provide work for otherwise unemployable academics (and they came up with Lisp ?). Computer engineering = making real, physical,computers work well enough that people will pay good money for them.Article: 33613
Computer engineering, is usually a digital hardware degree, where computer science is software. FPGAs require digital hardware design skills, which is not what is taught under a computer science degree. You've probably got alot of ground to cover in undergrad level courses before you are ready to pursue a doctorate in what is essentially a specific field of digital design. A grade of 65% is a 'D' here in the states, which is to say a rather poor showing. Even if you had the right background, your grades may not be high enough to be accepted. edgar wrote: > 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 -- -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: 33614
<ray@andraka.com> wrote: > > No trying to be a pain, but I've seen some > > pretty bad design in very expensive equipment over the years. B. Joshua Rosen wrote: > > Ray I shouldn't dignify this with a response since you are clearly > talking about a subject that you know nothing about. Whoa guys, settle down..! The subject is very interesting, don't fall into the 'shoot the messenger' trap. This type of problem will be often missed, or taken as something else. IIRC, Josh did say he fed the info back to Xilinx, and it seems they have changed/improved their testing coverage as a result. That's both significant, and a step forward. Test coverage is a time/cost tradeoff, but there are interesting points that come from using a finite defect device. eg it means a field upgrade needs care, and may not work 100.0% of the time. ( if the thing is in orbit, that's something of a problem :) It also suggests that a single Eval/development PCB is not a good idea, unless that FPGA has had the extra cost screening, or perhaps the designer is experienced enough to 'know' when it's a HW problem, not a SW one :-) Reminds me of a story I heard about Russian Microcontrollers - they were pushing the yield/fab envelope and every chip came with it's own 'functional opcode' list. Code written for that device, had to avoid the broken opcodes :-) This was many years before the 'errata' became more common practice. -jg B. Joshua Rosen wrote: > 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%.Article: 33615
Hi Ray, In principle, I agree with much of what you have said. On Tue, 31 Jul 2001 01:47:49 GMT, Ray Andraka <ray@andraka.com> wrote: > >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. > > Is there any way to take a modified verilog simulation file and put it back through to create a modified design? > >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) > I agree that much of the problem is with the designers at my customer. I cannot say for sure if all of the tools at their disposal are being correctly used. > >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). Some defects (such as gate oxide defects) are almost never the same on any given device. There are statistically some amount of random material defects in all processed semiconductor devices. As the die size increases, the chance of having a defect on a given die increases. > >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 have FAE from each manufacturer on site more days than not, and they have a weekly meeting with both manufacturers. They are a fairly large company, using easily over 200k units per month of FPGAs (EP10K, EP20K, XC4000XLA, Virtex, and VirtexE) The manufacturers have correlated some of the failures. Others have been traced to software problems, others not correlated. They are using plenty of good tools for board analysis (such as ASSET). Again I agree with what you are saying, and that this company is probably causing a high level of their own pain.Article: 33616
Though it is _not_ your typical FPGA, Chameleon Systems (www.chameleonsystems.com) offers a re-programmable device called a Reconfigurable Communications Processor (RCP) with two configuration planes. It looks like it's targeted at compute-heavy applications. I'm going by memory on this but there is a fairly detialed product brief at http://www.chameleonsystems.com/what/RCP_Product_Brief.pdf. Swapping contexts happens in a single clock, though they don't say how much instantaneous power this consumes. One additional feature that the Chameleon devices offer is dynamic interconnect. The routing to a specific logic function can be changed on a clock-by-clock basis. hartenst@rhrk.uni-kl.de (Reiner Hartenstein) wrote in message news:<a5a7222d.0107300945.151ab8d2@posting.google.com>... > Hi, colleague, > > are there multi context FPGAs on the market > having 2 or 4 banks of configuration memory ? > > ReinerArticle: 33617
Thanks Jim. To try and clarify things a little more. Most of the test patterns don't use any IO at all aside from a serial scan chain. These patterns are run both on boards and on chip testers. Also the boards involved have changed over the years. I have been doing these same style tests on five different generations of these products which have involved three completely different board designs and five different FPGAs. I'm also not accusing Xilinx of producing a "bad" product. The defects are very tiny, that's why it takes 150 different test patterns to find them. Generally a "bad" part will fail only one or two patterns out of the 150. Also these patterns use significantly more resources then the average design. The design goal is to use as much of the chip as possible in each test pattern. In case you are wondering how much of a Xilinx chip it is possible to use in one design, my worst case patterns use about 6% of the PIPs which is the highest number that the Xilinx test people have seen. For a regular design, i.e. something that was not designed to use the maximum number of PIPs, the number is probably closer to 1 or 2%. The utilization number that is reported by the Xilinx place and route tools is for things like CLBs and flip flops, not for interconnect. As you are all probably aware an FPGA is almost entirely interconnect, very little of it is actually usable logic. Thus a "90%" utilized part may be using only 2% of the resources. That's why it's possible for a part to have a bad pass gate on it and for most users to never see it. One more thing is that Xilinx does test these parts, and they do a pretty good job of covering the most commonly used resources, so the chance that a particular design will actually use the bad gate may be less than the 1%-2% that the PIP utilization would suggest. With that said the issue of field upgrades should be addressed. For most FPGA systems field upgrades are either impossible or are very infrequent. The application that I wrote these tests for was ASIC emulation where new patterns are being downloaded several times a day. For emulators a bad FPGA will make itself know in a fairly short time. For a board with one or two FPGAs that gets upgraded once in it's lifetime the chance that any particular board will fail after the upgrade may be as low as one in 10,000. For applications where upgrades are frequent the cost of doing the extra testing is well worth it, for applications where upgrades are rare the extra cost would outweigh the advantages. In article <3B672D71.78D0@designtools.co.nz>, "Jim Granville" <jim.granville@designtools.co.nz> wrote: > <ray@andraka.com> wrote: >> > No trying to be a pain, but I've seen some >> > pretty bad design in very expensive equipment over the years. > B. Joshua Rosen wrote: >> >> Ray I shouldn't dignify this with a response since you are clearly >> talking about a subject that you know nothing about. > > Whoa guys, settle down..! > > The subject is very interesting, don't fall into the 'shoot the > messenger' > trap. > > This type of problem will be often missed, or taken as something else. > > IIRC, Josh did say he fed the info back to Xilinx, and it seems > they have changed/improved their testing coverage as a result. > That's both significant, and a step forward. > > Test coverage is a time/cost tradeoff, but there are interesting points > that come from using a finite defect device. > eg it means a field upgrade needs care, and may not work 100.0% of the > time. > ( if the thing is in orbit, that's something of a problem :) > > It also suggests that a single Eval/development PCB is not a good idea, > unless that FPGA has had the extra cost screening, or perhaps the > designer > is experienced enough to 'know' when it's a HW problem, not a SW one :-) > > Reminds me of a story I heard about Russian Microcontrollers - they > were > pushing the yield/fab envelope and every chip came with it's own > 'functional opcode' list. Code written for that device, had to avoid the > broken opcodes :-) > This was many years before the 'errata' became more common practice. > > -jg > > B. Joshua Rosen wrote: >> 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%.Article: 33618
Rick Collins wrote:
> I am adding some code to a verilog design for debug and I need to access
> signals in a remote portion of the design. I have been told that there
> is a way to do this in the form of
> "top_level.mid_level.low_level.signal_name" where the level names are
> module instance names. This works ok in simulation, but I can't get it
> to work in synthesis. We are using Synplify. Is this not supported by
> this tool? Is this not supported by any synthesis tool?
hierarchical references are seldom, if ever used for synthesiss - you need
to bring those wires up and out the hard way I'm afraid.
Verilog hierarchical references are actually relative (even though most
people use them as absolute references which IMHO is the only close to safe
way to use them). Because synthesis is often done incrementally from the
bottom up hierarchical names that are anything other than relatively
downwards from where they are used are pretty much impossible to synthesize.
The searching rules use by the language to resolve them are not generally
well understood - and capable of dangerous, silent, changes when other
somewhat unrelated parts of the hierarchy change.
Consider the following example prints "1"
module a;
initial #1 $displayb(x.y);
endmodule
module x;
wire y = 1;
a x();
endmodule
But the following example prints "0" because the absolute is contextually
converted to a relative one:
module a;
wire y = 0;
initial #1 $displayb(x.y);
endmodule
module x;
wire y = 1;
a x();
endmodule
A simple set of rules to avoid evile relative hierarchical names:
- only use absolute references
- don't use the name of the top level model (say 'top')
anywhere else in the design
Article: 33619I an see where my comment might have been inflammatory. It was not intended to be so. I was merely making the observation that cost and size of company do not determine the quality of a design. Knowing nothing about this particular test suite I can't say whether or not there is a design fault. My experience causes me to be very skeptical when someone declares there is a chip problem, especially when there are claims of very high failure rates. Most of the time it turns out to be a problem with the design rather than the chip. If you look at your posts from an outsider's point of view, I am sure you'd reach the same conclusion. If the defects are of the order of magnitude Joshua indicates, there is need to worry, especially in designs like many of mine where we are taking some advantage of reconfiguration and depending on having a good device. I do realize the that large designs do not necessarily use many pips. In fact, for high performance designs, I try to minimize the number of pips crossed. Much of the routing is purposely to adjacent CLBs, which for the most part misses the majority of the pips in the chip. I'm probably using significantly LESS than the average number of used pips, so, I'll concede that my designs may not have hit a bad pip yet. Perhaps I have a lower probability of hitting a defect as a result. One thing that puzzles me is Joshua's comment that the error rates have remained pretty consistent over several generations of product. I would expect that as the device density increases and the feature size is decreased that the number of defects per chip would increase, not stay at some constant level. The constant error rate was part of what pointed me in the direction of a clock skew or signals integrity problem in the first place. Jim Granville wrote: > <ray@andraka.com> wrote: > > > No trying to be a pain, but I've seen some > > > pretty bad design in very expensive equipment over the years. > B. Joshua Rosen wrote: > > > > Ray I shouldn't dignify this with a response since you are clearly > > talking about a subject that you know nothing about. > > Whoa guys, settle down..! > > The subject is very interesting, don't fall into the 'shoot the > messenger' > trap. > > This type of problem will be often missed, or taken as something else. > > IIRC, Josh did say he fed the info back to Xilinx, and it seems > they have changed/improved their testing coverage as a result. > That's both significant, and a step forward. > > Test coverage is a time/cost tradeoff, but there are interesting points > that come from using a finite defect device. > eg it means a field upgrade needs care, and may not work 100.0% of the > time. > ( if the thing is in orbit, that's something of a problem :) It also means that you may have a yield fallout in a shipping product. > > > It also suggests that a single Eval/development PCB is not a good idea, > unless that FPGA has had the extra cost screening, or perhaps the > designer > is experienced enough to 'know' when it's a HW problem, not a SW one :-) > > Reminds me of a story I heard about Russian Microcontrollers - they > were > pushing the yield/fab envelope and every chip came with it's own > 'functional opcode' list. Code written for that device, had to avoid the > broken opcodes :-) > This was many years before the 'errata' became more common practice. > > -jg > > B. Joshua Rosen wrote: > > 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%. -- -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: 33620
Paul Smart wrote: > Hi Ray, > > In principle, I agree with much of what you have said. > > On Tue, 31 Jul 2001 01:47:49 GMT, Ray Andraka <ray@andraka.com> wrote: > > > > >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. > > > > > Is there any way to take a modified verilog simulation file and put it > back through to create a modified design? not any easy paths that I am aware of. You can remap the simprims into unisims, but it is a very painful process. Probably less work starting on a fresh design. > > > > > >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) > > > I agree that much of the problem is with the designers at my customer. > I cannot say for sure if all of the tools at their disposal are being > correctly used. > > > > >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). > > Some defects (such as gate oxide defects) are almost never the same > on any given device. There are statistically some amount of random > material defects in all processed semiconductor devices. As the die > size increases, the chance of having a defect on a given die > increases. Agreed. I was referring to designed in problems when I said a silicon bug...things like the SRL16, or the faulty parallel load configuration state machine on early XC4025E-2s. I am sure there are defects out there that passed thorugh the manufacturer's test. At issue is the percentage of fielded parts with silicon defects (not design bugs). Is there a number anyone can pin on the rate of substantiated defects? > > > > > >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 have FAE from each manufacturer on site more days than not, and > they have a weekly meeting with both manufacturers. They are a fairly > large company, using easily over 200k units per month of FPGAs (EP10K, > EP20K, XC4000XLA, Virtex, and VirtexE) > > The manufacturers have correlated some of the failures. Others have > been traced to software problems, others not correlated. They are > using plenty of good tools for board analysis (such as ASSET). So the manufacturers are heavily involved then. That is good. > > > Again I agree with what you are saying, and that this company is > probably causing a high level of their own pain. Thank you. ^^^^ -- -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: 33621
Hi ! I designed Xilinx project - 1000000 gates(Virtex). I want to convert this project to ASIC. 1.I know that Xilinx have way to automatic convert FPGA to ASIC. Who try this method? What about advantages of this method ? 2.Who know information about translation Xilinx EDIF file to ASIC ? I used AutoLogic for this, but now it was dead. Thanks AlexanderArticle: 33622
Mike Treseler wrote: > > Martin Schoeberl wrote: > > > > 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. > > > > Something like code below should work for leo. > --Mike Treseler > > ------------------------------------------------------------------------------- > -- Exemplar Infers lpm_ram_dq synchronous ram from this code How does leonardo know? Is it just because a large array of words is declared? > -- No exemplar libraries required, generic size > -- M. Treseler 6-13-2001 > ------------------------------------------------------------------------------- > library ieee; > use ieee.std_logic_1164.all; > use ieee.numeric_std.all; > > entity sync_ram is... -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 33623
Have you got any neccessary pull-up resistors connected? IIRC, one or two outputs are open-drain. There's some pdfs at altera saying what the connections should be. Michael Mellone wrote: > > Hello, > I am having trouble programming an Altera EPC16 via JTAG. Has anyone > successfully > programmed this part yet? > > Details: > Using Quartus II version 1.0 Service Pack 2 > Trying the program the EPC16 using Quartus via a ByteBlasterMV (JTAG > mode) > Using a .pof file generated by Quartus (converted .sof file to .pof) > Part is wired per Figure 11 of the EPC16 datasheet. > > Symptoms: In the programmer, I can Examine and Blank Check the part > correctly, > but when I select Program, the message "Programming failed" is generated > and the > status bar does not move from 0%. > > Any help / info would be appreciated. > > Thanks, > Mike Mellone > m-mellone@raytheon.com -- ___ ___ / /\ / /\ / /__\ Russell Shaw, B.Eng, M.Eng(Research) / /\/\ /__/ / Victoria, Australia, Down-Under /__/\/\/ \ \ / http://home.iprimus.com.au/rjshaw \ \/\/ \__\/ \__\/Article: 33624
Srinivasan Venkataramanan wrote: > Hi, > Try the one from XESS, kind-of-beginner's guide. > > HTH, > Srini > > http://www.xess.com/appnotes/webpack-1_5.pdf That's very old. Try the newer one for WebPACK 3.1: http://www.xess.com/appnotes/webpack-3_1.pdf Even this one is a bit too old since it only covers CPLDs, but it does show the design flow. -- || Dr. Dave Van den Bout XESS Corp. (919) 387-0076 || || devb@xess.com 2608 Sweetgum Dr. (800) 549-9377 || || http://www.xess.com Apex, NC 27502 USA FAX:(919) 387-1302 ||
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