Hi Neil, Thanks for the comments. Please see my embedded remarks. Regards, Doug > -----Original Message----- > From: Neil.Korpusik@Sun.COM [mailto:Neil.Korpusik@Sun.COM] > Sent: Saturday, March 17, 2007 7:30 PM > To: Warmke, Doug > Cc: SV_EC List > Subject: More comments on mantis 890 (part 1) > > Hi Doug, > > I have the following comments on mantis 890 version 8 (part 1). > > Page 2, section 15.10 > > - The note at the bottom of the changes to this section is redundant. > The text at the bottom of the second blue paragraph on this > page discusses > this already. > > I think that this note should be removed. DOUG: Done in SV-890-9. > > Page 2, section 15.12 > > - The note was changed in version 8 of the proposal. > > "NOTE - When the clocking block event is triggered by the > execution of a > program, there is a potential race between the update of a > clocking block > input value and programs that read that value without > synchronizing with > the corresponding clocking event." > > The following text was added: "... without synchronizing with the > corresponding clocking event." > > Can't a race occur even if the synchronization is taking place? DOUG: Already discussed in the last SV-EC meeting. No change made to the 890 proposal. > > Page 3, section 15.14, first blue paragraph > > - "For zero skew clocking block outputs with no cycle delay, > synchronous > drives shall schedule new values in the Re-NBA region of > the current time > slot." > > This isn't always true. As mentioned in the previous paragraph "the > corresponding signal changes value at the indicated > clocking event". > The statement which performs the synchronous drive may not > be executing in > the time slot where the clocking event occurred. So this > statement about > scheduling in the current time slot is not always true. > The synchronous > drive may need to be scheduled in the time slot > corresponding to the next > clocking event. DOUG: Changes made as per discussion in last SV-EC meeting. > > page 4, section 15.14, second paragraph > > - The first part of this paragraph has changes from the LRM, > which are no > longer in blue. > > For some reason, the first set of changes to this paragraph > are no longer > in blue. Version 7 of the proposal looks correct, version 8 > seems to have > some blue text shown in black. > > "...value after the ## in the cycle_delay production..." > should be blue? > And the corresponding text being replaced should show up > with red cross outs. DOUG: Oops, I don't know how that happened. The editing markups have been restored to their condition in SV-890-7. > > > Page 6, section 15.14.2, next to the last blue paragraph > > - Typo > > "If a synchronous drive and a procedural assignment write > to the same > variable in the same time, the writes shall take place in > an arbitrary > order." > > This text had a problem in version 7 of the proposal, it > was updated in > version 8, but it still isn't quite right. > > From: > in the same time, the > To: > in the same time slot, the DOUG: Done in SV-890-9. Thanks again, Doug > > Neil > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Mar 30 00:39:07 2007
This archive was generated by hypermail 2.1.8 : Fri Mar 30 2007 - 00:39:42 PDT