1
\$\begingroup\$

I'm working on plugin for simulation software (digital IC only).
For example there is 8 bit bus.
User wants to read it's value. On plugin side I check each pin's state. It can be 1, 0 or undefined. At the moment if at least one bit is floating, I return nil as bus value. Is it right at all? May be better return value replacing floating bits with random [1-0] and warn user in log about it?

\$\endgroup\$
  • 1
    \$\begingroup\$ If the user has not enabled internal pull-up/pull-down resistors that are present on some devices then this implementation is up to you. If it were me I would likely return the undefined state or a random value as you have suggested since there is no way of knowing the state of this pin at sample-time. \$\endgroup\$ – sherrellbc Mar 15 '15 at 13:44
3
\$\begingroup\$

I'm sorry, but you're out of luck. There is no obvious way to tell if a digital input is floating. The bus receivers cannot tell if a given input voltage level is occurring because a driver wanted to, or if it's because there is no input driver. All it knows is that the input is either higher (logic 1) or lower (logic 0) than the receiver's threshold voltage.

It's certainly possible to build such a circuit:

schematic

simulate this circuit – Schematic created using CircuitLab

In this case, Vth is the nominal logic threshold voltage, and R4 is a largish resistance. R1/R2/R3 set the upper and lower error bounds for the input voltage.

In operation, a valid high or low on the input will pull it either above or below the comparator set points, and both comparators will read either high or low. This sets the XOR output low, indicating that the output is good. If the input is left floating, R4 pulls the input to an intermediate value, and one comparator goes high while the other goes low, and the XOR output is driven high, indicating a floating input.

Needless to say, I doubt very much that your digital inputs look like this.

\$\endgroup\$
  • \$\begingroup\$ The problem is I can know for sure pin is floating because it is up to simulator to decide is pin float or not. It is said that this is undefined value. But I have to set value to something. For example I took Z80 CPU and made simple circuit, I just turned it on and off several times. Address bus was always the same, though it's value is undefined on the very start. So it's better to replace floats with random, but not nulls? Sorry for my English \$\endgroup\$ – pugnator Mar 15 '15 at 14:37
  • 1
    \$\begingroup\$ If you were to use this circuit in practice, you would get a short "invalid" pulse on every H-L and L-H transition. You could put debounce on the invalid signal but even then it would be a massive hack. \$\endgroup\$ – nitro2k01 Mar 15 '15 at 18:44
  • 1
    \$\begingroup\$ @nitro2k01 - Oh, yeah. It's just one of a number of real-world implementation details that I didn't want to bother the OP about. And "massive hack" pretty much sums up my feelings. That's not to say I've never done any, just that this one doesn't seem worth the time and effort. \$\endgroup\$ – WhatRoughBeast Mar 15 '15 at 18:53
  • 1
    \$\begingroup\$ @pugnator - that depends on what the simulated circuit is going to do with the bus data. In the case of a Z80, for instance, I believe that a hex 00 is a no op, so initializing for that would be good if the simulated circuit actually operates on the bus data. On the other hand, if the simulated circuit doesn't actually do anything with the bus data, then a random value won't hurt anything. It all depends on the consequences of your choice. I don't know the details of you simulation, so I can't give you a definite answer. Sorry. \$\endgroup\$ – WhatRoughBeast Mar 15 '15 at 18:57
  • 1
    \$\begingroup\$ @WhatRoughBeast Roger that. I thought I'd point it out in case someone, somewhere thinks that this is actually a good idea. \$\endgroup\$ – nitro2k01 Mar 15 '15 at 19:36
2
\$\begingroup\$

In most simulation software, the bus data display depends on the number representation being used. The general rule is that if any of the bits that affect a particular display digit are undefined, then that digit is displayed as an 'X'.

When the display is in binary, octal or hex, the resulting number might have valid digits with 'X's among them, because each bit can only affect one digit. But if the display is in decimal, each display digit can be affected by any of the bits, so if any of the bits are undefined, then the entire bus value is displayed as 'XXXXXX'.

\$\endgroup\$
  • \$\begingroup\$ Thanks a lot about the tip, but I don't display values. I just reading the pins as tristate values and the questions is how to interpret it as a value to fill the corresponding registry \$\endgroup\$ – pugnator Mar 15 '15 at 14:41
2
\$\begingroup\$

There was an almost ghostly effect to be observed on 1980s computers with multiplexed address/data buses - reading from addresses where there was no device at all tended to give you what looked like an ASCII table in a debugger. What likely really happened was that you read back the capacitive charge remaining from the address writes.... feasible if there were MOS devices on the reading end.

In practice, it depends on the reading device and on what can interfere with the wiring: Almost all TTL-ish devices will treat a floating input as a solid 1 if there is no pulldown resistor and a lack of severe interference. CMOS inputs without a pulldown or pullup will indeed give you whatever the capacitive charge is in the wiring has in store, if there is a severe lack of interference - many times, floating CMOS inputs will give you a 50/60Hz clock.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.