Standardize Tile Instantiation and Attachment

[hcook]

HasTiles is refactored to eagerly instantiate tiles of all types by pulling instances of CanAttachTile out of a new Field named TilesLocated.

This change has the following benefits:

• Any class <: BaseTile can be Config-urably instantiated inside a design without needing to mix in additional traits to the subsystem class hierarchy.
• Various subsystem user code that would like to operate over the tiles list (e.g. nTiles) does not have to jump through hoops to ensure that it doesn't get called before all tile-adding traits are mixed in, because those traits no longer exist.

In order to make a tile instantiate-able via the new field, you must supply a class like this one:

case class RocketTileAttachParams(
  tileParams: RocketTileParams,
  crossingParams: RocketCrossingParams,
  lookup: LookupByHartIdImpl
) extends CanAttachTile { type TileType = RocketTile }

where

• tileParams satisfies the new base class InstantiableTileParams[TileType] (you provide a function that instantiates an instance of your TileType)
• crossingParams satisfies TileCrossingParamsLike, for which you could just use the example RocketCrossingParams.

Backwards compatibility:

• Tiles can still be instantiated and attached manually via traits:

trait HasMyTiles extends HasTiles {
  val myTiles: Seq[MyTile] = p(MyTileField).map { ... }
  override val tiles = myTiles ++ super[HasTiles].tiles

• However, if you do so, be aware that you will have to also manually connect your tiles.
• The Fields RocketTilesKey and RocketCrossingKey are maintained for backwards compatibility and LegacyTileFieldHelper is applied to TilesLocated in BaseConfig to ensure that Config alterations that manipulate these fields continue to function
• BaseTile now extends HasLogicalTreeNode, but a GenericLogicalTreeNode() is supplied, which can be overridden.

Type of change: other enhancement

Impact: API modification

Development Phase: implementation

Release Notes
val tiles in trait HasTiles is now populated eagerly via the TilesLocated Field.

[aswaterman]

Seems like a good direction API-wise (but I didn't do a code review).

[jerryz123]

Will there be an example for what direct manipulation of the TilesLocated pattern looks like? (Not using the LegacyTileFieldHelper)

[hcook]

Good suggestion, will do

[hcook]

I ended up doing this example in WithTraceGen for the TraceGenTile subtype. I'm not very keen to mess too much with the existing RocketTilesKey Config alterations since it it seems hard to change them while remaining backwards compatibly with external alterations of RocketTilesKey. Check out WithTraceGen and HeterogeneousTileExampleConfig and let me know if that is sufficiently helpful.

[jerryz123]

Thanks, this is pretty clear.

I noticed that manipulation of core parameters is more verbose without direct access through CoreTilesKey, since the type of the core must be matched, and since AttachParams adds another layer of case-class nesting. Given that manipulating tile-level parameters is the common use-case of the core-specific TilesKey s, it may be worth defining a generic macro to modify the TileParams matching some desired Tile type.

[hcook]

if you can figure out a good pattern for applying a "lens" to nested case classes in Config alterations I will buy you a beer

[hcook]

But yes something specific to this particular use case is probably also possible