After a lot of poking my nose into different Chisel stuff out there, I decided it was time to try a thing of my own. Quite unexpectedly, the thing, a simple thing, but still, the thing I made based on the chisel-template works successfully.
I even managed to confirm that by running the simplest of tests. It is a dummy 32-bit ALU that contains (for now) a submodule intended for bitwise operation. I wrote the test following the existing test of GCD, so my test file, Alu32UnitTest.scala
, contains these important lines:
package alu32
import chisel3.iotesters
import chisel3.iotesters.{PeekPokeTester,Driver,ChiselFlatSpec}
class Alu32BoolTests(dut: Alu32) extends PeekPokeTester(dut) {
for (i <- 0 until 9) {
//first provide random values
val a = rnd.nextInt(256)
val b = rnd.nextInt(256)
val f = rnd.nextInt(16)
//decide what to expect based on opcode
var output = 0
if (f == 8) {
output = a & b
} else if (f == 14) {
output = a | b
} else if (f == 6) {
output = a ^ b
} else output = 0
//connect the generated inputs to dut
poke(dut.io.a, a)
poke(dut.io.b, b)
poke(dut.io.f, f)
//clock
step(1)
//check if everything is where it should be
expect(dut.io.y, output)
}
}
}
class Alu32UnitTester extends ChiselFlatSpec {
behavior of "Alu32"
backends foreach {backend =>
it should s"perform correct math operation on dynamic operand in $backend"
in {
Driver(() => new Alu32, backend)((dut) => new Alu32BoolTests(dut)) should be (true)
}
}
}
I run this test using (after running sbt
):
> testOnly alu32.AluUnitTester
and it correctly says SUCCESS
when it's good and it complains when I change the internals of the ALU. I've come to that testOnly
line, only by looking at the README of chisel-template and pressing [Tab] after test
, testOnly
and so on.
The next thing I wanted to do was to get Verilog code so I tried running the commands provided at chisel-tutorial, I mean those including run-main
. That, of course, resulted in errors as, I realized, no such tests were defined in my Alu32UnitTest.scala
So I tried adapting the lines found in GCD and that led me to notice another file in tests/scala - a GCDMain.scala
. So I went ahead and adapted that into:
package alu32
import chisel3._
object Alu32Main extends App {
iotesters.Driver.execute(args, () => new Alu32) {
dut => new Alu32UnitTester(dut)
}
}
object Alu32Repl extends App {
iotesters.Driver.executeFirrtlRepl(args, () => new Alu32)
}
and called it Alu32Main.scala
. With that one created, now nothing works :)
When I try the one that did work:
> testOnly alu32.AluUnitTester
I get now the following response:
[info] Compiling 1 Scala source to /home/apaj/ChiselProjects/alu32/target/scala-2.11/classes...
[warn] there were 8 feature warnings; re-run with -feature for details
[warn] one warning found
[info] Compiling 1 Scala source to /home/apaj/ChiselProjects/alu32/target/scala-2.11/test-classes...
[error] /home/apaj/ChiselProjects/alu32/src/test/scala/alu32/alu32Main.scala:7: too many arguments for constructor Alu32UnitTester: ()alu32.Alu32UnitTester
[error] dut => new Alu32UnitTester(dut)
[error] ^
[error] one error found
[error] (test:compileIncremental) Compilation failed
[error] Total time: 10 s, completed Jan 15, 2018 5:16:12 PM
I notice how it complains over having to many arguments. However, if the argument dut
is removed, than it complains about mismatched types.
At one point, somehow, can't remember to reconstruct how, I did get a response similar to the one presented in this question, but I really don't remember how.
I am sure that this is a beginner's issue, overlooking something probably obvious, so I hope you'll find time and help out.
Thanks a lot.