Initialize variables when reset is low in Chisel 3

[Lorenzo Di Tucci]

Hi,

I'm trying to reset registers in my Chisel module whenever 'reset' signal is low since I'm constrained by another module that works in this way.

As I did not find a solution to this in Chise3, I create a simple register"

val myReg = Reg(init = true.B)

and then I pass my file into a python script that substitutes in the Verilog generated

if(reset)

with 

if(!reset)

Is there a way to initialize all variables when the reset is low?

Thanks

[Edmond Cote]

Ouch, you really shouldn't have to preprocess.  Maybe this will help.

If you search through the code, there's a notion of implicit clock and reest.  I have not tried that.

Instead, my preference is to explicitly use withClockAndReset {}.

See: https://github.com/freechipsproject/chisel3/wiki/Multiple-Clock-Domains

Here's my use case.

class LazyTop(implicit p: Parameters) extends LazyModule {
  lazy val module = new LazyRawModuleImp(this) {
    val io = IO(new Bundle {
      
      val ref_clk_p = Input(Clock())
      val rst_sw_n = Input(Bool()) // async reset, debounced on board?
      val led_n = Output(Bits(8.W))
    })

    val GSR_INST = Module(new GSR()) // this is blackbox module
    GSR_INST.io.GSR := io.rst_sw_n

    val global_reset = Wire(Bool())
    val global_reset_n = Wire(Bool())
    global_reset_n := GSR_INST.io.GSR // appears GSR is active low
    global_reset := !GSR_INST.io.GSR

    // use active high clock
    withClockAndReset(ref_clk_p, global_reset) {
      io.led_n := RegNext("h5A".asUInt(8.W), init = 0.U)
    }
  }
}

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To post to this group, send email to chisel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/425389b5-7f01-499c-8e94-3abe3ea78979%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Schuyler Eldridge]

An orthogonal, less robust approach is to lazily (in the lazy programmer sense) exploit last-connect semantics.

Whatever is the last assignment in the module is going to "win" over everything else. If you use a `when (!reset) { reset_method() }` as the last thing that you do in some Chisel this becomes the de facto reset condition (assumedly, so long as you're not defining a reset condition along with the register definition).

The thing to be careful about here is that this really has to be the last thing that happens... this can get screwed up via inheritance, trait mixin, etc. There would then be some motivation in throwing the reset condition into a trait and mix that in last.

I've used this when dealing with a somewhat complicated reset, e.g., a partial reset of a register bundle. This use of last connect semantics does decrease code readability.

I'm actually not that against postponing the processing, however, the FIRRTL compiler is the natural approach for this as opposed to post-processing Verilog which I've found to be horrendously error-prone, e.g.:

  1) Annotate modules/components with a newly-defined 'ActiveLowAnnotation'

  2) Write a FIRRTL pass that consumes the 'ActiveLowAnnotation' to make the modifications that you want

Note: I'm biased. Everything looks like a FIRRTL pass to me...

[Guy Hutchison]

This really needs to be in the wiki as the code example instead of a bare withClock().  How does one update the wiki?  Fork the chisel3 project and generate a pull req?

- Guy

[Jim Lawson]

Submit a pull request to https://github.com/ucb-bar/chisel3-wiki

To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users+unsubscribe@googlegroups.com.

To post to this group, send email to chisel...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/e4e2aa0c-0a87-460a-b35b-44d7acd71492%40googlegroups.com.