Issue indexing an array constraint
Status: Beta
Brought to you by:
mballance
The following code should index properly. It compiles and runs on all major simulators. (Even though every constraint solver treats it differently)
class pkt; rand bit one_beat; rand int len; rand bit [31:0] addr; constraint wr_c { if (!one_beat) { addr[5:0] == 0, len == 15 }; } endclass
Hmm... I can see how this is being interpreted, but am at a bit of a loss as to how to parse it J
SVEditor's parser is a recursive-descent parser, so when it see '{' after a constraint 'if', it concludes that the 'if' is followed by a constraint block. The intent appears to be for the 'if' to be followed by a concatenation expression. Is that your interpretation?
In this case, '{' could be either a constraint block or an array.
VCS treats the above constraint like this:
This is a tricky one. You would almost have to run a check to see if it is
a concatenation before running the actual parser to run normally which
would slow things down, or find a way to unwind the db in case things go
wrong.
Almost easier to run an IsConcatenation check, because almost anything is
possible following an open brace ( another if, constraint etc.). Would the
check have to be run on every { in a constraint block? Don't know the lrm
well enough.
On Feb 15, 2014 1:18 PM, "Victor Lyuboslavsky" vxl119@users.sf.net wrote:
Related
Bugs:
#317Okay, I have a fix that (hopefully) doesn't add too much overhead. The fix is to do an IsConcat check when entering a potential constraint_set block after if, else, and foreach. The IsConcat check spins the lexer ahead, saving tokens, until a ',' ';' or matching brace is found. If the stopping token is a ',' then it must be a concat.
Admittedly, the heuristic may be a bit crude, but it's unlikely to give false positives.
This code will be in 1.5.3
I assume statements without a ',' will also work, like:
Yes, that's correct.