I'm trying to get a module to pass the syntax check in ISE 12.4, and it gives me an error I don't understand. First a code snippet:
parameter ROWBITS = 4;
reg [ROWBITS-1:0] temp;
genvar c;
generate
always #(posedge sysclk) begin
for (c = 0; c < ROWBITS; c = c + 1) begin: test
temp[c] <= 1'b0;
end
end
endgenerate
When I try a syntax check, I get the following error message:
ERROR:HDLCompiler:731 - "test.v" Line 46: Procedural assignment to a
non-register <c> is not permitted.
I really don't understand why it's complaining. "c" isn't a wire, it's a genvar. This should be the equivalent of the completely legal syntax:
reg [3:0] temp;
always #(posedge sysclk) begin
temp[0] <= 1'b0;
temp[1] <= 1'b0;
temp[2] <= 1'b0;
temp[3] <= 1'b0;
end
Please, no comments about how it'd be easier to write this without the generate. This is a reduced example of a much more complex piece of code involving multiple ifs and non-blocking assignments to "temp". Also, don't just tell me there are newer versions of ISE, I already know that. OTOH, if you know it's fixed in a later version of ISE, please let me know which version you know works.
You need to reverse the nesting inside the generate block:
genvar c;
generate
for (c = 0; c < ROWBITS; c = c + 1) begin: test
always #(posedge sysclk) begin
temp[c] <= 1'b0;
end
end
endgenerate
Technically, this generates four always blocks:
always #(posedge sysclk) temp[0] <= 1'b0;
always #(posedge sysclk) temp[1] <= 1'b0;
always #(posedge sysclk) temp[2] <= 1'b0;
always #(posedge sysclk) temp[3] <= 1'b0;
In this simple example, there's no difference in behavior between the four always blocks and a single always block containing four assignments, but in other cases there could be.
The genvar-dependent operation needs to be resolved when constructing the in-memory representation of the design (in the case of a simulator) or when mapping to logic gates (in the case of a synthesis tool). The always #posedge doesn't have meaning until the design is operating.
Subject to certain restrictions, you can put a for loop inside the always block, even for synthesizable code. For synthesis, the loop will be unrolled. However, in that case, the for loop needs to work with a reg, integer, or similar. It can't use a genvar, because having the for loop inside the always block describes an operation that occurs at each edge of the clock, not an operation that can be expanded statically during elaboration of the design.
You don't need a generate bock if you want all the bits of temp assigned in the same always block.
parameter ROWBITS = 4;
reg [ROWBITS-1:0] temp;
always #(posedge sysclk) begin
for (integer c=0; c<ROWBITS; c=c+1) begin: test
temp[c] <= 1'b0;
end
end
Alternatively, if your simulator supports IEEE 1800 (SytemVerilog), then
parameter ROWBITS = 4;
reg [ROWBITS-1:0] temp;
always #(posedge sysclk) begin
temp <= '0; // fill with 0
end
end
If you do not mind having to compile/generate the file then you could use a pre processing technique. This gives you the power of the generate but results in a clean Verilog file which is often easier to debug and leads to less simulator issues.
I use RubyIt to generate verilog files from templates using ERB (Embedded Ruby).
parameter ROWBITS = <%= ROWBITS %> ;
always #(posedge sysclk) begin
<% (0...ROWBITS).each do |addr| -%>
temp[<%= addr %>] <= 1'b0;
<% end -%>
end
Generating the module_name.v file with :
$ ruby_it --parameter ROWBITS=4 --outpath ./ --file ./module_name.rv
The generated module_name.v
parameter ROWBITS = 4 ;
always #(posedge sysclk) begin
temp[0] <= 1'b0;
temp[1] <= 1'b0;
temp[2] <= 1'b0;
temp[3] <= 1'b0;
end
Within a module, Verilog contains essentially two constructs: items and statements. Statements are always found in procedural contexts, which include anything in between begin..end, functions, tasks, always blocks and initial blocks. Items, such as generate constructs, are listed directly in the module. For loops and most variable/constant declarations can exist in both contexts.
In your code, it appears that you want the for loop to be evaluated as a generate item but the loop is actually part of the procedural context of the always block. For a for loop to be treated as a generate loop it must be in the module context. The generate..endgenerate keywords are entirely optional(some tools require them) and have no effect. See this answer for an example of how generate loops are evaluated.
//Compiler sees this
parameter ROWBITS = 4;
reg [ROWBITS-1:0] temp;
genvar c;
always #(posedge sysclk) //Procedural context starts here
begin
for (c = 0; c < ROWBITS; c = c + 1) begin: test
temp[c] <= 1'b0; //Still a genvar
end
end
for verilog just do
parameter ROWBITS = 4;
reg [ROWBITS-1:0] temp;
always #(posedge sysclk) begin
temp <= {ROWBITS{1'b0}}; // fill with 0
end
To put it simply, you don't use generate inside an always process, you use generate to create a parametrized process or instantiate particular modules, where you can combine if-else or case. So you can move this generate and crea a particular process or an instantiation e.g.,
module #(
parameter XLEN = 64,
parameter USEIP = 0
)
(
input clk,
input rstn,
input [XLEN-1:0] opA,
input [XLEN-1:0] opB,
input [XLEN-1:0] opR,
input en
);
generate
case(USEIP)
0:begin
always #(posedge clk or negedge rstn)
begin
if(!rstn)
begin
opR <= '{default:0};
end
else
begin
if(en)
opR <= opA+opB;
else
opR <= '{default:0};
end
end
end
1:begin
superAdder #(.XLEN(XLEN)) _adder(.clk(clk),.rstm(rstn), .opA(opA), .opB(opB), .opR(opR), .en(en));
end
endcase
endmodule
Related
always # (posedge clk) begin
if (x) begin
count <= count + 1'b1;
end
end
always # (posedge clk) begin
if (y) begin
count <= count - 2'b10;
end
end
always # (negedge clk) begin
if (x) begin
count <= count - 1'b1;
end
end
always # ( count ) begin
...do something... ;
end
Can I us the variable count inside multiple always block?
Is this a good design practice?
Why/Where should/should not use this method?
How does the simulator/synthesizer do the calculations for that variable 'count'?
Does the compiler throw error if I do this?
Can I us the variable count inside multiple always block?
Not in RTL code NO.
Is this a good design practice?
"good design practice" is not a well defined term. You might use it in a test-bench but not in the format you use. In that case you must make sure that all always conditions are mutual exclusive.
Why/Where should/should not use this method?
You could use it if you have about 10 years experience in writing code. Otherwise don't. As to "should" never!
How does the simulator/synthesizer do the calculations for that variable 'count'?
The synthesizer will refuse your code. The simulator will assign a value just as you described. Which in your code means: you have no idea which assignment is executed last so the result is unpredictable.
Does the compiler throw error if I do this?
Why ask if you can try?
I'm not a hardware designer, but this is not good. Your 3 always blocks will all infer a register and they will all drive the count signals.
You can read signals in multiple blocks, but you should only write to them in a single block.
In most cases you don't want to have multi-drivers. If you have something like a bus with multiple possible masters then you will want multi-drivers, but they need to drive the bus through tri-states and you need to ensure that the master has exclusive access.
Mixing posedge and negedge is not a good idea.
With a single block you might write something like this (which appropriate macros or parameter for UP1, DOWN1 and DOWN2).
always #(posedge clk or negedge reset_n)
begin
if (reset_n == 1'b0)
begin
count <= 32'b0;
end
else
begin
case (count_control)
UP1: count <= count + 1'b1;
DOWN2: count <= count - 2'b10;
DOWN1: count <= count - 1'b1;
endcase
end
end
No. You can't have assignments to a net from multiple always block.
Here is the synthesis result of 2 implementation in Synopsys Design Compiler
ASSIGNMENTS FROM MULTIPLE ALWAYS BLOCK.
module temp(clk, rst, x, y, op);
input logic clk, rst;
logic [1:0] count;
input logic x, y;
output logic [1:0] op;
assign op = count;
always # (posedge clk) begin
if (x) begin
count <= count + 2'd1;
end
end
always # (posedge clk) begin
if (y) begin
count <= count - 2'd2;
end
end
always # (negedge clk) begin
if (x) begin
count <= count - 2'd1;
end
end
endmodule
// Synthesis Result of elaborate command -
Error: /afs/asu.edu/users/k/m/s/kmshah4/temp/a.sv:16: Net 'count[1]' or a directly connected net is driven by more than one source, and not all drivers are three-state. (ELAB-366)
Error: /afs/asu.edu/users/k/m/s/kmshah4/temp/a.sv:16: Net 'count[0]' or a directly connected net is driven by more than one source, and not all drivers are three-state. (ELAB-366)
ASSIGNMENTS WITH SINGLE ALWAYS BLOCK.
module temp(clk, rst, x, y, op);
input logic clk, rst;
logic [1:0] count;
input logic x, y;
output logic [1:0] op;
assign op = count;
always # (clk)
begin
if (clk)
begin
case ({x, y})
2'b01 : count <= count - 2'd2;
2'b10 : count <= count + 2'd1;
default : count <= count;
endcase
end
else
begin
count <= (x) ? (count - 2'd1) : count;
end
end
endmodule
// Synthesis Result of elaborate command -
Elaborated 1 design.
Current design is now 'temp'.
1
I am trying to pass an integer value to a module, but the IF statement does not work with the parameter. It throws the following error. I am new to Verilog so I have no idea how to make this work.
Error (10200): Verilog HDL Conditional Statement error at clock_divider.v(17):
cannot match operand(s) in the condition to the corresponding edges in the enclosing
event control of the always construct
clock_divider.v module
module clock_divider (clockHandler, clk, rst_n, clk_o);
parameter DIV_CONST = 10000000 ; // 1 second
parameter DIV_CONST_faster = 10000000 / 5;
input clockHandler;
input clk;
input rst_n;
output reg clk_o;
reg [31:0] div;
reg en;
integer div_helper = 0;
always # (posedge clk or negedge rst_n)
begin
if(clockHandler == 0)
begin div_helper = DIV_CONST;
end
else
begin div_helper = DIV_CONST_faster;
end
if (!rst_n)
begin div <= 0;
en <= 0;
end
else
begin
if (div == div_helper)
begin div <= 0;
en <= 1;
end
else
begin div <= div + 1;
en <= 0;
end
end
end
always # (posedge clk or negedge rst_n)
begin
if (!rst_n)
begin
clk_o <= 1'b0;
end
else if (en)
clk_o <= ~clk_o;
end
endmodule
main.v module
reg clockHandler = 1;
// 7-seg display mux
always # (*)
begin
case (SW[2:0])
3'b000: hexdata <= 16'h0188;
3'b001: hexdata <= register_A ;
3'b010: hexdata <= program_counter ;
3'b011: hexdata <= instruction_register ;
3'b100: hexdata <= memory_data_register_out ;
3'b111: hexdata <= out;
default: hexdata <= 16'h0188;
endcase
if(SW[8] == 1)
begin
clockHandler = 1;
end
else
begin
clockHandler = 0;
end
end
HexDigit d0(HEX0,hexdata[3:0]);
HexDigit d1(HEX1,hexdata[7:4]);
HexDigit d2(HEX2,hexdata[11:8]);
HexDigit d3(HEX3,hexdata[15:12]);
clock_divider clk1Hzfrom50MHz (
clockHandler,
CLOCK_50,
KEY[3],
clk_1Hz
);
It's my understanding that the first statement in a verilog always block must be the if(reset) term if you're using an asynchronous reset.
So the flop construct should always look like this:
always # (posedge clk or negedge rst_n) begin
if(~rst_n) begin
...reset statements...
end else begin
...all other statements...
end
end
So for your case you should move the if(clockHandler==0) block inside the else statement, because it is not relevant to the reset execution. Even better would be to move it into a separate combinational always block, since mixing blocking and nonblocking statements inside an always block is generally not a good idea unless you really know what you're doing. I think it is fine in your case though.
To add to Tim's answer - the original code (around line 17, anyway) is valid Verilog.
What it's saying is "whenever there's a rising edge on clk or a falling edge on rst_n, check clockHandler and do something" (by the way, get rid of the begin/ends; they're redundant and verbose). The problem comes when you want to implement this in real hardware, so the error message is presumably from a synthesiser, which needs more than valid Verilog. The synth suspects that it has to build a synchronous element of some sort, but it can't (or won't, to be precise) handle the case where clockHandler is examined on an edge of both clk and rst_n. Follow the rules for synthesis templates, and you won't get this problem.
is this a compilation error or synthesis error? i used the same code to see if it compiles fine, and i din get errors.. Also, it is recommended to use "<=" inside synchronous blocks rather than "="
You're using the same flop construct for two different things. Linearly in code this causes a slipping of states. I always place everything within one construct if the states rely on that clock or that reset, otherwise you require extra steps to make sure more than one signal isn't trying to change your state.
You also don't need the begin/end when it comes to the flop construct, Verilog knows how to handle that for you. I believe Verilog is okay with it though, but I generally don't do that. You also don't have to use it when using a single statement within a block.
So your first module would look like this (if I missed a block somewhere just let me know):
clock_divider.v module (edited)
module clock_divider (clockHandler, clk, rst_n, clk_o);
parameter DIV_CONST = 10000000 ; // 1 second
parameter DIV_CONST_faster = 10000000 / 5;
input clockHandler;
input clk;
input rst_n;
output reg clk_o;
reg [31:0] div;
reg en;
integer div_helper = 0;
always # (posedge clk or negedge rst_n)
begin
if(!rst_n)
begin
div <= 0;
en <= 0;
clk_o <= 1'b0;
end
else if(en)
begin
clk_o <= ~ clk_o;
if(clockHandler == 0)
begin
div_helper = DIV_CONST;
end
else
begin
div_helper = DIV_CONST_faster;
end
else
begin
if (div == div_helper)
begin
div <= 0;
en <= 1;
end
end
else
begin
div <= div + 1;
en <= 0;
end
end
end
end module
If that clk_o isn't meant to be handled at the same time those other operations take place, then you can separate everything else with a general 'else' statement. Just be sure to nest that second construct as an if-statement to check your state.
And also remember to add always # (posedge clk or negedge rst_n) to your main.v module as Tim mentioned.
I wrote a behavioral program for booth multiplier(radix 2) using state machine concept. I am getting the the results properly during the program simulation using modelsim, but when I port it to fpga (spartan 3) the results are not as expected.
Where have I gone wrong?
module booth_using_statemachine(Mul_A,Mul_B,Mul_Result,clk,reset);
input Mul_A,Mul_B,clk,reset;
output Mul_Result;
wire [7:0] Mul_A,Mul_B;
reg [7:0] Mul_Result;
reg [15:0] R_B;
reg [7:0] R_A;
reg prev;
reg [1:0] state;
reg [3:0] count;
parameter start=1 ,add=2 ,shift=3;
always #(state)
begin
case(state)
start:
begin
R_A <= Mul_A;
R_B <= {8'b00000000,Mul_B};
prev <= 1'b0;
count <= 3'b000;
Mul_Result <= R_B[7:0];
end
add:
begin
case({R_B[0],prev})
2'b00:
begin
prev <= 1'b0;
end
2'b01:
begin
R_B[15:8] <= R_B[15:8] + R_A;
prev <= 1'b0;
end
2'b10:
begin
R_B[15:8] <= R_B[15:8] - R_A;
prev <= 1'b1;
end
2'b11:
begin
prev <=1'b1;
end
endcase
end
shift:
begin
R_B <= {R_B[15],R_B[15:1]};
count <= count + 1;
end
endcase
end
always #(posedge clk or posedge reset)
begin
if(reset==1)
state <= start;
else
begin
case(state)
start:
state <= add;
add:
state <= shift;
shift:
begin
if(count>7)
state <= start;
else
state <=add;
end
endcase
end
end
endmodule
You have an incomplete sensitivity list in your combinational always block. Change:
always #(state)
to:
always #*
This may be synthesizing latches.
Use blocking assignments in your combinational always block. Change <= to =.
Good synthesis and linting tools should warn you about these constructs.
Follow the following checklist if something does work in the simulation but not in reality:
Did you have initialized every register? (yes)
Do you use 2 registers for one working variable that you transfer after each clock (no)
(use for state 2 signals/wires, for example state and state_next and transfer after each clock state_next to state)
A Example for the second point is here, you need the next stage logic, the current state logic and the output logic.
For more informations about how to proper code a FSM for an FPGA see here (go to HDL Coding Techniques -> Basic HDL Coding Techniques)
You've got various problems here.
Your sensitivity list for the first always block is incomplete. You're only looking at state, but there's numerous other signals which need to be in there. If your tools support it, use always #*, which automatically generates the sensitivity list. Change this and your code will start to simulate like it's running on the FPGA.
This is hiding the other problems with the code because it's causing signals to update at the wrong time. You've managed to get your code to work in the simulator, but it's based on a lie. The lie is that R_A, R_B, prev, count & Mul_Result are only dependent on changes in state, but there's more signals which are inputs to that logic.
You've fallen into the trap that the Verilog keyword reg creates registers. It doesn't. I know it's silly, but that's the way it is. What reg means is that it's a variable that can be assigned to from a procedural block. wires can't be assigned to inside a procedural block.
A register is created when you assign something within a clocked procedural block (see footnote), like your state variable. R_A, R_B, prev and count all appear to be holding values across cycles, so need to be registers. I'd change the code like this:
First I'd create a set of next_* variables. These will contain the value we want in each register next clock.
reg [15:0] next_R_B;
reg [7:0] next_R_A;
reg next_prev;
reg [3:0] next_count;
Then I'd change the clocked process to use these:
always #(posedge clk or posedge reset) begin
if(reset==1) begin
state <= start;
R_A <= '0;
R_B <= '0;
prev <= '0;
count <= '0;
end else begin
R_A <= next_R_A;
R_B <= next_R_B;
prev <= next_prev;
count <= next_count;
case (state)
.....
Then finally change the first process to assign to the next_* variables:
always #* begin
next_R_A <= R_A;
next_R_B <= R_B;
next_prev <= prev;
next_count <= count;
case(state)
start: begin
next_R_A <= Mul_A;
next_R_B <= {8'b00000000,Mul_B};
next_prev <= 1'b0;
next_count <= 3'b000;
Mul_Result <= R_B[7:0];
end
add: begin
case({R_B[0],prev})
2'b00: begin
next_prev <= 1'b0;
end
.....
Note:
All registers now have a reset
The next_ value for any register defaults to it's previous value.
next_ values are never read, except for the clocked process
non-next_ values are never written, except in the clocked process.
I also suspect you want Mul_Result to be a wire and have it assign Mul_Result = R_B[7:0]; rather than it being another register that's only updated in the start state, but I'm not sure what you're going for there.
A register is normally a reg, but a reg doesn't have to be a register.
In Verilog HDL, how can I enforce that the rest of a register file to be untouched while I'm modifying a single bit? Like in the following example,
reg [31:0] result;
reg [31:0] next_result;
reg [4:0] count;
wire done;
//some code here...
result <= 32'b0;
always #* begin
if(done==1'b1) begin
next_result[count] <= 1'b1;
end
end
always #(posedge clock) begin
result <= next_result;
//the rest of the sequential part, in which count increments...
end
it turns out that result contains lots of x(unknown) values after several cycles, which means the register file is not held constant while I am modifying result[count]. Weird though, this problem is only present while I'm synthesizing, and everything goes just fine for simulation purposes. I wonder if there is some way to tell the synthesizer that I would like to "enforce" that not changing the rest of the register file.
You never assign all the bits inside the combinatorial loop. you have a floating assignment result <= 32'b0; I am surprised that this compiles. There is also an implied latch by not having next_result assigned in an else statement, ie when done=0 next_result would hold its value.
Try:
always #* begin
if(done==1'b1) begin
next_result = result;
next_result[count] = 1'b1;
end
else begin
next_result = result;
end
end
OR
always #* begin
next_result = result;
if(done==1'b1) begin
next_result[count] = 1'b1;
end
end
You have also used non-blocking <= assignments in the combinatorial loop.
I am new to verilog and I am working on verilg code that defines two modules.
The first module calculates the mod of 2 numbers and the second uses the result to do some operation on it.
The result was wrong and has alot of don't care values because the same clk was used in both modules. Any suggestion please for synchronisation.
The mod module
module mod(m,a,b);
input [15:0] a,b;
output [15:0] m;
reg [31:0] mod;
reg [31:0] mul;
integer i;
always #* begin
mul = a*b;
mod = 32'h80008000;
for(i=0;i<16;i=i+1) begin
if(mul > mod) begin
mul = mul - mod;
mod = mod >> 1;
end
else begin
mod = mod >> 1;
end
end
assign m=mul[15:0];
endmodule
Part of the top module:
initial begin
keyp <= 2'b10;
shift <= 1'b0;
end
always #(posedge clk) begin
if(load)
case (keyp)
2'b10: begin
key[127:64] <= {k1,k0};
keyp <= 2'b01;
end
2'b01: begin
key[63:0] <= {k1,k0};
keyp <= 2'b00;
shift <= 1'b1;
end
//default: keyp <=2'b00;
endcase
else if (shift) begin
//shift key for first round
temp[24:0] <= key[127:103];
key[127:25] <= key[102:0];
key [24:0] <= temp [24:0];
shift <= 1'b0;
end
end
assign w1[2*SIZE-1:SIZE] = d1+key[2*SIZE-1:SIZE];
assign w1[3*SIZE-1:2*SIZE] = d2+key[3*SIZE-1:2*SIZE];
mod mod1( w1[SIZE-1:0], d0, key[SIZE-1:0] );
mod mod2( w1[4*SIZE-1:3*SIZE], d3, key[4*SIZE-1:3*SIZE]);
Assigning to the same value multiple times with blocking assignments is perfectly valid Verilog. Even having the same term appear on both sides is fine, provided it's been assigned at least once prior to that.
The code here is incomplete but the problem appears to be that the code is assigning to 'key' in multiple places. Both as the output of the mod instances and inside the clocked block. Anytime these two 'disagree' about the value of key it's going to been seen as an X. X in addition to representing unknown also reflects contention where two different assignments conflict.
Since I'm not sure what this code is meant to do (seems to be some sort of encryption) I can't offer a fix but you need to separate the assignments to key.
x's are referred to as do not cares in casex statements or Karnaugh maps, here they represent unknown values. Unknown values can come from a value not being initialised (reset) or multiple (conflicting) drivers.
The mod module contains this section of code:
always #* begin
mul = a*b;
mod = 32'h80008000;
for(i=0;i<16;i=i+1) begin
if(mul > mod) begin
mul = mul - mod;
mod = mod >> 1;
end
else begin
mod = mod >> 1;
end
end
always #* is a combinatorial block, you assign mul multiple times only the last assignment will have any effect.
The use of a for loop here makes it look like you are trying to reuse variables, as you would in c. Remember that we are describing hardware and that the value is intended to exist somewhere as flip flops or wires between modules and can only hold a single value in any given clock cycle.
In the combinatorial block you have mul = mul - mod; that is mul defining itself this will not work, you need to add a flip flop to break the loop.