-
Notifications
You must be signed in to change notification settings - Fork 653
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
FIX (peripheral): add support for instantiating multiple peripherals of same type #1397
Conversation
case PeripheryUARTKey => Seq( | ||
UARTParams(address = 0x54000000L, nTxEntries = 256, nRxEntries = 256, initBaudRate = baudrate)) | ||
UARTParams(address = address, nTxEntries = 256, nRxEntries = 256, initBaudRate = baudrate)) | ||
}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think an API that makes more sense to me is: class WithUARTOverride(no: Int, ...)
where the no
is the index in the PeripheryUARTKey
Seq
to override.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or if you want to truely override the entire key I would have two APIs:
- one called
WithUARTOverride
that takes a Seq of tuples (enforced to be size of 2 - where the 1st element in the tuple is the address and the 2nd is the baudrate) that gets unrolled into multiple UARTParams. - another that is the additive uart (same as the current
WithUART
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually prefer the style here, as it matches how the WithNCores behaves
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ideally, we should get rid of the default UART (i.e. when user does not specify WithUART
, we shouldn't include a UART in the SoC).
I could not find where it adds the default UART though, so this is a hack to override the default parameter, and also to prevent error message when using WithUART
only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default UART is given here:
new chipyard.config.WithUART ++ // add a UART |
We have the CY config have a UART by default so that we can boot Linux easily in SW-RTL sims.
I actually think we can change the default implementation of WithUART
here:
chipyard/generators/chipyard/src/main/scala/config/fragments/PeripheralFragments.scala
Lines 35 to 38 in 44abc91
class WithUART(baudrate: BigInt = 115200) extends Config((site, here, up) => { | |
case PeripheryUARTKey => Seq( | |
UARTParams(address = 0x54000000L, nTxEntries = 256, nRxEntries = 256, initBaudRate = baudrate)) | |
}) |
To essentially be the "override" config (i.e. generalize it to override all the Seq[UARTParams]
given a Seq
of tuples) and renaming it as such WithUARTOverride
. Then we can keep the current implementation of WithUART
seen here (where it's additive and like WithN...Cores
) and just move it to the PeripheralFragments.scala
file.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to keep the default UART. There's hardly a good reason to build a SoC without a UART....
The default UART config should be close to "universal".. that is, rarely should users need to change the address/params of that UART.
Additional WithUART flags can add more UARTs at other addresses to the system..
We should have an additional WithUARTOverride fragment for special cases when the default UART settings are not correct ... I don't think that fragment will be used very frequently, but it should be available at least.
changelog:changed
Change how peripherals are included, so that user can instantiate multiple peripheral devices of same type in chip config.
Related PRs / Issues:
Type of change:
Impact:
Contributor Checklist:
main
as the base branch?changelog:<topic>
label?changelog:
label?.conda-lock.yml
file if you updated the conda requirements file?Please Backport
?