PLI call which won't back propagate

[Suresh V]

Hi,

I have design where i have to force on port/signal , my goal is that
applied force should not back propagate . Please help me is there any
way to do that without touching the design.

module top;
wire a;
inst i(.in(a));
endmodule

module inst(input in);
endmodule

pli force is applied on 'in' .


only way i currently see is to add cont_assign like

module top;
wire a;
wire x;
assign x = a;
inst(.in(x));
endmodule

But i dont want to change the design to do this.


+suresh

 

[Cary R.]

Suresh V wrote:

I have design where i have to force on port/signal , my goal is that
applied force should not back propagate. Please help me is there any
way to do that without touching the design.

module top;
wire a;
inst i(.in(a));
endmodule

module inst(input in);
endmodule

pli force is applied on 'in' .

From what you have provided it looks like the simulator has a bug. A
module input connection should create a continuous assignment from the
"a" wire to the "in" port. This should isolate any force on "in" from
back propagating to "a". If we had runnable code we could verify this
for sure. You could likely build a Verilog only test case using a normal
force from the "top" module instead of from some PLI call. FYI an output
should have a continuous assignment going the other way and an inout
uses a tran style of resolution so will behave differently.

Regards,

Cary

 

[Suresh V]

On Jul 18, 3:26 am, "Cary R." <no-s...@host.spam> wrote:

Suresh V wrote:

I have design where i have to force on port/signal , my goal is that
applied force should not back propagate. Please help me is there any
way to do that without touching the design.

module top;
wire a;
inst i(.in(a));
endmodule

module inst(input in);
endmodule

pli force is applied on 'in' .

 From what you have provided it looks like the simulator has a bug. A
module input connection should create a continuous assignment from the
"a" wire to the "in" port. This should isolate any force on "in" from
back propagating to "a". If we had runnable code we could verify this
for sure. You could likely build a Verilog only test case using a normal
force from the "top" module instead of from some PLI call. FYI an output
should have a continuous assignment going the other way and an inout
uses a tran style of resolution so will behave differently.

Regards,

Cary

Force done using verilog back propagates.
module top;
wire a;
inst i(.in(a));
initial begin
force i.in = 1'b1;
end

initial
begin
$display ( "i.in = %b", i.in); --> will output 1;
end
endmodule

+suresh

 

[Cary R.]

Suresh V wrote:

Force done using verilog back propagates.
module top;
wire a;
inst i(.in(a));
initial begin
force i.in = 1'b1;
end

initial
begin
$display ( "i.in = %b", i.in); --> will output 1;

As it should since this is the net that's being forced. You need to
check that "a" is not getting the value from the force. I do believe
that you are seeing the problem, It's just that this test doesn't
actually check for it. You also need.

$display("a = %b", a);

Which I believe should output 'x' but you're seeing '1'.

With this latest code you also have a potential race with the force and
$display statements. Which initial block will run first? I would
personally write this as a single initial block with a #1; between the
force and $display statements.

end
endmodule

Cary

 

[Suresh V]

On Jul 18, 9:15 pm, "Cary R." <no-s...@host.spam> wrote:

Suresh V wrote:
Force done using verilog back propagates.
module top;
wire a;
inst i(.in(a));
initial begin
force i.in = 1'b1;
end

initial
begin
$display ( "i.in = %b", i.in); --> will output 1;

As it should since this is the net that's being forced. You need to
check that "a" is not getting the value from the force. I do believe
that you are seeing the problem, It's just that this test doesn't
actually check for it. You also need.

$display("a = %b", a);

Which I believe should output 'x' but you're seeing '1'.

With this latest code you also have a potential race with the force and
$display statements. Which initial block will run first? I would
personally write this as a single initial block with a #1; between the
force and $display statements.

end
endmodule

Cary

Use this design you will see the back propagation. Is there any way to
avoid it through PLI without touching the design.
module top;
wire a;
inst i(.in(a));
initial begin
force i.in = 1'b1;
$display ( "a = %b", a);
end
endmodule


module inst(input in);
endmodule

Please help me !.

 

[Suresh V]

On Jul 18, 9:15 pm, "Cary R." <no-s...@host.spam> wrote:

Suresh V wrote:
Force done using verilog back propagates.
module top;
wire a;
inst i(.in(a));
initial begin
force i.in = 1'b1;
end

initial
begin
$display ( "i.in = %b", i.in); --> will output 1;

As it should since this is the net that's being forced. You need to
check that "a" is not getting the value from the force. I do believe
that you are seeing the problem, It's just that this test doesn't
actually check for it. You also need.

$display("a = %b", a);

Which I believe should output 'x' but you're seeing '1'.

With this latest code you also have a potential race with the force and
$display statements. Which initial block will run first? I would
personally write this as a single initial block with a #1; between the
force and $display statements.

end
endmodule

Cary

Please use this design for seeing the scenario. HOw can i prevent back
propagation through PLI without touching the design ?

module top;
wire a;
inst i(.in(a));
initial begin
force i.in = 1'b1;
$display ( "a = %b", a);
end
endmodule


module inst(input in);
endmodule

 

[Stephen Williams]

Suresh V wrote:

Hi,

I have design where i have to force on port/signal , my goal is that
applied force should not back propagate . Please help me is there any
way to do that without touching the design.

module top;
wire a;
inst i(.in(a));
endmodule

module inst(input in);
endmodule

pli force is applied on 'in' .

Simulators will sometimes merge the signals connected by a port
in order to save simulator resources. In your example, this will
have the effect of making top.i.in and top.a aliases of each other.
I think your stuck with it.

--
Steve Williams "The woods are lovely, dark and deep.
steve at icarus.com But I have promises to keep,
http://www.icarus.com and lines to code before I sleep,
http://www.picturel.com And lines to code before I sleep."

 

On Jul 17, 6:26 pm, "Cary R." <no-s...@host.spam> wrote:

 From what you have provided it looks like the simulator has a bug. A
module input connection should create a continuous assignment from the
"a" wire to the "in" port. This should isolate any force on "in" from
back propagating to "a".

The standard allows port connections to be collapsed instead of having
an
implicit continuous assignment. It had to, because that's what
Verilog-XL
generally did. And other simulators have generally followed suit,
either
for performance reasons or for compatibility with XL. And many legacy
Verilog designs rely on this collapsing to "fix" ports that were
declared
with the wrong direction.

When the port is collapsed, the nets on each side become the same net,
and
there is no way to force them separately. In fact, it acts rather
like a
real wire connection, with no buffering.

 

[Cary R.]

sharp@cadence.com wrote:

The standard allows port connections to be collapsed instead of having
an implicit continuous assignment.

I had forgotten about that. Thanks for the reminder. When I have some
free time I need to reread that section of the standard.

Cary

 

[Suresh V]

On Jul 20, 11:15 pm, sh...@cadence.com wrote:

On Jul 17, 6:26 pm, "Cary R." <no-s...@host.spam> wrote:



 From what you have provided it looks like the simulator has a bug. A
module input connection should create a continuous assignment from the
"a" wire to the "in" port. This should isolate any force on "in" from
back propagating to "a".

The standard allows port connections to be collapsed instead of having
an
implicit continuous assignment.  It had to, because that's what
Verilog-XL
generally did.  And other simulators have generally followed suit,
either
for performance reasons or for compatibility with XL.  And many legacy
Verilog designs rely on this collapsing to "fix" ports that were
declared
with the wrong direction.

When the port is collapsed, the nets on each side become the same net,
and
there is no way to force them separately.  In fact, it acts rather
like a
real wire connection, with no buffering.

Does simulator also provides a way to avoid collapsing ports using
some kind of directives ?

 

On Jul 23, 2:54 pm, Suresh V <vsuresh...@gmail.com> wrote:

Does simulator also provides a way to avoid collapsing ports using
some kind of directives ?

Not that I know of, in any simulator I am familiar with.

You could prevent it by using an expression that was not legal as a
net lvalue, and which therefore could not be collapsed. A simple
example would be to do a bitwise OR with 0 (though that would replace
Zs with Xs). Shifting by zero would preserve the value, including
Zs. You can't just put concatenation braces around it, since a
concatenation of nets is a legal net lvalue, and can still be
collapsed.