Re: gEDA-user: putting it all together

[John Sheahan <jrsheahan@optushome.com.au>]

On Sat, Feb 22, 2003 at 03:21:12PM -0800, Stephen Williams wrote:
> 
> cfk@pacbell.net said:
> > I am studying the use of Icarus Verilog to create an RTL netlist. From
> > that netlist, which has INV, OR, NAND, etc defined, I am trying to
> > understand how to flow the netlist into Magic.
> 
> The best way to get from Verilog to MAGIC is to write a code generator
> that generates the appropriate netlist format. The ivl_target API
> actually communicates the compiled design with LPM (approximately)
> level devices, which the code generators then write into real world
> netlist/library combinations.
> 
> The newer -tfpga supports Xilinx Virtex parts more directly then the
> -txnf code generator you are apparently using. The EDIF that comes
> out of that code generator can be handed directly to the Xilinx tools
> for map/par. The sqrt-virtex.v example demonstrates this.


Alternatively it would be not particularly difficult to have an
external filter take the xnf output and map it straight to structural 
verilog.   Sounds like only a little bit of perl.

following that,
I have written scripts to extract cells from structural verilog (and I
think nets too from memory, was a while back)
that could be trivially modified to match magic's unusual netlist
format.  they are available.

ftp://ftp.reptechnic.com.au/pub/scripts/report.cells will list the
cell types
ftp://ftp.reptechnic.com.au/pub/scripts/report.loose.wires
will report nets with only one pin. modifieable

It would also be necessary to add power and ground nets, which would
require information from the gate library.  Which in this 'flow' 
would just be the xnf primitives.   Seems like a gate level
reoptimizer is required to map to the final library for stuff like
ramptime (timing in general).     
 
Magic looks to be an extension of the older CIF flow, so I assume 
the cell placement would need to be hand done first?

john