X-Git-Url: https://git.libre-soc.org/?a=blobdiff_plain;f=nlnet_2021_lip6_vlsi.mdwn;h=bd1e4734efd55ea335462670608ec48758151ed1;hb=f4c06f2c90ef7d8c38f39306713f37aad6d4564f;hp=1a3f7ba3677a60596b9bfc0279f6954c598be4c2;hpb=42c4de2389c2823addd1255ff5a1a4df10c9ff04;p=libreriscv.git diff --git a/nlnet_2021_lip6_vlsi.mdwn b/nlnet_2021_lip6_vlsi.mdwn index 1a3f7ba36..bd1e4734e 100644 --- a/nlnet_2021_lip6_vlsi.mdwn +++ b/nlnet_2021_lip6_vlsi.mdwn @@ -1,3 +1,9 @@ +# NLnet LIP6 VLSI Project Grant + +* Code: 2021-08-049 +* Approved: 09 Nov 2021 +* Toplevel bugreport: + ## Project name LIP6 VLSI Tools @@ -26,11 +32,16 @@ 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 @@ -39,19 +50,125 @@ 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 2^N where N is the number of memory + *bits* in the circuit...).