Draft
Conversation
sequencer
commented
Mar 10, 2024
|
|
||
| /** Layers of hierarchy with this trait contain attachment points for TileLink interfaces */ | ||
| trait HasTileLinkLocations extends HasPRCILocations { this: LazyModule => | ||
| trait HasTileLinkLocations extends HasLocations with LazyScope { this: LazyModule => |
Member
Author
There was a problem hiding this comment.
I think we dont need HasLocations here.
| /** Subclasses of this trait have the ability to instantiate things inside a context that has TL attachement locations */ | ||
| trait CanInstantiateWithinContextThatHasTileLinkLocations { | ||
| def instantiate(context: HasTileLinkLocations)(implicit p: Parameters): Unit | ||
| def instantiate(context: HasTileLinkLocations with HasPRCILocations with LazyModule)(implicit p: Parameters): Unit |
Member
Author
There was a problem hiding this comment.
originally the
HasTileLinkLocations couples HasPRCILocations to much. It's a bad design pattern.
| * what is being made available via the LocationMaps in trait HasTileLinkLocations. | ||
| */ | ||
| trait Attachable extends HasTileLinkLocations { this: LazyModule => | ||
| trait Attachable extends HasTileLinkLocations with HasPRCILocations { this: LazyModule => |
Member
Author
There was a problem hiding this comment.
Maybe rename Attachable to TLAttachable?
| lazy val location = InCluster(clusterId) | ||
|
|
||
| lazy val allClockGroupsNode = ClockGroupIdentityNode() | ||
| // lazy val allClockGroupsNode = ClockGroupIdentityNode() |
Member
Author
There was a problem hiding this comment.
I'm not so sure about this...
| private val clockGroup = LazyModule(new ClockGroup(busName){ override def shouldBeInlined = true }) | ||
| val clockGroupNode = clockGroupAggregator.node // other bus clock groups attach here | ||
| val clockNode = clockGroup.node | ||
| val clockNode = ClockAdapterNode() |
Member
Author
There was a problem hiding this comment.
Need to assert input to this clockNode to be 1? or just use FixedClockBroadcast instead?
sequencer
force-pushed
the
no-more-clockgroup
branch
from
15c9041 to
ab61e47
Compare
sequencer
force-pushed
the
no-more-clockgroup
branch
4 times, most recently
from
38a8752 to
9505d87
Compare
sequencer
force-pushed
the
no-more-clockgroup
branch
from
9505d87 to
fdd303a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The Current ClockGroup API is misleading and is strange design pattern for clock doamins. This PR is used for purging out all the ClockGroup usage in rocket-chip, providing a clean API for ClockNode Attaching.