Hi, I have a design using a lpddr4 memory and I specified a bus Alias with all the signals related to this interface.

please advise how to assign a net class to this alias.
Using the same name as in the schematic {lpddr4} is not working
the schematic allows the unfolding of the bus:
means the Alias is working properbly.
would be great if I can use this Alias to assign the required netclasses to it.
Thanks, Rolf
Aliases are just that: another name for the bus, which would otherwise be something gruesome like {dq[31..0] dqsn[3..0] dqsp[3..0] dm[3..0] ... etc ...}
. The actual nets themselves are still called, for example, /dq31
and /cke
. They don’t “know” they’re in a bus alias, and the patterns are just text comparisons - they don’t look up/expand bus aliases.
One way to do what you want by text assignments is name the alias myprefix{lpddr4}
(you can choose the prefix) and then the nets will be named /myprefix.dq31
, etc., and you can match with the netclass assignment pattern /myprefix.*
.
The bus alias documentation was literally just expanded in this area yesterday with an example, perhaps it may help: Schematic Editor | master | English | Documentation | KiCad
You can also use a directive label, which can attach to the bus: Schematic Editor | master | English | Documentation | KiCad
Hi johnbeard,
thanks for the quick response, unfortunately I didn’t get your point. where should I add the prefix? Adding in the bus alias didn’t work

no longer able to unfold the bus signals.
Would be great to add the information as an example in the document - I don’t understand the USB example 
- Adding a net class to the bus seems not to work too:
adding the netclass lpddr4
sill results in the “Default Netclass” in the bottom status line.
add the prefix?
You add the prefix as the label of the bus. So prefix{bus_alias_name}
. bus_alias_name
in this case is lpddr4
and it what you put in the bus alias definition.
I do find it hard to word things so that they make sense when you don’t already know the subject. Would this change make it clearer to you? For
You can also add a prefix name to the group, such as USB1{USB}
, which results in nets such as USB1.DP
.
to something like:
You can also add a prefix name to the group**'s label**. For example, the label USB1{USB}
, results in nets such as USB1.DP
. This can make it easier to write net class assignment rules for buses of that type.
As for the directive label… That may be a bug. I’ll get back to you on that!
1 Like
OK, the directive label does work correctly, it’s just the bus label does have to match the bus alias for it to work, and I had it wrong in my test project. If it does not, it won’t match the right nets, and you’ll also get ERC errors for nets touching buses they are not members of.
So in your case, make your alias exactly as you did here:

Name your blue bus line with a normal label, just as you would a wire.
To assign a netclass, any of these will do:
- use a netclass assignment to assign
/prefix.*
to your net class.
- Use a prefix to make this easier. For example label the bus with
prefix{lpddr4}
(where prefix
can be anything, including lpddr4
if you want). The {lpddr4}
must be contain exactly the name of the alias.
- use a directive label with the net class attached to the net
- use a directive label with the net class attached to a rule area - applies to all wires and buses that pass through