Add support for NoC based interconnect with Constellation #1224
Conversation
| # Constellation can run without espresso, but this improves | ||
| # elaboration time drastically | ||
| pushd $REMOTE_CHIPYARD_DIR/generators/constellation | ||
| scripts/install-espresso.sh $RISCV |
There was a problem hiding this comment.
What is espresso? Is this like graalvm?
There was a problem hiding this comment.
https://github.com/chipsalliance/espresso .
Espresso is a logic minimizer that Constellation calls (through chisel3) to generate routing tables.
If espresso is not installed, the generator falls back on a slower implementation.
There was a problem hiding this comment.
I'm inclined to just add this installation in build-toolchains-extra.sh and add a flag to skip this if users don't want it.
There was a problem hiding this comment.
I'm going to leave it in like this for now, to avoid more churn on the install scripts.
There was a problem hiding this comment.
Sure. Can you make an issue so this is noted and we can put it into the next release? I get the feeling that majority of people won't have this installed and will complain about slowness
There was a problem hiding this comment.
Sure, I added an issue. There has been discussion of packaging espresso as a Scala library so it can just be added as a SBT dependency to Chisel, but I don't think there's been any progress on that.
Also, the performance improvement is only apparent for large many core designs, which are still slow to elaborate due to the cost of elaborating many cores.
jerryz123
force-pushed
the
constellation-integrate
branch
5 times, most recently
from
ae534f2
to
746d28a
Compare
jerryz123
force-pushed
the
constellation-integrate
branch
from
746d28a
to
d554c28
Compare
|
This also adds a new |
jerryz123
force-pushed
the
constellation-integrate
branch
from
aee1ddf
to
07cad27
Compare
| new constellation.soc.WithSbusNoC(constellation.protocol.TLNoCParams( | ||
| constellation.protocol.DiplomaticNetworkNodeMapping( | ||
| inNodeMapping = ListMap( | ||
| "Core 0" -> 1, "Core 1" -> 2, "Core 2" -> 4 , "Core 3" -> 7, |
There was a problem hiding this comment.
How are these strings determined?
There was a problem hiding this comment.
Currently its ad-hoc based on how the TL agents are diplomatically instantiated, whether or not an explicit name is provided.
This is admittedly very messy currently, the names often do not reflect what the device is.
This should be cleaned up in the future.
| @@ -23,7 +23,7 @@ class TinyRocketConfig extends Config( | |||
|
|
|||
| // DOC include start: FFTRocketConfig | |||
| class FFTRocketConfig extends Config( | |||
| new fftgenerator.WithFFTGenerator(baseAddr=0x2000, numPoints=8, width=16, decPt=8) ++ // add 8-point mmio fft at 0x2000 with 16bit fixed-point numbers. | |||
| new fftgenerator.WithFFTGenerator(numPoints=8, width=16, decPt=8) ++ // add 8-point mmio fft at 0x2000 with 16bit fixed-point numbers. | |||
There was a problem hiding this comment.
Comment needs to be updated. However, why was this address removed in favor of it being @ 0x2400?
There was a problem hiding this comment.
Making all the MMIO devices use different addresses makes it easier to generate and test 1 config that contains many devices.
I updated the SW tests as well for these.
| @@ -13,7 +13,7 @@ import freechips.rocketchip.util.UIntIsOneOf | |||
|
|
|||
| // DOC include start: GCD params | |||
| case class GCDParams( | |||
| address: BigInt = 0x2000, | |||
| address: BigInt = 0x1000, | |||
There was a problem hiding this comment.
Again, why is this address moved?
There was a problem hiding this comment.
I guess you can comment on this for all other MMIO addresses moving?
| MODEL ?= TestHarness | ||
| VLOG_MODEL ?= TestHarness | ||
| MODEL_PACKAGE ?= constellation.test | ||
| CONFIG ?= TestConfig00 |
There was a problem hiding this comment.
As opposed to TestConfig01, TestConfig02, etc.
Added support for NoC-based interconnect via Constellation.
Related PRs / Issues:
Type of change:
Impact:
Contributor Checklist:
mainas the base branch?changelog:<topic>label?changelog:label?.conda-lock.ymlfile if you updated the conda requirements file?Please Backport?