Open alvintung-sifive opened 2 years ago
I thought this should be guarded by: https://github.com/chipsalliance/chisel3/blob/f1e37900170124254f3cf4599a45e7a485c17a91/core/src/main/scala/chisel3/dontTouch.scala#L36-L38
i mean, the dontTouch
is just an example. In general I don't think we can annotate a literal value, right?
@sequencer I thought this should be guarded by:
Literals are synthesizable, they're just not nameable.
@mwachs5 i mean, the
dontTouch
is just an example. In general I don't think we can annotate a literal value, right?
You are correct, this is something of a fundamental issue.
We could make chisel3.experimental.annotate
(I'm glad it's still experimental!) take a SourceInfo
so that we could at least provide a source locator for where annotate
is called. The onus would then be on library writers to propagate that source locator. We could also encourage library writers to guard against literals (and we need to do that in dontTouch
).
Literals are synthesizable, they're just not nameable.
I see, I understand it now.
I personal think a better solution might be: DataMirror
providing more APIs for a binding to reflect a hardware type?(just pull more information from the Builder
), and user can guard it with those information? annotate
API can also check nameable
in this case as well.
Type of issue: bug report
Impact: no functional change
Development Phase: request
Other information
If the current behavior is a bug, please provide the steps to reproduce the problem: https://scastie.scala-lang.org/Yp73iZvSSaaQiViJAHyAZQ
What is the current behavior? Annotating a literal value does not provide a helpful enough error message to pinpoint the offending code.
What is the expected behavior? The error message should give the file and line number of the offending code.
Please tell us about your environment:
What is the use case for changing the behavior?