I am trying to assign a state to a register in a FSM machine #(posedge clk) and reset = 1. However, statement: state <= 2'b00; simply couldn't set state = 2'b00. I checked by debugging that this statement state <= 2'b00 did have been stepped over. I really don't know where the problem is.
I met similar problems in other situations when some registers couldn't be assigned a value using "<=", but some can be in the same always block.
These registers that couldn't take the values simply show as 2'bxx if they have two bits.
Does anybody know what could cause the problem?
Looking at your explanation, i suppose your code is something like this.
always#(posedge clk and reset = 1)
state <= 2'b00;
These are the mistakes you are doing.
1. Sensitivity list can't be a combination of edge triggered and level triggered signals.
2. For conditional operation, you should use "==", not "=".
Ideal code for your operation is,
always#(posedge clk)
if (reset == 1)
state <= 2'b00;
I actually used the same way as you use the clock and reset signal in my code. However, my problem is that I reset the state at the beginning of the always block. Then, in the case statement inside the same always block, I used the default case to put the state back to arbitrary state. I am still a little bit confused by this mistake. But, anyway, after I removed this default statement, everything goes back to normal.
Thanks.
Related
Recently I got stuck between two always block statements while implementing asynchronous reset.
One statement is :
always #(posedge clk or posedge reset)
The second statement is :
always #(posedge clk or reset)
I tried to find the difference between these two statements. Both statements target asynchronous reset, the first statement with edge sensitive reset and another statement with level reset. Please help me to find other differences which will affect the functioning of always block.
I bet you have not tried to synthesize that code.
The first form only works if you add a following:
if (reset)
...
Which gives a high active asynchronous reset.
The second form can not be synthesized at all.
Please help me to find other differences which will affect the functioning of always block.
That is rather a big question. You can't expect us to take you through all possible always constructs.
Hello I have a question about Verilog grammar.
I am aware that # is used with always usually.
but I want to do some action when a variable changes its value.
for example, I want to find out if switch is changing.
So, I tried if (# posedge switch or negedge switch)
But this made an error.
Is there any other way to do this?
Thanks in advance
If you want to write a synchronous design (And you want to do that ;), you have to change state of all your signal on one clock edge (generally rising).
Then to detect switch edge you have to save state of switch value and compare it with actual on rising edge of clock.
always #(posedge clock)
begin
if (switch_old != switch)
switch_edge <= 1'b1;
else
switch_edge <= 1'b0;
switch_old <= switch;
end
You can't do what you ask in a synchronous design, then it can't be syntesizable reasonably.
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 am making a state machine in verilog to implement certain arithmetic functions based on user input. I've run into a snag, however; my first always block, the one that handles my reset and maintains the correct state, is not behaving as expected; it is not updating the state correctly. The code is as follows:
always # (posedge CLOCK_50 or negedge RESET) begin
if(RESET == 1'b0)
STATE <= BASE;
else
STATE <= NEXT_STATE; // this always block, and specifically this line, is //not executing correctly.
end
Here is the general output of the file when reset and then following three button presses (KEY[1]) with SW = 0000:
EDIT: waveform with actual CLOCK_50 and RESET signals added
http://imgur.com/0DUka21
As for my question, I just want to know what I am doing incorrectly with this section of code. I can think of no reason for it to behave this way. Thanks for any help you can provide.
EDIT2: FFS, I changed the block to negedge CLOCK_50 and now it's working. I'd really like to know why if you can tell.
Ah, I see what you did now. You're assigning STATE in both of your two always blocks (STATE <= STATE in the default of the case block). This is bad, as it's a race condition between the two blocks as to which gets actually assigned. In your case, the second block is overriding the first, such that STATE <= STATE gets executed every clock. You should not assign the same variable in more than one always block.
Also you should pay attention to those warnings, but they are referring to the always #(ENABLE) block. This is complaining because you are inferring weird latched behavior, because the output is depending on STATE and SW, but they are not in the sensitivity list. You should probably just make this a combinational block, and use the auto-sensitivity list always #*.
Every always block, as well as every statement outside of an always block, effectively runs in parallel.
Since you have "state" being driven by two always blocks, you're effectively having two wires feed into a single wire. In digital logic design, you just can't do that. (Excluding pull-up resistors and such, but that's another topic.)
In simulation, if the multiple wires driving that single wire have the same logical value, you can get the output you desire; but if they have different values, you'll get invalid or unpredictable output.
In synthesis, this will simply fail with a "multiple drivers" error.
Also, the sensitivity list for an always block should have one of three things in it:
A clock
A clock and an asynchronous reset
Every wire/reg that is used as an input to that always block (*)
Anything else can result in an unintentional latch, which will cause problems.
In case 3, you need to make sure that every wire driven in the always block has a default value. Anything else can result in an unintentional latch.
Lastly, you can't have circular assignments or you risk a logic loop. You have one by assigning next_state to itself. Anything "circular" requires a flip-flop, aka an always block of type 1 or 2 outlined above.
I was wondering whether it was possible for an always block to be executed only when multiple signals in the sensitivity list change together.
As in, suppose I have a signal 'in' and another 'posedge clk'. I want the always block to be executed when BOTH the signals change. Is it possible, and if yes, what is the syntax for it?
In general, no there is no way to do it, as this doesn't actually map to any kind of standard logic cells that one would typically synthesize. However if you describe what your ultimate goal is, I'm sure someone can point you in the right direction while still using synthesizable logic. I'm having a hard time imagining what you could want such a block for.
This an answer to the original question, not the problem revealed in the comments
As #Tim has mentioned there is no hardware construct which can do this. always #(posedge clk) create flip-flops which sample the data on the edge of a clk.
always #* blocks create combinatorial logic which is evaluated by the simulator when ever the right hand side of an assignment or a select signal changes.
If you had multiple 1 bit signals driven from D-type flip-flops you could XOR (^) the input (D) and output (Q) to create a, 1 clock cycle wide, signal indicating the value has changed. These change signals could be combined to create an enable signal. Which is used as a select or enable for a flip-flop.
always #(posedge clk or negedge rst_n) begin
if (~rst_n) begin
//reset condition
end
else if (enabled)
//Enabled condition
end
// no final else, everything will holds its value
end
Or may be as the enable for a latch :
//synopsys async_set_reset "rst_n"
always #* begin
if (~rst_n) begin
// Reset
end
else if (latch_open) begin
//next datavalue
end
end