4
votes

I am a novice with chisel. I would be using it in my project in coming days and I am trying to get familiar with the library.

After working with Chisel-tutorials I have got a better hang of how things work in chisel. In tutorials, everything has been provided organized in a manner to make things easier for beginners (I suppose that is the purpose of tutorials!).

Now, i want to move onto next part, where i would like to develop my own small projects and dive a bit more into how chisel works (generating verilog, cpp, vcd) from say a simple Mux4.scala file in chisel. (I am taking the correct version of Mux4 module code and tester from here). I just added the following lines at the end of Mux4.scala

object Mux4Driver extends App {
  chisel3.Driver.execute(args, () => new Mux4(32))
} 

to get the verilog code directly.

I have placed the scala file in src/main/scala/ and tester in src/test/scala/.

Here is where I am having trouble. As pointed out by jkoenig, I can run my code by using the command sbt "run-main Mux4Driver" in the root directory. On doing so i get three files,Mux4.fir,Mux4.v, Mux4.anno.

  1. But how can I get various files(screenshot below) which i got by using

    TESTER_BACKENDS=verilator ./run-examples.sh GCD

when i am implementing my own module.(I understand that i can pass the verilog file through verilator to get cpp files, but is there any sleek way to get all the files at once like in tutorials [There should be a way, but i just could not figure it out]) enter image description here

(I am using the chisel-template for my project).

  1. I understand that after writing modules, it seems like knowledge of sbt is required to successfully run your code and generate the required files. I would like to understand how I can use sbt to organize my projects like in chisel tutorials and run them with a single command (like ./run-examples.sh mymodule).

I have done research on my end for above questions but could not get clarity. I would appreciate if you can compile a few steps for new users like me on how to deal with your own projects.

Edit:

On trying out the commands mentioned in the answer below I got the following errors:

enter image description here

And on trying out --help my options are different from what you have suggested. On matching my --help output with the output here i find that i don't have tester options in my output.

enter image description here

Is this some issue with the version of Chisel (using Chisel3) or sbt I am using?

1

1 Answers

3
votes

This is amended for the changes to the question.

The chisel-template repo is a reasonable example of how to organize your further development efforts. But based on your question, I would recommend you use a one of two different method of invoking your unit tests.

class GCDTester extends ChiselFlatSpec {
  "GCD" should "calculate proper greatest common denominator" in {
    iotesters.Driver.execute(Array(), () => new GCD) {
      c => new GCDUnitTester(c)
    } should be (true)
  }
}

or

object GCDMain extends App {
  iotesters.Driver.execute(args, () => new GCD) {
    c => new GCDUnitTester(c)
  }
}

One important difference from your code in your question is that the Driver referenced above is chisel3.iotesters.Driver instead of chisel3.Driver. You can use command line arguments with either, for example: Add --help to the arguments like

iotesters.Driver.execute(Array("--help"), () => new GCD) {

and run your test, or run the main from the second example:

sbt 'runMain examples.GCDMain --help'

Either way, you will see the large number of available options. You are interested in

  -tbn, --backend-name <firrtl|verilator|vcs>
                           backend to use with tester, default is firrtl

and maybe

  -fiwv, --fint-write-vcd  writes vcd execution log, filename will be base on top

You can add any of these arguments, in the same way you --help was added. So to run verilator

iotesters.Driver.execute(Array("--backend-name", "verilator"), () => new GCD) {

and run your test, or run the main from the second example:

sbt 'runMain examples.GCDMain --backend-name verilator'

The chisel.Driver only supports a subset of the options of the iotesters.Driver and does not include verilator.

Getting all the files you want requires that you run a simulation on your circuit which require some sort of test harness. The iotesters.Driver.execute will invoke your test harness, which will create the files you are interested in (when run with --backend-name verilator). The chisel.Driver.execute only elaborates the circuit, it does not run a simulation.

Note:Although the --fint-write-vcd is only for getting a VCD output file when using the interpreter, I believe using the verilator backend output vcd by default.