wafer.space Community - Standard Voltage & SRAM Macros

Hi, I am currently preparing a university lab course where we will hopefully target and tapeout on wafer.space. I noticed that the provided PDK seems to be both 5V or 3.3V. I do not have any real preference here, but if I download the project template and simply paste in my verilog will it generate a 5V or a 3.3V design? A bit unrelated to this: Are any of the SRAM macros silicon proven? Thanks

Florian S.

Hi, I am currently preparing a university lab course where we will hopefully target and tapeout on wafer.space. I noticed that the provided PDK seems to be both 5V or 3.3V. I do not have any real preference here, but if I download the project template and simply paste in my verilog will it generate a 5V or a 3.3V design? A bit unrelated to this: Are any of the SRAM macros silicon proven? Thanks

The gf180mcu_ocd_io SRAM macro targets 3.3V and the gf180mcu_fd_ip_sram 5V. You might be able to use them at different voltages but you will want to check that. By default template assumes you are working at 5V. As for if the SRAM has been silicon proven you will want to confirm with others but I think the answer is yes. @Tim Edwards would you be so kind as to confirm that the gf180mcu_ocd_io SRAMs you sent out as part of ws1 are working as intended ? (edited)

the foundry SCL works down to 1.8V nominal at a speed penalty, to be clear. AFAIK there's several of the actually-dense 3v3-transistor-based SRAM configurations on the currently-in-production chips, and the timeline plans are such that they'll be silicon-proven before the deadline for the next Run. It's therefore IMO reasonable to hedge your plans with a configuration that has less memory configured and have both layouts hardened to just submit the one that's confirmed-superior right before the deadline.

Essen

The gf180mcu_ocd_io SRAM macro targets 3.3V and the gf180mcu_fd_ip_sram 5V. You might be able to use them at different voltages but you will want to check that. By default template assumes you are working at 5V. As for if the SRAM has been silicon proven you will want to confirm with others but I think the answer is yes. @Tim Edwards would you be so kind as to confirm that the gf180mcu_ocd_io SRAMs you sent out as part of ws1 are working as intended ? (edited)

The SRAM he tested works as expected; harness limitations kept him from pushing the speed at the upper areas of the operating voltage range; tnt posted a matrix of speed vs. voltage but due to speed difficulty reasons that stops at something like 2.5V or maybe 2.8V or so, well shy of the 3.3V.

8:39 p.m.

IIRC retention is down to somewhere around 800~1000 mV.

namibj

The SRAM he tested works as expected; harness limitations kept him from pushing the speed at the upper areas of the operating voltage range; tnt posted a matrix of speed vs. voltage but due to speed difficulty reasons that stops at something like 2.5V or maybe 2.8V or so, well shy of the 3.3V.

Nice. How did I miss that, do you recall where did he post that ?

I think TT discord

1

As far as I know, the Tiny Tapeout GF180MCU version still uses the 5V padframe I/O and synthesizes to the original foundry 5V 7-track library. All of the 3.3V stuff has been done on custom chips.

1

Tim Edwards

As far as I know, the Tiny Tapeout GF180MCU version still uses the 5V padframe I/O and synthesizes to the original foundry 5V 7-track library. All of the 3.3V stuff has been done on custom chips.

Yes, but there was some trial entity of the fancy thin oxide sram, or at least one of those thin oxide sram's, which was tested.... IIRC. Could be confused, could have been something else he had measured there. There is no thin oxide SCL proven before Run2 dies undergo testing to that extend, and AFAIK there are no structures that had been designed to allow any sort of comprehensive test coverage of the SCL itself to "qualify" it for future production-targeted tapeouts. (Part of why I had hoped to get the e-test design working, but oh well, next tapeout: put an ability to e-test under DC conditions all necessary cells de-embedded to the LEF pins, so that RC extraction and modeling can take it from there to figure out the appropriate content for the liberty specs. AFAIK should work on at least most non-dynamic-logic gates; might have minor complications with flip-flops I guess, unless they work down to visible clock rise times.)

1

Tim Edwards

As far as I know, the Tiny Tapeout GF180MCU version still uses the 5V padframe I/O and synthesizes to the original foundry 5V 7-track library. All of the 3.3V stuff has been done on custom chips.

No we use your IOs.

9:20 p.m.

We run both core at 3v3 but separate domains and you can run IO at 5v if you want. Core is 3v3 only. We use the standard foundry 7T and run it at 3v3.

Thanks for the insights

For simplicity I will probably target 5V. However I am still in the design drafting phase so I don’t know yet if SRAM is required, but as it will probably be processor related having the option of something like a on die SRAM cache sounds interesting

I didn't do any tests on the SRAM ... the shmoo plots I posted are for my sky130 register file , nothing to do with gf180 sram.

1

tnt

I didn't do any tests on the SRAM ... the shmoo plots I posted are for my sky130 register file , nothing to do with gf180 sram.

ohhhh sorry for confusing the two.

I have the 3.3V SRAM on my desk but I have not done the full test over all bits at different frequencies yet. I did some spot tests and it was reading and writing up to 100MHz, which was the limit of my Analog Discovery 2's pattern generator.

1

@Florian S. You can configure the template to use all-3.3V IPs: https://github.com/wafer-space/gf180mcu-project-template#select-different-ip-libraries This will use Tim's 3.3V SRAMs. On ws-run2, we also had a few SRAMs generated using Staf's SRAM compiler (ID FS01-FS03): https://github.com/wafer-space/ws-run2 Of course, they still need to be verified once the chips come back :)

Maybe a bit of a table describing the capabilities and current state/risk of the different IP libraries would be useful to have somewhere. My understanding: SCLs:

gf180mcu_fd_sc_mcu7t5v0 - foundry provided, safe, works at 5V or 3V3. Slow.
gf180mcu_fd_sc_mcu9t5v0 - foundry provided, safe, works at 5V or 3V3. Faster than 7t but takes more area.
gf180mcu_as_sc_mcu7t3v3 - community provided, not tested, high risk, works at 3V3 only. Fast. PADs:
gf180mcu_fd_io - foundry provided, safe, works at 5V or 3V3 but connects core and IO power domains together.
gf180mcu_ocd_io - community provided, tested on run 1, low risk, works at 5V or 3V3 but keeps core and IO power domains separate, so you could e.g. run IO at 5V and core at 3V3. SRAMs:
gf180mcu_fd_ip_sram - foundry provided, safe, works at 5V or 3V3. 128, 256 and 512 bytes.
gf180mcu_ocd_ip_sram - community provided, initial testing from run 1 looks good, medium risk, works at 3V3 only. Smaller area. 64, 128, 256, 512 and 1024 bytes.

2

@RebelMike great post

AFAIK Staf's SRAM is far superior in density to the others; I'd like to see a comparison table though that at least covers the macro parametrizations supported by the others. And if there are any additional ones, those that are on Run2 masks without a verilog-level drop-in equivalent in the others. And then a highlight/marking of all hardened SRAM cells that are taped out in Run1 and those that are merely getting taped out on Run2.

@Tim Edwards if you are willing to send me over a board with your ws1 SRAM I can hook up an FPGA to test it over 100MHz. Alternatively, depending on what FPGA you have I can set you up with the bitstream.

I don't have a "proper" dev board with an FPGA. I used the simple breakout board and an Analog Discovery 2. That didn't have enough digital lines for the job, so I ordered an Analog Discovery 3. There was some snafu at Digilent so by the time I received it, I was busy with other things. Otherwise, it's sitting on my desk all wired up and just waiting to be tested. I would send you parts but right now I have just two working parts and two breakout boards. I think all of the other parts are missing at least one pin critical to getting full functionality.

Tim Edwards

I don't have a "proper" dev board with an FPGA. I used the simple breakout board and an Analog Discovery 2. That didn't have enough digital lines for the job, so I ordered an Analog Discovery 3. There was some snafu at Digilent so by the time I received it, I was busy with other things. Otherwise, it's sitting on my desk all wired up and just waiting to be tested. I would send you parts but right now I have just two working parts and two breakout boards. I think all of the other parts are missing at least one pin critical to getting full functionality.

Thanks for the update. The FPGA bitstream offer is on the table if you need it in the future.

Essen

Thanks for the update. The FPGA bitstream offer is on the table if you need it in the future.

Maybe he could give you remote access to the Analog Discovery 3, as I'm guessing it's just a list of pins and whatever information about the power configuration needs explaining?

1

Ahhh, just caught up in the other chat; there's good time until things need to happen anyways, so no need to rush Tim on this.