I'm learning Verilog and I was wondering, is there a mean to go back to an initial statement in case of a reset? Something like the pseudo-code below:
initial begin
do initial stuff
end
always #(posedge clock) begin
if(reset)
go back to initial
else
do stuff
end
end
It will be a lot less typing if it was possible.
One way I can think of is to use a ROM and use the stored values again at reset.
You could use a task:
task init_stuff;
begin
/* do initial stuff */
end
endtask
initial begin
init_stuff;
end
always #(posedge clock) begin
if(reset) begin
init_stuff;
end else begin
/* do stuff */
end
end
However, for synthesizable code you should be very careful with "initial". Depending on your target architecture it can only be used to initialize ROMs (ASIC) or may create a circuit with very sensitive power-on reset behavior and other oddities (FPGA).
Related
i know high level async reset can be achieved like:
always#(posedge clk or posedge rst)
begin
if (rst==1)
but how to realize posedge async reset, which means the moment reset edge coming up, the logic in always block reset immediately?
i wrote the logic below:
always#(posedge clk or posedge rst)
begin
rst_pre<=rst;
if(!rst_pre && rst) // to test if rst is posedge
//execute reset logic here...
but the question is, the always block was triggered in a unexpected high frequency, i finally figured out that although there was only 1 posedge of rst, the always block was triggered by rst signal much more than 1 time.
(tested using altera cyclone 10LP with quartus 18)
I think the method i used to achieve posedge async reset is not stable, can anyone tell me what can i do to solve this?
What you are trying to achieve is a asynchronous reset. It can be posedge or negedge.
always#(posedge clk or posedge rst)
begin
if (rst)
// do the reset
else begin
// your normal execution logic
end
end
If you want to use negedge reset then you can use:
always#(posedge clk or negedge rst)
begin
if (~rst)
// do the reset
else begin
// your normal execution logic
end
end
Other than that, there is nothing complicated on reset. Both on these occasions, on posedge/negedge of rst, block will get triggered and it will do the reset.
The very first code snippet which you call "high level async reset" logic is "posedge asynchronous reset logic".
The code snippet specified a active high asynchronous reset signal rst. "active high" + "asynchronous" means signals generated by this always block are reset immediately when rst asserts.
As soon as you include "posedge/negedge reset" in the sensitivy list, and the reset condition inside the always block has priority over the rest of the sequential logic, it is asynchronous:
always # (posedge clk_i, posedge arst_i) begin
if(arst_i) begin
...this condition has to be first
end
else begin
...normal sequential logic
end
end
Use "posedge" for active-high reset, and "negedge" for active-low reset.
Extra note: Sometimes it is also useful to have a reset synchronizer. This synchronized "soft reset" should be included in the normal sequential logic and it would help to have everything synchronized with the clock. By doing this you would have a first asynchronous reset condition, and the last synchronized reset would avoid any metastabiliy problems regarding the asynchronous condition.
I have an always block in verilog as shown below. All the input signals inside always block are not stable until startup time say 50ns. I don't want to execute the always block until start up time is reached. What is the best to achieve this functionality? Thanks.
always begin
//functional code
#10
end
Use an initial block
initial #50ns forever begin /* functional code */ #10; end
or for combinational logic, use
initial #50ns forever #* begin /* functional code */ end
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!
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.
I'm using Verilog for programming a FPGA.
I have my top module and I would like to call a Task which contains an always block.
The Task is a routine for serializing a byte in UART. (inputs: baudrate_clk, bytetosend ; output: TxD which is the physical output pin)
module serial();
task serial;
input baudrate;
input [7:0] data;
output TxD;
reg [3:0] state;
begin
always #(posedge baudrate) begin
case(state)
// ...
endcase
end
end
always #(state[2:0]) begin
case(state[2:0])
// ...
endcase
end
assign TxD ...
end
endtask
endmodule
I get a unexpected token: 'always' at the first always, always #(posedge baudrate) begin
I read Task could include wait, posedge etc...
If I cannot use Taks, what can I use for this purpose ?
Thank you.
Either your task should be a module or you should use a loop inside your task. It's difficult to see your design intent, but it looks to me that you needed a module in this case, not a task.
Tasks contain sequential code, just like an always block does. A task is just another place to put the kind of code that can go inside an always block. It makes no sense to put an always block inside a task.