-
Notifications
You must be signed in to change notification settings - Fork 620
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
Unify supernode/harness-clocking across chipyard/firesim/fpga #1474
Conversation
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.
This is niiiiiiice!
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.
Overall looks super nice. Couple of questions for clarification.
new chipyard.harness.WithHarnessBinderClockFreqMHz(50) ++ | ||
new chipyard.config.WithMemoryBusFrequency(50.0) ++ | ||
new chipyard.config.WithSystemBusFrequency(50.0) ++ | ||
new chipyard.config.WithPeripheryBusFrequency(50.0) ++ |
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.
A couple of questions on this:
- For FPGA prototypes, can you do multi-clock designs? Or are you enforced to have a single frequency across all clock domains? If that is the case, is there some
require/assert
to enforce this? - Why should the harness clock have a specific value? Can't you just choose the default fastest clock of the system and use that?
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.
For FPGA prototypes, can you do multi-clock designs? Or are you enforced to have a single frequency across all clock domains? If that is the case, is there some require/assert to enforce this?
The existing FPGA designs are all single clock. To support multi-clock FPGA, a HarnessClockInstantiator
variant would have to be designed that would configure the clock generator IP for that particular board. That is future work for the next use case which wants multi-clock-target FPGA prototypes.
The broadcast-single-clock approach is the simpler thing to do, and hopefully it can make it more clear how one might bring up a new board. The AllClocksFromHarnessClockInstantiator
will check/enforce that all requested clocks match the reference clock frequency.
Why should the harness clock have a specific value? Can't you just choose the default fastest clock of the system and use that?
Its not clear to me that using the fastest clock in the system is the most obvious behavior. On a realistic system, where the tile runs faster than the uncore, this doesn't really make sense.
Its also not clear to me that using the slowest clock is the most intuitive behvior either.
I feel like the most intuitive, and realistic, behavior, is for harness clocks to be completely async/unrelated with chip clocks.
A more aggressive refactor of the HarnessBinders could remove the harnessBinderClock
entirely, and force all HarnessBinders to request their own clock at whatever frequency they need, instead of relying on some implicit clock.
new chipyard.harness.WithHomogeneousMultiChip(n=4, new Config( | ||
new freechips.rocketchip.subsystem.WithExtMemSize((1 << 30) * 8L) ++ // 8GB DRAM per node | ||
new FireSimRocketConfig))) |
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.
Wow!
generators/chipyard/src/main/scala/harness/HasHarnessInstantiators.scala
Outdated
Show resolved
Hide resolved
generators/chipyard/src/main/scala/harness/HasHarnessInstantiators.scala
Show resolved
Hide resolved
generators/chipyard/src/main/scala/harness/HasHarnessInstantiators.scala
Show resolved
Hide resolved
generators/chipyard/src/main/scala/harness/HasHarnessInstantiators.scala
Show resolved
Hide resolved
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.
Overall looks super nice. Couple of questions for clarification.
This is nice! One question before I approve:
Let's say I am making a chip with multiple clocks, some of which are intended to be high-speed analog clocks. For simulation, this makes sense. But is a FPGA harness required to also generate those otherwise analog clocks and tie them to the reference clock? Or is there a mechanism for denoting that some clocks only apply to simulation but not for FPGA harnesses? |
If you are generating a design with high-speed analog clocks, what would you even want when putting the design on a FPGA? The analog blocks wouldn't be synthesizable, so you'd have to cut those out anyways. The FPGA prototype flows can be extended in the future to support multi-clock configurations under whatever constraints the FPGA PLLs and clock resources can support, this would involve only specifying a different HarnessClockInstantiator that ties chiptop clock domains to specific FPGA clock domains. |
Not true, we should be able to use behavioral models (or eventually, mixed-signal simulation). Anyways, if we are envisioning being able to have those additional FPGA clock domains, this should be trivial to support. |
Right, we should support multiclock prototypes with synthesizable models of analog blocks. |
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.
LGTM (lets hold off on merging this until mid-next week)
.github/scripts/run-tests.sh
Outdated
# Ibex cannot run the riscv-tests binaries for some reason | ||
# make run-binary-fast -C $LOCAL_SIM_DIR $DISABLE_SIM_PREREQ ${mapping[$1]} BINARY=$RISCV/riscv64-unknown-elf/share/riscv-tests/isa/rv32ui-p-simple |
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.
Do we have any easy way to compile a 32b test? If not, maybe we should just check that Ibex compiles (and not runs)
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.
Not at the moment, the default libgloss install is only rv64.
Ibex seems to fail this due to not implementing some necessary CSR 🤷♂️
This PR unifies TestHarness/SuperNode/HarnessClocking across chipyard/firesim/and firechip. This saves 200 LOC, while maintaining existing capabilities. It also makes it easier to bring up a new FPGA target, you can see the reduction in LOC in the ArtyHarness.
The general principle here is that there are two categories of clockSinks. ChipTops can request clocks for any clock ports they expose, at any frequency. The user will also specify a single frequency HarnessBinderFrequency that be provided to all the HarnessBinder collateral as the implicit clock.
The Harness generates the set of requested frequencies.
Changed
buildtopClock/Reset
->harnessBinderClock/Reset
: these are used to clock anything in a HarnessBinderwithClock(buildtopClock, buildtopReset)
no longer neededWithClockGroupsCombinedByName
changed to allow overriding previously set clock groupings. This allows theAbstractConfig
to specify a "default" set of clock groups across busesHasHarnessSignalReferences
->HasHarnessInstantiators
, this trait now does almost all harness-level HarnessBinder/clocking construction, deduplicating stuff across chipyard/firechip/fpgaMultiChip
in chipyardClockBridgeInstantiator
in firechip is refactored to fit chipyard'sHarnessClockInstantiator
APIRemoved
DefaultClockFrequencyKey
. Now clock frequencies must be either requested explicitly, or a clock group with no specified frequency will take the clock of a group it is combined with. This gets rid of one more user clocking API that is difficult to reason aboutTestChipMultiClockConfig
/TestChipBusFreqs
, nowChipLikeRocketConfig
demonstrates a tapeout-like designWithFireSimSimpleClocks
is removed, it is the same asWithPassthroughClockGenerator
WithFireSimHarnessClockBinder
is removed, it is the same asWithClockAndResetFromHarness
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
?