RE: [sv-ac] FW: 1900 - updated version

From: Neil Korpusik <Neil.Korpusik_at_.....>
Date: Sat Feb 23 2008 - 17:23:44 PST
<forwarding bounced email from dmitry.korchemny@intel.com>


> ------------------------------------------------------------------------
> 
> Subject: RE: [sv-ac] FW: 1900 - updated version
> From: "Korchemny, Dmitry" <dmitry.korchemny@intel.com>
> Date: Thu, 21 Feb 2008 13:50:33 +0200
> To: "Bresticker, Shalom" <shalom.bresticker@intel.com>, sv-ac@server.eda.org
> CC: Brad Pierce <Brad.Pierce@synopsys.com>
> 
> Hi Shalom,
> 
> There is no such restriction. Exactly as concurrent assertions don’t 
> limit their expressions to be of bit type,
> 
> Dmitry
> 
> ------------------------------------------------------------------------
> 
> *From:* Bresticker, Shalom
> *Sent:* Thursday, February 21, 2008 1:48 PM
> *To:* Korchemny, Dmitry; sv-ac@server.eda.org
> *Cc:* Brad Pierce
> *Subject:* RE: [sv-ac] FW: 1900 - updated version
> 
> I did not see, browsing quickly, that checkvars are limited to 2-state 
> types. If so, the other side of the coin is that elsewhere the default 
> type is 4-state, and it would be inconsistent if the default here would 
> be 2-state. I am not taking a position, but it is a consideration.
> 
> Also, assuming that a free variable can be a 4-state type, can a tool 
> assign it x or z values? If that is not intended, maybe the text should 
> restrict the assigned values to the 2-state set.
> 
> Shalom
> 
>     ------------------------------------------------------------------------
> 
>     *From:* owner-sv-ac@server.eda.org
>     [mailto:owner-sv-ac@server.eda.org] *On Behalf Of *Korchemny, Dmitry
>     *Sent:* Thursday, February 21, 2008 1:22 PM
>     *To:* sv-ac@server.eda.org
>     *Cc:* Brad Pierce
>     *Subject:* [sv-ac] FW: 1900 - updated version
> 
>     Hi all,     
> 
>     I am forwarding Brad’s comments. Let’s discuss them at today’s meeting.    
> 
>     Thanks, 
>     Dmitry      
> 
>     ------------------------------------------------------------------------
> 
>     For users, a very popular advantage of the Verilog "look and
>     feel" vs. VHDL is that Verilog is felt to be "less verbose" than
>     VHDL.   We need to try to preserve that perceived advantage as we
>     add new features.
> 
>     Judging by the examples, it is exceedingly rare for a checker
>     variable to not be either a bit or vector of bits.  So it seems
>     unnecessary to force people to write    
> 
>               **checkvar bit** x;
>               **checkvar bit** [1:0] y;    
> 
>     instead of simply writing
>  
>               **checkvar** x; 
>               **checkvar** [1:0] y;      
> 
>     I recommend making the default type here '**bit**', just as the
>     default data type for '**var**' is '**logic**'.  For more on
>     that  see after Syntax 6-2 with the examples like      
> 
>     **        var **v; // equivalent to "var logic v;"
>     *        var *[15:0] vw; // equivalent to "var logic [15:0] vw;"      
> 
>     And, for checkvars, is the generality of allowing other datatypes
>     even needed at all?  If not, then better to make the simpler syntax
>     mandatory instead of optional, and //require//        
> 
>               **checkvar **x;
>               **checkvar** [1:0] y; 
>      
> 
>     Finally, the proposed new "**free**" syntax doesn't seem like the
>     best choice to me.  The proposal consistently refers to these as
>     "free variables", not as "free checker variables", so in my opinion,
>     "**freevar**" would be a more natural keyword.  Instead of
> 
>               **free** **checkvar bit** x; 
>               **free checkvar bit** [1:0] y;      
> 
>     one would write
 >
>               **freevar** x;
>               **freevar** [1:0] y;
>  
>     That's not just easier to write -- it's easier to read and understand.
> 
>     -- Brad
> 
>     ---------------------------------------------------------------------


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat Feb 23 17:24:10 2008

This archive was generated by hypermail 2.1.8 : Sat Feb 23 2008 - 17:26:46 PST