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.Received on Thu Jan 3 09:48:50 2013
This archive was generated by hypermail 2.1.8 : Thu Jan 03 2013 - 09:48:58 PST