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

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
--