FreePDK45 Control Logic Timing - Glitches or Expected Behavior?

[buchtawill]

EDIT
Reverse engineering control block, the following expressions can be made, which tells me the graph below is not expected behavior.

p_en_bar = ~((clk & ~csb) & DLY(rbl_bl))
w_en = (~clk & ~csb) & (~web) & (~rbl_bl) = ~(clk | csb | web | rbl_bl)

Describe the bug

• "example_config_freepdk45" macro control logic timing only activates p_en_bar and w_en for 200-300ps on a 5ns clock period. This contrasts the documentation, where the internal signals w_en and p_en_bar are active for what looks like half the clock period.
• Also, the write diagram in the docs is out of date because p_en_bar is active for reads and writes according to my simulations, whereas is it not active for writes in the docs.
• Is this behavior / timing expected? How is the timing of p_en_bar controlled internally?
• Is there a verilog model of the control logic?

Version
Most recent (ea15a81)

To Reproduce
clone the repo, install miniconda, activate miniconda, set OPENRAM_HOME and OPENRAM_TECH, remove rom generation for compilation, cd OpenRAM/macros, make example_config_freepdk45, ngspice example_config_freepdk45/functional_stim.sp

Expected behavior
Expected behavior (I think?) is for p_en_bar to be active for at least half the clock period, and same for w_en0

Logs
My sim is below. For example:
p_en_bar goes low/active at 15.1 ns, and inactive at 15.4ns - shouldn't it be active from 15.1 - 17.5ns?
w_en0 goes high/active at 17.7ns, low at 18ns - shouldn't it be high from 17.7 until the next rising edge of clk0?

Many thanks for looking into this

[buchtawill]

Following up, I believe I see the cause of the glitch. Documenting here, will follow up with solution. From the control logic spice:
p_en_bar = ~(clk & cs & rbl_bl_delay)
w_en = ~(clk | csb | web | rbl_bl_delay)
It looks like the signals rbl_bl_delay and rbl_bl_delay_bar are reversed, due to an improper instantiation of the delay chain. The first image shows how the signal rbl_bl_delay_bar actually follows rbl_bl0 instead of ~rbl_bl0.

Investigating further, the delay chain instantiation between rbl_bl0 and rbl_bl_delay has 9 inverters, which causes this issue. Does this ring any bells to anyone?