I am trying to implement a 32-bit divider in Verilog and I am having issues. A and B are the numbers to be divided. Here is my code so far. The output of the testbench is:
What am I doing wrong? Also, what does it mean when the output is both Hi and Low at the same time? This is being implemented in EDAPlayground:
Design and Testbench
Unsure if this is your only problem, but you are casing on nextstate in your combinational logic block in the control path. You should be casing on state (ie, it should not be case (nextstate) but case (state))
You should also not be setting load, run, err and ok in both the always #(posedge clk or negedge reset) register block and the always #(*) combinational block in the control path, they should only be assigned from the combinational block.
Related
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.
I am a Verilog newbie and I am trying to implement some very simple logic to generates a pulse of a precise width. I am using an ICE40 FPGA dev board and IceStudio. I have a CLK signal with a period of ~83ns (12Mhz), and I want to generate pulses with a period of ~1245ns, but different lengths (i.e. a high time of ~415ns and a low time of ~830ns, for example).
I figured that I could do so by making a rotating shift register of 15 bits long and then toggle my output HIGH the rising edge of the first bit, then toggle it LOW on the falling edge of the fifth bit. Here is the code I came up with:
reg [14:0] shifter;
reg OUT;
initial begin
shifter <= 15'b01;
end
always #(posedge CLK) begin
shifter <= shifter << 1;
shifter[0] <= shifter[14];
end
always #(posedge shifter[0]) begin
OUT <= 1;
end
always #(negedge shifter[4]) begin
OUT <= 0;
end
If I assign the individual bits of "shifter" to an output, I am able to verify on a scope that that shift register is working as expected; but despite this, the OUT remains LOW as if the "always" blocks were never triggering.
Every tutorial I found online that discusses the "always #(posegde)" or "always #(negegde)" blocks do it on some external signal like CLK or RESET. I am wondering I am committing some sort of rookie mistake by assuming it could also work on an internal register variable like "shifter".
Can anyone explain to me whether this is the case or not?
UPDATE: The following code does what I want, but still curious why my original implementation doesn't work:
reg [14:0] shifter;
reg OUT;
initial begin
shifter <= 15'b01;
end
always #(posedge CLK) begin
shifter <= shifter << 1;
shifter[0] <= shifter[14];
OUT <= shifter[0] | shifter[1] | shifter[2] | shifter[3] | shifter[4] | shifter[5];
end
When making a register out of NAND gates, a rising edge triggered flip-flop takes less area, so that is what most people use.
Synthesis tools do not allow you to make assignments to the same variable from different (always) processes.
It is possible to declare a sensitivity on the edge of a register signal, but this should be avoided in FPGA workflows. Most FPGAs use separate routing networks for clock signals and logic, so "bridging" a logic signal to a clock network is complex and will result in a suboptimal design with poor timing properties. In some cases, there may even be limits on the number of signals that can be bridged this way.
It is generally not possible to perform nonblocking assignments to a register from multiple separate edge-triggered always blocks. This implies a register with multiple clock inputs, which isn't a component which exists in most FPGAs or ASIC cell libraries.
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.
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.