[libre-riscv-dev] [Bug 153] Top-level for NLNet 2019.10 ASIC Cell Libraries Project.

[whygee at f-cpu.org]

Hello Luke and list (Staf in particular)


On 2020-01-10 20:04, bugzilla-daemon at libre-riscv.org wrote:

> This is the top level issue for the Cell Libraries, on which all
> Cell Library Milestones will depend, for ease of tracking.

> http://bugs.libre-riscv.org/show_bug.cgi?id=153
> 
> --- Comment #1 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
> Staf, could you describe what the tasks are, in general? Basically, 
> this is
> pretty much exactly the list of tasks submitted in the NLNet Proposal.  
> we can
> then begin breaking them down into tasks, and assigned a budget to 
> each.  Then
> the process is: that list gets submitted to NLNet as a schedule on the
> Memorandum of Understanding, and future payments can be submitted.
> 
> it's important to note that each milestone *can* be further 
> sub-divided, they
> are very flexible.  so the "granularity" of these initial milestones 
> does *not*
> have to be to the absolute minutae: just top-level is good.

I've been working for a while on a gates library for my own use and it 
was picked
up by CERN because it's a free re-implementation of a proprietary 
library.
https://ohwr.org/project/microsemi-lib (and they use ProASIC3 family 
chips
in particle accelerators because it's less sensitive than SRAM-based 
FPGA)

What started as a tool to help me target a specific FPGA became a more
general tool to help with the gate-level design of my latest project :
https://hackaday.io/project/162594-vhdl-library-of-proasic3-gates
It could be more optimised for speed but would become more cumbsersome,
I think the flexibility and the wide range of features make it very 
useful
(I'm a speed freak but speed of development matters too, and any time
I start optimising something, it ends up in a publication 3 years 
later).

It can be extended easily and simulated with the Free GHDL compiler,
to help with DFT (Design For Test) : I can ensure functional 
verification
(not formal verification, which is a different thing).
The final goal is to let it create test vectors for on-wafer 
verification
before chips are packaged. I'm not there yet but it's already an 
invaluable
tool that is worth the time I've spent on it, as I can get a more 
precise
picture of the gate delays and dependencies in a circuit (as well as 
check
that the netlist is clean).

Why do I suggest it ? The least that I can benefit from is :
  - more tests and example designs to stress the code
  - more gates and targets (the core code can manage 4-inputs gates
        though I don't use them, yet)
  - linking the work to other families/technologies, ASIC gates in 
particular,
       because my projects aim at silicon (FPGA is just for mock-ups)
  - if all goes well, my CPU projects could use the ASIC Cell Libraries
       Luke mentions in the original post, which could be used as a
       reasonably small and well-controlled guinea pig before going
       to larger designs, such as the FP units.

Some synthesisers (such as Actel/MicroSemi/Microchip's) can output
a working VHDL netlist, I might one day tweak the system to parse EDIF
(VHDL is a real language, you know, I write awesome things with that)

So it's really a "backend tool" and "early functional verification 
tool",
it's free, self-contained, flexible and useful.

What do you think ?

yg