chisel-firrtl combinational loop handling

Question

I have met some troubles while simulating design that contains comb-loop. Firrtl throws exception like

"No valid linearization for cyclic graph"

while verilator backend goes normal with warnings.

Is it possible to simulate such design with firrtl backend? And can we apply --no-check-comb-loops not for all design but for some part of it while elaborating?

Example code here:

import chisel3._
import chisel3.iotesters.PeekPokeTester

import org.scalatest.{FlatSpec, Matchers}

class Xor extends core.ImplicitModule {
  val io = IO(new Bundle {
    val a = Input(UInt(4.W))
    val b = Input(UInt(4.W))
    val out = Output(UInt(4.W))
  })

  io.out <> (io.a ^ io.b)
}

class Reverse extends core.ImplicitModule {
  val io = IO(new Bundle {
    val in = Input(UInt(4.W))
    val out = Output(UInt(4.W))
  })

  io.out <> util.Reverse(io.in)
}

class Loop extends core.ImplicitModule {
  val io = IO(new Bundle {
    val a = Input(UInt(4.W))
    val b = Input(UInt(4.W))
    val mux = Input(Bool())
    val out = Output(UInt(4.W))
  })
  val x = Module(new Xor)
  val r = Module(new Reverse)

  r.io.in <> Mux(io.mux, io.a, x.io.out)

  x.io.a <> Mux(io.mux, r.io.out, io.a)
  x.io.b <> io.b

  io.out <> Mux(io.mux, x.io.out, r.io.out)
}

class LoopBackExampleTester(cc: Loop) extends PeekPokeTester(cc) {
  poke(cc.io.mux, false)

  poke(cc.io.a, 0)
  poke(cc.io.b, 1)

  step(1)

  expect(cc.io.out, 8)
}

class LoopBackExample extends FlatSpec with Matchers {
  behavior of "Loop"

  it should "work" in {
    chisel3.iotesters.Driver.execute(Array("--no-check-comb-loops", "--fr-allow-cycles"), () => new Loop) { cc =>
      new LoopBackExampleTester(cc)
    } should be(true)
  }
}

In what way does the combinational loop contribute to the working of this circuit. There is a dependency in the graph such that x.io.a depends on x.io.a without an intervening register. x.io_a -> r._T_4 -> r._T_5 -> r._T_7 -> -> r._T_8 -> r.io_out -> _T_1 -> x.io_a Chisel does not explicitly support this. There's usually another contruction. Do you have a test vector that more fully illustrates the properties you need this circuit to demonstrate — Chick Markley
actually its not, its just a reconfigurable combinational logic. comb loop will appear just in case of inconsistency of mux signal and i dont know a way to explain it to chisel-firrtl — SpaceCowboy max

Jack Koenig Jack Koenig · Accepted Answer · 2019-07-26T22:43:30

I will start by noting that Chisel is intended to make synchronous, flop-based, digital design easier and more flexible. It is not intended to represent all possible digital circuits. Fundamentally, Chisel exists to make the majority of stuff easier while leaving things that tend to be more closely coupled to implementation technology (like Analog) to Verilog or other languages.

Chisel (well FIRRTL) does not support such apparent combinational loops even if it possible to show that the loop can't occur due to the actual values on the mux selects. Such loops break timing analysis in synthesis and can make it difficult to create a sensible circuit. Furthermore, it isn't really true that the loop "can't occur". Unless there is careful physical design done here, there will likely be brief moments (a tiny fraction of a clock cycle) where there will be shorts which can cause substantial problems in your ASIC. Unless you are building something like a ring oscillator, most physical design teams will ask you not to do this anyway. For the cases where it is necessary, these designs typically are closely tied to the implementation technology (hand designed with standard cells) and as such are not really within the domain of Chisel.

If you need such a loop, you can express it in Verilog and instantiate the design as a BlackBox in your Chisel.

chisel-firrtl combinational loop handling

1 Answers