RE: Agenda for telecon on 25 Feb 2004

["Hamilton Carter" <hcarter@verisity.com>]

Hi,

I apologize for missing the call this morning.  I got called away at the
last minute on a work related conference call.

Best Regards,
Hamilton Carter


-----Original Message-----
From: owner-1647-l@verificationvault.com
[mailto:owner-1647-l@verificationvault.com]On Behalf Of Eran Keydar
Sent: Tuesday, February 24, 2004 9:58 AM
To: pitchumani.guru@wipro.com
Cc: 1647-fitf@ieee1647.org
Subject: Re: Agenda for telecon on 25 Feb 2004


Hi All,

I have several issues related to the paragraphs I've reviewed.

Summary of them is as follow :

1. Removing reference in the documentation to specific simulators in all
the chapters sections ( mainly in the force-release section)
2. e force behavior is not the same in vhdl and verilog.
3. Mistake in the verilog example for the force (25.3.1)
4. Wrong output for the vhdl example for force (25.3.1)
5. Release examples (25.3.2) are the same as force example - duplication.
6. 25.4.2 - specman deffered - should be removed from the standard or at
least move to be near the "verilog import".

I can describe them more tomorrow at the meeting.

Thanks,
Eran

pitchumani.guru@wipro.com wrote:

> Agenda: For Telecon 2 on 25 Feb 2004
>
>    1. All can have Issue Tracking login.
>    2. Process of issue tracking
>       (http://www.ieee1647.org/cgi-bin/bt.pl?action=help)
>    3. Issues logged:
>          1. Issue 68
>          2. Issue 97
>          3. Issue 98
>
>
>
>    4. New Issues to be logged:
>
>
>
>Hamilton’s suggestions on VHDL interface
>
>This is a very minor issue for the moment, but the hierarchy of the TOC for
Chapter 25 is incorrect.  For example, Section 25.2 is listed under a
section called 'See Also'.
>
>
>
>I propose that the original paragraph:
>
>
>
>A full or a relative VHDL path to the signal. If the signal has more than
one driver, one driver in the DUT and one in the e program, for example,
then the signal must be of a resolved type. If this name is not a constant,
it is calculated after the final step of pre-run generation.
>
>
>
>Should read:
>
>
>
>A full or a relative VHDL path to the signal.  If this name is not a
constant, it is calculated after the final step of pre-run generation.  If
the signal has more than one driver, one driver in the DUT and one in the e
program, for example, then the signal must be of a resolved type.
>
>
>    5. Comparison of verilog/vhdl interfaces:
>
> *Interface*
>
>
>
> *Verilog** Commands in e*
>
>
>
> *VHDL commands in e*
>
> Stub
>
>
>
> verilog code
>
>
>
> vhdl code
>
> Function
>
>
>
> verilog function
>
>
>
> vhdl function
>
> Text macro
>
>
>
> verilog import
>
>
>
> Task/procedure
>
>
>
> verilog task
>
>
>
> vhdl procedure
>
> Time
>
>
>
> verilog time
>
>
>
> vhdl time
>
> Reg/wire
>
>
>
> verilog variable
>
>
>
> Memory
>
>
>
> verilog variable
>
>
>
> Driver
>
>
>
>
>
> vhdl driver
>
>    6. System C interface:
>
> Reference in the LRM
>
> Suggestions?
>
>    7. SystemVerilog:
>
> Suggestions?
>
>    8. Simulation Related Actions/Expressions/Routines
>
> Errors?
>
> Suggestions?
>
>Confidentiality Notice
>
>The information contained in this electronic message and any attachments to
this message are intended
>for the exclusive use of the addressee(s) and may contain confidential or
privileged information. If
>you are not the intended recipient, please notify the sender at Wipro or
Mailadmin@wipro.com immediately
>and destroy all copies of this message and any attachments.
>
>