I need to add a synthesizable delay in my code to get an output. My code is:
module square_wave(clk,rst,dac_out);
input clk;
input rst;
output reg dac_out;
reg [3:0] counter; //
always #(posedge clk)
begin
if (rst == 1'b1 || counter == 4'b1111) // period, count from 0 to n-1
counter <= 0;
else
counter <= counter + 1'b1;
if (rst == 1'b0 && counter < 4'b0110) // duty cycle, m cycles high
dac_out = 1'b1;
else
dac_out = 1'b0;
end
endmodule
This gives me an output where 6 out of the 15 times of the initial clock cycle, it will be 1, and otherwise 0. So far, it is good. But the other signal I need, TG, needs to be kinda twice of this signal. Meaning in 15 cycles, it should be 1 2 times.
So, what I need to do is delay my output signal by 6 or 7 or 8 times the original clock cycle so that I get a delayed signal, which I can then add to my original output to get what I need. Please refer to the image attached. I am unable to figure out the synthesizable delay. Any help will be appreciated. Thanks.
Please look at this pic to help
You can use a shift register to delay your output the required number of cycles. Then OR the original output with the delayed output
module square_wave(
input clk, rst,
output regdac_out,
output TG);
reg [3:0] counter;
reg [7:0] shifter;
always #(posedge clk)
if (rst == 1'b1 || counter == 4'b1111) // period, count from 0 to n-1
counter <= 0;
else begin
counter <= counter + 1'b1;
shifter <= {shifter, dac_out};
if (rst == 1'b0 && counter < 4'b0110) // duty cycle, m cycles high
dac_out <= 1'b1;
else
dac_out <= 1'b0;
end
assign TG = dac_out || shifter[7];
endmodule
If that's not what you want, you need to give us a much better idea of what the waveform looks like. You picture does not help.
You may add delays by instantiating a delay buffer from the standard cell library if you want custom delays (i.e. delay != N(1/clk)). But please note that you may have to add dont_touch option while synthesizing because the tool may optimize the delay buffer since there is no logic in the data path of the buffer (capacitors are used to delay the signal).
Or you may use D-Flops shown below to delay (here delay value = N(1/clk))your signal.
always#(posedge clk)
begin
data1_d1 <= data1; //Delay data1 by one clock (clk)
data1_d2 <= data1_d1; //Delay data1 by two clocks (clk)
end
Related
I implemented a very simple counter with preset functionality (code reproduced below).
module counter
#(
parameter mod = 4
) (
input wire clk,
input wire rst,
input wire pst,
input wire en,
input wire [mod - 1:0] data,
output reg [mod - 1:0] out,
output reg rco
);
parameter max = (2 ** mod) - 1;
always #* begin
if(out == max) begin
rco = 1;
end else begin
rco = 0;
end
end
always #(posedge clk) begin
if(rst) begin
out <= 0;
end else if(pst) begin
out <= data;
end else if(en) begin
out <= out + 1;
end else begin
out <= out;
end
end
endmodule
I am having trouble understanding the following simulation result. With pst asserted and data set to 7 on a rising clock edge, the counter's out is set to data, as expected (first image below. out is the last signal, data is the signal just above, and above that is pst.). On the next rising edge, I kept preset asserted and set data to 0. However, out does not follow data this time. What is the cause of this behavior?
My thoughts
On the rising clock edge where I set data to 0, I notice that out stays at 7, and doesn't increment to 8. So I believe that the counter is presetting, but with the value 7, not 0. If I move the data transition from 7 to 0 up in time, out gets set to 0 as expected (image below). Am I encountering a race condition?
Testbenches
My initial testbench code that produced the first image is reproduced below. I show the changes I made to get coherent results as comments.
parameter mod = 4;
// ...
reg pst;
reg [mod - 1:0] data;
// ...
#(posedge clk); // ==> #(negedge clk)
data = 7;
pst = 1;
#(posedge clk); // ==> #(negedge clk)
data 0;
pst = 1;
#(posedge clk); // ==> #(negedge clk)
pst = 0;
#(posedge clk);
// ...
You have a race condition test bench. The Verilog scheduler is allowed to evaluate any # triggered in the time step in any order it chooses. All code after the granted # will execute until it hits another time blocking statement. In your waveform it looks like data and pst from the from the test bench are sometimes being assigned before the design samples them and sometimes after.
The solution is simple, use non-blocking assignments (<=). Refer to What is the difference between = and <= in Verilog?
#(posedge clk);
data <= 7;
pst <= 1;
#(posedge clk);
data <= 0;
pst <= 1;
#(posedge clk);
pst <= 0;
#(posedge clk);
I am able to obtain correct, predictable behavior if I modify my testbench to only modify input signals to my counter on falling clock edges rather than on rising clock edges (as it should be anyways). My best guess as to why the above behavior was occurring is that changing input signals at the same time the counter module is programmed to sample its inputs leads to undefined simulator behavior.
I was wondering if someone may be able to help me? I was not sure how to word the question, but I am basically trying to write a program that generates a square wave output signal from a square wave input signal, matching the duty cycle and frequency of the input signal. Basically, the output just copies the input. To summarize what I am saying graphically, here is a picture I made:
Link to diagram
It is not my final goal, but it would be enough to get me going. I am having a very hard time figuring out how to work with inputs. I have a signal generator making the input square wave signal, and am sending it into an input pin. I've tried calculating the duty cycle mathematically, and then just trying to assign the output to a reg that is set equal to the input on every rising edge of the clock signal but it didn't work.
Here's my code. It has extra functionality of generating a 1 Hz signal, but that is only from learning earlier how to create the pwm. You can ignore "pwm_reg" and the "pwm" output. The "pwm2" output is intended to copy "apwm" input:
`timescale 1ns / 1ps
module duty_cycle_gen(
input clk,
input rst_n,
input apwm,
output pwm,
output pwm2
);
// Input clock is 250MHz
localparam CLOCK_FREQUENCY = 250000000;
// Counter for toggling of clock
integer counter = 0;
reg pwm_reg = 0;
assign pwm = pwm_reg;
reg apwm_val;
always #(posedge clk) begin
if (!rst_n) begin
counter <= 8'h00;
pwm_reg <= 1'b0;
end
else begin
apwm_val <= apwm;
// If counter is zero, toggle pwm_reg
if (counter == 8'h00) begin
pwm_reg <= ~pwm_reg;
// Generate 1Hz Frequency
counter <= CLOCK_FREQUENCY/2 - 1;
end
// Else count down
else
counter <= counter - 1;
end
$display("counter : %d", counter);
end
assign pwm2 = apwm_val;
endmodule
Here is a simple example with a test bench. (I like to use a small delay when assigning, #1, to help capture causality for debugging purposes):
module example(
input wire clk,
input wire in,
output reg out);
always #(posedge clk)
begin
out <= #1 in;
end
endmodule // example
module example_test();
reg chip__clk;
reg chip__in;
wire chip__out;
reg [10:0] count;
example ex(
chip__clk,
chip__in,
chip__out);
initial
begin
$dumpvars();
count <= #1 0;
end
always #(count)
begin
count <= #1 (count + 1);
if (count == 1000)
begin
$display("RESULT=PASS:0 # done");
$finish_and_return(0);
end
if ((count == 60) & (chip__out != 1))
begin
$display("RESULT=FAIL:1 # chip.out not raised");
$finish_and_return(1);
end
if ((count == 30) & (chip__out != 0))
begin
$display("RESULT=FAIL:1 # chip.out not lowered");
$finish_and_return(1);
end
chip__in <= #1 count[5];
chip__clk <= #1 count[1];
end
endmodule // example_test
It works by treating the in signal as something that can can be thought of as constant over the timescale of the higher frequency clk.
If your in clock is an external signal which might be noisy, with the small latency delay, you can attempt to stabilize it by using a small fifo running with the high frequency clk:
module example(
input wire clk,
input wire in,
output reg out);
reg [1:0] buffer;
always #(posedge clk)
begin
out <= #1 buffer[1];
buffer[1] <= #1 buffer[0];
buffer[0] <= #1 in;
end
endmodule // example
I have a question about using timers and clocks in Verilog. I want to set up a custom reg to compare to an accumulator, which will control the state of an LED. The board uses inverse logic, so 0 is high on the LED. There are a few concepts I just need some clarification on. The clock is 100 MHz.
always #(posedge clk100 or negedge reset_)
begin
cust_LED_counter <= (cust_LED_counter<cust_LED_timer) ? cust_LED_counter + 1'b1 : 16'd0;
cust_LED_timer1 <= (cust_LED_counter == cust_LED_timer);
if(!reset_)
begin
cust_LED1 <= 'b0;
cust_LED_timer <= 'd0;
cust_LED_timer1 <= 'd0;
end
else
begin
cust_LED1 <= ~cust_LED_timer1;
end
end
For the accumulator, what is the action that resets it and allows for blinking to happen? Would it not hit the cust_LED_timer value and stay at that high reading?
I think I'm misunderstanding how a FPGA clock operates. Assuming this would cause a blinking action in the LED, it would mean some timer hit the upper limit and reset; however, I'm not sure if this would take place in the counter portion of the code, or instead would occur where the clock/reset is defined.
Also, based on how this layout looks it wouldn't be a uniform blink, in terms of equal time on and off. Is there a way to implement such a system for custom input?
Here's a simple module that should blink the LED with a 50-50 duty cycle for an arbitrary number of clocks (up to 2^26)
module blink(input clk, input rst, input [25:0] count_max, output LED);
reg [25:0] counter, next_count;
assign LED = counter < count_max >> 1;
always #(posedge clk or posedge rst)
begin
if (rst)
counter <= 0;
else
counter <= next_count;
end
always #* begin
if (counter < count_max - 1)
next_count = counter + 1;
else
next_count = 0;
end
endmodule // blink
Let me know if this doesn't compile! I don't have a verilog compiler where I'm writing this from at the moment!
I am asked to design simple clock divider circuit for different types of inputs.
I have a enabler [1:0] input and an input clock, and an output named clk_enable.
If enabler=01 then my input clock should be enabled once in 2 clock signals.If enabler=10 then my input should be divided by 4 etc.
I managed to divide my input clock for different cases with using case keyword but for enabler=00 my input clock should be equal to my output clk_enable which i could not manage to do it.
Here is what i tried. I am asking a help for the enabler=00 situation.
module project(input [1:0] enabler,
input clock,
output reg clk_enable);
reg [3:0] count,c;
initial begin
count=4'b0000;
c=4'b0000;
end
always #( posedge clock)
case(enabler)
2'b00:clk_enable<=clock;
2'b01:clk_enable<=~clk_enable;
2'b10:begin
if (count >= 4'b0100-1)
count<=4'b0000;
else begin
count<=count + 4'b0001;
clk_enable<=(count<(4'b0100 / 2));
end
end
2'b11: begin
if (count >= 4'b1000-1)
count<=4'b0000;
else begin
count<=count + 4'b0001;
clk_enable<=(count<(4'b1000 / 2));
end
end
endcase
endmodule
This will generate gated pulsed clock with posedge rate matching the div_ratio input.
div_ratio output
0 div1 clock (clk as it is)
1 div2 (pulse every 2 pulses of clk)
2 div3
3 div4
This is usually preferable when sampling at negedge of divided clock is not needed
If you need 50% duty cycle I can give you another snippet
module clk_div_gated (
input [1:0] div_ratio,
input clk,
input rst_n, // async reset - a must for clock divider
output clk_div
);
reg [1:0] cnt;
reg clk_en;
always #(posedge clk or negedge rst_n)
if (~rst_n)
cnt <= 2'h0;
else
cnt <= (cnt == div_ratio)? 2'h0 : cnt + 1'b1;
// clk_en toggled at negedge to prevent glitches on output clock
// This is ok for FPGA, synthesizeable ASIC design must use latch + AND method
always #(negedge clk)
clk_en <= (cnt == div_ratio);
assign clk_div <= clk & clk_en;
endmodule
This looks like you have a strong background in software development? :)
My suggestion is that you always make a clean cut between combinational and sequential logic. This includes some thoughts on what part of the design actually has to be sequential and what can be combinational.
For your case, the clock division clearly has to be sequential, since you want to invert the generated CLK signal (frequency f/2, case 0'b01) at each positive edge of the incoming CLK signal (frequency f, case 0'b00). Same is valid for f/4 (case 0'b10).
This part needs to be sequential, since you want to invert the previous CLK state...this would cause a cmobinational loop if realized in combinational logic. So triggering on a CLK edge is really necessary here.
However, the actual selection of the correct CLK output signal can be combinational. You just want to assign the correct CLK signal to the output CLK.
An implementation of the sequential part could look like:
// frequency division from input CLK --> frequency: f/2
always #(posedge clk or negedge rst_neg) begin
if (rst_neg = 1'b0) begin
clk_2 <= 1'b0;
end else begin
clk_2 <= ~clk_2;
end
end
// frequency division from first divided CLK --> frequency: f/4
always #(posedge clk_2 or negedge rst_neg) begin
if (rst_neg = 1'b0) begin
clk_ 4 <= 1'b0;
end else begin
clk_4 <= ~clk_4;
end
end
// frequency division from first divided CLK --> frequency: f/8
always #(posedge clk_4 or negedge rst_neg) begin
if (rst_neg = 1'b0) begin
clk_ 8 <= 1'b0;
end else begin
clk_8 <= ~clk_8;
end
end
So this plain sequential logic takes care of generating the divided CLK signals of f/2 and f/4 that you need. I also included reset signals on negative edge, which you usually need. And you spare the counter logic (increments and comparison).
Now we take care of the correct selection with plain combinational logic:
always #(*) begin
case(enabler)
2'b00: clk_enable = clk;
2'b01: clk_enable = clk_2;
2'b10: clk_enable = clk_4;
2'b11: clk_enable = clk_8;
endcase
end
This is quite close to your hardware description (clk_enable needs to be a reg here).
However, another way for the combinational part would be the following (declare clk_enable as wire):
assign clk_enable = (enabler == 2'b00) ? clk
: (enabler == 2'b01) ? clk_2
: (enabler == 2'b10) ? clk_4
: (enabler == 2'b11) ? clk_8;
I'm trying to make a second counter and millisecond counter using Verilog. The Problem is that whenever I run a simulation, the value of the second counter (clk_1sec) and millisecond counter (clk_1msec) is fixed to 0.
My Simulation shows proper result until 19th line of the code, but the simulation doesn't show the proper result of clk_1sec and clk_1msec (value of those two counters are fixed to 0)
module clk_gen(clk_5k, reset, loopcount, clk_1sec, clk_1msec);
input clk_5k, reset;
output [14:0] loopcount;
output clk_1sec, clk_1msec;
reg [14:0] loopcount;
reg clk_1sec, clk_1msec;
always #(posedge clk_5k or negedge reset)
begin
if (~reset)
begin
clk_1sec <= 0; clk_1msec <= 0; loopcount <= 0;
end
else
loopcount <= loopcount + 2'b10;
begin
if (loopcount += 13'b1001110001000)
clk_1sec = ~clk_1sec;
else if (loopcount += 3'b101)
clk_1msec = ~clk_1msec;
end
end
end
end
endmodule
Expected result is that clk_1sec should change its value when the value of loopcount is loopcount + 5000 (decimal) and clk_1msec should change its value when the value of loopcount is loopcount + 5 (decimal).
There are some misunderstandings in your code:
You are using blocking assignments inside clocked always. You should use only non blocking assignments.
You are using 13 bit constants to operate with a 15 bit register (loopcount). You should use 15 bit constants.
And above all, you are using an improper way to tell if the value of loopcount is multiple of 5 (to count miliseconds). Multiples of something that is not a power of two is difficult to implement in hardware. Either you should use a power of two clock signal (32.768 kHz is a common clock for these applications) or you should use a counter to count cycles to get miliseconds and another one to count miliseconds to get one second.
Assuming a 32.768 kHz clock, your module would go like this:
module clk_gen (
input wire clk32768,
input wire reset,
output reg [15:0] loopcount,
output wire clk_1sec,
output wire clk_1msec
);
assign clk_1sec = loopcount[15]; // 1 exact second (32768 counts)
assign clk_1msec = loopcount[5]; // not quite 1ms, but 0.97ms
always #(posedge clk32768 or negedge reset) begin
if (~reset)
loopcount <= 16'd0;
else
loopcount <= loopcount + 16'd1;
end
endmodule
If you need to stick with a 5KHz clock and/or need precise milisecond measurement (within the limits of your clock oscillator), then you can do as this:
module clk_gen (
input wire clk_5k,
input wire reset,
output reg clk_1sec,
output reg clk_1msec
);
reg [2:0] counter_cycles; // counts from 0 to 4 cycles => 1ms
reg [9:0] counter_msecs; // counts from 0 to 999 msecons => 1s
always #(posedge clk_5k or negedge reset) begin
if (~reset) begin
clk_1sec <= 1'b0;
clk_1msec <= 1'b0;
counter_cycles <= 3'd0;
counter_msecs <= 10'd0;
end
else begin
if (counter_cycles == 3'd4) begin
counter_cycles <= 3'd0;
clk_1msec <= ~clk_1msec;
if (counter_msecs == 10'd999) begin
counter_msecs <= 10'd0;
clk_1sec <= ~clk_1sec;
end
else begin
counter_msecs <= counter_msecs + 10'd1;
end
end
else begin
counter_cycles <= counter_cycles + 3'd1;
end
end
end
endmodule
You can edit/simulate this version at
https://www.edaplayground.com/x/3CjH
The problem is improper nesting of begin/end blocks with the first else. Your indentation does not match what the compiler sees. And I'm sure you meant == instead of +=