-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
Add unique
, unique0
, and priority
keywords
#937
Comments
A synthesis tool can make very aggressive optimization for a case/if statement with |
At the point of view of syntax complexity, adding #[cond_type(unique)]
case a {
}
#[cond_type(priority)]
case a {
}
#[cond_type(unique0)]
if a {
} else if b {
} else {
} About condition overlapping, mismatch between simulation and synthsis can be avoided if these modifiers are allowed when all conditions can be checked by Veryl compiler statilcally. param X: u32 = 1;
const Y: u32 = 1;
// OK
#[cond_type(unique0)]
case a {
0: x = 1;
Y: x = 2;
}
// NG because X may be overridden
#[cond_type(unique0)]
case a {
X: x = 1;
} |
I think Veryl also needs to check that all possible values for the case condition expression are listed as case items. |
There should not be a mismatch between synthesis and simulation in the sense that simulation will emit an error (or perhaps warning, I forget) in the case that no cases match, or more than a single case matches. I do like the idea of a compiler switch which automatically removes the non-priority I do not see how Veryl can possibly be expected to check condition overlapping. Consider a microprocessor design which purposely does not check for illegal instructions (e.g., a microcontroller executing firmware embedded in an SoC). A mux may only need to handle valid opcodes, but how is Veryl to know this? In the presence of external controllability don't cares, I think static analysis in Veryl is insufficient. |
Yes. Veryl can't check overlapping in all cases. |
I think this is exactly the wrong approach. If Veryl can check these conditions, then any logic synthesis tool will, also. These modifiers exist explicitly to enable encoding of external controlability don't cares. That is, they exist to be used precisely when logic synthesis tools (and thus Veryl) cannot check condition overlapping, condition uniqueness, etc. It would be like only allowing |
I understood like below. Is this right?
|
Yes on points 1, 2, 4.
Point 3, I disagree with the statement that there is mismatch between
simulation and synthesis.
In simulation, if `unique` is used and zero or more than 1 case match (or,
if zero or more than one if condition evaluates to true), then an
error/warning is emitted.
In simulation, if `unique0` is used and more than 1 case match (or, if more
than one if condition evaluates to true), then an error/warning is emitted.
…On Mon, Sep 9, 2024 at 8:18 PM Naoya Hatta ***@***.***> wrote:
I understood like below. Is this right?
- When condition is static and overlapping check can be done by tools,
synthesizer can optimize enough without these keywords.
- When these checking can't be done, designer notify the condition
uniqueness to synthesizer through these keywords. This enables additional
optimization which is impossible without these keywords.
- If there is any overlapping contrary to the keyword, mismatch
between simulation and synthesis occurs. Designer is responsible for the
condition ensurance.
- If these keywords are removed by compiler switch, mismatch doesn't
occur, but some optimizations may be disabled.
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/veryl-lang/veryl/issues/937*issuecomment-2339372052__;Iw!!DZ3fjg!_L9gTQH4KHQ0YLuIiyDeBhsJhV3QcX_9fJZaCwNpMWdPSHXtq9tXNC16DNLkwxzXBYCcbFEXydIgcSHw4qcGw315P8lV$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFAMUBETCSMFOWTYTHZXMXDZVY3EFAVCNFSM6AAAAABNURDUSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZZGM3TEMBVGI__;!!DZ3fjg!_L9gTQH4KHQ0YLuIiyDeBhsJhV3QcX_9fJZaCwNpMWdPSHXtq9tXNC16DNLkwxzXBYCcbFEXydIgcSHw4qcGw87ueaW5$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Very Respectfully,
Nathaniel Bleier
***@***.***
773-531-8229 (Cell)
|
I agree wrong usage of these keywords emits warning, but in many cases simulator works fine with warning messages. |
Regarding this idea, we cannot remove these quarifiers automatically if no default item is specified. always_comb begin
case (onehot)
3'b001: idx = 2'b01;
3'b010: idx = 2'b10;
3'b100: idx = 2'b11;
endcase
end synthesis tools will infer latch logic. always_comb {
#[cond_type(unique)]
case onehot {
3'b001: idx = 1;
3'b010: idx = 2;
#[default]
3'b100: idx = 3;
}
} If the build option to remove qualifiers is set false then Veryl will emmit SV RTL like below. always_comb begin
unique case (onehot)
3'b001: idx = 1;
3'b010: idx = 2;
3'b100: idx = 3;
endcase
end If the option is set true then Veryl will emmit SV RTL like below. always_comb begin
case (onehot)
3'b001: idx = 1;
3'b010: idx = 2;
default: idx = 3;
endcase
end
|
We have to trust designer if RTL code including case/if statements with these quialifiers works correctly. |
I think clean RTL should have no message because messages shown at all time will be ignored.
|
I agree with this idea. |
Yes. |
For if statement, how should we add |
The trailing `else` branch can be the default automatically.
…On Thu, Sep 12, 2024 at 9:09 AM Taichi Ishitani ***@***.***> wrote:
By the way, should Veryl support adding these quialifier to if statement?
Yes.
For if statement, how should we add default attribute?
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/veryl-lang/veryl/issues/937*issuecomment-2346240855__;Iw!!DZ3fjg!_SMz3XJZJXmDoQSpia42P5agKV86jvFdw6eAliigVbGhZ2gtEmvd2DIisxyVxyEiMuMv4zqF3AWsnI3QvvZh2UC21s3H$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFAMUBEZCCL7NMSAE2I5NGDZWGHALAVCNFSM6AAAAABNURDUSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBWGI2DAOBVGU__;!!DZ3fjg!_SMz3XJZJXmDoQSpia42P5agKV86jvFdw6eAliigVbGhZ2gtEmvd2DIisxyVxyEiMuMv4zqF3AWsnI3QvvZh2R5DZTPR$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Very Respectfully,
Nathaniel Bleier
***@***.***
773-531-8229 (Cell)
|
How about if statement without else branch like this? if onehot[0] {
idx = 1;
} else if onehot[1] {
idx = 2;
} else if onethot[2] {
idx = 3;
} |
With unique it is semantically equivalent to the version where the last
block is unconditional.
Without unique, we can just default the last block to be unconditional.
…On Thu, Sep 12, 2024, 6:38 PM Taichi Ishitani ***@***.***> wrote:
How about if statement without else branch like this?
if onehot[0] {
idx = 1;} else if onehot[1] {
idx = 2;} else if onethot[2] {
idx = 3;}
—
Reply to this email directly, view it on GitHub
<https://urldefense.com/v3/__https://github.com/veryl-lang/veryl/issues/937*issuecomment-2347359892__;Iw!!DZ3fjg!_6C6rKVp5nhuhXiWnZuBNaq9BeupyB02odp7h_VrzaPs1QCsFnERSARZi7Inu215lXTIpwE_wM3OE3fQOYaVUkSA7vyt$>,
or unsubscribe
<https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AFAMUBGUDXN6DHMKN6332ITZWIJUPAVCNFSM6AAAAABNURDUSSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNBXGM2TSOBZGI__;!!DZ3fjg!_6C6rKVp5nhuhXiWnZuBNaq9BeupyB02odp7h_VrzaPs1QCsFnERSARZi7Inu215lXTIpwE_wM3OE3fQOYaVUva7eCzY$>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
OK, I agree. case (onehot)
3'b001: idx = 1;
3'b010: idx = 2;
default: begin
assume (onhot == 3'b100)
else $error("unexpected condtion is matched");
idx = 3;
end
endcase
if (onehot[0]) begin
idx = 1;
end else if (onehot[1]) begin
idx = 2;
end else begin
assume (onehot[2])
else $error("unexpected condtion is matched");
idx = 3;
end |
That works with the caveat that it does not produce error on uniqueness violation. So if more than one case or branch evaluates to true, no error or warning is emitted. Perhaps this is fine, though. |
Consider
Synthesizing this with
dc_shell
results in inferred latches (ignore for a moment the fact that DC doesn't error out when latches are inferred in analways_comb
block) because only three out of eight possible mux selects are handled in the switch statement.This can be fixed by adding a default case, or by adding a default assignment prior to the switch statement. However, this infers unnecessary logic when we are guaranteed the external controllability constraint that
onehot
is, in fact, one-hot.However, adding the
unique
keyword solves this problem optimally:The
unique case
is a mechanism for the RTL designer to encode controllability constraints. It encodes the designer's guarantee to the synthesis tool / simulator / model checker that for each evaluation of the switch control signal, exactly one case in the switch statement will match. Similarly,unique
can be used to qualifyif-else if*-else
statements.Other SV2009 keywords
unique0
andpriority
also modify the semantics of control statements.The text was updated successfully, but these errors were encountered: