Can a posedge be detected on variables that aren't a clock?
For example I have a reset button R, which should reset the machine to the starting state whenever it is pressed.
always # (posedge clk, posedge R)
if(R)
reset_the_machine();
else
use_the_next_state();
You have two questions in your question:
can posegde in verilog be used only on clock?
The answer is no.
Can a posedge be detected on variables that aren't a clock?
The anser is yes.
There are no clocks in verilog language. Every signal is equal. Edges could be detected in simulation on any variable. Detection of edges itself is a simulation artifact.
Clock is only a modern hardware artifact. A verilog program reflects hardware behavior and therefore it needs to program clocks in a specific hardware-related way. But this is just a programming trick.
As for your example, see dave-59's answer.
The use of an edge on a signal like a set or reset is an artifact of the template pattern synthesis tools choose to represent asynchronous logic iin a single always block. If you didn't qualify R with posedge then the negative edge (negedge) of R would execute the use_next_state() branch. Thus simulation would be interpreting the release of reset as a posedge of clock.
When Verilog was first developed, the intent was to use separate always blocks for the synchronous and asynchronous behaviors using a procedural continuous assignment
always #(R)
if (R)
assign state = initial_state;
else
deassign state;
always #(posedge clk)
state <= next_state;
But today's synthesis tools no longer support this template probably because of confusion with the fully continuous assign statement.
Related
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.
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.
Let's say I have a code:
wire clk1;
wire clk2;
assign clk1 = Clk;
assign Clk2 = Clk;
Now clk1 and clk2 are used to clock various modules and traverse through the hierarchy of the design. Somewhere deep in the hierarchy, if a module is clocked by clk1, does it's output remain synchronous with another from module2?
e.g.
reg r1;
always # (posedge clk1)
r1 <= rSomething;
reg r2;
always # (posedge clk2)
r2 <= r1;
Is this code valid? Will the synthesis tools (Altera tool chain) maintain the skew across these two clocks? Or will it maintain the skew only on clocks that are named the same and clk1 and clk2 will cease to be synchronous despite their common source?
Thanks
EDIT1 : This for synthesis, not simulation.
EDIT2: Changed the second code example. I was trying to assign r2 <= r1, not the other way round as we the case earlier.
A synthesizer will transform your design input into an internal netlist that represents the logic structure. This is typically done in two stages. First to a high level behavioral form that represents abstract operations and then to a technology mapped form that directly implements logic primitives of the target architecture. In this transformation process clk1 and clkl2 will be seen as topologically equivalent to clk and they will be treated as one combined net.
The normal clock buffer insertion process will account for the skew across all leaf nodes in the unified net. Any timing constraints would need to be put on clk. An attempt to constrain clk1 and clk2 independently could have unpredictable results.
Renamed clocks remain synchronous. An explicit continuous assignment similar to passing a signal through a port where the connecting signal name and the port name are different.
However, no synthesis tool that I am aware of will let you make assignments to the same variable from multiple processes.
Let's take the example code below:
always #(posedge clock)
begin
if (reset == 1)
begin
something <= 0
end
end
Now let's say reset changes from 0 to 1 at the same time there's a posedge for the clock. Will something <= 0 at that point? Or will that happen the next time there's a posedge for the clock (assuming reset stays at 1)?
It depends on exactly how reset is driven.
If reset and something are both triggered off the same clock, then something will go to 0 one clock cycle after reset goes to 1. For example:
always #(posedge clock)
begin
if (somethingelse)
begin
reset <= 1;
end
end
If reset is synchronous and based on clock, The simulatore will defiantly see reset on the next clock and not the current. Physical design has clock-to-Q, therefor a rise in reset will not be observed in the same clock that caused it. You may see reset at the same time as clock in waveform. reset <= 1'b1; make the assignment happen near the end of the scheduler (after all code has executed).
To not have to worry about this when looking at a waveform, some logic designers like to put a delay on the assignment creating an artificial clock-to-Q delay (ex reset <= #1 1'b1; and something <=#1 0;). Synthesis tools will ignore the delay, but some will give warnings. That warning can be avoided by using a macro.
`ifdef SYNTHESIS
`define Q /* blank */
`else
`define Q #1
`endif
...
reset <= `Q 1'b1;
...
something <=`Q 1'b1;
...
If reset is asynchronous and being use with synchronous reset, setup time requirements need to be respected. In simulation if clock and reset rise at the same time, it is up to your verilog scheduler to decide if reset will be the new value or old value. Usually it will take the left-hand side value (old value), which means the reset will be missed on the current clock. Physical design uncertainly as well with a meta-stability risk.
The code you have written infers a flip-flop with synchronous reset. This means it is assumed that the "reset" signal is synchronised to the "clock" domain before being used in this way. If the "reset" signal is not synchronised then you should modify the code to infer a flip-flop with asynchronous reset as below:
always#(posedge clock or posedge reset)
begin
if (reset)
something <= 0
else
something <= something_else
end
Coming back to your question and assuming the code you have written is what you want, the outcome depends on how the reset is driven. If it is synchronous then the simulator will see it in the next clock edge. If it is asynchronous then the simulator can assume anything, it can vary from simulator to simulator. Please note that in simulator everything is a sequence of events and there is no such thing as happening at the same time.
In the physical world, what you have coded will result in a flip-flop with reset signal being one of the inputs to the combo driving the input of this flop. Now if the reset is synchronous, you are guaranteed that there will be no setup or hold violation at this flop. Whether the flop will 'see' the reset in this clock or the next depends on the various delays of the synthesised circuit (Usually this is the main reason that the reset is always held for few clock cycles to make sure all the flops in your design sees the reset). If reset is asynchronous then the flop will go into a metastable state. You will never want this in your design.
Hope this clarifies.
The short answer is that either of your two outcomes (immediately, or next cycle) could happen. This is a standard race condition, and simulators are free to handle this any way they want; some will give one answer, and others will give the other one.
For the long answer, look up any introductory text on how VHDL delta cycles work. Verilog doesn't specify 'delta cycles', but any Verilog simulator will work in exactly the same way, with some (irrelevant) changes in the overall scheduling algorithm. In this case, the scheduler finds that it has two events on the queue in a specific delta - reset rising, and clock rising. This is what "at the same time" means. It chooses one in an unspecified way (it might be earlier in the text source, or later, for example), works through all changes associated with that edge, and then goes back and works through all changes associated with the other edge.
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.