-
Notifications
You must be signed in to change notification settings - Fork 49
Ports in groups
We want to permit group g { port p; }; here's some design sketches for how to do this.
We have some different options, which I have parameterized by how you expect the port prefix to appear in the port object name.
The idea is that all ports appear under the dev.port namespace, so the g prefix appears after that.
A sibling bank b would appear as a second cousin, in dev.bank.g.b. For this reason, we need two params to define prefix, param port_portname_prefix and bank_portname_prefix, defaulting to parent.objkind == "device" #? "port." : "" (s/port/bank/ for bank_portname_prefix). Both params are available on groups, banks and ports, and the full name of a port is the sum of obj.port_portname_prefix + obj.name for all objects in the hierarchy, so in:
group g {
port_portname_prefix = "x.";
bank b {
param port_portname_prefix = "y.";
port p {
param port_portname_prefix = "z.";
}}}
... you will get dev.x.g.y.b.z.p and dev.bank.g.b.
The idea here is that the port prefix only appears directly under dev, as a common special case for top-level port objects. No prefix is added for any other objects; you generally create group indirections to control the namespace.
A single param portname_prefix is available, in port, bank and group objects (not strictly necessary in groups). Its primary purpose is to suppress port. on top level, and defaults to parent.objkind == "device" #? "port." #: "" in ports, the same with s/port/bank/ in banks, and "" in groups.
group g {
param portname_prefix = "x.";
bank b {
param portname_prefix = "y.";
port p {
param portname_prefix = "z.";
}}}
then the bank's name is dev.x.g.y.b and the port's name is dev.x.g.y.b.z.p.
The idea here is that "all ports are prefixed with 'port.' by default". I.e., the portname_prefix param works as in the previous design, but the default value is "port." in ports, "bank." in banks, and "" in groups. This is a simple rule that arguably is a natural generalization of current behaviour, but it's probably seldom what you want so it will be common to override the param with "".