netlist - technology remapping

[valentin tihomirov]

There is a netlist synthesied, say, for an ASIC technology. The netlist
should be prototyped on FPGA. Therefore, it should be implemented by FPGA
vendor's tools. Implementation should be done automatically for any netlist
given in EDIF format. Functionality of primitives is known. One of the
solutions is to create a VHDL netlist and resynthesize. It would be possible
to bypass VHDL export and synthesis by building (on-the-fly) a macro-library
of the ASIC primitives out of vendor's primitives, specifically out of
Xilinx's UniSim primitives. Please, give the idea, what are the macro-libs
and how can they be created? Thanks.

 

[Mike Treseler]

"valentin tihomirov" wrote:

There is a netlist synthesized, say, for an ASIC technology. The netlist
should be prototyped on FPGA. Therefore, it should be implemented by FPGA
vendor's tools. Implementation should be done automatically for any netlist
given in EDIF format.

Consider getting vhdl source code and
running synthesis for each target.

It would be possible
to bypass VHDL export and synthesis by building (on-the-fly) a macro-library
of the ASIC primitives out of vendor's primitives, specifically out of
Xilinx's UniSim primitives.

Possible, but it might be more efficient in time
and gates to write synth code from scratch.

-- Mike Treseler

 

[Kevin Neilson]

"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
message news:c1qck8$1ld1dc$1@ID-212430.news.uni-berlin.de...

There is a netlist synthesied, say, for an ASIC technology. The netlist
should be prototyped on FPGA. Therefore, it should be implemented by FPGA
vendor's tools. Implementation should be done automatically for any
netlist
given in EDIF format. Functionality of primitives is known. One of the
solutions is to create a VHDL netlist and resynthesize. It would be
possible
to bypass VHDL export and synthesis by building (on-the-fly) a
macro-library
of the ASIC primitives out of vendor's primitives, specifically out of
Xilinx's UniSim primitives. Please, give the idea, what are the macro-libs
and how can they be created? Thanks.

I think it would be possible to make, say, a Perl script that would convert

ASIC primitives into FPGA primitives. I don't know if it would be very
efficient, though. The ASIC primitives will be things like AND gates,
whereas the FPGA primitives are LUTs that can absorb several gates. A very
simple scripts would map a single gate to a single LUT and not be efficient,
so the best bet is to resynthesize the source if you can. I suppose if you
could do that, you wouldn't be asking the question though.
-Kevin

 

[Brian Philofsky]

Kevin Neilson wrote:

"valentin tihomirov" <valentin_NOSPAM_NOWORMS@abelectron.com> wrote in
message news:c1qck8$1ld1dc$1@ID-212430.news.uni-berlin.de...

There is a netlist synthesied, say, for an ASIC technology. The netlist
should be prototyped on FPGA. Therefore, it should be implemented by FPGA
vendor's tools. Implementation should be done automatically for any

netlist

given in EDIF format. Functionality of primitives is known. One of the
solutions is to create a VHDL netlist and resynthesize. It would be

possible

to bypass VHDL export and synthesis by building (on-the-fly) a

macro-library

of the ASIC primitives out of vendor's primitives, specifically out of
Xilinx's UniSim primitives. Please, give the idea, what are the macro-libs
and how can they be created? Thanks.


I think it would be possible to make, say, a Perl script that would convert
ASIC primitives into FPGA primitives. I don't know if it would be very
efficient, though. The ASIC primitives will be things like AND gates,
whereas the FPGA primitives are LUTs that can absorb several gates. A very
simple scripts would map a single gate to a single LUT and not be efficient,
so the best bet is to resynthesize the source if you can. I suppose if you
could do that, you wouldn't be asking the question though.
-Kevin

What is worse than this is the fact that translating a netlist in this
manner eliminates the possibility of using the carry chain, dedicated
muxes (MUXF5/6/7/8), and other "special" logic resources (i.e. SRL16,
MULTAND, etc.). It has the likelihood of not fully utilizing the
capabilities of the registers (i.e. clock enables and synchronous resets
mapped into general logic) and makes it very difficult and unlikely that
much of the dedicated RAM and Multiplier structures will be used. It
also lends itself more to misusing routing resources (i.e. not using
global routes properly for clocks, local connects, etc.). In the end
you are likely to use a much larger FPGA running at a fraction of the
speed possible and will likely be harder to get quickly up and runnning
and more difficult to debug as well which I assume is the whole purpose
of using the FPGA for prototyping. As mentioned before, it is a much
better route to use RTL code and synthesize directly to the FPGA
architecture you are targeting than to take a netlist mapped to one
technology library and remap it to an FPGA.


-- Brian