External Non-Shared Variable Name

Proposal Editing Information

• Who Updates: Brent Hayhoe
• Date Proposed: 2014-08-11
• Date Last Updated:
• Priority:
• Complexity:
• Focus:

Requirement Summary

The ability to access standard variables via the 'external' format method.

Related Issues:

External names for types.

Proposal

Current Situation

For external variable names, currently we can only reference shared variables as a variable reference.

When using external names for grey box access in a verification environment, the one thing that is still inaccessible are memory arrays coded as standard variables.

Currently, I am involved in generating a verification environment for a safety critical design some 10 years old. Altering source code is absolutely verbotten and this means access to all embedded variables within the design is impossible.

Similarly, without the associated proposal - External names for types - access to signals of enumerated types in the design is not possible.

Implementation details

There are two possibilities:

1. add standard variables with the proviso that the user is responsible for controlling mutual accesses in the same way as shared variables had to be used pre VHDL 2002?

or:

2. we add a read-only mode to the external access, this could be done implicitly.

Code Examples

For current shared variable:

  architecture rtl of dut_entity is
     shared variable dut_variable : dut_protected_type;
  begin
     ---
  end architecture rtl;

and current external access:

  my_process : process(...) is
  begin
     test_variable := <<variable .testbench.dut_top.dut_entity.dut_variable : dut_protected_type>>.get;
  end process my_process ;

For process variables:

  dut_process : process(...) is
     variable dut_variable : old_type;
  begin
     ---
  end process dut_process ;

and new external access:

  my_process : process(...) is
  begin
     test_variable := <<variable .testbench.dut_top.dut_entity.dut_process.dut_variable : dut_type>>;
  end process my_process ;

The use would be identical for old shared variables, except the path would not require the final process path-element.

I thought we might come into problems handling the old versions (pre-92) syntax of shared variables, but since all (that I know of) compilers (simulators & synthesisers) handle this on a file basis, they should be able to handle the syntax differences seamlessly.

Use Cases

Arguments FOR

This gives full access for grey box verification probing of designs under test.

Arguments AGAINST

Email Reflector Comments

From: Srinivasan Venkataramanan (Thu Jun 05 2014 - 17:44:40 PDT)

From Verification (specifically Assertion Based Verif), this would even become a "requirement", so I support this enhancement.

From: Jim Lewis (Fri Jun 06 2014 - 10:53:09 PDT)

Hi Brent, > For external variable names, we can only reference shared variables.
>
> Apart from the issues of mutual exclusion for accesses, does anyone know of any other reasons why we shouldn't allow references to standard variables within processes?
>
> When using external names for grey box access in a verification environment, the one thing that is still inaccessible are memory arrays coded as standard variables.
>
> Can we add this in as a requirement with the proviso that the user is responsible for controlling mutual accesses in the same way as shared variables had to be used pre VHDL2002?
Perhaps this is a reason to code your memory arrays as a shared variable. Do you have other things that you would like to access.

One of the next release candidates for some of the open source work I am doing (OSVVM.org), is our protected type based package for memory models.

From: Andy D Jones (Fri Jun 06 2014 - 16:43:01 PDT)

While shared variables may be a good idea for memory simulation models, shared variables of protected types are not synthesizable (yet). Arrays used to infer FPGA memory in RTL can either be local variables (not externally accessible for verification), signals (externally accessible, but too much simulation overhead), or old-style, non-compliant shared variables (the reason why most simulators only issue a warning if shared variables are of non-protected types.

If most simulators support non-PT shared variables, and their customers are happy to take the responsibility for mutual access, why shouldn't local variables be externally accessible per the standard?

Count me as one in favor of restoring non-PT shared variables too, for the same reason as above. Inferred, two-clock FIFOs are a good reason to use them in synthesizable RTL. Simultaneous access to the same array location by two processes has to be avoided for reliable HW anyway, so engineers are used to handling that, and protected types would not help anyway.

I love protected types in VHDL, but sometimes they are overkill, and the application does not need that level of protection.

From: Jim Lewis (Fri Jun 06 2014 - 21:13:33 PDT)

On 6/6/2014 4:43 PM, Jones, Andy D wrote: > If most simulators support non-PT shared variables, and their customers are happy to take the responsibility for mutual access, why shouldn't local variables be externally accessible per the standard?
>
> Count me as one in favor of restoring non-PT shared variables too, for the same reason as above. Inferred, two-clock FIFOs are a good reason to use them in synthesizable RTL. Simultaneous access to the same array location by two processes has to be avoided for reliable HW anyway, so engineers are used to handling that, and protected types would not help anyway.
My pragmatic side concurs with this too.

OTOH, I am not sure how I feel about accessing regular variables that were not originally designated as shared variables. However, if someone works out the details I will not stand in the way of this - provided it does not result in restrictions on shared variables of protected types. Shared variables with protected types need to evolve in some too (arrays, ports, ...).

General Comments

-- JimLewis - 2014-07-21

If you were to propose supporting shared variables of a regular type, then this would be perhaps a natural extension to that. This basically what you are implying by allowing access to a variable from a separate thread.

<Brent Hayhoe> - And this is what I have stated. The question is do we qualify it by making local process variables and old-style shared variables read-only. It would probably be adequate for most verification requirements, but there may be other applications that require a write mode.

However, if we decide to implement read-only, then I think we should we should still allow a write mode via the 'force' command. It's another valid tool for directed testing in order to capture obscure and difficult to reach code coverage metrics.

</Brent Hayhoe> - 2014-08-28

-- ErnstChristen - 2015-01-27 - What should be the execution semantics of assigning a value to a process variable from outside the sequential code? I doubt that a process should resume in response to this to propagate the value change. Just depositing the value may break assumptions the model writer has made about the value of the variable from the sequential code. In other words, it can cause hard to trace problems. This includes "force". We are left with read-only access or another class of variables specifically to model memories, but haven't we been there already?

-- TristanGingold - 2015-01-30 - Even read-only access is not safe. Two processes can execute concurrently.

Current Status

This proposal was discussed in the 2016 March 24th meeting under item 58 of the ranked proposals spreadsheet for VHDL201x.

It was stated that this proposal may be impossible to implement.

Supporters

-- Brent Hayhoe - 2014-08-11

Add your signature here to indicate your support for the proposal