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

One comment with regard to zero delay, or no delta cycle. This was to be a
coding shortcut, not a change in functional operation.

Looking at a proposed change within a port map to allow
    y => z and x,
Is the equivalent of a current port map having
    y => y_out,
with an assignment statement of
    y_out <= z and x;
This would be fully equivalent only if the delta cycle is present.

For those wishing to use a guard statement that is still available if it is
desired. I do not think the default behavior should be the same as the
example guard operation.

Charles B. Guy Voice (503) 628-0643
Avsys Corp. FAX (503) 628-5401
www.avsyscorp.com email cbguy@avsyscorp.com

----- Original Message -----
From: "Ries, John" <johnr@model.com>
To: <vhdl-200x-ft@eda.org>
Sent: Wednesday, September 15, 2004 9:00 AM
Subject: 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
| --
|
|
|
Received on Thu Sep 16 15:28:05 2004