Xilinx/Altera "behavioral" verilog 
Author Message
 Xilinx/Altera "behavioral" verilog

Hi All,

I was wondering if anyone can shed some light on this:

The Xilinx and Altera tools seem to produce a behavi{*filter*}verilog file
for simulation. Is there any way I can get a structural verilog file?

There are some (ASIC) tools I want to use with these files that only
support structural verilog (the tools are for ATPG, DFT, and fault
simulation (ultimate goal is device testing)). Examples of this type
of tool are:
  - IBM: TestBench (DFT, ATPG)
  - Synopsys: DFT Compiler and TetraMax ATPG

Is this something that Xilinx or Altera will  provide someday?

I know a lot of ASIC related tools cannot work with current FPGA
design methodologies, but do we really expect to work with multi
million gate FPGAs without access to DFT, ATPG, and fault simulation
tools as are used in the  ASIC world?

Thanks for your time,
Paul



Wed, 14 Jan 2004 01:00:25 GMT  
 Xilinx/Altera "behavioral" verilog

Quote:

> Hi All,

> I was wondering if anyone can shed some light on this:

> The Xilinx and Altera tools seem to produce a behavi{*filter*}verilog file
> for simulation. Is there any way I can get a structural verilog file?

You need to go all the way through to place & route and then

(1) Run NGDANNO on the routed database .ncd file => a timing
backannotated .nga file.

(2) Use the .nga + .ngm from the MAP stage as input to NGD2VER to get a
post-route structural netlist based on the ``simprims'' library. Also
outputs an SDF file.

Details are in the ``Development System Reference Guide'' aka
dev_ref..pdf  aka the Xilinx P&R Bible part I. [Part II is the Libraries
guide].

If you are not worried about timing info you can run NGD2VER on the .ngd
output from NGDBUILD.



Wed, 14 Jan 2004 02:16:20 GMT  
 Xilinx/Altera "behavioral" verilog

Quote:


> > Hi All,

> > I was wondering if anyone can shed some light on this:

> > The Xilinx and Altera tools seem to produce a behavi{*filter*}verilog file
> > for simulation. Is there any way I can get a structural verilog file?

> You need to go all the way through to place & route and then

> (1) Run NGDANNO on the routed database .ncd file => a timing
> backannotated .nga file.

> (2) Use the .nga + .ngm from the MAP stage as input to NGD2VER to get a
> post-route structural netlist based on the ``simprims'' library. Also
> outputs an SDF file.

> Details are in the ``Development System Reference Guide'' aka
> dev_ref..pdf  aka the Xilinx P&R Bible part I. [Part II is the Libraries
> guide].

> If you are not worried about timing info you can run NGD2VER on the .ngd
> output from NGDBUILD.

I should of course have begun this as ... for Xilinx devices ...


Wed, 14 Jan 2004 02:17:38 GMT  
 Xilinx/Altera "behavioral" verilog
Programmable parts have different test requirements to ASICs, so
I guess the answer to your question is Yes.


Quote:
> Hi All,

> I was wondering if anyone can shed some light on this:

> The Xilinx and Altera tools seem to produce a behavi{*filter*}verilog file
> for simulation. Is there any way I can get a structural verilog file?

> There are some (ASIC) tools I want to use with these files that only
> support structural verilog (the tools are for ATPG, DFT, and fault
> simulation (ultimate goal is device testing)). Examples of this type
> of tool are:
>   - IBM: TestBench (DFT, ATPG)
>   - Synopsys: DFT Compiler and TetraMax ATPG

> Is this something that Xilinx or Altera will  provide someday?

> I know a lot of ASIC related tools cannot work with current FPGA
> design methodologies, but do we really expect to work with multi
> million gate FPGAs without access to DFT, ATPG, and fault simulation
> tools as are used in the  ASIC world?

> Thanks for your time,
> Paul



Wed, 14 Jan 2004 03:16:34 GMT  
 Xilinx/Altera "behavioral" verilog


Quote:
>Programmable parts have different test requirements to ASICs, so
>I guess the answer to your question is Yes.

If you cannot insert scan into an FPGA how do you get a high fault
coverage? If you have a poor fault coverage you will be shipping
defective parts which is not good for your business.
--
Andy Botterill


Wed, 14 Jan 2004 03:53:10 GMT  
 Xilinx/Altera "behavioral" verilog


Quote:
> >Programmable parts have different test requirements to ASICs, so
> >I guess the answer to your question is Yes.

> If you cannot insert scan into an FPGA how do you get a high fault
> coverage? If you have a poor fault coverage you will be shipping
> defective parts which is not good for your business.

The FPGA manufacturers do this for you.  They use a combination of the
reprogrammability of the part and, presumably, a few undisclosed test
structures.

The result is closer to 100% tested than just about any ASIC.  All
you have to worry about is logical and timing errors :)



Wed, 14 Jan 2004 16:24:11 GMT  
 Xilinx/Altera "behavioral" verilog

Quote:



> > >Programmable parts have different test requirements to ASICs, so
> > >I guess the answer to your question is Yes.

> > If you cannot insert scan into an FPGA how do you get a high fault
> > coverage? If you have a poor fault coverage you will be shipping
> > defective parts which is not good for your business.

> The FPGA manufacturers do this for you.  They use a combination of the
> reprogrammability of the part and, presumably, a few undisclosed test
> structures.

> The result is closer to 100% tested than just about any ASIC.  All
> you have to worry about is logical and timing errors :)

Well somtimes the stupid software has a hard time  with routing and you can't
avoid timing errors.Ben.
--
Standard Disclaimer : 97% speculation 2% bad grammar 1% facts.
"Pre-historic Cpu's" http://www.jetnet.ab.ca/users/bfranchuk
Now with schematics.


Wed, 14 Jan 2004 16:06:35 GMT  
 Xilinx/Altera "behavioral" verilog


Quote:



>> >Programmable parts have different test requirements to ASICs, so
>> >I guess the answer to your question is Yes.

>> If you cannot insert scan into an FPGA how do you get a high fault
>> coverage? If you have a poor fault coverage you will be shipping
>> defective parts which is not good for your business.

>The FPGA manufacturers do this for you.  They use a combination of the
>reprogrammability of the part and, presumably, a few undisclosed test
>structures.

Hmmm I wonder what the test structures are.
Quote:

>The result is closer to 100% tested than just about any ASIC.  All
>you have to worry about is logical and timing errors :)

OK
--
Andy Botterill


Wed, 14 Jan 2004 18:58:08 GMT  
 Xilinx/Altera "behavioral" verilog
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. The FPGA vendors do some of this but they are limited
by the amount of time that they can tie up a chip tester for. Generally
the vendor tests runs in under a second, in my experience it takes about
20 minutes to really test an FPGA. If you are selling low volume high
value equiptment that contains a large number of FPGAs and loads many
different patterns into them, like and ASIC emulator, then this degree
of testing is necessary. If you are shipping high volume low priced
boards then it's cheaper to live with the one in 5000 fall out. Adding
scan logic to a particular circuit is useless because any change to the
pattern, including another place and route on the same design, will
change which resources are used inside of the FPGA.


Quote:



>> >Programmable parts have different test requirements to ASICs, so I
>> >guess the answer to your question is Yes.

>> If you cannot insert scan into an FPGA how do you get a high fault
>> coverage? If you have a poor fault coverage you will be shipping
>> defective parts which is not good for your business.

> The FPGA manufacturers do this for you.  They use a combination of the
> reprogrammability of the part and, presumably, a few undisclosed test
> structures.

> The result is closer to 100% tested than just about any ASIC.  All you
> have to worry about is logical and timing errors :)



Fri, 16 Jan 2004 01:35:02 GMT  
 Xilinx/Altera "behavioral" verilog


Quote:
>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.

Many thanks for such a detailed answer. I come from an ASIC
manufacturing background so the absence of scan would worry me. So there
is a 1 in 5000 chance of detecting a faulty FPGA? This is equivalent to
200 dppm which is a good quality level.

Quote:

>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. The FPGA vendors do some of this but they are limited
>by the amount of time that they can tie up a chip tester for. Generally
>the vendor tests runs in under a second, in my experience it takes about

A 1 second test time would be considered normal. A test time of 20
minutes would be very expensive.

Quote:
>20 minutes to really test an FPGA. If you are selling low volume high
>value equiptment that contains a large number of FPGAs and loads many
>different patterns into them, like and ASIC emulator, then this degree
>of testing is necessary. If you are shipping high volume low priced
>boards then it's cheaper to live with the one in 5000 fall out. Adding
>scan logic to a particular circuit is useless because any change to the
>pattern, including another place and route on the same design, will
>change which resources are used inside of the FPGA.





>>> >Programmable parts have different test requirements to ASICs, so I
>>> >guess the answer to your question is Yes.

>>> If you cannot insert scan into an FPGA how do you get a high fault
>>> coverage? If you have a poor fault coverage you will be shipping
>>> defective parts which is not good for your business.

>> The FPGA manufacturers do this for you.  They use a combination of the
>> reprogrammability of the part and, presumably, a few undisclosed test
>> structures.

>> The result is closer to 100% tested than just about any ASIC.  All you
>> have to worry about is logical and timing errors :)

--
Andy Botterill


Fri, 16 Jan 2004 03:04:08 GMT  
 Xilinx/Altera "behavioral" verilog
Truly interesting.  Any comments from A or X?



Quote:
> 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. The FPGA vendors do some of this but they are limited
> by the amount of time that they can tie up a chip tester for. Generally
> the vendor tests runs in under a second, in my experience it takes about
> 20 minutes to really test an FPGA. If you are selling low volume high
> value equiptment that contains a large number of FPGAs and loads many
> different patterns into them, like and ASIC emulator, then this degree
> of testing is necessary. If you are shipping high volume low priced
> boards then it's cheaper to live with the one in 5000 fall out. Adding
> scan logic to a particular circuit is useless because any change to the
> pattern, including another place and route on the same design, will
> change which resources are used inside of the FPGA.





> >> >Programmable parts have different test requirements to ASICs, so I
> >> >guess the answer to your question is Yes.

> >> If you cannot insert scan into an FPGA how do you get a high fault
> >> coverage? If you have a poor fault coverage you will be shipping
> >> defective parts which is not good for your business.

> > The FPGA manufacturers do this for you.  They use a combination of the
> > reprogrammability of the part and, presumably, a few undisclosed test
> > structures.

> > The result is closer to 100% tested than just about any ASIC.  All you
> > have to worry about is logical and timing errors :)



Fri, 16 Jan 2004 04:38:30 GMT  
 Xilinx/Altera "behavioral" verilog
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

Quote:



>> > Hi All,

>> > I was wondering if anyone can shed some light on this:

>> > The Xilinx and Altera tools seem to produce a behavi{*filter*}verilog file
>> > for simulation. Is there any way I can get a structural verilog file?

>> You need to go all the way through to place & route and then

>> (1) Run NGDANNO on the routed database .ncd file => a timing
>> backannotated .nga file.

>> (2) Use the .nga + .ngm from the MAP stage as input to NGD2VER to get a
>> post-route structural netlist based on the ``simprims'' library. Also
>> outputs an SDF file.

>> Details are in the ``Development System Reference Guide'' aka
>> dev_ref..pdf  aka the Xilinx P&R Bible part I. [Part II is the Libraries
>> guide].

>> If you are not worried about timing info you can run NGD2VER on the .ngd
>> output from NGDBUILD.

>I should of course have begun this as ... for Xilinx devices ...



Fri, 16 Jan 2004 23:43:01 GMT  
 Xilinx/Altera "behavioral" verilog
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
behavi{*filter*}verilog, some tools cannot work with non-scan architecture.

----------
"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.

----------
"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.

----------
"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

My customer DOES see significant failures in boards/system (100's of
devices per month)

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.



Sat, 17 Jan 2004 01:27:47 GMT  
 Xilinx/Altera "behavioral" verilog


Quote:
>----------
>"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

Have you considered using an FPGA to validate the logic and then
converting it to an ASIC. Do your overall volumes justify this option?

Quote:

>My customer DOES see significant failures in boards/system (100's of
>devices per month)

>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.

Surely RTL can be synthesised for an FPGA or an ASIC?

Quote:

>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.

--
Andy Botterill


Sat, 17 Jan 2004 02:12:35 GMT  
 Xilinx/Altera "behavioral" verilog

Quote:

> 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


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.


Sat, 17 Jan 2004 06:57:22 GMT  
 
 [ 22 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Choosing a verilog synthesis tool (Altera/Xilinx)

2. "bad synchronous description" in Xilinx WebPack

3. "xilinx software sampler"

4. Xilinx Vhdl "'event" synthesis problem

5. string.join(["Tk 4.2p2", "Python 1.4", "Win32", "free"], "for")

6. BEGIN{want[]={"s1o", "s2o", "s2q", "s3q"}

7. Looking for a Verilog "Lint" program

8. Looking for a Verilog "Lint" program

9. Verilog equivalent of VHDL "generate"

10. using "for" statement in Verilog

11. "cosimulation" of verilog and simulink

12. +define+unknown="'bx" chokes verilog

 

 
Powered by phpBB® Forum Software