I'm having difficulty figuring out how to assign the value of temp to the out. I searched the web for an answer and tried all kinds of things but still cannot get the output assigned. Here's the code:
module Reg8bit(
input CLK,
input En,
input CLR,
input [7:0] in,
output [7:0] out
);
reg[7:0] temp;
always #(posedge CLK)
begin
if (En)
begin
if (CLR)
out = 8'b0000_0000;
else
out = in;
end
end
assign out = tempQ;
endmodule
Edit: temp should be tempQ, sorry for the typo
You probably meant to write
module Reg8bit(
input CLK,
input En,
input CLR,
input [7:0] in,
output reg [7:0] out // out is a variable, not a wire
);
always #(posedge CLK)
begin
if (En)
begin
if (CLR)
out <= 8'b0000_0000; // use Non-blocking assignments
else
out <= in;
end
end
endmodule
Your code doesn't make much sense. You are assigning to out twice and your not using your temp register.
You probably meant to write something like this:
reg[7:0] temp;
always #(posedge CLK)
begin
if (En)
begin
if (CLR)
temp <= 0;
else
temp <= in;
end
end
assign out = temp;
Its usually (not always) considered good practice to use nonblocking assignments in always blocks. I think in this case you can even do this without the temp register.
The LHS of the assign statement should always be a wire. You have declared out as a reg and it's good to use a reg data type in the LHS inside an always block.
Related
This question already has answers here:
Why is this code getting inferred latches?
(2 answers)
Closed 5 months ago.
I am design a register file module and I am trying to prevent the "inferred latch warning". The module allows for asynchronous reads but synchronous writes. This is what I have designed so far. I generally know what latches are, but can't think of a solution to prevent latches in this case. What would I define as the else statement so that the regfile doesn't create inferred latches?
module register_file (
input wire clk,
input wire rst,
input wire [4:0] raddr_a,
input wire [4:0] raddr_b,
output reg [15:0] rdata_a,
output reg [15:0] rdata_b,
input wire [4:0] waddr,
input wire [15:0] wdata,
input wire we
);
reg [15:0] regfile [0:31];
/// 32 x 16 bit register file
// asynchronous reads
// don't allow read zero register
assign rdata_a = (raddr_a == 5'd0) ? 16'd0 : regfile[raddr_a];
assign rdata_b = (raddr_b == 5'd0) ? 16'd0 : regfile[raddr_b];
integer i;
always #(clk) begin
// reset registers
if (rst) begin
for (i = 0; i < 32; i = i + 1) begin
regfile[i] <= 0;
end
end else begin
// if write enabled, write to register at waddr
if (we == 1'b1) begin
regfile[waddr] <= wdata;
end
end
end
endmodule
Would I set the value to itself? How would I go on preventing an inferring latch? Thanks!
Change always statement from:
always #(clk) begin
to:
always #(posedge clk) begin
I was able to run the posted code on EDA Playground Yosys; it produces latches.
After the change, latches are no longer produced.
i have written a simple counter code in verilog (xilix 14.2). The code is working properly in the isim but i am not able to dump it onto spartan6. When I try to do dump the code, a red light is ON , on the spartan 6 and the code is not dumped . Please let me know the changes i need to make.
module clk(int_clk,ext_pulse,reset,pos_count,neg_count);
input int_clk;
input ext_pulse;
input reset;
output reg [7:0] pos_count;
output reg [7:0] neg_count;
reg [7:0] count;
always#(posedge int_clk)
if(reset)
begin
pos_count<=0;
neg_count<=0;
end
else if(ext_pulse)
begin
neg_count<=neg_count+1;
pos_count<=0;
end
else
begin
pos_count<=pos_count+1;
neg_count<=0;
end
endmodule
Hey you haven't put a begin..end in the always block. Moreover you have used a synchronous reset which is generally not advisable. I made some changes to your code. By the way did you generate the bitstream?
module clk(int_clk,ext_pulse,reset,pos_count,neg_count);
input int_clk;
input ext_pulse;
input reset;
output reg [7:0] pos_count;
output reg [7:0] neg_count;
reg [7:0] count; //This reg is unused
always#(posedge int_clk or posedge reset) //I am assuming you want active high reset
begin
if(reset)
begin
pos_count<=0;
neg_count<=0;
end
else if(ext_pulse)
begin
neg_count<=neg_count+1;
pos_count<=0;
end
else
begin
pos_count<=pos_count+1;
neg_count<=0;
end
end
endmodule
Since version 10.4, start problem with initial block. Like this:
reg [31:0] init_ram[15:0];
initial begin
init_ram[0] = 32'h1234_5678;
init_ram[1] = 32'h8765_4321;
...
end
always_ff #(posedge clk)
init_ram[addr] <= data;
Or
module test(
input clk,
...
output reg a
);
initial a = 1'b1;
always #(posedge clk)
a <= ...;
ModelSim 10.4 error:
Error (suppressible): (vlog-7061) {path} Variable 'init_ram' driven in
an always_ff block, may not be driven by any other process
In older versions all works well.
You don't know which ModelSim parameter should I change to fix it?
One of the problems with the always_ff and always_comb constructs is that they are supposed to check the synthesizability during simulation, except that there is no standard for what is synthesizable. If the intent is that the initial blocks are just for simulation, then you will need to change the always_ff to always or change the initial block to use force/release instead.
One idea for a work around to your problem is to add a reset
signal and use it to initialize the value of a register.
Well, probably this
would be a good way to give an initial value to your flip-flops.
This should be something like:
reg [31:0] init_ram[15:0];
input reset;
always_ff #(posedge clk) begin
if (reset) begin
init_ram[0] <= 32'h1234_5678;
init_ram[1] <= 32'h8765_4321;
end
else begin
init_ram[addr] <= data;
Or this:
module test(
input clk,
input reset,
...
output reg a
);
always #(posedge clk) begin
if (reset) begin
a <= 1'b1;
end
else begin
a <= ...;
I am attempting to use an FPGA as a shift register to some LEDs with pwm, but ran into an error while trying to assign a reg containing the value shifted in to an output variable. When I upload it to the FPGA(i'm using the mojo by embedded micro), it does nothing. when I use the simulator, it reports that all of the output variables are never assigned and have the value of X, while all the other variables inside of the module work just fine. here is my code for the shifting module:
module shifting(
input clk,
input shiftingpin,//data to be shifted in
input rst,
output done,
output [3:0]data//pwm compare value output
);
reg [2: 0] ctr_d, ctr_q;
reg don;
reg [3:0]datas;
always #(*) begin
if(ctr_q == 3'b100) begin
ctr_d[2:0] = 3'b0;
don = 1'b1;
end else begin
ctr_d = ctr_q + 1'b1;
don = 1'b0;
end
end
always #(posedge clk) begin
datas[ctr_q] = shiftingpin;// assign value to the output
if (rst) begin
ctr_q <= 1'b0;
end else begin
ctr_q <= ctr_d;
end
end
assign data = datas;
assign done = don;
endmodule
done tells the containing module when to update and assign the value to pwm.
If I understood the question correctly you have a syntax error when trying to drive ports from within always blocks.
When declaring ports they are typically wire by default which can only be driven by ports or assign. Resulting in the code below
module shifting(
input clk,
input shiftingpin,
input rst,
output done,
output [3:0] data
);
reg don;
reg [3:0] datas;
assign done = don;
assign data = datas;
Solution
The solution is to define ports as reg, logic is preferred if you can support System Verilog.
logic will effectively switch between wire and reg as required to make refactoring code easier.
module shifting(
input clk,
input shiftingpin,
input rst,
output reg done,
output reg [3:0] data
);
always #(posedge clk) begin
data[ctr_q] <= shiftingpin; // <-- data port used directly
//...
NB: shift registers can be done with just
always #(posedge clk) begin
datas[3:0] <= {datas[2:0], shiftingpin};
I sometimes find it useful to use blocking assignments for "local variables" inside clocked always blocks. This can help cut down on repeated code.
To avoid accidentally using the same variable in a different always block (which can be non-deterministic for simulation), I'd like to give it local scope. Is there a nice synthesizable way of doing this?
Something like:
module sum3(
input clk,
input [7:0] in1,
input [7:0] in2,
input [7:0] in3,
output reg [7:0] result,
output reg [7:0] result_p1);
begin :sum
reg [7:0] sum_temp; // local variable
always #(posedge clk) begin
sum_temp = in1 + in2 + in3;
result <= sum_temp;
result_p1 <= sum_temp + 1;
end
end
endmodule
(ModelSim seems to be okay with this, but Synplify doesn't seem to like it.)
I'm not sure of the semantics in plain Verilog, but according to the SystemVerilog LRM section 6.21:
Variable declarations shall precede any statements within a procedural block.
Therefore the following is legal syntax in SystemVerilog:
module sum3(
input clk,
input [7:0] in1,
input [7:0] in2,
input [7:0] in3,
output reg [7:0] result,
output reg [7:0] result_p1);
always #(posedge clk) begin : sum
reg [7:0] sum_temp; // local variable (scope limited to process)
sum_temp = in1 + in2 + in3;
result <= sum_temp;
result_p1 <= sum_temp + 1;
end
endmodule
Note that I have moved the variable declaration sum_temp into the process, thereby limiting the scope and removing the need for the named sum block. This compiles on Modelsim and Riviera (example on EDA Playground).
If your tool doesn't support this syntax, raise a bug!
The standard sythesizable way is to use a continuous assignment with a wire:
module sum3(
input clk,
input [7:0] in1,
input [7:0] in2,
input [7:0] in3,
output reg [7:0] result,
output reg [7:0] result_p1);
wire [7:0] sum_temp = in1 + in2 + in3;
always #(posedge clk) begin
result <= sum_temp;
result_p1 <= sum_temp + 1;
end
endmodule
Despite the common guideline, using blocking assignments inside clocked always blocks is ok, and sometime as you mentioned useful. See here: https://stackoverflow.com/a/4774450/1383356
Some tools however, may not support local variables defined inside a begin-end block.
Alternatively, you can try putting some or all of the the body of the always block in a task:
task SUM_TASK();
reg [7:0] sum_temp; // local variable
sum_temp = in1 + in2 + in3;
result <= sum_temp;
result_p1 <= sum_temp + 1;
endtask
always #(posedge clk) begin
SUM_TASK();
end
Verilog tasks can have access to global variables as well as local ones. Also, they can include non-blocking assignments.