I was trying to help a colleague sort out a simulation problem and tracked it down to a connect module which seems to be stuck in a bad state. His test bench has an analogLib 0V voltage source from gnd! to VSS. This drives a number of things including the VSS pin on a block, I1. That VSS pin is inputOutput. Inside of the block is only instantiations of some blocks with functional views and the VSS pin connects to VSS input pins on those blocks. If I start checking signals in the results browser, VSS at the test bench level is electrical and is 0 volts. But inside of I1 it is logic and has value 1. When I run through all the internal signals in the connect module, what I find is Din == 1 -- the digital port d_strength == `SUPPLY isHiz == 0 sie == 1 (what exactly is SIE??) and because of that, these 3 tri-state buffers end up with BSU and BST in high-z state and BSUN in low-z state and we end up with a 1 instead of a 0 for VSS internal to I1. bufif1 (supply0, supply1) BSU(Din, Dreg, sie && (d_strength != `SUPPLY) && (isHiz == 0)); bufif1 (supply0, supply1) BSUN(Din, Din, sie && (d_strength == `SUPPLY) && (Din !== 1'bx) && (isHiz == 0)); bufif1 (strong0, strong1) BST(Din, Dreg, !sie && (isHiz == 0)); If I change the VSS pin on I1 to be input then I lose the Bidir_2 connect module in favor of an E2L_2 and things are fine. However, there are many blocks which need to be touched and some have verilog-a or RNM+EEnet models for supply current used by some sims. If I add 1 Ohm in series with that voltage source I see that indeed the connect module is trying its best to drive ground to a logic high. It appears that if something goes wrong in the initialization of the connect module that it will get stuck without anything to bump it loose. Is this something others have hit? -Dan![]()
↧