CODEWITHSUNDEEP
verilog
Ginu Jacob
Ginu Jacob

Reputation: 1798

In Verilog, whether always @(*) expects the actions to be completed in 1 clock period?

In Verilog, my peripherals are running at 100MHz = 10 nano seconds. In once always@(positive) block I was trying to do operations that exceeds 10 nano seconds. I rearranged the code so that the operations are performed now in an always@(*) block. Even now I have the same issue and my bitstream is not getting generated. So my question is why should always block should worry about the period ? as synchronization between clock and always@(*) block is not expected

Upvotes: 2

Views: 163

Answers (1)

Unn
Unn

Reputation: 5098

While I cannot be certain that this is your problem without knowing more about your code and the synthesis results; it is possible you are running into a timing problem where the logic in your design cannot complete in a single 100MHz cycle.

When creating a sequential designs, one must always be aware that real logic has propagation delay. This means that the more logic is in between to registers (ie, that needs to be completed in a single clock cycle), the longer that logic will take in real time. Thus, what it seems you might be facing is that the amount of calculations you are trying to do in a single step takes longer than the clock period (minus the setup time of the registers that store the result).

Its also important to note that while changing your design from using a single always @(posedge) to an always @(*) will not result in any major changes in the synthesized result as the design you are describing is effectively the same (ie, a bunch of logic doing some calculations, followed by a set of registers to store the result). While simulating the design might be different, the hardware synthesized from the code will be very similar, thus the problem will remain.

In order to fix such timing problems, you can either break the logic into smaller pieces and pipeline it or you can change the design to bew iterative (taking multiple clock cycles). It is possible you might be able to change the logic in the design to convert long chains into tree structures or other things to try and break up the longest paths through the logic (thus decreasing overall propagation delay), but depending on the design, that might not be possible.

Upvotes: 1

Related Questions