+# NLnet LIP6 VLSI Project Grant
+
+* Code: 2021-08-049
+* Approved: 09 Nov 2021
+* Toplevel bugreport: <https://bugs.libre-soc.org/show_bug.cgi?id=748>
+
## Project name
LIP6 VLSI Tools
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
# 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 2^N where N is the number of memory
+ *bits* in the circuit...).
projects / libreriscv.git / blobdiff