dfhdl.compiler.stages

This stage adds clock and reset input ports across the entire design. This stage is run after ExplicitClkRstCfg, so no Derived is expected here. The rules are:

1. Explicit Clk/Rst configuration always causes Clk/Rst port inputs to be added, unless they are already explicitly declared by the user or an internal design has outputs of Clk/Rst of the same configuration.
2. Related Clk/Rst configuration does not add Clk/Rst ports.

This stage adds missing magnet ports across the entire design. These will be connected at a later stage.

This stage breaks the following operations:

• constant index selection of anonymous vector concatenation
• constant field selection of anonymous struct concatenation
• assignment of anonymous vector/struct concatenation (conditioned upon breakAssignments) Ideally this stage is run after removing user opaques and before naming multiple anonymous references, to be most effective. Without removing user opaques first, we pass through anonymous to/from opaque casting while looking for the concatenation.

This stage creates explicit magnet port connections across the entire design.

This stage flattens the domains by removing them and changing their named members according to the flattening mode.

This stage moves the local vars or named constants (at the conditional/process block level) to either the design level (in Verilog) or its owner level (in VHDL), where the owner can be a design or a process. Verilog does not support declarations inside an always block, so they must be moved to the design level. VHDL does support declarations at the process level.

This stage drops all opaque types that fit within the applied filter predicate.

This stage drops reading internally from an output port, by creating an intermediate variable. This is typically required by backends like vhdl.v93 that cannot read from output

This stage drops process(all) by transforming it to a process with explicit sensitivity list

This stage converts a derived clock-reset configuration of RT designs/domains to explicit/related configurations. The rules are (when a derived configuration is discovered):

1. For a design, we first check its contents for Clk/Rst "usage", and if they are in use, the explicit configuration is taken from its owner, if such exists. If its owner is an ED domain or the design is top-level, the elaboration options' default configuration is used. If no Clk/Rst "usage" is detected, then the explicit configuration is set to None. Clk/Rst "usage" is indicated by any of the following:
   • a register declaration (for rst, a non-bubble init must be used to trigger rst usage)
   • a register alias (for rst, a non-bubble init must be used to trigger rst usage)
   • an internal design that has explicit Clk/Rst configuration
   • an explicit Clk/Rst declaration by the user
2. For a domain with non-Clk/Rst input port members, the explicit configuration is taken from its input source. The input source is determined by searching for a source that is registered and get its register's owner domain, and consequently its configuration. An earlier elaboration check should prevent any ambiguity from the source. One such possible ambiguity is having two domains that provide inputs and outputs to each other and both are declared with derived configuration. In this case, we get a circular derived configuration dependency, which should yield an error during elaboration.
3. For a domain with no input port members, the domain is considered to be a related domain of the domain's owner and the configuration is set accordingly.
4. When deriving a no-Rst configuration from a with-Rst configuration cfg, the derived config is set as cfg.norst, with the name mangling ${cfg.name}.norst. This name mangling is special-cased in various stages and compiler logic and used to indicated that both domain configurations are derived from one another.

This stage propagates initialization values to the reg alias init value, and removes all declaration initializations.

This stage globalizes design parameters that set port vector lengths. This is needed only for vhdl.v93 that does not support arrays with unconstrained ranges.

This stage transforms match statements/expressions to if statements/expressions

This stage names register aliases (e.g., x.reg) and replaces them with explicit register variables. The most complex mechanism about this stage is the naming conversion convention.

1. If .reg is applied on a named immutable value x or a mutated wire/port that is mutated only once, then that register variable will be named x_reg. If we have several register stages applied, then we create an enumeration. So x.reg(2) yields x_reg1 and x_reg2.
2. If .reg is applied on a named mutable wire x that is mutated more than once, then we treat every new .reg application as a new version of x. In this case we get an enumeration of the version. E.g.:

      val i = DFUInt(8) <> IN
      val o = DFUInt(8) <> OUT
      val x = DFUInt(8) <> VAR
      x := i
      o := x.reg //x_ver1_reg
      x := i + 1
      o := x.reg(2) //x_ver2_reg1, x_ver2_reg2

1. If .reg is applied on an anonymous value, then extrapolate a name suggestion based on the destination variable. This is part of the destination, so it adds _part suffix to the name of the destination. In case of several parts, we create an enumeration. E.g.:

      val i = DFUInt(8) <> IN
      val o = DFUInt(8) <> OUT
      val z = DFUInt(8) <> OUT
      o := (i + 1).reg //o_part_reg
      z := ((i + 1).reg + 7).reg(2) //z_part1_reg, z_part2_reg1, z_part2_reg2

This stage transforms a sequential process from a VHDL style to Verilog style. E.g.,

 process(clk):
   if (clk.rising)
     ....

is transformed into

 process(clk.rising):
   ....