I wrote some verilog code about a 7-to-1 Multiplexer with "always" and "case" statements but when I made a simulation in ModelSim, the outcome seems to not work as expected
Part of multiplexer logic :
when SW[9:7] = 000, OUT = SW[0]
Contradiction :
In the simulation when SW[0] is changed to 1, the outcome stays at 0.
module SevenToOneMUX(SW, OUT);
input [9:0] SW;
output reg OUT;
always#(SW[9:7])
begin
case (SW[9:7])
3'b000: OUT = SW[0];
3'b001: OUT = SW[1];
3'b010: OUT = SW[2];
3'b011: OUT = SW[3];
3'b100: OUT = SW[4];
3'b101: OUT = SW[5];
3'b110: OUT = SW[6];
endcase
end
endmodule
The problem is that you only put the 3 most-significant bit of SW in the sensitivity list of your combinational block. This means that the compiler will only execute the always#(SW[9:7]) block if SW[9:7] changes.
If you want to the simulator to update OUT when any of SW's bits changed, change your sensitivity list to the following:
always#(*)
begin
/*...*/
end
It is also worth to note that always#(*), which was added in Verilog-2001, is usually used when creating synthesizable combinational logic. In hardware, the real logic will be "sensitive" to every right-hand side variable. That means: if any input of the logic you describe changes, the output will also change.
Related
Trying this on a Terasic DE10-Lite, programmed with Quartus Prime Lite Edition.
SW[0] is a switch. LEDR[0] is an LED. KEY[0] is a push button. The push button is active low.
I want to model a flip flop that stores SW[0] in register r0 and displays it in LEDR[0] when KEY[0] delivers a rising edge.
The following works as expected:
module flipfloptest (
input [9:0] SW,
input [1:0] KEY,
output [9:0] LEDR);
reg r0;
assign LEDR[0] = r0;
always #(posedge(~KEY[0]))
r0 <= SW[0];
endmodule
I now add another push button, KEY[1], to the sensitivity list with the intention that pushing either down will set the flip flop.
module flipfloptest (
input [9:0] SW,
input [1:0] KEY,
output [9:0] LEDR);
reg r0;
assign LEDR[0] = r0;
always #(posedge(~KEY[0]) or posedge(~KEY[1]))
r0 <= SW[0];
endmodule
This behaves like a latch (i.e. no longer edge triggered). LEDR[0] immediately reflects the state of SW[0] without the need to press either KEY[0] or KEY[1]. Pressing one or both does not affect behavior in any way.
Clearly, I don't understand the meaning of this sensitivity list. What is the correct interpretation?
More context: I can get the desired behavior using a clock and state machine as shown below. My question is why the sensitivity list isn't behaving intuitively.
module flipfloptest (
input MAX10_CLK1_50,
input [9:0] SW,
input [1:0] KEY,
output [9:0] LEDR);
reg [1:0] tic0, tic1;
reg r0;
assign LEDR[0] = r0;
always #(posedge MAX10_CLK1_50) begin
case (tic0)
0: tic0 = (~KEY[0])?1:0;
1: tic0 = (~KEY[0])?2:0;
2: tic0 = (~KEY[0])?2:0;
endcase
case (tic1)
0: tic1 = (~KEY[1])?1:0;
1: tic1 = (~KEY[1])?2:0;
2: tic1 = (~KEY[1])?2:0;
endcase
if (tic0==1 | tic1==1)
r0 <= SW[0];
end
endmodule
Synthesis tools only recognize certain Verilog coding patterns. Refer to synthesizable constructs. The documentation for your Quartus tool set should describe what coding styles are supported.
Your 1st and 3rd code examples adhere to the synthesizable coding style, whereas your 2nd example does not. You should look at the log files that your synthesis tools created: there should be messages in there warning you about unintended latches.
The code in your 2nd example is unusual. Perhaps your synthesis tool did not know what to do with it, and it just decided to give you a latch. Unfortunately for you, that is not how your code simulates.
This code:
always #(posedge(~KEY[0]) or posedge(~KEY[1]))
r0 <= SW[0];
can be simplified as:
always #(negedge KEY[0] or negedge KEY[1])
r0 <= SW[0];
r0 will be updated with SW[0] every time you get a negedge of either KEY[0] or KEY[1]. That does not behave like a latch. But, as I said, this code does not adhere to typical synthesis coding style.
Currently, I am beginning to write the firmware by Verilog for one idea. It is comparing bit by bit between two variables and then using one binary counter to count the number of different bits.
For example:
I have two variables in verilog
A : 8'b00100001;
B : 8'b01000000;
Then I give the condition to compare bit by bit between two variables. If there is difference between 1 bit of A and 1 bit of B at same bit position, binary counter will count.
This is my verilog code:
module BERT_test(
input CLK,
input RST,
input [7:0] SIG_IN,
input [7:0] SIG_OUT,
output [7:0] NUM_ERR
);
integer i;
reg[7:0] sign_in;
reg[7:0] sign_out;
always #(posedge CLK) begin
sign_in[7:0] <= SIG_IN[7:0];
sign_out[7:0] <= SIG_OUT[7:0];
end
reg [15:0] bit_err;
// Combinational Logic
always #* begin
bit_err = 8'b0;
for (i=0;i<8;i=i+1) begin
if (sign_in[i] == sign_out[i]) begin
bit_err = bit_err + 8'b0;
end else begin
bit_err = bit_err + 8'b1;
end
end
assign NUM_ERR = bit_err;
end
endmodule
Then I had a mistake
Reference to vector wire 'NUM_ERR' is not a legal reg or variable lvalue
I do not know how to solve this problem. Are there any solutions for this problem or how I need to modify my firmware, please suggest me.
You are driving NUM_ERR (a net) from an always block. It is not permitted to drive nets from always blocks (or initial blocks). You need to move this line:
assign NUM_ERR = bit_err;
outside the always block.
You should not use an assign statement inside an always block. This is legal but is deprecated and means something weird. If you have included this line inside the always block by mistake, then indenting you code properly would have shown it up.
You have an assign WITHIN an always block. Move it outside.
Adding zero to bit error if the bits are the same is superfluous.
if (sign_in[i] != sign_out[i])
bit_err = bit_err + 8'b1;
Also bit error is 16 bits so it is not wrong to add 8'b1 but misleading.
Writing verilog code from quite a few days and one question I have is 'Can we write generate block inside generate block'? I am writing an RTL something like this:
Where 'n' is a parameter.
reg [DATA_WIDTH:0] flops [n-1:0];
generate
if (n > 0) begin
always #(posedge clk) begin
if (en) begin
flops[0] <= mem[addr];
end
end
generate
genvar i;
for (i = 1; i <= n ; i = i + 1) begin
always #(posedge clk) begin
flops[i] <= flops[i-1];
end
end
endgenerate
always #(flops[n - 1])
douta = flops[n - 1];
else
always #(posedge clk) begin
if (en) begin
primary_output = mem[addr];
end
end
end
endgenerate
While compiling the above code, I am getting :
ERROR: syntax error near generate (VERI-1137)
Not sure why. Purpose of this RTL is to create an pipeline of 'n' flops at the output side of the design.
Lets say n is 2, then circuit should become :
flop1-> flop2-> primary output of design
flop1 and flop2 are newly created flops.
You are a long long way from where you should be.
Verilog is not a programming language; it is a hardware description language. You model hardware as a network of concurrent processes. Each process models a small bit of hardware such as a counter, a state machine, a shift-register, some combinational logic... In Verilog, each process is coded as an always block. So, one always statement never ever can appear inside another; that makes no sense.
Secondly, generate is quite a specialised statement. You use it when you want either a large number or a variable number of concurrent processes. That is not a common thing to need, so generate is not common, but is useful when required. You don't need a generate statement to implement a parameterisable shift-register. And, because an always block is a concurrent statement it sits inside a generate statement, not the other way round.
I don't know what your design intent is exactly, to I suspect this code does not do exactly what you want. However, it does implement a parameterisable shift-register of length n and width DATA_WIDTH+1 (did you really mean that?), enabled by the en input:
module N_FLOPS #(n = 2, DATA_WIDTH = 8) (input [DATA_WIDTH:0] dina, input clk, en, output [DATA_WIDTH:0] douta);
reg [DATA_WIDTH:0] flops [n-1:0];
always #(posedge clk)
if (en)
begin : SR
integer i;
flops[0] <= dina;
for (i = 1; i <= n ; i = i + 1)
flops[i] <= flops[i-1];
end
assign douta = flops[n-1];
endmodule
http://www.edaplayground.com/x/3kuY
You can see - no generate statements required. This code conforms to this template, which suffices for any sequential logic without an asynchronous reset:
always #(posedge CLOCK) // or negedge
begin
// do things that occur on the rising (or falling) edge of CLOCK
// stuff here gets synthesised to combinational logic on the D input
// of the resulting flip-flops
end
I am trying to make a counter in verilog and I want to know how to split the sequential part from the combinational one.
I have this module, it works fine, but I don't know how to split it?
module counter4bits(
input clk_i,
input rst_n_i,
input enable_i,
input up_down_i,
output reg[3:0] val_o);
always#(posedge clk_i) begin
if (rst_n_i == 1)
val_o <= 0;
else if(enable_i == 1)
val_o <= val_o + 1;
end
endmodule
One way is to make always #(*) blocks for the combinational parts using blocking assignments (=), and make always #(posedge clk_i) blocks for the sequential parts using non-blocking assignments (<=) to simple reg.
The blocking assignment (=) in combinational gives faster simulation and predictable behavior even if explicit sensitivity lists line #(rst_n_i or enable_i or ...) are used instead of #(*). The non-blocking assignment (<=) in sequential logic gives the expected flip-flop behavior where the next value depends on the previous value.
The code will then look like:
module counter4bits(
... input/output with no change
reg [3:0] val_nxt; // Not flip-flop but used in always #(*) thus reg
always #(*) begin
if (rst_n_i == 1)
val_nxt = 0;
else if(enable_i == 1)
val_nxt = val_o + 1;
end
always #(posedge clk_i)
val_o <= val_nxt;
endmodule
Why do you want to split the combinational and sequential logic.
The code you have written is good style for the power optimization.
With your style of code the tool can understand the flip flop value will change on enable_i hence the tools are intelligent enough to put a clock gate for flop using enable_i which will reduce the power.
I'm learning verilog and I think there is something that I must not understand about always #* and always (#posedge clk, ...)
Here is a piece of code supposed to send bits via uart. It fails at synthesization.
The error is
" The logic for does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release."
(and 3 other errors for , and )
If I change the always #(...) by always #*, things fail in the next step ("implement design") because things are not connected.
In the book that I have, they implement an fsmd with an always (posedge clk) for the state, and always #* for the other logic, but I don't understand why this doesn't work.
On another forum, I read that the error could come from too complicated conditions. But I have simplified things too (not code the code here but basically I removed the case(state) and the ifs to have single line assignments with ? : or binary conditions, but it didn't work either)
I have seen this error before in other pieces of code that I wrote but I didn't get to the bottom of it, so if you could help me understand the general problem (with this uart thing as a support for a concrete example), I would be very happy.
Thanks
Thomas
P.S : Im using xilinx spartan 3e starter kit and xilinx ise 14.4
module UART_out #(parameter [3:0] NUM_BITS = 8)
(
input wire baud_clk,
input wire send_tick,
input wire[NUM_BITS-1:0] data_in,
output wire tx,
output wire debug_done
);
localparam
IDLE = 0,
TRANSMIT = 1;
reg[NUM_BITS:0] bits_to_send;
reg state;
reg out_bit;
reg[4:0] cnt;
always #(posedge baud_clk, posedge send_tick)
begin
case (state)
IDLE:
if (send_tick)
begin
bits_to_send <= {data_in, 0};
state <= TRANSMIT;
cnt <= 0;
end
TRANSMIT:
begin
if (cnt < NUM_BITS)
cnt <= cnt + 1;
else
state <= IDLE;
bits_to_send <= {1, bits_to_send[NUM_BITS:1]};
out_bit <= bits_to_send[0];
end
endcase
end
assign tx = (state == IDLE ? 1 : out_bit);
assign debug_done = (state == IDLE);
endmodule
The error:
The logic for does not match a known FF or Latch template. The description style you are using to describe a register or latch is not supported in the current software release.
Is referring to the fact that the synthesis tool does not have any hardware cells to use which match your description.
What hardware do you want from :
always #(posedge baud_clk, posedge send_tick)
This looks like you want a flip-flop with an enable signal. The enable signal (send_tick) should be 1 clock period wide. This is then used to select the path of logic on a clock edge. not as an alternative trigger.
I think that this is all you really need:
always #(posedge baud_clk) begin
case (state)
IDLE:
if (send_tick) begin
//...
end
//...
endcase
end
If send_tick is from another clock domain then you will need to do some clock domain crossing to turn it it to a clock wide pulse on the baud_clk.
You may be getting confused with blocks which have multiple triggers, they are normally a clk and reset. A negedge reset_n or posedge reset are often added for reset (initialisation) conditions.
If adding a reset :
always #(posedge baud_clk or negedge reset_n) begin
if (~reset_n) begin
//reset conditions
state <= IDLE;
//...
end
else begin
// Standard logic
end
end
You will notice that there is a very definite structure here, if reset else ... The synthesis tools recognise this as a flip-flop with an asynchronous reset. The data in the reset condition is also static, typically setting everything to zero.