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

subsystem: update InterruptBusWrapper crossing code #2640

Merged
merged 5 commits into from
Sep 18, 2020

Conversation

hcook
Copy link
Member

@hcook hcook commented Sep 16, 2020

This updates InterruptBusWrapper in the following backwards-compatible ways:

  • It becomes a SimpleLazyModule with HasClockCrossings
  • But the wrapper layer is later inlined by FIRRTL
  • Parameterized clock crossing helper methods are exposed
  • But the legacy connection functions are preserved
  • No more use of deprecated IntXing

The beneficial effect beyond just modernization of APIs and more parameterizable crossing types is that the synchronization registers made by each crossing type will now be instantiated inside the InterruptBusWrapper hierarchically, each taking its clock and reset as their own. While in many cases the wrapper's clock and reset are the same as the subsystem clock and reset in which the from methods are presumed to be called (e.g. by the peripherals' attachTo methods), in certain cases these methods do get called inside some other scope. Thus this change should ensure that the synchronizing registers are always put in the destination clock domain, i.e. the one containing the InterruptBusWrapper and the PLIC, and not the hierarchy where the peripheral itself is attached.

Type of change: feature request

Impact: API addition (no impact on existing code)

Development Phase: implementation

Release Notes
Synchronizers

Copy link
Contributor

@rmac-sifive rmac-sifive left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was initially thinking it'd be nice to keep the optionality to instantiate synchronizers in the source domain, but on second thought I can't think of scenarios in which a designer would ever want to do that

@rmac-sifive rmac-sifive merged commit 4b613a2 into master Sep 18, 2020
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.

2 participants