Op 21/07/2021 om 22:54 schreef David Lanzendörfer:

Hi Staf Ok. That was, what I had asked TSMC among other things in my email, so thanks for answering this question. I don't really care who and how. All I wanna do is generate a layout, which I place and route and revision control on my public Git repository and I want a foundry which tapes it out. With some delay I am now starting on preparing for the beta tape-out on TSMC 0.35um. Timeline: first design available in two weeks (Oct. 10th) and a final version one month from now (Oct. 29th). Payment should be done by Nov. 8th. Cost will likely by €1750 unless we see that your design is too big; to be worked in detail when we go along. Sorry for late notice. I think it is best to start now already the discussion by detailing a little more what you want to tape-out if you agree to the offer. I should be able to handle a GDSII that is DRC clean for the 0.35um SCMOS design rules; more precisely SCN4M_SUBM with lambda of 0.20. AFAIK this should be available in magic. I am working on MOSIS 0.35 SCMOS rules support for klayout. Time of arrival for the latter is unknown though; as I am currently a little bit overstretched. BTW: I did see that IMEC now works with you without even bothering to come back to me concerning my question whether it would be possible to at least give us access to some design rules, so that we can generate standard cells with them. If you could get us some design rules for IMEC, we could start generating standard cells and synthesize some test chips for this process... THAT would be interesting.

Sorry for not replying earlier but imec is only allowed to give anything coming from TSMC to customers who have signed the three-way NDA between the customer, imec and TSMC. TSMC will only agree to a new NDA after telling them the product you are working on and evaluation of your market potential. Also for imec these older nodes have too much overhead compared to possible financial benefit so they are mainly for existing users only. I have worked at imec so have personal connections there plus I was already 0.35um customer before this 'existing customers only' policy was put in place. The three-way NDA I have signed does not allow me to distribute the design rules or any process related information that is not already public so we'll have to work with SCMOS design rules. Another service I plan to offer is that I will deliver ASICs for RTL (nmigen, VHDL, Verilog, ...) you provide to me. The NDA does forbid me to distribute the final GDSII in the TSMC design rules though. In interest of full disclosure I want to mention I am also developing an own standard cell library. Given that I have signed the NDA I can make it conforming to these and thus be more efficient than ones that use the SCMOS rules; e.g. yours. Also, as I am working on an EDA flow fully done in python so I also don't see much collaboration potential with your work on standard cells. greets, Staf.

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.