Avoid Subsystem Implicit Clock #2719
Conversation
| plic.node := tlbus.coupleTo("plic") { TLFragmenter(tlbus) := _ } | ||
| plic.intnode :=* ibus.toPLIC | ||
|
|
||
| // TODO: What should be responsible for defining the ibus domain when there's no PLIC? | ||
| ibus.interruptBusDomainWrapper.clockNode := tlbus.fixedClockNode |
There was a problem hiding this comment.
Yeah this gets at the heart of why I didn't want to put the PLIC inside the TLBusWrapper its tilelink port is attached to. A situation where IBus is on its own clock domain, the PLIC is on that clock domain, and the crossing is put between the TileLink control port of the PLIC and the TLBus a very plausible scenario that we are interested in enabling. Not to say you have to add the crossing capability now in this trait. I think this particular line of code can just go live here alongside some other associated technical debt (and just change tlbus to sbus)
There was a problem hiding this comment.
Just to check i understand you correctly: this will put the IBus in the same domain as the SBus for now. Would this not be problematic if the CBus and SBus are running at different frequencies, given where the PLIC attaches by default currently?
If so, I'm alright with this. I think we're probably going to just mandate CBUS = SBUS = FBUS for the time being in Chipyard anyways.
There was a problem hiding this comment.
CBUS = SBUS = FBUS
Yes we have a similar mandate for similar simplifying reasons, and only tweak the amount of synchronous buffering that is inserted between those three. But I want to be able to move to a situation where the domains are {SBUS}x{CBUS}x{IBUS,PLIC}x{TILES}. This does mean the PLIC will need more XType arguments to describe its relationship to CBUS and TILES than it currently has, but I think this approach is moving it in that direction, whereas the previous one wedded PLIC to CBUS by hierarchically including it there which I think we would have to walk back later.
There was a problem hiding this comment.
Can you make the change of handling this in BaseSubsystem for now? Then I think we are good to go and I will do some testing.
There was a problem hiding this comment.
Yeah, i'll do that now.
There was a problem hiding this comment.
{SBUS}x{CBUS}x{IBUS,PLIC}x{TILES}
Yeah, this would be great.
An alternate implementation to #2622.
Two problems:
I think it would be really cool if we had a mixin for LazyModule,This is effectively covered by extendingDiplomaticImplicitClockAndResetor something, that would add a ClockSinkNode and automatically drive the ModuleImp's implicit clock and reset using that node's resulting clock bundle.ClockSinkDomain.Related issue:
Type of change other enhancement
Impact: API modification
Development Phase: proposal
Release Notes