You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm running STA on the whole caravel+user_project_area to try to detect any issues we might get from the integreation of both.
I have a question about the mgmt_core.user_irq inputs:
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 some hold violations in our design.
Taking a quick look at the mgmt_core.sdc I see that it sets an input_delay of 1.0 to all the inputs (mprj_dat_i, la_input) but not for the user_irqs. Is there a reason behind that? I saw that the user_irq inputs use double flip-flop to sync the signal but when the signal comes from a synced cell in the projet area it might probably always caused a hold violation on the first ff
The text was updated successfully, but these errors were encountered:
I'm running STA on the whole caravel+user_project_area to try to detect any issues we might get from the integreation of both.
I have a question about the mgmt_core.user_irq inputs:
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 theuser_irq
paths, and that is causing some hold violations in our design.Taking a quick look at the
mgmt_core.sdc
I see that it sets aninput_delay
of 1.0 to all the inputs (mprj_dat_i
,la_input
) but not for theuser_irqs
. Is there a reason behind that? I saw that the user_irq inputs use double flip-flop to sync the signal but when the signal comes from a synced cell in the projet area it might probably always caused a hold violation on the first ffThe text was updated successfully, but these errors were encountered: