Alsop, Thomas R wrote: > Okay, how does this look? > Mostly Ok -- see below. > > *always_comb begin : *a1 > > *unique* *case* (1’b1) > > a : z = b; > > not_a : z = c; > > *endcase * > > *end* > > > > In this example the unique-case is checking for overlap in the two > case-item selects. When a and not_a are in state 0 and 1 respectively > and a transitions to 1, this unique-case will be executed while a and ^^^^^^^ Nope -- "could be" is correct here; "will be" is not. When "a" transitions to 1 there is no guarantee about the relative scheduling so only "could be" is correct. > not_a are both true, so the violation check for uniqueness will fail. I would write this as: When a and not_a are in state 0 and 1 respectively and a transitions to 1, this unique-case could be executed with a and not_a both being 1. If that occurs, the violation check for uniqueness will fail, but since this violation check is in the active region set the failure is not reported immediately. After the update to not_a, process a1 will be rescheduled, which results in a flush of the original error. After that, the violation check will pass, and no error will be reported. Gord -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Feb 15 10:09:05 2008
This archive was generated by hypermail 2.1.8 : Fri Feb 15 2008 - 10:09:23 PST