I've got an initial block which calls a task named power_task as below
initial begin
#10;
power_task;
end
Inside the power task, I've two signals power_a and power_b. Initially, power_a goes low and after a certain skew, power_b goes low. As long as both the signals are low, I need to check the output q. Output q should be low during the time window where power_a and power_b signals are low. Since there are no other signals like a clock, I'm not sure how to continuously monitor q. I've written something like below
task power_task;
#1;
power_a=0;
#5; //skew
power_b=0;
if (power_a==0 && power_b==0 && q==0) begin
$display("pass");
end
#50;
power_b=1;
#5;
power_a=1;
end
endtask
In the above task, the if statements check the value of q only after both signals are low and not during the entire 50 ns time window. Can someone please help?
You can use a wait statement in a fork block
task power_task;
begin
reg fail;
fail = 0;
#1 power_a=0;
#5 power_b=0; //skew
fork : check_q
wait (q) fail = 1;
#50 begin
if (fail)
$display("fail");
else
$display("pass");
disable check_q;
end
join
power_b=1;
#5 power_a=1;
end
endtask
Not exactly sure why you need to check that power_a/b are still 0 unless there is some other code that could change it.
Use an always block outside of the task, a control signal (check_en) and a flag variable (pass):
reg pass = 1;
reg check_en = 0;
always #(check_en, q) begin
if (check_en && q) begin
$display("fail");
pass = 0;
end
end
initial begin
#10;
power_task();
if (pass) $display("pass");
end
task power_task;
#1;
power_a=0;
#5; //skew
power_b=0;
check_en = 1;
#50;
check_en = 0;
power_b=1;
#5;
power_a=1;
endtask
The always block will continuously monitor the q signal for any changes when enabled.
Related
New to Verilog, Basys3 board and Vivid 2021.2.
Trying to implement a typical stopwatch with Stop/Start and Lap/Reset buttons.
A divider produces 1kHz and 100Hz clock from the board clock, 100Hz is for button debounce (and seven segment display multiplexing, next todo), the 1kHz drives a 20 bit 5 x 4 bit BCD counter, the low 16 bits of which drive a latch to freeze the display, the latch drives the 16 on board LEDs.
I've test 'wired' this up and the modules perform as expected. It's only when I add the FSM I run into trouble.
The FSM is simple, the two buttons determine the state changes and the state sets three outputs to control the counter.
The state module as been through many versions, tried using buttons in the sensitivity list, tried with button edges and levels, tried *, tried blocking and non-blocking assignments, can't get it right. The current error is:
[Synth 8-3332] Sequential element (state/transfer_reg) is unused and will be removed from module stopwatch.
The error changes but it's always Synth 8-3332 removing something, even curr_state or next_state.
The RTL synthesis schematic shows exactly what I expect, later schematics show the two buttons, 16 LEDs and nothing in between.
I'm lost at this stage, have I missed something fundamental?
`timescale 1ns / 1ps
////////////////////////////////////////////////////////////////////////////////
//
// Create Date: 02/02/2022 0800
//
// Module Name: state
// Project Name: Stop Watch
// Target Devices: BASYS 3
//
// state machine
//
// inputs:
// start-stop button via debounce (both edg and level are available)
// lap-reset buttonvia debounce (both edg and level are available)
//
// outputs:
// control 4 x 4 bit BCD counters and output latch
// clear state
// enabvble couter to count
//. transfer counter value to latch
//
////////////////////////////////////////////////////////////////////////////////
module state (
input clk,
input lap_reset,
input start_stop,
output reg clear,
output reg enable,
output reg transfer
);
// state encodings
localparam
RESET_0 = 3'd0,
STOPPED_1 = 3'd1,
RUNNING_2 = 3'd2,
PRELAP_3 = 3'd3,
LAP_4 = 3'd4;
// state reg
reg[2:0] curr_state;
reg[2:0] next_state;
// setup
initial
begin
curr_state <= RESET_0;
next_state <= RESET_0;
enable <= 0;
clear <= 0;
transfer <= 0;
end
// sync state transitons to clk
// always # (posedge clk)
// begin
// curr_state <= next_state;
// end
// state machine
always # (posedge clk)
begin
curr_state <= next_state;
case (curr_state)
RESET_0:
begin
// init, stop counter, clear counter
// transfer count to latch
enable <= 0;
clear <= 1;
transfer <= 1;
next_state <= STOPPED_1;
end
STOPPED_1:
begin
// stop counter, clear counter
enable <= 0;
clear <= 0;
transfer <= 0;
if (start_stop)
next_state <= STOPPED_1;
else if (lap_reset)
next_state <= RESET_0;
else
next_state <= curr_state;
end
RUNNING_2:
begin
// start or continue counting
// transfer count to latch
enable <= 1;
clear <= 0;
transfer <= 1;
if (start_stop)
next_state <= STOPPED_1;
else if (lap_reset)
next_state <= PRELAP_3;
else
next_state <= curr_state;
end
PRELAP_3:
begin
// start or continue counting
// don't update latch
enable <= 1;
clear <= 0;
transfer <= 0;
next_state <= LAP_4;
end
LAP_4:
begin
// continue counting
// transfer counter to latch
enable <= 1;
clear <= 0;
transfer <= 1;
if (start_stop)
next_state <= RUNNING_2;
else if (lap_reset)
next_state <= PRELAP_3;
else
next_state <= curr_state;
end
default:
begin
enable <= 0;
clear <= 0;
transfer <= 0;
next_state <= RESET_0;
end
endcase
end
endmodule
Getting somewhere at last, thankyou all.
After correcting a logical error and a couple of constants 0'b0 which make little sense (the compiler didn't complain about them) and doing suggested fixes my stopwatch works.
The SM structure is the 3 blocks, sync transitions, next state 'gotos' and state actions. I started with the suggested always # (*) but had to change to a posedge clk for it to work, not sure why.
Got rid of the inferred latches and now understand why they come about.
About generating a reset signal, I assume the Artix chip has one but it doesn't get a mention in the supplied xdc file, I was trying to simulate a reset held low (active) then going high a short time later, determined by a clock divider - which should have a reset... Also read Xilinx WP272 which tells a different story.
Thanks again.
Just from www.javatpoint.com/verilog-initial-block:
"An initial block is not synthesizable and cannot be converted into a
hardware schematic with digital elements. The initial blocks do not
have more purpose than to be used in simulations. These blocks are
primarily used to initialize variables and drive design ports with
specific values."
I am not sure now about the code for that FPGA, but in common ASICs I would remove the "initial" code section, which you use to implement the reset behaviour and add an actual reset section in the always#.
always#(posedge clk)
begin
if (rst) begin
// do the reset
curr_state <= RESET_0;
next_state <= RESET_0;
enable <= 0;
clear <= 0;
transfer <= 0;
end else begin
// the rest
end
end
EDITED:
Never leave a signal without a default value, as it will infer latches instead of flip-flops, which create problems when inferring sequential logic (of course latches are useful in some scenarios).
When one wants to build a finite state machine (FSM) there are two common approaches: Mealy and Moore. I will explain how the sequential logic should be implemented with a Moore FSM:
A synchronous always# block to write the state: cur_state <= next state.
A combinational block to generate next_state value based on cur_state and inputs.
A combinational block to generate outputs based on the state.
always#(posedge clk, rst)
begin
if (rst = '1') begin
cur_state <= State_0;
end else begin
cur_state <= next_state;
end
end
always_comb(cur_state, my_inputA)
begin
if (cur_state = State_0) begin
if(my_inputA)
next_state = State_1;
else
next_state = Stage_0;
end else if (cur_state = State_1) begin
next_state = State_2;
end
end
always_comb(cur_state)
begin
if (cur_state = State_0) begin
my_outputA = '1';
end else if (cur_state = State_1) begin
my_outputA = '0';
end else if (cur_state = State_2) begin
my_outputA = '1';
end
end
I have a simple module that uses a few different states. The Problem I am encountering is say if I want to stay at the same state for multiple clock cycles.
In this case, my current state is synchronous and updates on clock cycle. It executes that always block which goes from state 0 -> state 1. Then once pstate reaches state 1, I attempt to have it wait to reach the next state. The reason for this is to collect data off of the data_int input. I don't care what the data is, but I need to read off it for 2 clock cycles.
I believe this doesn't work however because in the first case, I set the next state to the same value as it previously was, so it is unable to trigger. The reason I don't think I could just also add 'data_int' to the trigger list, is because its possible it remains the same value for a clock cycle and thus the always block wouldn't trigger.
I'm wondering if there is another way to do this, I guess essentially I need the always block to retrigger on clock edge as well..
module TestModule(
input clk, rst, data_int);
reg [2:0] pstate = 0;
reg [2:0] nstate = 0;
ref [2:0] count = 0;
always#(pstate) begin
//only fires when pstate is assigned to a different value?
//would I make a internal clock to constantly have this always run?
if(pstate == 0) begin
nstate <= 1;
end
else if(pstate == 1) begin
//stay at this state for multiple clock cycles
//collect data off of data_int
count = count + 1;
if(count > 2) begin
nstate <= 2;
end else begin
nstate <= 1;
end
end
end
always#(posedge clk, posedge rst) begin
if(rst) begin
pstate <= 0;
end
else begin
pstate <= nstate;
end
end
pay attention to the usage of = and <=.
count is never reset, if you want to enter pstate == 3'h1 state multiple times.
use always#(*) to save your life. synthesis tools will respect the logic inside the always block, but simulation tools won't, which will lead to simulation mismatches.
The following code is based on my understanding of your question.
reg [2:0] pstate;
reg [2:0] nstate;
reg count; // 1-bit 'count' is enough to count 2 cycles
always#(posedge clk or posedge rst)begin
if(rst)begin
pstate <= 3'h0;
end
else begin
pstate <= nstate;
end
end
always#(*)begin
case(pstate)
3'h0: nstate = 3'h1;
3'h1:begin // lasts 2 cycles
if(count)begin
nstate = 3'h2;
end
else begin
nstate = 3'h1;
end
3'h2: (....)
default: (....)
end
endcase
end
always#(posedge clk or posedge rst)begin // 'count' logic
if(rst)begin
count <= 1'h0;
end
else if((pstate == 3'h1) & count)begin // this branch is needed if you don't
// count to the max. value of 'count'
count <= 1'b0;
end
else if(pstate == 3'h1)begin
count <= ~count; // if 'count' is multi-bit, use 'count + 1'
end
end
All my testbench is trying to do is verify whether or not the LED signal went high, but on Modelsim when I try and simulate it, the clock doesn't even start, but it initializes to zero. I can also step through my design so I don't appear to have an infinite loop or anything like that. Is there anything obviously wrong here, especially with regards to clock initialization and generation?
`timescale 1ns/100ps
module fir_filter_tb();
reg clk, reset_n;
reg led;
top top_level (
.clk(clk),
.reset_n(reset_n),
.led(led)
);
initial
begin
$display($time, " << Starting the Simulation >>");
clk = 1'b0; // at time 0
reset_n = 0; // reset is active
led = 0; // output is low
#10 reset_n = 1'b1; // at time 20 release reset
end
always #10 clk = ~clk;
always
begin
if (led == 1'b1) begin
$write($time, "Filter Successful");
end else begin
$write($time, "bleh you suck");
end
end
endmodule : fir_filter_tb
The problem is with the always block with led in it. Since there is no timing control, it prevents time from advancing (time remains stuck at 0). It creates an infinite zero-time loop.
One way to fix it is to use:
always #*
This will only trigger the block when led changes.
I was following a tutorial on SPI master in Verilog. I've been debugging this for about three hours now and cannot get it to work.
I've been able to break down the issue into a minimum representative issue. Here are the specifications:
We have two states, IDLE and COUNTING. Then, on the clock positive edge, we check:
If the state is IDLE, then the counter register is set to 0. If while in this state the dataReady pin is high, then the state is set to COUNTING and the counter is set to all 1s.
If the state is COUNTING, the state remains COUNTING as long as counter is not zero. Otherwise, the state is returned to IDLE.
Then, we count on the negative edge:
On the negative edge of clock if state is COUNTING, then decrement counter.
Here's the code I came up with to fit this specification:
// look in pins.pcf for all the pin names on the TinyFPGA BX board
module top (
input CLK, // 16MHz clock
input PIN_14,
output LED, // User/boot LED next to power LED
output USBPU // USB pull-up resistor
);
// drive USB pull-up resistor to '0' to disable USB
assign USBPU = 0;
reg [23:0] clockDivider;
wire clock;
always #(posedge CLK)
clockDivider <= clockDivider + 1;
assign clock = clockDivider[23];
wire dataReady;
assign dataReady = PIN_14;
parameter IDLE = 0, COUNTING = 1;
reg state = IDLE;
reg [3:0] counter;
always #(posedge clock) begin
case (state)
IDLE: begin
if (dataReady)
state <= COUNTING;
end
COUNTING: begin
if (counter == 0)
state <= IDLE;
end
endcase
end
always #(negedge clock) begin
if (state == COUNTING)
counter <= counter - 1;
end
always #(state) begin
case (state)
IDLE:
counter <= 0;
COUNTING:
counter <= counter;
endcase
end
assign LED = counter != 0;
endmodule
With this, we get the error:
ERROR: multiple drivers on net 'LED' (LED_SB_DFFNE_Q.Q and LED_SB_DFFNE_Q_1.Q)
Why? There is literally only one assign statement on the LED.
First of all it would not be easy to come up with a synthesizable model in such a case. But, you do not need any negedge logic to implement your model. Also you made several mistakes and violated many commonly accepted practices.
Now about some problems in your code.
By using non-blocking assignment in the clock line you created race condition in the simulation which will probably cause incorrect simulation results:
always #(posedge CLK)
clockDivider <= clockDivider + 1; // <<< this is a red flag!
assign clock = clockDivider[23];
...
always #(posedge clk)
you incorrectly used nbas in your always block
always(#state)
... counter <= conunter-1; // <<< this is a red flag again!
your state machine has no reset. Statements like reg state = IDLE; will only work in simulation and in some fpgas. It is not synthesizable in general. I suggest that you do not use it but provide a reset signal instead.
Saying that, i am not aware of any methodology which would use positive and negative edges in such a case. So, you should not. All your implementation can be done under the posedge, something like the following. However
always #(posedge clock) begin
if (reset) begin // i suggest that you use reset in some form.
state <= IDLE;
counter <= 0;
end
else begin
case (state)
IDLE: begin
if (dataReady) begin
state <= COUNTING;
counter <= counter - 1;
end
end
COUNTING: begin
if (counter == 0)
state <= IDLE;
else
counter <= counter - 1;
end
endcase
end
end
I hope i did it right, did not test.
Now you do not need the other two always blocks at all.
I'm trying to learn verilog having done C++ before. As a learning exercise I'm trying to flash turn an LED on after seeing 10 button presses. I also have an additional reset button that starts the 10 count again. What ever I try I can't get it to compile. Can anyone point me in the right direction?
My code is:
module led_counter (button, nreset, led);
input button, nreset;
output led;
reg counter[4:0]; // to hold the current count
always # (negedge nreset) begin
counter <= 0; // Just reset counter
end
always # (negedge button) begin
if (counter == 10) begin // see if the button has been pressed 10 times
led_state <= 1; // turn the led on
end
else begin
led_state <= 0; // the led is off
counter <= counter + 1;
end
end
assign led = led_state;
endmodule
led_state is not declared, it should be a reg.
To have something more concise I would also regroup the two processes into one. It would make it look like a synchronous process with asynchronous reset, i.e. triggered by a clock and reseted on falling edge of a reset.
always # (posedge button or negedge nreset) begin
if(~nreset) //reset counter when nreset is low
counter <= 0;
else begin //do something on posedge of button
//Do something//
end //end process
It would also be more likely to be synthesized.