"inconsistent net value" between tri-state buffer output and input/output pin

[logoliv]

I have this issue message when I enable the bottom tri-state buffer on this schematic :

Shouldn't the db[7..0] input/output pin take the tri-state buffer output value instead ? I think that's an incorrect behaviour from the I/O pins, what do you think @flandreas ?

[flandreas]

@logoliv I guess you first have clicked on the "db[7..0]" inout and thereby asserted the signal 4C on the wire. Now, the inout still asserts this same value, which collides with another value if you enable the ti-state buffer.

Try to set inout "db[7..0]" to "undefined" by clicking on it and entering "Z" before enabling the tri-state buffer.

[logoliv]

Yes it works with "ZZ" as initial value but it should also work in any case : when i'll be using this as a subcircuit the I/O pin will have a value... The same happens with the I/O pin D[7..0] and the tri-state buffer on the right.

I absolutely need the I/O pins to behave correctly or I won't be able to continue my project with Antares 😢

[flandreas]

When you use this as a subcircuit, "bus db oe" is only allowed to go to 1 if the bus connected to "db[0..7]" is undefined, or else you would have conflicts anyway. But when the bus is undefined, the IO pin is undefined as well, and there is no conflict.

I'm pretty sure the conflict in your scenario only occurs because you've clicked on the inout pin and manually entered a value. This value is then stuck until you enter "undefined". This is not the case when using the circuit as a subcircuit.

[logoliv]

I will trust you on this one because I don't yet know how the CPU is made 😄

However it's strange that when the value of a I/O pin is set by the tri-state buffer it can be reset to ZZ when closing it (normal behaviour as the output is then undetermined) but it isn't the case if I had manually set the I/O pin value before and when I close the buffer... Why isn't the behaviour of tri-state buffers the same in all cases ?

[flandreas]

It's not the behaviour of the tri-state buffer. It's the inout component. When you click on the inout during simulation, it behaves like a switch: The pressed state remains. It doesn't go away when an another component asserts a signal to the same wire. If the signals differ, a conflict occurs.

However, if you use the circuit as subcircuit, there is no "clicking" on the inout component, and signals flow freely through the inout.

[logoliv]

Speaking of that, what's the purpose of the "switch" property for the inout component ?

However, if you use the circuit as subcircuit, there is no "clicking" on the inout component, and signals flow freely through the inout.

You reassure me somewhat for my project, because I was asking myself since your first answer : "I will need to assign at least manually a value to the address pins of my CPU so it can read its first program instruction, so won't I be able to test it ?"

I think it would be profitable that I temporarily stop my project to dive deeply into the Tanenbaum example, I would learn a lot and it will also certainly serve me afterwards 💡

[flandreas]

Speaking of that, what's the purpose of the "switch" property for the inout component ?

It's the same property like on the switch component. I use it for CLK inputs when testing subcircuits: If "Switch " is unchecked, a full clock cycle requires only 1 click and 1 release on the mouse button.

[logoliv]

good to know, I will use that for my clock pins 👍