tranif1 always a driver ?

Hi,

I am not sure whether this is a verilog issue or ncsim issue.

We have a verilog model of a I/O buffer that can be configured as
either Analog or Digital. This is modelled using

// digital signal
bufif0 (PAD, I, OEN_global);
// analog signal
tranif1 (PAD,ANA_IN,ANAE);

i.e. when the analog enable (ANAE) is active (high) the tranif1 switch
is enabled.

However, I have noticed that even with ANAE disabled (low), this gate
is still considered a driver on PAD (checked using driver command in
ncsim, and also via EVCD analysis). i.e. If the digital O/P function
is enabled, then there are two drivers on PAD (bufif0 and tranif1).

This is causing us some difficulties because our EVCD analysis tool
(for ATPG pattern generator) is giving us errors (multiple drivers).

So, questions
- Is this "logical". i.e. Does anyone believe this behaviour is
correct? Any LRM lawyers out there ?
- Is it ncsim specific issue, or is it more general.

Any initial thoughts? I will generate and post a very simple test
case.

Thanks,

Steven

 

[glen herrmannsfeldt]

moogyd@yahoo.co.uk wrote:

We have a verilog model of a I/O buffer that can be configured as
either Analog or Digital. This is modelled using

// digital signal
bufif0 (PAD, I, OEN_global);
// analog signal
tranif1 (PAD,ANA_IN,ANAE);

i.e. when the analog enable (ANAE) is active (high) the tranif1 switch
is enabled.

However, I have noticed that even with ANAE disabled (low), this gate
is still considered a driver on PAD (checked using driver command in
ncsim, and also via EVCD analysis). i.e. If the digital O/P function
is enabled, then there are two drivers on PAD (bufif0 and tranif1).

Is PAD declared as inout?

As far as I know, verilog doesn't allow analog signals.
Still, tranif1 should pass the signal from either side to the
other side, though that would have to be to a tri or inout line.

For synthesis it might be that you can only generate a tristate
driver with an input, output, and enable line.

-- glen

 

On 19 Aug, 18:26, moo...@yahoo.co.uk wrote:

Hi,

I am not sure whether this is a verilog issue or ncsim issue.

We have a verilog model of a I/O buffer that can be configured as
either Analog or Digital. This is modelled using

// digital signal
bufif0 (PAD, I, OEN_global);
// analog signal
tranif1 (PAD,ANA_IN,ANAE);

i.e. when the analog enable (ANAE) is active (high) the tranif1 switch
is enabled.

However, I have noticed that even with ANAE disabled (low), this gate
is still considered a driver on PAD (checked using driver command in
ncsim, and also via EVCD analysis). i.e. If the digital O/P function
is enabled, then there are two drivers on PAD (bufif0 and tranif1).

This is causing us some difficulties because our EVCD analysis tool
(for ATPG pattern generator) is giving us errors (multiple drivers).

So, questions
- Is this "logical". i.e. Does anyone believe this behaviour is
correct? Any LRM lawyers out there ?
- Is it ncsim specific issue, or is it more general.

Any initial thoughts? I will generate and post a very simple test
case.

Thanks,

Steven

Hi,

I have generated a simple example.

// Simplified behavioural model of tri-state buffer with
// analog functionality
module my_buf (anae, ana_in, dout, oen,pad);
inout pad ; // Bidir Pad
inout ana_in ; // Analog in (to/from analog top)
input anae ; // Active high analog enable
input dout ; // Digital data
input oen ; // Digital data O/P enable

// Digital O/P function
assign pad = (oen == 1'b0) ? dout : 1'bz ;

// Analog Function
tranif1 (pad,ana_in,anae);
endmodule

// Simple Testcase
module tb_my_buf();

wire pad ;
wire ana_in, anae;
reg dout,oen ;

// Disable analog function for this test case
assign anae = 1'b0 ;
)
// Toggle dout
initial begin
oen = 1'b0 ; // Always enable digital I/P
dout = 1'b0 ;
end

always
#50 dout = ~dout;

// UUT

my_buf dut ( .pad(pad),
.ana_in(ana_in),
.anae(anae),
.dout(dout),
.oen(oen)
);

endmodule

When I run this simulation for 1000 ns and then check the drivers on
pad
Modelsim 6.2c shows 1 driver (as expected)
Cadence NCSIM 6 shows 2 drivers (includes tranif1 even through control
is 0)

Therefore, it looks like a cadence ncsim issue.

I would appreciate if anyone can check behaviour in the synopsys
simulator.

Thanks,

Steven

 

On Aug 19, 12:26 pm, moo...@yahoo.co.uk wrote:

So, questions
- Is this "logical". i.e. Does anyone believe this behaviour is
correct? Any LRM lawyers out there ?

I agree that this seems odd, and is not what I would have expected.

The bidirectional trans are strange beasts, and require some unusual
treatment from a simulator. That might affect the reporting of
drivers. Do you really need this transistor modelled as
bidirectional? If you just want a transistor model that passes
strength through in one direction, I would suggest using the
unidirectional nmos primitive instead. That avoids the special
treatment required for trans.