There were two problems here:
1. The docs indicated that this should be a dual-BOOM and
single-Rocket config, but the config actually had two Rocket
cores.
2. Since the doc include string was 'DualBoomAndRocket', it was
accidentally matching against the 'DualBoomAndRocketOneHwacha'
section, which comes first in the file.
So, I created a new 'DualLargeBoomAndSingleRocketConfig' config which
only has one Rocket core, and changed the doc include string to
'DualBoomAndSingleRocket'.
* Add c test files for DSPTools example
* Update tests Makefile to build DSPTools c tests
* Add DSPTools example configs to ConfigMixins and RocketConfigs
* Add dsptools and rocket-dsptools as dependancies for example
* Add Scala implementations of DSPTools test blocks
* Clean up GenericFIR scala
* Modify dsptools blocks and mixins to match 'CanHave' when adding peripherial
* Update documentation, will need reworking once FIR is characterized as fixed point
* Update naming of Passthrough to Streaming Passthrough. Update naming of Thing to Chain and remove old Chain
* Fix capitalization in docs (#419)
* Add c test files for DSPTools example
* Update tests Makefile to build DSPTools c tests
* Add DSPTools example configs to ConfigMixins and RocketConfigs
* Add dsptools and rocket-dsptools as dependancies for example
* Add Scala implementations of DSPTools test blocks
* Clean up GenericFIR scala
* Modify dsptools blocks and mixins to match 'CanHave' when adding peripherial
* Update documentation, will need reworking once FIR is characterized as fixed point
* Update naming of Passthrough to Streaming Passthrough. Update naming of Thing to Chain and remove old Chain
* Update docs/Customization/Dsptools-Blocks.rst
Co-Authored-By: alonamid <alonamid@eecs.berkeley.edu>
* Docummentation update for clarity and to explain how this can be applied to a generalized block
* Some refactoring to get dsptools working with these examples
* Oops, old files crept in
Co-authored-by: Ryan Lund <ryan.lund@bwrcrdsl-4.eecs.berkeley.edu>
Co-authored-by: Sagar Karandikar <sagark@eecs.berkeley.edu>
Co-authored-by: alonamid <alonamid@eecs.berkeley.edu>
Co-authored-by: Paul Rigge <rigge@berkeley.edu>
This adds an additional layer (ChipTop) between the System module and the TestHarness. The IOBinder API is now changed to take only a single parameter (an Any) and return a 3 things: The IO port(s), the IO cell(s), and a function to call inside the test harness, which is analogous to the old IOBinder function, except that it takes a TestHarness object as an argument instead of (clock, reset, success).
* A new Top-level module, ChipTop, has been created. ChipTop instantiates a "system" module specified by BuildSystem.
* BuildTop now builds a ChipTop dut module in the TestHarness by default
* A new BuildSystem key has been added, which by default builds DigitalTop (previously just called Top)
* The IOBinders API has changed. IOBinders are now called inside of ChipTop and return a tuple3 of (IO ports, IO cells, harness functions). The harness functions are now called inside the TestHarness (this is analogous to the previous IOBinder functions).
* IO cell models have been included in ChipTop. These can be replaced with real IO cells for tapeout, or used as-is for simulation.
* The default for the TOP make variable is now ChipTop (was Top)
