[Libre-soc-bugs] [Bug 526] create dry-run 180nm GDS-II files for IMEC
bugzilla-daemon at libre-soc.org
bugzilla-daemon at libre-soc.org
Mon Nov 30 14:46:03 GMT 2020
--- 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
> 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.
You are receiving this mail because:
You are on the CC list for the bug.
More information about the libre-soc-bugs