flatten: update scopename regardless of hdlname existance

[mmicko]

Noticed this with bram cells, since they usually do have hdlname and in that case cell will only have that attribute set
(* hdlname = "soc cpu cpuregs regs1.0.0" *)

But with this change we will also get additional attribute (* scopename = "soc cpu cpuregs" *) so we can make sure that even cells with public name hdlname will have scopename set.

[whitequark]

I'm not completely sure that's necessary? Do we have the exact semantics of these attributes documented somewhere?

[KrystalDelusion]

The only mention of scopename in the docs can be found at https://yosyshq.readthedocs.io/projects/yosys/en/latest/cmd/index_passes_hierarchy.html#cmd-flatten (or equivalently yosys -h flatten)

Create 'scopename' attributes for objects with a private name. This attribute records the 'hdlname' of the enclosing scope. For objects with a public name the enclosing scope can be found via their 'hdlname' attribute.

Comment in code is

yosys/passes/hierarchy/flatten.cc

Lines 87 to 88 in e4044e1

	// Preserve original names via the hdlname attribute, but only for objects with a fully public name.
	// If the '-scopename' option is used, also preserve the containing scope of private objects if their scope is fully public.

[whitequark]

In my opinion, we should not intentionally denormalize attributes such that objects with existing hdlname attribute also gain a scopename: a compliant consumer should use (and prefer) hdlname when extracting the scope, only looking at scopename for objects with private names.

This is for two reasons:

1. It's wasteful to duplicate attributes like this in a large netlist (I don't think Yosys uses ropes or similar, meaning the attribute value storage may double in the worst case).
2. More importantly, this creates potential for unresolvable ambiguity: if hdlname and scopename do not agree, which one do you trust?

I don't think we ever fail validation due to issues with attributes, so I think (2) is a deal-breaker. But if we ever did denormalize the netlist in this way, we should fail validation in case the scenario from point (2) happens.

@KrystalDelusion Do you think you could extend the documentation to accurately reflect the semantics of these attributes?

[widlarizer]

As an aside, we would actually like to use rope-like things soon for path-like attributes

[whitequark]

I wasn't aware of this and it would indeed eliminate (1), but I think (2) on its own is a strong enough argument against duplication, with the verfication caveat above.

[widlarizer]

If we internalize those attributes, converting them to optimized implementations or constructing them from the start, we can also link hdlname and scopename such that we don't have them desync. They'd just get emitted at the end of a flow but we'd be accessing them within the improved flow with a more meaningful interface than strings. I'm not committing to it, but it seems like an option worth trying. In the mean time, while we rely on attribute-modeled information, I agree there's risks to making it redundant

[whitequark]

How do you ingest RTL where hdlname and scopename do not agree?

[KrystalDelusion]

Do you think you could extend the documentation to accurately reflect the semantics of these attributes?

Added it to the next Docs JF agenda

[widlarizer]

I added a Discourse thread and will be sharing it around to check if somebody doesn't like their scopenames overridden

[mmicko]

hdlname or scopename should be mutually exclusive