@User I have a timing issue with the new management core that I want to check. In the new core there seems to be a lot of hold delays cells to handle outputs from the user_project_wrapper (

la_data_out

,

wbs_dat_o

) into the mgmt_core, that help even out the difference in clocks to avoid hold violations. But it seems there are no delay cells on the

user_irq

paths, and that is causing delay violations because of difference in clocks. Taking a quick look at the

mgmt_core.sdc

I see that is setting an input_delay of 1.0 to all the inputs (

mprj_dat_i

,

la_input

) but not the for the user_irqs, maybe that is the problem? Or is there a reason behind that?

good spot Maximo!

Can you please share in2reg timing report? For in2reg, there should be only capture clock path delay and input delay should be modelled with respect to that clock. But a timing report snippet will help to analyse

@User I'm running the

make caravel_timing

from the efabless/caravel repo, but adding the user_project_wrapper verilogs and spefs files to try to run STA on the whole chip, and see the issues that might arise from the mgmt_core <> user_project_wrapper paths That `input_delay`I mentioned was used when they hardened the

mgmt_core

, but I'm just using the results from that process, so in my analysis I think is not an in2reg case but a reg2reg case. Here's the report for two inputs to the mgmt_core:

user_irq[1]

(where the data changes a lot earlier than the clock) and from `wbs_dat_o[1]`( where the delays added to the mgmt_core makes the data change after the clock) It seems they need to add the

set input_delay 1.0000

for the user_irqs to the base.sdc of the mgmt_core so the flow adds the delays to even out the clocks (like they did on the other inputs

mprj_dat_i

and

la_input

)

I think CPPR (common clock path pessimism removal) is not enabled. That would remove the common clock delay and hence the slack will be improved Something like this https://www.vlsisystemdesign.com/common-clock-path-pessimism-removal-cppr-part-1/

I think it is:

-0.69    7.60   clock reconvergence pessimism

Oh yes The difference is in delaycells in second report, which you suspect is due to difference in constraints

@User Good to see there is no timing issue in

wbs_dat_o[*]

Typically interrupts (

user_irq[*]

are consider as async, as there will be double sync logic inside the core before core consume it .. I see double sync inside File: mgmt_core.v Double Sync Logic: multiregimpl131_regs0 <= user_irq[0]; multiregimpl131_regs1 <= multiregimpl131_regs0; multiregimpl132_regs0 <= user_irq[1]; multiregimpl132_regs1 <= multiregimpl132_regs0; multiregimpl133_regs0 <= user_irq[2]; multiregimpl133_regs1 <= multiregimpl133_regs0; multiregimpl134_regs0 <= user_irq[3]; multiregimpl134_regs1 <= multiregimpl134_regs0; multiregimpl135_regs0 <= user_irq[4]; multiregimpl135_regs1 <= multiregimpl135_regs0; multiregimpl136_regs0 <= user_irq[5]; multiregimpl136_regs1 <= multiregimpl136_regs0; Double Sync Status consumed by the core: *assign gpioin0_in_status = multiregimpl131_regs1*; assign gpioin1_in_status = multiregimpl132_regs1; assign gpioin2_in_status = multiregimpl133_regs1; assign gpioin3_in_status = multiregimpl134_regs1; assign gpioin4_in_status = multiregimpl135_regs1; assign gpioin5_in_status = multiregimpl136_regs1; I see similar double sync for la_input[*] also .. multiregimpl3_regs0 <= la_input[0]; multiregimpl3_regs1 <= multiregimpl3_regs0; multiregimpl4_regs0 <= la_input[1]; multiregimpl4_regs1 <= multiregimpl4_regs0; multiregimpl5_regs0 <= la_input[2]; multiregimpl5_regs1 <= multiregimpl5_regs0; multiregimpl6_regs0 <= la_input[3]; multiregimpl6_regs1 <= multiregimpl6_regs0; multiregimpl7_regs0 <= la_input[4]; multiregimpl7_regs1 <= multiregimpl7_regs0; multiregimpl8_regs0 <= la_input[5]; multiregimpl8_regs1 <= multiregimpl8_regs0; multiregimpl9_regs0 <= la_input[6]; I feel, effectively Wishbone interface only need to met w.r.t user_project_wrapper interface ..

I didn't thought about the async nature of the irqs, as I was driving them in sync with the wb_clk. Nevertheless I still thinks it would be better to have the delays as in the other inputs, because without them (and assuming a user project where there's too little delay added inside it) the synched irqs generated on the user area would always generate hold violations, and if I understand correctly you would always have to set the irq value for two clocks to get a valid value on the core. The la_input[*] are double synched but they also have those delays added before the that.

yes, we can add false path constraint to them .. We need to make sure that these signal are more than 2 cycles valid value.