Closed rehayes closed 5 years ago
Sorry, my reply somehow got blocked. The assumption is that any clock supplied into the wrapper will be merged with the scan clock outside the block. So, I assume the CLK_SLOW clock will be managed/muxed by your integration. This is true of CLK, CLK_SLOW, CLK_SLOW_TC. I do the merge for clocks generated from within the IP. The reasoning is that your are sourcing the clocks and may well want to handle the scan model in your clock-generator-unit.
There are flops in the file i3c_auton_wrapper.v that don't receive the scan clock. This is in the "generate" block @ line#367. Part of the problem was fixed by adding a clock mux: CLOCK_SOURCE_MUX fix_slow_clk(.use_scan_clock(scan_single_clock, .scan_clock(scan_clk), .pin_clock(CLK_SLOW), .clock(CLOCK_SLOW_scan)); and then updating the "always" block connections. The other flops in error are the syncronizer flops and these were "fixed" with a quick kluge to connect the port"CLK" and "scan_clk" with the same net. This should be permentaly fixed by adding another mux.