chisel
chisel copied to clipboard
Differences Between := and :<*= involving Analog and DontCare
I've noticed that driving an Analog with a DontCare in different ways results in differences in whether the analog can be later attached.
Basically, this is an error:
b :<= DontCare
b :<= a
Whereas this is not an error:
b := DontCare
b :<= a
The latter produces the following FIRRTL (which should probably elide the invalidate), but compiles:
invalidate b
attach (b, a)
Full example for playing around with:
//> using scala "2.13.11"
//> using repository sonatype-s01:snapshots
//> using lib "org.chipsalliance::chisel::6.0.0-M3+117-2372b1c4-SNAPSHOT"
//> using plugin "org.chipsalliance:::chisel-plugin::6.0.0-M3+117-2372b1c4-SNAPSHOT"
//> using options "-unchecked", "-deprecation", "-language:reflectiveCalls", "-feature", "-Xcheckinit", "-Xfatal-warnings", "-Ywarn-dead-code", "-Ywarn-unused", "-Ymacro-annotations"
import chisel3._
import chisel3.experimental.Analog
import circt.stage.ChiselStage
class Foo extends Module {
val a = IO(Analog(1.W))
val b = IO(Analog(1.W))
val c = IO(Analog(1.W))
b := DontCare
b :<= a
c :<= DontCare
c :<= a
}
object Main extends App {
println(
ChiselStage.emitCHIRRTL(
gen = new Foo
)
)
println(
ChiselStage.emitSystemVerilog(
gen = new Foo,
firtoolOpts = Array("-disable-all-randomization", "-strip-debug-info")
)
)
}
This produces the following error:
[error] AnalogConnect.scala 22:5: : Analog Foo.c: IO[Analog<1>] previously bulk to DontCare() is connected to Foo.a: IO[Analog<1>] at @[AnalogConnect.scala 21:5]
[error] There were 1 error(s) during hardware elaboration.
Exception in thread "main" chisel3.internal.Errors: Fatal errors during hardware elaboration. Look above for error list. Rerun with --throw-on-first-error if you wish to see a stack trace.
What is the error?
@mwachs5 wrote:
What is the error?
Edited it into the issue text at the bottom.
Basically I think this is a pitfall in chisel type system, in chisel it runtime modify the chisel type when a wire is connect to other wire.
Basically I think we need to think about embed all type information, here is the the Connectable semantic in FIRRTL spec and emit the connect IR, let firtool handle those errors. We should consider stopping detect these errors, make them a part of firrtl-spec and let a real compiler handle it.
This was added to detect a problematic case where bundles with Analog fields were assigned with a bulk connect for default values, and then later attempted to be overridden. In this instance, all non-Analog fields would be overridden, but without this error, Analog fields would be attached to both the default and the later "overriding" field.
The key incompatibility is last-connect-semantics with Analog signals doesn't make sense, so figuring out how bulk connects should work isn't likely going to have satisfactory semantics.
One idea I've been playing with is isolating last-connect-semantics with the := operator, but not with the connectable operators. So doing a :<= b; a:<= c would be an error, but a :<= b; a.x := foo would be ok.