On Sun, 2021-04-25 at 18:45 +0100, lkcl wrote:
>
> the last time i "fixed" this, it involved actually creating (fake)
> iopadvss.ap, etc. etc. etc., plus FlexLib dio_x0.ap etc. etc. etc. all
> of which took some doing, but "worked"....
>
> ah hang on, i still have the files. after copying them into the main
> subdirectory, i can run "make view".
>
> there are zero nets. *this is even after the routing has completed*
>
> likewise, running the command i created, here, *there are no nets*:
> https://gitlab.lip6.fr/vlsi-eda/alliance-check-toolkit/-/issues/1
>
> you can see, in the program, that it is calling Horizontal.create and
> Vertical.create then
> NetExternalComponents.setExternal()...
>
> ... it's just that if you then look at the AP file *it has no nets*.
This can't work. With FlexLib (TSMC or FreePDK45), the generated
layout is in GDS. So can be read back into Coriolis or KLayout
*only* in that format. I don't know what has been put into the
AP files (I could, but I don't see the point), it will have no
usable meaning. I should have suppressed their generation
altogether.
Either we go symbolic and can use cougar/lvx or we go real
and for the lack of a public extractor you will not be able
to perform the post-layout verification.
But what we needed was you to supply us with patterns and
cocotb setup so that we have a "validation" check.
The whole point being that pre-P&R and post-P&R must behave
exactly the same. Basically the P&R only insert buffers and
diodes. So any problem in post-P&R (which isn't already present
in the pre-P&R) would be for me to solve.
The ground rule is you cannot mix symbolic and real, it will
just don't work.
> > They are not "ghosts" (abstract), the problem is their connectors in
> > METAL1 won't be at the same place as the real cells so all terminals
> > connexions will be wrong. And, in fact everything will be misaligned.
>
> ... but it will "work". as long as topologically, the nets complete,
> it gives me an opportunity to "stay ahead" of where you are - to find
> problems in advance of you running into them.
>
> if i do not do this, it will be you that runs into them (under NDA),
> and you will *not be able to tell me the full details*.
>
> > > as long as i can complete the PnR, which will allow me to extract the netlist back
> > > out
> > > and then place that through cocotb i can help validate the design.
> >
> > My understanding was that you where to provides us with validated
> > patterns for cocotb with the pre-routed netlist and we (Staf or LIP6)
> > will do the post-routing simulations with them.
>
> yes - the issue you will encounter is that if you use just one machine
> (even an intel i9 4.8ghz) it will take about 8 weeks to *compile the
> program* (ghdl or verilator) and cause that machine to melt if it has
> anything less than 128 GB of RAM.
>
> i have registered a team with fed4fire which gives us cluster
> supercomputer access across the world: this will help.
>
> before getting to that, i'd like to make sure that it stands a chance
> of working.
>
> > Maybe we can find a way to give you the post-layout netlists.
>
> bear in mind i will need to upload them to world-wide federated
> supercomputer clusters.
>
> this will be the *only way* we can get the simulations to compile in a
> sane amount of time.
The two computer bip & bop at LIP6 have 128Gb of RAM. But I see the
point. I have to check with Marie-Minerve that the extracted netlists,
stripped of their parasitics could be write back into VHDL, and so
can be published without infringing the NDA.
--
.-. J e a n - P a u l C h a p u t / Administrateur Systeme
/v\ Jean-Paul.Chaput at lip6.fr
/(___)\ work: (33) 01.44.27.53.99
^^ ^^ cell: 06.66.25.35.55 home: 09.65.29.83.38
U P M C Universite Pierre & Marie Curie
L I P 6 Laboratoire d'Informatique de Paris VI
S o C System On Chip