Boring from parent module with probe doesn't get a necessary :#= assignment #3557
Comments
This should be optimized away by CIRCT, if it's not LMK 👍 . It does seem like it may simplify things a bit. In a sense a All good, but curious/interested: what's the reason/challenges preventing having |
It's due to current implementation. This can be changed. The problem is that To be able to use tl;dr: there are some infrastructure changes that have to happen. |
Expected result is fully aligned, which is what happens when reading from a probe. When the source is already at the LCA (from parent) there's no probe and the secret connections only support a few commands. For lack of a way to do, e.g., `:#=` here, use `read(probe(x))` to get the fully aligned result that's expected and bored down to the child. This isn't ideal but fixes this using only the sorts of expressions and commands that we've already committed to supporting. Fixes #3557.
Expected result is fully aligned, which is what happens when reading from a probe. When the source is already at the LCA (from parent) there's no probe and the secret connections only support a few commands. For lack of a way to do, e.g., `:#=` here, use `read(probe(x))` to get the fully aligned result that's expected and bored down to the child. This isn't ideal but fixes this using only the sorts of expressions and commands that we've already committed to supporting. Fixes #3557.
Expected result is fully aligned, which is what happens when reading from a probe. When the source is already at the LCA (from parent) there's no probe and the secret connections only support a few commands. For lack of a way to do, e.g., `:#=` here, use `read(probe(x))` to get the fully aligned result that's expected and bored down to the child. This isn't ideal but fixes this using only the sorts of expressions and commands that we've already committed to supporting. Fixes #3557.
Expected result is fully aligned, which is what happens when reading from a probe. When the source is already at the LCA (from parent) there's no probe and the secret connections only support a few commands. For lack of a way to do, e.g., `:#=` here, use `read(probe(x))` to get the fully aligned result that's expected and bored down to the child. This isn't ideal but fixes this using only the sorts of expressions and commands that we've already committed to supporting. Fixes #3557. (cherry picked from commit 0dbedc3) # Conflicts: # core/src/main/scala/chisel3/RawModule.scala
Expected result is fully aligned, which is what happens when reading from a probe. When the source is already at the LCA (from parent) there's no probe and the secret connections only support a few commands. For lack of a way to do, e.g., `:#=` here, use `read(probe(x))` to get the fully aligned result that's expected and bored down to the child. This isn't ideal but fixes this using only the sorts of expressions and commands that we've already committed to supporting. Fixes #3557. (cherry picked from commit 0dbedc3) # Conflicts: # core/src/main/scala/chisel3/RawModule.scala
…4096) * Fix boring tap of non-passive source from parent. (#4083) Expected result is fully aligned, which is what happens when reading from a probe. When the source is already at the LCA (from parent) there's no probe and the secret connections only support a few commands. For lack of a way to do, e.g., `:#=` here, use `read(probe(x))` to get the fully aligned result that's expected and bored down to the child. This isn't ideal but fixes this using only the sorts of expressions and commands that we've already committed to supporting. Fixes #3557. (cherry picked from commit 0dbedc3) # Conflicts: # core/src/main/scala/chisel3/RawModule.scala * Resolve backport conflicts --------- Co-authored-by: Will Dietz <will.dietz@sifive.com> Co-authored-by: Jack Koenig <koenig@sifive.com> Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>
Type of issue: Bug Report
Please provide the steps to reproduce the problem:
See the test in #3556. Even if fixing the issue reported there, the test will not pass, because as shown in the picture below, we implement the single black arrow not the dotted two-part arrow:
What is the current behavior?
Note the bottom arrow in the picture: when we are goign straight from a bidirectional thing, and then turning it into an Input, we dont have any part of the code that does the stripping of direction and then using a
:#=operator to drive the stripped-direction input to the bidirectional "real thing".When there is a layer of hierarchy in the middle:
we have to first create the probe, which handles the stripping and the define works without the
#:=.What is the expected behavior?
We need to not emit a
connectfrom a bidirectional thing to a monodirectional thing.This can be done by either emitting the individual fields (as in the
:#=would handle) or by making a probe define and then read in the same layer of hierarchy.The former is a little tricky to implement because we can't directly use the
:#=operator in the boring APIs, we can only add commands to the secretCommands, and there is no direct translation from:#=to the commands we would want to add to secretCommands.It might be simpler to just always make the probe, define, and read even if we are in the same layer of heirarchy.
Please tell us about your environment:
Other Information
What is the use case for changing the behavior?
Need to get code compiling. There is a possible workaround -- users can make the Wire(Output(...)) themself in the source of the tap.
The text was updated successfully, but these errors were encountered: