I am trying to understand if there is a well
defined procedure to do
ASIC prototyping using FPGA.  I was thinking that I can divide down
the ASIC design into multiple functional blocks. Such that each block
represents asn ASIC.  The design is in verilog HDL but it contains a
lot ASIC lib specific instantiations.   This is not understood by the
FPGA software.  Here are the things that I am trying to understand

(1) How to convert the ASIC libreray specific primitive such that the
FPGA software can understand?
(2) The ASIC design uses LATCHES every now and then for time
borrowing, I am not sure if it is OK to use the LATCH in FPGA design.
(3) What is the exact procedure of analyzing large designs containing
thousands of verilog modules?  I ran experment on a few selected
modules and dicovered some issues described in 1 and 2.  I am sure a
lot people use FPGAs for ASIC prototyping and do they go through the
verilog moduel one at a time to make them work with the FPGA.
(4) Deisgn of what complexity can be targeted for ASIC prototyping?
The design I have may require multiple big FPGAs.  I wish I could
everything into one big FPGA.
(5) Partitioning the design is also challenging that is why I was
thinking that the design should be partioned based on functional
blocks so there is clear division that matches the design.
(6) Is there a company that provides syhtnesis/partitioning software
and support for code synthesis that can run into above mentioned
problem?

Test01 <c...@yahoo.com> wrote:

< I am trying to understand if there is a well defined procedure to do
< ASIC prototyping using FPGA.  I was thinking that I can divide down
< the ASIC design into multiple functional blocks. Such that each block
< represents asn ASIC.  The design is in verilog HDL but it contains a
< lot ASIC lib specific instantiations.   This is not understood by the
< FPGA software.  Here are the things that I am trying to understand
 
< (1) How to convert the ASIC libreray specific primitive such that 
< the FPGA software can understand?

If they look like module references, you just need to write a
verilog module that does the same function.  Don't include it
when using the ASIC library.

< (2) The ASIC design uses LATCHES every now and then for time
< borrowing, I am not sure if it is OK to use the LATCH in FPGA design.

The usual FPGAs have an edge-triggered FF along with each LUT
(look-up table).  If that is what you mean by latch, then it
should work fine.  If you mean something more like a transparent
latch then it will be implemented with LUTs, take up more cells
and probably be slower.  It should still work, though.

< (3) What is the exact procedure of analyzing large designs containing
< thousands of verilog modules?  I ran experment on a few selected
< modules and dicovered some issues described in 1 and 2.  I am sure a
< lot people use FPGAs for ASIC prototyping and do they go through the
< verilog moduel one at a time to make them work with the FPGA.

As I understand it, with the current mask costs many projects 
previously targetting ASICs are now targetting FPGAs.  You might
check the total cost (NRE, masks, etc.)  Otherwise, FPGA arrays
are known to have been used for debugging microprocessors.
At that point, they can afford special software.

< (4) Deisgn of what complexity can be targeted for ASIC prototyping?
< The design I have may require multiple big FPGAs.  I wish I could
< everything into one big FPGA.

I believe there are stories about some of the intel Pentium series
prototyping in FPGA arrays.  I haven't followed them recently, though.
Is that big enough?

< (5) Partitioning the design is also challenging that is why I was
< thinking that the design should be partioned based on functional
< blocks so there is clear division that matches the design.

Well, partitioning is usually part of the design process. 
FPGA's are getting big enough that you won't have to partition
all that much, though.

< (6) Is there a company that provides syhtnesis/partitioning software
< and support for code synthesis that can run into above mentioned
< problem?

I believe so, but it might be pretty expensive.

-- glen 

>I am trying to understand if there is a well
defined procedure to do
> ASIC prototyping using FPGA.

A study by Dataquest in 2005 showed that nearly 40% of all ASIC companies
prototype on FPGA's. I suspect this figure to be a lot higher these days and I
wouldn't be surprised if all digital ASIC's are prototyped on FPGA's.

>I was thinking that I can divide down
> the ASIC design into multiple functional blocks. Such that each block
> represents asn ASIC.  The design is in verilog HDL but it contains a
> lot ASIC lib specific instantiations.   This is not understood by the
> FPGA software.

Depends, if the ASIC design contains DesignWare components then both Mentor's
Precision and Synopsys Synplify can handle (some of) them. These tools can also
handle gated clocks and SDC constraint files.

>Here are the things that I am trying to understand
>
> (1) How to convert the ASIC libreray specific primitive such that the
> FPGA software can understand?

As mentioned above, look into DesignWare.

> (2) The ASIC design uses LATCHES every now and then for time
> borrowing, I am not sure if it is OK to use the LATCH in FPGA design.

See Glen's answer.

> (3) What is the exact procedure of analyzing large designs containing
> thousands of verilog modules?  I ran experment on a few selected
> modules and dicovered some issues described in 1 and 2.  I am sure a
> lot people use FPGAs for ASIC prototyping and do they go through the
> verilog moduel one at a time to make them work with the FPGA.

If the design is very large then I would recommend a static/dynamic linting tool
such as spyglass/designchecker. These tools can very quickly check for all sorts
of issues such as latches, missing block, unused logic, un-synthesisable
constructs, both clock edges used, combinatorial feedbacks, etc.I would also
recommend a clock domain checkers such as 0-in's CDC if you have multiple clock
domains.

> (4) Deisgn of what complexity can be targeted for ASIC prototyping?

In addition to Glen's answer I suspect that it will be highly unlikely your
can't fit your design on say a Hardi/Enterpoint/ProDesign/etc board.

Have a look at this board:  http://www.enterpoint.co.uk/merrick/merrick1.html

> The design I have may require multiple big FPGAs.  I wish I could
> everything into one big FPGA.
> (5) Partitioning the design is also challenging that is why I was
> thinking that the design should be partioned based on functional
> blocks so there is clear division that matches the design.

If speed is not an issue than I would recommend that as well. There are
partitioners than can partition based on delays but this is normally a lot more
difficult to do.

> (6) Is there a company that provides syhtnesis/partitioning software
> and support for code synthesis that can run into above mentioned
> problem?

I believe that Synopsys's Certify is the current market leader in partioning
software but I have heard that Auspy ACE is more powerful but more difficult to
use (they also have a dreadful website, see http://www.auspy.com/)

Good luck,
Hans
www.ht-lab.com

For the Multi-FPGA boards, checkout:

www.dinigroup.com

and I belief Synopsys has software called Certify that will partition yourdesign for you.

Have fun.

Hi,

Here is a suggested methodology, based on my extensive experience with
FPGA prototyping...

(1) Design conversion
There are several types of ASIC elements that are not compatible with
FPGA prototyping:
(1.1) Memories
ASIC designs contains foundry-specific memory instances. For FPGA
prototyping, these should be replaced by FPGA friendly models. The
best solution is to rely on the ability of synthesis tool to
synthesize memories. In many cases, the simulation model from the
memory vendor will work fine. If not, you need to write your own
functional model.
(1.2) DesignWare
As mentioned by other posters, both Synopsys (Synplify and Certify)
and Mentor (Precision) have a built-in DW library that contains basic
DW IPs optimized for FPGA implementation. For unsupported DW IPs, you
will need to supply synthesizable model. Here again, simulation models
will mostly work fine, but are likely to result in poor performance.
You can always write you own models when required.
(1.3) Instantiated library cells
In some cases, your ASIC may contain instantiated cells from the
foundry-specific library. These can be handled automatically by
Synopsys Synplify/Certify by simply providing the .lib file(s) to the
synthesis tool. The alternate option is to supply synthesizable
models. Often, the simulation library will do the trick for basic
cells.
(1.4) Other hard IPs (analog, serdes, pll, etc)
For all other hard IPs (i.e. w/o a synthesizable model) you will need
to either partition it out of FPGAs (see partitioning topic below), or
write a FPGA friendly model. A good example is PLLs, which are
available on FPGAs, yet most likely with a different interface than
your ASIC one.
(1.5) Gated-clock and Generated-clock
FPGAs have a limited number of clock trees. Consequently, gated and
generated clocks must be transformed to "clock-enables". Synopsys
(Synplify and Certify) supports automatic conversion of gated and
generated clocks. Last I checked, Mentor Precision supports gated-
clock conversion but not generated-clock conversion (though rumored to
be coming).
Important note: gated/generated clock conversion is a global
optimization that requires the entire design to be provided at once to
the synthesis tool. Indeed, if the gated cell (the AND gate for
example) is located in a different partition (i.e. a distinct
synthesis project) than the driven FFs, then conversion cannot be
performed.
(1.6) Latches
Latches are supported by most FPGA vendors, though unequally. Watch
out vendors that implement latches as a feedback mux, as these
typically incur a noticeable clock skew. Additionally, and of critical
importance, no FPGA tools (synthesis or P&R) supports "time-
borrowing", and latches are treated as FFs during timing analysis.
This can result in both false positive and false negative, in presence
of shoot-through (of which time-borrowing is a special case). If you
have isolated latches that are always surrounded by rising-edge FFs
(either in the FPGA or outside the FPGA), then the default FF modeling
is safe (conservative).

=> A completed conversion should result in successful synthesis to the
FPGA target (possibly overflowing the resources of the target device).

(2) Partitioning
If the ASIC is too big to fit into one FPGA, then you need to
partition the logic. This consists in resolving several equations
simultaneously:
 - IOs: each partition should contain less IOs that the number of pins
on the target device
 - resources: each partition should not overflow the resource count
for each resource type (LUTs, DFFs, DSP blocks, memories, PLLs, clock
trees, etc)
 - board routability: if you're using an off-the-shelve board (Dini,
Synopsys/Hardi, Gidel, etc), you need to ensure that the number of
connections between any pairs of FPGAs can be accommodated by the
routing tracks on the board. If you plan on building a custom board,
this is not an issue.
 - performance: any path spanning two or more FPGAs will suffer from
severe performance degradation due to the IO delays (several ns). If
performance matters, one should try to contain critical paths in a
single device.
Synopsys Certify is the leading tool for FPGA partitioning. Although
both Synopsys and Auspy provide automatic partitioning, one most needs
to help the tool by manually specifying partition assignments. That's
largely due to the fact that partitioning algorithms don't "see" (e.g.
understand) your design, which can lead to poor results. At that game,
Certify has more powerful features for RTL and source code
partitioning, i.e. at the level you're familiar with (Try partitioning
synthesized LUTs by hand ...).
To my knowledge, Certify is also the only tool that resolves the board
routability for you: its reads-in the netlist of the target board, and
applies a routing algorithm to map the connections between partitions
onto wires on the board. This lets you quickly identify invalid
partitions when using off-the-shelve boards.

=> A valid partitioning should result in successful place and route
for each FPGA.

(3) Board management
You now need handle a few things to map your design to the target
board.
(3.1) Board creation
If you're not using an off-the-shelve board, you'll need to design
your own. Taray 7Circuits is a very neat tool that essentially is a
"PCB floorplanner". It allows you to quickly (i.e not manually) create
your board and automatically handles IO constraints (connectivity,
electrical, banking rules). There is a very nice flow with Synopsys
Certify to use 7Circuits to design your prototyping board (check
Taray's web site)
(3.1) Pin assignments
This consists in assigning every pin of each FPGA to the adequate
logic port, to properly connect the devices together. In other words,
this consists in "mapping" (routing) each connection between
partitions to a wire on the board. For off-the-shelve boards, both
Synopsys Certify and Auspy handle this automatically for you. This
saves the horribly tedious and error-prone job of performing pin-
assignment for each FPGA (picture a complex board with 4 FPGAs each
having 1,000+ pins - good luck handling this by hand looking at the
board schematic and your partitioned design). For custom boards, Taray
7Circuits will do the pin assignment for you.
(3.2) I/O timing constraints
This consists in applying input/output delay constraint to each pin of
each FPGA to ensure there are no timing violations for path spanning
across FPGAs. There again, both Certify and Auspy use timing-budgeting
to automatically generate timing constraints all FPGA pins. That is an
essential feature to avoid hidden timing violations on the board that
can take weeks or months to be identified (in lieu of a functional
bug).

=> At that point, you should be able to download each bitstream into
the board and boot it.

(4) Debug methodology
Your ASIC is now alive on the FPGA board. But most likely what you see
is ... well, functional bugs :~(. Debug such a beast if far from being
easy, and you should plan for it in advance:
(4.1) Probes
One basic debugging method is to send selected signals to FPGA pins
for observation with a logic analyzer. Auspy, Certify let you add
probes without editing your HDL. I don't know if Precision also
supports this (though I would guess it does).
(4.2) On-chip debugging
This consists in probing signals into FPGA memories and uploading
through JTAG. Synopsys Identify leads the pack, followed by SignalTap
and ChipScope from Altera and Xilinx, as well as tools from Temento or
DAFCA (no experience with these last two). One of the nicest feature
of Identify is to display the signal values back in your HDL. That's
much more efficient than looking at waveforms. Also, and importantly,
it is essential to insert such debugging logic *before* synthesis, in
the RTL. That's because FPGA synthesis perform many
complex optimizations, and sequential optimizations, can change very
subtly the behavior of your FFs (for example, pushing an inverter
through a FF). If your debug logic is inserted after synthesis, you
could very well end-up chasing false positive (i.e. chasing a non-
existent bug). However, if you insert your debug logic in the RTL,
this will prevent the synthesis from changing the functional behavior
of your FF (because the FF output is now 'observed').
Here, favor tools that can insert debug logic in your HDL without
requiring manual edit. Temento and Synopsys both have this feature,
and Auspy does not seem to support this.
(4.3) Assertions
I personally believe that synthesizing assertion into your FPGA
prototype is a very powerful methodology, in particular when combined
with on-chip debugging. This indeed allows capturing violations in on-
chip memories, but can also be used to trigger signal probing to help
diagnose the cause of the violation. I don't know which synthesis
tools actually support assertion synthesis yet.

(5) Additional considerations
(5.1) While I would believe the majority of FPGA prototypes to have
2-8 devices, I've heard of prototypes with 50+ -large- devices.
(5.2) Advanced partitioning features include pin-multiplexing (to save
FPGA pins at the expense of performance), high-speed IO (LVDS/SERDES)
support (to save FPGA pins with no performance impact), RTL hierarchy
manipulations (to allow for non module-based partitioning, such as
datapath slicing), logic replication (to save FPGA pins and board
traces), feedthrough elimination (to save FPGA pins), etc
(5.3) Emulation systems (EVE, Cadence, Synopsys, Mentor) also map
entire ASICs onto FPGAs for the sake of functional debugging. They
typically provide an extremely automated flow (much easier than FPGA
prototyping) and superior debugging tools (in particular, full
observability). However, these systems are *much* more expensive than
FPGA prototypes, and provide much lower operating frequencies (< 10
MHz).

(6) Conclusions
(6.1) For basic prototyping (vanilla RTL with 1 or 2 FPGAs), you can
use Mentor Precision or Synopsys Synplify and do partitioning and
board management by hand. I would stay away from FPGA vendor synthesis
tools who often want to "help the customer" by cleaning-up your design
in a way that does not exactly preserve the HDL behavior (not a good
idea for ASIC prototyping).
(6.2) For complex prototyping, you will have to use dedicated tools.
You can either opt for the integrated Synopsys flow (Certify +
Identify) or the composite Mentor + Auspy + Temento flow.

That's it for now, hope it helps,

- gael

PS: Despite my best efforts to be exhaustive and objective, I
apologize in advance for tools/companies I may have omitted or mis-
represented. I welcome their feedback through email: gael (at)
gaelpaul (dot) com

Thanks Gae for detailed response.  This seems to
be a big
undertaking.  One of the issue that I see is that the ASIC design team
will be constantly reving the HDL code.  I get the feeling that there
is a fair amount of time needed to convert the asic design that can
work in FPGA.  I am not sure if it is easy to keep up with the latest
code drop from asic design team.  Cadence has emulation hardware
called Palladium.   ASIC to Palladium netlist conversion seems a bit
easier.  It does not require big changes to the design - for example
replacing latches with flipflops, clocking.  Thus asiic to palladium
netlist conversion process is able to keep up with the design team
code drop updates.

Any comments on how this can be as good as Palladium?

Test01,

The initial mapping to an FPGA prototyping board is indeed a big
undertaking. However, if you use the dedicated tools described in the
previous post, then updating the prototype when the HDL changes will
be push-button in the vast majority of cases. Changes that would
require some assistance are of the kind that invalidate the partition:
 - changes to the interface between two modules that are in different
devices. This would require to incrementally update the partition and
pin assignment (Certify supports this, not sure about Auspy)
 - significant increase in resources leading to an overflow of one or
more devices. This would require an incremental update to the
partition to reassign logic in devices with some free room
 - etc

Emulation systems are in fact using commercial FPGAs. Thus, the
conversion effort is virtually identical. However, the partitioning
and board management tasks are fully automated and hidden from the
user.

The choice between emulation and prototyping should primary be based
on your objectives:
 - to perform early-stage functional debug, emulation is the better
choice. To some extent, emulation is HDL simulation on steroids.
 - to validate the chip in a (near) real-life environment, find the
late-stage functional bugs, develop and validate the embedded
software, pass certification, etc, prototyping is the better choice.
In fact, power users combine emulation and prototyping to validate
their SoCs.

Cheers,

 - gael

PS: a few additional notes on latches:
(1) wether using emulation of prototyping, there is no need to convert
latches to flip-flops as latches are supported in most FPGAs. However,
you cannot fully rely on timing analysis since it does not support
time-borrowing. This introduces the possibility of timing violations
on your emulator/prototype that would appear as functional bugs. If
you run the emulator/prototype at very low frequencies (e.g. < 1Mhz,
like emulators do), then this most likely not a problem. Otherwise, a
good option for power users would be to run PrimeTime (or any ASIC STA
that supports time-borrowing) on the protoype netlist annotated with
delays (SDF).
(2) wether using emulation or prototyping, you can opt for fully
automatic conversion of latches to flip-flops (Precision and Synplify/
Certify have this feature). While this resolves the above timing
analysis problem, it may create a design that is not functionally
equivalent. However, in my experience, if latches are used properly,
FF conversion will always be functionally equivalent. In other words,
if your ASIC design team is experienced and knows its trade, latches
should not be an issue and converting them to FFs is best option.

On Oct 13, 4:11=A0pm, Gael Paul
<gael.p...@gmail.com> wrote:
> (1) wether using emulation of prototyping, there is no need to convert
> latches to flip-flops as latches are supported in most FPGAs. However,
> you cannot fully rely on timing analysis since it does not support
> time-borrowing. This introduces the possibility of timing violations
> on your emulator/prototype that would appear as functional bugs. If
> you run the emulator/prototype at very low frequencies (e.g. < 1Mhz,
> like emulators do), then this most likely not a problem.

The timing issue with latches is hold time, not setup time.  Hold time
violations are independent of clock speed so if you have this problem
you'll have it whether you run the design at 1 Hz, or 500 MHz.

You'll likely find what turns out to be hold time problems started as
something that appears as a sensitivity to temperature, so cold spray
and heat guns can make the problem come and go.

You can get lucky with timing...or not.

Kevin Jennings

On Oct 13, 3:11=A0pm, Gael Paul
<gael.p...@gmail.com> wrote:
> Test01,
>
> The initial mapping to an FPGA prototyping board is indeed a big
> undertaking. However, if you use the dedicated tools described in the
> previous post, then updating the prototype when the HDL changes will
> be push-button in the vast majority of cases. Changes that would
> require some assistance are of the kind that invalidate the partition:
> =A0- changes to the interface between two modules that are in different
> devices. This would require to incrementally update the partition and
> pin assignment (Certify supports this, not sure about Auspy)
> =A0- significant increase in resources leading to an overflow of one or
> more devices. This would require an incremental update to the
> partition to reassign logic in devices with some free room
> =A0- etc
>
> Emulation systems are in fact using commercial FPGAs. Thus, the
> conversion effort is virtually identical. However, the partitioning
> and board management tasks are fully automated and hidden from the
> user.
>
> The choice between emulation and prototyping should primary be based
> on your objectives:
> =A0- to perform early-stage functional debug, emulation is the better
> choice. To some extent, emulation is HDL simulation on steroids.
> =A0- to validate the chip in a (near) real-life environment, find the
> late-stage functional bugs, develop and validate the embedded
> software, pass certification, etc, prototyping is the better choice.
> In fact, power users combine emulation and prototyping to validate
> their SoCs.
>
> Cheers,
>
> =A0- gael
>
> PS: a few additional notes on latches:
> (1) wether using emulation of prototyping, there is no need to convert
> latches to flip-flops as latches are supported in most FPGAs. However,
> you cannot fully rely on timing analysis since it does not support
> time-borrowing. This introduces the possibility of timing violations
> on your emulator/prototype that would appear as functional bugs. If
> you run the emulator/prototype at very low frequencies (e.g. < 1Mhz,
> like emulators do), then this most likely not a problem. Otherwise, a
> good option for power users would be to run PrimeTime (or any ASIC STA
> that supports time-borrowing) on the protoype netlist annotated with
> delays (SDF).
> (2) wether using emulation or prototyping, you can opt for fully
> automatic conversion of latches to flip-flops (Precision and Synplify/
> Certify have this feature). While this resolves the above timing
> analysis problem, it may create a design that is not functionally
> equivalent. However, in my experience, if latches are used properly,
> FF conversion will always be functionally equivalent. In other words,
> if your ASIC design team is experienced and knows its trade, latches
> should not be an issue and converting them to FFs is best option.

Have you all heard of vavlog?  It seems that some people initially use
this software to screen the RTL code. based on the feedback from
vavlog, code changes are made to the design (verilog files) to be able
to do vaelab synthesis.  I am not sure if the output of vavlog can be
fed to Synopsys certify.