I am trying to make a module that performs the twos complement of a value if the msb is 1. It works in cadence, however when I try to synthesize it I get the following error:
Cannot test variable X_parallel because it was not in the event expression or with wrong polarity.
The code for the module is as follows:
module xTwosComp (X_parallel, Clk, Reset, X_pos);
input [13:0] X_parallel;
input Clk, Reset;
//wire X_msb; //was an attempt at fixing the problem
output [13:0] X_pos;
reg [13:0] X_pos;
//assign X_msb=X_parallel[13];//failled attempt at fixing
always # (posedge Clk or posedge Reset)
begin
if (X_parallel[13]) begin
X_pos = ~(X_parallel) +1;
end else begin
X_pos = X_parallel;
end
end
endmodule
You are missing your reset statement. Not sure if this fixes the exact error, but synthesizers expect code to determine what events are asynchronous when there is more than one edge event.
You need an if (Reset) begin X_pos <= 14'b0; else before the if (X_parallel[13]). Otherwise posedge Reset is treated as another clock and not a asynchronous reset. This will confuse the synthesizer.
FYI: flops should be assigned with non-blocking assignments (<=). It will save you from debugging false race condition and RTL to gates simulation mismatches.
After countless hours I have figured it out. It was because i was not referencing Clk or Reset in my always block.
Thanks to anyone who considered the issue.
Thanks Greg for your answer, although I figured out how to make it work I am very glad for your response since it cleared up why it works now. Thanks!
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.
In the test-bench code shown below, I'm observing that the clock signal clk does not toggle as expected.
The clock changes from low to high at time 5, but doesn't toggle after that.
module tb();
reg clk;
initial begin
clk = 'b0;
#100 $finish;
end
always#* #5 clk = ~clk;
endmodule
However, if I remove #* from the always#* statement, the clock toggles every 5ns as expected. My question is why doesn't the process block always#* get triggered after the first change?
Note: I've tested the code in NCSIM and VCS, I don't think this a simulator issue.
The accepted answer is wrong - the always is initially triggered by the assignment to 0 in the initial block, so you have a perfectly valid question, which is why the always block isn't triggering itself after it ran the first time (and it clearly did run, because clk is set to 1).
Run the code below - you'll see that it works as expected if you change the blocking assignment to a non-blocking one, or if you use an intra-assignment delay instead of your delay control (clk = #5 ~clk). So, this is a scheduling issue. You might intuitively expect that your process would only trigger once, because the eventual blocking assignment and the process evaluation effectively occur in the same delta, so the blocking assignment could potentially be lost. However, I can't see a specific justification in the LRM. The delay control turns into a future inactive event, and the scheduler eventually executes it, creating an update event, which updates clk (you see this happen once). This should then create an evaluation event for the process, because it's sensitive to clk, but it's not doing this. The scheduling section is (very) woolly, and doesn't really cover this. Mentor would probably give you their version of what's going on if you ask them. VHDL avoids this issue by making all signal assignments non-blocking.
module tb();
reg clk1, clk2, clk3;
initial begin
$monitor($time,, "clk1 = %b; clk2 = %b, clk3 = %b", clk1, clk2, clk3);
clk1 = 1'b0;
clk2 = 1'b0;
clk3 = 1'b0;
#100 $finish;
end
always #*
#5 clk1 = ~clk1;
always #*
#5 clk2 <= ~clk2;
always #(clk3)
clk3 <= #5 ~clk3;
endmodule
clock generators are usually implemented in one of 2 ways:
using always with no sensitivity list, as you already tried:
always #5 clk = ~clk;
the always block without sensitivity list will loop forever and would cause your simulation to hang if it has no #delays inside. Though the latter make it perfect for the clock generator.
use forever loops in your initial block:
initial begin
forever
#5 clk = ~clk;
end
the above code works the same way as the previous always.
The problem is always#(*) will not be sensitive to signals written inside it. So in your case, the implicit sensitivity of the always block doesn't have "clk" in it. Rather it is not sensitive to any signal at all.
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 have written some Verilog code for an adder with 10 inputs. After simulation I am getting the output with one extra clock delay. Why am I getting this delay?
`timescale 1ns/1ps
module add_10(z0,z1,z2,z3,z4,z5,z6,z7,z8,z9,clk,reset,o);
input [7:0] z0,z1,z2,z3,z4,z5,z6,z7,z8,z9;
input clk,reset;
output reg[15:0] o;
always # (posedge clk or negedge reset)
begin
if (!reset)
o=16'b0000;
else
o = z0+z1+z2+z3+z4+z5+z6+z7+z8+z9;
end
endmodule
After asserting the reset, I am getting the output after one clock. But according to the code I wrote, it should come at the next posedge clk when reset=1.
It looks like it's working as it should to me.
I think you're misunderstanding how the reset signal is meant to be used. The reset signal should be kept high at all times. When it goes low, the output will be cleared immediately (it changes on the negative edge). When it goes high, the output will take on the sum of the inputs on the next clock cycle.
If you wanted to update on the positive edge of the reset signal, use the positive edge...
always # (posedge clk or posedge reset)
...
Just beware that doing so will likely affect your minimum cycle times.
I suggest you change the timing of reset with respect to clk in your testbench. The way you have it, reset and clk change simultaneously. I believe the simulator enters your always block as a result of posedge clk, while the value of reset is still 0, and therefore assigns 0 to your output.
I would shift the reset to the left or to the right of the posedge of the clock. That should give you the effect you are looking for.
Your code is probably working as expected, but it may not be. The issue is (a) that you're not showing how reset is generated, and (b) you're using blocking assignments (which you shouldn't be; use <=), so you may have a race elsewhere, in your reset generation.
Show the code that generates reset. If there are no race conditions, then your waveform is correct; edge A clears reset, but this isn't seen by your adder, which thinks that reset is still asserted; the adder sees it de-asserted on the next clock edge, so produces a result.