Bug 630 - Skywater 130nm PDKMaster
Summary: Skywater 130nm PDKMaster
Status: RESOLVED FIXED
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:
 
Reported: 2021-04-24 12:13 BST by Luke Kenneth Casson Leighton
Modified: 2022-07-19 13:44 BST (History)
3 users (show)

See Also:
NLnet milestone: NLnet.2021-08-049.coriolis2
total budget (EUR) for completion of task and all subtasks: 0
budget (EUR) for this task, excluding subtasks' budget: 0
parent task for budget allocation:
child tasks for budget allocation:
The table of payments (in EUR) for this task; TOML format:


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.
Comment 11 Staf Verhaegen 2022-04-19 09:28:21 BST
Update to this task.

I got seriously delayed on this task due to bug fixing I had to do. For MPW4 some bugs were seen and plan was to fix these in a week or two before continuing with these. The actual bug fixing took more than 6 weeks. The bug fixing itself is on budget of another project (https://nlnet.nl/project/AMSL/index.html) but it caused a serious delay for this task.

When I was ready to continue development on this task Sky130 MPW5 was already pretty close so I focused on preparing a design for tape-out there.
* Project page: https://platform.efabless.com/projects/739
* gitlab repo: https://gitlab.com/Chips4Makers/sky130mpw5-sramtest
Unfortunately the design went not through the lottery and was thus not part of MPW5. It did have single port on the design so the c4m-flexmem part of this task is considered to be finished. There is still some work to fully finish the single port compiler but this will be done combined with the dual port compiler.

The port of the standard cells was also done and used in another MPW5 tape-out (https://platform.efabless.com/projects/691). Luckily this design was on MPW5.

In the mean time I also prepared a follow-up to my MPW4 IO test tape-out. This was a proposal from efabless to have the IO cells taped using wire-bonding. On MPW4 I had to remove the pad opening on the IO cells to avoid shorts with the redistribution (RDL) layer.
I targeted this design for ChipIgnite3 but due to changing circumstances @ efabless this likely also has to move to later tape-out.
* Project page: https://platform.efabless.com/projects/821
* gitlab repo: https://gitlab.com/Chips4Makers/sky130chipign3-iotest
With this design done also the work in this task on IO cells is completed.

So with all these designs this task is completed.