Bug 630 - Skywater 130nm PDKMaster
Summary: Skywater 130nm PDKMaster
Status: CONFIRMED
Alias: None
Product: Libre-SOC's first SoC
Classification: Unclassified
Component: Source Code (show other bugs)
Version: unspecified
Hardware: PC Linux
: --- enhancement
Assignee: Staf Verhaegen
URL:
Depends on:
Blocks: 589
  Show dependency treegraph
 
Reported: 2021-04-24 12:13 BST by Luke Kenneth Casson Leighton
Modified: 2022-01-04 14:36 GMT (History)
3 users (show)

See Also:
NLnet milestone: NLnet.2021.02A.CryptoRouter
total budget (EUR) for completion of task and all subtasks: 7000
budget (EUR) for this task, excluding subtasks' budget: 7000
parent task for budget allocation: 589
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:
"Staf Verhaegen" = 7000


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2021-04-24 12:13:35 BST
Porting PDKMaster technologies and libraries to Sky130 is needed,
including flow, simulations setup, design rules. (7000€)

* TODO: Sky130 technology setup in PDKMaster (750€)
* TODO: Port and optimization of c4m-flexlib (1250€)
* TODO: Port and adaption of c4m-flexio (125MHz digital IO target) (1500€)
* TODO: Port of c4m-flexmem; complete single port compiler (3500€)

https://gitlab.com/Chips4Makers/c4m-pdk-sky130
Comment 1 Luke Kenneth Casson Leighton 2021-10-11 15:59:45 BST
i had an idea, this is the kind of task that i feel would really suit jacob.
particularly because it involves using python in a coding style which involves
types.
Comment 2 Staf Verhaegen 2021-10-11 18:41:47 BST
For Sky130 support specifically the PDKMaster API is too unstable ATM and guiding somebody else to do it will take me more time than doing it myself.

I am actually making some progress, currently looking at IO cell. Will report when I have something to show.

I am stabilizing and documenting PDKMaster in another NLnet project on mixed-signal blocks. There could be some work done there but of course this is not directly related to Libre-SOC.
Comment 3 Luke Kenneth Casson Leighton 2021-10-11 19:07:53 BST
(In reply to Staf Verhaegen from comment #2)
> For Sky130 support specifically the PDKMaster API is too unstable ATM and
> guiding somebody else to do it will take me more time than doing it myself.

ahh ok.

> I am actually making some progress, currently looking at IO cell. Will
> report when I have something to show.
> 
> I am stabilizing and documenting PDKMaster in another NLnet project on
> mixed-signal blocks.

Op-Amps, ADC, DAC, Diff-pairs, Schmidt triggers in that by any chance?

> There could be some work done there but of course this
> is not directly related to Libre-SOC.
Comment 4 Staf Verhaegen 2021-10-11 19:34:53 BST
(In reply to Luke Kenneth Casson Leighton from comment #3)
> 
> Op-Amps, ADC, DAC, Diff-pairs, Schmidt triggers in that by any chance?

For first project I tried to stick to 'simple' architectures. It will be
- bandgap (e.g. voltage reference)
- PLL (based on libre-SoC one, but made scalable)
- ADC
- DAC

We will look at LDO (e.g. voltage regulator) but it is not defined as deliverable of the project.
Comment 5 Luke Kenneth Casson Leighton 2021-10-11 21:29:51 BST
(In reply to Staf Verhaegen from comment #4)

> For first project I tried to stick to 'simple' architectures. It will be
> - bandgap (e.g. voltage reference)
> - PLL (based on libre-SoC one, but made scalable)
> - ADC
> - DAC

... but even those are incredibly valuable.  that's fantastic.
Comment 6 Staf Verhaegen 2021-10-12 08:14:19 BST
BTW, Schmidt trigger I consider part of IO. It should not be that much of work, I can add it to NGI POINTER project. Likely Q2 next year.
Comment 7 Staf Verhaegen 2021-10-12 08:17:35 BST
Regarding diff-pairs. For pseudo differential you don't have to do anything, you just take two IOs and see that one signal is always the opposite of the other one.
If you talk about LVDS then it becomes a bigger design effort as LVDS is current driven not voltage driven.
Comment 8 Staf Verhaegen 2022-01-04 08:39:33 GMT
There has been two designs committed for Sky130 based on the port:
1) https://efabless.com/projects/600
For this project I delivered the standard cells using c4m-flexcell and my Sky130 port of PDKMaster. Myrtle provided the RTL and then Myrtle and Jean-Paul cooperated on the Coriolis P&R. The conversion of c4m-flexcell is only partial complete at the moment but plan is to 
2) https://efabless.com/projects/621
This is my test design for IO; as always I had hoped to do a little more simulation on the performance side so the design is likely sub-optimal. But at least we have something that can be used to verify design and as base for optimization later.

So I think the state of the subtasks is then as follows:
* Sky130 technology setup in PDKMaster: 100%
* Port and optimization of c4m-flexcell: 70%
* Port and adaption of c4m-flexio (125MHz digital IO target): 90%
* Port of c4m-flexmem; complete single port compiler: 20%

In the coming weeks I will focus on the following things:
- complete c4m-flexcell conversion
- memory block for mpw5
- stabilize PDKMaster API so it will finally become possible to accept external contributions
Comment 9 Staf Verhaegen 2022-01-04 09:03:48 GMT
> The conversion of c4m-flexcell is only partial complete at the moment but plan is to 
... before Sky130 MPW-5
Comment 10 Luke Kenneth Casson Leighton 2022-01-04 14:36:25 GMT
(In reply to Staf Verhaegen from comment #8)

> This is my test design for IO; as always I had hoped to do a little more
> simulation on the performance side so the design is likely sub-optimal. But
> at least we have something that can be used to verify design and as base for
> optimization later.

yes. nice to have the chance to test things at all, esp. on such a quick
iteration (and not need to pay for them!)

> So I think the state of the subtasks is then as follows:
> * Sky130 technology setup in PDKMaster: 100%
> * Port and optimization of c4m-flexcell: 70%
> * Port and adaption of c4m-flexio (125MHz digital IO target): 90%
> * Port of c4m-flexmem; complete single port compiler: 20%

i've just started running linux (with virtual memory) in simulations,
that gives L1 caches, which are (per cache, i.e. D-Cache and I-cache),
they are quite small so as not to take up huge resources:

* QTY 1of 16x 192-bit (24 byte per row), for cache tags, total 384 bytes
* QTY 4of 128x 64-bit (8 bytes per row), for actual data, total 4x 1024 bytes

so, per cache, there are *five* SRAM blocks per L1 cache:
one of 384 bytes, four at 1k.  they are also 1R *OR* 1W, rather
than "simultaneous support on the same clock for 1R AND 1W"
(i remember you said that makes a big difference)

i *may* have time to reorganise those into something more "normal", however
getting the microwatt-ported dcache/icache code running has taken almost a
year so it is... unwise, shall we say, to mess with it.

the microwatt I-cache is designed to be 1 cycle delay (read-en on one clock, 
data appears on the next), but interestingly - and this is more for FPGAs than
ASICs - a *two* cycle delay was added by the microwatt team to the D-Cache.
that can be handled with putting an external latch in front of the (exact
same cell) same SRAM used for I-Cache.

i remember seeing somewhere that the 2-clock delay on D-Cache is to be
able to meet Xilinx FPGA BRAM rules. but, the microwatt design is so
complex (the 2-cycle delay is embedded into the HDL) that i don't want to
alter it.


> In the coming weeks I will focus on the following things:
> - complete c4m-flexcell conversion
> - memory block for mpw5
> - stabilize PDKMaster API so it will finally become possible to accept
> external contributions

brilliant to hear.