-
Notifications
You must be signed in to change notification settings - Fork 142
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
Unexpected behavior in Stmt sequence when using par #685
Comments
Your understanding of I think these warnings are an artefact of how the bsc compiler translates StmtFSM into rules and introduces state registers to sequence actions in the FSM, after which it cannot reconstruct some properties that were clear in the original StmtFSM. The attached code shows a "hand-translation" of the above StmtFSM into rules, using a particular choice of state variables to control the seq/par sequencing. When you compile it, it produces similar compiler warnings, the first of which is:
This warning is unnecessary if we recognize either of the following properties, which make the rules mutually exclusive. Both properties are clear from the original StmtFSM structure, but perhaps not so obvious from the rules:
|
It's quite possible that the StmtFSM behavior (much of which is implemented in a the library For example, in hand-written code, it's possible to silence the warning by telling BSC that you know two rules will never be enabled at the same time, using |
I am using the
StmtFSM
package to implement a protocol handler. A minimized example would be as follows:What I expect to happen here is that the FSM sets
control
to 1 in the first action, then executes the par block where it setscontrol
to 2 and waits for the ready flag to be set, before it continues to the final action where it setscontrol
back to 0. When compiling this however I get the following warnings:Removing the
par
statements, changing the sequence toresults in expected behavior where bsc appropriately determines the rules are mutually exclusive.
Is my understanding of
par
incorrect? I tried wrapping the three phases inseq endseq
blocks to try and force the schedule/sequence, but any time I introduce a par it looks likebsc
schedules all rules in the sequence in parallel, resulting in conflicts.The example above was tested to reproduce on the just released version 2024.01.
The text was updated successfully, but these errors were encountered: