On September 26, 2021 10:56:04 PM UTC, "Philipp Gühring" pg@futureware.at wrote:
Hi Staf,
It seems there is a slight misunderstanding. Most the codebase for generating the standard cells (lclayout) is actually in Python: https://codeberg.org/tok/librecell/ (And also lctime, the characterization tool) Just the netlist generation and the flow around is in other languages. So feel free to use our Python modules. Let me know if you need any help with it.
so, a bit of context and background: Staf helped Libre-SOC with our 180nm ASIC, 130,000 cells, 5.1x5.9 mm^2 which was taped out with Coriolis2, in a fully automated HDL-to-GDSII conversion with no manual intervention steps.
Jean-Paul Chaput put about 18 months work into coriolis2 to get it into shape, adding High-Fanout buffers, Antennae diodes, and multiple clock tree support, all of which were necessary due to the massive size: over 10x larger than the previous fully-automated layout with coriolis2.
Staf created FlexLib which is an auto-adjustable parametric Cell Library that, given the DRC for a particular node, auto-creates a Standard Cell Library exactly for that node.
there is close integration with Coriolis2 which was tested in TSMC 180nm and came back 100% DRC Clean from Synopsis tools. we get the ASIC back appx next month and will know soon if it works.
Staf also created FreePDK-C4M45 which is FlexLib using the FreePDK45 DRC rules, creating GDS-II Cell Libraries. these are not suitable for tape-out but have the exact same netlist as the (NDA'd) TSMC 180nm ones.
i was able to assist Jean-Paul by running the exact same coriolis2 layout program but instead of using the NDA'd 180nm FlexLib cells i used the non-NDA'd FreePDK45 FkexLib cells.
exactly the same configuration
exactly the same netlist
just not the same cell library.
this allowed me to work "in parallel" with Jean-Paul, setting up configurations of coriolis2 layout, making sure they would complete.... oh and then he re-ran them with the *real* Cell Library.
now, why am i mentioning this? for several reasons:
1) there are a large number of issues to solve (busting several layers of NDAs, from HDL down to Foundry). however unless some of the upper layers are solved there is nothing with which to test the lower layers, and being inter-related you cannot solve one without the other.
2) Staf i know is very busy. he has chosen to begin to develop FlexLib over 2 years ago (long before Skywater 130nm), and received NLnet funding for it. he is now also working on an Analog Cell Library (also NLnet funded), and many other things.
i mention (2) Philipp because although both FlexLib and librecell may be in python it is unrealistic to expect them to be "mergeable", and, given that FlexLib can already create DRC-clean GDS-II files and Coriolis2 files, it would be a huge amount of effort for Staf to look at librecell to create something that he has already done successfully (in a different way, and one which he has verified), and i would be extremely surprised if he had time anyway, *and* he would have to go through an extremely comprehensive Verification process.
basically, although obviously i cannot and do not speak *for* him, what he is offering is a way for LibreSilicon to jump ahead in its testing and validation of some of the higher levels by offering access to reliable tested and proven lower levels.
LibreSilicon is attempting to bust a chain of around five separate and distinct NDA'd processes. this is almost impossible to do all at once.
if you have a failure and there are five unknowns, there are 2^5 (32) possible combinations, only one was the success you were looking for, and 31 possible failures.
the test was therefore, if you get a failure, spectacularly useless because you have *no idea* how to tell *which one* of the five unknowns caused the failure.
by reducing it to *one* unknown, you only have 2 combinations: success or fail. if you get a failure, then the source of the failure *must* be because of the *one* unknown.
this is black-box reverse-engineering, aka debugging, aka triaging, aka knowledge-derivation (Epistemology).
therefore my advice would be that if you get an opportunity to test any unproven part of the LibreSilicon chain against *anything* that is proven and validated and thus constitutes "known", then for goodness sakes take it.
best,
l.