What I'm designing is a moore machine that gives particular color for each state.
Here's a part of my code.
always #(*) begin
case (state)
S0 : led = 6'b111111;
S1 : led = 6'b010100; // have to blink //
S2 : led = 6'b100010;
S3 : led = 6'b110110;
default : led_output = 6'b000000;
endcase
end
endmodule
Before the code shown above, there are codes about assigning state corresponding to the input.
The code shown above is to determine the output value of moore machine. (Therefore the condition is *)
What I left is to assign led output value for each state.
However the condition for S1 is not only particular color but it has to 'blink' for period of 1s.
I already googled for 'blink LED' verilog code but they were little bit different from my situation.
I have no idea of coding block that is needed.
Can you give me some advice or answer for what to add to make S1 to blink?
To make it blink, you need to distinguish 2 states. So create a 1-bit signal, say sel, which toggles in S1 state, and its toggle speed as well as its duty meet your requirement in 'blink' for period of 1s. This is basically implemented with the help of a counter.
reg [3:0] cnt; // assume 4-bit long
reg sel;
// counter to determine the HIGH / LOW time of sel.
always#(posedge clk or negedge resetn)begin
if(!resetn)begin
cnt <= 4'h0;
end
// since you can exit S1 state at any time using push_button,
// make sure cnt is always ZERO when entering S1 state next time.
// also to save power when using clock gating, because this statement
// is only active for 1 cycle.
else if((state == S1) & ((push_button == 2'b01) | (push_button == 2'b10)))begin // S1 exit condition
cnt <= 4'h0;
end
else if(state == S1)begin
// sel HIGH lasts <HIGH_MAX_VAL>+1 cycles
// sel LOW lasts <LOW_MAX_VAL>+1 cycles
if(cnt == (sel ? <HIGH_MAX_VAL> : <LOW_MAX_VAL>))begin
cnt <= 4'h0;
end
else begin
cnt <= cnt + 4'h1;
end
end
end
always#(posedge clk or negedge resetn)begin
if(!resetn)begin
sel <= 1'h0;
end
else if((state == S1) & ((push_button == 2'b01) | (push_button == 2'b10)))begin
sel <= 1'h0;
end
else if(state == S1)begin
if(cnt == (sel ? <HIGH_MAX_VAL> : <LOW_MAX_VAL>))begin
sel <= ~sel;
end
end
end
Use sel to select between 2 led values.
always#(*)begin
case(state)
....
S1 : led = sel ? 6'b010100 : <ANOTHER_VALUE>;
....
endcase
end
Related
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
I want to write a Serial to Parallel conversion in Verilog, and I can't realize what is wrong with my code. It doesn't synthesize, and not even the ISE shows what the problem is. Can anyone help me?
I guess the problem is around the second always block. The part:
if (STATE == TRANSMIT)
PAR_OUT[COUNTER] = SER_IN;
seems wrong to me, but I can't understand what to change or test.
module SIPO(
input SER_IN,
input RST,
input CLK,
input LOAD,
output reg READY,
output reg [7:0] PAR_OUT
);
parameter IDLE = 2'b00, START = 2'b01, TRANSMIT = 2'b10, STOP = 2'b11;
reg [1:0] STATE;
reg [2:0] COUNTER;
always # ( posedge CLK or negedge RST)
if (~RST)
begin
STATE <= IDLE;
READY <= 1;
COUNTER <= 0;
end
else
begin
if (STATE == IDLE)
begin
READY <= 1;
COUNTER <= 0;
if (LOAD)
begin
STATE <= START;
end
else
STATE <= IDLE;
end
else
if (STATE == START)
STATE <= TRANSMIT;
else
if (STATE == TRANSMIT)
begin
COUNTER <= COUNTER + 1;
if (COUNTER == 7)
STATE <= STOP;
end
else
begin
STATE <= IDLE;
READY <= 1;
end
end
always #( * )
begin
if (STATE == IDLE)
PAR_OUT = 1;
else
if (STATE == START)
PAR_OUT = 0;
else
if (STATE == TRANSMIT)
PAR_OUT[COUNTER] = SER_IN;
else
PAR_OUT = 1;
end
endmodule
I think your suspicion might be correct regarding PAR_OUT[COUNTER]. When I synthesize your code on edaplayground with Yosys, it infers latches for PAR_OUT, which you likely do not want.
PAR_OUT is 8 bits wide, but you only assign 1 of the 8 bits at a time in the TRANSMIT state, which means the other 7 bits retain their state. For example, if COUNTER=3, then only PAR_OUT[3] is assigned.
I recoded your combo logic, simplifying it with a case statement to make the issue more evident (it should be functionally equivalent to your if/else code):
always #* begin
case (STATE)
TRANSMIT: PAR_OUT[COUNTER] = SER_IN; // Assign to only 1 bit <---
START : PAR_OUT = 8'h00; // Assign to all 8 bits
default : PAR_OUT = 8'h01; // Assign to all 8 bits
endcase
end
If you can afford one cycle of latency, you could use sequential logic for PAR_OUT, such as a shift register.
I am creating a vending machine in verilog. There is one button on the FPGA board to act as the coin inserter, every time the button is pushed it will add a 'quarter' to the total amount the user can spend, and display the total on the left and right seven segment displays.
Ex.
1st button push : 25 cents
2nd button push : 50 cents
3rd button push : 75 cents
4th button push : $1.00 (10 on the seven segment display).
Wont increment after the 4th button press.
input quarterIn,
output reg [4:0] state,
output reg [4:0] next_state,
output reg totalChange,
output reg [7:0] RSSD,
output reg [7:0] LSSD
);
/***coin implementation***/
parameter
c0 = 0,
c1 = 1,
c2 = 2,
c3 = 3,
c4 = 4;
always #(posedge clock)
begin
state = next_state;
end
always # (quarterIn or totalChange)
begin
case(totalChange)
0: begin if(quarterIn == 1) totalChange = 1; state = c1; end
1: begin if(quarterIn == 1) totalChange = 2; state = c2; end
2: begin if(quarterIn == 1) totalChange = 3; state = c3; end
3: begin if(quarterIn == 1) totalChange = 4; state = c4; end
4: begin if(quarterIn == 1) totalChange = 4; state = c4; end
endcase
end
I am getting stuck on how to keep count of the button clicks. I can see the first value on the seven segment display, but am unsure as to how to increment the total coins. I couldn't find any sort of information on this from trying to research on my own.
From what I understood, you need a saturating counter to keep track of the button presses.
In order to count, you need a clock in the system:
input clock;
And you'll need a reset signal to initialize the counter to a known value, zero in this case:
input reset;
And the counter (equivalent to the state variable, let me just call it num_push):
reg [2:0] num_push;
The saturating counter can be specified this way:
always #(posedge clock) begin
if (reset) begin // Active high, synchronous reset
num_push <= 3'b0;
end else begin
if (quarterIn == 1'b1 && num_push != 3'b100) begin
num_push <= num_push + 3'b1;
end
end
end
This will synthesize to a counter with a count-enable on your FPGA and the enable will be equal to quarterIn == 1'b1 && num_push != 3'b100. You could press reset to start over.
Now, there are a few issues to be addressed before we put this on an FPGA. First of all, quarterIn needs to be synced for metastability:
reg quarterIn_f;
reg quarterIn_sync;
always #(posedge clock) begin
quarterIn_f <= quarterIn;
quarterIn_sync <= quarterIn_f;
end
We should use only quarterIn_sync in the design and never quarterIn directly. You should do the same with for the reset signal as well.
Second, the signals that come from the keys need to be debounced. Debouncing is a whole topic in itself, so I'll skip it for the time being :(
Another thing is that the clock needs to be pulled from the onboard clock generator circuitry and this clock will be running at a few MHz. A typical button-press lasts for about 500ms and this means our counter will sample a few hundred thousand keypresses in a single press. To avoid this, we should count the edge of quarterIn_sync, and not the level:
wire quarterIn_edge;
req quarterIn_sync_f;
always #(posedge clock) begin
if (reset) begin
quarterIn_sync_f <= 1'b0;
end else begin
quarterIn_sync_f <= quarterIn_sync;
end
end
assign quarterIn_edge = quarterIn_sync & ~quarterIn_sync_f; // Detects rising edge
Now, replace the quarterIn in the saturating counter code with quarterIn_edge:
always #(posedge clock) begin
if (reset) begin
num_push <= 3'b0;
end else begin
if (quarterIn_edge == 1'b1 && num_push != 3'b100) begin
num_push <= num_push + 3'b1;
end
end
end
And we're done!
Im just starting to learn how to code in Verilog. Can anyone help me figure out how to implement the following code in verilog using one-hot encoding
module Controller(b, x, clk, rst);
input b, clk, rst;
output x;
reg x;
parameter Off = 2'b00,
On1 = 2'b01,
On2 = 2'b10,
On3 = 2'b11;
reg [1:0] currentstate;
reg [1:0] nextstate;
//state register
always # (posedge rst or posedge clk)
begin
if(rst==1)
currentstate <= Off;
else
currentstate <= nextstate;
end
//combinational
always # (*)
begin
case (currentstate)
Off: begin
x <= 0;
if(b==0)
nextstate <= Off;
else
nextstate <= On1;
end
On1 : begin
x <= 1;
nextstate <= On2;
end
On2 : begin
x <= 1;
nextstate <= On3;
end
On3 : begin
x <= 1;
nextstate <= Off;
end
endcase
end
I tried changing the parameters to:
parameter Off = 4'b0001,
On1 = 4'b0010,
On2 = 4'b0100,
On3 = 4'b1000;
However, ive read that this is not a good implementations.
Some of the advantages of onehot encoding in FSMs are as follows:
Low switching activity. Since only single bit is switched at a time, the power consumption is less and it is less prone to glitches.
Simplified encoding. One can determine the state just by looking at the bit position of '1' in the current state variable.
The disadvantage of this technique is that it requires more number of flops. So, if one has a FSM with 10 different states, one needs 10 flops, while one needs only 4 flops when using decimal encoding.
Coming to your question, it is simple to change to onehot encoded FSM. One needs to implement a case statement based on the position of 1 in the currentstate variable. The code snippet can be implemented as follows:
parameter Off = 2'b00,
On1 = 2'b01,
On2 = 2'b10,
On3 = 2'b11;
//...
always # (*)
begin
nextstate = 4'b0000;
case (1'b1)
currentstate[Off] : begin
x = 0;
if(b==0)
nextstate[Off] = 1'b1;
else
nextstate[On1] = 1'b1;
end
currentstate[On1] : begin
x = 1;
nextstate[On2] = 1'b1;
end
//...
A simple example is available at this link and explanation is over here. Cummings paper is also a good source for more info.
EDIT: As #Greg pointed out, it was a copy-paste error. A combinational block must use blocking assignments.
`timescale 1ns / 1ps
module stopwatch(
input clock,
input reset,
input increment,
input start,
output [6:0] seg,
output dp,
output [3:0] an
);
reg [3:0] reg_d0, reg_d1, reg_d2, reg_d3; //registers that will hold the individual counts
reg [22:0] ticker;
wire click;
//the mod 1kHz clock to generate a tick ever 0.001 second
always # (posedge (clock) or posedge (reset))
begin
if(reset)
begin
ticker <= 0;
end
else
begin
if (start)
begin
if(ticker == (100000 - 1)) //if it reaches the desired max value reset it
ticker <= 0;
else if (increment)
ticker <= ticker;
else
ticker <= ticker + 1;
end
end
end
//increment a second everytime rising edge of down button
reg [3:0] inc_temp;
always # (posedge (increment))
begin
if (reg_d3 == 9)
inc_temp = 0;
else
inc_temp = reg_d3 + 1;
end
assign click = ((ticker == (100000 - 1))?1'b1:1'b0); //click to be assigned high every 0.001 second
//update data start from here
always # (posedge (clock) or posedge (reset))
begin
if(reset)
begin
reg_d0 <= 0;
reg_d1 <= 0;
reg_d2 <= 0;
reg_d3 <= 0;
end
else
begin
if (increment)
begin
reg_d3 <= inc_temp;
reg_d0 <= reg_d0;
reg_d1 <= reg_d1;
reg_d2 <= reg_d2;
end
else if (click) //increment at every click
begin
if(reg_d0 == 9) //xxx9 - 1th milisecond
begin
reg_d0 <= 0;
if (reg_d1 == 9) //xx99 - 10th milisecond
begin
reg_d1 <= 0;
if (reg_d2 == 9) //x999 - 100th milisecond
begin
reg_d2 <= 0;
if(reg_d3 == 9) //9999 - The second digit
reg_d3 <= 0;
else
reg_d3 <= reg_d3 + 1;
end
else
reg_d2 <= reg_d2 + 1;
end
else
reg_d1 <= reg_d1 + 1;
end
else
reg_d0 <= reg_d0 + 1;
end
else
begin
reg_d3 <= reg_d3;
reg_d0 <= reg_d0;
reg_d1 <= reg_d1;
reg_d2 <= reg_d2;
end
end
end
//Mux for display 4 7segs LEDs
localparam N = 18;
reg [N-1:0]count;
always # (posedge clock or posedge reset)
begin
if (reset)
count <= 0;
else
count <= count + 1;
end
reg [6:0]sseg;
reg [3:0]an_temp;
reg reg_dp;
always # (*)
begin
case(count[N-1:N-2])
2'b00 :
begin
sseg = reg_d0;
an_temp = 4'b1110;
reg_dp = 1'b1;
end
2'b01:
begin
sseg = reg_d1;
an_temp = 4'b1101;
reg_dp = 1'b0;
end
2'b10:
begin
sseg = reg_d2;
an_temp = 4'b1011;
reg_dp = 1'b1;
end
2'b11:
begin
sseg = reg_d3;
an_temp = 4'b0111;
reg_dp = 1'b0;
end
endcase
end
assign an = an_temp;
//update the data to display to LEDs
reg [6:0] sseg_temp;
always # (*)
begin
case(sseg)
4'd0 : sseg_temp = 7'b1000000;
4'd1 : sseg_temp = 7'b1111001;
4'd2 : sseg_temp = 7'b0100100;
4'd3 : sseg_temp = 7'b0110000;
4'd4 : sseg_temp = 7'b0011001;
4'd5 : sseg_temp = 7'b0010010;
4'd6 : sseg_temp = 7'b0000010;
4'd7 : sseg_temp = 7'b1111000;
4'd8 : sseg_temp = 7'b0000000;
4'd9 : sseg_temp = 7'b0010000;
default : sseg_temp = 7'b0111111; //dash
endcase
end
assign seg = sseg_temp;
assign dp = reg_dp;
endmodule
I'm trying to design a stop watch, but I'm stuck at the increment thing. The intent is when I press increment(a button), the reg_d3 will increment by one and hold its state until the button is released. I'm able to make the clock stop when the button is pressed, but I can't update the reg_d3. I always receive
[Place 30-574] Poor placement for routing between an IO pin and BUFG
I don't know why; I use increment in the clkdivider just find.
I think the problem is related to this part of your code:
always # (posedge (increment))
begin
if (reg_d3 == 9)
inc_temp = 0;
else
inc_temp = reg_d3 + 1;
end
You are basically using an input signal as a clock, and that is completely discouraged when designing for a FPGA. The P&R tries to re-route an IO pin to a BUFG (global buffer) inside the FPGA so it can be used as a clock.
For FPGA design, you should use one clock signal for all your always #(posedge...) constructions, and use input signals to conditionally load/update the register.
To do that, you have first to synchronize your increment signal to your clk, so avoiding metastability issues:
reg incr1=1'b0, incr2=1'b0;
always #(posedge clk) begin
incr1 <= increment;
incr2 <= incr1;
end
wire increment_synched = incr2;
Then, deglitch increment_synched and detect a rising edge in it:
reg [15:0] incrhistory = 16'h0000;
reg incr_detected = 1'b0;
always #(posedge clk) begin
incrhistory <= { incrhistory[14:0] , increment_synched };
if (incrhistory == 16'b0011111111111111)
incr_detected <= 1'b1;
else
incr_detected <= 1'b0;
end
To detect a valid rising edge, we store a history of the last 16 values of increment_synched. When a valid steady change from 0 to 1 is produced, the history pattern will match the pattern 0011111111111111. Then, and only then, we signal it by raising incr_detected to 1. The next clock cycle, the history pattern won't match the above sequence, and incr_detected will go down to 0 again.
Prior to that, multiple bounces in the push button increment is connected to would cause many transitions, leading to many increments. Using a pattern matching like that eliminates those glitches caused by multiple bounces. With 1Khz clock as you seem to use, this pattern should be enough.
Now you can use incr_detected in your original code, incr_detected wil be 1 for just a single clk cycle.
always # (posedge clk) begin
if (incr_detected) begin
if (reg_d3 == 9)
inc_temp = 0;
else
inc_temp = reg_d3 + 1;
end
end
You can test these additions using the following simulation:
http://www.edaplayground.com/x/AQY
What you will see there is a module that takes your increment input signal from the outside, and generate a glitch-free one-cycle pulse when the input signal makes a final transition from low to high level.
Actually, I've written two versions. The second one tries to mimic the behaviour of a monostable, so the input won't be sampled for a specific period of time after the first low to high transition is detected.
You will see that the second version produces a pulse much sooner than the first version, but it's also prone to take a glitch as valid rising edge, as showed in the simulation. I'd stick with the first version then.