I have the following Code:
`timescale 1ps / 1ps
module tb;
localparam t_CLOCK_PERIOD = 1000;
bit clk;
bit clk_del;
always #(t_CLOCK_PERIOD/2) clk = ~clk;
assign #490 clk_del = clk;// clk_del toggling normally
//assign #510 clk_del = clk;// clk_del not toggling
initial begin
clk =1'b1;
$display("waiting for Clock delayed");
#(posedge clk_del);
$display("Clock delayed");
$finish;
end
endmodule
I am trying to delay a clock signal, but when I do that by more of half a period, the signal stays unassigned (it does not toggle).
What am I doing wrong? How can I delay this signal more that the half period?
Your clk_del assign statement does not work with the 510 delay because the RHS (clk) changes more quickly than the delay. It is like you are always sampling clk when it is 0. The assign statement is confusing, and it is not the proper way to generate two related clock signals.
You can control the phase relationship between the 2 clocks by using an initial delay for the delayed clock. This approach is more conventional and is easier to understand:
always #(t_CLOCK_PERIOD/2) clk = ~clk;
initial begin
clk_del = 1;
#10;
forever #(t_CLOCK_PERIOD/2) clk_del = ~clk_del;
end
By varying the initial value of clk_del and the initial delay value, you can achieve any phase relationship you want.
The issue is related to clk changing before the assignment delay as toolic points out.
This problem is independent of clock signal and can be faced on data signals too. A detailed explanation of the delays usage in verilog can be found here.
The proper solution to my problem was to change
assign #510 clk_del = clk;
to
always #(clk) clk_del <= #510 clk;
Related
`timescale 1 ns/1 ns
module VIT_ENC (Vx,Ux,tb_en,clock,reset);
`include "params_b213.v"
output [`n-1:0] Vx;
input [`k-1:0] Ux;
input tb_en;
input clock;
input reset;
reg [`m:0] encoder_reg;
always #(posedge clock or posedge reset)
begin
if(reset)
encoder_reg = 4'b0;
if (tb_en==1'b0)
encoder_reg = {Ux, encoder_reg[3:1]};
end
assign Vx[1] = encoder_reg[3]^encoder_reg[1]^encoder_reg[0];
assign Vx[0] = encoder_reg[3]^encoder_reg[2]^encoder_reg[1]^encoder_reg[0];
endmodule
The always block does not work for some reason. The encoder_reg is not getting any values. How to assign values to a reg in an always block?
EDIT: I am adding the test bench code also here. So we are giving some input to Ux, which has to get shifted and stored in encoder_reg. Modulo 2 addition(XOR) is performed between the bits of encoder_reg and stored in the output.
`timescale 1 ns/1 ns
module tb_VIT_ENC();
`include "params_b213.v"
wire [`n-1:0] Vx;
reg [`k-1:0] Ux;
reg tb_en;
reg clock;
reg reset;
VIT_ENC
dut(.Vx(Vx),.Ux(Ux),.tb_en(tb_en),.clock(clock),.reset(reset));
initial
begin
Ux=1;tb_en=0;clock=1;reset=0;
#100;
Ux=0;tb_en=0;clock=1;reset=0;
#100;
Ux=1;tb_en=0;clock=1;reset=0;
#100;
Ux=0;tb_en=0;clock=1;reset=0;
end
endmodule
I can see that there is no clock signal generation in the test bench. Without a positive edge on the clock signal the registers are'nt going to work. You could use the following initial block in your test bench, instead of driving clock = 1 every 100ns as written in your test bench.
initial
begin
clock = 1'b1;
forever #5 clock = ~clock; //Clock Generator
end
The initial block sets clock to 1 initially. The next line toggles the clock after 5ns and sets clock to 0. The forever keyword ensures the clock toggles every 5 time units forever till the end of the simulation, thus generating a square wave of period 10 time units. (Given the timescale in your code 10 time units = 10 ns)
All my testbench is trying to do is verify whether or not the LED signal went high, but on Modelsim when I try and simulate it, the clock doesn't even start, but it initializes to zero. I can also step through my design so I don't appear to have an infinite loop or anything like that. Is there anything obviously wrong here, especially with regards to clock initialization and generation?
`timescale 1ns/100ps
module fir_filter_tb();
reg clk, reset_n;
reg led;
top top_level (
.clk(clk),
.reset_n(reset_n),
.led(led)
);
initial
begin
$display($time, " << Starting the Simulation >>");
clk = 1'b0; // at time 0
reset_n = 0; // reset is active
led = 0; // output is low
#10 reset_n = 1'b1; // at time 20 release reset
end
always #10 clk = ~clk;
always
begin
if (led == 1'b1) begin
$write($time, "Filter Successful");
end else begin
$write($time, "bleh you suck");
end
end
endmodule : fir_filter_tb
The problem is with the always block with led in it. Since there is no timing control, it prevents time from advancing (time remains stuck at 0). It creates an infinite zero-time loop.
One way to fix it is to use:
always #*
This will only trigger the block when led changes.
I have an ice40 that drives the clock and data inputs of an ASIC.
The ice40 drives the ASIC's clock with the same clock that drives the ice40's internal logic. The problem is that the rising clock triggers the ice40's internal logic and changes the ice40's data outputs a few nanoseconds before the rising clock reaches the ASIC, and therefore the ASIC observes the wrong data at its rising clock.
I've solved this issue by using an inverter chain to delay the ice40's internal clock without delaying the clock driving the ASIC. That way, the rising clock reaches the ASIC before the ice40's data outputs change. But that raises a few questions:
Is my strategy -- using an inverter chain to delay the ice40 internal clock -- a good strategy?
To diagnose the problem, I used Lattice's iCEcube2 to analyze the min/max delays between the internal clock and output pins:
Notice that the asic_dataX delays are shorter than the clk_out delay, indicating the problem.
Is there a way to get this information from yosys/nextpnr?
Thank you for any insight!
Instead of tinkering with the delays I would recommend to use established techniques. For example SPI simple clocks the data on the one edge and changes them on the other: .
The logic to implement that is rather simple. Here an example implementation for an SPI slave:
module SPI_slave #(parameter WIDTH = 6'd16, parameter phase = 1'b0,
parameter polarity = 1'b0, parameter bits = 5) (
input wire rst,
input wire CS,
input wire SCLK,
input wire MOSI,
output reg MISO,
output wire data_avbl,
input wire [WIDTH-1:0] data_tx,
output reg [WIDTH-1:0] data_rx
);
reg [bits:0] bitcount;
reg [WIDTH-1:0] buf_send;
assign clk = phase ^ polarity ^ SCLK;
assign int_rst = rst | CS;
assign tx_clk = clk | CS;
assign data_avbl = bitcount == 0;
always #(negedge tx_clk or posedge rst) begin
MISO <= rst ? 1'b0 : buf_send[WIDTH-1];
end
always #(posedge clk or posedge int_rst) begin
if (int_rst) begin
bitcount <= WIDTH;
data_rx <= 0;
buf_send <= 0;
end else begin
bitcount <= (data_avbl ? WIDTH : bitcount) - 1'b1;
data_rx <= { data_rx[WIDTH-2:0], MOSI };
buf_send <= bitcount == 1 ? data_tx[WIDTH-1:0] : { buf_send[WIDTH-2:0], 1'b0};
end
end
endmodule
As one can see the data are captured at the positive edge and changed on the negative edge. If one wants to avoid the mixing of edge sensistivies a doubled clock can be used instead.
i want to shift a signal by fixed number of clock cycles. I receive the signal from adc. kindly let me know how to implement this
HINT: Not a full answer
A 8 bit flip-flop in verilog might look like:
reg [7:0] a;
always #(posedge clk, negedge rst_n) begin
if (~rst_n) begin
// Active Low Reset condition
a <= 'b0;
end
else begin
a <= input_eight_bit;
end
end
To delay for multiple clock cycles you need multiple flip-flops feeding from one to the next. This creates a pipe line or delay line.
I am currently teaching myself Verilog and going through a few tutorials that I found and two things that kind of confuse me are how to specifically calculate how much time you need to delay after changing the inputs to a combinatorial circuit, and in what order items get executed in your code. I understand generally that real circuits have rise/fall delay times and that you want to delay your outputs so that your inputs generate a value before you calculate your outputs, but I want to know specifics.
So, here's an example:
module dflipflop (d,clk,reset,q);
input d, clk, reset;
output q;
reg q;
always # (posedge clk or posedge reset) begin
if (reset) begin
q <= 0;
else begin
q <= #2 d; //why did I need to delay this 2 time units?
end
end
end module
module main;
reg d, clk, rst;
wire q;
dflipflop dff(d,clk,rst,q);
inital begin
forever begin
clk = 0;
#5
clk = 1;
#5
clk = 0; //why do I need to reset the clk to 0 if this is a forever block and my first assignment is clk = 0 in the beginning?
end
end
initial begin
d=0; rst=1;
#4 //why #4? How did they calculate that?
d=1; rst=0;
#50
d=1; rst=1;
#20
d=0; rst=0;
end
end module
Some of my questions are embedded in comments in the code. However, my other confusion is with timing. In the beginning of the main module, I instantiate a dflipflop module called dff with my parameters that I defined in main above. Where in my code does it say: rebuild the module/recalculate the Q when I change the inputs in main? I don't see the link.
On your specific questions:
//why did I need to delay this 2 time units?
You don't. Adding a transport delay to the clock branch and not the reset branch makes little or no sense.
//why do I need to reset the clk to 0 if this is a forever block and my first assignment is clk = 0 in the beginning?
You don't; the model is flawed. Remove the first clk=0, or move it above the forever.
//why #4? How did they calculate that?
No idea - it's just an arbitrary delay in your stimulus generation. It doesn't matter, as long as it's 'long enough'.
General points:
You don't care about specifying delays when writing HDL code; this
is almost always a job for the tools. Your tools will work out real
silicon delays and back-annotate them into your code using sdf,
specify blocks, and so on. If you want details, look at the
simulation model output by your synth or place-and-route tools.
As long as you're careful about your use of blocking and non-blocking assignments then your code will 'work', even though you haven't explicitly put delays into it. 'Working' means that the outputs change in the correct order to preserve your required functionality.
I think you may be confused in your understanding of 'rise/fall delays' and 'delaying outputs'. In general, at the HDL level, you're never concerned with signal rise or fall times; everything happens at a threshold voltage. An input changes at time x, and dependent outputs change at some later time. This is a propagation delay. For clocked circuits, the prop delay will depend on whether the output goes to 0 or goes to 1, which leads to unfortunate terminology involving 'rise delay' or 'fall delay' (actually propagation delay to 1, or to 0). You don't "delay your outputs so that your inputs generate a value before you calculate your outputs". Except in exceptional circumstances, you calculate your outputs immediately, and then specify how long it takes the outputs to actually propagate to the pins of your model.
If your dflipflop module will be synthesized, there should not be a #2 delay. Sometimes people add these delays because they are simulating with a mix of different coding styles: behavioral and structural. Sometimes the structural code has delays which make your behavioral code behave incorrectly.
Perhaps this is what was intended:
inital begin
clk = 0;
forever begin
#5
clk = 1;
#5
clk = 0;
end
end
Perhaps the #4 was used to release the rst just before the 1st clk edge at time=5.
q <= #2 d; This is the clock-to-q delay. The number is most likely arbitrary, but it could be coming from characterization of a specif flip-flop design. Many designers put a small delay on the clock-to-q to make the looking a waveforms easier. Normally you want this number very small and almost always less then the clock period.
for your clock generator, the extra clock = 0 doesn't matter as long as there is a semicolon. Most likely this is the coding style designer liked to use. Both of the following are equivalent to your clock, just written differently:
always begin
clk = 0;
#5;
clk = 1;
#5;
end
// or
initial begin
clk = 0;
forever #5 clk = !clk;
end
The #4 is because the designer wanted the test to end the reset on the design before the first clock (# #5). This also gives all the following delays (which are multiples of the clock period of #10) and #1 setup time.
your dflipflip will only react if there is a posedge clk or posedge reset. if reset is high, then q will be assigned to 0. If reset and the positive edge of clk is detected, then d will be sampled and #2 latter assign the sampled value to q.
Here is a step buy step on what is happening:
initial begin
d=0; rst=1; /* simulation time #0, rst goes 1'bx->1'b1 (posedge) therefore q goes 1'bx->1'b0 */
#4
d=1; rst=0; /*
simulation time #4, rst goes low, sill no posedge clk therefore dflipflop does nothing
simulation time #5 first posedge clk therefore sample d (1)
simulation time #7 q is assigned to 1 (sampled d)
simulation time #15 posedge clk therefore sample d (1) again
simulation time #17 q is assigned to 1 (sampled d) again
... repeat pattern ...
simulation time #45 posedge clk therefore sample d (1) again
simulation time #47 q is assigned to 1 (sampled d) again */
#50
d=1; rst=1; /*
simulation time #54, rst goes high therefore assign q to 0
simulation time #55 posedge clk, rst==1 therefore assign q to 0
simulation time #65 posedge clk, rst==1 therefore assign q to 0 */
#20
d=0; rst=0; /*
simulation time #74, rst goes low therefore no change
simulation time #74, initial block ends */
end