open-source-silicon.dev

<@U0175T39732> Did we had any working Silicon data on SRAM working from MPW-3 or Chipignite ?  My ChipIgnite logic around SRAM is not working - Not Sure it's SRAM issue or My logic issue as there are limited debug hooks available.

I'm still working on testing MPW 2/3. Which macros did you use?

My one all are 2KB - sky130_sram_2kbyte_1rw1r_32x512_8

We've only tested the 1kb and it works in it's previous form. It was updated a bit but should still work.

Did we see any voltage sensitivity? OR working range ..

"any"? Yes, the performance depends on the voltage. The last 4 slides of:
<https://docs.google.com/presentation/d/1oqkwK-Bo6I21hFCy7MM0K_7mwA__p8LMpf3UgHEldeo/edit?usp=drivesdk|https://docs.google.com/presentation/d/1oqkwK-Bo6I21hFCy7MM0K_7mwA__p8LMpf3UgHEldeo/edit?usp=drivesdk>

<@U0175T39732> Is this statement means "Swept from 10Mhz to 44Mhz, 6.6ns to 11ns capture delay".
My understanding SRAM output are launched at negedge of the clock
i.e For 10 Mhz   = 5 ns  (Half cycle of 10mhz)  + 6ns output delay  = 11ns
i.e For 44 Mhz  = 1.1 ns (Half cycle of 44Mhz) + 5.5ns output delay  = 6.6ns

I'd have to check with the person that ran the tests but I think so.

The bigger issue is that this had very large wire delay between the SRAM and chip IO since the wiring wasn't buffered. The SRAM itself is probably much faster

tcm_log-Chip5-1.52v.txt

tcm_log-Chip5-1.44v.txt

tcm_log-Chip5-1.66v.txt

tcm_log-Chip5.1,62v.txt

<@U0175T39732> Out of 3 SRAM, I am able run a test on one memory with Pattern
0x55555555, 0x33333333, 0x0F0F0F0F,0x00FF00FF,0x0000FF,0xFFFFFFFF,0x00000000
Test Sequence:
      For Each Pattern Written into 16 Location Once
      Read Back Two time and validate against expected value.
      Same test is Run for 3 time to see the consistency of the failures.

Tested in 4 voltage point: 1.44v, 1.52v, 1.62v, 1.66v.   I have attached the test log your reference.
Look like as voltage increase, failure is reducing.  I am not expecting setup violation as system clock is just 10Mhz.  I feel like IR Drop issue around SRAM and Bit cell charging and de-charging issue or coupling issue?

The SRAMs aren't designed for less than 1.8V so it is likely noise margin in the bitcell itself

So you configure GPIO at all? If so, do you change the LDO after GPIO configuration?

My design wise, SRAM Power Rail is shared with Digital core rail. Look like there is hold violation inside the Digital core and core does not works above 1.66v. Are you recommending Separate power Rail for SRAM. Typically, all design should work in 1.8+/- 10% -&gt; 1.62v to 1.98v range.

We started to see errors at about 1.66 at all frequencies if you look at the data in my presentation

<@U0175T39732> Thanks, This information will be useful for my debug. :pray:

<@U0175T39732> In some chip, SRAM are working even at 1.6V which helps us work with internal cache mode. Which has given a good performance bump-off.  We are able demonstrate live demo with our chip. Appreciate you and OPENRAM team efforts :pray:
<https://www.youtube.com/watch?v=lH7PFgr5z0U>

That is good to know. Our errors could have been due to some external circuitry timing errors.

We had 3 SRAM of 2KB each and all of them are working.