Re: [vhdl-200x] Performance Proposals

From: Jim Lewis <Jim@synthworks.com>
Date: Fri Jan 11 2013 - 11:51:11 PST
Hi All,
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.

Best,
Jim

> 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.
>
> On Perf 3:  Define 2 and 4 state semantics
>
> The language allows for development of any state systems needed for the task
> at hand through overloading.
> I recently had the need to develop a logic system with probabilistic fault
> injection, i.e., a logic function randomly generates the wrong result.
> This can be done.   If the logic system developed has merit it can be
> incorporated as a package in the standard.
>
> Regards,
> Joanne
>
> -----Original Message-----
> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On Behalf Of
> Peter Flake
> Sent: Thursday, January 03, 2013 12:48 PM
> To: vhdl-200x@eda.org
> Subject: [vhdl-200x] Performance Proposals
>
> Hi,
>
> While we are waiting for more details on Perf 1 to 7, I would like to make
> some comments on them:
>
> 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.
>
> Perf 2: Expressions in the sensitivity list
>
> The question here is: when is the expression evaluated? If it is evaluated
> at the update phase, then some of the signals may not yet have been updated.
> If it is at the evaluation phase, then it is just like running a process.
> The only worthwhile case is a posedge or negedge on a scalar signal, which
> can be correctly evaluated at the update phase.
>
> Perf 3: Define 2 and 4 state semantics
>
> Since the language allows 2 state and 4 state signals to be defined, it
> seems unnecessary to change the language.  Of course a tool can attempt to
> optimise std_logic into fewer states, at the risk of getting the wrong
> results!
>
> Perf 4: Light-weight signals
>
> Signals without resolution functions can only have a single driver.  I do
> not understand the proposal.
>
> Perf 5: Signal atomicity
>
> I do not understand the effect of this enhancement, and its purpose.
>
> Perf 6: Removal of constructs indicated in VHDL 2002
>
> I would want to keep postponed processes.
>
> Perf 7: Zero-delay ordering of signals
>
> It is unclear what algorithm is required here.  It must cope with multiple
> clock domains and asynchronous circuits.
>
> Regards,
>
> Peter Flake
>
>
> --
> This message has been scanned for viruses and dangerous content by
> MailScanner, and is believed to be clean.
>
>
>


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri Jan 11 11:51:42 2013

This archive was generated by hypermail 2.1.8 : Fri Jan 11 2013 - 11:55:00 PST