Maintain connection order on FIRRTL using Cat operator - chisel

I want to ask for any idea for the following problem :
I want to connect the input port of a block named dut whose width is 787:0 bits, to a byte interface. I am doing like following :
val io = this.IO(new VerilatorHarnessIO(input_byte_count, output_byte_count*2))
val dut = Module(new DUT(dut_conf))
// inputs
val input_bytes = Cat(io.input_bytes)
val input_width = input_byte_count * 8
dut.io.inputs := input_bytes(input_width-1, input_width - dut_conf.inputBits)
I want that the order of the connection is preserved, ie:
Byte_0[7:0] ->input[7:0]
Byte_1[7:0] ->input[15:8]
But what I am getting is :
Byte_0[7:0] ->input[787:780]
Byte_1[7:0] ->input[779:772]
It will be much easier to debug if the ports are matched.
Is there a way to make this connection in the right order?
Thank you

Using the reverse method before you Cat should do what you want.
Consider the following Chisel:
import chisel3._
import chisel3.stage.{ChiselStage, ChiselGeneratorAnnotation}
import chisel3.util.Cat
class Foo extends RawModule {
val in = IO(Input(Vec(4, UInt(8.W))))
val out = IO(Output(UInt(32.W)))
out := Cat(in.reverse)
}
(new ChiselStage)
.execute(Array.empty, Seq(ChiselGeneratorAnnotation(() => new Foo)))
This produces the following Verilog with the bytes in the order you're looking for:
module Foo(
input [7:0] in_0,
input [7:0] in_1,
input [7:0] in_2,
input [7:0] in_3,
output [31:0] out
);
wire [15:0] _T; // #[Cat.scala 29:58]
wire [15:0] _T_1; // #[Cat.scala 29:58]
assign _T = {in_1,in_0}; // #[Cat.scala 29:58]
assign _T_1 = {in_3,in_2}; // #[Cat.scala 29:58]
assign out = {_T_1,_T}; // #[<pastie> 25:7]
endmodule

Cat appears backwards because it matches Verilog semantics and is thus backwards from the perspective of Scala semantics.
Consider:
val xs = List(8, 9, 10)
println(xs(0)) // 8
The left-most element is the lowest order index in Scala. However, in Verilog, you get the opposite:
assign x = {4'hde, 4'had};
The left-most part of that concatenation is actually the high-order nibble in the result. Chisel Cat was made to match Verilog semantics which makes it somewhat counter-intuitive in Scala.
As Schuyler mentioned, you can always reverse your Vec or Seq argument to Cat. Alternatively, you can cast to a UInt which will use the more intuitive Scala order:
import chisel3._
class Foo extends RawModule {
val in = IO(Input(Vec(4, UInt(8.W))))
val out = IO(Output(UInt(32.W)))
out := in.asUInt
}
.asUInt is defined on all Chisel Data, so you can use it to cast Bundles and other types to UInt as well. The only catch is that many methods defined on Vec return Seq, the Scala supertype of Vec which is not a chisel Data. This means you cannot do something like myVec.map(_ === 0.U).asUInt. You can always cast a Seq[T <: Data] (ie. a Seq containing Chisel Data elements) to a Vec via VecInit(mySeq), so you could do VecInit(myVec.map(_ === 0.U)).asUInt

Related

SyncReadMem generated verilog vs. Rocketchip emitted verilog

I am using SyncReadMem() for sram behavioral simulation. With the generated Verilog by verilator, I hope to replace it with a commercial sram compiler compiled verilog such that I can do synthesis for the whole design including sram.
However, I noticed that the verilog emitted by SyncReadMem() is not with uniform IOs just like the sram emitted in rocketchip. I wonder how do we generate some sram verilog just like the rocketchip one, using chisel mem API like SyncReadMem()?
You can use the Scala FIRRTL Compiler's "Replace Sequential Memories" pass to blackbox the memories. This is exactly what is happening with Rocket Chip.
Note that this is limited to only work if the memories have a single read port and a single write port and with read latency 1 and write latency 1.
As an example, consider the following 1r1w (one read, one write) SyncReadMem:
import chisel3._
class Foo extends MultiIOModule {
val read = IO(new Bundle {
val en = Input(Bool())
val addr = Input(UInt(8.W))
val data = Output(UInt(1.W))
})
val write = IO(new Bundle{
val en = Input(Bool())
val addr = Input(UInt(8.W))
val data = Input(UInt(1.W))
})
val bar = SyncReadMem(256, UInt(1.W))
read.data := bar.read(read.addr, read.en)
when (write.en) {
bar.write(write.addr, write.data)
}
}
If you compile this with a request to run the replace sequential memories pass:
(new ChiselStage)
.emitVerilog(new Foo, Array("--repl-seq-mem", "-c:Foo:-o:Foo.mem.conf"))
The arguments used there are -c:<circuit> where <circuit> is the name of the circuit you want to run on and -o:<mem-conf-file> is the name of a file to generate that will contain information (e.g., name, width, and depth) of the memories that were blackboxed.
You wind up with the memory blackboxed inside a new module bar called bar_ext:
module bar(
input [7:0] R0_addr,
input R0_en,
input R0_clk,
output R0_data,
input [7:0] W0_addr,
input W0_en,
input W0_clk,
input W0_data
);
wire [7:0] bar_ext_R0_addr;
wire bar_ext_R0_en;
wire bar_ext_R0_clk;
wire bar_ext_R0_data;
wire [7:0] bar_ext_W0_addr;
wire bar_ext_W0_en;
wire bar_ext_W0_clk;
wire bar_ext_W0_data;
bar_ext bar_ext (
.R0_addr(bar_ext_R0_addr),
.R0_en(bar_ext_R0_en),
.R0_clk(bar_ext_R0_clk),
.R0_data(bar_ext_R0_data),
.W0_addr(bar_ext_W0_addr),
.W0_en(bar_ext_W0_en),
.W0_clk(bar_ext_W0_clk),
.W0_data(bar_ext_W0_data)
);
assign bar_ext_R0_clk = R0_clk;
assign bar_ext_R0_en = R0_en;
assign bar_ext_R0_addr = R0_addr;
assign R0_data = bar_ext_R0_data;
assign bar_ext_W0_clk = W0_clk;
assign bar_ext_W0_en = W0_en;
assign bar_ext_W0_addr = W0_addr;
assign bar_ext_W0_data = W0_data;
endmodule
You can then run a memory compiler to consume the information in the memory configuration file and drop the output in place of bar_ext.

How to exchange certain bits of the register

I want to exchange certain bits of a register variable, just like the following example.
val data = Reg(UInt(100.W))
val re_order1 = Wire(UInt(log2Ceil(100).W))
val re_order2 = Wire(UInt(log2Ceil(100).W))
//Exchange the bits of the data register in re_order1 and re_order2
data(re_order1) := data(re_order2)
data(re_order2) := data(re_order1)
I tried to use shift and mask to achieve, but found it will be very complicated, is there a simple way
The following chisel Module does what I think you are aiming for here, that is: flip two arbitrary dynamically indexed bits in a register. This is going to require a lot of Muxes to accomplish this but I think this example shows that chisel can generate those pretty cleanly. The basic strategy is to treat the register as a Vec of bools then create a Mux every one of those bools to any other bit, based on whether the bit is referenced as one of the two bit addresses.
Then convert the sequences of generated as a new Vec using VecInit and then convert that vec to a UInt and wire it back into reg.
This module has a little bit of additional code to load the register. You may want to do that some other way.
import chisel3._
import chisel3.util.log2Ceil
import chiseltest._
import org.scalatest.freespec.AnyFreeSpec
import org.scalatest.matchers.should.Matchers
class FlipBits(bitWidth: Int) extends Module {
val io = IO(new Bundle {
val load = Input(Bool())
val loadValue = Input(UInt(bitWidth.W))
val bitAddress1 = Input(UInt(log2Ceil(bitWidth).W))
val bitAddress2 = Input(UInt(log2Ceil(bitWidth).W))
val out = Output(UInt(bitWidth.W))
})
val reg = RegInit(0.U(bitWidth.W))
val bits = VecInit(reg.asBools())
when(io.load) {
reg := io.loadValue
}.otherwise {
reg := VecInit(bits.indices.map { index =>
val index1 = Mux(index.U === io.bitAddress1, io.bitAddress2, index.U)
val index2 = Mux(index.U === io.bitAddress2, io.bitAddress1, index1)
bits(index2)
}).asUInt
}
io.out := reg
}

how to override/extend chisel signal naming

It seems not an easy thing to do or even impossible, but we are using a naming convention that prefix or postfix signals with "i_" or "o_" for inputs/outputs in verilog.
Is there some method to mess with or override inside the chisel library to to that?
I saw that except for clock and reset, all signals have "io" prefix.
Is is possible to use just "i" for input and "o" for output?
The easiest way to do this is to probably use a MultiIOModule. However, you can also do it with suggestName. Both approaches are shown below.
MultiIOModule
This a more flexible Module that lets you call the IO method to add ports to a module more than once. (Module requires that you define an io member and only allows you to call IO once.)
Because MultiIOModule frees you from the constraints of val io = ... you can use the prefix/postfix naming that you want with the names of your vals. Reflective naming will then get these right in the generated Verilog.
Consider the following Chisel code:
import chisel3._
import chisel3.stage.{ChiselStage, ChiselGeneratorAnnotation}
class Foo extends MultiIOModule {
val i_bar = IO(Input(Bool()))
val o_baz = IO(Output(Bool()))
o_baz := ~i_bar
}
(new ChiselStage).execute(Array.empty, Seq(ChiselGeneratorAnnotation(() => new Foo)))
This produces the following Verilog:
module Foo(
input clock,
input reset,
input i_bar,
output o_baz
);
assign o_baz = ~ i_bar;
endmodule
SuggestName
As an alternative, you can use the suggestName method to change the name to be different from what reflective naming (getting the name from the name of the val) would use.
Using suggestName you can coerce the names to be whatever you want. The following Chisel produces the same Verilog as above:
class Foo extends MultiIOModule {
val a = IO(Input(Bool())).suggestName("i_bar")
val b = IO(Output(Bool())).suggestName("o_baz")
b := ~a
}

Vector of RegEnable

Looking for an example/advice on how to use RegEnable as vector.
Also I want to control the inputs & enable signals to be a function of the register index in the Vector.
So first, how do I declare Vector of RegEnable(), and second how to iterate over it and connect the input & enable. In the RegEnable() case the declaration and the connection are made in the same statement. Something like:
for (j <- 0 until len) {
val pipe(j) = RegEnable(in(j),en(j))
}
The above code doesn't compile. Also in & en are vectors or bit selection
For this type of thing, it's likely much easier to use RegEnable to construct a Seq[T <: Data] and then construct a Vec out of that. The Vec object has two main apply methods: a varargs one and a seq. For your own reference, take a look at the Chisel Vec object API documentation.
The following full example builds, but the relevant part is the val pipe and val pipe2 lines. You can do this with either a map or a for/yield.
import chisel3._
import chisel3.util.RegEnable
import chisel3.iotesters
import chisel3.experimental.MultiIOModule
class Example(len: Int) extends MultiIOModule {
val in = Seq.fill(len)(IO(Input(UInt(1.W))))
val en = Seq.fill(len)(IO(Input(Bool())))
val mySeq: Seq[Data] = (0 until len).map( j => RegEnable(in(j), en(j)) )
val pipe = Vec(mySeq)
val mySeq2: Seq[Data] = for (j <- 0 until len) yield ( RegEnable(in(j), en(j)) )
val pipe2 = Vec(mySeq2)
}

Chisel/FIRRTL constant propagation & optimization across hierarchy

Consider a module that does some simple arithmetic and is controlled by a few parameters. One parameter controls the top level behavior: the module either reads its inputs from its module ports, or from other parameters. Therefore, the result will either be dynamically computed, or statically known at compile (cough, synthesis) time.
The Verilog generated by Chisel has different module names for the various flavors of this module, as expected. For the case where the result is statically known, there is a module with just one output port and a set of internal wires that are assigned constants and then implement the arithmetic to drive that output.
Is it possible to ask Chisel or FIRRTL to go further and completely optimize this away, i.e. in the next level of hierarchy up, just replace the instantiated module with its constant and statically known result? (granted that these constant values should by optimized away during synthesis, but maybe there are complicated use cases where this kind of elaboration time optimization could be useful).
For simple things that Firrtl currently knows how to constant propagate, it already actually does this. The issue is that it currently doesn't const prop arithmetic operators. I am planning to expand what operators can be constant propagated in the Chisel 3.1 release expected around New Years.
Below is an example of 3.0 behavior constant propagating a logical AND and a MUX.
import chisel3._
class OptChild extends Module {
val io = IO(new Bundle {
val a = Input(UInt(32.W))
val b = Input(UInt(32.W))
val s = Input(Bool())
val z = Output(UInt(32.W))
})
when (io.s) {
io.z := io.a & "hffff0000".U
} .otherwise {
io.z := io.b & "h0000ffff".U
}
}
class Optimize extends Module {
val io = IO(new Bundle {
val out = Output(UInt())
})
val child = Module(new OptChild)
child.io.a := "hdeadbeef".U
child.io.b := "hbadcad00".U
child.io.s := true.B
io.out := child.io.z
}
object OptimizeTop extends App {
chisel3.Driver.execute(args, () => new Optimize)
}
The emitted Verilog looks like:
module Optimize(
input clock,
input reset,
output [31:0] io_out
);
assign io_out = 32'hdead0000;
endmodule