I have two 2-bit inputs and an output of 1-bit. So what I'm trying to do is code a next state value with taking AND of the two inputs, then use non-blocking <= to assign that value into register xy_r, which is now two D-flipflops. So I am seeking to get always the XOR-value of the xy_r previous clock edge as my output xor_out. I suppose that the way below is not the right one?
It worked in the simulation but then again in RTL Synthesis I didn't end up with an XOR gate but a third flip-flop so it seems like xor_out is treated as a register.
I suppose I can't use assign outside of the if-else-statements because in that case the output wouldn't follow the xy_r previous state but the present.
Can you please assist me how to solve this issue, if there is a somewhat simple way.
module 2ffsxor
(input logic clk,
input logic rst_n,
input logic [1:0] x_in,
input logic [1:0] y_in,
output logic xor_out
);
logic [1:0] xy;
logic [1:0] xy_r;
always # (posedge clk or negedge rst_n)
begin
if (rst_n == '0)
xy_r <= '0;
else
begin
xy = x_in & y_in;
xy_r <= xy;
xor_out = xy_r[0] ^ xy_r[1];
end
end
endmodule
And here's a schematic what it should be:
Schematic 2ffsxor
Synthesis treats this code as if you had wrote
begin
xy_r <= x_in & y_in;
xor_out <= xy_r[0] ^ xy_r[1];
end
That's two stages of registers. But since you assigned xor_out with a blocking assignment, you have a simulation race condition for any process that tries to read xor_out. The race would be from the result from the previous values of xy_r and the result before that!
If you use an continuous assign statement outside this always block, any process reading xor_out on the clock edge will see the result from the previous state of xy_r.
But why not write this as on register:
always # (posedge clk or negedge rst_n)
begin
if (rst_n == '0)
xor_out <= '0;
else
begin
xy = x_in & y_in;
xor_out <= xy[0] ^ xy[1];
end
end
I am creating UVM VIP which is able to switch its clock polarity. Clocking block is used in the interface.
For example, a monitor should sample the data using posedge or negedge of incoming clock depending on UVM configuration - and this polarity change can happen on the fly.
This can be implemented as follows:
// In the interface, two clocking blocks are defined
// one for posedge (passive_cb), one for negedge (passive_cbn).
task wait_clock_event();
if (cfg.pol == 0) #vif.passive_cb;
else #vif.passive_cbn;
endtask
task sample_data();
if (cfg.pol == 0) pkt.data = vif.passive_cb.data;
else pkt.data = vif.passive_cbn.data;
endtask
task run();
wait_clock_event();
sample_data();
endtask
This seems to work but waste code lines and prone to error.
Is there any better solution?
Assuming the monitor has exclusive access to the clocking block, you could consider modifying clocking event in the interface with the iff qualifier.
bit pol;
clocking passive_cb #(posedge clk iff !pol, negedge clk iff pol);
input data;
endclocking
There is a potential race condition if pol changes in the same timestep as the target clock polarity.
Your monitor code would then include a set function and other tasks can be simplified to us only one clocking block.
function void set_vifcb_pol();
vif.pol = cfg.pol;
endfunction
task wait_clock_event();
#vif.passive_cb;
endtask
task sample_data();
pkt.data = vif.passive_cb.data;
endtask
task run();
set_vifcb_pol();
wait_clock_event();
sample_data();
endtask
I am generating a divided clock, something like this:
logic div_clk;
always_ff #(posedge clk or negedge rstb) begin
if(!rstb) div_clk <= 1'b0;
else div_clk <= !div_clk;
end
I then launch data on clk and capture on div_clk. Something like this:
always_ff #(posedge clk) begin
clk_data <= something;
end
always_ff #(posedge div_clk) begin
div_clk_data <= clk_data;
end
In my simulations I am getting a race condition since clk_data updates coincident with div_clk and the div_clk_data gets the wrong value.
In synthesis I define these two clocks to be synchronous by creating a generated clock:
create_clock -name CLK [get_ports clk]
create_generated_clock -name GEN_DIV_CLK -source [get_ports clk] -divide_by 2 [get_pins div_clk]
Is there something equivalent that I can put into my RTL, or something I can do to tell my simulator that div_clk is synchronous to clk and prevent the race condition from happening?
This is a case where NBA's should not be used. You should not have any NBA's in your clock tree (including gated clocks) if you want the clocks to remain synchronous.
We have an interface with modports connectin gmodules that looks something like this:
interface test_interface (clk, in1, out1);
input logic in1;
output logic out1;
input logic clk;
logic mid1;
logic aliased_signal;
modport a_to_b (
input in1,
input clk,
output mid1,
input aliased_signal
);
modport b_to_a (
input clk,
input mid1,
output out1,
output aliased_signal
);
endinterface : test_interface
module top(clock, inpad, outpad);
input logic clock;
input logic inpad;
output logic outpad;
test_interface test_if(.clk(clock), .in1(inpad), .out1(outpad));
a A0(.a2b(test_if));
b B0(.b2a(test_if));
endmodule
module a ( test_interface.a_to_b a2b);
always_ff #(posedge a2b.clk) begin
a2b.mid1 <= a2b.in1 & a2b.aliased_signal;
end
endmodule
module b (test_interface.b_to_a b2a);
assign b2a.aliased_signal = b2a.out1;
always_ff #(posedge b2a.clk) begin
b2a.out1 <= ~b2a.mid1;
end
endmodule
This is a trivial example, but demonstrates the problem. In the real design, we have, for example 32-bit outputs and 8 bits of that may go to one place and 8 bits to another, etc. In the destination, they would like to use names that are more meaningful in the destination module, so are using assignments to create those names in the interface so that the destination code isn't using just part of the bits of an obfuscated bus name in the interface.
While the above simulates fine, the result is assignment statements during synthesis (even if using always_comb obviously) and while we can have the synthesis tool insert buffers to make APR happy, this is not desired when these signals are just used as convenient aliases basically.
Is there an RTL coding style with SV interfaces that would allow such "aliasing" without creating complications downstream in synthesis/APR tools?
Below is a closer example to what I'm trying to do. The "obfuscated_name" signal is an output of the a module because some modules use the name directly from the interface (this could be cleaned up to only do what the a->b connection is doing), but I get the same errors from IUS and DC if I connect to mid2 a->c instead of using the obfuscated_name signal directly.
interface test_interface(clk, in1, out1, out2);
input logic [7:0] in1;
output logic [3:0] out1;
output logic [3:0] out2;
input logic clk;
logic [7:0] obfuscated_name;
logic [3:0] mid1;
logic [3:0] mid2;
modport a_mp (
input clk,
input in1,
output obfuscated_name
);
modport a_to_b (
input clk,
input .mid1(obfuscated_name[3:0]),
output out1
);
modport a_to_c (
input clk,
input obfuscated_name,
output out2
);
endinterface : test_interface
module a ( test_interface.a_mp a_intf);
always_ff #(posedge a_intf.clk) begin
a_intf.obfuscated_name <= ~a_intf.in1;
end
endmodule
module b (test_interface.a_to_b b_intf);
always_ff #(posedge b_intf.clk) begin
b_intf.out1 <= b_intf.mid1;
end
endmodule
module c (test_interface.a_to_c c_intf);
always_ff #(posedge c_intf.clk) begin
c_intf.out2 <= ~c_intf.obfuscated_name[7:4];
end
endmodule
module top( input logic clock,
input logic [7:0] inpad,
output logic [3:0] outpad1,
output logic [3:0] outpad2 );
test_interface test_if(.clk(clock), .in1(inpad), .out1(outpad1), .out2(outpad2));
a A0(.a_intf(test_if));
b B0(.b_intf(test_if));
c C0(.c_intf(test_if));
endmodule
The error I get from IUS is:
ncvlog: *E,MODPXE (test_interface.sv,18|18): Unsupported modport
expression for port identifier 'mid1'.
and DC gives this error:
Error: ./b.sv:1: The construct 'b_intf.mid1 (modport expression without a modport from parent)' is not supported in synthesis. (VER-700)
I'm hoping I'm doing something ignorant here and that this is possible what I'm trying to do.
There is a feature in Verilog called a port expression .name_of_port(expression_to_be_connected_to_port) that most people recognize in a module instance port list that they don't realize can also be used in the module deceleration port list header. This declares the name of the port, and the expression that gets connected to the port. This way a smaller part select of a larger internal bus can be made into a port.
module DUT(input clk, inout .data(bus[7:0]) );
wire [31:0] bus;
endmodule
module top;
reg clock;
wire [7:0] mydata;
DUT d1(.data(mydata), .clk(clock) );
endmodule
In SystemVerilog you can do the same thing with a modport expression.
interface test_interface (clk, in1, out1);
input logic in1;
output logic out1;
input logic clk;
logic mid1;
logic aliased_signal;
modport a_to_b (
input in1,
input clk,
output mid1,
input .aliased_signal(out1) // modport expression
);
modport b_to_a (
input clk,
input mid1,
output out1
);
endinterface : test_interface
module top( input logic clock,
input logic inpad,
output logic outpad );
test_interface test_if(.clk(clock), .in1(inpad), .out1(outpad));
a A0(.a2b(test_if));
b B0(.b2a(test_if));
endmodule
module a ( test_interface.a_to_b a2b);
always_ff #(posedge a2b.clk) begin
a2b.mid1 <= a2b.in1 & a2b.aliased_signal; // port reference to alias
end
endmodule
module b (test_interface.b_to_a b2a);
always_ff #(posedge b2a.clk) begin
b2a.out1 <= ~b2a.mid1;
end
endmodule
module input2 (output [3:0] out1, out2, input [3:0] in1, input clk);
clocking c_clk #(posedge clk);
output #2ns out1, temp = in1[1:0];
input in1;
endclocking
clocking d_clk #(posedge clk);
output out2;
input #2ns svar = in1[3:2];
endclocking
assign out1 = c_clk.temp ^ 4'b1101;
assign out2 = d_clk.svar + in1;
endmodule
my tool is giving an error that "Reading of a clocking block output (c_clk.temp ) is not allowed." I have not found any standard for this statement.
Thanks in advance for your help.
The 1800-2012 standard says in 14.3 Clocking block declaration
It shall be illegal to read the value of any clockvar whose
clocking_direction is output.
The reason is an output has no defined sampling semantics. An inout does.