Vivado bistreaming message: Rule violation (LUTLP-1) Combinatorial Loop - verilog

I got a problem when bistreaming. The project is to create a clock with a 1:2 duty cycle. There are no problems during Synthesis and Implementation. I tried a few ways to solve it. But they didn't work well.
module clock_div(clk, clk_out);
input clk;
output reg clk_out;
integer count1, count2;
reg clk_div;
always#(posedge clk)
begin
count1 <= count1 + 1;
if(count1 == 16666667)
begin
count1 <= 0;
clk_div <= ~clk_div;
end
end
always#(clk_div)
begin
count2 <= count2 + 1;
if(count2 == 1)
begin
clk_out <= ~clk_out;
end
else if(count2 == 3)
begin
count2 <= 0;
clk_out <= ~clk_out;
end
end
endmodule
The message that Vivado gave is as follows:
[DRC 23-20] Rule violation (LUTLP-1) Combinatorial Loop - 231 LUT
cells form a combinatorial loop.
This can create a race condition.
Timing analysis may not be accurate.
The preferred resolution is to modify the design to remove
combinatorial logic loops.
To allow bitstream creation for designs with combinatorial logic loops
(not recommended), use this command: set_property SEVERITY {Warning}
[get_drc_checks LUTLP-1].
NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl
command), add this command to a .tcl file and add that file as a pre-
hook for write_bitstream step for the implementation run.
clk_out_reg_i_3, clk_out_reg_i_4, clk_out_reg_i_5, clk_out_reg_i_7,
clk_out_reg_i_8, clk_out_reg_i_10, clk_out_reg_i_11, clk_out_reg_i_12,
clk_out_reg_i_13, clk_out_reg_i_14, clk_out_reg_i_15,
clk_out_reg_i_16, clk_out_reg_i_17, clk_out_reg_i_20, clk_out_reg_i_21
(the first 15 of 231 listed).
I would appreciate it if someone can help me.

This is wrong:
always#(clk_div) // <<== WRONG!!!!
begin
count2 <= count2 + 1;
if(count2 == 1)
begin
clk_out <= ~clk_out;
end
else if(count2 == 3)
begin
count2 <= 0;
clk_out <= ~clk_out;
end
end
You are using an incomplete sensitivity list. This gives a mismatch between simulation and synthesis. For all code that you want to synthesize use a complete sensitivity list or even easier use :always#( * )
If you use that in the section above you will find that your simulation no longer works. It will get in an infinite loop. Which is exactly the combinatorial loop the tool is complaining about.
To solve this you should put all code into the top section:
always#(posedge clk)
begin
count1 <= count1 + 1;
if(count1 == 16666667)
begin
count1 <= 0;
// Here you should make your 2:1 clock(s!)
// I leave that as an exercise to you
end
end
Problem:
As you divide by 16666667 you will not get a 2:1 clock but more a 33333334:1 clock.
Unless you wanted a 2:1 clock between clk_div and clk_out, but clk_div is not coming out. In that case make both clk_div and clk_out in the above marked section

Related

Find Maximum Number present in Verilog array

I have tried writing a small verilog module that will find the maximum of 10 numbers in an array. At the moment I am just trying to verify the correctness of the module without going into specific RTL methods that will to do such a task.
I am just seeing a a couple of registers when I am synthesizing this module. Nothing more that that. Ideally the output should be 7 which is at index 4 but I am seeing nothing neither on FPGA board or in the test bench. What I am doing wrong with this ?
module findmaximum(input clk,rst,output reg[3:0]max, output reg[3:0]index);
reg [3:0]corr_Output[0:9];
always#(posedge clk or posedge rst)
if(rst)
begin
corr_Output[0]=0;
corr_Output[1]=0;
corr_Output[2]=0;
corr_Output[3]=0;
corr_Output[4]=0;
corr_Output[5]=0;
corr_Output[6]=0;
corr_Output[7]=0;
corr_Output[8]=0;
corr_Output[9]=0;
end
else
begin
corr_Output[0]=0;
corr_Output[1]=0;
corr_Output[2]=0;
corr_Output[3]=0;
corr_Output[4]=7;
corr_Output[5]=0;
corr_Output[6]=0;
corr_Output[7]=0;
corr_Output[8]=0;
corr_Output[9]=0;
end
integer i;
always#(posedge clk or posedge rst)
if(rst)
begin
max=0;
index=0;
end
else
begin
max = corr_Output[0];
for (i = 0; i <= 9; i=i+1)
begin
if (corr_Output[i] > max)
begin
max = corr_Output[i];
index = i;
end
end
end
endmodule
Looking are your code, the only possible outputs are max=0,index=0 and a clock or two after reset max=7,index=4. Therefore, your synthesizer is likely optimizing the code with equivalent behavior with simpler logic.
For your find max logic to be meaningful, you need to change the values of corr_Output periodically. This can be done via input writes, LFSR (aka pseudo random number generator), and or other logic.
Other issues:
Synchronous logic (updated on a clock edge) should be assigned by with non-blocking (<=). Combinational logic should be assigned with blocking (=). When this guideline is not followed there is a risk of behavior differences between simulation and synthesis. In the event you need to compare with intermediate values (like your original max and index), then you need to separate the logic into two always blocks like bellow. See code bellow.
Also, FPGAs tend to have limited asynchronous reset support. Use synchronous reset instead by removing the reset from the sensitivity list.
always#(posedge clk) begin
if (rst) begin
max <= 4'h0;
index <= 4'h0;
end
else begin
max <= next_max;
index <= next_index;
end
always #* begin
next_max = corr_Output[0];
next_index = 4'h0;
for (i = 1; i <= 9; i=i+1) begin // <-- start at 1, not 0 (0 is same a default)
if (corr_Output[i] > next_max) begin
next_max = corr_Output[i];
next_index = i;
end
end
end

Verilog Design Problems

How to fix multiple driver , default value and combinational loop problems in the code below?
always #(posedge clk)
myregister <= #1 myregisterNxt;
always #* begin
if(reset)
myregisterNxt = myregisterNxt +1;
else if(flag == 1)
myregister = myregister +2;
end
right there are at least 3 issues in your code:
you are driving myregister within 2 different always blocks. Synthesis will find multiple drivers there. Simulation results will be unpredictable. The rule: you must drive a signal within a single always block.
you ave a zero-delay loop over myregisterNxt = myregisterNxt +1. Since you are using a no-flop there, it is a real loop in simulation and in hardware. You need to break such loops with flops
#1 delay is not synthesizable and it is not needed here at all.
You have not described what you were trying to build and it is difficult to figure it out from our code sample. In general, reset is used to set up initial values. So, something like the following could be a template for you.
always #(posedge clk) begin
if (reset)
myregister <= 0;
else
myregister <= myregister + increment;
end
always #* begin
if (flag == 1)
increment = 1;
else
increment = 2;
end
the flop with posedge clk and nonblocking assignments will not be in a loop.

Verilog Multiple Counters

I have a Verilog module with the fowling input and outputs
module Foo
#(
parameter DATA_BITS = 32,
parameter ENUM_BITS = 8,
parameter LED_BITS = 8
)
(
//Module IO declarations
input logic Clk_i,
input logic Reset_i,
input logic NoGoodError_i,
input logic EncoderSignal_i,
input logic [DATA_BITS-1:0]DistanceCount_i,
//Enable the gate
output logic GateEnable_o
)
The overall design idea is the following. When I receive the positive edge of the NoGoodError_i start a counter and count up to the DistanceCount_i count via the positive edges of the EncoderSignal_i signal. That seems pretty straight forward, however my design challenge becomes that I could get another NoGoodError_i before I am finished counting the previous count. So, I need a way to get up to 10 NoGoodError_i signal in row and start counters. Then reuse the counters once they expire (Rollover). Please any design tips would be greatly appreciated.
I would take an array of counters each with a 'busy' bit. If the bit is set the counter is running.
Next you use a modulo-10 index which busy bit to set.
I would raise a flag if the counter you want to start is still busy.
I just typed this in on the fly: not parsed for syntax and typos are possible (even likely):
reg [DATA_BITS-1:0] counter [0:9];
reg [9:0] busy;
reg [3:0] cntr_to_start;
always #(posedge Clk_i or posedge Reset_i)
begin
if (Reset_i)
begin
busy <= 10'b0;
for (i=0; i=<10; i=i+1)
counter[i] <= 'b0;
cntr_to_start <= 'b0;
end
begin
// Run a counter if it's busy flag is set
// At max (rollover) stop and clear the busy flag
for (i=0; i<10; i=i+1)
begin
if (busy[i])
begin
if (counter[i]==(33'b1<<DATA_BITS)-1)
begin
counter[i] <= 1'b0;
busy[i] <= 1'b0;
end
else
counter[i] <= counter[i] + 1;
end
end
// If no good start the next counter
// If we have no next counter: ????
if (NoGoodError_i)
begin
if (busy[cntr_to_start])
// Houston: we have a problem!
// More errors then we have counters
else
begin
busy[cntr_to_start] <= 1'b1;
if (cntr_to_start==9)
cntr_to_start <= 'b0;
else
cntr_to_start <= cntr_to_start + 1;
end
end
end

Mixing blocking and non-blocking assign in Verilog (or not!)

I'm implementing a simple serializer in Verilog, but I do not understand the nuances of when blocking assigns can cause problems. I'm specifically having trouble understanding part of this answer. "However, you should never use blocking assignments for synchronous communication, as this is nondeterministic."
I'm building a block that takes, as an input:
A bit clock
A 5-bit parallel data input (the value to be serialized)
A "Data valid" signal that indicates valid 5-bit data is present
As an output, I have:
Serial data out
A "Complete" signal that indicates it's time for a new 5-bit value
A "Transmitting" signal that's high whenever there's valid serial data going out on the bus
Whenever data valid goes high, the block starts outputting the 5-bit value, one bit a time, starting at the next rising edge of the bit clock. When the last bit is out on the wire, the block signals "complete" so a new 5-bit value can be made available.
Omitting some of the reset logic, the code to do this looks like this:
always # (posedge clk) begin
if(shiftIndex == 0) begin
if(dataValid == 1) transmitting = 1; //Blocking assign
else transmitting = 0; //Blocking assign
end
//Need the blocking assign up above to get this part to run
//for the 1st bit
if(transmitting == 1) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
Now, I can write the block with all non-blocking assigns, but I feel that it hurts readability. That would look something like this:
always # (posedge clk) begin
if(shiftIndex == 0) begin
if(dataValid == 1) begin
transmitting <= 1; //Non-blocking now
shiftIndex <= shiftIndex + 1; //Duplicated code
dataOut <= data5b[shiftIndex]; //Duplicated code
complete <= 0; //Duplicated code
end
else transmitting <= 0;
end
//Now, this only runs for the 2nd, 3rd, 4th, and 5th bit.
else if(transmitting == 1) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
Both appear to do what I want in simulation, and I favor the 1st one because it's easier for me to read but since I don't understand why using blocking assignments for synchronous communication is nondeterministic, I'm worried that I've coded up a ticking time bomb
The Question: Am I doing something wrong in the 1st code that's going to blow up when I try to synthesize this? Is the 2nd code preferable despite being a bit harder (for me anyway) to read? Is there some 3rd thing I should be doing?
When using the blocking (=) assignment the value is available to use in the next line of code. This implies it is combinatorial and not driven from a flip-flop.
In simulation it looks like it is driven from a flip-flop because the block is only evaluated on positive clock edge, in reality it is not which might break the interface.
I am of the faction which says never mix styles, as it can be a problem in code reviews and refactoring. The refactor, if a module needs to output a new signal and it is seen that it already exists they just change to be an output. At first glance looked like it was a flip-flop because it was in a always #(posedge clk block.
Therefore I would recommend to NOT mix styles, but pull out the section that is combinatorial and put it in its own block. Does this still meet your requirements? if not then you would have had problem.
I do not see how data valid is controlled but it can change the output transmitting, potentially transmitting could also glitch as it is from a combinatorial decode, not driven cleanly from a flip-flop. The receiving interface might be async, glitches could cause lock up etc.
always #* begin
if(shiftIndex == 0) begin
if(dataValid == 1) transmitting = 1; //Blocking assign
else transmitting = 0; //Blocking assign
end
end
always # (posedge clk) begin
if(transmitting == 1) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
As far as correctness is concerned, there is no problem with mixing blocking and non-blocking assignments, but you need to have a clear understanding of which signal is sequential and which signal is combinational block (note that the inputs of this combinational block come either from other sequential blocks or primary inputs). Also, you need to decide if you want any latches in your design or not.
If you use blocking assignments for a variable that you don't mean to be sequential, make sure to always assign to it, otherwise, it might be interpreted as a sequential element.
In your first code, you don't assign to transmitting when (shiftIndex != 0). This implies the previous value of transmitting should be used when (shiftIndex != 0), hence it would be a sequential element. But you need its value in the current clock, hence you used a blocking assignment.
Below is another version of your code, where firstBit_comb for the first bit is used and is always assigned to.
always # (posedge clk) begin
//Default value to avoid sequentials. Will be overwritten later if necessary
firstBit_comb = 0;
if(shiftIndex == 0) begin
if(dataValid == 1) begin
transmitting_seq <= 1;
firstBit_comb = 1;
end
else begin
transmitting_seq <= 0;
firstBit_comb = 1;
end
end
//Need the blocking assign up above to get this part to run
//for the 1st bit
if(firstBit_comb || transmitting_seq) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end
It is however more clear if you separate sequential and combinational blocks. Note that the next state of your sequential elements is often an output of a combinational block.
//combinational block
always_comb
begin
//The default value of next state is the previous state
transmitting_next = transmitting_seq;
//The default value of firstBit_comb=0. It would be overwritten if necessary
firstBit_comb = 0;
if(shiftIndex == 0 && dataValid == 1) begin
firstBit_comb = 1;
transmitting_next = 1;
end
else begin
firstBit_comb = 0;
transmitting_next = 0;
end
end
//Sequential block
always # (posedge clk) begin
//update transmitting_seq with its next state
transmitting_seq <= transmitting_next;
if(firstBit_comb || transmitting_seq) begin
shiftIndex <= shiftIndex + 1;
dataOut <= data5b[shiftIndex];
if(shiftIndex == 4) begin
complete <= 1;
shiftIndex <= 0;
end
else begin
complete <= 0;
end
end
end

Using a for loop inside a clocked process: "Cannot generate logic"

I would like to generate a number of statements inside a clocked process, seen below:
parameter C_INPUT_LENGTH = 32;
parameter C_OUTPUT_NUM_BITS = 5;
reg [C_OUTPUT_NUM_BITS-1:0] address;
reg [C_INPUT_LENGTH-1:0] vector_i;
always#(posedge clk) begin
if(rst) begin
address <= 0;
end
else begin
if (vector_i[0] == 1) begin
address <= 0;
end
if (vector_i[1] == 1) begin
address <= 1;
end
...
if (vector_i[C_INPUT_LENGTH-1] == 1) begin
address <= C_INPUT_LENGTH-1;
end
end
end // always# (posedge clk)
I did so like this:
integer forcount;
always#(posedge clk) begin
if(rst) begin
address <= 0;
end
else begin
for (forcount = 0;forcount <= C_INPUT_LENGTH-1 ;forcount = forcount + 1) begin
if (vector_i[forcount] == 1) begin <--
address <= forcount;
end
end
end
end // always# (posedge clk)
Xilinx vivado (2014.1) gives the following error, referring to the line indicated above:
[Synth 8-903] failed to generate logic
I've done this before using a similar method in the past and it has worked, what am I doing wrong? How do I generate these if statements?
According to Xilinx, this is a known bug documented under CR 801365. The use of an integer as a loop counter causes this issue in some cases. It's due to be fixed in vivado 2014.3.
The solution is to replace the integer with a signal type reg of appropriate size.
Is your input vector_i one-hot? The code you wrote doesn't guarantee that address will only be written to one value. Try this:
for (forcount = 0;forcount <= C_INPUT_LENGTH-1 ;forcount = forcount + 1) begin
if (vector_i[forcount] == 1) begin
address <= forcount;
break;
end
end
Adding the break statement will break out of the for loop the first time the condition is true. Note that this will generate some carry-chain logic and you might get better results with a case statement.
As a temporary work-around, you could consider using a generate statement.
For example:
genvar i;
always #(posedge clk) begin
if (rst) begin
address <= 0;
end else begin
generate
for (i = 0; i < C_INPUT_LENGTH; i = i + 1) begin: foreach_input
if (vector_i[i]) address <= i;
end
endgenerate
end // if (rst)
end // always #(posedge clk)
edit: oh, never mind -- I missed the bit above where Xilinx's recommended workaround is to simply use a dimensioned variable rather than "integer" for the iterator. That would be easier!

Resources