Assume we have a D-flip-flop.
in RTL simulation (No t_hold and t_setup here), If its data input and clk changes at the same time, what the output should be ? The value before clk rise or the value after it ?
To make it even harder,
If a data_in and clock are connected to same wire. what should be the flop's output be ? zero all time ? or one all time ?
I tried the last case in ModelSim, and I get that the output is 1 all the time, while I expect it to be 0.
I expect that the flop in RTL-simulation should simulate the value before the clock edge.
When you use a simulation you will see results depend on how this case interpreted in the simulator what you use.
As you wrote in simulation t_setup = 0, it means that you don't need to keep signal in that level (what should be caught by flip flop) some time before rising (or falling) edge of clock signal, but can be applied exactly in the same time with the rising (or falling) edge of clock.
Because you see all time of the simulation '1' on the output of flip flop
Related
I am pretty new to Verilog
and I use it to verify some code from a simulation program.
Right now I am struggeling if a verilog code snippet because the simulation programm uses 2 clocks ( one system clock and a pll of this ) where two hardware componentes work together, thus synchronize each other:
module something (input data)
reg vid;
always #(posegde sys_clk)
vid <= data;
always #(posegde pll_clk)
if (vid)
// do something
When reading about non blocking assignments it says the evaluation of the left-hand side is postponed until other evaluations in the current time step are completed.
Intuitive I thought this means they are evaluated at the end of the time step, thus if data changes from 0 to 1 in sys_clk tick "A", this means at the end of "A" and the beginning of next sys_clk tick this value is in vid and so only after "A" the second always block ( of pll_clk) can read vid = 1
Is this how it works or did i miss something ?
Thank you :)
In this particular case it means that
if posedge sys_clk and pll_clk happen simultaneously then vid will not have a chance to update before it gets used in the pll_clk block. So, if vid was '0' before the clock edges (and is updated to '1' in the first block), it will still be '0' in the if statement of the second block. This sequence is guaranteed by use of the non-blocking assignment in the first block
if the posedges are not happening at the same time, then the value of vid will be updated at posedge sys_clk and picked up later at the following posedge of pll_clk.
In simulation non-blocking assignment guarantees that the assignment itself happens after all the blocks are evaluated in the current clock tick. It has nothing to do with the next clock cycle. However, the latter is often used in tutorials to illustrate a particular single-clock situation, creating confusion.
Also being simultaneous is a simulation abstraction, meaning that both edges happen in the same clock tick (or within a certain small time interval in hardware).
Consider the following SV code snippet:
module clocks();
logic a ;
bit clk =0;
initial begin
forever #1ns clk = ~clk ;
end
clocking cb#(posedge clk);
default input #1step output negedge;
output a;
endclocking
initial begin
#(cb);
#100ps;
cb.a <= 1 ;
#(cb);
#100ps;
cb.a <= 0 ;
repeat(10) #(cb);
end
endmodule
A signal changes after 100ps after the clocking block event through an output synchronous drive.
I observe a different behavior while running it with two EDA simulators.
With the first simulator, the clocking block output a acts on the second posedge, with the signal changing on the second falling edge. You can see the image below.
First simulator
On the other hand, with the second simulator, the clocking block output acts on the FIRST clock, and the effects can be seen on the first falling clock edge. You can see the image below.
Second simulator
If, on the other hand, I change the output skew delay, using a delay smaller (es 10ps) than the 100ps delay, the second simulator behaves as the first one ( the a signal changes after the second posedge with the the output skew of 10ps).
Which one of the two simulators is more compliant to the IEEE 1800-2017 SV standard ? In my opinion, according to my comprehension of the standard, the first simulator is more compliant.
The timescale is set to 1fs to avoid any issue related to simulator resolution.
The second simulator (with the unexpected negedge behavior) is VCS. I found the following information on Solvnet:
Enhanced Clocking Block Behavior When Skew is negedge/posedge By
default, VCS overrides the clocking event with the skew when the skew
is specified as posedge/negedge. However, you can use the
-ntb_opts no_cb_edge_override option to avoid overriding the clocking event at input, output, and inout. The following is the behavior of
this option at different clocking directions: • Input: Value is
sampled at the specified clocking skew delay before the clocking event
and the update happens at the clocking event. • Output: The output is
updated at the specified clocking skew delay after the clocking
event.1
Don't know why VCS has such behavior, but with the flag "-ntb_opts no_cb_edge_override" the simulation runs as in Questa.
Signal "ADDR" has a setup time constraint of 1ns with respect to the rising edge of signal "WR".
During every new clock cycle, I need to assign a value to "ADDR" and then make "WR" 0->1 after 1ns.
The clock cycle is 10ns. How do I do this in structural verilog?
There are many ways. I would use:
`timescale 1ns/1ps
...
assign #1.2 wr_out = wr; // (wr_out is a wire)
or
always #(wr)
wr_out <= #1.2 wr; // (wr_out is a reg)
The 1.2 is to have 200ps slack.
The first one is an inertial delay, which is more in line with how most real logic behaves. (If the signal change is faster then 1.2ns it is not seen. Like a signal that gets filtered out by a capacitor)
The two second one gives a 1.2ns transport delay no matter what the waveform of wr is. (Like a chain of gates delay where the pulse travels through)
I come from a world where we do NOT change the resulting gates but if you want to add delay to a gate it is very similar:
buf #(1.2,1.2) delaybuf (out,in);
You can add such a buffer with delay, alternative you have to find the last gate in the design which outputs the signal and add a delay there.
module syncrisedgedetect(input logic sig_a, rst,clk,output logic sig_a_risedge);
logic sig_a_d1;
always #(posedge clk or negedge rst)
begin
if(!rst)
sig_a_d1<=1'b0;
else
sig_a_d1<=sig_a;
end
assign sig_a_risedge=sig_a & !sig_a_d1;
endmodule
Hi, I came across this code in a book regarding rising edge detection for sig_a.
Can anybody explain me its working?
Thanks
This is a basic synchronous edge detection circuit.
The input, sig_a, is sampled on each rising edge of the clock, clk. The sampled value is registered; that is, sig_a_d1 is the value of sig_a delayed by one clock cycle.
The output will go to a 1 when there is a rising edge on the input. The assignment to sig_a_risedge is responsible for this. It says that "there was a rising edge on sig_a if the current value is 1 and the value on the previous clock cycle was 0".
Note that this will only work properly if the frequency of the input signal is lower than that of clock. If the input goes 0 -> 1 -> 0 all within a single clock period of the sampling clock, the edge may be missed.
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.