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.
Related
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.
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.
Wondering about the behavior of event control statements in an always block:
always #(posedge clk) begin: TEST
...
#(wait_for_signal_from_subsystem);
...
#(wait_for_another_signal_from_subsystem);
...
end
Will the process be "stuck" until the event signals come in, or will it restart every time a clk edge comes in ?
Also is this synthesizable (Quartus II says yes, but not simulated yet...) ? and is this a good practice or is there an alternative better approach to this problem ?
Yes, it is 'stuck' as you would say. Only one 'loop' of the block can be active at a time, it will not reenter if it has not completed the loop.
The thing you are trying to do there is likely not synthesizable, due to the wait operations inside the block.
I don't know the exact specifics of your design, but I would approach this with a small finite state machine. I assume that the signals from your subsystem are not faster than the clock, so it would look something like:
always #* begin
if(state_f == `WAIT_FOR_FIRST)
state_nxt = got_first_signal ? `WAIT_FOR_SECOND : `WAIT_FOR_FIRST;
else if(state_f == `WAIT_FOR_SECOND)
state_nxt = got_second_signal ? `DONE_STATE : `WAIT_FOR_SECOND;
else if(state_f == `DONE_STATE)
state_nxt = `WAIT_FOR_FIRST;
else
state_nxt = 2'bxx;
end
always #(posedge clk) begin
state_f <= state_nxt;
end
Assuming you are designing hardware and not non-synthesized testbench code, this not a good practice and likely won't do what you want anyways.
From a language perspective, this will compile and simulate. It will block waiting on the events within the always blocks and NOT restart on each posedge of the clock. I could not find a spec reference for this but it's what I observed in simulation. I'm curious what this would synthesize to if you even get it to synthesize with no errors.
If the signal from the other subsystem is already in the same clock domain (synchronous to clk), then you can just check the state of it on each clock edge, and use this do something.
always #(posedge clk) begin: TEST
if (the_other_signal == 1'b1) begin
...
end
end
Some other things to consider:
Maybe you only care about when the signal assert/deasserts. In that case you need to do an edge detection.
If the signal is asynchronous to clk, then you have a clock domain crossing and you need to synchronize the incoming signal before you look at it.
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
I have a CPLD with a digital input representing a reset button. When the reset button is pressed, the signal goes high. What I need to do is have a register whose value tells if the button has ever been pressed. Basically a latch. When the button goes high, a latch register goes high and stays high forever.
I thought this would be straightforward, but I got a bunch of warnings when I tried to code it up. A little Googling showed "Don't make latches in HDL! Bad practice!", but I don't really see the alternative here.
Here's my attempt. clk_10m is a fast free-running clock, pwr_off_req is the button input.
reg pwr_off_req_latched = 0;
always # (clk_10m or pwr_off_req) begin
if (pwr_off_req == 1'b1)
pwr_off_req_latched <= 1'b1;
else
pwr_off_req_latched <= pwr_off_req_latched;
// I tried this to make sure it's always set to something
end
Can you assume that the pulse length of the button press is much longer than the clock frequency of your device? If it's a physical button I think that is a very safe assumption. In that case I think this would work perfectly fine:
always #(clk_10m)
pwr_off_req_latched <= power_off_req_latched | power_off_req;
Latches are not bad in HDL they just require some consideration, implied latches from forgetting to specify else clauses in combinatorial sections are bad because you do not end up with the hardware you expect, and can create timing problems.
If you are applying a reset you might need to specify a 'pragma' so that the synthesis tool correctly identifies it.
Also latches should use = not <=, when they are enabled they are combinatorial (open) and will not break feedback loops.
This is typical way to create a latch with an asynchronous reset:
//synopsys async_set_reset "rst_an"
always #* begin
if (~rst_an) begin
// Reset
x = 1'b0;
end
else if (latch_open) begin
//next datavalue
x = y ;
end
end
In your case you might want something like :
//synopsys async_set_reset "rst_an"
always #* begin
if (~rst_an) begin
pwr_off_req_latched = 1'b0;
end
else if ( pwr_off_req ) begin
pwr_off_req_latched = 1'b1 ;
end
end
Latches can create problems for timing analysis tools. They also don't map to certain (FPGA) architectures directly, so are much harder for the place-and-route tools. Hence the warnings.
However, what you are asking for is not a latch as I understand the digital logic sense - merely a flipflop which doesn't ever get reset.
So, it can be simplified to a simple d-type flipflop with the D input tied to 1 and the clk input connected to your pwr_off_req signal:
reg pwr_off_req_latched = 0;
always # (posedge pwr_off_req) begin
pwr_off_req_latched <= 1'b1;
end
You'll have no noise rejection on that at all - any positive going edge will latch the flipflop to 1.
If I were doing this, I would run the input into a double-flip-flop synchroniser and then count a few clock pulses of the synchronised signal to make sure it's not noise before setting the latched signal. Unless you are expecting real events shorter than a few clock pulses that'd the way to do it.
Aside:
A "latch" in the digital logic world usually means either
a circuit whose output holds whichever of the two inputs was last high (a Set/Reset or SR latch)
a circuit whose output holds the input value while a control signal is inactive, but follows the input when the control signal is low - a transparent latch
This is in comparison to a flipflop, whose output holds some aspect related to the input(s) when the control signal changes (usually) from low to high, and ignores the inputs except for a tiny time window around that rising edge. These are D-type, T-type and JK-type flipflops, depending on how the output behaves relative to the input.