VHDL switch in real numbers

Hello,

does anyone know if it would be possible to implement an "analog" (real
number) version of Ben Cohen's bidirectional switch in VHDL?

Thanks
-Jake

canadianJaouk

canadianJaouk wrote:

> Hello,
>
> does anyone know if it would be possible to implement an "analog"
> (real number) version of Ben Cohen's bidirectional switch in VHDL?

You mean http://members.aol.com/vhdlcohen/vhd...de/switch1.vhd ?
And do you mean replacing the std_logic types with reals?

That cannot be done, as the types of the A and B ports must be
resolved types. You could create your own resolved real type, but
then you should choose a particular value (or rather range) and
interpret that range as 'Z'. Rather nasty, if you ask me.

By the way: looking at the code of Ben Cohen I see that he has
included a resolution function in his code. I wonder why, because it
is not used anywhere.
--
Paul.

canadianJaouk schrieb:

> does anyone know if it would be possible to implement an "analog" (real
> number) version of Ben Cohen's bidirectional switch in VHDL?

Yes, I have done it. Maybe I can provide the source code soon - have to
ask my boss.

The idea is simple: You need a resolved data type, but real is not
resolved. Furthermore you need something to describe the driving
strength similar to std_logic.
Ok, then define a new type that is a record out of one signal std_logic
(to describe the driving strength) and one signal real (to hold the
analog value). I have called this type uanalog (unresolved analog).
Then you need a resolution function making out of uanalog a new resolved
type (called analog). Make it similar to the resolution function that is
used for std_logic.

Put the definitions of the record uanalog, the resolution function and
the derived type analog into a package, include it where ever you want
and you are done.


And if you want to use Ben Cohens transfer gate model, have a look at my
modified version
http://www.ralf-hildebrandt.de/publi...ansfergate.vhd
http://www.ralf-hildebrandt.de/publi...ansfergate.vhd
The Problem of the transfergate in VHDL is, that it "fires" only once.
My modified version fires as often as you wish.


I have used my modified transfer gate model together with the uanalog /
analog types to model a network of analog switches to test purpose. It
was a testbench for a DAC with multiple selectable inputs. Several
simulted analog switches in a chain was not a problem with the modification.


Ralf

Ralf,
You can simplify your resolution function by making it have
a wired or sense rather than a tristate sense. To contribute
a non-driving value, drive 0. Then the resolution function
can sum up all of its inputs. Alternately it could hunt for
the only non-zero input and if there are more than one non-zero
input signal an error.

Below is one for integer (tested). I also have one for time.
It would be very easy to extend to real.
Wish it were my idea, however, I got it from
Ofer Hofman of Sital - thanks again Ofer.

Cheers,
Jim


package ResolutionPkg is

type integer_array is array (natural range <>) of integer ;
function resolved ( s : integer_array ) return integer ;

subtype resolved_integer is resolved integer ;


end ResolutionPkg ;
package body ResolutionPkg is

function resolved ( s : integer_array ) return integer is
variable result : integer := 0 ;
begin
if (s'LENGTH = 1) then return s(s'LOW);
else
for i in s'RANGE loop
result := result + s(i) ;
end loop ;
end if ;
return result ;
end resolved ;


end ResolutionPkg ;



> canadianJaouk schrieb:
>
>
>>does anyone know if it would be possible to implement an "analog" (real
>>number) version of Ben Cohen's bidirectional switch in VHDL?
>
>
> Yes, I have done it. Maybe I can provide the source code soon - have to
> ask my boss.
>
> The idea is simple: You need a resolved data type, but real is not
> resolved. Furthermore you need something to describe the driving
> strength similar to std_logic.
> Ok, then define a new type that is a record out of one signal std_logic
> (to describe the driving strength) and one signal real (to hold the
> analog value). I have called this type uanalog (unresolved analog).
> Then you need a resolution function making out of uanalog a new resolved
> type (called analog). Make it similar to the resolution function that is
> used for std_logic.
>
> Put the definitions of the record uanalog, the resolution function and
> the derived type analog into a package, include it where ever you want
> and you are done.
>
>
> And if you want to use Ben Cohens transfer gate model, have a look at my
> modified version
> http://www.ralf-hildebrandt.de/publi...ansfergate.vhd
> http://www.ralf-hildebrandt.de/publi...ansfergate.vhd
> The Problem of the transfergate in VHDL is, that it "fires" only once.
> My modified version fires as often as you wish.
>
>
> I have used my modified transfer gate model together with the uanalog /
> analog types to model a network of analog switches to test purpose. It
> was a testbench for a DAC with multiple selectable inputs. Several
> simulted analog switches in a chain was not a problem with the modification.
>
>
> Ralf

Jim Lewis schrieb:

> You can simplify your resolution function by making it have
> a wired or sense rather than a tristate sense. To contribute
> a non-driving value, drive 0.

> function resolved ( s : integer_array ) return integer is
> variable result : integer := 0 ;
> begin
> if (s'LENGTH = 1) then return s(s'LOW);
> else
> for i in s'RANGE loop
> result := result + s(i) ;
> end loop ;
> end if ;
> return result ;
> end resolved ;
>
>
> end ResolutionPkg ;

Hmm ... if there are two drivers, one driving 2 and one 4 then 6 is the
result of the resolution function, if I did not make a mistake. This
suits very well for the simulation of currents at a node (2A+4A=6A), but
not for voltages. For voltages I prefer something like 'X' if one driver
drives with 2V and one 4V. That was the reason why I suggested a record
type.

Ralf

Ralf, thanks for your reply. I am running into a lot of limitations
with ben cohen's models because of the delta delay issue. I have tried
your modified version of his switch. I have strung 3 of them back to
back (a-b-c)... I drove the input of a and expected to see it at the
output of c. It sort of worked, the ouput of C was indeed the correct
value. However, the input of a and the intermediate signals between a
and b were resolved back to 'X'. So the end result was correct but the
intermediate values were not. Does that make sense? Am I using it
wrong?

Ralf Hildebrandt wrote:

> And if you want to use Ben Cohens transfer gate model, have a look at my
> modified version
> http://www.ralf-hildebrandt.de/publi...ansfergate.vhd
> http://www.ralf-hildebrandt.de/publi...ansfergate.vhd
> The Problem of the transfergate in VHDL is, that it "fires" only once.
> My modified version fires as often as you wish.

I have done that... i use negative infinity as 'Z' and positive
infinity as 'X'. It seems to work ok. I am running into issues with
delta times however. I am wondering why 'transaction is used for this?
I have made a simpler version where I simply wait for events on either
port of the switch, and fire the resolution of both ports when an event
occurs. Standard event driven process. That seems to work better and
does not create issues with delta times. I assume there is a reason
why ben cohen did it with transactions to begin with. I wonder why
that is though.


Paul Uiterlinden wrote:
> canadianJaouk wrote:
>
> > Hello,
> >
> > does anyone know if it would be possible to implement an "analog"
> > (real number) version of Ben Cohen's bidirectional switch in VHDL?
>
> You mean http://members.aol.com/vhdlcohen/vhd...de/switch1.vhd ?
> And do you mean replacing the std_logic types with reals?
>
> That cannot be done, as the types of the A and B ports must be
> resolved types. You could create your own resolved real type, but
> then you should choose a particular value (or rather range) and
> interpret that range as 'Z'. Rather nasty, if you ask me.
>
> By the way: looking at the code of Ben Cohen I see that he has
> included a resolution function in his code. I wonder why, because it
> is not used anywhere.
> --
> Paul.

canadianJaouk schrieb:

> I have tried
> your modified version of his switch. I have strung 3 of them back to
> back (a-b-c)... I drove the input of a and expected to see it at the
> output of c. It sort of worked, the ouput of C was indeed the correct
> value. However, the input of a and the intermediate signals between a
> and b were resolved back to 'X'. So the end result was correct but the
> intermediate values were not. Does that make sense? Am I using it
> wrong?

I will check this as soon if can spend some time at work with the
simulator. But I can't remember, that I observed such behavior.

Did you try my testbench:
<http://www.ralf-hildebrandt.de/publication/transfergate/tbench_transfergate.vhd>?
All signals have been initialized in this testbench with 'Z'. Maybe
that's the difference.


Ralf

You were right, when i initialized all signals to 'Z', it worked fine.
I also made it work with my resolved real type. Thanks

Ralf Hildebrandt wrote:
> canadianJaouk schrieb:
>
> > I have tried
> > your modified version of his switch. I have strung 3 of them back to
> > back (a-b-c)... I drove the input of a and expected to see it at the
> > output of c. It sort of worked, the ouput of C was indeed the correct
> > value. However, the input of a and the intermediate signals between a
> > and b were resolved back to 'X'. So the end result was correct but the
> > intermediate values were not. Does that make sense? Am I using it
> > wrong?
>
> I will check this as soon if can spend some time at work with the
> simulator. But I can't remember, that I observed such behavior.
>
> Did you try my testbench:
> <http://www.ralf-hildebrandt.de/publication/transfergate/tbench_transfergate.vhd>?
> All signals have been initialized in this testbench with 'Z'. Maybe
> that's the difference.
>
>
> Ralf

canadianJaouk wrote:

> I have done that... i use negative infinity as 'Z' and positive
> infinity as 'X'. It seems to work ok. I am running into issues
> with
> delta times however. I am wondering why 'transaction is used for
> this?
> I have made a simpler version where I simply wait for events on
> either
> port of the switch, and fire the resolution of both ports when an
> event
> occurs. Standard event driven process. That seems to work better
> and
> does not create issues with delta times. I assume there is a reason
> why ben cohen did it with transactions to begin with. I wonder why
> that is though.

So do I. The more I look at the code, the more my brain hurts. Clearly
a sign I should load the code in a simulator and play with it.
Perhaps I will do that, on a rainy Sunday afternoon.

I see how it works, but I'm not sure why the "until ThenTime_v /= now"
should work. Clearly, it is to prevent reacting on the process's own
assignment.

> Paul Uiterlinden wrote:
>> By the way: looking at the code of Ben Cohen I see that he has
>> included a resolution function in his code. I wonder why, because
>> it is not used anywhere.

Duh, I don't know what made me say that. The function *is* used, only
not as a real resolution function to create a resolved type.

--
Paul.
www.aimcom.nl
email address: switch x and s