Custom ChipTop/DigitalTop and Configs

[lsteveol]

I have been trying to figure out a clean-ish way to support different ChipTop/DigitalTop instances and Configs based on certain use cases. For example I have added some custom AXI/TL ports to connect memory mapped IPs. I generally don't generated the ChipTop but the DigitalTop or my version of it. Currently I have been creating my own DigitalTop, ChipyardSystem, and ChipyardSubsystem, as well as changing the ChipTop BuildSystem key to be whatever my DigitalTop is. This isn't too bad, however I'm sure there is a better way to do it.

Looking at the Chipyard docs (https://chipyard.readthedocs.io/en/latest/Customization/Custom-Chisel.html and the remainder of section 6), it appears that you can just include a submodule. This works, however I seem to have an issue getting the Generator to recognize any custom DigitalTops that I create. For example I would try

class WMLDigitalTop(implicit p: Parameters) extends DigitalTop
  with chipyard.CanHavePeripheryWMLNVDLA
{
  override lazy val module = new WMLDigitalTopModule(this)
}

class WMLDigitalTopModule[+L <: WMLDigitalTop](l: L) extends ChipyardSystemModule(l)

This would be in a generators/mysubmodule dir which should be found by the common.mk SCALA_SOURCES var.

When building I would pass

make CONFIG=<myconfig> TOP=WMLDigitalTop

It breaks at the GenerateTopandHarness stage. My assumption is either a) the scala files is not being picked up or b) there is soemthing specific that the generators are looking for and I either need to overload those, or what I want to do just isn't possible.

If I take https://chipyard.readthedocs.io/en/latest/Customization/MMIO-Peripherals.html#constructing-the-digitaltop-and-config as an example with the GCD. The ReadTheDocs shows that you would modify DigitalTop and the other respective Configs. I would prefer to create something like a GCDDigitalTop (and GCDChipTop if I wanted a ChipTop), then give a Config.

Hopefully that is a clear example.

Is what I'm trying to do possible? And if so, am I even on the right track?

Thanks

[lsteveol]

Currently I have been creating my own DigitalTop, ChipyardSystem, and ChipyardSubsystem, as well as changing the ChipTop BuildSystem key to be whatever my DigitalTop is. This isn't too bad, however I'm sure there is a better way to do it.

Also to be clear what I mean by this. I created separate files that are essentially the DigitalTop, ChipTop, *System and copy them into the generators/chipyard/src/main/scala dir. Effectivetly overwriting the old ones

[alonamid]

What you're doing seems to make sense. Can you tell us a little bit more about the errors you're getting?

[lsteveol]

Hi @alonamid , thanks for the response. Let me try to put together another example.

IIRC, I was getting an error that WMLDigitalTop was unknown. It was acting as if my .scala files were not being picked up, however if I printed SCALA_SOURCES it would show the file, so I don't think that was the issue.

[michael-etzkorn]

What does your config look like? I know bringup in the vcu118 custom config example does an override:

class WithBringupVCU118System extends Config((site, here, up) => {
  case BuildSystem => (p: Parameters) => new BringupVCU118DigitalTop()(p) // use the VCU118-extended bringup digital top
})

[michael-etzkorn]

I'm also noticing this as I'm trying to extend Digital Top instead of modifying it inside my own generators/project. It seems like these projects are expected to be dependencies of generators/chipyard? But then how would I use generators/chipyard classes in my project? Maybe the solution is making chipyard the dependency of my project instead, but I feel like there'd be required changes in the build process to do that.

[alonamid]

generators/chipyard is the top-level sbt project. If your generators/project is a subcomponent/block, then it would usually depend on generators/rocketchip rather that generator/project. If your project is a complete SoC, then the recommended workflow is to use configurations and mix-ins which can be mixed with the chipyard top-level rather than defining a new project.