Skip to content
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

Closed
wants to merge 2 commits into from
Closed

FIX (peripheral): add support for instantiating multiple peripherals of same type #1397

wants to merge 2 commits into from

Conversation

T-K-233
Copy link
Member

@T-K-233 T-K-233 commented Mar 12, 2023

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:

  • Bug fix
  • New feature
  • Other enhancement

Impact:

  • RTL change
  • Software change (RISC-V software)
  • Build system change
  • Other

Contributor Checklist:

  • Did you set main as the base branch?
  • Is this PR's title suitable for inclusion in the changelog and have you added a changelog:<topic> label?
  • Did you state the type-of-change/impact?
  • Did you delete any extraneous prints/debugging code?
  • Did you mark the PR with a changelog: label?
  • (If applicable) Did you update the conda .conda-lock.yml file if you updated the conda requirements file?
  • (If applicable) Did you add documentation for the feature?
  • (If applicable) Did you add a test demonstrating the PR?
  • (If applicable) Did you mark the PR as Please Backport?

@T-K-233 T-K-233 changed the title [changelog:changed] FIX (peripheral): add support for instantiating multiple peripherals of same type FIX (peripheral): add support for instantiating multiple peripherals of same type Mar 12, 2023
@T-K-233 T-K-233 marked this pull request as draft March 12, 2023 06:09
@T-K-233 T-K-233 marked this pull request as ready for review March 12, 2023 06:11
case PeripheryUARTKey => Seq(
UARTParams(address = 0x54000000L, nTxEntries = 256, nRxEntries = 256, initBaudRate = baudrate))
UARTParams(address = address, nTxEntries = 256, nRxEntries = 256, initBaudRate = baudrate))
})
Copy link
Contributor

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.

Copy link
Contributor

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)

Copy link
Contributor

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

Copy link
Member Author

@T-K-233 T-K-233 Mar 12, 2023

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.

Copy link
Contributor

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:

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.

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants