[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 #71 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jean-Paul.Chaput from comment #69)
> > > So I've successfully done the P&R with Staf FlexLib & I/O pads. I will
> > > commit that work under experiments11. Only I or Staf will be able to
> > > run it because it needs the NDA (this directory, however, will not
> > > contains any classified information).
> > 
> > sigh.  now we have two sets of identical work to maintain.  so, when i add
> > the core back in, you have to duplicate that.
> 
>   Yes that's far from ideal. However, just copying the ".il" generated by
>   nMignen should suffice. 

and ls180 pinmux changes should be picked up cleanly, too.


> 
> > > * Could it be possible for the JSON file to be human-readable formatted?
> > 
> > with some independent parser tool, probably yes.  unix philosophy applies.
> 
>   With Python/JSON this is very easy... Already did.

if you are using that command regularly please do feel free to add it as a
helper script to soclayout (experiments9 and 11) so that you don't have to
repeat it / forget it


>  
> > >   It will not induce significant slowdown and I will be able to perform
> > >   manual tweaks more easily.
> > 
> > mmm... if you're doing manual tweaks to an auto-generated
> > (machine-generated) file this raises alarm bells in my mind.
> 
>    And I totally agree. I mean, it is useful for debugging purpose.
>    If I can read the JSON I can quickly pinpoint the problem, make
>    a manual correction to see if it works, then suggest/request an
>    appropriate fix (fast debug loop).

i get it.  the ls180 pinmux program is... slightly obtuse.


> 
> > > * In your json file, you seems to have inverted vdd/vss on the I/O pads.
> > >   "vdd" should be connecteds to "power" and "vss" to "ground".
> > 
> > ah ok good catch.
> 
>   Benefit of human readable file...

:)

> > by using the core size not the chip size then regardless of the chip size
> > the positions of the IOpads align up perfectly with the core.
> 
>   Yes, I didn't forgot. But it means that we loose some space at the end of
>   each side. If we are core limited, no problem. 

there are three possibilities:

* IO bound (IO defines size of chip)
* core bound (core defines size of chip)
* grey area right in the middle where either one could end up defining the size

there are bugs/quirks in the current algorithm (without the pads.useChipSize
patch) that mean that things will neverrrr work (unless forcing to move the
VSS/VDD inwards which i do not want to do).

the current size of the chip is, by a coincidence, in the "upper" part of that
"grey area", just transitioning to core-bound.

this upper limit of the grey area is what pads.useChipSize is designed to fix.

once the OpenPOWER core is added back in, this will *not* be the case, because
the chip will definitely be core-bound, and the bugs/quirks will not be
encountered.


> If we are pad limited, this
>   may be bad (especially if the core is *much* smaller than the corona).

then such designers would not use the pads.useChipSize option.

>   Anyway, for a better power distribution it is likely that I will change
>   the whole approach.

ah ok.

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