Date: Wed Mar 09 2011 - 08:28:26 PST
Kudos on the proposal. It goes beyond what I was hoping for. Specifically, having resolution functions accept the present net value provides a back door for storing state on a net outside of the resolution function. That's very clever and potentially very powerful.
In some cases, a force that overrides the resolved value is perfectly fine, but there are instances in which an additional driver is needed instead. For example, one might desire to add a parasitic load or inject a noise source. Is there a mechanism for adding drivers dynamically?
Minor corrections and notes:
Change
Tsum += driver[i];
to
Tsum.field1 += driver[i].field1;
Tsum.field2 |= driver[i].field2;
The terms "vectored" and "scalared" are not described.
The phrase "with a scheduling region" should be changed to "within a scheduling region"
Kindest Regards,
Jim Lear
Cirrus Logic
(512) 851-4612
(512) 293-7248 (mobile)
From: owner-sv-dc@eda.org [mailto:owner-sv-dc@eda.org] On Behalf Of Abhi Kolpekwar
Sent: Tuesday, March 08, 2011 8:37 PM
To: sv-dc@eda.org
Cc: Gordon Vreugdenhil; Shekar Chetput
Subject: [sv-dc] A proposal on UDT and resolution functions
Hi All,
Attached is a joint proposal by Cadence and Mentor on UDTs and resolution functions. While we are in agreement in most cases, there are still some open issues that need to be cleared out in the committee.
We look forward to our discussions in tomorrow's meeting.
Thanks,
Abhi
[http://www.cadence.com/mail/footer_logocdns1.gif]
Abhi Kolpekwar | Initiatives Architect
P: 5124652260 www.cadence.com<http://www.cadence.com> abhijeet@cadence.com<mailto:abhijeet@cadence.com>
-- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
