Doesn't look too complicated, uses cases 1 & 3 appear to have mixed
nets, 2 looks like the nets are either digital or analog.
The generalization of the method used in Verilog-AMS is to convert all
drivers of a net to a common level (with non-lossy conversions), resolve
at that level and then convert back to the receivers.
For case 1 I would assume aout is a voltage and therefore not a resolved
type, but you need to be able to convert the voltage to logic value for
the receiver in the RTL (that's a lossy conversion since real has finer
granularity than logic).
In case 3 it's not clear what is driving and receiving but the worst
case is that you have drivers and receivers of both types, which implies
that the real drivers are some kind of current (and real receivers are
voltage). I think the solution in that case is to convert logic drivers
to discrete currents, resolve the currents (similarly to the previously
posted capacitance/current example) which should give a voltage (for the
real receivers), and that would be converted (as case 1) for the logic
receiver(s).
If no state needs maintained in the real/logic conversions then simple
functions can be used - i.e. you could use similar syntax to the AMS
"connect module", but specify "connect functions" instead. What the
analyzer needs to do is recognize that the "real" and "logic" types need
resolved together, find a common level to convert up to for resolution,
and find conversion functions to convert back to the receivers. If you
mark conversion functions as lossy or non-lossy then a lot of it can be
determined automatically (up conversion to the resolution level should
be non-lossy, down can be lossy). Up/down conversion could be performed
by multiple conversion calls.
The tricky part (IMO) is accessing the right information to do the
logic->current and voltage->logic conversions (e.g. transistor sizing
and supply voltage).
Kev.
On 08/16/2010 07:14 AM, Little Scott-B11206 wrote:
> Hi Kevin:
>
> I mean that different types of drivers will be used in the same
> simulation/configuration run. I have attached a pdf with 3 figures that
> I hope clarify some bits of the Freescale roadmap contribution. The
> first two figures correspond to the two use cases. The final figure
> refers to the final requirement.
>
> Thanks,
> Scott
>
>
>> -----Original Message-----
>> From: Kevin Cameron [mailto:edaorg@v-ms.com]
>> Sent: Friday, August 13, 2010 6:40 PM
>> To: Little Scott-B11206
>> Cc: sv-dc@eda.org >> "sv-dc@eda.org"
>> Subject: Re: [sv-dc] Freescale SV-DC Roadmap Content
>>
>> On 08/13/2010 01:33 PM, Little Scott-B11206 wrote:
>>
>>> ...
>>>
>>> Freescale SV-DC Roadmap Content
>>> ...
>>>
>>> 1. Motivation and Use Cases [why]
>>>
>>> -There are several cases in our designs where we have mixed I/Os.
>>>
>> The same wire may be driven at times by a digital clock and at other times by an analog voltage. Modeling these I/Os as real/composite nets gives us an acceptable accuracy/performance trade-off.
>>
>>>
>>>
>> - just for clarification: do you mean different types of drivers in the
>>
>> same simulation configuration/run, or that different
>> configurations/runs will have either digital or analog for the I/O on some block?
>>
>> A goal I think might be worth adding is VHDL compatibility, i.e. types
>> and mechanisms used in VHDL can be duplicated in SV so that SV is a
>> superset of VHDL.
>>
>> Kev.
>>
>>
>
>
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Aug 16 15:52:06 2010
This archive was generated by hypermail 2.1.8 : Mon Aug 16 2010 - 15:52:08 PDT