wafer.space Community - 💻-digital

@BreakingTaps - Quick google search says - https://www.tinytapeout.com/chips/tt03/github_com_proppy_tt02_xls_counter and https://tinytapeout.com/chips/tt02/github_com_proppy_tt02_xls_popcount

141 XLS: 8-bit counter - Tiny Tapeout

Increment output bits

42 XLS: bit population count - Tiny Tapeout

Count bits set in the input.

10:46 p.m.

Randomly, it seems like the recent OpenAI accelerator that everyone is drooling over had some XLS used in development.

yeah the OpenAI thing is where I heard about XLS and it piqued my interest. Cheers for the links, will dig into those! contemplating trying it out for my next project

Hi, does anyone have experience here connecting their chip to external DRAM? I’ve been looking into hyperRAM since it looks easy to use but wanted to check if there are any alternatives

glaxus

Hi, does anyone have experience here connecting their chip to external DRAM? I’ve been looking into hyperRAM since it looks easy to use but wanted to check if there are any alternatives

I think @asic destroyer used DRAM on his Run #1 design?

BreakingTaps

I think @asic destroyer used DRAM on his Run #1 design?

Ah cool! Do you happen to have a link?

one s lemme go digging

5:01 p.m.

ah yeah, 32 MiB SDRAM: https://www.crowdsupply.com/wafer-space/gf180mcu-run-2/updates/taping-out-kianv-a-linux-xv6-capable-risc-v-soc https://github.com/splinedrive/gf180mcu-kianv-rv32ima-sv32 (edited)

Taping Out KianV - a Linux/XV6-capable RISC-V SoC

In this update we'll be exploring a homegrown SoC which is capable of booting Linux, µLinux and XV6. It implements the RISC-V RV32IMA ISA alongside additional extensions for more functionality.

GitHub - splinedrive/gf180mcu-kianv-rv32ima-sv32: KianV GF180 ASIC ...

KianV GF180 ASIC runs ulinux, linux and XV6. Contribute to splinedrive/gf180mcu-kianv-rv32ima-sv32 development by creating an account on GitHub.

2

Thanks!

1

BreakingTaps

I think @asic destroyer used DRAM on his Run #1 design?

SDRAM

3

I took a look, the memory controller was a lot simpler than I expected - I think the main blocker if anything is the number of pads required depending on how much other i/o you need

@glaxus - I think PSRAM and HyperRAM are potentially interesting due to the reduce number of pads/wires.

1

I’ve also taken a look at xls - it’s neat just to be able to generate some blocks using it. I think for our purposes, it seems like there’s 2 things we’d need to integrate end to end with our flow IIUC: having chip_core.sv available as a template usable when we write xls code to be able to wire to the pads, as well as setting up the XLS FDO path with the GF PDK so xls gets useful timing estimates. I wonder if there’s anyone with more experience that might be able to comment.

1

glaxus

Hi, does anyone have experience here connecting their chip to external DRAM? I’ve been looking into hyperRAM since it looks easy to use but wanted to check if there are any alternatives

Want to tell what you're aiming for/trying to accomplish?

namibj

Want to tell what you're aiming for/trying to accomplish?

Right now my idea is kind of a simple floating point capable SIMD core. Just need enough bandwidth from the memory to be able to feed the core

glaxus

Right now my idea is kind of a simple floating point capable SIMD core. Just need enough bandwidth from the memory to be able to feed the core

Uh huh, what kind of operations are you aiming at matching with memory bandwidth?

glaxus

I’ve also taken a look at xls - it’s neat just to be able to generate some blocks using it. I think for our purposes, it seems like there’s 2 things we’d need to integrate end to end with our flow IIUC: having chip_core.sv available as a template usable when we write xls code to be able to wire to the pads, as well as setting up the XLS FDO path with the GF PDK so xls gets useful timing estimates. I wonder if there’s anyone with more experience that might be able to comment.

Where in the world are you and what is your day job?

Tim 'mithro' Ansell

Where in the world are you and what is your day job?

I’m a software engineer in the SF Bay Area

@glaxus - FWIW - The Google XLS team is mostly in the SF bay area. @proppy, the related devrel however is in japan. If people showed interest there would be some support for improving GF180MCU in XLS or something?

1

5:30 a.m.

I was working on that a bit before I left Google

Tim 'mithro' Ansell

@glaxus - FWIW - The Google XLS team is mostly in the SF bay area. @proppy, the related devrel however is in japan. If people showed interest there would be some support for improving GF180MCU in XLS or something?

Ah I was under the impression it would just work out of the box, do you know what’s missing right now?

glaxus

Ah I was under the impression it would just work out of the box, do you know what’s missing right now?

I think it didn't have full characterization of standard cells -- but they might have fixed that since I left.

Tim 'mithro' Ansell

I think it didn't have full characterization of standard cells -- but they might have fixed that since I left.

Oh I see, is there a way to check which PDKs have full support? I noticed a few in the tutorials but didn’t see a list anywhere

@glaxus - Afraid I don't know, I've been out of the loop for too long there.

1

glaxus

Ah I was under the impression it would just work out of the box, do you know what’s missing right now?

It works but you don't get accurate schedule information, because we don't have a delay model for gf180

6:57 a.m.

There is a script to characterize one though

6:58 a.m.

https://github.com/google/xls/blob/main/xls/estimators/run_op_characterization.py

xls/xls/estimators/run_op_characterization.py at main · google/xls

XLS: Accelerated HW Synthesis. Contribute to google/xls development by creating an account on GitHub.

6:58 a.m.

It run a bunch of yosys/openroad jobs to measure the area and delay of each IR op

proppy

https://github.com/google/xls/blob/main/xls/estimators/run_op_characterization.py

How well does this work compared to the officially supported PDKs?

glaxus

How well does this work compared to the officially supported PDKs?

Not sure I don't think anybody tried to generate one for gf180

7:29 a.m.

but the designs I did with XLS, I did with the unit model, because timing wasn't critical for this design

7:30 a.m.

The delay model matters to improve how the scheduler balance the logic across the pipeline stages

quick question for the 0.5x0.5 die, how many transistors can i pack in? and is it die area or core area that we put the transistors in? and i cant see what "metal layers" are on the website

CrankHank

quick question for the 0.5x0.5 die, how many transistors can i pack in? and is it die area or core area that we put the transistors in? and i cant see what "metal layers" are on the website

The transistors you put in go into the core area. You can expect to squeeze up to 40~50k standard logic cells (7T type) into that area with the default pad frame; if you don't need as much IO and at the cost of less straight-firward/cheap bonding, you could give up 1-3 edges of the die to use the area normally occupied by the IO cells (incl. the power ring) for logic instead; giving up 3 edges I'd expect 100k SCL cells to be just about do-able, if the connectivity isn't too hard to route and you can relax speed targets a bit if timing doesn't close at normally planned clocks.