Subject: [vhdl-200x-mp] Re: Bi -directional modeling support
From: Jim Lewis (Jim@SynthWorks.com)
Date: Mon Jul 07 2003 - 06:11:04 PDT
Kevin,
Sorry I have been working vhdl-200x-ft stuff.
Need to finish that first. It has a critical deadlines
there.
On May 30th, I enumerated the list of proposals.
You said that this is Rick's request, however,
the original request came from Stephen's list
(perhaps there it was an old ISAC request that people
remember that came from Rick, I am not sure).
Note right now, nothing is in the proposal part.
I have a proposed solution also and it is not there
either. My current plan is to document my proposed
solution.
My thought is that any proposed solution for this
(and we can consider more than one) must be something
intuitive to a casual user. I don't think a user should
be thinking about simulator algorithms for connectivity.
I think the simulator must think about how to do these
but not the user.
Please complete your proposal by showing some code and
showing how to model a bidirectional switch with it
(and resistors).
Cheers,
Jim
Kevin Cameron wrote:
> I notice that Rick's requirement for modeling bi-directionional
> components got onto the proposals web page but my proposed solution
> (copied again below) is not there yet.
>
> Can you add it please.
>
> Kev.
>
>
>
>>From dkc Sat Jun 7 13:54:45 2003
>>To: Jim@synthworks.com
>>Subject: Re: Bi -directional modeling support
>>
>>Here's the proposal for supporting bi-directional modelling again (the
>>previous version got mangled by Netscape).
>>
>>Regards,
>>Kev.
>>
>>----- Begin Included Message -----
>>
>>A requirement for bi-directional modeling is that a process should be able to interogate
>>all the drivers of a signal so that it can determine what to pass through. It's similar to driver
>>resolution, but you want to skip over the driver for the calling process. E.g. if you want to model
>>a resistor, the modeling process would look at all the drivers on one end (excluding its own) and
>>drive a strengh-reduced value onto the signal at the other end, and the same in the opposite
>>direction, the signal on either end is then resolved including the driver from the resistor model.
>>
>>The proposal is written assuming that the implementation probably has the drivers in an
>>array-like structure already for handling resolution.
>>
>>Signal resolution really needs to be done "flat" rather than hierarchically, but I can't find
>>the specific text in the LRM that says it's done either way.
>>
>>Regards,
>>Kev.
>>
>>------------------------------------------------------------------------
>>
>>IEEE 200X Modeling and Productivity Change Proposal
>>
>>ID: MP-
>>
>>Proposer: Kevin Cameron
>>email: dkc(at)grfx.com
>>
>>Status: Open
>>Proposed: Date
>>Analyzed: Date
>>Resolved: Date
>>
>>Enhancement Summary: Implicit signals to enable bi-directional modeling
>>Related issues:
>>Relevant LRM section: Predefined Attributes
>>
>>Enhancement Detail:
>>----------------------------
>>
>>Additional/modified predefined attributes for signals -
>>
>> S'DRIVERS
>> Kind: Function
>> Prefix: Any signal denoted by the static signal name S.
>> Result Type: universal_integer
>> Result: The number of driving processes the signal S has.
>>
>> S'DRIVER_INDEX
>> Kind: Function
>> Prefix: Any signal denoted by the static signal name S.
>> Result Type: universal_integer
>> Result: The process index for the calling context for use with S'DRIVING_VALUE and
>> S'DRIVING. S'DRIVING is equivalent to S'DRIVING(S'DRIVER_INDEX)
>> and S'DRIVING_VALUE is equivalent to S'DRIVING_VALUE(S'DRIVER_INDEX).
>>
>> S'DRIVING[(N)]
>> Kind: Function
>> Prefix: Any signal denoted by the static signal name S.
>> Paramater: universal_integer, a value between 1 and S'DRIVERS.
>> If omitted it defaults to S'DRIVER_INDEX.
>> Result Type: Boolean
>> Result: If the prefix denotes a scalar signal, the result is False if the current value of the
>> driver for S in the process whose index is N is determined by the null transaction;
>> True otherwise. If the prefix denotes a composite signal the result is True if and
>> only if R'DRIVING is True for every Scalar subelement R of S; False otherwise.
>> If the prefix denotes a null slice of a signal the result is True.
>> Restrictions: ... as is ...
>>
>> S'DRIVING_VALUE[(N)]
>> Kind: Function
>> Prefix: Any signal denoted by the static signal name S.
>> Paramater: universal_integer, a value between 1 and S'DRIVERS.
>> If omitted it defaults to S'DRIVER_INDEX.
>> Result Type: The base type of S
>> Result: If S is a scalar signal S, the result is the current value of the driver for S in the
>> process whose index is N. If S is a composite signal, the result is the aggregate of
>> the values of R'DRIVING_VALUE for each element R of S for drivers belonging to
>> the process whose index is N. If S is a null slice, the result is a null slice.
>> Restrictions: ... as is ...
>>
>>
>>Analysis:
>>----------------------------
>>[To be performed by the 200X Modeling & Productivity Working Group]
>>
>>
>>Resolution:
>>----------------------------
>>[To be performed by the 200X Modeling & Productivity Working Group]
>>
>>
>>----- End Included Message -----
>>
>
>
>
>
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This archive was generated by hypermail 2b28 : Mon Jul 07 2003 - 06:11:49 PDT