Hello, I have a bus between Ethernet MAC and PHY in two separate subsheet connected through the root.
Definition of the bus:
Using it on the root page:
The MAC subsheet:
The PHY subsheet:
I got DRC errors. For the root:
for the MAC:
for the PHY:
I don’t clearly see the principles of KiCad busses; what is the problem with this schema?
Name these sheet pins:
Either {GIG_ETH} or ANY_PREFIX{GIG_ETH} to denote their bus nature and the “structure” of the bus that should connect.
E.g. from the vme_wren demo:
Thanks, John,
but it is not working.
I guess that I define the bus type in the hierarchical sheet with
so KiCad knows that ETH hierarchical label connects a bus of GIG_ETH type.
When I sync the subsheet box on the root page, the name comes from the hierarchical shhet:
If I manually edit the h.labels on the root page, I get DRC errors:
Thanks again for the effort, but any other guess?
T.
That is incorrect, you need to name the sheet pin like this (still from the vme_wren demo project):
If you want the pin to be named ETH, then it is ETH{GIG_ETH}, and you can access the members as ETH.TX_CLK rather than GIG_ETH.TX_CLK, which is what you’d have if you didn’t use a prefix.
Even leaving aside the mismatch of a bus and a single-wire name like ETH, having a label on the bus and the port is analogous to this:
Nets only get one name, so something will not be what you expect.
That’s working:) Many thanks!
One more follow up question: now I don’t need it, but let’s suppose
Exactly so. You need 4 hierarchical labels in the subsheet named just like that. You don’t need labels on the buses - they will get the name from the hierarchical label, just like a wire would.
SPI_A{SPI} will have members SPI_A.MOSI etc. And so on.
It came from a forum post or youtube video (?), that hier.label could be a simple name string and the connecting bus type was given by a net label, where the bus name is within { } indicating it was a bus. That syntax seemed logical to me…could have worked:)))
Cheers,
T.
Possibly that’s very old advice - busses had a huge overhaul around 5/6 era, maybe it worked like that? Or just an AI-like “hallucination” of how it feels like it should work.
To be fair, this exact case seems not super obvious from the manual right now.
Remember that a bus alias is just that, an alias. Alias-using labels with no prefix is a double-alias, for using the prefix is the bus alias name:
ETH{GIG_ETH} is just shorthand for a label {ETH.TX_CLK ETH.RX_CLK ....}{GIG_ETH} is shorthand for GIG_ETH{GIG_ETH}, which is shorthand for a label {GIG_ETH.TX_CLK GIG_ETH.RX_CLK ....}So {GIG_ETH} is not a special label that contributes “bus-nature” to something with a different name - it’s just an easier way to write {GIG_ETH.TX_CLK GIG_ETH.RX_CLK ....} (which you can also do if you really want!).
So, in {GIG_ETH}, the string GIG_ETH is doing double-duty: one is it’s saying which bus alias to expand, the other is what the prefix is.
Edit: see correction below that I found while writing up some manual content:
I was mistaken here - the VME Wren demo defines the buses like this:
So the prefix does NOT comes from the string PCIE in the alias, it’s baked into the alias definition. If you were to write P2{PCIE}, you’d get nets like P2.PCIE.PET_P.
So, what I should have written above was: {GIG_ETH} is not a special label that contributes “bus-nature” to something with a different name - it’s just an easier way to write {TX_CLK RX_CLK ....}
And the double-duty thing was rubbish.
Sorry for the confusion!