Re: [vhdl-200x] Expression signal assertion

On 14 Feb 2013, at 10:38 AM, Jerry Kaczynski wrote:

> Brent,
> 
> Right now 6.5.6.3 explicitly forbids the use of 'inertial' in actuals associated with anything but ports in port maps.
> In addition, 4.2.2.1 says that actual associated with formal parameter of signal class must be a signal name.
> If we carry the trick of "creating anonymous intermediate signal for expression association" from port to signal parameters, it should be relatively easy to implement.
> It would be nice to hear from tool vendors if they are aware of any hidden issues of adding this feature.
> 
> Jerry 
> 
> 
> On Wed, Feb 13, 2013 at 12:55 PM, Brent Hayhoe <Brent.Hayhoe@aftonroy.com> wrote:
> Thanks for that Jerry,
> 
> Yet another 2008 enhancement that passed me by!
> 
> Now, as far as I understand it, this applies only to port clauses of entities and block port maps.
> 
> Do you think that we would be able to extend this to parameter clauses of procedures with signal ports?

Not a tool vendor, but -

You have no need of an implicitly declared signal in a sequential procedure call statement.  

Instead of a  concurrent procedure call you could use a block statement with a port clause and port map aspect enclosing an equivalent process to the procedure call.  

You don't declare signals (implicitly or otherwise) in a procedure declaration or equivalent process statement while signals can be declared in blocks (or things with equivalent block statements).  (14.5 Elaboration of a statement part, 14.5.5 Other concurrent statements, "All other concurrent statements are either process statements or are are statements for which there is an equivalent process statement." Not a block statement (14.5.2), a generate statement (14.5.3) or a component instantiation statement(14.5.4).)

From Jerry's quote 6.5.6.3 paragraph 15:

If the actual part of a given association element for a formal port of a block is the reserved word inertial followed by an expression, or is an expression that is not globally static, then the given association element is equivalent to association of the port with an anonymous signal implicitly declared in the declarative region that immediately encloses the block. The signal has the same subtype as the formal port and is the target of an implicit concurrent signal assignment statement of the form

anonymous <= E;

where E is the expression in the actual part of the given association element. The concurrent signal assignment statement occurs in the same statement part as the block.

 --

I'd contend that the enclosing declarative region is the block declarative part (11.2), the region that immediately encloses the block and the statement part for the concurrent implicit signal assignment is in the block statement part. Thus the implicit signal is said to have been declared in the declarative region immediately enclosing the block when it is in the block declarative part and the concurrent assignment occurs in the block statement (after begin, before end).

You don't have access to that in a procedure which maps to to a process, where signal declarations aren't allowed in the process declarative part (11.3) and process statement part statements are sequential.

You'd violate scope and visibility appending the implicit declaration in the wider enclosing region's declarative region.

You'd essentially be editing that enclosing (block) declarative part after the fact as well as adding a concurrent signal assignment into the enclosing region.  You'd also be editing the enclosing block statement part to include a new concurrent signal assignment.

The message here is no implicit signal declarations in things that have equivalent process statements and whose statement parts are sequential statements.






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