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.
Related
I'm working on an assignment where I need to create a jackpot game. But I'm having trouble driving the register that controls the win condition and I can't figure out why. As far as I know, the always#(posedge zero) block should be able to run whenever I flip my switch to the up position. Then, so long as the right hot register value happens in the same instant, it should be able to set the win register. However, this is not the case. Nothing seems to happen, and I'm not sure why. I've tried running the always block from different sensitivities but nothing seems to effect it. Maybe I'm just mis-understanding how always blocks work or how the switch works, any help is appreciated.
module jackpot(
input [3:0] SWITCHES,
output [3:0] LEDS,
input CLOCK,
input reset
);
reg [3:0] hot = 4'd1;
reg win;
wire clk, zero, one, two, three;
Clock_Div CDD (CLOCK, clk);
assign LEDS[2:0] = hot[2:0];
assign zero = SWITCHES[0];
assign one = SWITCHES[1];
assign two = SWITCHES[2];
assign three = SWITCHES[3];
assign LEDS[3] = zero;
initial begin
win <= 1'b0;
end
always #(posedge zero) begin
if(hot[0] && zero)
win <= 1'd1;
end
always #(posedge clk) begin
if (reset == 1'b1) begin
hot <= 4'd1;
win <= 1'd0;
end
else if(win == 1'b1) begin
hot <= 4'b1111;
end
else begin
if(hot == 4'b1000) begin
hot <= 4'b0001;
end
else begin
hot <= hot << 1;
end
end
end
endmodule
Thanks to Serge's comment I've realized the issue. Like his comment says, driving a register from multiple always blocks throws a critical warning, and Vivado picks one of the blocks to use over the other. Once I made sure to isolate a reg to an always block the behavior started to look like I expected. This must just be something that got glossed over during class, or maybe I wasn't paying attention enough.
I am trying to implement the I2S Transmitter in verilog. The datasheet for it is at: https://www.sparkfun.com/datasheets/BreakoutBoards/I2SBUS.pdf
I wrote the code, but my SD line is delayed 1 clock cycle when i test it.
Can someone check my implementation?
module Transmiter(
input signed [23:0] DLeft, input signed [23:0] DRight, input WS, input CLK,
output reg SD
);
wire PL;
reg Q1,Q2;
reg [23:0] shift_reg;
reg [23:0] Tdata;
assign PL = Q1^Q2;
always #(posedge CLK)
begin
Q1 <= WS;
Q2 <= Q1;
end
always #( Q1) begin
if (Q1)
begin
Tdata <= DRight;
end
else
begin
Tdata <= DLeft;
end
end
always #(negedge CLK)
begin
if(PL)
begin
shift_reg <= Tdata;
end
else begin
SD <= shift_reg[23];
shift_reg <= {shift_reg[22:0],1'b0};
end
end
endmodule
EDIT: here is a image of waveform image
TEST BENCH CODE:
module Transmitter_tb(
);
reg CLK, WS;
reg [23:0] dataL;
reg [23:0] dataR;
wire SDout;
Transmiter UT(dataL, dataR, WS, CLK, SDout);
initial begin
dataL = 24'hF0F0FF; #2;
dataR = 24'h0000F0; #2;
end
always begin
CLK=0; #20;
CLK=1; #20;
end;
always begin
WS=0; #1000;
WS=1; #1000;
end;
endmodule
Your negedge block contains an if-else construct and will only ever compute one or the other on a single clock edge. SD will therefore not change value when PL is high.
Furthermore you are using non-blocking assignments(<=) in your code. This roughly means that changes won't be evaluated until the end of the always block. So even if SD <= shift_reg[23] after shift_reg <= Tdata it will not take on the new value in shift_reg[23] but use the previous value. If you want SD to change immediately when shift_reg[23] changes you need to do this combinatorically.
This should work:
always #(negedge CLK)
begin
if(PL)
begin
shift_reg <= Tdata;
end
else
shift_reg <= {shift_reg[22:0],1'b0};
end
assign SD = shift_reg[23];
Working example: https://www.edaplayground.com/x/4bPv
On a side note I am still not convinced that DRight and DLeft are in fact constants, I can see that they are in your TB but it doesn't make sense that the data for your I2S is constant. Your current construct will probably generate a latch(instead of a MUX), and we generally don't want those in our design.
You should clean up your use of blocking versus non-blocking statements:
Always use non-blocking assigments, meaning "<=", in clocked statements.
Always use blocking assigments, meaning "=", in combinational (non-clocked) statements.
This is a industry-wide recommendation, not a personal opinion. You can find this recommendation many places, see for instance:
http://web.mit.edu/6.111/www/f2007/handouts/L06.pdf
The sensitivtity list being incomplete (as pointed out by #Hida) may also cause issues.
Try to correct these two things, and see if it starts working more as expected.
Also note that you are using Q1 (among other signals) to generate your PL signal. If the WS input is not synchronous to your local clock (as I assume it is not), you need to put one more flop (i.e. two in series) before starting to use the output, to avoid metastability-issues. But you won't see this in an RTL simulation.
I write two module by Verilog.
first module is 4 bit counter:
module ASYNCHRONOUS_COUNTER( clk, res, out);
input clk;
input res;
output[3:0] out;
reg[3:0] out;
wire clk;
wire res;
initial
out = 4'b0;
always #(negedge clk or posedge res)
if(res) begin
out[0] <= 1'b0;
end else begin
out[0] <= ~out[0];
end
always #(negedge out[0] or posedge res)
if(res) begin
out[1] <= 1'b0;
end else begin
out[1] <= ~out[1];
end
always #(negedge out[1] or posedge res)
if(res) begin
out[2] <= 1'b0;
end else begin
out[2] <= ~out[2];
end
always #(negedge out[2] or posedge res)
if(res) begin
out[3] <= 1'b0;
end else begin
out[3] <= ~out[3];
end
endmodule
second module use first module :
module tripleInputClk(clk,tripledClk);
input clk;
wire clk;
output tripledClk;
wire tripledClk;
wire res;
wire[3:0] out;
reg temp;
initial
temp <= 1'b0;
//assign out = 3'b0;
assign res = ~out[3] & ~out[2] & out[1] & out[0];
ASYNCHRONOUS_COUNTER myCounter(
.clk(clk),
.res(res),
.out(out)
);
always #(posedge res)
begin
temp <= ~temp;
end
assign tripledClk = temp;
endmodule
first module works correctly, but when I compiled it and made it's wave form ,I understood that outputs of first module doesn't pass correctly and value of 'res' always equal '0'.
Here, res is declared as wire in your tripleInputClk module.
I simulated your code and observed that the signal tripledClk goes HIGH after three clock pulses. Thereby, suspecting that a posedge of res signal must occur. But, res is in continuous assignment statement. As soon as res becomes HIGH, the reg out changes (#(posedge res)) and again makes res LOW; all this in a single time stamp. So you are not able to view transition of res signal.
Also, after that, the tripledClk signal does not toggle as expected, I guess.
One way out is to declare res as reg in tripleInputClk module and remove it from continuous assignment. Instead, make it work on the edge of clock signal only.
This is because, reg is used to store values. Here, there is a circular dependency of res on out and vice-versa (i.e. out is also dependent on res). Henceforth, it creates some sort of confusing conditions(I would not term it as a race around condition exactly).
When you'll proceed to synthesis (even though initial block is not synthesizable here..!), the tool may issue this circular dependency warning. And, proper hardware may not be formed.
I've modified your code and provided a testbench to it. The only change is the one that I described here, i.e. res signal. Kindly go through the link below. The tripledClk is now also working fine as (3*frequency_of_clk).
Link to EDAPlayground.
This is something that I think should be doable, but I am failing at how to do it in the HDL world. Currently I have a design I inherited that is summing a multidimensional array, but we have to pre-write the addition block because one of the dimensions is a synthesize-time option, and we cater the addition to that.
If I have something like reg tap_out[src][dst][tap], where src and dst is set to 4 and tap can be between 0 and 15 (16 possibilities), I want to be able to assign output[dst] be the sum of all the tap_out for that particular dst.
Right now our summation block takes all the combinations of tap_out for each src and tap and sums them in pairs for each dst:
tap_out[0][dst][0]
tap_out[1][dst][0]
tap_out[2][dst][0]
tap_out[3][dst][0]
tap_out[0][dst][1]
....
tap_out[3][dst][15]
Is there a way to do this better in Verilog? In C I would use some for-loops, but that doesn't seem possible here.
for-loops work perfectly fine in this situation
integer src_idx, tap_idx;
always #* begin
sum = 0;
for (scr_idx=0; src_idx<4; src_idx=scr_idx+1) begin
for (tap_idx=0; tap_idx<16; tap_idx=tap_idx+1) begin
sum = sum + tap_out[src_idx][dst][tap_idx];
end
end
end
It does unroll into a large combinational logic during synthesis and the results should be the same adding up the bits line by line.
Propagation delay from a large summing logic could have a timing issue. A good synthesizer should find the optimum timing/area when told the clocking constraint. If logic is too complex for the synthesizer, then add your own partial sum logic that can run in parallel
reg [`WIDHT-1:0] /*keep*/ partial_sum [3:0]; // tell synthesis to preserve these nets
integer src_idx, tap_idx;
always #* begin
sum = 0;
for (scr_idx=0; src_idx<4; src_idx=scr_idx+1) begin
partial_sum[scr_idx] = 0;
// partial sums are independent of each other so the can run in parallel
for (tap_idx=0; tap_idx<16; tap_idx=tap_idx+1) begin
partial_sum[scr_idx] = partial_sum[scr_idx] + tap_out[src_idx][dst][tap_idx];
end
sum = sum + partial_sum[scr_idx]; // sum the partial sums
end
end
If timing is still an issue, then you have must treat the logic as multi-cycle and sample the value some clock cycles after the input changed.
In RTL (the level of abstraction you are likely modelling with your HDL), you have to balance parallelism with time. By doing things in parallel, you save time (typically) but the logic takes up a lot of space. Conversely, you can make the adds completely serial (do one add at one time) and store the results in a register (it sounds like you want to accumulate the total sum, so I will explain that).
It sounds like the fully parallel is not practical for your uses (if it is and you want to rewrite it, look up generate statements). So, you'll need to create a small FSM and accumulate the sums into a register. Here's a basic example, which sums an array of 16-bit numbers (assume they are set somewhere else):
reg [15:0] arr[0:9]; // numbers
reg [31:0] result; // accumulated sum
reg load_result; // load signal for register containing result
reg clk, rst_L; // These are the clock and reset signals (reset asserted low)
/* This is a register for storing the result */
always #(posedge clk, negedge rst_L) begin
if (~rst_L) begin
result <= 32'd0;
end
else begin
if (load_result) begin
result <= next_result;
end
end
end
/* A counter for knowing which element of the array we are adding
reg [3:0] counter, next_counter;
reg load_counter;
always #(posedge clk, negedge rst_L) begin
if (~rst_L) begin
counter <= 4'd0;
end
else begin
if (load_counter) begin
counter <= counter + 4'd1;
end
end
end
/* Perform the addition */
assign next_result = result + arr[counter];
/* Define the state machine states and state variable */
localparam IDLE = 2'd0;
localparam ADDING = 2'd1;
localparam DONE = 2'd2;
reg [1:0] state, next_state;
/* A register for holding the current state */
always #(posedge clk, negedge rst_L) begin
if (~rst_L) begin
state <= IDLE;
end
else begin
state <= next_state;
end
end
/* The next state and output logic, this will control the addition */
always #(*) begin
/* Defaults */
next_state = IDLE;
load_result = 1'b0;
load_counter = 1'b0;
case (state)
IDLE: begin
next_state = ADDING; // Start adding now (right away)
end
ADDING: begin
load_result = 1'b1; // Load in the result
if (counter == 3'd9) begin // If we're on the last element, stop incrementing counter, we are done
load_counter = 1'b0;
next_state = DONE;
end
else begin // Otherwise, keep adding
load_counter = 1'b1;
next_state = ADDING;
end
end
DONE: begin // finished adding, result is in result!
next_state = DONE;
end
endcase
end
There are lots of resources on the web explaining FSMs if you are having trouble with the concept, but they can be used to implement your basic C-style for loop.
I am implementing a simple counter which is counting the number of time push buttons are pressed. I wrote the following code:
module lock(
anodes,cathodes,leds,
sw,btns,clk );
//input declarations
input[7:0] sw;
input[3:0]btns;
input clk;
always #(curbtns)
begin
if( prevbtns!=0 && curbtns==0)
begin
counter_next = counter + 5'b00001;
end
else
counter_next = counter;
prevbtns = curbtns;
end
always #(btns or sw)
begin
case(btns)
4'b0001:curbtns=4'b0001;
4'b0010:curbtns=4'b0010;
4'b0100:curbtns=4'b0100;
4'b1000:curbtns=4'b1000;
4'b0000:curbtns=4'b0000;
default:curbtns = prevbtns;
endcase
end
always #(posedge clk)
begin
counter <=counter_next;
create_slow_clock(clk,slow_clock);
end
endmodule
When I simulate the above code in icraus verilog it seems to be working but on actual FPGA my counter is not changing. Is there any problem in the logic of incrementing the variable.
Updated code(Working)
always #(curbtns or prevbtns or counter)
begin
if( prevbtns!=0 && curbtns==0)
begin
counter_next = counter + 5'b00001;
end
else
counter_next = counter;
end
always #(posedge clk)
begin
counter <=counter_next;
prevbtns <=curbtns;
create_slow_clock(clk,slow_clock);
end
You look to be missing some signals in your sensitivity lists for the combinational always blocks.
For your code to be properly synthesizable, a combinational block must be sensitive to every input signal.
The first always block always #(curbtns) needs to be sensitive to prevbtns, curbtns, and counter.
The second block always #(btns or sw) also needs to be sensitive to prevbtns (I don't see sw used in this block anyway, should get rid of it).
I recommend changing both blocks to always #*, so that the lists may be automatically inferred, and it's not a fragile point of breakage if you change the logic and forget to change the list.