RE: EXTERNAL: Re: [vhdl-200x] Switch model

From: Jones, Andy D <andy.d.jones@lmco.com>
Date: Mon Mar 17 2014 - 16:11:17 PDT
I've played around with trying to deduce the 'others value from the resolved value and my driven value, with limited success. If any driver ever drives U|X|-, the switch is pretty much toast, and cannot recover. 

I think a 'others attribute nicely handles it, and since no deduction logic (which can be thwarted/confused) is required, it will not suffer the same consequences.

So far, we've the 'others attribute for a signal with only one local driver. 

Defining it for signals with multiple local drivers would need some work (i.e. which driver(s) are NOT included in 'others). We could either disallow that, or allow it and just remove all local drivers from 'others. We might have to define "local drivers" too.

Would 'others create an implicit new signal? 

Would S'others'event only be true if an event occurred on the other driver(s), excluding self?

Other related effects?

Andy D Jones
Electrical Engineering
Lockheed Martin Missiles and Fire Control
Dallas TX



-----Original Message-----
From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of Jim Lewis
Sent: Sunday, March 16, 2014 6:20 PM
To: vhdl-200x@eda.org
Subject: EXTERNAL: Re: [vhdl-200x] Switch model

Hi Kevin,
I think you forgot to put your switch model into a process (since your 'others seems to require it).  I put an updated process in the proposal.  I also used if rather than the assignment form as it makes it more clear that it is a switch you want rather than a transceiver:

process(a, b, ctrl)
begin
   if ctrl then
a <= b'others ;
     b <= a'others ;
   else
     a <= 'Z' ;
     b <= 'Z' ;
   end if;
end process ;

vs a transceiver.
process(a, b, ctrl)
begin
   if ctrl then
a <= b'others ;
     b <= 'Z' ;
   else
     a <= 'Z' ;
     b <= a'others ;
   end if;
end process ;

I only point this out as when I read your model that uses the conditional assignment initially, my mind automatically assumed that you were doing a transceiver and I wondered why you even needed the 'others.

If we only implemented a 'others attribute, what would we not be able to support?

Jim

> There's some discussion on bidirectional components and switches here 
> -
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/BidirectionalConnections
>
> - I just added an example for a simple pass-through switch. A strength-reducing switch isn't much more complicated.
>
> If you do mixed signal stuff properly and support switch-branches for 
> analog as in verilog-AMS a switch is fairly simple -
>
>      branch b(x,y);
>
>      analog
>
>          if (<condition>) V(b) <+ 0.0; // closed
>
>                     else  I(b) <+ 0.0; // open
>
> A smart compiler can probably make that work in discrete simulation too.
>
> Unfortunately VHDL's use of hierarchical resolution and port-bound 
> conversions makes it all difficult. Which is why I also added the 
> requirement for supporting flat resolution -
>
> http://www.eda-twiki.org/cgi-bin/view.cgi/P1076/MixedSignalSupport
>
> Kev.
>
>
> On 03/11/2014 06:29 AM, Jennings, Kevin wrote:
>> One simple solution to the problem mentioned below with differential transceivers and analogue switches is to simply add the appropriate time delays.  In the situation described below, the 'troubling to model' parts both presumably have datasheets and most likely do not specify a 0 ns propagation delay.  Simply modeling the part with the manufacturer's specified prop delays will avoid having multiple delta cycles be part of the problem.  One could argue (for this case), that adding the delay more properly models the part than 0 ns delay.
>>
>> I realize that a general solution may be handy as well, but in order to justify the language change one should probably come up with scenarios that don't already have a solution and then see how much support there is for that class of scenarios.
>>
>> Kevin Jennings, P.E
>>
>> -----Original Message-----
>> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On 
>> Behalf Of Brent Hayhoe
>> Sent: Monday, March 10, 2014 8:15 PM
>> To: vhdl-200x@eda.org
>> Subject: Re: [vhdl-200x] Switch model
>>
>> As I've (re-)started this thread I will generate a proposal for it.
>>
>> However I think we should leave the discussion on the reflector for 
>> now until we can sort out these delta cycle propagation problems, 
>> especially the problem of two switches in a row.
>>
>> I will have a play with my current test bench and see what happens.
>>
>> I can second Rick on this problem as I have had many issues in trying 
>> to support this bidirectional assignment problem in many test bench scenarios before.
>>
>> My current task involves targeting a commercial development board 
>> which has differential transceivers (separate from the FPGA) and 
>> 'bypass-able' using analogue switches. Hence my need to get a 
>> solution (which I have at present) for my application test bench, but 
>> also wanting to generate properly supported VHDL functionality for this.
>>
>> The main task as Jim says is quantifying the problem, but also 
>> identifying a simulate-able solution for the problem(s).
>>
>> Cheers,
>>
>> Brent.
>>
>> On 10/03/2014 20:36, Jim Lewis wrote:
>>> Hi Rick,
>>> Would have been happy to support your detailed proposal for this for 
>>> VHDL-2008.  However, while people asked for the feature, no one 
>>> liked it so much that they were willing to volunteer to write it up and make it happen.
>>>
>>> I suspect the rest of the working group would have supported this 
>>> work also if someone who really needed it would have written the proposal.
>>>
>>> I would be happy to support it now too.  We need to quantify exactly 
>>> what we need.
>>>
>>> I understand connections of the form:
>>> A <=> B ;
>>> A <=> B when S = '1' ;
>>>
>>> However, VHDL-2008 had requests for something of the form without any circuit
>>> for it.   I have never had a need for this, so this meant to me that I did not
>>> understand what was wanted enough to successfully complete a proposal.
>>> A <=> B when S = '1' else C ;
>>>
>>> Can anyone provide a compelling reason (circuit not words) to implement this?
>>>
>>> We need a proposal documenting all forms needed and the compelling 
>>> reason (circuits not words) to implement it.
>>>
>>> Jim
>>>
>>>> Jim,
>>>>
>>>> Pull up the datasheet for a TI SN74CBT3125D.  I have been asking 
>>>> for this since the late 1990s.
>>>>
>>>> Rick
>>>>
>>>>
>>>>
>>>> On 03/10/2014 07:41 PM, Jim Lewis wrote:
>>>>> HI Jakko,
>>>>> I would particularly be interested in seeing an example and 
>>>>> hardware picture of something that requires conditional usage of this.
>>>>>
>>>>> I would more likely call it a switch or attachment operation. 
>>>>> Calling it an assignment is going to make people want to inject 
>>>>> delta cycles - which is not going to work.
>>>>>
>>>>> Jim
>>>>>
>>>>>
>>>>>
>>>>>> Hi Brent,
>>>>>>
>>>>>>
>>>>>> What you actually want is a bidirectional assignment (for any 
>>>>>> resolved type).
>>>>>>
>>>>>> The problem with the code you listed below, is that you cannot 
>>>>>> have 2 of those assignments in a row, it will lead to wrong results.
>>>>>>
>>>>>> If you could assign 2 ways (like tran or tranif), then the 
>>>>>> problem is solved.
>>>>>>
>>>>>> I'd like to see something like
>>>>>>
>>>>>> a <=> b [when c else 'Z'];
>>>>>>
>>>>>> This would ease multiport wires with bidirectional (and 
>>>>>> conditional) assignments.
>>>>>>
>>>>>> Jakko
>


--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
VHDL Training Expert, SynthWorks
IEEE 1076 VHDL Working Group Chair
Open Source VHDL Verification Methodology (OSVVM), Chief Architect and Co-founder

1-503-320-0782
Jim@SynthWorks.com
http://www.SynthWorks.com

VHDL Training on leading-edge, best coding practices for hardware design and verification.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


--
This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Mar 17 16:11:30 2014

This archive was generated by hypermail 2.1.8 : Mon Mar 17 2014 - 16:13:49 PDT