I have a schematic where I always get incomprehensible warnings about conflicts between output pins and tri-state pins. Granted that:
the schematic is absolutely correct and it works this way (it is a replica of a Z80 CPU board)
the address pins of the Z80 CPU are outputs (as per datasheet)
the pins of the 74LS245 buffer are tri-state
I would expect the same warning on all pins of all integrated circuits involved, and not only on some of them (see U40 and U41 in the images, but there are other ICs involved).
And the most bizarre thing is that repeating ERC more and more times, the warned pins may change!
And notice that part of the warnings are on one side and the remaining on the other side, even if all 16 pins are connected together.
Eeschema only prints each error once, and not on each pin of the net. There has probably never been given much thought to the pin that the message is printed on. The ERC errors indicate a net. not a pin.
KiCad also has no knowledge whatsoever about a Z80. It only knows it’s ERC matrix (See: Eeschema / Inspect / Electrical Rules Checker / Options (tab)
Hmmm,
a bit weird that according to the matrix, a connection between an “Output Pin” and a “Bidirecional Pin” is OK, but a connection between an “Output Pin” and a Tri-State Pin gives a warning.
My Z80 knowledge is rusty. (Last used 20+ years ago) but if the address bus can be tri-stated (which is necessary to connect U40 and U41, then for the ERC rules it should be a “Tri-State Pin”, and that would also better fit the actual use of the pin, regardless of what is printed in the datasheet.
Also:
You’ve got 24 ERC errors, but only 16 address lines. What are those other 8 errors?
An output <> tri-state gives a warning because if you turned the tri-state to driving mode rather than high-Z mode, you’d have two drivers on the same net. A bidirectional pin doesn’t give this warning by default because it’s assumed you have configured it in “input” mode.
/MREQ -> pin 19 of Z80 and pin 12 of U38 (74LS245)
/RD -> pin 21 of Z80 and pin 14 of U38
/WR -> pin 22 of Z80 and pin 13 of U38
/IORQ -> pin 20 of Z80 and pin 11 of U38
Pin 19 (output) of U42 (PAL16L8) and pin 2 of U15 (74LS245)
Pin 19 (output) of U42 (PAL16L8) and pin 9 of U19 (74LS367)
Pin 12 (output) of U42 (PAL16L8) and pin 2 of U13 (74LS373)
Pin 12 (output) of U42 (PAL16L8) and pin 3 of U19 (74LS367)
I know that I could change the ERC matrix, but the new state is not saved in the project, as far as I know.
My Z80 knowledge is rusty. (Last used 20+ years ago) but if the address
bus can be tri-stated (which is necessary to connect U40 and U41, then
for the ERC rules it should be a “Tri-State Pin”, and that would also better
fit the actual use of the pin, regardless of what is printed in the datasheet.
The Z80 manual asserts that A0…A15 are outputs (but I have some doubts: an address can be put on the bus, so I assume that the Z80 reads the address and hence A0…A15 are inputs in that particular moment, but I could be wrong).
Also the Z80 symbol furnished with KiCad library defines A0…A15 as outputs. Should I have to make a new copy of the symbol defining A0…A15 as bidirectional?
ok, I see, but it’s not the case of this schematic that is working as it should. Unfortunately the suppression of that particular warning in the ERC matrix is not saved with the project and pops out every time the project is reopened.
The Z-80 manual I just downloaded from Zilog states:
A15–A0.Address Bus (output, active High, tristate). A15–A0 form a 16-bit Address Bus, which provides the addresses for memory data bus exchanges (up to 64 KB) and for I/O device exchanges.
The address bus has to be tri-state to allow DMA operations. Fix the part definition.
They all involve U42 that is a programmed PAL 16L8 with 8 outputs, two of which are only outputs (pin 19 and 12) and the other six can be I/O. The symbol was not available so I have created it, defining pins 19 and 12 as outputs, and the other six I/O as tri-state, but I suppose that there is nothing else that I can do.
If pin 19 of U42 (your PAL) is electrically output-only, and it is connected to pin 13 of U29 (D7 of the Z80), you have an electronic design error, not a KiCad problem.
KiCad is warning you that if the Z80 drives D7 (which it will during any write cycle), you will have two outputs driving the same net. This is a valid warning. Ignoring the warning will result in you making a board that will not work.
Instead of arguing based on the information you gave, I searched for the PAL16L8 on octopart and then looked at the TI datasheet. Here is the first page (my highlights):
The two output only pins are tri-state pins. (Looks like only 2 states, output or high-Z, but tri-state refers to three output states of HIGH, LOW, and high-Z.) Change your symbol to reflect that and you should correct the ERC issues appropriately.
FWIW, I know very little about PALs or GALs or even FPGAs, but I think that table on page 1 of the data sheet is very clear even to my uninformed eyes. I’m not blaming you for not noticing this, though. I don’t know how many times I’ve had a problem understanding a part of a chip until someone else (with fresh eyes) pointed out something just as obvious to me.
no, there is not any design error. The schematic has been reproduced from the original, taken from the card manual. Of course, when pins 19 and 12 of the PAL output their data, the receivers are set appropriately.
thank you for the indication. The only datasheets that I own are ancient and there is no indication of the type of the outputs. So now I can correct the symbol.
Yeah, this would indicate a tri-state. Another indicator of a tri-state output is an output enable pin. If this were a true output pin it would always be trying to assert either a logic high or a logic low, thus the reason for the ERC warning.
I think that some of the confusion about the difference between bidirectional and tri-state is electrically they are similar. When the bidirectional pin is in Input mode it is often in high-Z so electrically would look like a tri-state in high-Z mode. The difference is when analyzing information flow, the tri-state will ignore logic levels. See this quote from above:
I think the reason for the warning connecting an output to a tri-state is because the output pin should be expected to always trying to assert a logic level there won’t be any time for the tri-state to safely leave it’s high-Z “off” mode to assert it’s logic level. But it’s ok to connect the bidirectional pin to an output because the pin can still do a task of reading the input.
I also made this mistake of forgetting that a tri-state is output only when writing my response where I screenshotted the datasheet page. I heavily re-wrote the paragraph after the screenshot within a minute of posting (fast enough that it didn’t trigger the post-edited flag).
Effectively, it’s very strange to define as tri-state a pin that has only two states. Pins 19 and 12 will NEVER be inputs. Anyway, I suspect that also the six I/O pins should be tri-state. The PAL marked U42 in this circuit sets its outputs at High-Z immediately after power-on and after having set the initial jump address on the address bus.
But you see, those pins do have three states, this means three output states:
Drive the output HIGH.
Drive the output LOW.
Don’t drive the output (this is the high-Z state I was referring to, above).
BTW, your symbol looks good. Though I might be tempted to put the two tri-states next to each other. Unless for your schematic layout you get less crossing lines with them on either side of the I/O bus, then keep it as is.
