[Libre-soc-bugs] [Bug 526] create dry-run 180nm GDS-II files for IMEC

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=526

--- Comment #70 from Jean-Paul.Chaput at lip6.fr ---
(In reply to Luke Kenneth Casson Leighton from comment #68)
> (In reply to Jean-Paul.Chaput from comment #66)
> > Just pushed experiments11 in soclayout git repository.
> > 
> > Note that it cannot be run without the NDA part of Coriolis2.
> > You may place under non_generated the full chip .il and the associated .json
> > for the I/O pad placement so I can pull them and P&R them. Maybe with
> > different names.
> > I am usually against copying/duplicating file, but in this instance it
> > will allow us to work in parallel and choosing when we want to synch.
> 
> yeah honestly i am not happy about that.  i was under the distinct
> impression (right up until last week) that an NDA-free Phantom Library would
> be available, so that exactly this situation would never occur.
> 
> however... we work with things as they are.

  Yes I perfectly understand. I am not completly happy either.

  I think I should write a more complete explanation so that everyone can
  understand the pros and cons of each approach. I only (very) recently
  fully understand the whole implications of Staf ways, leading to a
  intermediate one. So here is the situation, with three possible paths:

  Plan A : FlexLib with maximum density routing gauge (routing tracks as
           close as allowed by the technology).
           * Pros: Gives close to maximum density for the design.
                   Easier for the P&R to complete, minimum area (i.e. cost).
           * Cons: Impossible to publish the layout. Only netlist, and
                   maybe placement (but no routing).

  Plan B : (Intermediate, *new*) FlexLib, but with a routing gauge with
           track pitches on a fractional of the cell height/cell width.
           * Pros: Allow publication of a "symbolicized" layout of both
                   cells (phantom/abstracts or full).
                   Not portable across technological nodes.
           * Cons: Increased area. More difficult for the router.

  Plan C : Use the original NSXLIB/Alliance symbolic layout.
           * Pros: Same as plan B, plus possibility of cross porting
                   between technological nodes.
           * Cons: Even more increase of area. Marie-Minerve is working
                   on that as part backup plan, but she's still facing
                   some scaling problems.

  For the future, people should be able to choose between, at least A and B,
  given the tradeoff they want.

-- 
You are receiving this mail because:
You are on the CC list for the bug.