BTF Please review and VOTE on B35

From: Anders Nordstrom (andersn@nortelnetworks.com)
Date: Fri Jun 18 1999 - 07:30:09 PDT

BAD MSG:
<x-html><!doctype html public "-//w3c//dtd html 4.0 transitional//en">
html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#FF0000" alink="#000088">
Team,
<p>Please review the enclosed proposal for B35 PLA System Task Enhancement.
<br>Tom had an action to review it with his developers. His response is
included below:
<p>Subject:
<br> Re: BTF B35 PLA Enhancement
<br> Date:
<br> Thu, 17 Jun 1999 09:22:58
-0400
<br> From:
<br> Tom Fitzpatrick &lt;tfitz@Cadence.COM>
<br> To:
<br> "Nordstrom, Anders [SKY:1V29-I:EXCH]"
&lt;andersn@americasm01.nt.com>
<br>
<br>
<br>
<p>According to our developers, there's no problem with this. Please send
it out for a vote and count me as "in favor".
<br>
<p>Thanks,
<p>-t
<br>
<p>Please vote via email to the BTF reflector before June 30.
<br>I vote in favour of this enhancement request
<p>Regards,
<p> Anders
<br>
<pre>--
+-------------------------------------------------------------------------+
| Anders Nordstrom |
| Manager OC192 Data ASIC Development |
| |
| Nortel Networks Email: andersn@nortelnetworks.com |
| P.O. Box 3511 Station C Phone: 613-763-9186 |
| Ottawa, Ontario K1Y 4H7 Fax: 613-763-2626 |
+-------------------------------------------------------------------------+</pre>
 
</body>
</html>
</x-html><x-html><HTML>
<HEAD>
<TITLE> B35 </TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF">
 
<BR>
<HR SIZE=5 NOSHADE>
 
<H2> B35 - PLA System Task Enhancement </H2>
Content-Length: 8064
X-Lines: 203
X-Status: $$$$
X-UID: 0000000965
Status: RO

<TABLE BORDER COLS=2 WIDTH="75%" >
<TR><TD>
Section: </TD><TD> 14.6 page 197
</TD></TR><TR><TD>
Date Submitted: </TD><TD> 980827
</TD></TR><TR><TD>
Requestor: </TD><TD> Shalom Bresticker (shalom@msil.sps.mot.com)
</TD></TR><TR><TD>
Status: </TD><TD> Proposal
</TD></TR><TR><TD>
Analyzed by: </TD><TD> Anders Nordstrom
</TD></TR><TR><TD>
Synthesizable: </TD><TD> No
</TD></TR>
</TABLE>

<H3> Details </H3>

The PLA system tasks are described in section 14.6.

The arguments of the tasks are in the form:
<PRE>
( memory_name, input_terms, output_terms )
</PRE>
where input_terms and output_terms are defined as:
<PRE>
input_terms ::= { scalar_variables }
output_terms ::= { scalar_variables }
</PRE>
That is, the input and output terms are concatenations of scalar variables,
where a scalar variable is either a scalar identifier or
a bit select of a vector.

But vectors and part-selects are not allowed !
<P
This is a tremendous absurdity!

Why can't
<PRE>
$async$or$array(pla_or_array, { ip0[199],
  ip0[198], ip0[197], ip0[196], ip0[195], ip0[194], ip0[193], ip0[192], ip0[191], ip0[190], ip0[189],
  ip0[188], ip0[187], ip0[186], ip0[185], ip0[184], ip0[183], ip0[182], ip0[181], ip0[180], ip0[179],
  ip0[178], ip0[177], ip0[176], ip0[175], ip0[174], ip0[173], ip0[172], ip0[171], ip0[170], ip0[169],
  ip0[168], ip0[167], ip0[166], ip0[165], ip0[164], ip0[163], ip0[162], ip0[161], ip0[160], ip0[159],
  ip0[158], ip0[157], ip0[156], ip0[155], ip0[154], ip0[153], ip0[152], ip0[151], ip0[150], ip0[149],
  ip0[148], ip0[147], ip0[146], ip0[145], ip0[144], ip0[143], ip0[142], ip0[141], ip0[140], ip0[139],
  ip0[138], ip0[137], ip0[136], ip0[135], ip0[134], ip0[133], ip0[132], ip0[131], ip0[130], ip0[129],
  ip0[128], ip0[127], ip0[126], ip0[125], ip0[124], ip0[123], ip0[122], ip0[121], ip0[120], ip0[119],
  ip0[118], ip0[117], ip0[116], ip0[115], ip0[114], ip0[113], ip0[112], ip0[111], ip0[110], ip0[109],
  ip0[108], ip0[107], ip0[106], ip0[105], ip0[104], ip0[103], ip0[102], ip0[101], ip0[100], ip0[99],
  ip0[98], ip0[97], ip0[96], ip0[95], ip0[94], ip0[93], ip0[92], ip0[91], ip0[90], ip0[89],
  ip0[88], ip0[87], ip0[86], ip0[85], ip0[84], ip0[83], ip0[82], ip0[81], ip0[80], ip0[79],
  ip0[78], ip0[77], ip0[76], ip0[75], ip0[74], ip0[73], ip0[72], ip0[71], ip0[70], ip0[69],
  ip0[68], ip0[67], ip0[66], ip0[65], ip0[64], ip0[63], ip0[62], ip0[61], ip0[60], ip0[59],
  ip0[58], ip0[57], ip0[56], ip0[55], ip0[54], ip0[53], ip0[52], ip0[51], ip0[50], ip0[49],
  ip0[48], ip0[47], ip0[46], ip0[45], ip0[44], ip0[43], ip0[42], ip0[41], ip0[40], ip0[39],
  ip0[38], ip0[37], ip0[36], ip0[35], ip0[34], ip0[33], ip0[32], ip0[31], ip0[30], ip0[29],
  ip0[28], ip0[27], ip0[26], ip0[25], ip0[24], ip0[23], ip0[22], ip0[21], ip0[20], ip0[19],
  ip0[18], ip0[17], ip0[16], ip0[15], ip0[14], ip0[13], ip0[12], ip0[11], ip0[10], ip0[9],
  ip0[8], ip0[7], ip0[6], ip0[5], ip0[4], ip0[3], ip0[2], ip0[1], ip0[0]},
 {out[0], out[1], out[2], out[3], out[4], out[5], out[6], out[7], out[8],
  out[9], out[10], out[11], out[12], out[13], out[14], out[15], out[16], out[17], out[18],
  out[19], out[20], out[21], out[22], out[23], out[24], out[25], out[26], out[27], out[28],
  out[29], out[30], out[31], out[32], out[33], out[34], out[35], out[36], out[37], out[38],
  out[39], out[40], out[41], out[42], out[43], out[44], out[45], out[46], out[47], out[48],
  out[49], out[50], out[51], out[52], out[53], out[54], out[55], out[56], out[57], out[58],
  out[59], out[60], out[61], out[62], out[63], out[64], out[65], out[66], out[67], out[68],
  out[69], out[70], out[71], out[72], out[73], out[74], out[75], out[76], out[77], out[78],
  out[79], out[80], out[81], out[82], out[83], out[84], out[85], out[86], out[87], out[88],
  out[89], out[90], out[91], out[92], out[93], out[94], out[95], out[96], out[97], out[98],
  out[99], out[100], out[101], out[102], out[103], out[104], out[105], out[106], out[107], out[108],
  out[109], out[110], out[111], out[112], out[113], out[114], out[115], out[116], out[117], out[118]});
</PRE>
be written simply as
<PRE>
$async$or$array(pla_or_array, { ip0[199:0] } , { out[0:118] } );
</PRE>
(This is just an example. Our real pla is about 8 times larger!)

Compilers are smart enough these days!!
<BR>
In addition, the arguments of the tasks are in the form:
<PRE>
( memory_name, input_terms, output_terms )
</PRE>
where input_terms and output_terms are defined as:
<PRE>
input_terms ::= { scalar_variables }
output_terms ::= { scalar_variables }
</PRE>
However, "scalar_variables" is not defined.

Nor is it written that while input_terms may be wires,
output_terms must be regs.
<BR>
There is neither an explanation nor an example.
<BR>
Without these, it is not possible to even guess how to use them.
<BR>
The truth is, the Cadence VXL RM is not much better,
but it does show this example:
<PRE>
forever @(posedge clk)
        $sync$and$array(mem, { ... }, { ... } ) ;
</PRE>
>From this, it is possible to guess that the $async tasks
are like continous assignments: the outputs are re-evaluated
whenever one of the inputs changes.

In contrast, the $sync tasks are like procedural assignments:
the outputs are re-evaluated only when the task is explicitly
called. To re-evaluate the outputs again, you have to call the
task again.
<BR>
This information about how to use the $sync tasks is essential
and currently missing.

Sincerely,
<PRE>
******************************************************************************
Shalom Bresticker email: shalom@msil.sps.mot.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522444
http://www.motorola-semi.co.il/
******************************************************************************
</PRE>

<H3> Proposal </H3>

Change Syntax 14-9 on page 197 in LRM 1995 from:

<PRE>
input_terms ::= <B>{</B> scalar_variables <B>}</B>
output_terms ::= <B>{</B> scalar_variables <B>}</B>
</PRE>
to
<PRE>
input_terms ::= <B>{</B> netl_value { , netl_value} <B>}</B>
output_terms ::= <B>{</B> netl_value { , regl_value} <B>}</B>

<HR SIZE=5 NOSHADE>
</BODY>
</HTML>
</x-html>From ???@??? Fri Jun 18 10:06:34 1999
Return-Path: <owner-btf@boyd.com>
Received: (from majordomo@localhost)
        by gw.boyd.com (8.9.3/8.9.3) id KAA28042
        for btf-list; Fri, 18 Jun 1999 10:01:50 -0700
X-Authentication-Warning: gw.boyd.com: majordomo set sender to owner-btf@boyd.com using -f
Received: from up.cyrix.com (upp.go.cyrix.com [206.103.90.90])
        by gw.boyd.com (8.9.3/8.9.3) with ESMTP id KAA28038
        for <btf@boyd.com>; Fri, 18 Jun 1999 10:01:40 -0700
Received: from gemini.eng.cyrix.com (gemini.cyrix.com [147.5.10.50])
        by up.cyrix.com (Pro-8.9.2/Pro-8.9.2) with ESMTP id LAA10882;
        Fri, 18 Jun 1999 11:59:56 -0500 (CDT)
Received: from ester (ester.eng.cyrix.com [147.5.2.68])
        by gemini.eng.cyrix.com (Pro-8.9.2/Pro-8.9.2) with SMTP id LAA09991;
        Fri, 18 Jun 1999 11:57:21 -0500 (CDT)
Message-Id: <199906181657.LAA09991@gemini.eng.cyrix.com>
Date: Fri, 18 Jun 1999 11:58:59 -0500 (CDT)
From: Adam Krolnik <adamk@cyrix.com>
Reply-To: Adam Krolnik <adamk@cyrix.com>
Subject: Re: BTF Please review and VOTE on B35
To: andersn@nortelnetworks.com
Cc: btf@boyd.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 7mdvDOuF8V4qSPNqTDbdCg==
X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4m sparc
Sender: owner-btf@boyd.com
Precedence: bulk
Status: RO

<p>Good afternoon Anders:

<p>I still vote for my proposed syntax.

Check netl_value and regl_value;

Both include as an option concatenation - which allows
a single element!

netl_value ::=
  net_identifier
  | net_identifier [ expression ]
  | net_identifier [msb_constant_expression : lsb_constant_expression ]
  | net_concatentation
  
concatenation ::= <b>{</b> expression {, expression} <b>}</b>

<p>The old way still works, you also can specify a single vector
as an input and an output - without the required concatenation braces.

<p><p> Adam Krolnik
    Verification Engineer
    Cyrix - NSC.
    Richardson TX. 75085

This archive was generated by hypermail 2.1.4 : Mon Jul 08 2002 - 12:53:28 PDT and
sponsored by Boyd Technology, Inc.