There are exceptions, but this should be the starting point.Ĥ. Doing this will give you predictable timing results and make it easier to write constraints. You would have to simulate your design or probe it on board to make sure that the function is equivalent in your particular case, but the basic philosophy in the FPGA should be that any assignment other than simple a <= b and c or some_vec <= smaller_vec & another_bit uses a clocked process. This will infer a flip-flop for offset_val. Use a clocked process that contains the assignment. If it not ok to have inferred clocks in the design, how can I fix this by coding the logic differently? In your case it looks like it should be quite easy to avoid a latch.ģ. One example where latches must be used would be if some external interface had to use a level sensitive input of some kind. Latches in general should be avoided unless there is a strong reason to have them, because they usually provide poor timing performance, and can more easily result in hazards and races in the design. Is it alright to have such statements in the design? Does the presence of inferred clocks indicate a bad design practice? Your gate signal at that point is using clock resource, but ultimately it is derived from another 'data' signal, as opposed to a 'real' clock.Ģ. In any FPGA I have used, this will be implemented by activating a 'latch' mode in a normal flip flop, using the 'clock' pin as the 'gate'. This line does not describe anything happening when pstate is not s2. Why is there an inferred clock on pstate in this design? If you are creating an ASIC or using some other flow, a different answer might apply.ġ. You have added an FPGA tag, so I will answer from an FPGA perspective.
I am looking for a few clarifications in this regard. However, my logic doesn’t work correctly. When I put the same statement inside a clocked process, the inferred clock warning disappears.
I realised that this assignment statement is causing the inferred clock in the design (but don’t know why). The state s2 is used for capturing the value of ctr1 before it resets to 0. This offset value is stored to a signal vector, as can be seen in the last line of the code. The value of ctr1 determines how much later is ctr2 started (in terms of 25MHz clock period), referred to as the offset. ctr1 stops counting when ctr2 is enabled. In the first phase ctr1 is run, which is then followed by ctr2. The counters are run when there are no system failures. The logic contains two counters – ctr1 and ctr2. P_ctr1 : process(reset_n_in, clk_25mhz_in) Save the counter1 value and start counter2 If (sys_fail = '0' and restart_ctr = '1') then p_fsm_clk : process(reset_n_in, clk_25mhz_in)
#Synplify pro reviews code
I traced back to the part of the code where the warning is being generated and the same is reproduced here for reference. | Found inferred clock counter_unit| pstate_inferred_clock with period 10.00ns. Please declare a user-defined clock on object "n:bcu_ins.ctr_ins.pstate" The synthesis report gives me the following warning on inferred clocks.
I am trying to synthesize a design in VHDL into a ProASIC3 FPGA using the Synplify Pro tool.
0 kommentar(er)
