RE: [sv-ac] d4 review feedback

Hello John,

this is OK.

Thanks,
ed 

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On 
> Behalf Of John Havlicek
> Sent: Thursday, November 01, 2007 8:53 AM
> To: sv-ac@eda.org
> Subject: [sv-ac] d4 review feedback
> 
> Hi Folks:
> 
> Please find attached the D4 review feedback to be sent to 
> Stu.
> 
> Please review my rendering of the comments as LRM changes and
> send any feedback.
> 
> I would like to have a voice vote on this in our next meeting
> so that we can approve it and send it on.
> 
> Ed:  I decided not to include your comments about the Courier-Bold
> font on keywords used in the text passages.  Your response to me
> was that the editor could decide on these. I think Stu has already 
> explained what is going on: 
> 
> > Regarding use of special fonts for keywords, the LRM is full of
> > inconsistencies, but I have been trying to make it more 
> consistent as I add
> > in new changes.  I am not placing terms such as "if-else" 
> and "always
> > procedure" in the Courier-Bold keyword font because they 
> refer to a general
> > construct that has been defined elsewhere in the LRM.  For 
> example "always
> > procedures" without the keyword font is defined to include "always",
> > "always_comb", "always_latch", and "always_ff" (see 9.2 for 
> draft 4),
> > whereas "always" in Courier-Bold refers to just the "always" keyword
> > (perhaps when referring to a specific line in a code 
> example).  The term
> > "if-else" is defined as a conditional statement, which 
> might be just "if" or
> > as an "if...else" pair (see 12.4 of draft 4).
> > 
> > My suggestion is to try to follow the general LRM style for font
> > specializations in final proposals, but to not be overly 
> concerned about
> > getting it perfect.  Font usage in a proposal is a guide 
> for the editor, but
> > it should be the editor's responsibility to try to take 
> care formatting
> > details and overall consistency.  Reviews after the changes 
> are made, such
> > as this e-mail thread, are then used to determine if the editor
> > inadvertently changed the meaning of text when applying font
> > specializations.  The system of checks-and-balances we have 
> works well.
> 
> 
> The question still lingers about proving to ourselves that
> "!(bit'(b!=0))" really gives the correct representation of the "else"
> guard for procedural "if...else" when b is multi-bit 4-state.
> 
> J.H.
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
> 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.