Do you know why case inside is preferred over both casez and casex? Let’s find out 👇
Casex vs Casez vs Case inside
If you work in the RTL Design Verification field, you've likely heard fellow engineers tell you about not using casex (or even casez) in your RTL code. The reason behind this is that casex can potentially hide bugs in the design whenever the case select becomes unknown. This is because both casex and casez are symmetrical in nature, meaning that with casex, if the select becomes unknown (’❌), the case statement treats it as a don’t care condition.
Essentially, this means that the select will match with all case statements, leading to the execution of the first statement being selected and driving the output.
Do you know why the first statement will get executed?
This is where the stricter case type - case inside comes into play. Not only does it provide a cleaner syntax, but it's also asymmetrical. This means that even when the select is unknown, it doesn't become a don’t care condition. The simulator will evaluate each case statement to find a match, and if it doesn't, it will proceed to the default statement.
This approach is considered safe as it avoids masking potential bugs in the design.
Interested in learning more? Checkout my Hands-on RTL Design course at QuickSilicon for deeper insights into micro-architectural and RTL Design: quicksilicon.in
Well, that's it for this edition of the SiliconNotes.