RE: [sv-ac] Mantis 1900. Checkers

Hi Jonathan,

Please, see my comments below. I uploaded a new version into Mantis
(checkers_071120dk.pdf). This version addresses also other people
comments.

Thanks,
Dmitry

-----Original Message-----
From: Jonathan Bromley [mailto:jonathan.bromley@doulos.com] 
Sent: Thursday, November 15, 2007 8:11 PM
To: Korchemny, Dmitry; sv-ac@server.eda.org
Subject: RE: [sv-ac] Mantis 1900. Checkers

> The proposal forbids initializing continuous free variables,
> but it allows initializing sequential free variables.
> In case of an unpacked array of free variables some of
> them may be sequential and others continuous. The issue
> is that the array assignment patterns forbid partial
> initialization of the array elements (see 18.9.1).
> I relaxed this requirement for unpacked arrays of
> free variables in the new version of the proposal.

Dmitry, I apologise for interfering in AC business,
but I've been working on array assignment (in connection
with Mantis 1702) and so your comment caught my attention.

Your relaxation in 10.9.1 makes reference to 16.8.5,
but there is no further mention of assignment patterns 
anywhere in the proposal.  I think it is probably 
insufficient to say that there is an exception, 
without also specifying in detail what that 
exception is and how it is to work.

<<<
[Korchemny, Dmitry] I added the following explanation (16.5.8.1):

"Since unpacked arrays of free variables may contain both continuous and
sequential free variables, the array pattern used in the initialization
shall define only elements corresponding to the sequential free
variables. This is an exception from the general statement defined in
10.9.1 prescribing that every array element should be covered by the
array pattern. The similar rule also applies for initialization of
unpacked structures of free variables (see 10.9.2). The following
example illustrates this rule for free variable array initialization.

Example 3.
		
		freevar bit fv[1:0] = '{2'{1'b1}}; // Illegal
		assign fv[0] = a; // a is a regular variable defined
elsewhere
		always_check @clk		
			fv[1] <= !fv[1];
In this example the bit fv[0] is continuous, and therefore it shall be
illegal to initialize it. The correct initialization of fv is:
		
		freevar bit fv[1:0] = '{1:1'b1};"

Do you think it is sufficient? I also added a statement about unpacked
structures.
>>>
~~~~~~

I also noticed another issue:  In several places you
mention "assignment statement" where I am fairly sure
you are talking about *continuous* assignments of the
form
   assign v = expr;
(by contrast with *procedural* assignments).  I am not
sure exactly how this is defined in the LRM, but I think
it would be clearer if you were to use "continuous 
assignment" wherever it's appropriate, to avoid any 
risk of  confusion.

<<<
[Korchemny, Dmitry] I am using a term "assignment" without further
clarification in two cases: when the statement talks about both forms of
free variable assignments, continuous and nonblocking, or when it is
clear form the context what the type of the assignment is. E.g.,

...
assign fv2 = ~fv1;
...
the assignment of fv2 ...

Could you point to a specific example where "continuous" is missing?
>>>

Thanks
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web:
http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

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