Unknown verilog error 'expecting "endmodule"' - verilog

In verilog I have an error that I can't get past. this is the first bit of the code then the last bit
module Decoder(op,funct,aluop,mwr,mreg,mrd,alusrc,regdst,regwr,btype);
input[5:0] op,funct;
output[2:0] aluop;
output[1:0] btype;
output mwr,mreg,mrd,alusrc,regdst,regwr;
wire aluop,mwr,mreg,mrd,alusrc,regdst,regwr,btype;
case(op)
6'b000000: begin
case(funct)
6'b001010:
assign aluop = 3'b010;
6'b001100:
assign aluop = 3'b111;
6'b010001:
assign aluop = 3'b011;
default:
assign aluop = 3'b000;
endcase
assign btype = 2'b00;
assign mwr = 1'b0;
assign mreg = 1'b0;
assign mrd = 1'b0;
assign alusrc = 1'b0;
assign regdst = 1'b1;
assign regwr = 1'b1;
end
...
default: begin
assign aluop = 3'b000;
assign mwr = 0;
assign mreg = 0;
assign mrd = 0;
assign alusrc = 0;
assign btype = 2'b00;
assign regdst = 0;
assign regwr = 0;
end
endcase
endmodule
it keeps giving me the following errors
Error (10170): Verilog HDL syntax error at Decoder.v(7) near text "case"; expecting "endmodule"
Error (10170): Verilog HDL syntax error at Decoder.v(14) near text "6"; expecting "endmodule"
It also does this at every end statement and default and endcase
I have no idea why it's doing this, I'm fairly new to verilog.
thanks in advance

I believe you're only allowed to use a case statement or if/else inside of an always block. I'm not sure why your error message doesn't say something a little more helpful, but that is likely to be the problem.
Try rewriting your code like the following:
//change wire types to reg type
always #*
begin
case (op)
6'b000000: begin
aluop = 3'b000
end
...
endcase
end

This is a guess, but the compiler is complaining because it is likely expecting IEEE 1364-2001 verilog and your code isn't valid for this version of the language. In any case, Tim's code is probably the functionality you're looking for.
As to why it isn't valid, Verilog contains essentially two 'contexts' inside every module declaration. Anything that appears directly in the module is a module item. These include reg/wire declarations, assign statements, always statements, generate constructs and module instances.
module mod;
reg reg1; //Module item
wire wire1; //Module item
assign wire1 = 0; //Module item
always reg1 = 0; //Module item
parameter con1 = 0; //Module item
//Instances a different module based on con1
case(con1) //Module item
0:mod2 inst1(reg1);
1:mod3 inst1(reg1);
2:mod4 inst1(reg1);
endcase
endmodule
Second, there are procedural contexts in which there can be procedural statements. This is any code inside a task declaration, function declaration, always block, initial block and a few other areas.
module mod2;
reg a;
always
begin
a = 0; //Procedural statement
end
initial
a = 0; //Procedural statement
function func1(input arg1);
case (arg1) //Procedural statement
0:func1 = 0;
default:func1 = 9;
endcase
endfunction
endmodule
Since 2001, Verilog contains two types of case statements, procedural case statements and generate case statements. Procedural case statements work just like they do in procedural languages but must appear in a procedural context. Generate case statements are evaluated statically before simulation starts and may only appear in a module declaration context as a module item. Note that the second context requires the case expression to be constant.
In the latest version of verilog, 1364-2005, a generate case may appear directly in the module scope however in the 2001 version of the language any generate item must be surrounded with generate..endgenerate keywords. If your compiler is expecting IEEE 1364-2001 then the error message you see makes sense.

Related

Assigning x (dont care) to a register reset value or combinatorical output to improve area efficiency [duplicate]

This question already has answers here:
How can I assign a "don't care" value to an output in a combinational module in Verilog
(2 answers)
Closed 2 years ago.
My question is regarding FPGA design - if I have some registers in my design that I dont care what will be their reset value, can I set the reset value to x? will that improve area efficiency (will the synthesizer be able to utilize this and generate the design in a more efficient way?)
For example,
always #(posedge clk or negedge reset_n) begin
if(~reset_n) begin
reg_1 <= 'x
end
...
end
Edit:
And another question in a similar topic - assuming I have a state machine for example that I dont care what will some outputs be in some states - does setting them to 'x improve area efficiency?
for example, if I have a fsm with two states, STATE_1, STATE_2, and two outputs will the synthesis tool be able to utilize the following code:
always_comb begin
case(state):
STATE_1:begin
out_1 = 1;
out_2 = x;
end
STATE_2:begin
out_1 = x;
out_2 = 0;
end
end
better than this:
always_comb begin
case(state):
STATE_1:begin
out_1 = 1;
out_2 = 0;
end
STATE_2:begin
out_1 = 0;
out_2 = 0;
end
end
(under the assumption that I dont care what is out_2 in STATE_1, and what is out_1 in STATE_2).
Thanks
Using 'x in sequantial logic
Yes, Verilog-wise, you could use this syntax. However, in your particular example, it does not really make sense to do this and you could consider it to be a bad coding practive. Instead of explicitly assigning 'x, you can also omit the asynchronous reset.
The following two processes will synthesise to the same flip-flop. I would personally recommend to use the latter style.
// Assigning 'x to tell synthesis tool that there is no reset value
always #(posedge clk or negedge reset_n)
if(~reset_n)
reg_1 <= 'x;
else
reg_1 <= reg_1_next;
// Omitting the asynchronous reset from the sensitivity list to tell
// synthesis tool that there is no reset
always #(posedge clk)
reg_1 <= reg_1_next;
In general: if you have different variables which must be either resetable or non-resetable, you should split their assignment into different always-blocks. This generally makes your code better readable. See the example below:
// Do NOT do this
always #(posedge clk or negedge reset_n)
if(~reset_n)
begin
vld <= 1'b0;
reg_1 <= 'x;
end
else
begin
vld <= vld_next;
reg_1 <= reg_1_next;
end
// Do this
always #(posedge clk or negedge reset_n)
if(~reset_n)
vld <= 1'b0;
else
vld <= vld_next;
always #(posedge clk)
reg_1 <= reg_1_next;
Bonus
Having said that, there are cases where it could make sense to assign 'x in the reset condition to tell the synthesis tool to not generate resetable flops for particular variables. Please take a look at this answer: https://stackoverflow.com/a/21477457/7949378
Lets create an example, based on this answer. Lets say you have a struct with 1 valid-signal (vld) and 2 data signals (data_a and data_b). The data is only valid when vld is 1'b1. In other words, we can save area by only resetting vld and not resetting data_a and data_b.
Now, we want to use the full potential of structs, and simply assign the full struct instead of the seperate members (see struct_example_q <= struct_example_next;). This means we cannot split this always-block into two seperate processes (like I recommened before). In that case, we must explicitly tell the synthesis tool to not reset the data signals.
See the code below:
typedef struct {
logic vld;
logic [31:0] data_a;
logic [31:0] data_b;
} struct_example_t;
struct_example_t struct_example_next;
struct_example_t struct_example_q;
always #(posedge clk or negedge reset_n)
if (!reset_n)
begin
/**
* Only reset the valid-bit
* We could use '{default:'x} to simplify this even further
**/
struct_example_q.data_a <= 'x;
struct_example_q.data_b <= 'x;
struct_example_q.vld <= 1'b0;
end
else
begin
struct_example_q <= struct_example_next;
end
Using 'x in combinatorial logic
Lets first look at your RTL:
always_comb begin
case(state):
STATE_1:begin
out_1 = 1;
out_2 = x;
end
STATE_2:begin
out_1 = x;
out_2 = 0;
end
end
I want to note that this is not really the best example. Assuming that the FSM is full—i.e., that STATE_1 and STATE_2 are the only two states state can take—you would achieve exactly the same with the code below, assuming you don't case anyway about out_1 and out_2 in the other states.
always_comb begin
out_1 = 1;
out_2 = 0;
end
Now, for the sake of the example, lets assume that we cannot rewrite this. In that case, you should set default values before your case-statement. This prevents the synthesis logic from infering latches in your don't-care state, but it also helps you to not run into issues with 'x once you start doing gate-level simulations (GLS). Using your example, you RTL would look like the code below. (Again note that the case here is kind of redundant.)
always_comb begin
out_1 = 1;
out_2 = 0;
case(state):
STATE_1:begin
out_1 = 1;
end
STATE_2:begin
out_2 = 0;
end
end
You will see that this strategy makes sense once you have more elaborate FSMs.
Bonus
I want to give an example where using unique or priority can make sense (instead of using 'x as default value). Take a look at the RTL below and assume that select == 3'b0 will never occur:
always_comb
begin
out_1 = 'x;
case (1'b1)
select[0]: out_1 = a & b;
select[1]: out_1 = a ^ b;
select[2]: out_1 = a | b;
endcase
end
Setting a default value for out_1 will prevent the logic from inferring a latch (since it does not know that select == 3'b0 can never occur). Furthermore, the 'x here will help the synthesis tool to optimize this logic (not necessarily w.r.t. area!). However, as we discussed before, using 'x is generally considered to be bad practice.
Instead of using a default value, you can use the priority keyword to tell the synthesis tool that all valid cases have been listed and that the tool must evaluate your cases in order. Because of that, the following case will also be considered as full:
always_comb
priority case (1'b1)
select[0]: out_1 = a & b;
select[1]: out_1 = a ^ b;
select[2]: out_1 = a | b;
endcase
If you, additionally, can be sure that select is a onehot signal ($countones(select) == 1), you can use the unique keyword. This will tell the synthesis tool that this is full-parallel case
always_comb
unique case (1'b1)
select[0]: out_1 = a & b;
select[1]: out_1 = a ^ b;
select[2]: out_1 = a | b;
endcase
Note that simulators will trry to enforce these assumptions by throwing errors at you if you violate the assumptions that are necessary to use priority or unique.

Verilog error: not a valid l-value

I'm trying to test if a wire(s) is on or not to signify if there is an error/overflow in my alu code. Given this code:
output reg[3:0]x; // line 149
output wire error;
output wire overflow;
always #* begin
if(error || overflow) begin
assign x = 4'b1111; // line 155
assign error = ~error;
assign overflow = ~overflow;
end else begin
assign x = opcode;
end
end
I get following error messages:
uut is my instantiation unit in my testbench called main
The code in the example has several issues.
1) you tried to use 'procedural assignments' which is an advanced verilog topic. In other words assign statement inside of an always block. This is not synthesizable, can only be used on reg types, and is there in verilog for very special cases. Do not use it.
You error messages coming from the fact that error and overflow are declared as wire.
2) you are trying to assign inverted version of a value to itself in a non-clocked logic. It will not behave the way you expect. Depending on usage it can either not toggle or will cause an infinite zero-delay loop, or in your case it could just generate a glitch.
So, potentially, your code should look something like the following:
input wire clk; // << you need clock
output reg[3:0]x; // line 149
output wire error;
output wire overflow;
reg error_reg, overflow_reg;
always #(posedge clk) begin
if(error || overflow) begin
x <= 4'b1111; // line 155
error_reg <= ~error;
overflow_reg <= ~overflow;
end else begin
x <= opcode;
end
assign error = error_reg;
assign overflow = overflow_reg;
end
Your using the assign incorrectly. That can be used outside of a always process, but not inside of one.
Also, the type wire, is required for an assign
wire [3:0] x;
assign x = 4'b1111;
Inside the always process, remove the assign statement and just say
reg [3:0] x; // Note that this is assigned as a reg now
always #* begin
if(blah) begin
x = 4'b1111;
end else begin
x = opcode;
end
end

How can I use the force with array in verilog?

I'd like to force some bunch of signals by derived multiple instances in verilog as below.
integer ii;
initial begin
for (ii=0; ii<19; ii=ii+1) begin
force sydnney.top.vx1.mpg.jpg[ii].trig.be[3] = 1'b1;
end
end
But, I've got the below error :
Illegal operand for constant expression [4(IEEE)].
Is that impossible way to using like that?
update
I've got some error when I use as below,
generate
wire val;
genvar xidx;
for(val=0; val<3; val=val+1) begin : force_be3y_loop
#10
for(xidx=0; xidx<3; xidx=xidx+1) begin : force_be3x_loop
initial force top.comp.img.tc[xidx].t1c.b2tc = val;
initial force top.comp.img.tc[xidx].t1c.b2tc[23] = val;
initial force top.comp.img.tc[xidx].t1c.b2tc[22] = val;
initial force top.comp.img.tc[xidx].t1c.b2tc[21] = val;
initial force top.comp.img.tc[xidx].t1c.b2tc[20] = val;
end
end
endgenerate
error message :
Expecting the keyword 'end' [12.1.3(IEEE 2001)].
An 'endgenerate' is expected [12.1.3(IEEE 2001)].
expecting the keyword 'endmodule' [12.1(IEEE)].
An 'endgenerate' is expected [12.1.3(IEEE 2001)].
Do I make something wrong?
update2
the original concept of mine is the below,
integer ii;
initial begin
for (bb=0; bb<3; bb=bb+1) begin
#10
for (ii=0; ii<19; ii=ii+1) begin
force sydnney.top.vx1.mpg.jpg[ii].trig.be[3] = bb;
...
end
end
but that is not work with
Illegal operand for constant expression [4(IEEE)] error message.
So I'm looking for solution.
The module portion of a hierarchical references must be constant. You cannot loop through the indexes of arrayed module instances or generate-for-loops at simulation time. You can loop through them durring the elaboration phase of compilation with a generate-for-loops.
generate
genvar gidx;
for(gidx=0; gidx<19; gidx=gidx+1) begin : force_be3_loop
initial force sydnney.top.vx1.mpg.jpg[gidx].trig.be[3] = 1'b1;
end
endgenerate

Verilog Array Walkthrough

I am just starting Verilog, and with little to no direction. I have been trying to build an 4 bit array that I want to walk through turning on and then off each of my LED's in order. I want them to go from 0-3, 7-4 and start over. I haven't set up my loops yet, however I want to see if I'm at least going in the right direction.
// 4 bit oscillating LED pattern
module count_osc (rstn, osc_clk, clk, LED);
input rstn;
output osc_clk;
output clk;
output [7:0] LED;
reg [22:0]c_delay;
genvar i;
genvar j;
GSR GSR_INST (.GSR(rstn)); // Reset occurs when argument is active low.
OSCC OSCC_1 (.OSC(osc_clk));
generate
for (i=0; i<4; i=i+1) begin : LED_loop
assign LED[i] = (clk);
for (j=4; j<8; j=j+1) begin : LED_loop_2
assign LED[j] = (~clk);
end
end
endgenerate
// The c_delay counter is used to slow down the internal oscillator (OSC) output
// to a rate of approximately 0.5 Hz
always #(posedge osc_clk or negedge rstn)
begin
if (~rstn)
c_delay <= 32'h0000;
else
c_delay <= c_delay + 1;
end
assign clk = c_delay[22];
endmodule
There are few misconceptions about verilog here, which are quite common for programmers coming from more procedural languages.
If your not aware Verilog describes hardware and therefore everything can happen in parallel, we do not procedurally start at the top and work our way through lines of code. Every initial and always blocks are running at the same time.
assign should be used outside of loops and it is a continuos assignment, ie combinatorial logic.
generate is used for parameterising hardware instances, you should not need this on basic examples. NB it also means that the hardware you describe can be quite tricky to understand.
With that in mind you may realise that this block:
generate
for (i=0; i<4; i=i+1) begin : LED_loop
assign LED[i] = (clk);
for (j=4; j<8; j=j+1) begin : LED_loop_2
assign LED[j] = (~clk);
end
end
endgenerate
Does not mean much, the first section is:
assign LED[0] = (clk);
assign LED[1] = (clk);
assign LED[2] = (clk);
assign LED[3] = (clk);
The second for loop is inside the first but only uses the second variable essentially overwriting the same statements 4 times:
assign LED[4] = (~clk);
assign LED[5] = (~clk);
assign LED[6] = (~clk);
assign LED[7] = (~clk);
When suggesting you write out what you want I was implying you write out the above instead of using generates.
Solution
I am not sure of the exact sequence you want from your question as you refer to a 4 bit array but uses 8 elements for the LED.
I think this might be a good place to practice creating a FSM (Finite state machine).
reg [2:0] state;
reg [2:0] nextstate;
always #(posedge clk or negede rst_n) begin
if (~rst_n) begin
state <= 'b0;
end
else begin
state<= nextstate;
end
end
//Next state logic (keeping it simple)
always #* begin
nextstate = state +1;
end
//Output logic
always #* begin
case(state)
3'd0 : LED = 'b0000_0000; //Binary makes sense as we can see the LED pattern
3'd1 : LED = 'b0000_0001;
3'd2 : LED = 'b0000_0011;
3'd3 : LED = 'b0000_0111;
3'd4 : LED = 'b0000_1111;
3'd5 : LED = 'b0000_0111;
3'd6 : LED = 'b0000_0011;
3'd7 : LED = 'b0000_0001;
default : LED = 'b0000_0000; //Default unreachable if we completed the case
endcase
end
I do not think this completes the sequence your trying to do but it should give enough of an understanding to complete the sequence yourself.

Verilog generate/genvar in an always block

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

Resources