Verilog wait function explanation - verilog

I have problem with my Verilog code. I have 2 clocks - one 100kHz, second 10kHz. I'd like to toggle LED with 100kHz frequency only when 10kHz is HIGH. But my output is still low. This is my code:
module LED_toggle(
input clock_100kHz,
input clock_10kHz,
output reg LED_PIN,
);
initial begin
LED_PIN <= 1'b0;
end
always begin
if(clock_10kHz) begin
LED_PIN = 1'b1;
#(posedge clock_100kHz);
LED_PIN = 1'b0;
#(posedge clock_100kHz);
end
else begin
LED_PIN = 1'b0;
end
end
endmodule
I know that I can do this in other way (like trigger on 100kHz edge and check state ot 10kHz), but I try to understand why #(posedge clock_100kHz); don't act like I would expect. I also try wait(clock_100kHz) insted, but this also don't work.
I'm sure that my clocks are configured properly, because this code works like I expect:
module LED_toggle (
input clock_100kHz,
input clock_10kHz,
output reg LED_PIN,
);
initial begin
LED_PIN <= 1'b0;
end
always begin
if(clock_10kHz) begin
LED_PIN = ~LED_PIN;
end
else begin
LED_PIN = 1'b0;
end
end
endmodule
but I try to understand what is wrong with my wait conditions.

It would likely be best if you built this more like HW instead of SW. Your always begin blocks act more like a behavioral model than a HW representation.
It looks like, based on the first snippet that you actually want the LED to run at 50kHz (since you are toggling the LED output on each posedge of the 100kHz)? This would be what I would do, for 100kHz:
assign LED_PIN = clock_10kHz & clock_100Hz;
For 50kHz
always #(posedge clock_100kHz) begin
if(clock_10kHz) LED_PIN <= ~LED_PIN
else LED_PIN <= 1'b0;
end
What the first snippet does is just use the 10kHz clock as a gate and basically the 100kHz clock directly drives the LED.
The second snippet still uses the 10kHz clock as a gate, but there is a register built that is clocked with the 100kHz clock that drives the LED_PIN output. This will make the effective toggling of the LED 50kHz instead of the 100kHz you described/desired, but this matches your behavioral in your first snippet. I'm making an assumption that these clocks are synchronous, but really that gate should be synchronized into the 100kHZ clock domain, but that's a different topic.
always begin is really a behavioral construct. It is essentially something that say "always do this, and do it as fast as I say". In your example, I'm not sure how the simulator didn't just run away when the clock_10kHz was low. Many simulators would see no time statement (such as a #delay or #()) and try to compute that as many times as possible, or just error if it was smart enough to see an infinite loop. Remember that verilog is an event based language. In your code, there are cases where you don't have any "Events", just actions that should happen. This can, and will cause you some grief. If you've done other programming languages, and start verilog, this is usually the hardest part to grasp, but when you do, it makes much more sense.
Hopefully this helps!

Related

How to set a signal at both posedge and negedge of a clock?

I'm trying to implement a controller with the function that sends out the same clock signal as its input clock. But the controller can also halt the output signal if needed. I'm implementing it on Xilinx ISE.
My idea is: At the negedge of the input clock, the output clock signal set to 0. At the posedge of the input clock, if I want to send out the clock I'll set the output clock to 1, but if I want to halt the output clock, I'll set the output clock to 0 so other devices (all posedge-triggered) won't detect the posedge.
Here's my design:
module controller(
input clk_in,
input reset,
output clk_out
//and other ports
);
always #(negedge clk_in)
clk_out<=0;
always #(posedge clk_in)
if(reset)
clk_out<=1;
else
begin
case(cases)
case1:
begin
//do something and halt the output clock
clk_out<=0;
end
case2:
begin
//do something and continue the output clock
clk_out<=1;
end
endcase
end
When I synthesized the design I had an error saying the signal clk_out is connected to multiple drivers. Is there any way to solve it?
You have two different always blocks which drive the same signal clk_out. This is what synthesis tells you about. All signals in a synthesizable rtl must be driven from a single block only.
It looks like you are trying to create some type of a gated clock. Instead of going through the trouble of detecting negedges of the clock, which most likely will not be synthesizable as well, you can use a simple logic to do so:
always #*
clk_out = enable & clk_in;
You just have to figure out how to generate enable.
BTW, never use NBAs (<=) in generating clock signals or you end up with clock/data race conditions.

In Verilog, can "always #(posegde)" or "always #(negegde)" work on a register variable?

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.

What will happen in synthesis if a signal is only defined inside reset logic in always_ff?

Let's say I've following code:
always_ff #(posedge clk, negedge rst) begin
if (~rst) begin
bad_singal <= '0;
good_signal <= '0;
end else begin
// do something
// bad_signal is not used here or anywhere in design.
if (some condition)
good_signal <= 1'b1;
end
end
What will happen to bad_signal in synthesis? Will the synthesis tool optimize away the flop as it's not used anywhere in the design?
If a signal or register doesn't drive anything, then yes -- any competent synthesis tool will trim it away, regardless of how it is set. Many synthesis tools will report a warning when this occurs.
It should infer a latch technically.
If it not used it will be optimized away. If it is used somewhere it will be tied to the ground since its value is always 0.

Event control in always #(posedge clk)

Wondering about the behavior of event control statements in an always block:
always #(posedge clk) begin: TEST
...
#(wait_for_signal_from_subsystem);
...
#(wait_for_another_signal_from_subsystem);
...
end
Will the process be "stuck" until the event signals come in, or will it restart every time a clk edge comes in ?
Also is this synthesizable (Quartus II says yes, but not simulated yet...) ? and is this a good practice or is there an alternative better approach to this problem ?
Yes, it is 'stuck' as you would say. Only one 'loop' of the block can be active at a time, it will not reenter if it has not completed the loop.
The thing you are trying to do there is likely not synthesizable, due to the wait operations inside the block.
I don't know the exact specifics of your design, but I would approach this with a small finite state machine. I assume that the signals from your subsystem are not faster than the clock, so it would look something like:
always #* begin
if(state_f == `WAIT_FOR_FIRST)
state_nxt = got_first_signal ? `WAIT_FOR_SECOND : `WAIT_FOR_FIRST;
else if(state_f == `WAIT_FOR_SECOND)
state_nxt = got_second_signal ? `DONE_STATE : `WAIT_FOR_SECOND;
else if(state_f == `DONE_STATE)
state_nxt = `WAIT_FOR_FIRST;
else
state_nxt = 2'bxx;
end
always #(posedge clk) begin
state_f <= state_nxt;
end
Assuming you are designing hardware and not non-synthesized testbench code, this not a good practice and likely won't do what you want anyways.
From a language perspective, this will compile and simulate. It will block waiting on the events within the always blocks and NOT restart on each posedge of the clock. I could not find a spec reference for this but it's what I observed in simulation. I'm curious what this would synthesize to if you even get it to synthesize with no errors.
If the signal from the other subsystem is already in the same clock domain (synchronous to clk), then you can just check the state of it on each clock edge, and use this do something.
always #(posedge clk) begin: TEST
if (the_other_signal == 1'b1) begin
...
end
end
Some other things to consider:
Maybe you only care about when the signal assert/deasserts. In that case you need to do an edge detection.
If the signal is asynchronous to clk, then you have a clock domain crossing and you need to synchronize the incoming signal before you look at it.

How can I create a latch in Verilog

I have a CPLD with a digital input representing a reset button. When the reset button is pressed, the signal goes high. What I need to do is have a register whose value tells if the button has ever been pressed. Basically a latch. When the button goes high, a latch register goes high and stays high forever.
I thought this would be straightforward, but I got a bunch of warnings when I tried to code it up. A little Googling showed "Don't make latches in HDL! Bad practice!", but I don't really see the alternative here.
Here's my attempt. clk_10m is a fast free-running clock, pwr_off_req is the button input.
reg pwr_off_req_latched = 0;
always # (clk_10m or pwr_off_req) begin
if (pwr_off_req == 1'b1)
pwr_off_req_latched <= 1'b1;
else
pwr_off_req_latched <= pwr_off_req_latched;
// I tried this to make sure it's always set to something
end
Can you assume that the pulse length of the button press is much longer than the clock frequency of your device? If it's a physical button I think that is a very safe assumption. In that case I think this would work perfectly fine:
always #(clk_10m)
pwr_off_req_latched <= power_off_req_latched | power_off_req;
Latches are not bad in HDL they just require some consideration, implied latches from forgetting to specify else clauses in combinatorial sections are bad because you do not end up with the hardware you expect, and can create timing problems.
If you are applying a reset you might need to specify a 'pragma' so that the synthesis tool correctly identifies it.
Also latches should use = not <=, when they are enabled they are combinatorial (open) and will not break feedback loops.
This is typical way to create a latch with an asynchronous reset:
//synopsys async_set_reset "rst_an"
always #* begin
if (~rst_an) begin
// Reset
x = 1'b0;
end
else if (latch_open) begin
//next datavalue
x = y ;
end
end
In your case you might want something like :
//synopsys async_set_reset "rst_an"
always #* begin
if (~rst_an) begin
pwr_off_req_latched = 1'b0;
end
else if ( pwr_off_req ) begin
pwr_off_req_latched = 1'b1 ;
end
end
Latches can create problems for timing analysis tools. They also don't map to certain (FPGA) architectures directly, so are much harder for the place-and-route tools. Hence the warnings.
However, what you are asking for is not a latch as I understand the digital logic sense - merely a flipflop which doesn't ever get reset.
So, it can be simplified to a simple d-type flipflop with the D input tied to 1 and the clk input connected to your pwr_off_req signal:
reg pwr_off_req_latched = 0;
always # (posedge pwr_off_req) begin
pwr_off_req_latched <= 1'b1;
end
You'll have no noise rejection on that at all - any positive going edge will latch the flipflop to 1.
If I were doing this, I would run the input into a double-flip-flop synchroniser and then count a few clock pulses of the synchronised signal to make sure it's not noise before setting the latched signal. Unless you are expecting real events shorter than a few clock pulses that'd the way to do it.
Aside:
A "latch" in the digital logic world usually means either
a circuit whose output holds whichever of the two inputs was last high (a Set/Reset or SR latch)
a circuit whose output holds the input value while a control signal is inactive, but follows the input when the control signal is low - a transparent latch
This is in comparison to a flipflop, whose output holds some aspect related to the input(s) when the control signal changes (usually) from low to high, and ignores the inputs except for a tiny time window around that rising edge. These are D-type, T-type and JK-type flipflops, depending on how the output behaves relative to the input.

Resources