Doing constrained random verification is pretty easy on paper. You know what the transactions look like and what constraints you want to apply to their fields. It gets trickier when you want to convert this intent into a real life verification environment by building all the sequence items and sequences. If done improperly, this can lead to a lot of doubled up work. A problem I've hit a couple of times is how to handle my constraints so as to avoid scattering them all over the place.
This constraint is producing:
Warning: RC_1013 …/sv/vgm_ahb_seq_lib.svh(45): Randomization failed. Cyclic dependency between functions with random arguments detected.
Is
burst inside { VGM_AHB_INCR4, VGM_AHB_INCR8, VGM_AHB_INCR16 }
a constraint or a conditional?
It should be interpreted as a conditional in thit context. The idea is that the solver chooses a value for ‘burst’ and then based on the value it chose it constraints ‘addr[10:0]’.
The constraint is uni-directional (because given an ‘addr’ we can’t constrain the ‘burst’), but it doesn’t create any cyclical dependency, just an ordering. This is described in the IEEE 1800-2012 standard in section ‘18.5.12 Functions in constraints’.
It might be that your simulator doesn’t like ‘->’. Try using ‘if (burst …) addr == …’ instead.
We basically want to say that (addr+burst_size-1)[31:10] == addr[31:10], where addr[31:10] is the 1kb block we start in and addr+burst_size-1 is the last address in the burst. Using just [9:0] isn’t enough, as those bits can toggle freely within a 1kb block.
Using just addr[9:0] maybe would be possible, by saying something addr[9:0]+burst_size -1 < 'h40000, but we’d also need the extra constraint that burst_size <= 'h40000 to handle wrap around.
Either of the two is probably more readable than the code in the post.
