FPGA Central

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.

"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

"valentin tihomirov" <[email protected]> wrote in
message news:[email protected]
> 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

Kevin Neilson wrote:
> "valentin tihomirov" <[email protected]> wrote in
> message news:[email protected]
>
>>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