verilog 'pullup' and VHDL

[Mark McDougall]

Hi,

I've got a problem which I'm sure has been solved before.

I'm doing mixed-language simulation in ModelSim, and have two VHDL
entities connected by an 'inout' port. The top-level of my testbench is
Verilog, so I use a 'wire' to connect the two ports with a 'pullup'.

Trouble is, the entities (3rd party code) specifically compare against
logic level '1' on the wire in certain circumstances. So when the line
isn't driven, I see 'H' on ModelSim wave output but the VHDL code fails.

Is there any way in Verilog of forcing a pullup to '1', so that VHDL
comparisons against '1' succeed?

Or is there another/better way of achieving this end?

I'd prefer not to change either entity as it's 3rd party code.

Regards,

 

[unfrostedpoptart]

I'm doing mixed-language simulation in ModelSim, and have two VHDL
entities connected by an 'inout' port. The top-level of my testbench is
Verilog, so I use a 'wire' to connect the two ports with a 'pullup'.

Trouble is, the entities (3rd party code) specifically compare against
logic level '1' on the wire in certain circumstances. So when the line
isn't driven, I see 'H' on ModelSim wave output but the VHDL code fails.

Is there any way in Verilog of forcing a pullup to '1', so that VHDL
comparisons against '1' succeed?

I don't think this has anything to do with it being a mixed language
setup. When I was coding VHDL a few years ago I ran into the exact
same thing with a completely VHDL setup. The top-level drove an 'H' on
the tristate bus, similar to the Verilog pullup.

I found two solutions. One, change the compare against '1' to compare
equal '1' or 'H'. I also tried using one of the millions of VHDL
functions (can't remember the name or the library - I've been happily
back doing Verilog for the last four years) that converted 4-value
logic to 2-value.

I think both of these would require you to change the entities, which
you didn't want to do. If anyone does have a way of fixing this just
by changing the testbench, I'd like to see it.

David

 

[Mark McDougall]

I found two solutions. One, change the compare against '1' to compare
equal '1' or 'H'.

I've found that there's a *single* assignment in the main entity that
reads the inout port and maps it to a signal. For now I've changed that
to an if-else construct so I can at least simulate the design. I may
even decide to leave it as-is for synthesis too.

I'd still like to know if there's a solution...

Regards,

 

[KJ]

I've found that there's a *single* assignment in the main entity that
reads the inout port and maps it to a signal. For now I've changed that
to an if-else construct so I can at least simulate the design. I may
even decide to leave it as-is for synthesis too.

I'd still like to know if there's a solution...

The 'To_X01" function is what you want. Assuming that 'Sig1' is the signal
that has the pullup and 'Sig2' is a newly created signal that will be used
in place of 'Sig1' inside the entity where it is currently being read
from....

signal Sig1, Sig2: std_logic;
....
Sig2 <= To_X01(Sig1);

KJ

 

[Mark McDougall]

The 'To_X01" function is what you want.

Yes, I am now using that in place of my earlier 'fix' using if-else.
However, this is done in the entity itself.

I want to know if it can be done in the testbench - where I don't know
which end of the wire is driving or when!?!

Regards,

 

[KJ]

Yes, I am now using that in place of my earlier 'fix' using if-else.
However, this is done in the entity itself.

I want to know if it can be done in the testbench - where I don't know
which end of the wire is driving or when!?!

Unless the testbench has access to the 'output enable' for all of the
drivers of the signal then the answer is 'no'. I'm assuming that you
don't have access to such output enable signals in the testbench since
if you did you would probably have figured out when to have the pullup
resistor drive a '1' or a 'Z'.

The problem though is not in your testbench but in the entity that is
incorrectly using this signal when using it as an input, so this is
where the proper fix needs to be made. Since (from the first post)
this is in 3rd party code then you should open a bug report to that 3rd
party and have them fix it (if you're paid up on support). If the 3rd
party doesn't provide support (or you're not paid up) then you need to
fix it yourself anyway.

Adding the To_X01() function is probably benign enough that it can be
done correctly while waiting for the 3rd party support or if there are
questions from your bosses about why the 3rd party code needs to be
modified (explain to them, the code has a bug, it's not perfect).

The only work around to fixing it properly is to have the resistor
drive a '1' when it 'knows' that nobody else is driving it (or at least
when the offending receiver is not using it as input) and a 'Z'
otherwise. The only way the pullup would 'know' is through some
additional information (i.e. the output enables). If you don't have
those output enables on the entity of all the drivers of that signal
then you would have to modify that 3rd party code also to get it...and
doing it that way would be a definite kludge and a flag that you're not
applying the proper fix.

KJ