Skip to content

Ports in groups

Jump to bottom
Erik Carstensen edited this page Feb 24, 2022 · 9 revisions

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.

dev.port.g.p

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 and bank_portname, defaulting to parent.objkind == "device" #? "port." + name : name (s/port/bank/ for bank_portname). Both params are available on groups, banks and ports, and the full name of a port is the sum of obj.port_portname for all objects in the hierarchy, so in:

group g {
  port_portname = "x.g";
  bank b {
    param port_portname = "y.b";
    port p {
      param port_portname = "z.p";
}}}

... you will get dev.x.g.y.b.z.p and dev.bank.g.b.

dev.g.p

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 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." + name #: name in ports, the same with s/port/bank/ in banks, and name in groups.

group g {
  param portname = "x.g";
  bank b {
    param portname = "y.b";
    port p {
      param portname = "z.p";
}}}

then the bank's name is dev.x.g.y.b and the port's name is dev.x.g.y.b.z.p.

dev.g.port.p

The idea here is that "all ports are prefixed with 'port.' by default". I.e., the portname param works as in the previous design, but the default value is "port." + name in ports, "bank." + name in banks, and name 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 name.

Clone this wiki locally