![]() |
|
|
|
#1 |
|
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, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266 Mark McDougall |
|
|
|
|
#2 |
|
Posts: n/a
|
Mark McDougall wrote: > 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 unfrostedpoptart |
|
|
|
#3 |
|
Posts: n/a
|
unfrostedpoptart wrote:
> 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, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266 Mark McDougall |
|
|
|
#4 |
|
Posts: n/a
|
"Mark McDougall" <> wrote in message news:45405757$0$15649$... > unfrostedpoptart wrote: > >> 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... > 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 KJ |
|
|
|
#5 |
|
Posts: n/a
|
KJ wrote:
> 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, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266 Mark McDougall |
|
|
|
#6 |
|
Posts: n/a
|
Mark McDougall wrote: > KJ wrote: > > > 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!?! > 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 KJ |
|