I'm trying to design this state machine in verilog:
I was have:
`timescale 1ns/1ns
module labEightMachine(y, x,clk,clr)
output y;
input [1:2] x;
input clk, clr;
reg [1:2] q;
reg y;
reg nX;
always # (posedge clk)
begin
if(clr)
{q}<=2'b00;
else
q<= {nX}
end
always #(y,x)
begin
if(q==2'b00)
if(x==2'b00)
q<=2'b00;
else
q<=2'b01;
y<=1;
if(q==2'b01)
if((x==2'b00)||(x==2'b01))
q<=2'b00;
y<=0;
else
q<=2'b11;
y<=0;
if(q==2'b11)
if(x==2'b10)
q<=2'b10;
y<=1;
else
q<=2'b00;
y<=0;
if(q==2'b10)
q<=2'b00;
y<=0;
end
endmodule
If any one could help by telling me where it is incorrect, that would be greatly appreciated. The state machines confuse me and I'm not sure that I am reassigning everything correctly.
Applying stimulus is always a better way to check your code. Leaving the syntax errors of semi-colons/begin-end and all that, a couple of immediate logical errors I can see are as below.
The declaration reg nX declares a variable of single bit width. On the contrary, q is declared as reg [1:2] q, of two bits width.
Secondly,q is driven from two always blocks. If clr is LOW, then q is driven by nX. While, nX is never driven by any signal. So, the output will be x majority of times (leaving those race-conditions). Multiple driver issues.
Thirdly, it would be better to use if--else if--else ladder instead of multiple ifs. This will make the next_state logic clear.
A better FSM, might have two always blocks and one output logic block. One for sequential logic and other for combinational logic. Sequential block is used to update the current_state value by the next_state value. While, a combinational block is used to update the next state value according to inputs. The output logic must either have a separate block of continuous assignments or a procedural block.
Also, it might be convenient to use a case statement for next_state logic. This will be useful when too many states are interacting with each other in a single FSM. Using default in case statement is inevitable.
For further information on efficient FSM coding styles, refer to CummingsSNUG1998SJ_FSM paper and CummingsSNUG2000Boston_FSM paper.
Related
Picture given is a module I'd like to express.
MulCell
For some reason I had to bring up the Multiplicand or Multiplier from arrays of numbers using wire. ex)wire [3:0] abc = 4'b1111;
But very odd! When I assign specific value of wire abc to "Multiplier", it works well. However if I assign it to "Multiplicand", I see red lines just as in the picture. redline
Any idea what had gone wrong? Thanks
Code for MulCell
module MulCell(Multiplicand,Multiplier,Sin,Cin,Sout,Cout);
input Multiplicand,Multiplier,Sin,Cin;
output Sout,Cout;
reg Sout,Cout;
wire tmp;
assign tmp=Multiplicand&Multiplier;
always#(tmp) begin
{Cout,Sout} <= tmp+Sin+Cin;
end
endmodule
Code for testbench_MulCell
`timescale 1ns/1ns
module testbench_MulCell();
reg Multiplicand,Multiplier,Sin,Cin;
wire Sout,Cout;
MulCell MC(Multiplicand,Multiplier,Sin,Cin,Sout,Cout);
wire [3:0]abc;
assign abc=4'b1111;
initial begin
Multiplicand=abc[2];
Multiplier=1'b1;
Sin=1'b1;
Cin=1'b1;
#10 //expecting 11
Multiplicand=1'b0;
Multiplier=abc[1];
Sin=1'b1;
Cin=1'b1;
#10 $stop;//expecting 10
end
endmodule
I can be wrong, but it seems there's a race condition between assigning value to abc and running initial block. At the moment when initial block started running, the assign abc =.. isn't executed yet. That's why you get x/red_lines in waveform view.
Verilog is an event driven simulator. It means that every 'always...', 'assign' block has inputs and outputs. Inputs in always block is are represented by its sensitivity list. In your case that would be the tmp signal. The whole block will start evaluation if and only if a change of an input is detected.
Also in the module the initial is scheduled for execution once during the simulation and is always executed first, before any of the always blocks (except in special cases in system verilog). So, in your case first few statements of the initial block (before first #10) are executed before the assign statement. So, for the first 10 cycles value of abc will be `4bxxxx, which explains your red line. For the same reason the values. As a result, values of multiplicand and consequently of MC/tmp,Sout,Cout will also be 'x'.
At #10 you change the values of the variables, causing always block in MC to re-evaluate with new values. By that time abc is already set to 1111 and all 'x' disappear.
So, efficiently you simulated only the second set of values but hot the first.
The suggestion is: add a small delay in front of the initial block:
initial begin
#1
Multiplicand=abc[2];
Multiplier=1'b1;
Sin=1'b1;
This will delay execution of the statements and the value of 'abc' will be set by this time. You will have a short period (1) of the red line, but you will see results of the values you set.
Another possibility is to set value of abc in the initial block first, but you would need a reg variable to do so:
reg[3:0] abcSet;
assign abc = abcSet;
initial begin
abcSet = 4'b1111;
...
another thing, in your always block you use non-blocking assignment (<=). Do not! This is good for flops and latches but bad for simple combinatorial logic. Use the regular assignment there (=).
{Cout,Sout} = tmp+Sin+Cin;
Also, this always block will not be avaluated if you just change Sin or Cin and tmp stays the same. You should either add those into the sensitivity list:
always #(tmp, Sin, Cin)
or use always #* instead. Actually it is a good idea to always use this construct instead of regular V95 always blocks. This way you will avoid possible implicit latches in the design (as in your case in respect to missing parts of the sensitivity list).
Also, in general most of the modern designs are synchronous designs and use a clock signal for synchronization. In your case the multpliplier sell shoudl be synchronized as well, you would need to provide a toggling clock signal. In theis case your operation could look like the following:
always #(posedge clk)
{Cout,Sout} <= tmp+Sin+Cin;
It makes evaluation happen at positive edge of the clk signal, it it is the only member of the sensitivity list. All other signals should set before the clock change. And yes, it is a flop and <= is used there.
I came to know that we can use assign statements in procedural blocks(like in always), what will be the difference in using "assign" inside always block and outside it(in concern with synthesized circuit). I mean when it is absolutely necessary to use assign in always?
Never, assign keyword is for continuous assignment and it will generate combinatorial logic at synthesis. In fact, you can obtain the assign behaviour with an always block:
wire test;
//At all times, test equals input
assign test = input;
Is equivalent to:
reg test;
//Each time input changes(with the always#*), test takes its value
always#*
test = input;
In always blocks, you should only use non-blocking assignment('<=') which are procedural assignments. Using blocking assignment is possible, however, you have to be sure to do what you want.
From this thread:
Two rules to live by that I know of no exceptions:
Always use blocking assignments for combinatorial or level-sensitive code, as well a clock assignments
Always use non-blocking assignments for variables that are written on a clock edge, and read on the same clock edge in another process.
assign and corresponding deassign (in always blocks) are also called 'procedural continuous assighment' can be used in always blocks for specific purposes. In most cases this is non-synthesizable and I had never ran across its use.
an example:
reg in1, in2, out;
reg [1:0] select;
always #* begin
case (select)
2'b01: assign out = in1;
2'b10: assign out = in2;
2'b11: deassign out;
endcase // case (select)
end
general recommendateion -- do not use it.
This code is supposed to increment a counter (outputting to LEDs) when one button is pushed and decrement it when the other one is pushed. It works OK with decrementing but on incrementing it changes LEDs to random configuration instead.
module LED_COUNTER( CLK_50M, LED, Positive, Negative );
input wire CLK_50M;
input wire Positive;
input wire Negative;
output reg[7:0] LED;
always#( posedge Positive or posedge Negative )
begin
if(Positive == 1)
LED <= LED + 1;
else
LED <= LED - 1;
end
endmodule
I am using this board: http://www.ebay.com/itm/111621868286. The pin assignment is:
The connections:
After swapping pin assignments for buttons the behavior stays the same.
As others have already pointed out, you should be clocking with the CLK_50M and you should de-bounce your inputs (some FPGAs do it for you automatically, check your manual).
The reason you see partial functionality is from the way the synthesizer interprets the RTL. If the sensitivity list is edge triggered and that signal is referenced in the body of the always block, then the synthesizer will think it is an asynchronous level sensitive signal. This is intend for asynchronous reset & set (sometimes named clear & preset). ASIC design typically use flops with asynchronous reset in most the design. FPGAs tend to have a limited number of flops with asynchronous set or rest, so check your manual and use sparingly.
With your code, Negative is the clock and Positive is treated as an active high asynchronous input.
Modify the code to a functional behavioral equivalent (in simulation) seen below, then Positive will be the clock and Negative will be the active high asynchronous input.
always#( posedge Positive or posedge Negative )
begin
if(Negative == 1)
LED <= LED - 1;
else
LED <= LED + 1;
end
There are several resource for learning Verilog available online (use your favorite search engine), and I have some resources posted on my profile though more aimed at SystemVerilog.
Here is some pseudo code to point you in the correct direction for your project:
always #(posedge CLK_50M)
begin
past_Positive <= Positive;
// ...
case({/* ... , */ past_Positive,Positive})
4'b0001 : LED <= LED + 1;
4'b0100 : LED <= LED - 1;
// ...
endcase
end
First, update the design to a synchronous design where state only changes at rising edge of the CLK_50M, like
always#( posedge CLK_50M)
begin
...
end
Then add de-bounce logic logic for the two switch inputs; see contact bounce. This can be done with a small module you write yourself; that is a good exercise.
Output from the contact de-bounce logic can then be used for change detection, to make a single cycle indication each time a contact is pressed, and this indication can then be used to update the counter.
You have no debounce circuitry or logic. A mechanical switch will physically bounce a lot, so your 50MHz clock is going to see many, many transitions on the input signal, leading to erratic behavior.
I forgot to mention that you're not even using that 50MHz clock in a synchronous design. Rather you're asynchronously looking for transitions.
You need a low-pass filter somewhere. Either implemented with analog components on the input signal, or as a counter in hardware.
I'm running into some problems implementing a synthesizeable state machine to output the results from several lower-level modules I've already implemented. As far as I can tell, the structure I have so far wants nested always blocks, but that can't be done in Verilog. I'm not sure how to circumvent this problem.
EDIT: code taken down as at least one classmate has turned in identical (and non-functioning, lol) portions of my own code.
If you think you need nested always blocks then you are likely not thinking about hardware design, while RTL gives some abstraction from the electronic components it has to be written in such away that represent possible hardware behaviour.
always #* represents a combinatorial block.
always #(posdege clk) represents sequential logic, where the outputs are driven by flip-flops.
always blocks tell the simulator when to trigger the block for simulation, as everything is happening at once, it is all parallel. The simulator could not know when to schedule code not contained in these blocks.
You need to have always #(posedge KEY[0] and always #(posedge KEY[1] which each contain the case statement. If they are not to do anything for a particular case then hold or Zero the current values. You can have a default: case as a catch all for those unspecified.
Update
Regarding the rotate function you should be able to take the MSB to indicate if negative.
Use >>> to preserve sign bits. you might need to declare the reg/wires assigned or add $signed function
reg signed [msb:0] data_in;
always #(posedge clk) begin
if (data_in[msb] == 1'b0) begin
data_out <= data_in <<< 1;
end
else begin
data_out <= data_in >>> 1;
end
end
// or use $signed(data_in) >>> 1;
You appear to have everything inside an initial block, so looking for a posedge doesn't even make sense. In general, initial blocks are not synthesizable.
No, you can't nest always blocks and you shouldn't need to.
You should have a single always #(posedge KEY[1]) that contains all of the possible assignments to STATE. You can't make assignments to the same reg in different always blocks. Be sure to use non-blocking assignments.
Create additional always blocks for your other reg signals, ideally using one always block per signal.
i just want to know the difference between this two statement
always #(posedge CLK)
begin
state <= next_state;
end
AND:
always #(CLK)
begin
case(CLK)
1'b1:
state <= next_state;
1'b0:
state <= state;
end
Is there a difference between both ?
Thanks
Not quite. posedge detects these transitions (from the LRM):
Table 43—Detecting posedge and negedge
To 0 1 x z
From
0 No edge posedge posedge posedge
1 negedge No edge negedge negedge
x negedge posedge No edge No edge
z negedge posedge No edge No edge
So, 0->x is a posedge, for example. Your second example only detects cases where CLK ends up as 1, so misses 0->x and 0->z.
The IEEE Std. 1364.1(E):2002 (IEC 624142(E):2005), the Verilog register transfer level synthesis standard, states in Sec. 5.1 that an always block without any posedge/negedge events in the sensitivity list is combinational logic. I.e. the signals in the event list are ignored and the block is synthesized as if an implicit expression list (#(*), #*) was used. The following example is given in the standard ("Example 4" on page 14):
always # (in)
if (ena)
out = in;
else
out = 1’b1;
// Supported, but simulation mismatch might occur.
// To assure the simulation will match the synthesized logic, add ena
// to the event list so the event list reads: always # (in or ena)
(the comment is also copied from the standard document)
I.e. for a synthesis tool your second block is effectively:
always #*
begin
case(CLK)
1'b1:
state <= next_state;
1'b0:
state <= state;
end
which is just a multiplexer with CLK as select input, next_state as active-1 input and the output (state) fed back as active-0 input. A smart synthesis tool might detect that this is identical to a d-type latch with CLK as enable-input and create a d-type latch instead of a combinational loop. Note that the synthesis tool is not required to detect this latch because the code explicitly assigns state in all branches (compare Sec. 5.3. of the standard).
Either way this is different from the d-type flip-flop your first code example would synthesize to. This is one of many cases where Verilog-code has different meaning in simulation and synthesis. Therefore it is important to (1) write synthesizeable Verilog code in a way that avoids this cases and (2) always run post-synthesis simulations of your design (even if you are also using formal verification!) to make sure you have successfully avoided this pitfalls.
Functionally, those two circuits describe the same behavior in verilog, so I think there should be no difference.
However you should generally use the first style, as that is the one that is standard for writing synthesizable code, and most understandable by anyone else reading your code. The latter style, while describing the correct behavior, may confuse some synthesizers that don't expect to see clocks that are both sensitive to positive and negative edge.
The two blocks are VERY different.
The top one gives you a flip-flop while the bottom one gives you a latch with a multiplexer with the CLK as the select signal.
The critical difference between the two blocks is that the top one is a synchronous block i.e. the posedge clk part while the bottom one is asynchronous with the CLK level, not edge.
A verilog simulator could do left-hand sampling of CLK, effectively making the the case(CLK) version the same as a negedge CLK flop. Otherwise the simulator will treat it like a posedge CLK flop. It really depends how it is handled in the scheduler of specific simulator (or how a particular synthesizer will process it).
The most common codding styles all use the first condition. It is explicitly clear to the synthesizer and anyone reading the code that state is intended to be a flip-flop with a positive edge clocking trigger.
There is also a simulation performance differences. The posedge CLK performances 2 CPU operations every clock period, while the case(CLK) will perform 6 CPU operations every clock period. Granted in this example the differences is insignificance, but in large designs the poor coding used everywhere will add up to hours of simulation time wasted.