Verilog HDL, User Input from an FPGA - verilog

I am currently working on a project in Verilog HDL with an FPGA obtained from my school (I am running Quartus II vers. 10.1 and 11.0 (I've tried both)). I am getting a very bizarre bug that I cannot figure out for the life of me.
I am developing a Morse Code program which detects dots and dashes, and then outputs the appropriate letter on a HEX display based upon this input. The HEX display works beautifully, but my UserInput module doesn't seem to do anything at all!
module UserInput(Clock, reset, in, out);
input Clock, reset, in;
output reg [1:0] out;
wire [2:0] PS;
reg [2:0] NS;
parameter NONE = 2'b00, DOT = 2'b01, DASH = 2'b11; //For Output
parameter UP = 3'b000, SHORT0 = 3'b001, SHORT1 = 3'b010, UP_DOT = 3'b011, LONG = 3'b100, UP_DASH = 3'b101;
//Active High
always#(PS or in)
case (PS)
UP: if (in) NS = SHORT0;
else NS = UP;
SHORT0: if (in) NS = SHORT1;
else NS = UP_DOT;
SHORT1: if (in) NS = LONG;
else NS = UP_DOT;
UP_DOT: NS = UP;
LONG: if (in) NS = LONG;
else NS = UP_DASH;
UP_DASH: NS = UP;
default: NS = 3'bxxx;
endcase
always#(PS)
case (PS)
UP: out = NONE;
SHORT0: out = NONE;
SHORT1: out = NONE;
UP_DOT: out = DOT;
LONG: out = NONE;
UP_DASH: out = DASH;
default: out = 2'bxx;
endcase
D_FF dff0 (PS[0], NS[0], reset, Clock);
D_FF dff1 (PS[1], NS[1], reset, Clock);
D_FF dff2 (PS[2], NS[2], reset, Clock);
endmodule
module D_FF (q, d, reset, clk);
input d, reset, clk;
output reg q;
always#(posedge clk or posedge reset)
begin
if (reset) q = 0;
else q = d;
end
endmodule
The input for the module is a KEY on the FPGA. The FSM represented by the UserInput module has the key be in the "UP" state at t=0. Then, if there is input, it will move through SHORT0 or SHORT1, and finally LONG. If it the key is released at any of these states, they go to their appropriate intermediary UP states and provide an output of "DOT" or "DASH".
However, when I connect this to my FPGA, I get nothing. From my testing, it seems that it never moves away from the "UP" state. Even my simulations give me nothing. Secondly, I've tried connecting a different UserInput module from a different project (one I know works), and still nothing. Is there something going on in the background of Verilog I am missing?
Here is an image of the simulation waveform:
DFf 0, 1, and 2 are the bits 0, 1, and 2 of PS. My simulation won't allow a showing of the NS.

Your code looks bad to me (which I guess you want to hear as your code doesn't work). It looks like a combination of timing problems and a design flaw.
Let's walk through your waveform view and see if we can't work out what's going on.
signal in goes high, which triggers an always block. PS is 0 so we set NS to 1. This is not in time for the rising clock edge so it's not triggered in the DFF (as you'd have suspected), never mind it'll be caught on the next clock edge.
signal in goes low, which triggers an always block, PS is 0 so we set NS to 0. This happens in time for the rising clock edge and is captured in the DFF (argh we missed the NS signal going to 1 as we wanted).
Also, someone mentioned that there's an error with your flip-flop being asserted while reset is asserted. This isn't a problem: the reset is synchronous. So on the next rising clock edge the DFF is reset to 0.
So, what's the solution (looks like homework to me, so hopefully you've fixed this already!):
It should look something like this (I haven't simulated it, so no guarantees):
Module UserInput (clk, reset, in, out);
input clk, reset, in;
output [1:0] out;
// output parameters
parameter IDLE = 2'b00;
parameter DOT = 2'b01;
parameter DASH = 2'b10;
// FSM states
parameter LOW = 3'b000;
parameter SHORT1 = 3'b001;
parameter SHORT2 = 3'b010;
parameter LONG = 3'b100;
reg [2:0] state;
wire [1:0] next_out;
wire [2:0] next_state;
always #(posedge clk)
begin
if (reset)
begin
out <= IDLE;
state <= LOW;
end;
else
begin
out <= next_out;
state <= next_state;
end
end if;
end
always #(*)
begin
case (state)
LOW:
next_out = IDLE;
next_state = (in? SHORT1 : LOW);
SHORT1:
begin
next_state = (in? SHORT2: LOW);
next_out = (in? IDLE : DOT);
end;
SHORT2:
next_state = (in? LONG: LOW);
next_out = (in? IDLE : DOT);
LONG:
next_state = (in? LONG : LOW);
next_out = (in? IDLE : DASH);
default:
// we shouldn't get here!!
next_state = LOW;
next_out = IDLE;
end;
end module;
So what's going on here:
I think this should be fairly obvious. When the in signal moves from high to low then we want to output the current state (LONG as a DASH, SHORT1 and SHORT2 as a DOT), otherwise we output IDLE. If the in signal is high then we want to move the state along depending on how long it's been high for.
There's an error with this code which won't effect simulation, but which will almost certainly effect you on the FPGA: if you are getting input from an external source then you'll need to buffer it through a (series?) of flip-flops to prevent metastability problems. This can be fixed by adding a series of D flip-flops to capture the in signal and then passing this "cleaned" buffered_in to the UserInput.
ie:
module in_buffer (clk, reset, in, out);
input clk, reset, in;
output out;
reg buf1, buf2;
always # (posedge clk)
begin
if (reset)
begin
out <= 0;
buf1 <= 0;
buf2 <= 0;
end
else
out <= buf2;
buf2 <= buf1;
buf1 <= in;
end
end

Related

Verilog Synchronous 4 bit Counter stay on max value until given signal

So I have my counter in verilog which is 4 bits and I want it to stay on max value, 1111, until I give it a signal to start counting from 0000 again.
Here's what I've been able to come up with so far:
module contadorAscMax
(
input iClk,
input iRst,
output oQ,
input iCE,
input iSignal,
output [3:0] orCnt
);
reg[3:0] rvCnt_d;
reg[3:0] rvCnt_q;
assign orCnt = rvCnt_q;
always #(posedge iClk or posedge iRst)
begin
if(iRst)
begin
rvCnt_q<=4'b0;
end
else
begin
if(iCE)
begin
rvCnt_q<=rvCnt_d;
end
else
begin
rvCnt_q<=rvCnt_q;
end
end
end
always #*
begin
rvCnt_d=rvCnt_q+4'b1;
if(rvCnt_d == 4'b1111)
begin
rvCnt_d = rvCnt_d;
end
else if(rvCnt_d == 4'b1111 & iSignal)
begin
rvCnt_d = 4'b0;
end
end
endmodule
But it just won't wait for the signal. I am very new to verilog so my code probable doesn't make much sense to a hardware guy, since I am a software engineer so sorry if there are some rookie mistakes here.
As for the testbench, here is what I have:
`timescale 1ns / 1ps
module vtfContMax;
// Inputs
reg iClk;
reg iRst;
reg iCE;
reg iSignal;
// Outputs
wire oQ;
wire [3:0] orCnt;
// Instantiate the Unit Under Test (UUT)
contadorAscMax uut (
.iClk(iClk),
.iRst(iRst),
.oQ(oQ),
.iCE(iCE),
.iSignal(iSignal),
.orCnt(orCnt)
);
initial begin
// Initialize Inputs
iClk = 1;
iRst = 1;
iCE = 1;
iSignal = 0;
// Wait 100 ns for global reset to finish
#10;
iRst = 0;
repeat(10)
begin
repeat(10)
begin
wait(iClk);
wait(!iClk);
end
end
$stop();
// Add stimulus here
end
always
begin
#5;
iClk = ~iClk;
#10
iSignal = ~iSignal;
end
endmodule
Thanks for any help :)
You have split the code in a register and combinatorial section. Although that is a good idea for complex logic, for a simple 4 bit counter it is a bit over the top.
For solving your problem you are close. The trick with code like this, is to make the definition using 'programming' language. Then the code flows from that.
I want to have a counter which goes from 1111 to 0000 when a signal is present, else I want it to count up.
This then leads to:
always #(clk or posedge reset)
begin
if (reset)
count <= 4'b1111;
else
begin
if (count==4'b1111 && start_signal)
count <= 4'b0000;
else
count <= count + 4'b0001
end
end
What you don't mention, but what I see from your code you also have an enable (iCE) and an unused output oQ. The total then becomes:
module contadorAscMax
(
input iClk,
input iRst,
// output oQ,
input iCE,
input iSignal,
output reg [3:0] orCnt
);
always #(iClk or posedge iRst)
begin
if (iRst)
orCnt <= 4'b0000; // or should that be 4'b1111
// Is this really what you want?
// It will start counting after a reset!
else
begin
if (iCE)
begin
if (orCnt==4'b1111 && iSignal)
orCnt <= 4'b0000;
else
orCnt <= orCnt+ 4'b0001;
end
end
end
endmodule
Some more remarks:
Your reset condition looks flawed to me but you have to solve that.
Give the counter enable signal a decent name: 'count_enable' not 'signal'.
Last: I would not use all the 'i's and 'o's. The 'o' signals from one module will be the 'i' of another. Thus you have to change the signal names somewhere. It is better to have a defined signal in your system. If only so you can find in the timing report or gates after synthesis.

How to write a verilog code in two-always-block style with multiple state regs?

I'm a begginer of Verilog. I read a several materials about recommended Verilog coding styles like this paper and stackoverflow's questions.
Now, I learned from them that "two always block style" is recommended; separate a code into two parts, one is a combinational block that modifies next, and the another is a sequential block that assigns it to state reg like this.
reg [1:0] state, next;
always #(posedge clk or negedge rst_n)
if (!rst_n)
state <= IDLE;
else
state <= next;
always #(state or go or ws) begin
next = 'bx;
rd = 1'b0;
ds = 1'b0;
case (state)
IDLE : if (go) next = READ;
else next = IDLE;
...
And here is my question. All example codes I found have only one pair of registers named state and next.
However, if there are multiple regs that preserve some kinds of state, how should I write codes in this state-and-next style?
Preparing next regs corresponding to each of them looks a little redundant because all regs will be doubled.
For instance, please look at an UART sender code of RS232c I wrote below.
It needed wait_count, state and send_buf as state regs. So, I wrote corresponding wait_count_next, state_next and send_buf_next as next for a combinational block. This looks a bit redundant and troublesome to me. Is there other proper way?
module uart_sender #(
parameter clock = 50_000_000,
parameter baudrate = 9600
) (
input clk,
input go,
input [7:0] data,
output tx,
output ready
);
parameter wait_time = clock / baudrate;
parameter send_ready = 10'b0000000000,
send_start = 10'b0000000001,
send_stop = 10'b1000000000;
reg [31:0] wait_count = wait_time,
wait_count_next = wait_time;
reg [9:0] state = send_ready,
state_next = send_ready;
reg [8:0] send_buf = 9'b111111111,
send_buf_next = 9'b111111111;
always #(posedge clk) begin
state <= state_next;
wait_count <= wait_count_next;
send_buf <= send_buf_next;
end
always #(*) begin
state_next = state;
wait_count_next = wait_count;
send_buf_next = send_buf;
case (state)
send_ready: begin
if (go == 1) begin
state_next = send_start;
wait_count_next = wait_time;
send_buf_next = {data, 1'b0};
end
end
default: begin
if (wait_count == 0) begin
if (state == send_stop)
state_next = send_ready;
else
state_next = {state[8:0], 1'b0};
wait_count_next = wait_time;
send_buf_next = {1'b1, send_buf[8:1]};
end
else begin
wait_count_next = wait_count - 1;
end
end
endcase
end
assign tx = send_buf[0];
assign ready = state == send_ready;
endmodule
I think you did a good job and correctly flopped the variables. The issue is that without flops you would have a loop. i.e. if you write something like the following, the simulation will loop and silicon will probably burn out:
always_comb wait_count = wait_count - 1;
So, you need to stage this by inserting a flop:
always_ff #(posedge clk)
wait_count <= wait_count - 1;
Or in your case you you used an intermediate wait_count_next which is a good style:
always_ff #(posedge clk)
wait_count_next <= wait_count;
always_comb
wait_count = wait_count_next;
You might or might not have an issue with the last assignments. Which version of the signals you want to assign to tx and ready? the flopped one or not?
And yes, you can split theses blocks in multiple blocks, but in this case there seems to be no need.
And yes, the other style would be write everything in a single flop always block. But this will reduce readability, will be more prone to your errors and might have synthesis issues.

Verilog: wait for module logic evaluation in an always block

I want to use the output of another module inside an always block.
Currently the only way to make this code work is by adding #1 after the pi_in assignment so that enough time has passed to allow Pi to finish.
Relevant part from module pLayer.v:
Pi pi(pi_in,pi_out);
always #(*)
begin
for(i=0; i<constants.nSBox; i++) begin
for(j=0; j<8; j++) begin
x = (state_value[(constants.nSBox-1)-i]>>j) & 1'b1;
pi_in = 8*i+j;#1; /* wait for pi to finish */
PermutedBitNo = pi_out;
y = PermutedBitNo>>3;
tmp[(constants.nSBox-1)-y] ^= x<<(PermutedBitNo-8*y);
end
end
state_out = tmp;
end
Modllue Pi.v
`include "constants.v"
module Pi(in, out);
input [31:0] in;
output [31:0] out;
reg [31:0] out;
always #* begin
if (in != constants.nBits-1) begin
out = (in*constants.nBits/4)%(constants.nBits-1);
end else begin
out = constants.nBits-1;
end
end
endmodule
Delays should not be used in the final implementation, so is there another way without using #1?
In essence i want PermutedBitNo = pi_out to be evaluated only after the Pi module has finished its job with pi_in (=8*i+j) as input.
How can i block this line until Pi has finished?
Do i have to use a clock? If that's the case, please give me a hint.
update:
Based on Krouitch suggestions i modified my modules. Here is the updated version:
From pLayer.v:
Pi pi(.clk (clk),
.rst (rst),
.in (pi_in),
.out (pi_out));
counter c_i (clk, rst, stp_i, lmt_i, i);
counter c_j (clk, rst, stp_j, lmt_j, j);
always #(posedge clk)
begin
if (rst) begin
state_out = 0;
end else begin
if (c_j.count == lmt_j) begin
stp_i = 1;
end else begin
stp_i = 0;
end
// here, the logic starts
x = (state_value[(constants.nSBox-1)-i]>>j) & 1'b1;
pi_in = 8*i+j;
PermutedBitNo = pi_out;
y = PermutedBitNo>>3;
tmp[(constants.nSBox-1)-y] ^= x<<(PermutedBitNo-8*y);
// at end
if (i == lmt_i-1)
if (j == lmt_j) begin
state_out = tmp;
end
end
end
endmodule
module counter(
input wire clk,
input wire rst,
input wire stp,
input wire [32:0] lmt,
output reg [32:0] count
);
always#(posedge clk or posedge rst)
if(rst)
count <= 0;
else if (count >= lmt)
count <= 0;
else if (stp)
count <= count + 1;
endmodule
From Pi.v:
always #* begin
if (rst == 1'b1) begin
out_comb = 0;
end
if (in != constants.nBits-1) begin
out_comb = (in*constants.nBits/4)%(constants.nBits-1);
end else begin
out_comb = constants.nBits-1;
end
end
always#(posedge clk) begin
if (rst)
out <= 0;
else
out <= out_comb;
end
That's a nice piece of software you have here...
The fact that this language describes hardware is not helping then.
In verilog, what you write will simulate in zero time. it means that your loop on i and j will be completely done in zero time too. That is why you see something when you force the loop to wait for 1 time unit with #1.
So yes, you have to use a clock.
For your system to work you will have to implement counters for i and j as I see things.
A counter synchronous counter with reset can be written like this:
`define SIZE 10
module counter(
input wire clk,
input wire rst_n,
output reg [`SIZE-1:0] count
);
always#(posedge clk or negedge rst_n)
if(~rst_n)
count <= `SIZE'd0;
else
count <= count + `SIZE'd1;
endmodule
You specify that you want to sample pi_out only when pi_in is processed.
In a digital design it means that you want to wait one clock cycle between the moment when you are sending pi_in and the moment when you are reading pi_out.
The best solution, in my opinion, is to make your pi module sequential and then consider pi_out as a register.
To do that I would do the following:
module Pi(in, out);
input clk;
input [31:0] in;
output [31:0] out;
reg [31:0] out;
wire clk;
wire [31:0] out_comb;
always #* begin
if (in != constants.nBits-1) begin
out_comb = (in*constants.nBits/4)%(constants.nBits-1);
end else begin
out_comb = constants.nBits-1;
end
end
always#(posedge clk)
out <= out_comb;
endmodule
Quickly if you use counters for i and j and this last pi module this is what will happen:
at a new clock cycle, i and j will change --> pi_in will change accordingly at the same time(in simulation)
at the next clock cycle out_comb will be stored in out and then you will have the new value of pi_out one clock cycle later than pi_in
EDIT
First of all, when writing (synchronous) processes, I would advise you to deal only with 1 register by process. It will make your code clearer and easier to understand/debug.
Another tip would be to separate combinatorial circuitry from sequential. It will also make you code clearer and understandable.
If I take the example of the counter I wrote previously it would look like :
`define SIZE 10
module counter(
input wire clk,
input wire rst_n,
output reg [`SIZE-1:0] count
);
//Two way to do the combinatorial function
//First one
wire [`SIZE-1:0] count_next;
assign count_next = count + `SIZE'd1;
//Second one
reg [`SIZE-1:0] count_next;
always#*
count_next = count + `SIZE'1d1;
always#(posedge clk or negedge rst_n)
if(~rst_n)
count <= `SIZE'd0;
else
count <= count_next;
endmodule
Here I see why you have one more cycle than expected, it is because you put the combinatorial circuitry that controls your pi module in you synchronous process. It means that the following will happen :
first clk positive edge i and j will be evaluated
next cycle, the pi_in is evaluated
next cycle, pi_out is captured
So it makes sense that it takes 2 cycles.
To correct that you should take out of the synchronous process the 'logic' part. As you stated in your commentaries it is logic, so it should not be in the synchronous process.
Hope it helps

Iteration limit when implementing a multicycled processor

I'm trying to implement a simple multicycle processor and I ran into some problems that I don't seem to be getting through. The code is below. I'm just experimenting right now to get this flowing. When I'm done, I'll begin implementing instructions and ALU. However, I'm stuck at this point. In the code below, I'm aware that data_memory is never used (I'll get to there if I can resolve this), some inputs and outputs are also not used for now, x1 and x2 are just variables I created to see what's really going on. What's in definitions.v file is self-evident.
I'm using Altera Quartus 15.1 with Verilog2001. This code compiles fine excepts some warnings due to unused stuff but when I try to simulate it with a clock period of 20ns it gives an error saying that "Error (suppressible): (vsim-3601) Iteration limit 5000 reached at time 100 ns". It also says this is suppressible but I don't know how to suppress either.
I looked up for this error and I learned that this is happening because at some point the code goes into an infinite loop. I tried to solve this by creating another variable ok. A cycle will start by setting ok to 0 and after microoperations for that cycle are done, I set ok to 1. So the cycle will not change at an improper time (it's like locking the cycle). Unfortunately, this resulted with the same error.
I tried another flow, too. Instead of cycle and next_cycle, I created one variable for cycle. At every rising edge of clock, I checked the current state and did things accordingly, then set the cycle for next step. Example:
always # (posedge clk) begin
case (cycle)
3'b000: begin
MAR <= PC;
cycle <= 3'b001;
ire <= 1'b1;
x2 <= 2'b00;
3'b001: begin
...
...
This also compiles fine, and can be simulated without error! However, is not functioning correctly, giving weird(or unexpected) results. I find other approach more intuitive. So I will try to make it work.
How can I resolve/implement this?
`include "definitions.v"
module controller(
input clk,
input nres,
output reg ire,
output reg dwe,
output reg dre,
output reg [1:0] x2,
output reg [`IADR_WIDTH-1:0] i_address,
output reg [`DADR_WIDTH-1:0] d_address,
output reg [`DATA_WIDTH-1:0] data_out);
reg [2:0] cycle = 3'b000;
reg [2:0] next_cycle;
reg [`IADR_WIDTH-1:0] PC = 6'b000000;
reg [`INST_WIDTH-1:0] IR = 12'b00000_0000000;
reg [`DADR_WIDTH-1:0] MAR = 6'b000000;
reg [4:0] OPC = 5'b00000;
wire [`DATA_WIDTH-1:0] data_in;
wire [`INST_WIDTH-1:0] instruction;
reg [1:0] x1;
data_memory dmem ( .clk (clk),
.dwe (dwe),
.dre (dre),
.nres (nres),
.d_address (d_address),
.d_data (data_out),
.d_q (data_in));
instruction_memory imem ( .clk (clk),
.ire (ire),
.i_address (i_address),
.i_q (instruction));
reg ok = 1;
always # (posedge clk) begin
cycle = (ok) ? next_cycle : cycle;
end
always # (cycle) begin
case (cycle)
3'b000: begin
ok = 0;
MAR = PC;
next_cycle = 3'b001;
ire = 1'b1;
x2 = 2'b00;
ok = 1;
end
3'b001: begin
ok = 0;
i_address = MAR;
IR = instruction;
ire = 1'b0;
next_cycle = 3'b010;
x2 = 2'b01;
ok = 1;
end
3'b010: begin
ok = 0;
OPC = IR;
next_cycle = 3'b011;
x2 = 2'b10;
ok = 1;
end
3'b011: begin
ok = 0;
if (OPC==5'b01011) x1 = 2'b11;
PC = PC + 1;
next_cycle = 3'b000;
x2 = 2'b11;
ok = 1;
end
endcase
end
endmodule
When we write always #(signal) in verilog, a specified sensitivity list, the logic is triggered on a change in that signal. This can lead to misunderstanding of how hardware actually works. The only hardware we have that changes on an edge is a flip-flop and you need to specify the posedge or negedge keyword for that.
When always #(signal) is synthesised you actually get a combinatorial block, which has the effect of behaving like always #(*). This is an automatic sensitivity list.
So from the comments we will look at this small section of code:
always # (*) begin
case (cycle)
3'b011: begin
ok = 0;
if (OPC==5'b01011) x1 = 2'b11;
PC = PC + 1;
next_cycle = 3'b000;
x2 = 2'b11;
ok = 1;
This a combinatorial block, triggered in the simulator when anything which can effect he output changes. Most signals are assigned to static signals, or other known values with out loops.
PC = PC +1;
The above line though updates the value of PC, this new value of PC should trigger the combinatorial block to be re-evaluated, hitting the PC increment again, etc. This all happens inside the delta cycle of the simulator.
With hardware description languages (HDLs) like Verilog we have to remember that we are describing parallel statements, not serially executed lines of code.

Hamming (7,4) Code - Finite State Machine

So I am working on a lab assignment for a Computer Engineering class. I have a assignment due and I am trying to get all the help I can, as for the professor I have to wait until a few days before I can speak with them for help. So I am seeing if I can get help her.
My issue is that my finite state machine is not working how it should be as asked from the lab assignment. The state machine is supposed to have 3 states; idle, s1, s2. Idle is supposed to show all zeros in the waveform, State 1 will show the randomly generated 4-bit number from the LFSR, and State 2 will show the result from the 4-bit number after hamming (7,4) is done. The clock is changed to a 1HZ clock, clk division used.
Code is as follows:
CLOCK_1HZ
module clock_1hz (clk, reset, clk2);
input clk, reset;
output clk2;
reg temp;
reg [25:0] cnt;
always #(posedge clk or posedge reset)
begin
if (reset)
begin
cnt = {25{1'b0}};
end
else
begin
if (cnt == 26'b10111110101111000001111111)
begin
cnt = {25{1'b0}};
temp = 1'b1;
end
else if (cnt < 26'b01011111010111100000111111)
begin
cnt = cnt + 1;
temp = 1'b1;
end
else
begin
cnt = cnt + 1;
temp = 1'b0;
end
end
end
assign clk2 = temp;
endmodule
LFSR
module lfsr (out, clk, rst);
output [4:1] out;
input clk, rst;
reg [4:1] w;
always #(posedge clk or posedge rst)
begin
if (rst)
begin
w = 4'b1011;
end
else
w = {w[3],w[2],w[1]^w[4], w[4]};
end
assign out=w;
endmodule
HAMMING
module hamming(din, dout);
output [6:0] dout;
input [3:0] din;
assign dout[6] = din[3];
assign dout[5] = din[2];
assign dout[4] = din[1];
assign dout[3] = din[1] ^ din[2] ^ din[3];
assign dout[2] = din[0];
assign dout[1] = din[0] ^ din[2] ^ din[3];
assign dout[0] = din[0] ^ din[1] ^ din[3];
endmodule
All this code works properly and computes the correct HAMMING and the clock division works well with the LFSR and works when it is combined as hierarchy design.
When I make the FSM for this code it works upto it computing the hamming number but does not change state when indicated.
When Switch 1 set: State IDLE
When Switch 2 set: State 1, Shows 4-bit LFSR number
When Switch 2 set: State 2, Shows 7-bit Hamming result
The following is my code for the Finite State Machine and following that is the waveform output.
module fsm ( clk , reset , sw1 , sw2 , sw3 , lights );
input clk, reset, sw1, sw2, sw3;
output reg [6:0] lights;
reg[2:0] state;
wire clkhz;
wire [3:0] lfsr_out;
wire [6:0] hout;
parameter S0 = 3'b000, S1 =3'b001, S2 = 3'b010; // states
clock_1hz u1(.clk(clk),
.reset(reset),
.clk2(clkhz));
lfsr u2(.rst(reset),
.clk(clkhz),
.out(lfsr_out));
hamming u3(.din(lfsr_out),
.dout(hout));
always #(posedge clk or posedge reset)
begin
if (reset == 1)
begin
state <= S0;
end
else
case(state)
S0: if(sw1 == 1)
begin
state <= S0;
end
S1: if(sw2 == 1)
begin
state <= S1;
end
S2: if(sw3 == 1)
begin
state <= S2;
end
default state <= S0;
endcase
end
always #(*)
begin
case(state)
S0: lights = 7'b0000000; //led are all off
S1: lights = lfsr_out; //4bit lfsr shown on led
S2: lights = hout; // display hamming code result
default lights = 7'b0000000; //led are all off
endcase
end
endmodule
WAVEFORM OF FINITE STATE MACHINE:
I don't think it is a state machine that you need here. From you description of the requirements, perhaps you just need to remember the current switch pressed? If that is the case, you could do something along the lines of:
always #(posedge clk or posedge reset)
if (reset == 1)
state <= S0;
else
if (sw1)
state <= S0;
else if (sw2)
state <= S1;
else if (sw3)
state <= S2;
Now state is remembering the current switch pressed. From your description of the requirements, doing this does not seem to depend on which switch which switch was pressed before that and so it doesn't look like you need a state machine - the behaviour does not depend on the state.
(You don't need all those begins and ends, either. You don't need them if there is only one statement in the branch.)

Resources