[Libre-soc-dev] Update on Coriolis & LS180.

Jean-Paul Chaput Jean-Paul.Chaput at lip6.fr
Mon Apr 26 15:05:26 BST 2021

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
    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)              
     ^^ ^^    cell:   home:

    U P M C   Universite Pierre & Marie Curie
    L I P 6   Laboratoire d'Informatique de Paris VI
    S o C     System On Chip

More information about the Libre-soc-dev mailing list