Re: gEDA-user: putting it all together

[cfk <cfk@pacbell.net>]

Well, it seems to me that the placement could be in the form of rows with
and columns. Certainly a piece of Verilog logic could be defined to fit into
a rectangular box x microns by y microns and it could be argued that each
module or group of modules should be routed together so the local
connections dont try to wire across too long a distance. I could also
envision that the height of the box could define the spacing between rows to
allow a variable amount of space for routing the metal1/metal2
interconnects. A dialog for width of signal traces, spacing between traces,
width of power/ground and whether or not the power comes in from the left or
the right of the box would be appropriate. I'm not inventing this, its
allready invented. I am just parroting how the QUISC works within Electric.

The manner of inputting this to Magic could be a .mag file with a list of
commands such as "use OR", "transform to x,y". I could see the desire to
sometimes mirror horizontally, but since the VDD and GND are consistently on
one end of the cell, mirroring vertically would present a big problem for
VDD and GND. I thnk a set of rules could be worked out for routing the power
and ground with, of course, wider traces and ensure that the cells are lined
up nicely in rows to accomodate 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