NLnet LIP6 VLSI Project Grant

Project name

LIP6 VLSI Tools

Website / wiki

https://libre-soc.org/nlnet_2021_lip6_vlsi

Please be short and to the point in your answers; focus primarily on the what and how, not so much on the why. Add longer descriptions as attachments (see below). If English isn't your first language, don't worry - our reviewers don't care about spelling errors, only about great ideas. We apologise for the inconvenience of having to submit in English. On the up side, you can be as technical as you need to be (but you don't have to). Do stay concrete. Use plain text in your reply only, if you need any HTML to make your point please include this as attachment.

Abstract: Can you explain the whole project and its expected outcome(s).

LIP6's VLSI tools are one of the few user-operated toolchains for creating ASIC layouts where the full source code is available for inspection. This means that there is no opportunity for insertion of rogue hardware into an ASIC made by LIP6 tools which could compromise user trust, either locally or for internet use. Further: academic, public and free discussion are all engendered and fostered where at present NDAs rife through the VLSI Industry prevent and prohibit discussion and general improvements beneficial to users.

The expected outcome is to improve Coriolis2, HITAS/YAGLE and extend the whole toolchain so that it is faster, able to handle larger ASIC designs, and can perform Logical Validation. Also to be improved and tested is support for lower geometries (starting with 130nm)

Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?

LIP6 has created the ASIC Layout for the Libre-SOC 180nm ASIC that went to IMEC TSMC MPW in June 2021. It was developed entirely with Libre source code from HDL to GDS-II, the only NDA being the TSMC PDK.

Requested Amount

EUR $50,000.

Explain what the requested budget will be used for?

To improve the speed of the GUI front-end, to make it possible to handle larger ASIC designs, to add LVS capability, improve the internal data format (to better handle mixed case module and signal names), integrate the Static Timing Analysis tool (HITAS) and YAGLE gate-level extraction tool, to complete the conversion to python 3, to try smaller geometry ASICs (beginning with 130nm), and potentially investigate using multi-processing to speed up completion.

Does the project have other funding sources, both past and present?

LIP6 is part of Sorbonne University. The developers and maintainers of Coriolis2, HITAS/TAGLE, and Alliance, are all employed by Sorbonne University. For the Libre-SOC 180nm ASIC development an NLnet Grant was received, most of this work is now completed.

Compare your own project with existing or historical efforts.

The only other major proven VLSI Toolchain that is Libre Licensed and has created successful ASICs is Magic, selected as part of the OpenROAD toolchain. The entire OpenROAD toolchain is based on tcl/tk, a late 1980s scripting language technology. LIP6 VLSI tools are written in c++ and python, which are modern much better well-known programming languages. With python being so well-known and prevalent it is much easier to operate and coriolis2 for the development of complex reproducible ASIC layouts.

What are significant technical challenges you expect to solve during the project, if any?

The size of databases for VLSI ASIC Layout are extremely large, and a huge amount of computing power is needed, in one single machine. In addition a huge amount of specialist knowledge of VLSI and silicon is needed, completely separately from actual Software Engineering skills. These three factors combine to really tax the development of VLSI tools.

Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?

The entire source code is developed and available immediately, through LIP6 online resources including gitlab instance, mailing list, and website. Sorbonne University and LIP6 both have twitter accounts, and the developers write Academic papers and present at conferences. In addition, they work with the Libre-SOC Team to promote milestones and developments.

Extra info to be submitted

Questions 01 Oct 2020

What rates were used, and what main tasks are there

we estimate the rates based on LIP6 University hiring an additional engineer in France, at commercial rates, to be around EUR 3000 to 4000 a month.

  • training a new Engineer on coriolis2 c++/python internals: estimated 2 months
  • porting to python3 estimated 2 months (some libraries have to be removed and rewritten) including re-running several designs and checking they are still the same.
  • porting and updating of older (Alliance) layout extractor tools (solstice, equinox) to newer (c++/python) coriolis2 as pure netlist extractor: 2 months
  • adding limited electrical information extraction (wire resistance and capacitance) to the new layout extractor: 4-6 weeks
  • researching Logical Equivalence algorithms and Academic papers to ensure good knowledge before proceeding: 4 to 5 weeks.
  • implementation of Logical Equivalence checker: 10 to 14 weeks. this is not the same as an extraction tool (above). the LEQ tool uses (checks) the extracted database.
  • validation of Logical Equivalence checker against simulations and other (proprietary) checkers: 5 to 7 weeks
  • Identifying locations in 150,00 lines of code which can be parallelised by "divide and conquer", and those which can be "threaded": 3 weeks
  • separation of code into separate processes ("divide and conquer"): 2 months
  • adding "mutex" (exclusion) protection around code which can be "threaded": 2 months
  • debugging and stabilising of both of the above: 2 months.
  • alternative file formats and data structures which support case-sensitive net names: 2 months
  • HITAS/YAGLE integration into coriolis2, updating license and documentation: 2 months

You mention you will be able to perform Logical Validation. Can you expand a bit on that, what assurances could that bring?

Short summary:

there are two main ways to check that the HDL matches (is "equivalent") with the transistor layout, which has many changes made:

1) simulation. for large designs this requires supercomputers for months and sometimes years to complete the simulation. realistically, only a very small number of cycles can be run (several days to run one "clock" cycle).

2) Formal Mathematical "Logical equivalence". this performs boolean logic analysis and takes only hours (or days for very large designs).

it is extremely important for a professional VLSI toolchain to have this capability.

Longer version:

As I assume you are not familiar with making ASIC, I will try to explain with sufficient details while not being too long.

  • The Place & Route (P&R) step of making an ASIC takes in input, you can think of it as a "specification", a netlist.
  • A netlist is, or can be understood as:
    1. A specialized kind of electrical schematic with (in digital cases) all components being 1 bit memories or boolean functions (AND, OR, NOR, ...).
    2. A gigantic automaton, or set of big boolean equations. The fact that all the components are either memories or logical functions enable that.
  • Checking that the P&R has worked correctly amount to re-create a netlist from the layout generated by the router. And, then, perform a comparison of the specification netlist and the one coming from the layout. Of course, they must be identical... This is a "simple" graph comparison.
  • BUT, during the P&R, to meet electrical constraints like timing or good power supply, the specification netlist is modified. For example, the clock is split into a clock-tree to ensure synchronicity all over the design or some very long wire is broken into smaller ones. In some cases, more drastic operations can be performed, like completely changing the way the boolean computations are done.
  • So, after extraction, we end up with two different netlists, which should implement the same automaton, hence the concept of "logical equivalence" (LEQ).
  • Currently, with Alliance/Coriolis, we check that the modificated netlist is identical to the one extracted from the layout. But we don't know with mathematical certainty that the modificated one is equivalent (not equal) to the specification one. Of course we have made some other tests to check that (pattern simulation) but it's not foolproof (to have good coverage the number of pattern grows in 2N where N is the number of memory bits in the circuit...).