How to extend chisel3's bundle to a specific width the value this.getWidth? - chisel

I'm reinterpreting some chisel3 bundle struct into another bundle.
say,
val a = Wire(new BundleA)
val b = Wire(new BundleB)
b := a.asTypeOf(b)
The two bundle's width is different, I need to extend the BundleB to the width of BundleA so that the BundleB aligns with BundleA starting from MSB.
I tried
class BundleB extends Bundle{
val sub = UInt(subfield.W)
val dummy = UInt((fullwidth - this.getWidth).W)
}
But the width of B is still only subfield, not fullwidth
So how to construct a bundle of specific width with dummy data and current width?

It's actually a bug that Chisel isn't erroring here, but this.getWidth is causing Chisel to resolve BundleB too early, grabbing sub as a field but ignoring dummy.
There isn't a built-in way to get the "current running width" of the Bundle you're constructing, you'd need to do it yourself, something like:
class BundleB(val subfieldWidth: Int, val fullWidth: Int) extends Bundle {
val sub = UInt(subfieldWidth.W)
private val currentWidth = subfieldWidth // + ... if you have other fields
val dummy = UInt((fullWidth - subfieldWidth).W)
}

Related

suggestName for IO(Vec(...))

I have a module like so...
class ApbSplitter (clients : List[ApbRange]) extends MultiIOModule {
val nApb = clients.length
val apb = IO(Vec(nApb, new ApbChannel()))
val apb_m = IO(Flipped(new ApbChannel))
...
What I'd like to do is suggestName to each element of the Vec so that instead of prefixed as apb_0_ apb_1_ etc... it's whatever I provide for each element.
I can apb.suggestName but that only affects the leading prefix and the array indices remain. Doing apb(idx).suggestName("blah") compiles but has no effect.
Any way to make this happen?
Got this to work by eliminating the Vec and creating a list of IO
case class ApbRange (name: String, loAddr : Int, hiAddr : Int)
class ApbSplitter (clients : List[ApbRange]) extends MultiIOModule {
val apb = clients.map({x => IO(new ApbChannel).suggestName(x.name)})
val apb_m = IO(Flipped(new ApbChannel))
...
Not sure if this is canonical but seems to do the trick just fine.
Answering this with Brian's other post and comment on his own answer on this post in mind. This is going to be a long answer because it touches on a couple of warts in the Chisel API that are being improved but are certainly relevant in the current version (v3.4.3 as of 12 Aug 2021).
Brian's answer is correct that if you want to name the individual fields you need to use a Seq and not a Vec. The reason for this is that, from Chisel's perspective, an IO of type Vec is a single port with an aggregate type, whereas the Seq is just a sequence of unrelated ports. The Seq is a Scala construct (whereas Vec comes from Chisel), so Chisel itself doesn't know anything about the relationship between the ports in the Seq.
The problem then, is that you need a Vec to do dynamic indexing. You can use VecInit to create a dynamically indexable Wire from your Seq whenever you need to do dynamic indexing:
For example:
class MyModule(names: Seq[String]) extends RawModule {
val enq = names.map(n => IO(Flipped(Decoupled(UInt(8.W)))).suggestName(n))
val idx = IO(Input(UInt(log2Ceil(names.size).W)))
val deq = IO(Decoupled(UInt(8.W)))
// enqWire connects all fields of enq
val enqWire = VecInit(enq)
// Need to make sure backpressure is always driven
enqWire.foreach(_.ready := false.B)
deq <> enqWire(idx)
}
This will work so long as deq is itself a port. It will not work if deq were a Wire because <> is a commutative operator and is thus ambiguous when connecting 2 bidirectional wires. For a longer explanation, see this PR comment.
If deq needs to be a Wire for some reason, you could use a helper module that does have Vecs as ports:
For example:
class InnerHelper(n: Int) extends RawModule {
val enq = IO(Flipped(Vec(n, Decoupled(UInt(8.W)))))
val idx = IO(Input(UInt(log2Ceil(n).W)))
val jdx = IO(Input(UInt(log2Ceil(n).W)))
val deq = IO(Vec(n, Decoupled(UInt(8.W))))
// backpressure defaults
enq.foreach(_.ready := false.B)
deq.foreach { x =>
x.valid := false.B
x.bits := DontCare
}
deq(jdx) <> enq(idx)
}
class MyModule(names: Seq[String]) extends RawModule {
val enq = names.map(n => IO(Flipped(Decoupled(UInt(8.W)))).suggestName(n))
val idx = IO(Input(UInt(log2Ceil(names.size).W)))
val jdx = IO(Input(UInt(log2Ceil(names.size).W)))
val deq = names.map(n => IO(Decoupled(UInt(8.W))).suggestName(s"${n}_out"))
val helper = Module(new InnerHelper(names.size))
helper.enq <> enq
helper.idx := idx
helper.jdx := jdx
helper.deq <> deq
}
It's a bit of a pain, but it at least resolves the ambiguity. There are other utilities we could build--for example, instead of a custom InnerHelper for each case, we could make a utility method that creates a module so that the returned value of dynamically indexing a Seq is a port of a new submodule, but it's a bit tricky.
The good news is that a better way is coming--DataView in Chisel 3.5 should make it possible to view a Seq as a Vec (rather than having to use VecInit which creates a Wire) which makes it easier to avoid this Wire <> connect ambiguity issue. I also hope to either "fix" <> for Wires or perhaps provide a new operator that is not commutative :<>, but that is not yet being worked on.
I am guessing your new apbChannel has a bunch of Input Output signals or wires. So instead of apb(idx).suggestName if your apbChannel has a (say) val ip = Input(Bool()) you can do apb(idx).ip.suggestName("blah")

Poking individual bits using peekpoketester

I have an IO bundle as shown below
val io = IO(new Bundle{
val test = Input(UInt(32.W))
})
Now from the testbench I want to give inputs to the test pin. I know that we can use peekpoketesters to give an input like this
poke(dut.io.test, 40.U)
But is there a way I can use peekpoketester to set the individual bits of the test input pin?
For example something like this
poke(dut.io.test(31,23) , 6.U)
The short answer is no, poking to specific bits of an input is not directly supported, but using the fact that you can peek top level inputs here is a very simplistic workaround. You can run and test this on scastie here.
You could generalize this to operate on inputs more directly as in your example.
This code uses an extremely quick, dirty, and naive bit manipulation method, but I like working with binary text strings when I'm in a hurry. One more note, this is using the more modern chiseltest (vs old iotesters), but a similar method could be used in iotesters
import chisel3._
import chiseltest._
import chiseltest.experimental.ChiselTestShell
class PassThrough extends Module {
val io = IO(new Bundle {
val in = Input(UInt(32.W))
val out = Output(UInt(32.W))
})
io.out := io.in
}
/** use strings to construct bit mask to clear target range and then or in newbits */
def setBits(
target: BigInt,
topBit: Int,
lowBit: Int,
newBits: BigInt
): BigInt = {
val clearMask = BigInt(
"1" * (target.bitLength.max(
newBits.bitLength
) - topBit) + "0" * (topBit - lowBit + 1) + "1" * lowBit,
radix = 2
)
(target & clearMask) | (newBits << lowBit)
}
// crude verification of setBits
println(setBits(BigInt(31), 2, 1, 2).toString(2))
chiseltest.RawTester.test(new PassThrough) { c =>
c.io.in.poke(40.U)
c.clock.step()
c.io.out.expect(40.U)
val lastIn = c.io.in.peek().litValue()
val newVal = setBits(lastIn, 31, 23, 6)
val bitAddr = (0 to 31).map { x => x % 10 }.reverse.mkString("")
println(s" = $bitAddr")
println(f"lastIn = ${lastIn.toString(2)}%32s")
println(f"newVal = ${newVal.toString(2)}%32s")
c.io.in.poke(newVal.U)
c.clock.step()
c.io.out.expect(newVal.U)
}

How to initialize a Reg of Bundle in Chisel?

I declared a Bundle for my specific data :
class RValue (val cSize: Int = 16) extends Bundle {
val rvalue = Output(UInt(cSize.W))
val er = Output(UInt((cSize/2).W))
val part = Output(Bool()) /* set if value is partial */
}
And I want to use it as a register in my module :
val valueReg = Reg(new RValue(cSize))
//...
valueReg.rvalue := 0.U
valueReg.er := 0.U
That works well. But I want to initialize it at Register declaration with RegInit(). Is it Possible ?
val valueReg = RegInit(new RValue(cSize), ?? ) ??
Chick's answer of using Bundle Literals is the cool new way and is nice because you can give a Bundle arbitrary values in a single expression.
If you just want to zero-out the register at reset type, you could always cast from a literal zero to the Bundle:
val valueReg = RegInit(0.U.asTypeOf(new RValue(cSize))
You can do similar things with any literal if you want, but I wouldn't recommend it unless you're zeroing out or setting everything to 1s.
For setting each field to some other value, I think Chick's way is better, but the normal style you'll see in older code is something like:
val valueReg = RegInit({
val bundle = Wire(new RValue(cSize))
bundle.rvalue := 1.U
bundle.er := 2.U
bundle.part := 3.U
bundle
})
In Scala, you can put { } anywhere an expression is needed and the last expression in the Block will be the return value. Thus we can create a Wire with the values we want to reset the register to and then pass that Bundle as the initialization value. It would be equivalent to write:
val valueRegInit = Wire(new RValue(cSize))
valueRegInit.rvalue := 1.U
valueRegInit.er := 2.U
valueRegInit.part := 3.U
val valueReg = RegInit(valueRegInit)
I hope this helps!
BundleLiterals are the new way to do this. First
import chisel3.experimental.BundleLiterals._
Then
val valueReg = RegInit((new RValue(cSize)).Lit(_.rvalue -> 1.U, _.er -> 2.U, _.part -> true.B)
It's possible there will be some problem with having declared the fields in the Bundle with the OutputBinding. I would probably leave that off and just wrap with the output when necessary, e.g.
val rValueOut = IO(Output(new RValue(csize)))

How to writing a accumulator by using ScalaBlackBox?

I want to create some new number types that like DspReal for dsptools, such as DspPosit and DspQuire. DspPosit bases on posit which I have some Java code, and DspQuire bases on quire which is a kind of accumulator for posit. Because I just want to simulation now, so I have write many ScalaBlackBox for their operation like DspReal. However, I found that ScalaBlackBox can't construct sequential logic. For example, current output of the quire accumulator depends on it's input and last output. But ScalaBlackBox can't get the value of the output. In addition, step(n) also influences the output. Because accumulator will read its input per clock cycle.
I found some system problems of treadle. First, the function of ScalaBlackBox, twoOp and oneOp and so on, will be called many times. I don't know why. Second, step(n) is the function of PeekPokeTester, which can't be access by ScalaBlackBox. Third, I try to read current output but system gives errors.
trait DspBlackBlackBoxImpl extends BlackBoxImplementation with ScalaBlackBox
abstract class DspQuireAccumulator extends DspBlackBlackBoxImpl {
lazy val accValue = Quire32() // initial value
/**
* sub-classes must implement this two argument function
*
* #param posit accumulate element
* #return quire operation result
*/
def accOp(posit: Posit32): Unit
def outputDependencies(outputName: String): Seq[(String)] = {
outputName match {
case "out" => Seq("in") // Seq("out", "in") gives errors
case _ => Seq.empty
}
}
def cycle(): Unit = {}
def execute(inputValues: Seq[Concrete], tpe: Type, outputName: String): Concrete = {
val arg1 :: _ = inputValues
val positArg = Posit32(arg1.value)
accOp(positArg)
val result = quire32ToBigInt(accValue)
ConcreteSInt(result, DspQuire.underlyingWidth, arg1.poisoned).asUInt
}
def getOutput(inputValues: Seq[BigInt], tpe: Type, outputName: String): BigInt = {
val arg1 :: _ = inputValues
val positArg = Posit32(arg1)
accOp(positArg)
quire32ToBigInt(accValue)
}
}
class DspQuireAddAcc(val name: String) extends DspQuireAccumulator {
def accOp(posit: Posit32): Unit = accValue += posit
}
class QuireBlackboxAccOperand extends BlackBox {
val io = IO(new Bundle() {
val in = Input(UInt(DspPosit.underlyingWidth.W))
val out = Output(UInt(DspQuire.underlyingWidth.W))
})
}
class BBQAddAcc extends QuireBlackboxAccOperand
class TreadleDspQuireFactory extends ScalaBlackBoxFactory {
def createInstance(instanceName: String, blackBoxName: String): Option[ScalaBlackBox] = {
blackBoxName match {
case "BBQAddAcc" => Some(add(new DspQuireAddAcc(instanceName)))
...
accOp will be called many times. So, if I want to accumulate List(1, 2, 3), the result maybe 0 + 1 + 1 + 2 + 2 + ...
And peek function will call accOp one time again, this makes me confused also.
I believe most of your problems at this point are caused by mixing two different approaches. I think you should not be using BlackBoxImplmentation because it is an older scheme used in with the firrtl-interpreter. Just use the ScalaBlackBox and implement the methods as described in the wiki page Black Boxes and Treadle and shown in the TreadleTest BlackBoxWithState.
Don't use outputDependencies, and instead specify any dependencies between inputs and outputs with with getDependencies. inputChanged will be called whenever an input IO is changed. So in that method you want to record or update the internal state of your black box. clockChange will be called whenever a clock is changed and will provide the transition information so you can decide what happens then. Treadle will call getOutput whenever it needs that output of your black box, since you will not have used outputDependencies you can ignore the inputs and just provide the output value depending on your internal state.
I am still trying to reproduce a running version of your code here but it will be a little time for me to put it together, if you can try my suggestions above and let me know how it goes that would be helpful. I am interested in making this feature of Treadle better and easier to use so all feedback is appreciated.

Scala: Self-Recursive val in function [duplicate]

Why can't i define a variable recursively in a code block?
scala> {
| val test: Stream[Int] = 1 #:: test
| }
<console>:9: error: forward reference extends over definition of value test
val test: Stream[Int] = 1 #:: test
^
scala> val test: Stream[Int] = 1 #:: test
test: Stream[Int] = Stream(1, ?)
lazy keyword solves this problem, but i can't understand why it works without a code block but throws a compilation error in a code block.
Note that in the REPL
scala> val something = "a value"
is evaluated more or less as follows:
object REPL$1 {
val something = "a value"
}
import REPL$1._
So, any val(or def, etc) is a member of an internal REPL helper object.
Now the point is that classes (and objects) allow forward references on their members:
object ForwardTest {
def x = y // val x would also compile but with a more confusing result
val y = 2
}
ForwardTest.x == 2
This is not true for vals inside a block. In a block everything must be defined in linear order. Thus vals are no members anymore but plain variables (or values, resp.). The following does not compile either:
def plainMethod = { // could as well be a simple block
def x = y
val y = 2
x
}
<console>: error: forward reference extends over definition of value y
def x = y
^
It is not recursion which makes the difference. The difference is that classes and objects allow forward references, whereas blocks do not.
I'll add that when you write:
object O {
val x = y
val y = 0
}
You are actually writing this:
object O {
val x = this.y
val y = 0
}
That little this is what is missing when you declare this stuff inside a definition.
The reason for this behavior depends on different val initialization times. If you type val x = 5 directly to the REPL, x becomes a member of an object, which values can be initialized with a default value (null, 0, 0.0, false). In contrast, values in a block can not initialized by default values.
This tends to different behavior:
scala> class X { val x = y+1; val y = 10 }
defined class X
scala> (new X).x
res17: Int = 1
scala> { val x = y+1; val y = 10; x } // compiles only with 2.9.0
res20: Int = 11
In Scala 2.10 the last example does not compile anymore. In 2.9.0 the values are reordered by the compiler to get it to compile. There is a bug report which describes the different initialization times.
I'd like to add that a Scala Worksheet in the Eclipse-based Scala-IDE (v4.0.0) does not behave like the REPL as one might expect (e.g. https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started says "Worksheets are like a REPL session on steroids") in this respect, but rather like the definition of one long method: That is, forward referencing val definitions (including recursive val definitions) in a worksheet must be made members of some object or class.