nlnet_2021_lip6_vlsi.mdwn

   1 # NLnet LIP6 VLSI Project Grant
   2
   3 * Code:         2021-08-049
   4 * Approved: 09 Nov 2021
   5 * Toplevel bugreport: <https://bugs.libre-soc.org/show_bug.cgi?id=748>
   6
   7 ## Project name
   8
   9 LIP6 VLSI Tools
  10
  11 ## Website / wiki
  12
  13 <https://libre-soc.org/nlnet_2021_lip6_vlsi>
  14
  15 Please be short and to the point in your answers; focus primarily on
  16 the what and how, not so much on the why. Add longer descriptions as
  17 attachments (see below). If English isn't your first language, don't
  18 worry - our reviewers don't care about spelling errors, only about
  19 great ideas. We apologise for the inconvenience of having to submit in
  20 English. On the up side, you can be as technical as you need to be (but
  21 you don't have to). Do stay concrete. Use plain text in your reply only,
  22 if you need any HTML to make your point please include this as attachment.
  23
  24 ## Abstract: Can you explain the whole project and its expected outcome(s).
  25
  26 LIP6's VLSI tools are one of the few user-operated toolchains for creating
  27 ASIC layouts where the full source code is available for inspection.
  28 This means that there is no opportunity for insertion of rogue hardware
  29 into an ASIC made by LIP6 tools which could compromise user trust, either locally or for
  30 internet use. Further: academic, public and free discussion are all
  31 engendered and fostered where at present NDAs rife through the VLSI
  32 Industry prevent and prohibit discussion and general improvements beneficial
  33 to users.
  34
  35 The expected outcome is to improve Coriolis2, HITAS/YAGLE and extend the
  36 whole toolchain so that it is faster, able to handle larger ASIC designs,
  37 and can perform Logical Validation. Also to be improved and tested is
  38 support for lower geometries (starting with 130nm)
  39
  40 # 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?
  41
  42 LIP6 has created the ASIC Layout for the Libre-SOC 180nm ASIC that went to
  43 IMEC TSMC MPW in June 2021.  It was developed entirely with Libre source code
  44 from HDL to GDS-II, the only NDA being the TSMC PDK.
  45
  46
  47 # Requested Amount
  48
  49 EUR $50,000.
  50
  51 # Explain what the requested budget will be used for?
  52
  53 To improve the speed of the GUI front-end, to make it possible to
  54 handle larger ASIC designs, to add LVS capability, improve the internal
  55 data format (to better handle mixed case module and signal names), integrate
  56 the Static Timing Analysis tool (HITAS) and YAGLE gate-level extraction tool, to complete the conversion
  57 to python 3,
  58 to try smaller geometry ASICs (beginning with 130nm), and potentially
  59 investigate using multi-processing to speed up completion.
  60
  61 # Does the project have other funding sources, both past and present?
  62
  63 LIP6 is part of Sorbonne University.  The developers and maintainers
  64 of Coriolis2, HITAS/TAGLE, and Alliance, are all employed by Sorbonne
  65 University. For the Libre-SOC 180nm ASIC development an NLnet Grant
  66 was received, most of this work is now completed.
  67
  68 # Compare your own project with existing or historical efforts.
  69
  70 The only other major proven VLSI Toolchain that is Libre Licensed and
  71 has created successful ASICs is Magic, selected as part of the OpenROAD
  72 toolchain.  The entire OpenROAD toolchain is based on tcl/tk, a late 1980s
  73 scripting language technology.  LIP6 VLSI tools are written in c++ and python,
  74 which are modern much better well-known programming languages. With python
  75 being so well-known and prevalent it is much easier to operate and
  76 coriolis2
  77 for the development of complex reproducible ASIC layouts.
  78
  79 ## What are significant technical challenges you expect to solve during the project, if any?
  80
  81 The size of databases for VLSI ASIC Layout are extremely large, and a huge
  82 amount of computing power is needed, in one single machine.  In addition
  83 a huge amount of specialist knowledge of VLSI and silicon is needed,
  84 completely separately from actual Software Engineering skills. These
  85 three factors combine to really tax the development of VLSI tools.
  86
  87 ## Describe the ecosystem of the project, and how you will engage with relevant actors and promote the outcomes?
  88
  89 The entire source code is developed and available immediately, through LIP6
  90 online resources including gitlab instance, mailing list, and website.
  91 Sorbonne University and LIP6 both have twitter accounts, and the developers
  92 write Academic papers and present at conferences.  In addition, they work
  93 with the Libre-SOC Team to promote milestones and developments.
  94
  95 # Extra info to be submitted
  96
  97 # Questions 01 Oct 2020
  98
  99 **What rates were used, and what main tasks are there**
 100
 101 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.
 102
 103 * training a new Engineer on coriolis2 c++/python internals: estimated
 104   2 months
 105 * 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.
 106 * porting and updating of older (Alliance) layout extractor tools
 107   (solstice, equinox) to newer (c++/python) coriolis2 as pure
 108   netlist extractor: 2 months
 109 * adding limited electrical information extraction (wire resistance
 110   and capacitance) to the new layout extractor: 4-6 weeks
 111 * researching Logical Equivalence algorithms and Academic papers to ensure good knowledge before proceeding: 4 to 5 weeks.
 112 * implementation of Logical Equivalence checker: 10 to 14 weeks.
 113   this is **not** the same as an **extraction** tool (above). the LEQ tool
 114   **uses** (checks) the extracted database.
 115 * validation of Logical Equivalence checker against simulations and other (proprietary) checkers: 5 to 7 weeks
 116 * Identifying locations in 150,00 lines of code which can be parallelised by "divide and conquer", and those which can be "threaded": 3 weeks
 117 * separation of code into separate processes ("divide and conquer"): 2 months
 118 * adding "mutex" (exclusion) protection around code which can be "threaded": 2 months
 119 * debugging and stabilising of both of the above: 2 months.
 120 * alternative file formats and data structures which support case-sensitive net names: 2 months
 121 * HITAS/YAGLE integration into coriolis2, updating license and documentation: 2 months
 122
 123 **You mention you will be able to perform Logical Validation.
 124 Can you expand a bit on that, what assurances could that bring?**
 125
 126 Short summary:
 127
 128 there are two main ways to check that the HDL matches (is "equivalent") with the transistor layout, which has many changes made:
 129
 130 1) simulation.  for large designs this requires supercomputers for months and sometimes years to complete the simulation.  realistically, only a
 131 very small number of cycles can be run (several days to run one "clock" cycle).
 132
 133 2) Formal Mathematical "Logical equivalence".  this performs boolean logic analysis and takes only hours (or days for very large designs).
 134
 135 it is extremely important for a professional VLSI toolchain to have this capability.
 136
 137 Longer version:
 138
 139 As I assume you are not familiar with making ASIC, I will try to
 140 explain with sufficient details while not being too long.
 141
 142 * The Place & Route (P&R) step of making an ASIC takes in input,
 143   you can think of it as a "specification", a netlist.
 144 * A netlist is, or can be understood as:
 145    1. A specialized kind of electrical schematic with (in digital
 146      cases) all components being 1 bit memories or boolean functions
 147      (AND, OR, NOR, ...).
 148    2. A gigantic automaton, or set of big boolean equations.
 149      The fact that all the components are either memories or logical
 150      functions enable that.
 151 * Checking that the P&R has worked correctly amount to re-create
 152   a netlist *from* the layout generated by the router. And, then,
 153   perform a comparison of the *specification* netlist and the
 154   one coming from the layout. Of course, they must be identical...
 155   This is a "simple" graph comparison.
 156 * BUT, during the P&R, to meet electrical constraints like timing or
 157   good power supply, the specification netlist *is modified*.
 158   For example, the clock is split into a clock-tree to ensure
 159   synchronicity all over the design or some very long wire is
 160   broken into smaller ones. In some cases, more drastic operations
 161   can be performed, like completely changing the way the boolean
 162   computations are done.
 163 * So, after extraction, we end up with two *different* netlists,
 164   which *should* implement the same automaton, hence the concept
 165   of "logical equivalence" (LEQ).
 166 * Currently, with Alliance/Coriolis, we check that the *modificated*
 167   netlist is identical to the one extracted from the layout.
 168   But we don't know with mathematical certainty that the
 169   *modificated* one is equivalent (not equal) to the specification
 170   one.
 171   Of course we have made some other tests to check that (pattern
 172   simulation) but it's not foolproof (to have good coverage the
 173   number of pattern grows in 2^N where N is the number of memory
 174   *bits* in the circuit...).