Well, as I started moaning about this, I guess I ought to add my two cents worth: 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. PERF-02 Expressions in the sensitivity list I have a feeling I have seen this suggested before, but cannot remember where or when. The suggestion then was to add predefined attributes that return a toggling signal in a similar manner to 'TRANSACTION. The suggestions were 'EDGE, 'RISING_EDGE and 'FALLING_EDGE. Whilst these sound sensible, they would have to be defined on a type by type or packagebasis in order to actually define what change(s) constitute a particular edge. PERF-03 Define 2 & 4 state semantics As has already been said, the types required already exist. I think the answer is/are types 'BIT' and 'X01Z', just needs a resolution function for 'BIT'. PERF-04 Light-weight signals What is termed here as 'Light-weight signals' almost sounds like a request for variables. The problem of PERF-01 seems to be creeping in here, which is how is the updating process with this new signal type guaranteed to be deterministic? PERF-05 Signal Atomicity I am guessing here, but could this be linked to this scenario: type comp_rt is record sig1_l : Std_Logic; sig2_l : Std_Logic; end record comp_rt; signal rec_grp_rs : comp_rt; ... begin process a1(rec_grp_rs.sig1_l) ..... process a2(rec_grp_rs.sig2_l) In order to trigger each process independently, the selected record elements would each act as a sort of sub-signal for the sensitivity lists, rather than have the processes sensitive to the entire record signal. PERF-06 Removal of constructs indicated in VHDL-2002 I too would want to keep 'postponed' processes. The main problem is how do we check that no one is using any of the proposed constructs to be depreciated. The obvious candidates are port mode 'linkage' and guarded blocks, but how do we poll the user community? PERF-07 Zero-delay ordering of signals I am presuming that this is to do with clock edges arriving too late (in terms of deltas) with respect to data. Due to zero delay buffers in the gate level design, they can arrive after the data (from the test bench) rather than just before. It is an inconvenience, but something which can be worked around. I just add a delta delay loop on the clock in the test bench, which adds as many delta delay cycles to the clock as is required to match the delay in the design. Having said this, I haven't come across this problem for along time, but then again I don't do many zero delay gate-level simulations either. <html> <font face="new courier"> <pre> My example: --------------------------------------------------------- | | Test Bench ------------------------------------ | | | CLK | |\ |\ |\ |\ | -->------ ----->--|----| >----| >----| >----| >--- | | | |/ |/ |/ |/ | | ------- | | | | delta | | ------<-------------<----- | | delay | | | | | loop | | v | ------- | | Gate-Level Design | | | | | -v- | -v- | DATA | | | | | | -->----| |--->--|--| |------- | | | | | | | --- | --- | | Where the 'delta delay loop' code is something like: signal clk_vs : Std_Logic_Vector(MAX_jg - 1 downto 0); begin clk_vs(0) <= clk_i; for I_jlv 0 to MAX_jg - 2 loop clk_vs(I_jlv + 1) <= clk_vs(I_jlv); end loop clk_b <= clk_vs(MAX_jg); </pre> </font> </html> Cheers, Brent On 14/01/2013 09:38, Martin.J Thompson wrote: >> -----Original Message----- >> From: owner-vhdl-200x@eda.org [mailto:owner-vhdl-200x@eda.org] On >> Behalf Of Jim Lewis >> Sent: 11 January 2013 19:51 >> To: vhdl-200x@eda.org >> Subject: Re: [vhdl-200x] Performance Proposals >> >> 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. >> > [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. > > Cheers, > Martin > -- Regards, Brent Hayhoe. Aftonroy Limited Telephone: +44 (0)20-8449-1852 135 Lancaster Road, New Barnet, Mobile: +44 (0)79-6647-2574 Herts., EN4 8AJ, U.K. Email: Brent.Hayhoe@Aftonroy.com Registered Number: 1744190 England. Registered Office: 4th Floor, Imperial House, 15 Kingsway, London, WC2B 6UN, U.K. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Jan 21 13:10:21 2013
This archive was generated by hypermail 2.1.8 : Mon Jan 21 2013 - 13:10:27 PST