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