Re: [vhdl-200x-ft] Comments on FT11

I agree with John here, and have an additional concern.

I like to look at type conversions in port maps as a mechanism
to convert between two "views" of a signal. For example, the
actual may be represented as an integer and the formal port
may be an std_logic_vector. These are part of the same hardware
wire and should change simultaneously. I am not aware of any
real VHDL designs in which type conversions on ports have been
used for any other purpose.

On the other hand, an expression associated with an IN port
is just a short form for representing actual logic - something
that represents real hardware. I believe there should always be
a delta cycle for this evaluation. Otherwise, as John mentioned,
we can get inconsistent behavior for two descriptions of a design
that should ideally mean the same thing.

-ajay

------------- Begin Forwarded Message -------------

To: vhdl-200x-ft@eda.org
Subject: Re: [vhdl-200x-ft] Comments on FT11
Date: Wed, 15 Sep 2004 09:00:43 -0700
X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on
server
X-Virus-Scanned: clamd / ClamAV version 0.74, clamav-milter version 0.74a on
server
X-Virus-Status: Clean
X-Virus-Status: Clean

I have two "issue" with not having a delta.

One is that the behavior of the circuit change when you move
a concurrent signal assignment expression into a port map.

For example

clk2 <= not clk;
u1: entity work.flip_flop( ..., clk2, ...)

and

u1: entity work.flip_flop( ..., not clk2, ...)

can behave differently when there is a delta delay race condition going on.

Secondly issues to performance related. The lack of delta strongly implies
that all signals evaluation needed to be ordered. For example

u1: entity work.something port map ( a, not a);

entity something is port map( x, y : in std_logic); end;

architecture behave of something is
begin
   u2: entity work.someother port map( x, y, y and x);

end;

The expression ( z and x ) needs to be evaluate after a, and NOT a have
been evaluated. Assume a is 0, when a changes to a 1, if (y AND x) is evaluated
before NOT a is evaluated,then the value of (y AND x) is 1, then when NOT a is
compute the value of ( y AND x) changes back to 0. The simulator would have
to suppress this "glitch". Ordering of the expressions "fixes" the problem
at the cost of more complex signal evaluation/ordering. Also if we allow
hierarchical references the signal ordering becomes even more complex and
may result in true zero delay loops.

Regards,
   John

Peter Ashenden wrote:
> Folks,
>
> Jim asked me to think about FT11, association of expressions involving
> signals with in-mode ports. I'd like to fly an idea past committee
> members...
>
> The desire in FT11 is to do something like:
>
> signal A, B : bit;
> ...
>
> UUT1 : UUT
> port map ( X => A and B, ... ); -- where X is an in-mode port
>
> In our previous discussions on this, we considered expressing the semantics
> in terms of an equivalent concurrent signl assignment to an anonymous
> signal
> that is then associated with the port. This would introduce a delta delay,
> which we decided to tolerate.
>
> However, this introduces some anomalies, such as one mentioned in the FT11
> proposal:
>
> UUT2 : UUT
> port map ( X => "not"(A), ... );
>
> In this case, there is no delta delay, since the actual part is a
> conversion
> function. Whereas:
>
> UUT3 : UUT
> port map ( X => not A, ... );
>
> Here, there would be a delta cycle, since the actual part is an expression.
>
> It occurs to me that the effect we really want is more akin to update of
> guard signals. Consider the following model:
>
> B1: block ( A and B ) is
> begin
> UUT4 : UUT
> port map ( X => GUARD, ... );
> end block B1;
>
> Here, when either of A or B is active, the GUARD signal is updated, causing
> the effective value of the formal port X to be updated. This all occurs in
> the same simulation cycle in which A or B is active. We avoid the anomaly
> shown above.
>
> We could define the semantics of associating an expression with an in-mode
> port in terms of update of the effective value of the port. We would say
> that an in-mode port that is associated with an expression is active if any
> signal in the expression is active. This would be a simple extension of
> the
> existing rule that says such a port is active if the associated signal is
> active.
>
> Furthermore, we may be able to subsume the semantics of type conversions
> and
> conversion functions in actual parts into associating expressions as
> actuals, since both type conversions and conversion functions are specific
> cases of expressions.
>
> What do folks think? Is this worth persuing, or is there something obvous
> I've overlooked?
>
> Cheers,
>
> PA
>
> --
> Dr. Peter J. Ashenden peter@ashenden.com.au
> Ashenden Designs Pty. Ltd. www.ashenden.com.au
> PO Box 640 Ph: +61 8 8339 7532
> Stirling, SA 5152 Fax: +61 8 8339 2616
> Australia Mobile: +61 414 70 9106
>

-- 
-- mailto: johnr@model.com     phone: (503)685-0864
--   http://www.model.com        fax: (503)685-0921
--
------------- End Forwarded Message -------------