-
Notifications
You must be signed in to change notification settings - Fork 140
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assertion checks should have knowledge of rwire/creg internals #631
Comments
do you remember why this check is happening before rwire inlining and not after? is it for historical reasons because it happened in the dark ages when rwires were not being inlined? conversely it seems that the inlining happens after astate, which seems like a pretty intentional place to do this; does it have to go after that? |
Inlining happens in the Verilog backend (which starts with In the early days, the check for I don't think that inlining can be brought forward, to before the backend split, because Bluesim operates on the design in terms of modules and rules. The |
ah right, i totally forgot about bluesim. and i guess bluesim needs this b/c it can't turn the rwire inside out and make it into an expression, which i guess is kinda the whole point of an rwire? hmm. are you thinking of specialcasing this in the SMT generation (which would need to match the InlineWires code), or an annotation (or rewriting rule?) that would be common to both? |
I was going to add special knowledge about the primitive modules I do think that we'll want to allow users to specify additional information that they know about a design, to the SMT solver, to use in analysis (including scheduling). (For example, things like: two input ports never have the same value.) I have no idea what that would look like, but I wonder if this info about primitive submodules could be represented using that feature, if it existed. Here, again, I don't think that my proposal prevents doing that in the future. |
IIRC Verilog-imported modules have a combinational path annotation that is used to detect combinational loops; I was musing that perhaps that could be extended to capture this as well. I guess the objectives are different, though: if you had some expression syntax you could convert to SMT, then in one case you'd be prepared to underapproximate and in the other to overapproximate (to stay conservative in each case), so maybe not? But yeah I agree hacking it in for now as you suggest is the right thing to do; the issue is pretty ugly when one runs into it, and I think wires are probably the main use case anyway. |
The following example produces Verilog with a RDY signal defined as 1:
However, if we add an
always_ready
attribute to the module, BSC reports that the method is not always ready:This is because the RDY signal depends on a port from the wire submodule, and BSC treats that submodule as a black box (at that point). Later, BSC inlines wires before generating Verilog, which exposes that the value is always True.
For any module that BSC knows how to inline, it would be reasonable for BSC to also consider its internals when doing assertion checks / proof obligations, like
always_ready
. BSC creates an SMT context containing the signal definitions; it can also include definitions for combination outputs from inline-able primitive modules (like rwire and creg).This is bug 968 in Bluespec Inc's pre-GitHub bug database.
The text was updated successfully, but these errors were encountered: