The module to be verified is as follows...
The module has an input in1 and an output out1, on alternating clock cycles, out1 is the buffered and inverted value of in1.
I tried coding the checker module using a recursive property.
module check (input in1, out1, clk);
property p1(bit state);
bit nxt;
#(posedge clk)
(1 ,nxt=!state) |-> (out1 == (nxt) ? !in1 : in1) and
nexttime p1(nxt);
endproperty
initial assert property(p1(0)) else $fatal(3, "Failed!");
endmodule
However, running the code at edaplayground throws this error...
RROR VCP2000 "Syntax error. Unexpected token: nexttime[_NEXTTIME]. The
'nexttime' is a SystemVerilog keyword and cannot be used as an
identifier.
I know that this assertion can be done without recursion but I would like to use recursion to write it.
The error says that you have used nexttime which is a systemverilog property keyword in a wrong manner. This operator checks that "if the clock ticks once more, then a shall be true at the next clock tick" in the following code
property p1;
nexttime a;
endproperty
By default, the concurrent assertions shall be checked on every clock pulse, so there is no need of recursion here. Roughly, you can do something like this:
module check (input in1, out1, clk);
bit o_nxt;
function bit update(input bit nxt);
o_nxt = nxt;
return 1;
endfunction
property p1(bit state);
bit nxt;
#(posedge clk)
(1 ,nxt=!state) |-> (out1 == (nxt) ? !in1 : in1) and
update(nxt);
endproperty
initial assert property(p1(o_nxt)) else $fatal(3, "Failed!");
endmodule
Related
I am getting X as clk_out.Example of the frequency divider.
module freq_by2(input clk,rst,output reg clk_out);
always #(posedge clk)
begin
if (rst==1'b1)
begin
clk_out<=0;
end
else
begin
clk_out<=~clk_out;
end
end
endmodule
module freq_by4(input clk,rst,output reg [1:0] clk_out);
freq_by2 f0(.clk(clk),.rst(rst),.clk_out(clk_out[0]));
freq_by2 f1(.clk(clk_out[0]),.rst(rst),.clk_out(clk_out[1]));
endmodule
Are you sure, you are generating a correct, synchronous rst pulse? That is, synchronous to both clk and clk/2, because your f1 instantiation is synchronous to the clk_out output of f0? Otherwise, you are negating the last value of clk_out inside of freq_by2, which is X initially, unless a correct reset was generated.
When designing finite state machines in verilog, I find myself writing code like this a lot to preserve a value in a particular state.
always#(state, a, b) begin
case(state) begin
S1: a = b;
S2: a = a; // preserve a;
endcase
end
This is necessary because if I don’t specify a value for each register in the sensitivity list, the compiler will infer a latch. To me this feels like a code smell, but I’m not experienced enough to know for sure. Is this the best way to preserve a value in verilog?
Preserve state means to create a latch, which is a device that do exactly that.
a=a is a null statement and you should not use it at all.
Do not use sensetivity lists in the always block, they are error prone, use #* instead.
And, for latches, you should use non-blocking assignments.
Your latch case statement should look like the following:
always#(*) begin
case(state) begin
S1: a <= b;
S2: // do nothing about 'a', a will not change.
endcase
end
in general the FSM scheme use in industry uses clocks and looks like the following:
always#(posedge clk) begin
case(state) begin
S1: begin
next_state <= S2;
a <= b;
end
S2: // do nothing about 'a', a will not change.
....
endcase
end
assign state = next_state;
Verilog case statmenet expression is always true
module test(input clk,
input reset,
output reg[3:0] ledss
);
reg[31:0] dataread;
always #(posedge clk)
begin
case(dataread)
32'b1010101010101010101:ledss='b1010;
endcase
end
endmodule
dont understand why this line executed
32'b1010101010101010101:ledss='b1010;
leds is on same pattern 1010
also after executing this code , leds not on
module test(input clk,
input reset,
output reg[3:0] ledss
);
reg[31:0] dataread;
always #(posedge clk)
begin
if(dataread==32'b1010101010101010101) ledss='b1010;
end
endmodule
but if i execute this,leds is on ,pattern 1010
module test(input clk,
input reset,
output reg[3:0] ledss
);
reg[31:0] dataread;
always #(posedge clk)
begin
case(dataread)
32'b101010101010:
begin
if(dataread==32'b101010101010) ledss='b1010;
end
endcase
end
endmodule
dont understand how case statement works in verilog
I believe you are skipping Verilog simulation and loading your code directly to FPGA.
In simulation. ledss would be X until the patter match is satisfied (both case or if). In the provided code dataread is never assigned so it will be X, therefore in simulation ledss will always be X. In your pastebin links you have dataread driven by a ROM output, so it will have a know output that might match the checking condition.
FPGA synthesizes your RTL and typically goes through some optimization. ledss is not explicitly initialized and has only one possible value if ever assigned. Because of this the optimizer might assume the initial value is don't care, then simplify logic by choosing the initial value to be the same as the only possible value it can be assigned to. Or it might assume the initial value is 0 and keep the logic. For this scenario in general, case tends the follow the former and if tends to follow the latter. Though your code is functionally equivalent, it is uncommon to have a case-statement with only one condition.
I suggest you improve your coding style so your intended behavior is more explicitly understood by the synthesizer and anyone reading your code. Bellow are some suggestions. Remember to assign dataread to a known value. (Note: replaced 32'b1010101010101010101 with the equivalent 32'h0005_5555 for human readability)
always #(posedge clk)
begin
case(dataread)
32'h0005_5555 : ledss <= 4'b1010;
default : ledss <= 4'b1111;
endcase
end
Or equivalent:
always #(posedge clk)
begin
if (dataread == 32'h0005_5555)
ledss <= 4'b1010;
else
ledss <= 4'b1111;
end
If you want ledss to keep the 1010 patter after assignment, then you could do:
always #(posedge clk)
begin
if (reset) begin
ledss <= 4'b1111;
end
case(dataread)
32'h0005_5555 : ledss <= 4'b1010;
endcase
end
Or equivalent:
always #(posedge clk)
begin
if (reset) begin
ledss <= 4'b1111;
end
else if (dataread == 32'h0005_5555) begin
ledss <= 4'b1010;
end
end
I have this code below:
module timer(
input clk,
input reset,
output reg signal // <--- PROBLEMATIC SIGNAL
);
always#(posedge clk or posedge reset)
begin
if(reset)
signal <= 1;
else
signal <= 0;
end
endmodule
and this testbench, which was executed on modelsim:
`timescale 1ns / 1ps
`define PERIOD 20
module timer_tb;
logic clk;
logic reset;
logic signal;
timer inst(
.clk(clk),
.reset(reset),
.signal(signal)
);
initial
begin
clk = 0;
forever clk = #(`PERIOD/2) ~clk;
end
initial
begin
reset = 0; //<--- RESET STARTS CLEANED.
#(`PERIOD)
reset = 1;
#(`PERIOD)
reset = 0;
#(`PERIOD*3)
reset = 1;
#(`PERIOD)
reset = 0;
#(`PERIOD*3)
$display("End of the simulation");
$stop;
end
endmodule
Output reg signal starts HIGH but in the code, this reg depends of reset, and the reset starts DOWN. I don't understand why signal register is HIGH in the beginning of the simulation as the reset starts surely DOWN.
I need the signal starting DOWN and only be set up IF reset go to 1 (condition posedge reset just like my code).
Please take a look on this print of the waveform for clear understanding of my problem.
Your waveform has clock-to-q delay, but your RTL model doesn't have any delay. This implies you are not running RTL simulation. Rather your are running a synthesized gate level simulation or getting output from an FPGA.
Something to consider is that in the test bench, clk and reset start as X not 0. The become 0 at time zero. Verilog allows indeterminate order for parallel process, it is optional to execute an always block at time zero regardless of its sensitivity list, and an X in for a comparison evaluates as true. Depending how the vendor implemented the simulator, it is possible the always block got executed first. reset being X evaluates as true and assigns signal to 1. Then clk and reset are assigned to 0. All of this happens at time 0 and cannot be seen in waveform.
This allowed unpredictability is an unintentional slice of reality. When you first power up a circuit what you initially get may be unpredictable (this is from process variation, physical routing, glitches while the power supply is being ramped, etc. ). You use a reset to get the design into a known state.
If you want to prevent the clk and reset from ever begin X, then change the data-type in the test-bench from logic to bit (note:bit and logic are SystemVerilog). Another option that should work (not 100% guaranteed) is to initialize clk and reset in the same line as it's declaration.
logic clk = 1'b0;
logic reset = 1'b0;
This should work assuming you are running simulation. If you are running on FPGA you cannot guaranty this time zero behavior through changes in your test bench.
The cleanest solution is to start with reset enabled. You should not care what the values are before reset at time zero.
signal has not initial value, so its value at time 0 is undefined. Some simulators initialize it to 0, others to 1, others to X.
Use an initial block to have signal initialized to 0.
module timer(
input clk,
input reset,
output wire signal
);
reg rsignal;
assign signal = rsignal;
initial begin
rsignal = 1'b0;
end
always#(posedge clk or posedge reset)
begin
if(reset)
rsignal <= 1;
else
rsignal <= 0;
end
endmodule
The default value of reg is 'x' or undefined and default value of wire is 'Hi-Z' , so in this case your output (signal) is reg type so simulator took default value accordingly, to get a default value of '0' SystemVerilog(IEEE1800-2012) comes with bit data type, you can try using bit in the output as shown below
module timer(
input clk,
input reset,
output bit signal
);
always#(posedge clk or posedge reset)
begin
if(reset)
signal <= 1;
else
signal <= 0;
end
endmodule
EDIT: I am not sure of quartus but conversely you can try initializing the value to 0 or 1 at the output by this method, It should work in Verilog
module timer(
input clk,
input reset,
output reg signal=0
);
always#(posedge clk or posedge reset)
begin
if(reset)
signal <= 1;
else
signal <= 0;
end
endmodule
I'm trying to write RS232 transmitter module in vhdl for Spartan. According to simulation in Xilinx, it seems to be working fine, but when i try to deploy it on device, it simply doesn't work. I have found out that it might be problem with latches, but somehow I'm not able to pinpoint them. I'm using 50 Mhz clock and the bit rate of transmission is 115200 bs.
This is my vhdl code:
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
USE ieee.std_logic_arith.all; -- Uncomment the following library declaration if using
-- arithmetic functions with Signed or Unsigned values
use IEEE.NUMERIC_STD.ALL;
-- Uncomment the following library declaration if instantiating
-- any Xilinx primitives in this code.
--library UNISIM;
--use UNISIM.VComponents.all;
entity nadajnikRS is
Port ( start : in STD_LOGIC;
reset : in STD_LOGIC;
clk : in STD_LOGIC;
DI : in STD_LOGIC_VECTOR(7 downto 0);
RS_TX : out STD_LOGIC;
busy : out STD_LOGIC);
end nadajnikRS;
architecture Behavioral of transRS is
signal register : STD_LOGIC_VECTOR(8 downto 0) := (others => '1' );
signal counter : INTEGER range 0 to 9 := 0;
signal baud_clk : STD_LOGIC := '0';
signal ready : STD_LOGIC := '0';
type states is (working, free);
signal state: states := free;
signal baud_counter : INTEGER range 0 to 220 := 215;
begin
baud_clock: process (clk)
begin
if rising_edge(clk) then
if (ready = '1') then
if (baud_counter < 218) then
if (baud_counter = 217) then
baud_clk <= '1';
end if;
baud_counter <= baud_counter+1;
else
baud_counter <= 0;
baud_clk <= '0';
end if;
else
baud_counter <= 0;
end if;
end if;
end process baud_clock;
shiftregister : process (baud_clk)
begin
if rising_edge(baud_clk) then
if (state = free) then
RS_TX <= '0';
register (7 downto 0) <= DI;
else
RS_TX <= register(0);
register <= '1' & register(8 downto 1);
end if;
end if;
end process shiftregister;
bitcounter : process (baud_clk)
begin
if rising_edge(baud_clk) then
counter <= counter + 1;
if (counter = 10) then
counter <= 1;
end if;
end if;
end process bitcounter;
shiftstate: process (reset, counter, start)
begin
if (reset = '1') then
ready <= '0';
end if;
if (start = '1') then
ready <= '1';
state <= free;
end if;
if (counter = 1 ) then
state <= working;
elsif (counter = 10) then
state <= free;
end if;
end process;
statemachine : process (state)
begin
case state is
when working => busy <= '1';
when free => busy <= '0' ;
end case;
end process statemachine;
end Behavioral;
During synthesis I get two latch warnings:
Xst:737 - Found 1-bit latch for signal <ready>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
Xst:737 - Found 1-bit latch for signal <state_0>. Latches may be generated from incomplete case or if statements. We do not recommend the use of latches in FPGA/CPLD designs, as they may lead to timing problems.
I tried to eliminate them by adding additional if statements, but nothing seems to work.
I will be grateful for any help,
Ghaad
A process describing a register should have exactly one signal in the sensitivity list, clk (possibly a reset signal as well if you use asynchronous resets), since a register is only sensitive to a single event, namely a clock edge.
Thus your process sensitivity list baud_clock: process (clk,ready) and shiftregister : process (baud_clk, state) already indicate that you have a problem.
When describing a register, always make sure that your if(rising_edge(clk)) surrounds ALL of the described logic. A simple registered process should look like this:
process(clk) begin
-- NO LOGIC HERE
if(rising_edge(clk)) then
if(reset='1') then
-- Synchronous reset logic here.
else
-- All other logic here.
end if;
end if;
-- NO LOGIC HERE
end process;
Look at your 'shiftstate' process, which is responsible for driving 'ready'. How does it drive 'ready' when 'reset' is not 1, and 'start' is not 1? You haven't told it, so it keeps 'ready' unchanged in those cases. That's what 'latch' means: the process needs to remember what 'ready' was before, and keep it the same; your code therefore infers a memory. Make sure that 'ready' is driven in all branches; you can do this easily with a default assignment at the top.
Having said that, your code has multiple other issues. Did someone suggest in another thread that you shouldn't have your rising edge detection inside an if statement? Or was that someone else? Go back and read it again.
Try to fill all the posibilities of if statements so that for every run the program will know which value correspond to a variable. If statement has almost always go with else or elsif options to not produce latches..
A latch can occur when a process is allowed to go from start to finish without the driven outputs being assigned a value. That is if you have any conditional statements in your process and your outputs are driven inside these conditional statements then there a high chance that the outputs may never be driven. To avoid this it is good practice to place a concurrent statement at the beginning of your process to ensure your outputs are being set at least once. This will tell your synthesiser not to create a latch.