It looks like these antenna diodes didn't get properly aligned and we didn't end up with filler cells above

DIODE_INSERTION_STRATEGY=0

worked around it for now

@User @User I'm trying to get the last of my DRC issues sorted. I get a few of these at the edges near a macro (with a halo):

----------------------------------------
P-diff distance to N-tap must be < 15.0um (LU.3)
----------------------------------------
 5.655 1006.635 5.915 1007.505
 6.505 1006.635 6.765 1007.505
 7.035 1006.635 7.295 1007.505

Wondering if it's an issue, and if was because the macro chops the met1 rails on a power rail (vs gnd)

DRC violations are down to zero, and I've been trying to understand if this LVS issue is a problem or not:

LVS Summary:
Source: /project/openlane/user_project_wrapper/runs/user_project_wrapper/results/lvs/user_project_wrapper.lvs_parsed.lef.log
    net count difference = 0
    unmatched nets = 0
Total errors = 1

The only issue I can see is one pin appears twice:

io_oeb[27]                                 |io_oeb[27]
io_oeb[27]                                 |(no matching pin)
...
Cell pin lists for user_project_wrapper and user_project_wrapper altered to match.
The top level cell failed pin matching.

@User @User I'm doing gate level simulation and the build fails because we can't find an implementation of

sky130_ef_sc_hd__fakediode_2

. For now I'm just converting them to a

sky130_fd_sc_hd__diode_2

.

@User I made a start on a DFFRFile for Microwatt. Any recommendations on how I could modify it to forward writes to the readers? I was going to use a mux but I noticed a github comment from you saying the sky130 muxes are slow. Should I use a tristate buffer? https://github.com/antonblanchard/DFFRAM/blob/Microwatt-DFFRFile/Handcrafted/Models/Microwatt_DFFRFile.v

Hi @User. It depends on your target clock. From my experiments, every mux adds around 300ps. So, tri-state buffers are better as long as you don't have too many of them driving the same net.

@User Ahh thanks. Another thing, is the new latch based DFFRAM safe to try out?

@User Yes. It is verified; but not used in any design in the first MPW. So, it is safe to try and use as long as your verification tests pass. Btw, the new version has better timing (at the cost of extra added cells). So, if you wish, you may disable the latch usage and gain only the performance improvements over the previous version.

@User Great! I did notice the recent update with better buffering too. I'll run some experiments on Microwatt

I just noticed the first metal 4 vccd1 rail isn't connected to the metal 1 array. I saw it in microwatt but it appears in the example project too. Not a big deal, but possibly worth fixing in openlane/openroad?

@User any recommendations on a handcrafted DEC7x128?

@User Still looking for the DEC7x128? I have more resources now to work on RAM, RegFile and Cache generation. Will be happy to hear from you your RegFile requirements/configurations to consider them

@User Thanks! Let me upload a few things I've worked on. To save space I've implemented 80 registers since we don't actually need the full 128.

I also realise forwarding writes to reads in the register file is a pretty bad idea, and we should add that cycle of forwarding into the core (which already has forwarding for the functional units)

@User running DFFRAM through the OpenROAD flow shows up capacitance violations on the tristate buffer outputs. Experimentally, it seems we get into issues above 32 (it looks like DFFRAM is currently connecting 64). I looked in the liberty file and

max_capacitance/capacitance

for the Z pin is 33-39 depending on the gate size (wire capacitance would bring that down I presume). I'm not sure how much of an issue this is in practice. Would it just affect frequency, or are there other potential issues?

Hi @User, it will affect the frequency. I thought I corrected this earlier in one of my recent updates.

I think I had the latest, but will double check.

@User It does look like we are using 64 tri state buffers in upstream DFFRAM:

Yes. I don't see an issue with that other than timing. I did not notice anything weird in the timing reports. I will do some experiments and share the results w/ you.

I was using OpenROAD upstream which has improved the timing analysis quite a bit. I'm not sure if the version in openlane is using the liberty data to get max capacitance values, or if it is using the `CTS_MAX_CAP`global. @User might know for sure

@User OpenLane master is not using the latest OpenROAD App. It will soon.

@User Are you referring to opensta? or resizer? when you said "improved the timing analysis"

@User I was thinking of OpenSTA. Here is my current regfile: https://github.com/antonblanchard/DFFRAM/blob/Microwatt-DFFRFile/Handcrafted/Models/Microwatt_FP_DFFRFile.v

DEC4x10 came straight out of yosys synthesis.

@User has left the channel

@User has left the channel

@User has left the channel