What's the general workflow for modifying/testing a generator?
242 views
Skip to first unread message
Benjamin Ou
Aug 18, 2021, 8:16:09 PM8/18/21
to Chipyard
I'm trying to extend the decoder in BOOM core for a few new toy instructions, so I'd like to be able to instantiate the Decoder and use PeekPokeTester to poke in my instruction and see what signals pop out. It's not really clear how I'd go about that, though; can't seem to find step-by-step instructions for using the testing tools (as in, where should I make a file? What do I need to import? What commands do I run to compile the file and see/pipe test output?)
Benjamin Ou
Aug 19, 2021, 10:08:24 PM8/19/21
to Chipyard
Some updates on this:
I now understand some basics about the Scala Built Tool, particularly that it runs tests in src/test with the "test" command. This also readily demonstrates how to import ChiselTest tools like PeekPokeTester, since there are existing tests for boom core that do so.
Problem now is that since the boom repo is not compilable standalone, I'm not sure how to write tests for boom that can actually be run, since a boom core typically needs to be instantiated on the rocket chip, and I can only seem to run rocket-chip tests from that project.
Alon Amid
Aug 22, 2021, 5:07:18 PM8/22/21
to chip...@googlegroups.com
Why not write an assembly test and compile it into a binary? Then you can use the same flow that is used in the Chipyard and BOOM CI, or use that standard Verilator-based flow to run that assembly test.
If your challenge is dealing with assembling custom encodings, you can have a look at macros like the ones sometimes used from RoCC extensions.
Alon
--
You received this message because you are subscribed to the Google Groups "Chipyard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chipyard+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chipyard/6e0c3bb8-2e10-40b7-8038-ce4fb63f2be2n%40googlegroups.com.
Kevin Laeufer
Aug 23, 2021, 1:48:10 PM8/23/21
to chip...@googlegroups.com
Hi Benjamin,
While I do not have a direct solution for you, this might help you:
Some Masters students were working on testing chipyard components with
sbt + scalatest + chiseltest last semester. You can find some
documentation on how they did that in the context of chipyard here:
https://github.com/TsaiAnson/verif#inside-chipyard
Since you integrated your tests directly into the boom reposiotory, you
probably do not have to modify any build.sbt file.
Try running `make launch-sbt` in the `sims/verilator` folder. Then when
you are in the sbt shell, you need to navigate to the boom project. I am
not sure what it will be called, but after you type `project ` you can
hit the shift key twice and sbt should show you the available projects.
Once you are in the boom project, try running `test` which should
automatically run all scalatest based unit tests in boom's `src/test`
directory.
Regards,
Kevin
On 8/22/21 2:07 PM, Alon Amid wrote:
> Why not write an assembly test and compile it into a binary? Then you
> can use the same flow that is used in the Chipyard and BOOM CI, or use
> that standard Verilator-based flow
> <https://chipyard.readthedocs.io/en/latest/Simulation/Software-RTL-Simulation.html#simulating-the-default-example>
>
>
>
> Alon
>
>
>
> *From:* chip...@googlegroups.com <chip...@googlegroups.com> *On Behalf
> Of *Benjamin Ou
> *Sent:* Friday, August 20, 2021 5:08 AM
> *To:* Chipyard <chip...@googlegroups.com>
> *Subject:* [chipyard] Re: What's the general workflow for
> <https://groups.google.com/d/msgid/chipyard/098501d79799%24af3ab650%240db022f0%24%40berkeley.edu?utm_medium=email&utm_source=footer>.
While I do not have a direct solution for you, this might help you:
Some Masters students were working on testing chipyard components with
sbt + scalatest + chiseltest last semester. You can find some
documentation on how they did that in the context of chipyard here:
https://github.com/TsaiAnson/verif#inside-chipyard
Since you integrated your tests directly into the boom reposiotory, you
probably do not have to modify any build.sbt file.
Try running `make launch-sbt` in the `sims/verilator` folder. Then when
you are in the sbt shell, you need to navigate to the boom project. I am
not sure what it will be called, but after you type `project ` you can
hit the shift key twice and sbt should show you the available projects.
Once you are in the boom project, try running `test` which should
automatically run all scalatest based unit tests in boom's `src/test`
directory.
Regards,
Kevin
On 8/22/21 2:07 PM, Alon Amid wrote:
> Why not write an assembly test and compile it into a binary? Then you
> can use the same flow that is used in the Chipyard and BOOM CI, or use
> that standard Verilator-based flow
> to run that assembly test.
>
> If your challenge is dealing with assembling custom encodings, you can
> have a look at macros like the ones sometimes used from RoCC extensions
> <https://github.com/ibm/rocc-software/tree/fddb795a0b52e82f8f4ce9ead9b1428440a62ab0>.
>
> If your challenge is dealing with assembling custom encodings, you can
> have a look at macros like the ones sometimes used from RoCC extensions
>
>
>
> Alon
>
>
>
> *From:* chip...@googlegroups.com <chip...@googlegroups.com> *On Behalf
> Of *Benjamin Ou
> *Sent:* Friday, August 20, 2021 5:08 AM
> *To:* Chipyard <chip...@googlegroups.com>
> *Subject:* [chipyard] Re: What's the general workflow for
> modifying/testing a generator?
>
>
>
> Some updates on this:
>
>
>
> I now understand some basics about the Scala Built Tool, particularly
> that it runs tests in src/test with the "test" command. This also
> readily demonstrates how to import ChiselTest tools like PeekPokeTester,
> since there are existing tests for boom core that do so.
>
>
>
> Problem now is that since the boom repo is not compilable standalone,
> I'm not sure how to write tests for boom that can actually be run, since
> a boom core typically needs to be instantiated on the rocket chip, and I
> can only seem to run rocket-chip tests from that project.
>
>
>
> On Wednesday, August 18, 2021 at 5:16:09 PM UTC-7 Benjamin Ou wrote:
>
> I'm trying to extend the decoder in BOOM core for a few new toy
> instructions, so I'd like to be able to instantiate the Decoder and
> use PeekPokeTester to poke in my instruction and see what signals
> pop out. It's not really clear how I'd go about that, though; can't
> seem to find step-by-step instructions for using the testing tools
> (as in, where should I make a file? What do I need to import? What
> commands do I run to compile the file and see/pipe test output?)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Chipyard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to chipyard+u...@googlegroups.com
> <mailto:chipyard+u...@googlegroups.com>.
>
>
>
> Some updates on this:
>
>
>
> I now understand some basics about the Scala Built Tool, particularly
> that it runs tests in src/test with the "test" command. This also
> readily demonstrates how to import ChiselTest tools like PeekPokeTester,
> since there are existing tests for boom core that do so.
>
>
>
> Problem now is that since the boom repo is not compilable standalone,
> I'm not sure how to write tests for boom that can actually be run, since
> a boom core typically needs to be instantiated on the rocket chip, and I
> can only seem to run rocket-chip tests from that project.
>
>
>
> On Wednesday, August 18, 2021 at 5:16:09 PM UTC-7 Benjamin Ou wrote:
>
> I'm trying to extend the decoder in BOOM core for a few new toy
> instructions, so I'd like to be able to instantiate the Decoder and
> use PeekPokeTester to poke in my instruction and see what signals
> pop out. It's not really clear how I'd go about that, though; can't
> seem to find step-by-step instructions for using the testing tools
> (as in, where should I make a file? What do I need to import? What
> commands do I run to compile the file and see/pipe test output?)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Chipyard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to chipyard+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/chipyard/6e0c3bb8-2e10-40b7-8038-ce4fb63f2be2n%40googlegroups.com
> <https://groups.google.com/d/msgid/chipyard/6e0c3bb8-2e10-40b7-8038-ce4fb63f2be2n%40googlegroups.com?utm_medium=email&utm_source=footer>.
> https://groups.google.com/d/msgid/chipyard/6e0c3bb8-2e10-40b7-8038-ce4fb63f2be2n%40googlegroups.com
>
> --
> You received this message because you are subscribed to the Google
> Groups "Chipyard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to chipyard+u...@googlegroups.com
> <mailto:chipyard+u...@googlegroups.com>.
> --
> You received this message because you are subscribed to the Google
> Groups "Chipyard" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to chipyard+u...@googlegroups.com
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/chipyard/098501d79799%24af3ab650%240db022f0%24%40berkeley.edu
> <https://groups.google.com/d/msgid/chipyard/098501d79799%24af3ab650%240db022f0%24%40berkeley.edu?utm_medium=email&utm_source=footer>.
Benjamin Ou
Sep 4, 2021, 7:24:52 PM9/4/21
to Chipyard
Is looking at waveform dumps a standard part of debugging with assembly binary inputs? If so, any pointers on how to navigate to the relevant signals? The signal hierarchy in GTKWave looks very intimidatingly complex.
Benjamin Ou
Sep 8, 2021, 4:32:35 PM9/8/21
to Chipyard
OK, I think I've got it figured out. Just gotta cross-reference signal names between the chisel source, the generated verilog (sims/verilator/generated-src/[config].top.v), and the signals in the waveform viewer.
Reply all
Reply to author
Forward
0 new messages