I'm trying to run the static timing analysis on th...
# timing-closure
m
I'm trying to run the static timing analysis on the caravel design including our user project area. Right now I'm only focusing on the main clock (no other external IO or reset yet), and just using the modules:
caravel
,
mgmt_core
,
mgmt_protect
, and a "fake"
chip_io
that just forwards clock to clock_core My idea is first check if the wishbone bus and LA meet the timings Here is the WIP repository of the project: https://github.com/mbalestrini/caravel_timing_analysis On the first tests I'm getting HOLD violations between mgmt_core and our user_project_wrapper and it seems I'm also getting HOLD violations inside mgmt_core. If anyone with more experience wants to check the repository to see if the process is correct or if I'm missing something that would be great. (I'm using caravel's mpw-3a tag)
๐Ÿ‘ 1
d
@User Appreciate your effort in trying to bring-up the full-chip STA setup. ๐Ÿ™ Here is my quick observation based on file: results/zero_to_asic_mpw3/sta_zero_to_asic_mpw3_211206_204933.log 1. On HOLD Violation inside the mgmt_core, I see only one Hold Violation Startpoint: clock (clock source 'clock') Endpoint: soc/_46788_ (rising edge-triggered flip-flop clocked by clock) Path Group: clock Path Type: min -2.68 slack (VIOLATED) This path looks like somehow clock is feedback through mgmt_io_in[15] .. I feel this is not a valid path .. I don't see any other Hold Violation inside mgmt_core 2. I see HOLD violation in Most of the Wishbone User => mgmt_core signal. This is due to hugh difference in clock skew. In mgmt_core clock skew is 5.7ns and User project is 1.4ns .. All the path are violated in range of 3.5ns to 2.5ns - 5.7 ns clock skew inside mgmt_core clock skew is bit concerning one - If these number are true, then i feel most of the MPW-2/MPW-3 Digital project wishbone interface will be broken. 3. I see there are annotation issue at wishbone interface, this need to be clean-up for better understanding of wishbone timing violation. Warning: /project_files/spef/user_project_wrapper.spef line 83843, 728 not connected to net mprj/wbs_adr_i[]. Warning: /project_files/spef/user_project_wrapper.spef line 91522, 735 not connected to net mprj/wbs_dat_i[]. Warning: /project_files/spef/user_project_wrapper.spef line 98806, 728 not connected to net mprj/wbs_dat_o[] Warning: /caravel/spef/mgmt_core.spef line 269089, 53839 not connected to net soc/mgmt_addr[] As there is high number of annotation issue at interface .. For better timing violation clarity we need to all the block DEF + SPEF
๐Ÿ‘ 1
m
I'm going to check those warnings
Those reports were showing just the first 20 results I think, where the violations were mainly related to the user project area Here's the report for an empty caravel with no user project loaded
d
@User Yes, I see valid functional Hold violation in the range of 1ns within the management core (soc) itself. We need clarification from caravel team (#caravel) on this + also we need confirmation on caravel def available in https://github.com/efabless/caravel is tape-in version or not