Re: PERF-06 Removal of constructs indicated in VHDL-200 After jumping in with both feet, I have since learnt that the port mode 'linkage' is used extensively by the IEEE Std. 1149.1 BSDL - a subset of VHDL. So we can't get rid of that one! Regards, Brent. On 21/01/2013 21:09, Brent Hayhoe wrote: > 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 Wed Jan 30 16:07:02 2013
This archive was generated by hypermail 2.1.8 : Wed Jan 30 2013 - 16:07:30 PST