When I compile my code I get these error msg for following lines. can someone explain it.
This is verilog code for a processor
assign Imm = instruction[7:0];
assign OUT1addr = instruction[2:0];
assign OUT2addr = instruction[10:8];
assign INaddr = instruction[18:16];
assign address = instruction[23:16];
assign address = instruction[7:0];
The following message comes for ABOVE LINES
tgt-vvp sorry: procedural continuous assignments are not yet fully supp
orted. The RHS of this assignment will only be evaluated once, at the time the assignment statement is executed.
You did not do what I asked which is show me where that code is.
From the error message I very much suspect that code is inside an always block:
always #( ...)
...
assign Imm = instruction[7:0];
This is called "a procedural continuous assignment".
The alternative is:
always #( ...)
...
Imm = instruction[7:0];
This is a standard assignment.
There is a significant difference between the two. You would normally not use the first form (unless you really, really know what you are doing.)
Thus the solution is to remove all the 'assign' keywords if they are inside an always block.
Outside an always you need the assign:
always #( * )
begin
...
x = y ^ z;
end
assign write = valid & select;
The short answer is you should probably remove the assign keyword.
The assign keyword has two different meanings depending on context you do not show.
When used at the top level of a module, the assign keyword is a permanent process sensitive to RHS changes and assigns it to the LHS wire. The assign statement has equivalent functionality to the always block below
module mod;
...
assign Awire = B + C;
always #(B or C) begin
Areg = B + C;
end
endmodule
When used inside a procedural process, it is a temporary process that assigns the LHS variable every time the RHS changes. The two always blocks below have the same functionality
module top;
...
always #(sel)
begin
if (sel)
assign Areg = B;
else
assign Areg = C;
end
always #(sel or B or C) // #*
begin
if (sel)
Areg = B;
else
Areg = C;
end
endmodule
Unfortunately, almost all synthesis tools require you to write your code with a complete sensitivity list as in the latter always block. Thus this eliminates allowing the use of assign inside a procedural block.
Related
I am trying to write an "inverter" function for a 2's compliment adder. My instructor wants me to use if/else statements in order to implement it. The module is supposed to take an 8 bit number and flip the bits (so zero to ones/ones to zeros). I wrote this module:
module inverter(b, bnot);
input [7:0] b;
output [7:0]bnot;
if (b[0] == 0) begin
assign bnot[0] = 1;
end else begin
assign bnot[0] = 0;
end
//repeat for bits 1-7
When I try and compile and compile it using this command I got the following errors:
vcs +v2k inverter.v
Error-[V2005S] Verilog 2005 IEEE 1364-2005 syntax used.
inverter.v, 16
Please compile with -sverilog or -v2005 to support this construct: generate
blocks without generate/endgenerate keywords.
So I added the -v2005 argument and then I get this error:
vcs +v2k -v2005 inverter.v
Elaboration time unknown or bad value encountered for generate if-statement
condition expression.
Please make sure it is elaboration time constant.
Someone mind explaining to me what I am doing wrong? Very new to all of this, and very confused :). Thanks!
assign statements like this declare combinatorial hardware which drive the assigned wire. Since you have put if/else around it it looks like you are generating hardware on the fly as required, which you can not do. Generate statements are away of paramertising code with variable instance based on constant parameters which is why in this situation you get that quite confusing error.
Two solutions:
Use a ternary operator to select the value.
assign bnot[0] = b[0] ? 1'b0 : 1'b1;
Which is the same as assign bnot[0] = ~b[0].
Or use a combinatorial always block, output must be declared as reg.
module inverter(
input [7:0] b,
output reg [7:0] bnot
);
always #* begin
if (b[0] == 0) begin
bnot[0] = 1;
end else begin
bnot[0] = 0;
end
end
Note in the above example the output is declared as reg not wire, we wrap code with an always #* and we do not use assign keyword.
Verliog reg vs wire is a simulator optimisation and you just need to use the correct one, further answers which elaborate on this are Verilog Input Output types, SystemVerilog datatypes.
I am somewhat new to Verilog. I know that in a Clock Process we should use non blocking assignments, and in a Non Clock processes, we use blocking assignments.
I have came across this code, when I was reading someone else's code.
reg iowrb_int,iowrb_met;
reg iordb_int,iordb_met;
always#(*)
begin
iowrb_int <= iowrb_met;
iordb_int <= iordb_met;
iowrb_met <= iowr_bar;
iordb_met <= iord_bar;
end
I am really not sure about the above code ! I don't think it is doing any registering, correct? Would it mean anything to have a non-blocking in a always#(*) statement ?
Is there any difference in using blocking vs non-blocking in a always#(*) statement ?
The main difference is:
a blocking assignment is executed before the next assignment i.e. it blocks the execution of the next statement.
non-blocking assignments execute in parallel i.e. they don't block the execution of the statement following them.
Suppose a = 2 and b = 3 then non-blocking assignments:
a <= 4;
b <= a;
results in a = 4 and b = 2 - value of a before assignment
But
a = 4;
b = a;
Will result in a=4 and b=4 - value of a after the blocking assignment completes.
A variable getting synthesized to a register (latch or flip-flop) vs. combinatorial logic depends on the sensitivity list of the always block. It does not depend on use of blocking or non-blocking assignment.
For example:
always #(*) begin
if (enable)
q = d;
end
This will result in a D-latch since assignment to q is not specified for when enable==0 so it needs to remember is last assignment.
While
always #(*) begin
if (enable)
q = d;
else
q = f;
end
This will result in a mux (combinatorial logic) since assignment to q is specified for both cases of enable and so q need not remember anything.
The blocking vs non-blocking is so that your gate level (synthesis) matches your RTL simulation. Using a different one to alter the behaviour of the simulation as far as I know will not effect synthesis and therefore the behaviour of gate-level.
<= non-blocking effectively take a temporary copy of the copy right-hand side, and make the = blocking assignment at the end of the timestep.
a <= b;
b <= a;
is equivalent to:
a_temp = b;
b_temp = a;
//
a = a_temp;
b = b_temp;
The example uses combinatorial logic, that is it contains no state, so all inputs must be defined by all outputs.
always#* begin
iowrb_int <= iowrb_met;
iordb_int <= iordb_met;
iowrb_met <= iowr_bar;
iordb_met <= iord_bar;
end
When the right hand side updates the block should be retriggered. Since iowrb_met is on both sides I am not sure what this implies interms of electrical connectivity.
while <= implies copying to a temp location, combinatorial logic does not have this capability, it is always and continuously driven by the assignment.
I think in simulation you effectively have this:
always#* begin
iowrb_int_temp = iowrb_met;
iordb_int_temp = iordb_met;
iowrb_met = iowr_bar;
iordb_met = iord_bar;
iowrb_int = iowrb_int_temp;
iordb_int = iordb_int_temp;
end
In hardware you would have:
always#* begin
iowrb_int = iowrb_met; //= iowr_bar;
iordb_int = iordb_met; //= iord_bar;
iowrb_met = iowr_bar;
iordb_met = iord_bar;
end
Where iowrb_int is effectively the same as iowrb_met
Flip-flops are implied using always #(posedge clk
Combinatorial logic is implied using always #* but latches can be implied when the output is not fully defined from inputs.
By only changing to code to blocking assignments it may synthesize to latches and/or create logical equivalency check mismatches depending on the tools handle.
This is how it looks through the scheduler:
With blocking:
The *_int signals are assigned
The *_met signals are assigned
Move on to the next time step.
*_int keeps the non-updated values of *_met
With non-blocking:
The *_int signals are assigned
The *_met signals are assigned
A change to *_met is detected causes a loop back the the Active region of the scheduler
Re-assign the *_int signals
Re-assign the *_int signals
Move on to the next time step.
*_int has the same values as *_met
Waste CPU time to reprocessing. This is not important on a small project, but can add noticeable overhead used throughout a large project.
The correct, logical equivalent, and CPU friendly way would be to revers the assignment order (assign *_met before *_int):
always#(*)
begin
iowrb_met = iowr_bar;
iordb_met = iord_bar;
iowrb_int = iowrb_met;
iordb_int = iordb_met;
end
The *_int signals are assigned
The *_met signals are assigned
Move on to the next time step.
*_int has the same values as *_met
OR use *_bar as the assigning value (i.e. if a==b and b==c, then a==b and a==c):
always#(*)
begin
iowrb_int = iowr_bar;
iordb_int = iord_bar;
iowrb_met = iowr_bar;
iordb_met = iord_bar;
end
The *_int and *_met signals are assigned
Move on to the next time step.
*_int has the same values as *_met
As others have said, changing to blocking assignments here will actually not work. Using blocking assignments in combinational always blocks (which is the recommendation) require you to put assignments in the right order.
Using non-blocking assignments in combinational always blocks may seem attractive, because you can then have assignments in any order, like in VHDL. Besides performance, one good reason to avoid this is that it doesn't work with always_comb. This code does not work:
always_comb begin
tmp <= in;
out <= tmp;
end
The reason is that tmp will not be part of the sensitivity list. It will work as expected if you use always #(*), always #(tmp, in) or replace with blocking assignments.
I tried to figure out the inferred latch and why it is needed internally, but I couldn't find any resources with enough detail.
A latch is inferred within a combinatorial block where the net is not assigned to a known value. Assign a net to itself will still infer a latch. Latches can also be inferred by missing signals form a sensitivity list and feedback loops.
The proper way of inferring a intended latch in Verilog/SystemVerilog are:
/* Verilog */ //// /* SystemVerilog */
always #* //// always_latch
begin //// begin
if (en) q = d; //// if (en) q = d;
end //// end
Ways latches are accidentally inferred:
Signal(s) missing for the sensitivity list (this is why #* should be used):
always #(a or b) // inferred latch :: "c" missing for the sensitivity list.
begin
out = a + b + c;
end
Missing Condition:
always #*
begin
case(in[1:0])
2'b00: out = 1'b0;
2'b01: out = 1'b1;
2'b10: out = 1'b1;
// inferred latch "out" :: missing condition 2'b11/default
endcase
end
always #*
begin
next0 = flop0;
next1 = flop1;
// inferred latch "next2" :: missing initial condition
next3 = flop3;
case(a[2:0])
3'b001: next0 = in;
3'b010: if(b) next1 = in;
3'b100: if(c) next2 = in;
default: if(!b&&!c) next3 = in;
endcase
end
Feedback Loop:
assign out = en ? in : out; // inferred latch "out" :: feedback to mux
assign a = en ? z : c;
// ... any amount of code between ...
assign z = en ? a : y; // inferred latch "a" :: feedback chain
Feedback loops can traverse through the hierarchy and design.
How to mitigate the risk of unintended latches:
Make intended latches simple and identifiable:
Put intended latches in their own always blocks with as little combinatorial logic as possible; ideally put the latches' combinatorial logic in its own separate always block. Be as explicit and identify intended latches. Use comments, labels, and if possible use the SystemVerilog always_latch.
All combinatorial logic blocks need to be defined with always #* or SystemVerilog's always_comb.
Make sure all variables assigned in a combinatorial logic blocks have an initial or default assignment.
case statements should have a default condition.
if statements should have a corresponding else.
When the combinatorial logic blocks is assigning many variables, giving each variable an initial value at the start of the block (before any case or if).
Know where the inputs are coming from and where the outputs are going to.
The inputs of combinatorial logic should be flops or the outputs combinatorial logic should be flops.
Do code reviews, use linting tools and logical-equivalency-checking tools.
Code review requires the reviewer(s) to know where latches could hide.
Using SystemVerilog's always_comb can help identify inferred latches with linting and logical-equivalency-checking tools.
Worst case scenario, put all logic inside synchronous blocks. All inferred latches become inferred flip-flops. This is usually a bad idea because it can unnecessarily increases the gate count, create more routing, and impact timing.
A latch is inferred when the output of combinatorial logic has undefined states, that is it must hold its previous value.
Combinatorial logic does not have any flip-flop to hold state therefore the output should always be defined by the inputs.
A short example might be:
always #* begin
if (a == 1'b1) begin
b = x|y|z;
end
end
What is b when a == 1'b0. b is not being overridden so it would hold its value. How can something hold its value when it does not have the concept of state. You have to introduce state by inferring a latch. This is normally a really bad thing.
You can imply latches and be carefull about the timing etc but inferred latches are nominally from buggy code.
Latches are only generated with combinational always blocks. Sequential logic will never generate a latch.
For more information read about how transparent latches are created and how to avoid inferring latches
I am trying to write a simple module to output a 14-bit number based on the value of four input signals. My attempt is shown below.
module select_size(
input a,
input b,
input c,
input d,
output [13:0] size
);
if (a) begin
assign size = 14'h2222;
end
else begin
if (b) begin
assign size = 14'h1111;
end
else begin
if (c) begin
assign size = 14'h0777;
end
else begin
assign size = 14'h0333;
end
end
end
endmodule
Upon compilation, I receive the following error:
ERROR:HDLCompiler:44 - Line 67: c is not a constant
I don't understand why that particular if-statement isn't working if the other two preceding it are. I have tried changing the condition to
if (c == 1) begin
but to no avail.
Does anybody know how to solve this error? Thank you!
Two problems:
1) You need to put if statements inside an always block.
If you use verilog-2001, you can use
always #*
if ....
end
end
Otherwise specify all the inputs in the sensitivity list:
always #(a or b or c or d)
if ....
end
end
2) Constant assignments are not allowed inside if statements.
Remove the assign keyword from any statements inside the if block:
if (a) begin
size = 14'h2222;
end
You will also have to declare size as a reg type.
However my preference would be to rewrite the entire module with conditional operator, I find it much preferrable to read. This following module achieves the same result:
module select_size(
input a,
input b,
input c,
input d,
output [13:0] size
);
assign size = a ? 14'h2222 :
b ? 14'h1111 :
c ? 14'h0777 :
14'h0333 ;
endmodule
As #Tim has already answered, using reg types inside always blocks or wire with assign.
#Tim has also described the nested ternary assignments, while in the example are written very well, they are generally seen as bad practice. They imply a very long combinatorial path and can be hard to maintain. The combinatorial path may be optimised by synthesis which should imply a mux with optimised selection logic.
Easier to maintain code will have a lower cost of ownership, and as long as it does not lead to a larger synthesised design it is normally preferred.
My implementation would be to use a casez, (? are don't cares). I find the precedence of each value easier to see/debug.
module select_size(
input a,
input b,
input c,
input d,
output logic [13:0] size //logic (SystemVerilog) or reg type
);
always #* begin
casez ({a,b,c})
3'b1?? : size = 14'h2222 ;
3'b01? : size = 14'h1111 ;
3'b001 : size = 14'h0777 ;
3'b000 : size = 14'h0333 ;
default: size = 'bx ;
endcase
end
endmodule
Is this allowed?
input w;
input [8:0]y;
output reg [8:0]x;
always#(w)
begin
//x[0] or A is never on in any next state
assign x[0] = 0;
assign x[1]= (y[0]&~w) | (y[5]&~w) | (y[6]&~w) | (y[7]&~w) | (y[8]&~w); //B
assign x[2]= (y[1]&~w); //C
assign x[3]= (y[2]&~w); //D
assign x[4]= (y[3]&~w) | (y[4]&~w); //E
assign x[5]= (y[0]&w) | (y[1]&w) | (y[2]&w) | (y[3]&w) | (y[4]&w); //F
assign x[6]= (y[5]&w);
assign x[7]= (y[6]&w);
assign x[8]= (y[7]&w) | (y[8]&w);
end
You can, it's called a "Procedural Continuous Assignment". It overrides ordinary procedural assignments, there doesn't seem to be a call for them in the code you've posted. I'm not sure if they're synthesisable, but I never have cause to use them anyway.
A note on your code - you're missing y from your sensitivity list: eg always #( w or y ) or always #(*) is safer.
Building upon Marty's answer, you should read section 9.3 of the IEEE Verilog Standard (1364-2005, for example), where it describes "Procedural Continuous Assignment". The spec allows for assign statements within an always block. However, from my experience, it is quite rare.
Another issue with your code is that it has compile errors with two different simulators that I tried. Both generate error messages that bit-selects or part-selects cannot be used on the left hand side of the assignment.
Another possible solution is to get rid of the always block, and just use simple continuous assignments.
input w;
input [8:0] y;
output [8:0] x;
assign x[0] = 0;
assign x[1]= (y[0]&~w) | (y[5]&~w) | (y[6]&~w) | (y[7]&~w) | (y[8]&~w); //B
assign x[2]= (y[1]&~w); //C
assign x[3]= (y[2]&~w); //D
assign x[4]= (y[3]&~w) | (y[4]&~w); //E
assign x[5]= (y[0]&w) | (y[1]&w) | (y[2]&w) | (y[3]&w) | (y[4]&w); //F
assign x[6]= (y[5]&w);
assign x[7]= (y[6]&w);
assign x[8]= (y[7]&w) | (y[8]&w);
The procedural continuous assign statement was intended to be an optimized way of writing a mux-like behavior. For example, if you have
always #(A or B or select)
if (select)
out = A;
else
out = B;
You could write this as
always #(select)
assign out = A;
else
assign out = B;
But people don't like having to deal with sensitivity lists, so #(*) was added to Verilog, and SystemVerilog added always_comb.
But the real killer for this construct is that many people would write code like
always #(*)
assign out = A;
Which simulates fine, but you now have a double penalty in performance because the assign statement is already sensitive to changes in A, but so is the always block. This repeatedly executes the procedural assign statement replacing the same RHS.
Assign is a continuous assignment statement which is used with wires in Verilog. assign statements don't go inside procedural blocks such as always. Registers can be given values in an always block.
Assign statements can be viewed as:
always #(*)
statements for wires.
Yes, but you don't want to. Since x[] doesn't depend on x[] the order doesn't matter. Just use <= instead of assign =.
There is no need using assign inside a procedural block (In this case Always)
Assign is a continuous assignment, and it has to go outside a procedural block.
Thinking from the circuit level: this always(w) begin ..... end , so every code inside it will be activated whenever w is changed ie it falls or raise .
assign statement requires pin/port which it assign to some wire or reg output
its a complete combinational circuit I am unable to see how the same will only activate at w, that is who/what circuit will make it to only change when w either rises or fall
anyway you cant assign a reg output to some wire/reg output using assign statement because as I said it requires you to put pin/port to be assigned only
anyway if you go for basic verilog and not so called "Procedural Continuous Assignment" i guess its weird to use the same .