Removal of Deltas

Recommendation: Reject

Proposal Information

• Who Updates:
• Date Last Updated
• Priority:
• Complexity:
• Focus: Performance

Requirement Summary & Rationale

Currently VHDL requires that all signal values be updated before any processes are executed. While this allows for a deterministic simulation it can impact simulation performance.

Arguments For

Add your signature here to indicate your support for the proposal

Arguments Against

Add your signature here to indicate your do not support for the proposal

From Jan 31, 2013 meeting

• Lots of concern about delta cycles
• Not necessarily much performance gain
• Recommend reject

General Comments

Email Reflector Comments

• Original VHDL-200X Simulation Performance Reflector Archive

From: Peter Flake (Thu Jan 03 2013 - 09:48:21 PST)

Perf 1: Removal of simulation deltas

If this means removal of simulation deltas from existing code, I would be against it on the grounds that it could change the simulation results. If this means a new kind of process to execute during the update phase, I would support a copy only to an unresolved signal. This would allow an ungated clock tree to have no delta cycles. If a general expression is allowed, multiple changes can cause multiple executions yielding different results.

From: Joanne Degroat (Thu Jan 03 2013 - 11:38:20 PST)

I will comment on Perf 1: Removal of simulation deltas

I would be against this as the deltas allow the signal waveform to deterministically propagate through multiple stages of logic.

If they were removed some mechanism needs to be incorporated to insure determinism.

Determinism is the feature that sets VHDL apart from Verilog.

From: Jim Lewis (Fri Jan 11 2013 - 11:51:11 PST)

I wanted to comment on Perf 1: Removal of simulation deltas

If you take this as remove the delta cycles and try to run the code, then it would likely be a disaster.

OTOH, if you take this as, let a compiler that understands how the language and delta cycles are intended to work, optimize away delta cycles where it is possible and it makes sense, then perhaps we have something that is useful.

In my testbenches I do things that handshake on delta cycle basis and depends on a specific ordering to be respected. However, if a compiler were able to determine this and do appropriate optimizations I would be ok with it.

From: Martin.J Thompson (Mon Jan 14 2013 - 01:38:43 PST)

> I wanted to comment on Perf 1: Removal of simulation deltas
>
> If you take this as remove the delta cycles and try to run the code,
> then it would likely be a disaster.
>
[MJT] Seconded (or thirded or fourthed!)

> OTOH, if you take this as, let a compiler that understands how the
> language and delta cycles are intended to work, optimize away delta
> cycles where it is possible and it makes sense, then perhaps we have
> something that is useful.
>
[MJT] Is this precluded with the present language spec? The language is specified to work in the way it does - if the compiler/simulator combination is clever enough to optimise away things whilst keeping the behaviour the same, who is to know? It's still a compliant toolchain. For all I know, some of them may do this already!

Any change to the way delta-cycles work would be a retrograde step IMHO - for reasons others have already noted.

From: Brent Hayhoe (Mon Jan 21 2013 - 13:09:26 PST)

PERF-01 Removal of simulation deltas

Quoting:

"While this (deltas) allows for a deterministic simulation it can impact simulation performance."

I am in agreement with others, all I can say is; determinism is what it's all about; and simulation performance is improved by clever simulator design.

From: Sudeep Kumar (Wed Jan 30 2013 - 21:56:54 PST)

I Agree with Martin Thompson,

Removal of deltas would not be a good idea, and its a simulators job to do it.

From: Kevin Cameron (Mon July 15 2013)

This is really the same as a request for blocking-assignments as in Verilog. As such it makes sense to support it on interoperability grounds if nothing else.

The behavior is equally (non)deterministic with blocking and non-blocking, just different.

It's hard to optimize around a defined behavior that involves time delays, so the simulator/compiler can't really do much with this.