one important task: the tricky part of writing the translation rules
symbolic to real (that is GDSII). 


http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2020-February/003848.html

also need the "target technology" (staf?)

In the NLNet project the tape-outs are foreseen to be on 180nm. I would like to stick to that for the moment.
I would see 130nm as a possible follow-up. These tape-outs will be sponsored by Google though, so I don't know if that is acceptable for libre-soc development.

> > This should be discussed with Staf also. This is important becausewe need that information to configure the symbolic layout for it(typically, how many metal layers, are they all usable for routingnormal wires and so on). Then we can make place & route that aresufficiently realistics.
>
> ok.

The process has 6 layers of metal. Metal2-Metal5 have the same min.space/min.width design rule. Metal6 is a thick metal so needs higher pitch. Via5 (between Metal5 and Metal6) also has bigger width and space so Metal5 will likely need to be higher pitch.
I think it is best to discuss the exact configuration first further off-line; exact dimensions of the technology are under NDA.

> > And lastly, there is the tricky part of writing the translation rulessymbolic to real (that is GDSII). We have tried to automate that inthe past but never finished for various non-technical reasons...This may be the occasion.
>
> that would be helpful, or at least know what needs to be done so itcan go on the list of tasks.

I will take care of S2R. DRC etc; of course if there is a bug in S2R I will need support.
I am doing standard cell development and S2R may not even be needed... In the mean time the nsxlib can be used for development of the place-and-route process.

* each intern receives EUR 600 per month from LIP6.fr.
* let us assume additional costs (management, other engineers) bringing that to EUR 1000 per month, particularly in case LIP6 interns are not available.
* let us assume 3 interns, that's EUR 3,000 per month.  around 4-6 weeks of that will be "training".

to do the layout, we can estimate between 6-9 months of work.  a "do everything automated and pray" is not going to work: we need to do low-level partial-manual, partial-automated layout.

then (as you surmise, Michiel), we will run into issues with nmigen.  already, we know for example that nmigen needs to be modified to support ASICs ("unknown / uninitialised" signal states). *migen* supports these, nmigen does not.  we would like to reserve around EUR 6,000 to 8,000 for the nmigen developers.

then, Jean-Paul explained that sometimes, you actually have to modify the verilog - small tweaking - to get it to properly in to shape for the layout.  this will need one of the people who wrote the nmigen HDL (me, or jacob) to take a look at it.  let us estimate 7-10 weeks here, around EUR 5,000.

so we are at around EUR 27,000 + 8,000 + 5,000 = EUR 40,000 *estimated*, hence the reason for requesting EUR 50,000, to be on the safe side.

I did have a chat with Jean-Paul and provided him information on the process that will be used for the prototype tape-out. He will have a further look to see if changes need to be done the coriolis setup.

(In reply to Staf Verhaegen from comment #5)
> I did have a chat with Jean-Paul and provided him information on the process
> that will be used for the prototype tape-out. He will have a further look to
> see if changes need to be done the coriolis setup.

fantastic that is very helpful.  i asdume it was private because it was under NDA (because of the TSMC NDA).

> i assume it was private because it was under NDA (because of the TSMC NDA).

Indeed, the information about the process I can make public is already in this thread.

jean-paul i am happy now with the experiments in #178 that what we want to do is achievable.  some interns could now fairly easily do the layout, what would the process and timeline be, there? do we need to bring Marie-Minerve in?

joost are you happy with this one?  i will begin creating toplevel bugreports.

http://lists.phcomp.co.uk/pipermail/arm-netbook/2020-March/016255.html

To be attached as Schedule A to the 2010-10-029 MoU

# create tutorial / workflow page for setup, establish first layout
we need the alliance2/coriolis workflow documented, a suite of tutorials
found (or written), and a "test project" to be done which gives a guide
to completion time of layout.
https://libre-riscv.org/HDL_workflow/coriolis2/

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=178
Budget: 3000

# layout for single-core 180nm ASIC
do layout for single-core 180nm ASIC including 1st level cache.
also peripherals: minimum priority is SDRAM 32 bit, 16550 UART, JTAG and SPI. secondary priorities are 64 bit SDRAM, GPIO, PWM, EINT, QSPI, SDMMC, RGBTTL, I2C and the pinmux.
package is to be QFP, maximum around 200 pins only including power and ground.

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=199
Budget: 9000

# layout for IEEE754 SIMD ALU 180nm
layout of the IEEE754 FPU "Function Units" needed, as part of the 180nm ASIC in bug #199. these are to be done as reuseable blocks because several FPMUL blocks, several FPSQRT blocks etc. are needed per core, and they are very large.

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=200
Budget: 7000

* bug #201 - create specifications for modifications needed for additional nmigen functionality.
nmigen needs some very specific additions to support the LibreSOC layout. these include adding SRNOR Latches, as well as "z" and "x" in signals (migen supported "x" but nmigen does not).

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=201
Budget: 9000

* bug #202 - modifications to HDL to suit coriolis2
coriolis2 layout expects some specific rules regarding connections between Cells. it has sometimes been the case that only when seeing a layout is it discovered that there is a mistake or it is suboptimal. a redesign of the nmigen HDL would be needed.

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=202
Budget: 6000

* bug #203 - bugfixes and modifications to alliance/coriolis2
coriolis2 was initially designed for small ASICs (50,000 gates).  it needs significant improvements to be suitable for use with LibreSOC due to its massive size (500,000 gates).  additionally, it would be useful to prepare for coriolis2 conversion and refactoring to use python3

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=203
Budget: 7000

* bug #205 - Documentation for maintenance purposes of layout
this is important for maintenance purposes and for later ASICs as well as educational purposes and for other developers on alternative projects.  the process and decisions on how the layout was done must be documented, here:
http://libre-riscv.org/3d_gpu/layouts/coriolis2_180nm/

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=205
Budget: 4000

* bug #204 - Transition support from symbolic to real layout and GDSII
Staf will need to do the "real" layout, using a "real" Cell Library instead of the purely symbolic one. Also the IO Pads. If there are any issues he will need  to resolve them in order to get a working ASIC.

URL: http://bugs.libre-riscv.org/show_bug.cgi?id=204
Budget: 5000

Sentence for MoU:

Reducing complexity makes software and hardware we rely on to provide crucial services and infrastructure more secure and reliable. Making sure that not only the tools to develop ASICs (coriolis2) but the ASIC itself is fully transparently developed leaves no opportunity for subversion of hardware.

On 23/11 a meeting was organised to discuss roadmap for tape-out of this 180nm prototype. Due delay in progress for both standard cell and Coriolis development the tape-out date has been moved to 2/12. One month is foreseen for verification so all input need to be available 30/10. Following milestones have been put forward to get there:

- now: freeze first version of libre-soc code, without any macro blocks
  on-chip RAM syntehsized to flip-flops
- 2/10: First layout of scaled standard cells
- 16/10: First dry run of P&R and test of tape-out flow with Europractice.
- 30/10:
  - Final code freeze of libre-soc nmigen code.
  - Final standard cell library
  - SRAM block finished
  - IO cell tested and finalized
  - PLL available
- 2/12: Hard deadline for tape-out submission of final layout.

This that need to be done from libre-soc side:
- now: finalize IO definition for current design (Luke & Staf)
- 30/10:
  - Finalize peripherals + IO (bug #490)
  - Finish MMU design + cache (bug #450, ...)
  - Determine expected operating frequency + align with PLL spec
  - Determine SRAM block dimensions + implement it (bug #502)

closing as completed, with many thanks to NLnet.