wafer.space Community - project-template

Getting some extreme hold violations when integrating a macro into chip_top that is not present when hardening the macro itself. Checking the logs, the worst slack is simply from the reset pad.

Tholin

Getting some extreme hold violations when integrating a macro into chip_top that is not present when hardening the macro itself. Checking the logs, the worst slack is simply from the reset pad.

Is that in ns? If so, oof. And could it be a bad capacitance extraction on the pads themselves?

That's probably because the macro has its own clock tree. So the clock that its internal FF sees is delayed by many ns compared to the clock on its input pin.

7:29 p.m.

If the CTS inside your top level project isn't setup to feed the macro an "early clock" (i.e. from the root of its clock tree instead of a leaf), that could explain why you see so many hold violations.

7:30 p.m.

(Just a theory of course ... can't do more than theorize without more data)

7:45 p.m.

I don't have a repo for this yet

7:46 p.m.

There is no CTS in the top level

7:46 p.m.

Actually, there is no standard cells in the top level

7:46 p.m.

Just macros

I guess this calls for a custom SDC file. I started by copying the SDC file provided by efabless for user project macros and will progressively modify it.

Literally nothing I do is changing the hold violations. Its refusing to budge.

Almost got it. Commit soon. Just trying to clean up my SDC file.

4:17 p.m.

What’s the point of set_driving_cell? Does it automatically determine slew rates and delays, or do I still need to specify those manually?

Doesn’t matter. I cannot set_driving_cell -lib_cell gf180mcu_fd_io__bi_24t inside my macro SDC files anyways:

Do you use the LibreLane version from the template or this branch? Otherwise the pad cells are not read in.

I cannot use the LibreLane version from the template for my macros. Python error.

6:17 p.m.

I mean, the PDK Version

6:18 p.m.

The error during GPL I reported before persists, so I cannot use the LibreLane version.

6:21 p.m.

But I also don’t understand what set_driving_cell even does. Right now my approach has been to determine values to set on set_input_delay , set_clock_latency, set_input_transition and set_clock_transition by manually interpreting the values in the liberty files for the IO pads.

6:21 p.m.

Except when it comes to the internal bus inside the chip, where I have to rely on STA for numbers.

Tholin

The error during GPL I reported before persists, so I cannot use the LibreLane version.

Actually, it seems fine now, at least on this one macro, but there is still a big difference in behavior.

6:24 p.m.

I just got to Stage 37 - Resizer Timing Optimizations (Post-Clock Tree Synthesis) on this CPU macro and on Iteration 0 its starting with a TNS of -5042 compared to main librelane, where I got -250.

6:24 p.m.

I changed nothing about the config.

6:24 p.m.

Just switched LL versions.

Yeah, I’m getting severe performance degradation in the wafer.space template LL version in two ways. The timings of the design are worse, and also the flows take forever to run. After one hour, it is still stuck in Timing Optimizations. This whole flow used to take < 15 minutes. @Leo Moser (mole99) (edited)

@Leo Moser (mole99) This page linked in the README of the template no longer exists.

12:24 a.m.

Tholin

I mean, the PDK Version

The wafer.space gf180mcu PDK requires the LibreLane version in the template (or from the branch).

Tholin

The error during GPL I reported before persists, so I cannot use the LibreLane version.

The issue is still open at OpenROAD's side: https://github.com/The-OpenROAD-Project/OpenROAD/issues/8229 However, as mentioned before, you can simply disable timing driven placement.

Tholin

But I also don’t understand what set_driving_cell even does. Right now my approach has been to determine values to set on set_input_delay , set_clock_latency, set_input_transition and set_clock_transition by manually interpreting the values in the liberty files for the IO pads.

set_driving_cell automates exactly that. It takes the values directly from the LIB.

Tholin

@Leo Moser (mole99) This page linked in the README of the template no longer exists.

Thanks for reminding me. The LibreLane docs have recently been updated.

Leo Moser (mole99)

set_driving_cell automates exactly that. It takes the values directly from the LIB.

Thank you. I could find 0 information about this command online.

https://github.com/The-OpenROAD-Project/OpenSTA/blob/master/doc/OpenSTA.pdf

OpenSTA/doc/OpenSTA.pdf at master · The-OpenROAD-Project/OpenSTA

OpenSTA engine. Contribute to The-OpenROAD-Project/OpenSTA development by creating an account on GitHub.

This is the ✨ magic ✨ line for the gf180mcu_fd_ip_sram__sram512x8m8wm1 SRAM:

add_pdn_stripe -grid macro -layer Metal4 -width 2.36 -offset 1.18 -spacing 0.28 -pitch 426.86 -starts_with GROUND -number_of_straps 2

It adds a power/ground pair on each side of the SRAM macro, directly above the pins. Since this uses the local coordinate system of the macro, you can move the macro around as you wish, the PDN straps will follow. As the PDN straps go all the way across the macro, connecting them to the PDN above is very easy.

1

8:35 p.m.

(top left)

8:35 p.m.

(top right)

8:35 p.m.

If you rotate the SRAM by 90 or 270 degrees, you need to use this line:

add_pdn_stripe -grid sram_macros_WE -layer Metal4 -width 2.36 -offset 1.18 -spacing 0.28 -pitch 479.88 -starts_with GROUND -number_of_straps 2

Unfortunately, the connection to VSS is not as good on the right side. It is better to use the first orientation. Don't forget the PDN connect:

add_pdn_connect \
    -grid macro \
    -layers "$::env(PDN_VERTICAL_LAYER) Metal3"

8:35 p.m.

Now I just need to make magic DRC happy, and then I can push the the example usage of the SRAM to the template repo.

Awesome

8:36 p.m.

I re-used my setup from GFMPW with a wrapper macro for the SRAM that just added the Metal4 strips.

8:36 p.m.

Which is not optimal

Well, if I remember correctly, Efabless used your solution too :)

Yeah. That’s where I got it from.

1

Leo Moser (mole99) started a thread. 2025-11-03 8:45 p.m.

I've setup a new system following the readme. And then just run the stock template as a sanity check, it does complete. But I'm seeing KLayout DRC errors. (along with timing/cap/slew warnings at some corners)

...
    "DM4.8": 0,
    "DF.12": 3,
    "NW.2b_MV": 16,
    "DPF.4": 38,
    "DCF.4": 48,
    "total": 105
}

Is this expected? Or does it indicate something I should debug with my environment first?

Leo Moser (mole99) started a thread. 2025-11-05 7:38 a.m.

It's update time! The project template has been updated with support for the foundry SRAMs! Two SRAMs of type sram512x8m8wm1 are instantiated in chip_core and placed inside the chip in two different orientations (north and east). If you add more SRAMs, make sure to update the LibreLane config (librelane/config.yaml) and the PDN configuration (librelane/pdn_cfg.tcl). In addition, an issue has been fixed with filler generation, the way how the KLayout DRC deck was invoked (connectivity rules), and an error in the seal ring generator. With these changes the template is now DRC clean for both the magic and KLayout DRC deck. Furthermore, the design is LVS clean and the there are no setup and hold violations for this example. Please update your projects to the latest template, and don't forget to update the PDK as well (make clone-pdk). Let me know if you have any questions.

5

2

1

Updated my AS2650v2 wafer.space port to use the new method for instantiating SRAMs. (edited)

1

10:46 p.m.

Works!

Great to hear

Tim 'mithro' Ansell pinned a message to this channel. 2025-11-07 12:03 p.m.

@Leo Moser (mole99) - Has performance / RAM usage changed much in the latest updates?

Tim 'mithro' Ansell

@Leo Moser (mole99) - Has performance / RAM usage changed much in the latest updates?

RAM usage has gone down drastically during the filler generation step after I fixed a bug there. However, that was already before this update.

How long does the template build (default) take for people ?

10:35 a.m.

Just wondering if my vm is slow or something ...

The CI takes around 50mins without DRC: https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19297076321/job/55181634117 Locally, it's faster for me. The DRC can then take an additional 1–1.5 hours.

1

Here full run took 3h30

Looking at timestamps, klayout drc was 2h 48 min of that. (edited)

What? My top-level DRC runs don't take nearly as long.

1:37 p.m.

I'm also still struggling with analog pads not getting wired up.

tnt

Here full run took 3h30

Looking at timestamps, klayout drc was 2h 48 min of that. (edited)

Just had a full run (inlcuding DRC) in 48:05 using the template

Huh ... that's worrying ...

Something changed. KLayout DRC is so much slower now.

Tholin

Something changed. KLayout DRC is so much slower now.

There haven't been changes to the PDK for two weeks: https://github.com/wafer-space/gf180mcu Although a number of changes are coming up.

GitHub - wafer-space/gf180mcu: Temporary development repository for...

Temporary development repository for the gf180mcuD PDK variant. - wafer-space/gf180mcu

And why are my analog signals not getting routed?

1

I CTRL+F’d for "analog" in the global routing logs and found nothing. Its skipping it.

Are they defined any differently in your netlist ?

No

Z80 design is finally green on github \o/ @Leo Moser (mole99) is there a way to download artifacts / GDS from github job for local inspection? I feel quite dumb for asking, but I couldn't figure how to do it so far

1

11:30 a.m.

Ah, when building locally on Mac it is necessary to increase file-descriptor count otherwise Magic streamout fails ulimit -n 1024

11:32 a.m.

@Leo Moser (mole99) I tried to add ulimit to flake.nix as shell hook, but failing so far even with ChatGPT "help"

(edited)

ReJ aka Renaldas Zioma

Z80 design is finally green on github \o/ @Leo Moser (mole99) is there a way to download artifacts / GDS from github job for local inspection? I feel quite dumb for asking, but I couldn't figure how to do it so far

Hi ReJ! Congrats

Just so you know, the CI only runs the implementation, as the DRC requires too much memory. So you need to make sure to run DRC locally. Yes, there are ways to upload artifacts: https://docs.github.com/en/actions/tutorials/store-and-share-data I haven't added this to the CI yet since I though it would quicky fill up the available storage space. But perhaps with a compression of the artifacts and a short retention time, it could be fine?

1

For some reason I get hold violations when I build locally (MacOS could be a problem here

), but it is fine building on github. Investigating atm. (edited)

ReJ aka Renaldas Zioma

Ah, when building locally on Mac it is necessary to increase file-descriptor count otherwise Magic streamout fails ulimit -n 1024

The Nix flake in the template uses LibreLane's create-shell: https://github.com/librelane/librelane/blob/dev/nix/create-shell.nix It seems that mkShell has a shellHook that could be used for that. However, I'm not sure how to override this from the template.

1

ReJ aka Renaldas Zioma

For some reason I get hold violations when I build locally (MacOS could be a problem here

), but it is fine building on github. Investigating atm. (edited)

Strange. There may be slight differences between the Linux and mac version of OpenROAD. If your hold violations are only just over the limit, perhaps that could make the difference. Make sure your clock tree is good, and you could increase the PL_RESIZER_HOLD_SLACK_MARGIN.

All of my configs contain

GRT_RESIZER_HOLD_SLACK_MARGIN: 0.1
PL_RESIZER_HOLD_SLACK_MARGIN: 0.1
PL_RESIZER_HOLD_MAX_BUFFER_PCT: 100

by default now since I had hold violations screw me over before.

1

@ReJ aka Renaldas Zioma If you're just running a batch job with no editing, you probably don't need file locking. Disabling this with the magic command locking disable may allow you to load large designs without changing the ulimit. http://opencircuitdesign.com/magic/commandref/locking.html (edited)

1

Is it expected to get some antenna violations from building the project template?

* Antenna
Failed 𐄂
Pin violations: 17
Net violations: 11
Check the report directory of OpenROAD.CheckAntennas.

checking the CI run here I do see the same violations: https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19297076321/job/55181634117

Remove set_driving_cell from SDC file · wafer-space/gf180mcu-pro...

Project template for wafer.space MPW runs using the gf180mcu PDK - Remove set_driving_cell from SDC file · wafer-space/gf180mcu-project-template@9b6c284

Yes

Ok, thanks

are they concerning or just something to waive?

That is something that requires a closer look into OpenROAD and LibreLane in order to find a proper solution. For large ratios you can manually insert ECO diodes. So far, most (all?) Tiny Tapeout designs seem to work just fine, and almost all of them have some antenna violations.

1

4:09 p.m.

Search for INSERT_ECO_DIODES in https://librelane.readthedocs.io/en/latest/reference/step_config_vars.html

Thanks, I guess I'll worry about that later then

1

5:25 p.m.

In chip_core.sv in the example project, why does it have keep attributes on the SRAM? Are they just left in from initial hacking or are they required?

    logic [7:0] sram_0_out;

    (* keep *)
    gf180mcu_fd_ip_sram__sram512x8m8wm1 sram_0 (
        `ifdef USE_POWER_PINS
        .VDD  (VDD),
        .VSS  (VSS),
        `endif

        .CLK  (clk),
        .CEN  (1'b1),
        .GWEN (1'b0),
        .WEN  (8'b0),
        .A    ('0),
        .D    ('0),
        .Q    (sram_0_out)
    );

5:26 p.m.

I will happily cargo cult it into my own memory wrappers, I was just curious

LukeW

In chip_core.sv in the example project, why does it have keep attributes on the SRAM? Are they just left in from initial hacking or are they required?

    logic [7:0] sram_0_out;

    (* keep *)
    gf180mcu_fd_ip_sram__sram512x8m8wm1 sram_0 (
        `ifdef USE_POWER_PINS
        .VDD  (VDD),
        .VSS  (VSS),
        `endif

        .CLK  (clk),
        .CEN  (1'b1),
        .GWEN (1'b0),
        .WEN  (8'b0),
        .A    ('0),
        .D    ('0),
        .Q    (sram_0_out)
    );

The former. You should be able to remove the (* keep *) and since Yosys sees that the outputs of the macro are being used, it will keep it. I'll remove it the next time I push another change to the template :)

ok nice thanks, I thought that would be the case but wasn't sure if there were hidden gotchas

1

5:30 p.m.

flow related question (if the answer is "RTFM" I can attempt to do that): in our ASIC flow at work, if I hand-instantiate a cell then the buffer width can be changed during layout but otherwise it'll remain the same cell with the same hierarchical path. Is that the case here or do I need to add (* dont_touch keep *) etc to my cell wrappers?

Cell attributes are currently not retained. You can set SYNTH_WRITE_NOATTR to false and they should be passed on to OpenROAD. However, there's RSZ_DONT_TOUCH_RX and RSZ_DONT_TOUCH_LIST if you want to keep a cell or net untouched. I think if you just set the (* keep *) attribute on a stdcell, Yosys will instantiate the stdcell and OpenROAD is free to change it's buffer width.

1

nice, thanks

5:35 p.m.

so it sounds like just putting (* keep *) on my cells is what I want; quite happy for the tools to change the drive as I don't fancy going and fixing all the transition violations myself

1

Leo Moser (mole99)

Cell attributes are currently not retained. You can set SYNTH_WRITE_NOATTR to false and they should be passed on to OpenROAD. However, there's RSZ_DONT_TOUCH_RX and RSZ_DONT_TOUCH_LIST if you want to keep a cell or net untouched. I think if you just set the (* keep *) attribute on a stdcell, Yosys will instantiate the stdcell and OpenROAD is free to change it's buffer width.

FYI time driven placement (enabled by default) ignores the RSZ_DONT_TOUCH_* setting and resizes the cells nonetheless. You can work around it by setting PL_TIME_DRIVEN to 0.

htamas

FYI time driven placement (enabled by default) ignores the RSZ_DONT_TOUCH_* setting and resizes the cells nonetheless. You can work around it by setting PL_TIME_DRIVEN to 0.

Yes, that is actually a "bug" in LibreLane as dont_touch does not prevent placement. So we could actually keep the attribute throughout GPL. See here: https://github.com/librelane/librelane/issues/695

1

Some incredibly minor DRCs (SRAM VDD/VSS completely unconnected while I figure out how the hierarchical paths are escaped) but in theory here is a processor, JTAG and 4 kB of RAM. Thanks for making the template, it made it super fast to get started

3

2

8:35 p.m.

Also I may have mixed up the SRAM dimensions and there is only a 15 um routing channel between the two rows

I'm guessing it's expected that the librelane-magicdrc makefile target crashes out during klayout/magic XOR, since klayout was skipped?

10:59 p.m.

i.e.

Reading /home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds ..
ERROR: In /nix/store/g3fml7j9yabcq2cmqm5yh19fxrm1h919-python3-3.12.10-env/lib/python3.12/site-packages/librelane/scripts/klayout/xor.drc: 'source': Stream has unknown format: /home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds in Layout::read
Total elapsed: 0.010s  Memory: 413.00M
ERROR: RuntimeError: 'source': Stream has unknown format: /home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds in Layout::read in Executable::execute
  /nix/store/g3fml7j9yabcq2cmqm5yh19fxrm1h919-python3-3.12.10-env/lib/python3.12/site-packages/librelane/scripts/klayout/xor.drc:78:in `execute'
  :/built-in-macros/drc_interpreters.lym:31:in `instance_eval'
  :/built-in-macros/drc_interpreters.lym:31:in `execute'
/home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/56-magic-streamout/chip_top.magic.gds
/home/luke/proj/riscboy-180/librelane/runs/RUN_2025-11-18_22-06-42/57-klayout-streamout/chip_top.klayout.gds

if it's a known issue with that target then I won't bother debugging

11:05 p.m.

Does this YAML config go anywhere other than chip_top.sdc?

# Clock
CLOCK_PORT: clk_PAD
CLOCK_NET: clk_pad/Y

CLOCK_PERIOD: 40 # 25 MHz

I saw the warning about multiple clocks in there but hoping I can just ignore that and write a normal .sdc file.

Leo Moser (mole99) started a thread. 2025-11-19 7:20 a.m.

LukeW

Does this YAML config go anywhere other than chip_top.sdc?

# Clock
CLOCK_PORT: clk_PAD
CLOCK_NET: clk_pad/Y

CLOCK_PERIOD: 40 # 25 MHz

I saw the warning about multiple clocks in there but hoping I can just ignore that and write a normal .sdc file.

From what I know, this is only passed on to the SDC file. Yes, you should be able to fully customize your SDC.

1

Leo Moser (mole99)

Hi ReJ! Congrats

Just so you know, the CI only runs the implementation, as the DRC requires too much memory. So you need to make sure to run DRC locally. Yes, there are ways to upload artifacts: https://docs.github.com/en/actions/tutorials/store-and-share-data I haven't added this to the CI yet since I though it would quicky fill up the available storage space. But perhaps with a compression of the artifacts and a short retention time, it could be fine?

DRC is passing (minus some antenna violations). Tiny Z80 looks so lonely in there. (edited)

4

7:55 a.m.

@Leo Moser (mole99) However I ran into some problems with gf180mcu-precheck repository. It:

crashes on my Ubuntu machine (perhaps running out of memory, investigating) during the Density check
fails to find qrcode library on OSX machine (*Error: Couldn't load the qrcode library. *)

(edited)

ReJ aka Renaldas Zioma

DRC is passing (minus some antenna violations). Tiny Z80 looks so lonely in there. (edited)

Congrats!

You did enable the environment within the precheck, right? Because I specifically request the qrcode Python module

https://github.com/wafer-space/gf180mcu-precheck/blob/1b639dff3d87a50e0759541701c7d162e1765630/flake.nix#L47

Leo Moser (mole99)

Congrats!

You did enable the environment within the precheck, right? Because I specifically request the qrcode Python module

https://github.com/wafer-space/gf180mcu-precheck/blob/1b639dff3d87a50e0759541701c7d162e1765630/flake.nix#L47

ah, this might be the problem pkgs.stdenv.isLinux

1

You're absolutely right! It's a leftover from a different flake, I completely overlooked it.

8:05 a.m.

Pushing a fix shortly...

1

8:09 a.m.

@ReJ aka Renaldas Zioma You can give it another try now.

1

Leo Moser (mole99)

@ReJ aka Renaldas Zioma You can give it another try now.

Worked like a charm. Precheck passed!

2

is there an additional log to get more information about librelane build failures? Trying a test build of what I have to see the end-to-end workflow, and it's failing to wire up power pins to my sram macos (deep in the bowels of my project)

Connecting power net VDD to i_chip_core.u_core.tta_0.lsu_fu_0.sram_512x32_0.gf180mcu_fd_ip_sram__sram512x8m8wm1_0/VDD…
[INFO] Made 0 connections.
[06:50:13] ERROR    The following error was encountered while running the flow:  __main__.py:189 
    Odb.SetPowerConnections failed with the following errors:
         add_global_connections failed to make any connections for 'i_chip_core.u_core.tta_0.lsu_fu_0.sram_512x32_0.gf180mcu_fd_ip_sram__sram512x8m8wm1_0/VDD' to VDD.

I've gone through and added the conditional stuff where needed

`ifdef USE_POWER_PINS
.VDD  (VDD),
.VSS  (VSS),
`endif

2:59 p.m.

ah... yosys is deleting my sram module (and a bunch of other stuff) Deleting now unused module tta::sram::sram_512x32.

1

3:00 p.m.

ok new question.... why?

I know there's a "keep" annotation to force it, but I don't think any of this is dead code? but I have no idea how synthesizing works

BreakingTaps

is there an additional log to get more information about librelane build failures? Trying a test build of what I have to see the end-to-end workflow, and it's failing to wire up power pins to my sram macos (deep in the bowels of my project)

Connecting power net VDD to i_chip_core.u_core.tta_0.lsu_fu_0.sram_512x32_0.gf180mcu_fd_ip_sram__sram512x8m8wm1_0/VDD…
[INFO] Made 0 connections.
[06:50:13] ERROR    The following error was encountered while running the flow:  __main__.py:189 
    Odb.SetPowerConnections failed with the following errors:
         add_global_connections failed to make any connections for 'i_chip_core.u_core.tta_0.lsu_fu_0.sram_512x32_0.gf180mcu_fd_ip_sram__sram512x8m8wm1_0/VDD' to VDD.

I've gone through and added the conditional stuff where needed

`ifdef USE_POWER_PINS
.VDD  (VDD),
.VSS  (VSS),
`endif

You can find all log files and artifacts in the librelane/runs/* directory. Making the power connections in the RTL is one way, the other is to use PDN_MACRO_CONNECTIONS.

1

aha! PDN_MACRO_CONNECTIONS looks much more convenient

BreakingTaps

ok new question.... why?

I know there's a "keep" annotation to force it, but I don't think any of this is dead code? but I have no idea how synthesizing works

Yes, if Yosys removes the SRAM instances, it's because it recognises that none of the outputs are being used. Optoimizing it away

3:02 p.m.

So there is probably an issue in your RTL.

hm, it seems to be deleting basically my entire project

3:09 p.m.

if a module doesn't have an output, does it get optimized away? I've only wired up inputs to my processor so far (clock, reset, uart loading, etc). so it can run programs but no output

Yes. Yosys checks input to output paths to see what it can optimize away, in my experience.

1

3:13 p.m.

If it sees 0 outputs, it just goes "this whole design is just void"

argh

3:14 p.m.

gotcha, thanks!

wired in a temporary output, got the ball moving again! Just to confirm, it looks like the sram macros have to be placed manually on the die? (I see the placement stuff in pdn_cfg.tcl for the two macros in the demo chip_top)

3:55 p.m.

and in the config toml

Yes exactly. Placement is defined in config.yaml and connection to PDN in pdn_cfg.tcl.

great, thank you! out of curiosity, is there a reason placements are done by hand instead of being auto-placed by librelane? because they are so large you want a human to do it?

4:02 p.m.

(entirely new to this whole world, so lacking a lot of background context

)

No problem! In our case, manual placement is mostly fine, since there are only a handful of SRAM macros to place. There was some effort to integrate OpenROAD's automatic macro placer into LibreLane, but it wasn't completed: https://github.com/librelane/librelane/issues/537

Makes sense. Juice probably isn't worth the squeeze given the nature of projects here. Easier to do it by hand

BreakingTaps

great, thank you! out of curiosity, is there a reason placements are done by hand instead of being auto-placed by librelane? because they are so large you want a human to do it?

Not my domain (I do frontend) but I can take a couple of guesses at the reasons: 1. Difficult to move large macros later in pnr due to the number of ripups, so there's a high likelihood of automatic placement backing itself into a corner and making the design unroutable. 2. Desire for consistency between implementation runs -- implementation is usually iterative with new RTL updates regularly coming in, and you want to know whether issues are due to RTL changes etc as opposed to just the tools having a bad day 3. The power connections to macros like SRAMs etc are usually hand-tuned for best results, and you don't want to rip this up every time

1

4:37 p.m.

At least that's for the commercial projects I've worked on. Different dynamics for the new open-source stuff

Ahh interesting!

I'd love to have suggestions though. Like it would just do a rough electrostatic-style placement of all standard cells and macro to sort of see how things arrange themselves and make sure I'm not placing those macro at a very inconvenient spot.

1

4:39 p.m.

And then I can lock it there and never move it while refining RTL.

Yeah, like BRAM locking on FPGA

4:42 p.m.

It's a really interesting question, I never thought about it. I just sort of accepted the layout folks at work spent days gently massaging the RAMs into place

still not 100% confident yosys didnt optimize away half the design and my laptop locked up so I'm not sure if it actually completed successfully before I had to go to work...but it did finish enough to generate an output GDS

so much unused space

(edited)

1

My custom ASIC KianV SV32 SoC is now finalized! RV32IMA + Zicntr/Zicsr/Zifencei/SSTC with full MMU — running uLinux, Linux, and xv6. With huge help from @Leo Moser (mole99) — and thanks to @Tim 'mithro' Ansell

3

4

1

BreakingTaps started a thread. 2025-11-19 6:08 p.m.

It will run mailine linux/uLinux/XV6 Unix or newer

I’ve shared a Python script to render the chip layout from GDS. It’s pretty slow and memory-hungry, but it works. I’ll put it on my GitHub repo later.

ieee_export_chip.py

13.52 KB

1

definitely will try that when I get home!

This script generates 3D models and is multithreaded https://github.com/AvalonSemiconductors/gfmpw1-multi/blob/main/gds2gltf.py

2

Richtig geil...danke

And here is my entry in the list of layout renderers. It simply uses KLayout (pip install klayout) to render the layout and can therefore load both GDS and OAS. I disabled the filler layers to make the layout stand out better.

7:07 p.m.

2

7:07 p.m.

lay2img.py

2.19 KB

7:08 p.m.

You can run it as python3 lay2img.py librelane/runs/<timestamp>/final/gds/chip_top.gds image --width 4069 --height 6144 in the root of your repository.

Rendering the AS2650-2 with @asic destroyer ’s script shows some missing wires.

Tholin

This script generates 3D models and is multithreaded https://github.com/AvalonSemiconductors/gfmpw1-multi/blob/main/gds2gltf.py

Watch your RAM use running this, btw. It gets intense.

1

asic destroyer

My custom ASIC KianV SV32 SoC is now finalized! RV32IMA + Zicntr/Zicsr/Zifencei/SSTC with full MMU — running uLinux, Linux, and xv6. With huge help from @Leo Moser (mole99) — and thanks to @Tim 'mithro' Ansell

Super cool!

1

Tim 'mithro' Ansell started a thread. 2025-11-19 8:47 p.m.

LukeW

Some incredibly minor DRCs (SRAM VDD/VSS completely unconnected while I figure out how the hierarchical paths are escaped) but in theory here is a processor, JTAG and 4 kB of RAM. Thanks for making the template, it made it super fast to get started

What MCU is that Hazard3?

Tim 'mithro' Ansell started a thread. 2025-11-19 8:52 p.m.

LukeW

It's a really interesting question, I never thought about it. I just sort of accepted the layout folks at work spent days gently massaging the RAMs into place

Automatic macro placement stuff was one of the big things that Google's ML team did for the TPU

1

Tim 'mithro' Ansell

Automatic macro placement stuff was one of the big things that Google's ML team did for the TPU

https://github.com/google-research/circuit_training

GitHub - google-research/circuit_training

Contribute to google-research/circuit_training development by creating an account on GitHub.

1

Tim 'mithro' Ansell

What MCU is that Hazard3?

Yep, it's Hazard3. There will be at least two of them once I'm done (one for main game firmware and one for audio processing)

LukeW

Yep, it's Hazard3. There will be at least two of them once I'm done (one for main game firmware and one for audio processing)

What about one for graphics?

RISCBoy PPU is already quite programmable

8:57 p.m.

and can do affine blits and stuff at 1 pix/clk

8:57 p.m.

so I'm planning to use that with external parallel async SRAM

8:57 p.m.

serial SPI LCD

2

BreakingTaps

still not 100% confident yosys didnt optimize away half the design and my laptop locked up so I'm not sure if it actually completed successfully before I had to go to work...but it did finish enough to generate an output GDS

so much unused space

(edited)

@Leo Moser (mole99) - Maybe LibreLane needs container limits to stop locking computers up or something?

would love to do DVI out but if I only have 13 days til final GDS then now is not the time for custom layout

1

8:59 p.m.

I'll probably have some std cell-based DCOs on board to play with generating internal clocks but nothing of the quality you'd need for DVI

LukeW

would love to do DVI out but if I only have 13 days til final GDS then now is not the time for custom layout

Sleep is for the weak

(edited)

sleep is for two weeks from now

Oh. Tapeout is that soon?

9:08 p.m.

Uhhhhh

9:08 p.m.

Yeah, sleep is indeed for two weeks from now

Dammit, there is too many cool things to look at in this channel and I need to be finishing the GDS prechecking on platform.wafer.space

1

Leo Moser (mole99)

Click to see attachment 🖼️

Ja, Leo ist richtig geil!

1

We definitely need a gallery or something!

2

Tim 'mithro' Ansell

@Leo Moser (mole99) - Maybe LibreLane needs container limits to stop locking computers up or something?

hehe well I think we can blame my laptop for this one. the display/linux controlling it seems to get flaky in memory-constrained circumstances

10:54 p.m.

(i also forgot to boost swap before starting it)

How we can do the same here, excluding gf180mcu_fd_sc_mcu7t5v0__oai21_1 @Leo Moser (mole99) https://discordapp.com/channels/1009193568256135208/1438584424554827788 (edited)

Since the last announcement, a number of important changes have been made to both the PDK and the template.

PDK

1. #3: The seal ring generator has been updated.

Now actually includes the glass cut.

Pplus does not overlap comp, as required by DRC.

2. #3: Filler generation has been updated to ensure 10um spacing to the seal ring. (This was only a problem for smaller slot sizes).

Template

1. The core ring now connects to all vss pads again. (thanks @tnt!) 2. #22: Magic has been updated with fix that significantly reduces peak memory usage. 3. #21: The render-image Make target renders the GDS layout. 4. #21: The CI has been updated.

Commands in the nix shell are now only executed once. (thanks @Egor Lukyanchenko!)

Create a summary and upload artifacts (gds and image) (Example)

5. #23: Workaround for a PDN issue. 6. #24: Fix antenna violations using DRT_ANTENNA_REPAIR_ITERS (disable if any issues occur). 7. The PDK version has been pinned. Please update your repository in line with the template and clone the latest PDK.

6

Leo Moser (mole99) pinned a message to this channel. 2025-11-20 6:38 p.m.

@Leo Moser (mole99) Is the environment of the leo/gf180 branch of libre lane good ? That's what I'm using since TT is not based at all on the template .

Leo Moser (mole99)

Since the last announcement, a number of important changes have been made to both the PDK and the template.

PDK

1. #3: The seal ring generator has been updated.

Now actually includes the glass cut.

Pplus does not overlap comp, as required by DRC.

2. #3: Filler generation has been updated to ensure 10um spacing to the seal ring. (This was only a problem for smaller slot sizes).

Template

1. The core ring now connects to all vss pads again. (thanks @tnt!) 2. #22: Magic has been updated with fix that significantly reduces peak memory usage. 3. #21: The render-image Make target renders the GDS layout. 4. #21: The CI has been updated.

Commands in the nix shell are now only executed once. (thanks @Egor Lukyanchenko!)

Create a summary and upload artifacts (gds and image) (Example)

5. #23: Workaround for a PDN issue. 6. #24: Fix antenna violations using DRT_ANTENNA_REPAIR_ITERS (disable if any issues occur). 7. The PDK version has been pinned. Please update your repository in line with the template and clone the latest PDK.

Does the template have a CHANGELOG file or something? Seems like this would be great to include in that.

10:09 p.m.

@Leo Moser (mole99) - BTW Did you see that I made the git describe version number work?

tnt

@Leo Moser (mole99) Is the environment of the leo/gf180 branch of libre lane good ? That's what I'm using since TT is not based at all on the template .

Yes, the template uses leo/gf180mcu as well. Unfortunately, I still need to rebase from time to time, so any commit hashes that you reference might break.

@Leo Moser (mole99) I meant the nix environment of the leo/gf180mcu. Digging a bit I think the magic version is different.

Leo Moser (mole99)

Since the last announcement, a number of important changes have been made to both the PDK and the template.

PDK

1. #3: The seal ring generator has been updated.

Now actually includes the glass cut.

Pplus does not overlap comp, as required by DRC.

2. #3: Filler generation has been updated to ensure 10um spacing to the seal ring. (This was only a problem for smaller slot sizes).

Template

1. The core ring now connects to all vss pads again. (thanks @tnt!) 2. #22: Magic has been updated with fix that significantly reduces peak memory usage. 3. #21: The render-image Make target renders the GDS layout. 4. #21: The CI has been updated.

Commands in the nix shell are now only executed once. (thanks @Egor Lukyanchenko!)

Create a summary and upload artifacts (gds and image) (Example)

5. #23: Workaround for a PDN issue. 6. #24: Fix antenna violations using DRT_ANTENNA_REPAIR_ITERS (disable if any issues occur). 7. The PDK version has been pinned. Please update your repository in line with the template and clone the latest PDK.

@Leo Moser (mole99) it might be a red herring, but I think I started getting KLayout DRC violations when running a precheck. This started after merging the latest template changes. I get 12 drc errors and if I read it correctly (drc.klayout.lyrdb file) errors are in sealring (edited)

tnt

@Leo Moser (mole99) I meant the nix environment of the leo/gf180mcu. Digging a bit I think the magic version is different.

Right! I override the magic version in the template. There is no change in functionality, but it reduces peak RAM usage. I can update nix-eda as a whole in the leo/gf180mcu branch once the latest Yosys hang is fixed.

ReJ aka Renaldas Zioma

@Leo Moser (mole99) it might be a red herring, but I think I started getting KLayout DRC violations when running a precheck. This started after merging the latest template changes. I get 12 drc errors and if I read it correctly (drc.klayout.lyrdb file) errors are in sealring (edited)

ReJ, yes that is expected. Sorry! I still need to sync the precheck with the latest changes to the template. I started a run yesterday but didn't get to push the changes yet.

Tim 'mithro' Ansell

Does the template have a CHANGELOG file or something? Seems like this would be great to include in that.

Yes, we can use versions and a changelog for the template from now on.

Tim 'mithro' Ansell

@Leo Moser (mole99) - BTW Did you see that I made the git describe version number work?

I would prefer tags in the format x.y.z, like in the gf180mcu repository. I'll update the tag.

Leo Moser (mole99)

I would prefer tags in the format x.y.z, like in the gf180mcu repository. I'll update the tag.

with git-describe you get v0.0-<commits>-<hash> which some people map to v0.0.<commits>

6:19 a.m.

But I don't really care that enough, do what you prefer

Yes, git-describe is really neat

I'm generally following the conventions in LibreLane to keep things simple.

Leo Moser (mole99)

ReJ, yes that is expected. Sorry! I still need to sync the precheck with the latest changes to the template. I started a run yesterday but didn't get to push the changes yet.

no worries! Happy to hear it is expected (edited)

1

Random piece of information, template project also works fine with gf180mcu_fd_sc_mcu9t5v0 (edited)

1

ReJ aka Renaldas Zioma

no worries! Happy to hear it is expected (edited)

You could give this PR a try: https://github.com/wafer-space/gf180mcu-precheck/pull/3

chore: update precheck to match template by mole99 · Pull Request ...

Update PDK_TAG to 1.1.0 Pin nix-eda to 5.9.0 and override magic to 8.3.576

Antenna check is taking forever

It's been an hour and I think it's still at Metal1. (edited)

I mean, you do have a lot of Metal1 in the layout if the whole core area has a standard cell grid in it.

2:33 p.m.

My flows are faster than average, I believe, because I only have macros in the top-level and no cell grids.

Well the top level of TT doesn't have any cell grid

2:34 p.m.

and this test sample is only maybe ... 15~20% filled.

That’s probably already denser than my chip.

2:38 p.m.

But antenna check takes a few seconds for me, so something seems wrong there.

Are you talking about KLayout.Antenna or OpenROAD.CheckAntennas step ?

Both, I guess.

2:43 p.m.

A step getting stuck for that long would be quite memorable and I don’t remember anything other than STA and DRC taking forever.

Well https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/librelane/config.yaml#L6 It's disabled in your default config so you'd have to enable it to see it.

I just pushed to the repo

3:00 p.m.

Has my analog pad fixes now

tnt

Well https://github.com/AvalonSemiconductors/ws-submission-2025/blob/main/librelane/config.yaml#L6 It's disabled in your default config so you'd have to enable it to see it.

@tnt Should we enable it?

5:17 p.m.

@Leo Moser (mole99) (edited)

It's been running here for 4h ....

5:18 p.m.

so I get why it's disabled

1

Does anyone know which step in the (template) flow is responsible for adding buffers on a high fanout net? I have a reset net with a fanout of ~1k and in my powered netlist ./25-openroad-globalplacementskipio/chip_top.pnl.v still has the reset synchroniser output going directly to all ~1k loads without buffering. This makes the following STAs meaningless because the reset net has like a 100 ns rise time

ah, somewhat answered my own questions: 1. the buffers are added in the repairdesignpostgpl step 2. my issue with insane violations was actually because removing the clock variables from your .yaml and just defining clocks in your .sdc completely skips CTS, so I had like a 450 ns clock rise/fall, and all the flop timings are derated according to slew

2

Does anyone have a design which currently fails precheck quickly?

8:31 p.m.

I need some test cases for the manufacturability checking testing

What if you just run precheck against a corrupted GDSII file so it fails just loading?

Yeah, I can do those ones pretty easy, I'm other an otherwise compliant design that just has DRC violations.

@Leo Moser (mole99) - I believe your pull request to the precheck is now merged and the docker image got updated.

Antenna check is going on 18h, so I think I'll give up on it

Tim 'mithro' Ansell

@Leo Moser (mole99) - I believe your pull request to the precheck is now merged and the docker image got updated.

Thanks!

tnt

Antenna check is going on 18h, so I think I'll give up on it

Yeah, I also remember it taking forever during my testing

For the second shuttle, I can look into rewriting/improving the KLayout antenna checks (there have been some updates to KLayout), or using a magic antenna check. But I don't see how we can possibly enforce zero antenna violations on the first shuttle.

I ran a precheck on the GDS with PDK updated to 1.1.0 and new Filler and Sealing. It has been successfully completed. It took 4 hours and 36 minutes on Ubuntu24.04. The PC specifications are: "Ryzen 3 Pro 4350G (4-core, 8-thread) & MEM: 64GB". However, when running on WSL, Klayout crashed when signals such as SIGKILL were sent or no response. When I used about 14GB of memory, Klayout has crashed.

Precheck Log

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/tree/main/precheck_log/RUN_2025-11-22_16-51-07

Project GitHub

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1

Interesting I'm getting quite a few

Error while reading cell "tt_gf_wrapper" (byte position 137203656): Warning: cell "Metal1_fill_cell" placed on top of   itself.  Ignoring the extra one.

during the pre-check, maybe something's wrong somewhere in fill generation ?

tnt

Interesting I'm getting quite a few

Error while reading cell "tt_gf_wrapper" (byte position 137203656): Warning: cell "Metal1_fill_cell" placed on top of   itself.  Ignoring the extra one.

during the pre-check, maybe something's wrong somewhere in fill generation ?

You can ignore those for now. From what Tim had looked into it, these are most likely real overlapping cells generated by KLayout during filler generation. I still need to prepare a reproducible for Matthias.

2

Noritsuna Imamura

I ran a precheck on the GDS with PDK updated to 1.1.0 and new Filler and Sealing. It has been successfully completed. It took 4 hours and 36 minutes on Ubuntu24.04. The PC specifications are: "Ryzen 3 Pro 4350G (4-core, 8-thread) & MEM: 64GB". However, when running on WSL, Klayout crashed when signals such as SIGKILL were sent or no response. When I used about 14GB of memory, Klayout has crashed.

Precheck Log

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/tree/main/precheck_log/RUN_2025-11-22_16-51-07

Project GitHub

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1

Hi @Noritsuna Imamura, with which error does KLayout crash?

Leo Moser (mole99)

Hi @Noritsuna Imamura, with which error does KLayout crash?

It's like this.

Noritsuna Imamura

It's like this.

Could you please open an issue in the precheck repo with all the details and a link to the GDS? Unfortunately, I cannot look into it right now, but I would like to try and see if it crashes on my end as well. You should be able find the full KLayout log in the run directory.

1

1

It worries me a bit that 30 min into the execution of the klayout drc step, it hasn't even started with the "Executing rule XXX" phase of the check

Is there a way for me to run the KLayout DRC checks on a GDSII file without running the full chip_top flow? I just want to know if my DACs still have DRC errors without waiting 4+ hours for DRC to run on the full chip.

klayout -b -zz -r ${PDK_ROOT}/gf180mcuD/libs.tech/klayout/tech/drc/gf180mcu.drc -rd input=your.gds -rd report=drc.klayout.lyrdb -rd feol=True -rd beol=True -rd dummy=True -rd offgrid=True -rd conn_drc=True -rd wedge=True -rd run_mode=deep -rd thr=16

5:23 p.m.

That's the command run by the pre-check.

Its so annoying to me that I can spend days putting something together in magic until its DRC clean, and then KLayout comes in "Actshually, there is 107 DRC errors"

1

I think that's pretty much the deal of being on this first run is that you're beta testing stuff ...

5:43 p.m.

Although I'm looking at some of the error in KLayout and ... they might be false positive.

1

I have tons of DRC errors for this. So uhm. Is it too long? Too short? What is the limit?

5:45 p.m.

Am I about to have to dive into some source code just to know what this is about?

5:46 p.m.

No errors in magic

Yes, looking at that now. I think there is a missing marker layer.

1

5:47 p.m.

5V and 6V transistors have no difference except the channel length.

What is the marker layer?

And there is a marker layer (purely informational, doesn't mean anything for manufacturing) to tell klayout that a given transistor is meant to be 5V and not 6V.

5:48 p.m.

v5_xtor

5:50 p.m.

112/1

string MASKHINTS_V5_XTOR does not have an effect. Will actually have to draw this in KLayout.

Yeah, MASKHINTS only works if support for maskhints for that particular layer is in the tech file.

5:51 p.m.

@Tim Edwards it seems magic isn't creating that layer at all, I see no support for writing it in the tech file ?

But also, these are supposed to be 6V devices

5:52 p.m.

But also, magic extracts them as 5V?

5:52 p.m.

There is weird things going on here

5:59 p.m.

Oh no, the transistors are indeed too small for 6V devices - and magic doesn’t see a problem with that.

5:59 p.m.

In other words, I’d like to report a bug...

I'm guessing the mv devices (which are the ones used in your design) are meant to be the 5V one and the hv would be the 6V ones.

6:10 p.m.

Ah no, I think magic doesn't differentiate between 5V and 6V devices at all.

6:10 p.m.

both are mvnfet / mvpfet and it's just whatever length you use that will dictate which one it is ... (edited)

hv is 10V

6:18 p.m.

GF180mcu has LV, MV 5V, MV 6V, Native Vt, HV LDMOS

6:18 p.m.

Which are 3.3V, 5V, 6V, 6V and 10V respectively.

6:20 p.m.

Here is another DRC error that I’m seeing a lot of in KLayout but that isn’t represented in magic.

6:20 p.m.

Even though it totally could be.

I think there are also drc not checked by klayout because anything wider than 30u must be slitted and it didn't spot that.

@Leo Moser (mole99) I think the KLayout deck has issues.

6:42 p.m.

"M3.2b : Space to wide Metal3 (length & width > 10um) : 0.3µm"

6:43 p.m.

That's a 0.28u trace ... hardly "wide Metal3".

1

@Tholin : Sorry, I was not following this conversation until Sylvain flagged me. I keep trying to remind people that the magic DRC deck for GF180MCU was designed in a hurry for what was a digital-only tapeout from Efabless. I made a "good first pass" at the analog rules and layers but there were no analog designs to validate it with. I have made some corrections since then, but it is more or less in the same state. I suppose the same goes for the klayout deck---No real validation in practice.

@Tholin : I found the GF handling of "5V" devices to be awkward and looked for some method to be consistent. It has never seemed reasonable to me that the same device can be either "5V" or "6V", and requires a marker layer to specify the intent of it. But mostly the issue of the way it is currently implemented in magic comes from early on struggling with what was meant by a 5V or 6V transistor, along with largely unreadable documentation trying (badly) to explain it. There were no 5V devices in the device model files originally. I added those to the model files recently. I could certainly redo the magic tech file to separate the 5V and 6V transistor types (now that there is a device model for each of them) and use the V5_XTOR ("FET5VDEF" in the magic techfile) to distinguish them (and apply the device length rules separately for each of them).

IMHO it's fine to only have mv to represent 5V/6V , but the V5_XTOR layer still need to be generated if length is too small to be 6V to comply with the DRC requirement ... I'm not sure if that's something doable in the magic tech file ?

Tholin

Oh no, the transistors are indeed too small for 6V devices - and magic doesn’t see a problem with that.

So it's not so much a bug as an implementation decision. Given that (at the time I implemented it) there was only one device model, I just had magic extract that one device model and discarded the information from the V5_XTOR mask. Either way, it's the same device, same model (my 5V model is just a copy of the 6V model, with a restriction on device length applied to the 6V model).

7:15 p.m.

@tnt : It can be done. I assume the purpose is to have magic-generated GDS pass DRC in klayout?

Yes. But also potentially any DRC GF themselves are running since this is in the design manual.

But I think that just implementing, say, "mvpfet" = 5V pfet and "hvpfet" = 6V pfet would be more consistent with the PDK overall.

Sure, I have no strong opinion on that.

7:17 p.m.

The 10V one are ld if I read the tech file correctly.

Are there any published rules for V5_XTOR? I can't find any in the open PDK documentation. In the vendor libraries, it appears to cover entire cells, although I would assume it is only meaningful over the gate of the device.

@Tholin : The magic tech file does implement rule V1.3d; where do you see it not flagging the rule? (Note that the DRC documentation has no rule"V1.3d", only "V1.3". The "d" seems to have been invented by Mabrains when they make the klayout DRC deck.)

https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_08.html

7:49 p.m.

AFAICT it's just the gate over comp that needs to be covered.

@tnt : Thanks, I missed PL.11. But PL.12 suggests that the diffusion as well as the gate must be covered.

7:53 p.m.

Rule PL.12 might be intended to prevent mixing 5V and 6V devices in the same circuit.

At least the klayout DRC only checks the gate.

But GF might flag PL.12.

Yes. Without exactly a drawing for what PL.12 means, I'm not sure tbh.

7:57 p.m.

I like also how there is a drawing for PL.19 but then no PL.19 rule

I'll start counting the issues in the rules and illustrations, and get back to you next week.

1

8:04 p.m.

It occurs to me that there must (?) also be "cap_nmos_05v0", "cap_pmos_05v0", "cap_nmos_05v0_b", and "cap_pmos_05v0_b" devices, but the devices themselves are just modeled as ideal capacitors (?!) and the models have no restriction on length and width. Also, moscap-connected transistors in the SRAM are just transistors in the netlist. Maybe the moscap device should just be quietly removed from the PDK. . .

@tnt : Okay, I have reworked the GF tech file for magic, and pushed the change. There is also a pending commit to add the 3.3V SRAM library to the open_pdks installation of GF180MCU, so it will all be mirrored to github by tomorrow.

3

Oh wow, that was fast

8:28 p.m.

Thanks !

Is anyone else using clock gates (ICGs) in their designs? I'm getting ~2ns SRAM address hold violations with CPU on a gated clock and SRAM on an ungated version of the same clock. I saw TritonCTS had a -balance_levels switch (off by default, enabled by CTS_BALANCE_LEVELS: True), but it didn't seem to help with overall clock skew:

-balance_levels Attempt to keep a similar number of levels in the clock tree across non-register cells (e.g., clock-gate or inverter). The default value is False, and the allowed values are bool.

(edited)

8:34 p.m.

Related note: based on a tip in the Caravel report I found I could reduce overall clock skew by about 40% (2.8 -> 1.7 ns in post-CTS STA) by forcing Triton to always use the largest available clock buffer. Is there any reason not to make this the default? If you're tight on timing then it may even save area overall as you should need fewer fixups and resizes

# Force use of chonky bois to reduce clock skew (default list is 2, 4, 8)
CTS_CLK_BUFFERS:
  - "gf180mcu_fd_sc_mcu7t5v0__clkbuf_16"

(edited)

LukeW

Is anyone else using clock gates (ICGs) in their designs? I'm getting ~2ns SRAM address hold violations with CPU on a gated clock and SRAM on an ungated version of the same clock. I saw TritonCTS had a -balance_levels switch (off by default, enabled by CTS_BALANCE_LEVELS: True), but it didn't seem to help with overall clock skew:

-balance_levels Attempt to keep a similar number of levels in the clock tree across non-register cells (e.g., clock-gate or inverter). The default value is False, and the allowed values are bool.

(edited)

Actually there is something suspicious in my CTS report: Total number of Clock Roots: 6. I have four defined clocks with two gates on one of those clocks. If I rebuild with the ICG cells removed, I get Total number of Clock Roots: 4. Is Triton treating each gate as a new root? Normally ICGs are just buffers for CTS purposes, and you'd explicitly define a root if you wanted a root

re: DRC, I assumed these were checks that GF provided, but I guess they are "implemented" based on written rules that GF publishes? What happens if we submit a design that validates fine but doesn't meet GF's internal checks?

9:13 p.m.

or do they just YOLO it and you get back a bad wafer?

GF definitely didn't provide the decks for KLayout and Magic

9:14 p.m.

If it's the same as for Sky130, the fab runs their own deck and comes backs with a list of violations that need fixing.

9:15 p.m.

They usually only bother reporting the MR ( Manufacturing Rule ), i.e. the rules that would actually prevent manufacturing the thing at all. There are also a bunch of rules that are not MR. i.e. they would affect the performance or function, but are not manufacturing risk, so they don't care so much, it's sort of your problem.

makes sense, thanks

Actually I don't think GF had any concept of "MR" rules (or rather, no documented "MR" rule set); we (Efabless) went through the usual iteration of them sending us a document highlighting all the errors, and coming to an agreement on which rules to waive and which rules to pass back to the user to fix. Because the two tapeouts were all-digital, we didn't have any user project errors that I recall. The errors were things in the GF IP (like the I/O cells) which were being flagged by GF's own DRC deck; none of which would meet the definition of an "MR" rule.

1

LukeW

Actually there is something suspicious in my CTS report: Total number of Clock Roots: 6. I have four defined clocks with two gates on one of those clocks. If I rebuild with the ICG cells removed, I get Total number of Clock Roots: 4. Is Triton treating each gate as a new root? Normally ICGs are just buffers for CTS purposes, and you'd explicitly define a root if you wanted a root

Yes, the default is to find roots automatically. In OpenLane 2 there didn’t seem to be a way to explicitly specify roots, I don’t know if things have improved since then. If the gated clock only feeds a small number of cells, I believe you can avoid getting a full clock tree built for it by explicitly instantiating a buffer after the gate, which should reduce the skew.

urish started a thread. 2025-11-23 12:33 p.m.

Tim Edwards

Actually I don't think GF had any concept of "MR" rules (or rather, no documented "MR" rule set); we (Efabless) went through the usual iteration of them sending us a document highlighting all the errors, and coming to an agreement on which rules to waive and which rules to pass back to the user to fix. Because the two tapeouts were all-digital, we didn't have any user project errors that I recall. The errors were things in the GF IP (like the I/O cells) which were being flagged by GF's own DRC deck; none of which would meet the definition of an "MR" rule.

That's right. From the first round of DRC with GF, it seems the whole rule deck is checked, including recommended rules.

Do they allow to waive the recommended ?

Yes. But it's going to be a back and forth.

1:19 p.m.

In other words, if we don't have any DRC violations, we don't need a waiver file, and submitting to the foundry would be faster and less complicated.

Does the klayout deck test for recommended rules ?

The ones that were violated weren't checked at least. I would need to go through the whole deck to see which are implemented and which are not. The other way is to go backwards: see which DRC rules are triggered and trying to fix them/add them to the deck. With actual designs in the reticle we should see a more complete list of DRC violations that are not yet caught by the open source rule decks.

Hi all, have people had success running LVS of their designs including the generated padframe? Would like some assurance it is possible before committing to running the long netgen LVS script.

I should do that sometime. I am super worried about VDD/VSS shorts and I believe LVS could detect them.

11:37 p.m.

Though I’m not sure.

First DRC, LVS, STA clean GDSII

6

What flow are you using for LVS? Did you create your own padframe schematic using the io spice files from GF or is there a way to get it from the project template?

The LVS that runs when you do make librelane

I see.

@Tholin Be aware that the librelane LVS abstracts any macros and standard cells. I can advise on a setup to run full device level LVS along with soft connection and ERC checks.

I’m mostly just interested in checking for VDD/VSS shorts

1

1:13 a.m.

I accidentally created such shorts before and the flow did not fail.

Is it possible to get librelane installed as an editable package (like a submodule of my repo) but still use the rest of the nix-shell setup? I wanted to look at adding a yosys extraction for mux + flop -> scan flop but librelane is quite hardcoded.

I have a similar complaint. nix-shell currently pulls binaries, but I’d actually like the option to have everything be built from source.

@Tholin you can just remove the cachex entry I think. Then it will be everything from source.

LukeW

Is it possible to get librelane installed as an editable package (like a submodule of my repo) but still use the rest of the nix-shell setup? I wanted to look at adding a yosys extraction for mux + flop -> scan flop but librelane is quite hardcoded.

You can clone the leo/gf180mcu branch (same one used for wafer.space). Next, you can make any changes inside the repo and then start LibreLane with nix-shell. That's basically the same step as in: https://librelane.readthedocs.io/en/latest/installation/nix_installation/installation_linux.html#cloning-librelane You can also apply patches in the in the Nix flake of the template, but it's a bit finicky.

Tholin

I have a similar complaint. nix-shell currently pulls binaries, but I’d actually like the option to have everything be built from source.

That's what Nix is for. It builds all the binaries for you. In the case of the wafer.space template we point to a specific branch of LibreLane and the binaries are already cached.

Leo Moser (mole99)

You can clone the leo/gf180mcu branch (same one used for wafer.space). Next, you can make any changes inside the repo and then start LibreLane with nix-shell. That's basically the same step as in: https://librelane.readthedocs.io/en/latest/installation/nix_installation/installation_linux.html#cloning-librelane You can also apply patches in the in the Nix flake of the template, but it's a bit finicky.

ah, so the shell I get from running nix-shell in that branch of the librelane repo is a suitable environment for running the makefile in the project template? If so then got it, thanks

12:57 p.m.

I probably would move to putting patches in the flake (should just be a few lines to add a flag to pass an extraction file) but I need to develop the patch

1

LukeW

ah, so the shell I get from running nix-shell in that branch of the librelane repo is a suitable environment for running the makefile in the project template? If so then got it, thanks

Yes. The project template uses that branch with an override to get a newer magic version. But it should also work with the magic version specified in LibreLane.

very silly newbie question: does part of the librelane build process spit out the max frequency the chip is expected to run at? or is there some other way to tell?

Yes, you can find the report in the console or inside 54-openroad-stapostpnr/summary.rpt. It contains a list of all corners and whether there are any setup violations for the target frequency. If there is a setup violation at a corner, it means that you will not be able to run the chip at the target frequency at that particular corner (PVT - Process, Voltage and Temperature). Using the setup worst slack, you can calculate the maximum frequency for each corner, which could even be above the target frequency.

There is also 54-openroad-stapostpnr\nom_tt_025C_3v30\clock.rpt (and actually for each corner) which tells you fmax for that corner. (edited)

thanks!

5:20 p.m.

aha, and found the target frequency in the yaml. cheers!

1

Anyone else getting occasional crashes in the detailed router? e.g.

 [INFO DRT-0076]   Complete 3000 pins.
Signal 6 received
Stack trace:
 0# handler(int) in /nix/store/g74fz644z0828i5dksxm95mzdb91aq2g-openroad-2025-10-28/bin/.openroad-wrapped
 1# _sigtramp in /usr/lib/system/libsystem_platform.dylib
 2# pthread_kill in /usr/lib/system/libsystem_pthread.dylib
 3# abort in /usr/lib/system/libsystem_c.dylib
 4# malloc_vreport in /usr/lib/system/libsystem_malloc.dylib
 5# malloc_report in /usr/lib/system/libsystem_malloc.dylib
 6# ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED in /usr/lib/system/libsystem_malloc.dylib

Probably won't have time to file reproducibles til after tapeout but I've made note of my git hashes. I'll just back out the RTL changes for now. Wondering if there is any way to work around it without undoing RTL commits

LukeW

Anyone else getting occasional crashes in the detailed router? e.g.

 [INFO DRT-0076]   Complete 3000 pins.
Signal 6 received
Stack trace:
 0# handler(int) in /nix/store/g74fz644z0828i5dksxm95mzdb91aq2g-openroad-2025-10-28/bin/.openroad-wrapped
 1# _sigtramp in /usr/lib/system/libsystem_platform.dylib
 2# pthread_kill in /usr/lib/system/libsystem_pthread.dylib
 3# abort in /usr/lib/system/libsystem_c.dylib
 4# malloc_vreport in /usr/lib/system/libsystem_malloc.dylib
 5# malloc_report in /usr/lib/system/libsystem_malloc.dylib
 6# ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED in /usr/lib/system/libsystem_malloc.dylib

Probably won't have time to file reproducibles til after tapeout but I've made note of my git hashes. I'll just back out the RTL changes for now. Wondering if there is any way to work around it without undoing RTL commits

Wie hast Du das geschafft?

Keine Ahnung

MacOSX? (edited)

Yeah it is on MacOS on an M4. The tools do just seem to behave slightly weirdly there, like I also get klayout/magic XORs and I'm not the only person to see that (but fine on Linux)

I don’t have these issues on my Debian or Ubuntu machines. Leo and I have generated over 60 chips in the last 3 weeks.

yep I'll go back to my Linux box when I need to close DRC. M4 is just faster

1

Leo Moser (mole99) started a thread. 2025-11-26 7:44 a.m.

Those CAP violations, I think I am getting them even with vanilla project template, how serious are they? (So far I couldn’t find a way to get rid of them)

11:28 a.m.

If they don't lead to slew rate violation, then, they really don't matter AFAIK.

1

I heard there is a way to use the 9-track cells now?

11:37 a.m.

I’d like to use them in the multiplexer of my die, since that thing is very performance critical.

You didn't use your cell library ? Or do you want 5V support ?

I need 5V support

1

You should be able to change it via: STD_CELL_LIBRARY: gf180mcu_fd_sc_mcu9t5v0. But there have been no changes to the 9t library.

Several people hardened TT projects with 9t without issues.

Leo Moser (mole99)

You should be able to change it via: STD_CELL_LIBRARY: gf180mcu_fd_sc_mcu9t5v0. But there have been no changes to the 9t library.

...so by omission you're saying there have been changes to the 7t library? I'm using 9t, do I need those changes?

12:33 p.m.

The thing I came here to post was: there are several bugs in the vendor RAM model that seem to be simulation related and not functional details of the RAM macro. What's our policy on patching the models? In particular:

It drops the first access because it fails to correctly initialise cen_dly and cen_flag_dly; can be fixed by just using always_comb to get a time=0 evaluation
It registers its inputs on a 100 ps delayed version of the clock, making it unsuitable for RTL simulations which just have an NBA delay on the input for the next cycle

LukeW

...so by omission you're saying there have been changes to the 7t library? I'm using 9t, do I need those changes?

No, there have been no changes to the 7t or 9t library :) I only mentioned this because Tholin wrote: "I heard there is a way to use the 9-track cells now?" It already worked before.

ah. phew, ok

12:44 p.m.

heart rate returning to normal

1

LukeW

The thing I came here to post was: there are several bugs in the vendor RAM model that seem to be simulation related and not functional details of the RAM macro. What's our policy on patching the models? In particular:

It drops the first access because it fails to correctly initialise cen_dly and cen_flag_dly; can be fixed by just using always_comb to get a time=0 evaluation
It registers its inputs on a 100 ps delayed version of the clock, making it unsuitable for RTL simulations which just have an NBA delay on the input for the next cycle

I think it would be great to fix those issues. Preferably in the FOSSi upstream repository.

12:46 p.m.

Let me just quickly check where open_pdks gets the SRAM sources from, I don't see a FOSSi fork for that.

Ok sure, added to my list of post-tapeout tasks

actually I'm curious, is anyone else using the vendor RAM models for RTL sims? I have a behavioural model in my RAM wrapper which I was using until now, but I wanted to run RTL sims with all my manually-instantiated cells enabled so that pulled in the vendor model.

1

Aha, it's still the original google repo: https://github.com/RTimothyEdwards/open_pdks/blob/486fb8633c3d95ae475a5ccd68d0066c25919bb5/gf180mcu/Makefile.in#L184

The analog IO pads are still broken and cannot be used with LibreLane, but the fix is easy. Should be possible to upstream.

LukeW

Ok sure, added to my list of post-tapeout tasks

actually I'm curious, is anyone else using the vendor RAM models for RTL sims? I have a behavioural model in my RAM wrapper which I was using until now, but I wanted to run RTL sims with all my manually-instantiated cells enabled so that pulled in the vendor model.

Yes, I did use it for some very simple tests.

Huh. And were you driving the inputs from posedge flops or did you have some behavioural delay and/or negedge stuff going on?

There are two things going on in my case: I was testing the FPGA fabric in my chip and to prevent logic loops during configuration I added delays to it. In the testbench I was waiting two clock cycles before I read the output. I don't remember if the two clock cycles were really necessary, but I was simply happy to get the correct data out again.

I didn't have time to take a closer look since then.

One of the issues I think I saw (not fully diagnosed) is a read where the address changes on the posedge can give you the data from the address after the posedge

12:55 p.m.

ah ok if the address is stable over the edge then you won't see issues

12:55 p.m.

I'm always nervous about patching vendor models but this one does seem quite broken

1

Leo Moser (mole99) started a thread. 2025-11-26 1:03 p.m.

Project Template Update! Version 1.1.2 has been tagged. Notable updates include:

Support for different slot sizes ◻️◽▫️

This will likely be an option for future shuttles. For the first shuttle, however, smaller slot sizes are still experimental.

You can try this out by setting the SLOT variable. See the README for more information.

The CI now also runs for all slot sizes in the upstream repo wafer-space/gf180mcu-project-template: https://github.com/wafer-space/gf180mcu-project-template/actions/runs/19697592187
Better SRAM power connections

pdn_cfg.tcl: better connectivity for the SRAM orientations. Please make sure to update your PDN config!
The PDK has been updated to 1.1.2

NP.12 and PP.12 reimplemented

Wide metal check fixed

Please update your projects and PDKs. The latest precheck tag is 1.0.1.

5

Leo Moser (mole99) pinned a message to this channel. 2025-11-26 1:49 p.m.

Will quarter slots be 1/4 of the price ?

I assume the cost of packaging will not go down by much. However, regarding the area, that's for @Tim 'mithro' Ansell to say.

▫️<-- that would be great for retro stuff (Z80)!

tnt

You didn't use your cell library ? Or do you want 5V support ?

@Tholin I am hardening with both mcu7t5v0 and mcu9t5v0 in parallel. I need (imho ridiculously high) 0.5 slack margins for HOLD violation in case of 7t, but otherwise both work and pass precheck. And with @htamas help, we tried both in TT. (edited)

LukeW

Ok sure, added to my list of post-tapeout tasks

actually I'm curious, is anyone else using the vendor RAM models for RTL sims? I have a behavioural model in my RAM wrapper which I was using until now, but I wanted to run RTL sims with all my manually-instantiated cells enabled so that pulled in the vendor model.

I've been using the vendor verilog as well. I assumed it was correct (looking to be a mistake?) and didn't trust myself to write a correct behavior stub.

I've been getting data in/out but if there was a timing discrepancy I probably chalked it up to my own timing issues and just worked around it in my code

BreakingTaps

I've been using the vendor verilog as well. I assumed it was correct (looking to be a mistake?) and didn't trust myself to write a correct behavior stub.

I've been getting data in/out but if there was a timing discrepancy I probably chalked it up to my own timing issues and just worked around it in my code

Oh interesting. Do you have the address changing every cycle, on a posedge?

LukeW

Oh interesting. Do you have the address changing every cycle, on a posedge?

yep. I'm using it for both instruction memory and generic SRAM. so most (all?) of the tests are probably incrementing the address each cycle to fetch a new instruction. the few tests that check branching also jump around but don't hold the same address over multiple clocks. and the general sram tests are just random accesses as well

Huhhhh

I do have a somewhat mystery clock delay at the beginning of the core bootup, which I attributed to my own jank code. will have to check when I get home but iirc it's two cycles before things start looking correct

and you're using the RAM model in both gate sim and behavioural RTL sim?

emmm, maybe? I'm using Spade HDL (transpiles to verilog), so copied/pasted the macro verilog into the spade setup so it can reference for tests. Not sure if that's gate sim or behavioural? probably behavioural (cocotb tests)

yeah, behavioural. Ok thanks, that's useful information, I need to look at my sims a bit more

definitely some weird stuff going on in that model

1

i'm praying it's not toooooo terribly off, otherwise my chip is totally not gonna work

gate sim would be a simulation of the synthesised (or post-place etc) netlist instead of your (transpiled) source code

aha

8:04 p.m.

i should probably figure out how to add some basic tests for that...

There is already some setup for it in the template's cocotb harness, if you look through where this variable is used in chip_top_tb.py: gl = os.getenv("GL", False)

8:06 p.m.

in theory just set that flag. in practice, dragons abound

1

ooh interesting. so theoretically the same cocotb tests would run and should match the behavioural testing pre-synth? will try it out when i get home

that is the theory. you can have new issues in gate sim like Xs propagating in places they didn't before, but the netlist should be equivalent to your RTL

rad! that would make me a lot more confident, especially if I can get it run before the payment deadline

8:09 p.m.

cheers for the info!

unrelated: i rented a beefy'ish droplet to run the process flow. turns out despite being memory-short on my laptop, fewer/faster cores still win over more slower cores and lots of memory

9:13 p.m.

looks like quite a few steps are single-core operations. alas

Yep, the fastest machine in my house for running this ASIC flow is my macbook air, annoyingly

9:36 p.m.

it's worse for some commercial ASIC tools because vendors will apply per-core licensing so the optimal play is to buy the fastest single-core machine you can find

1

Gaming machine trend to do well

1

Good way to justify a new machine

https://claude.ai/public/artifacts/77fed888-f1c3-431e-a4d1-7ec42a556241

Best Servers for EDA Performance Under $100/Month 2024

Compare dedicated servers vs cloud instances for single-threaded EDA workloads. Hetzner's i9-13900 delivers 40% better performance than AWS/GCP at $91/month.

"To be compatible with the default breakout PCB, do not change any of the power or ground pads." Just to make sure I understand correctly, I can do the wirebond option if I drop a few pwr/gnd pins, I just have to bring my own PCB?

2:20 a.m.

Also, it's been a minute since I used the template, I pulled it in October and have not been following updates. Whoever added the automatic pads is amazing. I remember seeing the pad instances individually laid out on the config.yaml. This is night and day, bravo!

Trevor Peyton

"To be compatible with the default breakout PCB, do not change any of the power or ground pads." Just to make sure I understand correctly, I can do the wirebond option if I drop a few pwr/gnd pins, I just have to bring my own PCB?

Hi Trevor, if you want to use the CoB bonding option: 1. Do not change the number of pads on any side. This ensures that the bondpad placement stays exactly the same. 2. The VSS pads are shorted on the default breakout PCB. This is why you should not change any of the ground pins. 3. As for whether you can provide your own PCB, @Andrew Wingate should be able to answer that.

Trevor Peyton

Also, it's been a minute since I used the template, I pulled it in October and have not been following updates. Whoever added the automatic pads is amazing. I remember seeing the pad instances individually laid out on the config.yaml. This is night and day, bravo!

I'm glad you appreciate the updated template. Having all pad instances individually was really too much

Our GDS had errors in the zero polygon and wide metal. (The new check item is functioning properly.) We fixed our GDS, and the new precheck was successful. https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/raw/main/images/precheck_5th_OK.png

precheck log

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/tree/main/precheck_log/RUN_2025-11-27_10-26-31

GDS

https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/blob/main/gds/ISHI-KAI_WS_RUN1.zip

2

I'm getting a couple of hundred klayout DRCs in the standard cell region. They're all CO.6a (i) Metal1 (< 0.34um) end-of-line overlap contact. Only other mention I found on this discord was https://discord.com/channels/1361349522684510449/1424739011846471740/1424745841952030860. Any ideas what could be causing that? I'm using 9-track cells if that helps

2:25 p.m.

I have to confess I've not merged the project template for about a week and a half, so I could be missing some updates

2:29 p.m.

here is one point it flagged between 33/0 and 34/0 (presumably m1 and contact). 1 box = 20 nm

https://gf180mcu-pdk.readthedocs.io/en/latest/physical_verification/design_manual/drm_07_13.html

2:31 p.m.

I'm trying to understand the rule but ... it's not super clear TBH

2:32 p.m.

Can you zoom out a bit ? Does the line "end" there ?

I know this rule!

2:32 p.m.

It needs some metal right here

2:33 p.m.

There is a separate contact overlap minimum for traces that are exactly the minimum-width and at the end of their line.

Well KLayout seems convinced it does, but I'm not sure it's not an error in the KLayout deck. For me I see that as falling in the CO.6b case.

When a trace terminates at a contact, then the edge opposite to where the trace extends is the "end of line"

2:36 p.m.

In these cases, additional overlap is needed

Tholin

It needs some metal right here

Which is only partially true for the example shown here, but it seems its still covered by the rule.

2:37 p.m.

For now, I suggest adding the affected standard cells to the exclude lists.

OTOH that cell library was made by GF so when there is doubt, I tend to suspect the KLayout deck more.

LukeW

here is one point it flagged between 33/0 and 34/0 (presumably m1 and contact). 1 box = 20 nm

Actually, the overlap shown here is tiny. I doubt this would pass even magic DRC.

CO.6b rule is specially for that case that says if the overlap is less than 40 nm you can "compensate" by having a bigger overlap on the adjacent sides.

2:39 p.m.

But I agree that excluding the affected cell is the easiest thing to do given the time constraints.

This is a zoom-out of the same region. It doesn't end, just necks down

2:53 p.m.

actually this looks like it is inside of one of the std cells

2:54 p.m.

yeah, it's an icgtp_1

2:56 p.m.

circled it here. from: https://gf180mcu-pdk.readthedocs.io/en/latest/digital/standard_cells/gf180mcu_fd_sc_mcu9t5v0/cells/icgtp/gf180mcu_fd_sc_mcu9t5v0__icgtp_1.html

Tholin

Actually, the overlap shown here is tiny. I doubt this would pass even magic DRC.

it's clean with magic DRC (apart from all the overlapping filler cells)

3:03 p.m.

Yeah I clicked through all 200 CO.6a warnings and they're all the same spot in the icgtp_1. I also have four PL.3a : Space on COMP/Field: 0.24µm which are just for the four orientations of the same cell. Inclined to waive given it's a foundry cell...

Yes, so for me that's valid and the KLayout DRC is an error.

1

The points flagged by PL.3a are across this neck on 30/0 in the icgtp_1 cell:

3:06 p.m.

My pattern recognition monkey brain is telling me this is just the two-gate poly on the left-hand side of the cell in my picture

3:08 p.m.

Oh that's definitely a bug right? It's treating it as multiple polygons and saying they violate spacing

Yeah, that seems weird to me too. How wide is the neck down ?

in x it's about 0.22 um

3:12 p.m.

I wonder if it's actually flagging the y distance between the two horizontals, since it's a spacing rule

3:12 p.m.

(the y distance is around 0.10 um)

I looked at the cell, it all seems good to me.

nice, thank you

3:16 p.m.

I think I'm DRC clean then (for now)

3:17 p.m.

is it possible to waive a specific cell for the klayout checks? (in librelane)

Thanks for the investigation, that makes things easy for me

The easiest path forward is to exclude this cell from synthesis and PnR. Does _icgtp_2 (if it exists) have the same issues?

1 and 2 both have the metal neck around the via. 4 does not

3:20 p.m.

they all seem to have the same kink in the poly

3:20 p.m.

I'd rather not remove clock gating as it would hurt QoR quite a bit given this cell library lacks DFFEs

3:21 p.m.

also I think the map file for lighter is buried deep inside librelane or openroad somewhere

Has anyone used Slang and gotten the power ports to work? It looks like yosys-slang doesn't support inout ports?

Trevor Peyton

Has anyone used Slang and gotten the power ports to work? It looks like yosys-slang doesn't support inout ports?

It does support them, but I think you need to keep the hierarchy, if I recall correctly. See here: https://github.com/mole99/greyhound-ihp/blob/2a2cf3e284a2f2486b71e48212d01458f55e8a0e/config.yaml#L103

1

Leo Moser (mole99)

It does support them, but I think you need to keep the hierarchy, if I recall correctly. See here: https://github.com/mole99/greyhound-ihp/blob/2a2cf3e284a2f2486b71e48212d01458f55e8a0e/config.yaml#L103

Looks like that worked, thanks!

1

LukeW

I'd rather not remove clock gating as it would hurt QoR quite a bit given this cell library lacks DFFEs

Alright, I absolutely get your point. The problem with waiving is, there is currently no way to ignore a cell in KLayout with the current setup afaik. In the worst case I can take a manual look at the submission and waive those errors. Ideally, I would find the time to fix them before the tapeout, unfortunately time is currently rare.

3:29 p.m.

Could you open an issue detailing both issues (collecting the info from above)?

Leo Moser (mole99)

Alright, I absolutely get your point. The problem with waiving is, there is currently no way to ignore a cell in KLayout with the current setup afaik. In the worst case I can take a manual look at the submission and waive those errors. Ideally, I would find the time to fix them before the tapeout, unfortunately time is currently rare.

ok, in that case is there a way to add a grep -v or so to the log lint in librelane?

3:40 p.m.

Separately I get magic DRC errors for overlapping identical filler cells (I think other people have seen this) and this is harmless afaict but prevents me from running make copy-final

What causes icgtp?

either clock gating inference or manual instantiation (I have both)

hmm

LukeW

ok, in that case is there a way to add a grep -v or so to the log lint in librelane?

LibreLane counts the DRC errors in the .lydrb that was produced by KLayout. So I don't think that would help. You would need a filter inside of that function.

how have people waived DRCs on past tapeouts?

3:44 p.m.

(I'm filing an issue with all of the pictures)

1

LukeW

Separately I get magic DRC errors for overlapping identical filler cells (I think other people have seen this) and this is harmless afaict but prevents me from running make copy-final

I don't think that's the issue. The default template should also have these overlap issues, but they should be ignored by LibreLane afaik. If you get any DRC violations, LibreLane won't create the final folder.

These are my primitives for GF180.

Leo Moser (mole99)

I don't think that's the issue. The default template should also have these overlap issues, but they should be ignored by LibreLane afaik. If you get any DRC violations, LibreLane won't create the final folder.

ohhh you're right, I actually have some new magic DRCs:

Poly overlap of contact < 0.065um (CO.3)
MV N-Diffusion overlap of contact < 0.065um (CO.4)

Here's one of the CO.3 violations: contact poly overlap here in dffrnq_4. For scale the thick part of that poly is 500 nm across.

1

asic destroyer

These are my primitives for GF180.

You won't have any clock gating cells if you don't explicitly enable it. Also you got lucky and your dffrnq (flop with async reset) are all drive=1. (edited)

1

LukeW

You won't have any clock gating cells if you don't explicitly enable it. Also you got lucky and your dffrnq (flop with async reset) are all drive=1. (edited)

Oh, I was using some negedge resetn signals. I’ve removed them now.

4:34 p.m.

stage 06 (edited)

I wrote up those DRC issues with some pictures: https://github.com/wafer-space/gf180mcu-project-template/issues/34

9-track foundry standard cells are not clean with KLayout or Magic ...

KLayout violations The clock gating cell icgtp_1 is flagged with the following by klayout: CO.6a : (i) Metal1 (< 0.34um) end-of-line overlap contact (Applies to all < 0.34µm wide metal lines,...

1

Last time, I brought you the neverending LVS run, today, I bring you the Synthesis run from hell:

1

asic destroyer

stage 06 (edited)

if you have no async reset in your design then how do you know that resetting your chip puts all the pads into tristate?

Tholin

Last time, I brought you the neverending LVS run, today, I bring you the Synthesis run from hell:

is this still a gate ROM? I found ABC was thinking incredibly hard about my 256-byte ROM and it helped to have a pipestage after it

No, this is something different.

4:40 p.m.

What does ABC even stand for?

https://people.eecs.berkeley.edu/~alanmi/abc/

4:42 p.m.

That's a logic mapper used by yosyis.

LukeW

if you have no async reset in your design then how do you know that resetting your chip puts all the pads into tristate?

https://gf180mcu-pdk.readthedocs.io/en/latest/IPs/IO/gf180mcu_fd_io/tri_state_2.html

yes that's a tristate buffer?

4:54 p.m.

is there an async path from your reset input to OE or do you have to clock the chip to stop it from driving its outputs in reset?

LukeW

is there an async path from your reset input to OE or do you have to clock the chip to stop it from driving its outputs in reset?

I wrote a DM

LukeW

is there an async path from your reset input to OE or do you have to clock the chip to stop it from driving its outputs in reset?

Do we need a power-on reset chip?

A PoR would be nice for future tapeouts. I'm just treating my reset input pad as a PoR.

LukeW

A PoR would be nice for future tapeouts. I'm just treating my reset input pad as a PoR.

sonst macht das alles kein Sinn im Chip

tristating all of your outputs when held in reset is pretty common and not just a PoR thing. For example it lets you drive other signals into those PCB traces on your board when you're debugging. If you have two chips on a bidirectional bus and they both enable their outputs at reset then that creates drive contention. Etc

5:39 p.m.

on a real board your chip may be held in reset for some time with its clock stopped while power rails are sequenced

Quick question: instead of a synchronizer, Hirosh could use an async apply and sync remove circuit for the reset. The ouput of this circuit gates the bidir OE and also goes into his circuit. So when you apply the reset, the bidir pads are immediately in a safe state. If you remove the reset, his circuit still works as before. Did I understand this correctly?

Yep that seems like it would work

1

5:58 p.m.

so you have an async reset, which is derived from the reset pad input with an async reset synchroniser

1

5:58 p.m.

that resets the pads and also goes into another synchroniser which generates the sync reset used for your digital logic

5:59 p.m.

something like that would work. I don't think he necessarily needs to make any changes but for a "production" chip it's certainly unusual to drive outputs at start of day

Why do you need another synchronizer afterwards? The reset signal is then already asynchronously removed.

depends how your resets are constrained but if you allow async transitions to propagate to a sync reset net then that usually needs a timing exception

6:01 p.m.

even if it is async apply, sync remove

I see, thanks!

6:01 p.m.

And another one: Without a PoR the outputs can still be in an unknown state during power up, right? Holding the reset low doesn't help in that case, as the input pads could be doing anything?

I don't have a simple answer to that and don't fully understand it myself. There's a question there about how the pads behave during ramp-up, and how the logic cells behave at much less than nominal voltage

6:03 p.m.

If you have an async path from the reset that disables the pads then any spurious enable during power supply ramp will at least be a short-lived transient

"It's complicated" is what I thought as well

my answer as a digital designer is values other than 1 and 0 don't exist and can't hurt me

2

1

Thanks for all the tips. It's great to have so many people with different experiences around. There's something for everyone to learn

yeah this project has been a huge learning curve for me. Thanks for all the help, hope I'm not too annoying with flagging issues

On the contrary, it is greatly appreciated!

@LukeW thank you

6:10 p.m.

6:11 p.m.

@Leo Moser (mole99) thank you

Now only the synchronizer to the core is missing

asic destroyer

Click to see attachment 🖼️

Functionally looks good, might look funny in STA though. I would add a false path between the synchroniser output and the pad OE signals

Leo Moser (mole99)

Now only the synchronizer to the core is missing

is inside the soc

1

LukeW

Functionally looks good, might look funny in STA though. I would add a false path between the synchroniser output and the pad OE signals

Could I use (* async_reg="true" *) reg [1:0] ff; (edited)

asic destroyer

Could I use (* async_reg="true" *) reg [1:0] ff; (edited)

Maybe @LukeW Do you have an example to set false path. I think I need it for 2 signals

6:24 p.m.

https://github.com/Wren6991/RISCBoy-180/blob/bb4540d8b1ee8493448395a5b010c80b37377010/librelane/chip_top.sdc

Most of them come from this wildcard:

# Apply RTL-inserted false path constraints (setup/hold only, still constrain slew)
set_false_path -setup -hold -through [get_pins *.magic_falsepath_anchor_u/Z]

And then there is an RTL module that inserts magic buffers for the constraints: https://github.com/Wren6991/RISCBoy-180/blob/bb4540d8b1ee8493448395a5b010c80b37377010/hdl/cells/falsepath_anchor.v

6:31 p.m.

You can also do it directly in the sdc, something like set_false_path -setup -hold -from sync_reg_name_here/Q -to *_PAD/OE but it's a bit cumbersome in this flow because flops don't have predictable names unless you instantiate them yourself

1

asic destroyer

Click to see attachment 🖼️

Hi-z

️ Update to the precheck, version 1.2.1.

Zero area polygons are checked.
The layout origin and size are checked depending on the selected slot size, the default is 1x1.
Ensure that PDK_ROOT and PDK are set.

2

Leo Moser (mole99) pinned a message to this channel. 2025-11-27 6:54 p.m.

will try in on ttgf0p2

7:01 p.m.

https://github.com/TinyTapeout/tinytapeout-gf-0p2/actions/runs/19745733739

LukeW

You can also do it directly in the sdc, something like set_false_path -setup -hold -from sync_reg_name_here/Q -to *_PAD/OE but it's a bit cumbersome in this flow because flops don't have predictable names unless you instantiate them yourself

Should I apply the same approach to the FPGA as well?

You can? FPGAs normally already handle this with their own PoR, before your bitstream ever loads

1

Yes, that's what I thought, which is why I wanted to ask you again.

LukeW

is there an async path from your reset input to OE or do you have to clock the chip to stop it from driving its outputs in reset?

Update to the precheck, version 1.2.1. All Green! https://github.com/ishi-kai/ISHI-KAI_Multiple_Projects_WaferSapce-GF180-1/raw/main/images/precheck_6th_OK.png

Is there a "routing keep-out" layer I can define in KLayout?

Tholin

Is there a "routing keep-out" layer I can define in KLayout?

You can add a macro with an empty .gds and a .lef file with an OBS block containing a rectangle on the right metal layer. I don't think klayout can write .lef files but they are easy to write by hand.

12:17 a.m.

VERSION 5.7 ;
  NOWIREEXTENSIONATPIN ON ;
  DIVIDERCHAR "/" ;
  BUSBITCHARS "[]" ;
MACRO whatever
  CLASS COVER ;
  FOREIGN whatever ;
  ORIGIN 0.000 0.000 ;
  SIZE 100.000 BY 100.000 ;
  OBS
    LAYER Metal2 ;
    RECT 25.000 25.000 75.000 75.000 ;
  END
END whatever
END LIBRARY

Tholin

Is there a "routing keep-out" layer I can define in KLayout?

@Tholin you may already be aware, but I believe you can also specify obstruction areas in the openlane config file.

1

Sorry, let me rephrase: how can I block just routing while leaving the PDN free to do what it wants?

1

is there somewhere in the flow that lists overall stats like total transistors, etc?

Every step in a run should have a state_out.json. Have a look at the metrics key in the JSON file, maybe that has what you're looking for?

1:09 a.m.

        "design__instance__count__stdcell": 116005,
        "design__instance__area__stdcell": 2878000,
        "design__instance__count__macros": 28,
        "design__instance__area__macros": 5360940,
        "design__instance__count__padcells": 1136,
        "design__instance__area__padcells": 5271000,
        "design__instance__count__cover": 0,
        "design__instance__area__cover": 0,
        "design__instance__utilization": 0.63858,
        "design__instance__utilization__stdcell": 0.381646,
        "design__rows": 3408,
        "design__rows:GF018hv5v_green_sc9": 3408,
        "design__sites": 2496942,
        "design__sites:GF018hv5v_green_sc9": 2496942,
        "design__instance__count__class:macro": 28,
        "design__instance__area__class:macro": 5360940,
        "design__instance__count__class:input_pad": 3,
        "design__instance__area__class:input_pad": 78750,
        "design__instance__count__class:input_output_pad": 53,
        "design__instance__area__class:input_output_pad": 1391250,
        "design__instance__count__class:power_pad": 18,
        "design__instance__area__class:power_pad": 472500,
        "design__instance__count__class:tie_cell": 383,
        "design__instance__area__class:tie_cell": 4323.92,
        "design__instance__count__class:buffer": 2135,
        "design__instance__area__class:buffer": 42671.9,
        "design__instance__count__class:inverter": 7722,
        "design__instance__area__class:inverter": 89255.6,
        "design__instance__count__class:clock_gate_cell": 613,
        "design__instance__area__class:clock_gate_cell": 50137.1,
        "design__instance__count__class:sequential_cell": 7291,
        "design__instance__area__class:sequential_cell": 568677,
        "design__instance__count__class:multi_input_combinational_cell": 48145,
        "design__instance__area__class:multi_input_combinational_cell": 912403,

Maybe more detail than you wanted

1:11 a.m.

Doesn't go down to transistor count unfortunately because the design flow is working with bigger units than transistors. If you wanted a transistor count you could write some script to scrape the transistors from the std cell spice netlist gf180mcu/gf180mcuD/libs.ref/gf180mcu_fd_sc_mcu7t5v0/spice/gf180mcu_fd_sc_mcu7t5v0.spice and then multiply by instance counts scraped from your netlist

1

When using the slang frontend, I'm seeing errors, this line in config.yaml suggested this was a tested option. Maybe I'm the first to try it

# Enable plugin for better SystemVerilog support
USE_SLANG: True

The error seems to be slang's handling of the VDD/VSS connecting in the netlist it passes through to yosys. Not liking the inout type.

use_slang
6. Executing SLANG frontend.
src/chip_core.sv:12:17: error: direction 'InOut' on inlined port connection unsupported
inout  wire VDD,
^
src/chip_core.sv:13:17: error: direction 'InOut' on inlined port connection unsupported
inout  wire VSS,
^
src/chip_core.sv:32:39: error: direction 'InOut' on inlined port connection unsupported
inout  wire [NUM_ANALOG_PADS-1:0] analog  // Analog
^
ERROR: Compilation failed

3:59 a.m.

I was seeing this with a custom design that's using some systemverilog feature to carry arrays of signals into a module. Which plain yosys does not understand. But I have confirmed the issue with the vanilla template.

Greg

When using the slang frontend, I'm seeing errors, this line in config.yaml suggested this was a tested option. Maybe I'm the first to try it

# Enable plugin for better SystemVerilog support
USE_SLANG: True

The error seems to be slang's handling of the VDD/VSS connecting in the netlist it passes through to yosys. Not liking the inout type.

use_slang
6. Executing SLANG frontend.
src/chip_core.sv:12:17: error: direction 'InOut' on inlined port connection unsupported
inout  wire VDD,
^
src/chip_core.sv:13:17: error: direction 'InOut' on inlined port connection unsupported
inout  wire VSS,
^
src/chip_core.sv:32:39: error: direction 'InOut' on inlined port connection unsupported
inout  wire [NUM_ANALOG_PADS-1:0] analog  // Analog
^
ERROR: Compilation failed

apparently there is a workaround: https://discord.com/channels/1361349522684510449/1423348662318272592/1443623510667821167

1

Ahh, I should have searched this channel before asking :doh:

New error, but this time I'm pretty sure it's related to my RTL

6. Executing SLANG frontend.
ERROR: Assert `count_id(cell->name) == 0' failed in kernel/rtlil.cc:2624.

Has anyone used Fault with this template? I've never used it before and hoping for an easy integration, any tips would be welcome!

Trevor Peyton

Has anyone used Fault with this template? I've never used it before and hoping for an easy integration, any tips would be welcome!

It is probably more advisable to create a macro with DFT support and integrate this macro into the chip. The successor to Fault is Difetto: https://github.com/donn/difetto/tree/main

Leo Moser (mole99)

It is probably more advisable to create a macro with DFT support and integrate this macro into the chip. The successor to Fault is Difetto: https://github.com/donn/difetto/tree/main

Thanks I'll look into that!

7:35 a.m.

Has anyone seen this? XOR: missing required input 'mag_gds' I get it at the end of a run during the KLayout vs. Magic XOR step. (edited)

Did you disable the magic streamout step by any chance ?

I pulled a fresh template earlier today and haven't changed the config except for macros and to use SLANG.

7:43 a.m.

meta:
  version: 3
  flow: Chip
  substituting_steps:
    # Disable KLayout DRC
    #KLayout.DRC: null
    #Checker.KLayoutDRC: null

    # Disable KLayout antenna check
    KLayout.Antenna: null
    Checker.KLayoutAntenna: null

    # Disable KLayout density check
    #KLayout.Density: null
    #Checker.KLayoutDensity: null

    # Save time during development
    # Enable for sign-off
    #OpenROAD.IRDropReport: null
    #Magic.DRC: null
    #Checker.MagicDRC: null
    #KLayout.XOR: null
    #Netgen.LVS: null
    #Checker.LVS: null

PRIMARY_GDSII_STREAMOUT_TOOL: klayout

This is some relevant lines from the config.yaml.

Trevor Peyton

Has anyone seen this? XOR: missing required input 'mag_gds' I get it at the end of a run during the KLayout vs. Magic XOR step. (edited)

Are you using macOS by any chance? @LukeW Didn't you encounter this error as well?

In the runs directory, do you see it running magic stream out ?

Leo Moser (mole99)

Are you using macOS by any chance? @LukeW Didn't you encounter this error as well?

Yes, I am on a mac.

tnt

In the runs directory, do you see it running magic stream out ?

Yes... Interestingly the log shows: Up at the top (not sure if this is important just caught my eye): Using NULL graphics device. Then at the bottom:

Cannot open .../librelane/runs/RUN_2025-11-28_00-08-28/73-magic-streamout/chip_top.magic.gds to write GDS-II stream output

I only have a chip_top.mag , no .magic.gds. (edited)

NULL is normal, just means it's running in console, no GUI output.

8:06 a.m.

The bottom one is not normal

Trevor Peyton

Yes... Interestingly the log shows: Up at the top (not sure if this is important just caught my eye): Using NULL graphics device. Then at the bottom:

Cannot open .../librelane/runs/RUN_2025-11-28_00-08-28/73-magic-streamout/chip_top.magic.gds to write GDS-II stream output

I only have a chip_top.mag , no .magic.gds. (edited)

Now I remember, you likely reached the limit of max open file handlers! You can try to increase it with ulimit. A proper fix would be for LibreLane to tell magic it doesn't have to lock the files. It's on my list...

1

urish

https://github.com/TinyTapeout/tinytapeout-gf-0p2/actions/runs/19745733739

Passed!

2

urish

Passed!

You could probably use the prebuilt docker containers @ https://github.com/wafer-space/gf180mcu-precheck/pkgs/container/gf180mcu-precheck

Build software better, together

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

Tim 'mithro' Ansell

You could probably use the prebuilt docker containers @ https://github.com/wafer-space/gf180mcu-precheck/pkgs/container/gf180mcu-precheck

Thanks, I'll check it out.

Leo Moser (mole99)

Now I remember, you likely reached the limit of max open file handlers! You can try to increase it with ulimit. A proper fix would be for LibreLane to tell magic it doesn't have to lock the files. It's on my list...

I maxed my limit, and unfortunately, the error still persists.

Trevor Peyton

I maxed my limit, and unfortunately, the error still persists.

For now, it might be the best path forward to use a Linux machine to build the complete ASIC. Unfortunately, there seem to be a number of differences between the Linux and macOS versions of the tools.

1

Leo Moser (mole99)

Are you using macOS by any chance? @LukeW Didn't you encounter this error as well?

The issue I had was on Ubuntu 24 LTS. I was getting a zero bytes magic GDS because magic failed to open some of the IP mag files. I found my soft open file limit was 1024 and increasing it with ulimit -Sn 4096 solved that particular issue. On MacOS I have a different issue which is that I get actual XORs between KLayout and Magic GDS. I didn't diagnose that, I just stopped using MacOS for now (it also tends to crash in the detailed router).

Possibly related is someone on sky130 had klayout on MacOS hallucinate DRC violations that weren't there ( and don't show up when running klayout on linux ). (edited)

Yes, he created an issue: https://github.com/KLayout/klayout/issues/2231

LukeW

Every step in a run should have a state_out.json. Have a look at the metrics key in the JSON file, maybe that has what you're looking for?

this'll do, thanks! I assume the cells used in a macro are counted in the instance stdcell count? was trying to get a sense for how many transistors/cells were in my logic but not the sram macros. Not really important, just curious

I think the SRAM macros are just counted as whole macros, so they don't appear in the cell instance counts there. They're usually custom layout, not standard cells

1

3:08 p.m.

for a rough transistor count estimate just multiply the number of SRAM bits by 6

oh awesome, that's perfect. cheers

I’d like to share how GF180mcu KianV ASIC SoC will behave. It currently runs on an FPGA at 30 MHz, using the same setup we have on wafer.space GF180mcu. We’ll show a short demo over the serial console; the rest will be over Telnet, we support spi/ethernet on the chip. The design will become a tiny Linux network SoC. It already runs XV6 (the MIT teaching Unix) , and μLinux. (edited)

4

1

Kernel 6.18.0-rc5 riscv32

2

1

Tim 'mithro' Ansell started a thread. 2025-11-28 11:15 p.m.

urish

Passed!

How are you running the precheck on GitHub Actions? Are you using custom runners? I thought that the precheck was too resource heavy for the actions?

asic destroyer

I’d like to share how GF180mcu KianV ASIC SoC will behave. It currently runs on an FPGA at 30 MHz, using the same setup we have on wafer.space GF180mcu. We’ll show a short demo over the serial console; the rest will be over Telnet, we support spi/ethernet on the chip. The design will become a tiny Linux network SoC. It already runs XV6 (the MIT teaching Unix) , and μLinux. (edited)

@carlfk / @asic destroyer - Do you think we could get this running on fpgas.online? I'm guessing the issue is SDRAM controller and https://fpgas.online only having Arty boards with DDR3? @carlfk - Did I ever end up giving you ulx3s boards or did they all end up in my shipping container? I think I had them as the 3rd priority FPGAs to get onto https://fpgas.online behind the NeTV2 boards?

Tim 'mithro' Ansell

@carlfk / @asic destroyer - Do you think we could get this running on fpgas.online? I'm guessing the issue is SDRAM controller and https://fpgas.online only having Arty boards with DDR3? @carlfk - Did I ever end up giving you ulx3s boards or did they all end up in my shipping container? I think I had them as the 3rd priority FPGAs to get onto https://fpgas.online behind the NeTV2 boards?

I don't think you gave me or I have any ulx3s

1

@asic destroyer - I assume you are using ulx3s boards?

Yes, best board on earth

11:25 p.m.

The FPGA design targets multiple boards. ASIC and ULX3s differs only in the top-level module. The underlying hierarchy remains identical in behavior.

11:26 p.m.

I need only 32MiB SDRAM, I could built top for ARTIX7, ecp5, cyclone, gatemate, ...

11:27 p.m.

@Tim 'mithro' Ansell @GoranMahovlic sells ulx3s on https://www.ebay.de/itm/385678851894?_skw=ulx3s&itmmeta=01KB6CNS3DATNKFMD1BADXY67H&hash=item59cc403f36:g:EbYAAOSwdBpjvJtw&itmprp=enc%3AAQAKAAAA4FkggFvd1GGDu0w3yXCmi1fwK1STpgN5pylpk0DDHI4qgOMwtWMnwHddsMaZ--aq3DW7e3EB8j26DYmkpKx441kiUMlJEmXbwEMNnBW7WPlmo61%2FPLyYGXGuiYPxwJymjdgnkgawKFn0aUZLj6ciIwu7V5bQdM2l3YaVkC3ZJ5Ai6WuIb0GcpLzbmOTZbEXIHHz3VEGlr8alajydtJqUfaQeXUS74VKBttzRMap%2FJEPuQYDY5W%2BG2KqT6kCAC5MM1Z9NmjHYoWPaGpRD9kQiXn3N3r%2B83W3rk92piNCIaEjn%7Ctkp%3ABk9SR-KS18zZZg

ULX3S with ECP5 12F Entwicklungsboard Open Source 32 MB RAM | eBay.de

ULX3S - A powerful, open hardware ECP5 FPGA dev board. Finally, if you are just starting out with FPGAs, you can use the Arduino IDE to program ULX3S in seconds. FPGA: Lattice ECP5. LFE5U-12F-6BG381I (12K LUT).

I had a video chat with @GoranMahovlic a while back and he offered to help with supplying the ulx3s for https://fpgas.online and wafer.space related stuff

1

The designs fits into 12f

11:34 p.m.

Do you want ASIC-like behavior, or can I optimize it further? I can add more cache (more ways), more TLBs, and still clock it at 70 MHz on the ECP5.

11:35 p.m.

I support these models

11:36 p.m.

But after the deadline, I’m going to heavily rework this repo so it’s based on the ASIC design. After that, I’ll probably only support ULX3S, iCEPi, and the QMTech Wukong.

some dumb pad questions

:

we can reconfigure input vs bidirectional pads to suit our design, right? should we leave VDD/VSS alone?
what's the actual difference between input and bidir? bidir just has extra stuff for sourcing output current or something? (i.e. why would you prefer input over bidir set to input)
what should I do with unused pins? Set to bidir and bidir_ie = 0 "ignore pad" ?

yes, all pads are the same size (the two bidi types, the input-only, and the power pads) so changing pad types does not change the pad coordinates
VDD/VSS need to be left alone to stay bond-compatible with the COBs; you can move them around if you don't rely on the default COB setup
One case you'd prefer input is for a global reset input, because you don't want that to spuriously enable its output driver during power-up. Pretty much everything else can be bidi
Tying off A = IE = OE = 0 is one option, you could also put a small hardcoded UART that prints a rude message

awesome, thanks! And lol at the rude message

Or any message. Spare chips could then be used to advertise "BreakingTaps!\r\n" at 9600bps.

1

urish started a thread. 2025-11-29 6:24 a.m.

Greg

Or any message. Spare chips could then be used to advertise "BreakingTaps!\r\n" at 9600bps.

We need more silicon artwork!

On my GFMPW-1 multi-project die, giving an invalid project selection code causes the chip pins to become all outputs and go "RTFM!" in binary ASCII

1

Hm, so I added a few 256x8 SRAM macros and it seems unhappy about that now. At step 57 (klayout xor magic) I'm getting a slew of errors which seems to stem from:

File /home/ubuntu/gf180mcu-project-template/gf180mcu/gf180mcuD/libs.ref/gf180mcu_fd_ip_sram/mag/M3_M24310590878114_256x8m81.mag couldn't be read
Failure to read entire subtree of the cell.

Failed on cell M3_M24310590878114_256x8m81.
I/O error in writing file /home/ubuntu/gf180mcu-project-template/librelane/runs/RUN_2025-11-29_06-44-00/56-magic-streamout/chip_top.magic.gds.
File may be incompletely written.

BreakingTaps

Hm, so I added a few 256x8 SRAM macros and it seems unhappy about that now. At step 57 (klayout xor magic) I'm getting a slew of errors which seems to stem from:

File /home/ubuntu/gf180mcu-project-template/gf180mcu/gf180mcuD/libs.ref/gf180mcu_fd_ip_sram/mag/M3_M24310590878114_256x8m81.mag couldn't be read
Failure to read entire subtree of the cell.

Failed on cell M3_M24310590878114_256x8m81.
I/O error in writing file /home/ubuntu/gf180mcu-project-template/librelane/runs/RUN_2025-11-29_06-44-00/56-magic-streamout/chip_top.magic.gds.
File may be incompletely written.

Not positive, but it could possibly be related to: https://discord.com/channels/1361349522684510449/1423348662318272592/1443879406962610287 (edited)

was just scrolling up to that. will give it a shot!

while that's chugging along, what's the general road to fixing PVT violations? I guess the easiest fix is just dropping the clock right? any other config changes/tweaks, or is it mostly down to clock speed + layout + what the code is doing? Edit: related, how much should I care about the non-nominal PVT corners? if nominal looks good are you generally good to go, or is it pretty important to make sure the other corners are passing too? (edited)

Another DRC clean build

6

3

BreakingTaps

while that's chugging along, what's the general road to fixing PVT violations? I guess the easiest fix is just dropping the clock right? any other config changes/tweaks, or is it mostly down to clock speed + layout + what the code is doing? Edit: related, how much should I care about the non-nominal PVT corners? if nominal looks good are you generally good to go, or is it pretty important to make sure the other corners are passing too? (edited)

My understanding is that a hold violation will make the chip non functional, setup timing means it just can't operate at the set clock speed at those corners. I'd say it depends on your chips use case. If you expect the chip to never deviate from normal operation (no power supply issues) or in hot/cold temps then yes you can ignore them if you choose. However those corners cover cases when you say get a power supply surge/drop or the chip get's really hot/cold so they are very important if you don't assume ideal. (edited)

1

makes sense! I'll focus on Holds. Probably easiest to just drop the clock rate, doesn't particularly matter anyway for a demo chip. i just found some docs on OpenLane which look helpful for improving my background knowledge too, and some config values to tweak: https://openlane2.readthedocs.io/en/latest/usage/timing_closure/index.html

Leo taught me that you should eliminate all hold violations in the different voltage domains, and that this is very important. Setup violations are a different matter — you can always deal with those later by adjusting the clock frequency.

noted! is there a shortlist of "ways to fix" that I should be aware of (other than what's at that openlane page)? I'm so new to this I don't really know what knobs are available

You won’t believe it, I’m a newbie too.

1

5:15 p.m.

but Leo has helped me a lot.

5:15 p.m.

And luke

It turns out the C64 SID has two built-in ADCs, which I am trying to replicate in my recreation of it as well. Interestingly, they are implemented using just digital logic cells because they’re not true ADCs and are more like....resistance to digital converters. Each ADC pin requires a capacitor and resistor (usually a potentiometer) connected to it. The chip runs a loop of pulling those pins low for a bit, before tri-state-inputing them and running a timer until they register a logic one.

1

6:00 p.m.

Obviously, this depends on the RC circuit’s time constant. (edited)

6:00 p.m.

Fixing the resistor to measure the capacitance also works.

6:01 p.m.

Maybe someone here will find this trick useful.

1

Tholin

It turns out the C64 SID has two built-in ADCs, which I am trying to replicate in my recreation of it as well. Interestingly, they are implemented using just digital logic cells because they’re not true ADCs and are more like....resistance to digital converters. Each ADC pin requires a capacitor and resistor (usually a potentiometer) connected to it. The chip runs a loop of pulling those pins low for a bit, before tri-state-inputing them and running a timer until they register a logic one.

That mechanism is also similar readout mechanism for potentiometers in paddle controllers - in Atari Pokey chip and Atari 2600 TIA chip! (edited)

BreakingTaps

makes sense! I'll focus on Holds. Probably easiest to just drop the clock rate, doesn't particularly matter anyway for a demo chip. i just found some docs on OpenLane which look helpful for improving my background knowledge too, and some config values to tweak: https://openlane2.readthedocs.io/en/latest/usage/timing_closure/index.html

Please check out the LibreLane docs: https://librelane.readthedocs.io/en/latest/ LibreLane is the successor to OpenLane 2, so the docs should be more up to date :)

1

BreakingTaps

noted! is there a shortlist of "ways to fix" that I should be aware of (other than what's at that openlane page)? I'm so new to this I don't really know what knobs are available

First thing would be to look at the clock tree in OpenROAD GUI to see if it's reasonably balanced. If that's the case, then increasing the hold slack margin should mostly resolve the hold violations. If there are still some remaining, taking a closer look at the timing paths can be helpful.

2

Leo Moser (mole99)

First thing would be to look at the clock tree in OpenROAD GUI to see if it's reasonably balanced. If that's the case, then increasing the hold slack margin should mostly resolve the hold violations. If there are still some remaining, taking a closer look at the timing paths can be helpful.

these docs are great, giving them a thorough read-through now. Project template request as complete newbie: I see the docs are linked for nix install, but I totally missed that it also included more general documentation about the build process.

maybe a subsection heading that's basically "If you have questions about build output read these docs" ? followup questions: how do i judge if the clock tree is balanced? Just visually, seeing if it branches somewhat-nicely? ditto to how should I check timing paths? (edited)

8:41 p.m.

here's where I'm at currently. Pretty substantially bad on the ss cases but I think trending towards ok everywhere else?

(hmm I do see that the clock line initially has to wind all the way from bottom left up through a bunch of sram blocks. Can probably re-configure everything so the logic is down in the clock corner) (edited)

2

I meant to ask this a while ago but forgot is anyone using cocotb tb with SRAM and passing? I'm using verilator and I get quite a few complaints.

gf180mcu_fd_ip_sram__sram512x8m8wm1.v:132:28: Unsupported: minimum/typical/maximum delay expressions. Using the typical delay
  132 |   specparam Tcyc = 55600 : 55600 : 55600;
      |

This is a typical error. I got this weeks ago and replaced the entire sram section with those with a:

`ifndef VERILATOR
  specparam Tcyc = 55600 : 55600 : 55600;
...
`endif

Then outside the specify block I did:

`ifdef VERILATOR
  parameter Tcyc = 8183;
  parameter Tckh = 4000;
  parameter Tckl = 4000;
...
`endif

Is there a better way? Since now it's failing all github deployments automatically since it's using the repo direct and not my local changes. (edited)

Is LVS of the foundry io pads able to pass using the netgen LVS script from the project template? The netgen script we have is causing issues with the pads (see questions channel "Running LVS for padframe")

I know you can pass parameters to verilog modules during instantiation, but is it possible to then use those parameters inside the module to do conditional compilation?

9:40 p.m.

I need to `ifdef exclude some stuff in a module, but only during one specific instantiation of it.

asc

Is LVS of the foundry io pads able to pass using the netgen LVS script from the project template? The netgen script we have is causing issues with the pads (see questions channel "Running LVS for padframe")

Try gds flatglobing these cells before reading the gds in magic

*Bondpad*
*CLAMP_COR*
*FILL*
*METAL_RAIL*
*NMOS_*
*POWER_RAIL_COR*
*_BASE*
*comp018green*  
*diode_nd2ps_06v0_*[A-Z]*
*diode_pd2nw_06v0_*[A-Z]*
*mim_*_*[A-Z]*  
*moscap_*
*nmos_*_*[A-Z]* 
*nmos_4T_metal_stack*
*nmos_clamp_*   
*pmos_6p0_esd_* 
*power_via*     
*ppolyf_u_*[A-Z]*
*top_route*

Tholin

I need to `ifdef exclude some stuff in a module, but only during one specific instantiation of it.

Do you mean like this? https://stackoverflow.com/questions/52061466/verilog-conditional-hardware-based-on-parameter-value

Verilog conditional hardware based on parameter value

Is it possible to create conditional hardware in Verilog depending on the value of a parameter? Something like this module test #( parameter param = 1 )( input wire clk ); reg[3:0] counter = 0;

asic destroyer

Click to see attachment 🖼️

Dear @LukeW , @Leo Moser (mole99) The previous code corrupted the entire netlist for the control signals. I checked your riscvboy-180 implementation and saw that your anchor tricky style approach works for synthesis. Can I simply declare rst_pad as a false path in sdc?

12:31 a.m.

message.txt

6.11 KB

Tholin

I know you can pass parameters to verilog modules during instantiation, but is it possible to then use those parameters inside the module to do conditional compilation?

Would an if inside a generate block do what you need?

Yes

During gate-level simulation I found that CEN has to remain high for one clock cycle. I had previously hardwired it to 0, but I’ve now combined it with reset_n, so the SRAM is operational.

1:50 a.m.

asic destroyer

During gate-level simulation I found that CEN has to remain high for one clock cycle. I had previously hardwired it to 0, but I’ve now combined it with reset_n, so the SRAM is operational.

I am fairly certain the cen_fell thing is a bug in the RAM model where they don't initialise all of their variables

asic destroyer

Click to see attachment 🖼️

ah maybe I had a separate issue which is the model doesn't accept the first access if you start up with CSn high

1:53 a.m.

I haven't looked at the schematic for the SRAM but that would be a super weird requirement

1

My caches are working!

2

asic destroyer

Dear @LukeW , @Leo Moser (mole99) The previous code corrupted the entire netlist for the control signals. I checked your riscvboy-180 implementation and saw that your anchor tricky style approach works for synthesis. Can I simply declare rst_pad as a false path in sdc?

yes IMO it's ok to falsepath the reset pad input since it's synchronised before use

1

I was able to boot from flash, copy the code into SDRAM, and execute it via micron sdram model.

nice

1

@Leo Moser (mole99) those 0.5 x 0.5 slots are so cute

think they would be a great gate-golf target

1

I got the model from you Luke 2022

1

how did we choose the number of VDD/VSS pins? seems to have like 75% the IOs of the 1x1 but < 50% the power and ground pins

1

asic destroyer

Click to see attachment 🖼️

FYI for my application, SRAM should remain on once started, I added a small prime latch where on reset, it toggles the CEN for a cycle to ensure it's always started.

Trevor Peyton

FYI for my application, SRAM should remain on once started, I added a small prime latch where on reset, it toggles the CEN for a cycle to ensure it's always started.

that was my fix!

1

Does anyone have a simple SD card Verilog model for iverilog? I only need SPI support, then I could try booting xv6 Unix. (edited)

Looks like it's coming together. This is an updated serv soc design. 28 cores, with each processor making use of the SRAM block for registerfile/program text and ram. A small FSM pre-loads each cores memory from SPI flash. (similar to an FPGAs bitstream) The cores are connected via a cross-bar to peripherals. One of which enables core to core communication, via queues or flags.

4

2

7:38 a.m.

Given the logic density, I think I could fit 32 cores in there... But didn't want to hit a wall with routing. (edited)

7:40 a.m.

A cross-bar between every core isn't a very scalable solution. But gives a lot of flexibility to the application

CoreScore style @Greg ?

8:45 a.m.

I did take a look at corescore. We can probably make this the highest ranking serv ASIC on that list

3

LukeW

how did we choose the number of VDD/VSS pins? seems to have like 75% the IOs of the 1x1 but < 50% the power and ground pins

@Leo Moser (mole99)

asic destroyer

@Leo Moser (mole99)

Thanks Hirosh, I did see the question, I just haven't had time to reply yet :)

1

LukeW

how did we choose the number of VDD/VSS pins? seems to have like 75% the IOs of the 1x1 but < 50% the power and ground pins

The default pinout of the 1x1 slot is based on the TT chip: https://docs.google.com/spreadsheets/d/1sZCpz6yy-bHGaV2BVG4IZOLBWn--WIddM9pkCQm_Vyc/edit?gid=0#gid=0 A number of the VDD/VSS pads will be used for the analog power domain in the future. In addition, the core are of the 0p5x0p5 chip is less than a quarter of that of the 1x1 chip. That's why I reduced the number of power/ground pads considerably. It may turn out that this is not enough to support the number of I/Os at high speeds, so we might change that again for run 2.

1

Z80 in a quarter slot. I think it is cute! (edited)

3

2

2

2

1

1:10 p.m.

@Leo Moser (mole99) quarter slot works!

I noticed the project template SDC file has set_input_delay -min 0 -clock $clocks $clk_core_input_ports which sets the hold time on the inputs to zero. I think that's may be why you've had to turn up the hold slack margin, because it means a bunch of buffering is required on the inputs which is a bit difficult for the flow to get right.

1

BreakingTaps

these docs are great, giving them a thorough read-through now. Project template request as complete newbie: I see the docs are linked for nix install, but I totally missed that it also included more general documentation about the build process.

maybe a subsection heading that's basically "If you have questions about build output read these docs" ? followup questions: how do i judge if the clock tree is balanced? Just visually, seeing if it branches somewhat-nicely? ditto to how should I check timing paths? (edited)

Make sure to also check that the actual timing of the clock tree in the "Clock Tree Viewer". This shows the example template where the design is quite sparse so there's a lot of routing between the clock buffers and after SPEF extraction the tree isn't as balanced as it should be (that's why I had to increase the hold margin).

1

2:07 p.m.

For a detailed report on the timing paths, take a look at librelane/runs/<timestamp>/54-openroad-stapostpnr/<corner>/ and open min.rpt/max.rpt for hold/setup checks.

ReJ aka Renaldas Zioma

Z80 in a quarter slot. I think it is cute! (edited)

Have you implemented PIO and SIO?

asic destroyer

Have you implemented PIO and SIO?

Well, I looked at a bunch of Z80 computers from back in the day… and I couldn’t find almost a single one that would use Zilog’s PIO/SIO. So I am actually thinking to focus on ZX Spectrum like machine repairs and put ULA (graphics) and AY (audio) instead.

1

2:18 p.m.

If I am missing some, let me know plz!

I have no idea

Plus 16KB of RAM if I go full slot.

1

Leo Moser (mole99)

Make sure to also check that the actual timing of the clock tree in the "Clock Tree Viewer". This shows the example template where the design is quite sparse so there's a lot of routing between the clock buffers and after SPEF extraction the tree isn't as balanced as it should be (that's why I had to increase the hold margin).

aha, didn't know that little widget existed in the gui, cheers! Didn't see the timing report tab either. looking through the violators now, looks like my ALU is popping up in the list which is interesting. didn't think I had anything particularly expensive in there but will give examine it closer. thanks for all th ehelp!

2

Just one more design. I can still fit more. I can do just one more design!

4

1

I think I’m a little behind. I still have not submitted any GDSIIs and let precheck run.

5:17 p.m.

How do I even do this?

Tholin

I think I’m a little behind. I still have not submitted any GDSIIs and let precheck run.

You can do it locally: https://github.com/wafer-space/gf180mcu-precheck But I believe the test project is where we will end up submitting which just runs that on a server: https://doc.test-platform.wafer.space I'd do it locally, mine timed out on the website.

GitHub - wafer-space/gf180mcu-precheck: Precheck for wafer.space MP...

Precheck for wafer.space MPW runs using the gf180mcu PDK - GitHub - wafer-space/gf180mcu-precheck: Precheck for wafer.space MPW runs using the gf180mcu PDK

Welcome to wafer.space …

Platform for wafer.space low cost silicon manufacturing.

It would be nice to run the SPICE model. I could run it on a remote server and check what it does after a year. How can I run something like that in SPICE?

I tried to use the online platform, but it just keeps cycling between "Queued" and "Starting"