Anton Blanchard

Here's an example when building a `512x64` DFFRAM. The clock makes it to the output buffering stage a long time before the memory elements. ``` ======================= Typical Corner =================================== Startpoint:...

Thank you @donn, the cache RAMs (32x64_1RW1R) have no hold violations. My main RAM (512x64) still have hold violations unfortunately: ``` ./dffram.py --size 512x64 --vertical-halo 100 --horizontal-halo 20 ```

``` Fanout Cap Slew Delay Time Description ----------------------------------------------------------------------------- 0.00 0.00 clock CLK (rise edge) 0.00 0.00 clock network delay (propagated) 3.75 3.75 v input external delay 0.14 0.10 3.85 v...

Running STA across the entire design (including the 512x64 DFFRAM): ``` Startpoint: _131570_ (rising edge-triggered flip-flop clocked by user_clock2) Endpoint: microwatt_0.soc0.bram.bram0.ram_0.memory_0/BANK128[1].RAM128.BLOCK[0].RAM32.SLICE[0].RAM8.WORD[7].W.BYTE[4].B.BIT[5].genblk1.STORAGE (positive level-sensitive latch clocked by user_clock2') Path Group: user_clock2...

@donn @shalan Thank you! FYI this is what I came up with many months ago, interested in your thoughts. In reality we only require 80 registers (32 GPR + 32...

@shalan any suggestions here? The Microwatt MPW5 tape out used this DFFRAM and I was wondering if the STA timing results are going to be suspect.

I think some of these problems were a result of the suspect RCX data. Things look better with the latest tools. Also, having worked through a number of issues while...

@d-m-bailey Great idea, having commit IDs for all repos used would help a lot.

@tspyrou I tried this out and noticed a few places where `check_setup` gives false positives: - input ports that are unused. There's no timing issue here, but perhaps the warning...

Why are we preventing the resizer from using delay cells? Sounds like an Openlane bug to me.