Hi all, I Agree with Martin Thompson, Removal of deltas would not be a good idea, and its a simulators job to do it. Sudeep On Thu, Jan 31, 2013 at 5:36 AM, Brent Hayhoe <Brent.Hayhoe@aftonroy.com>wrote: > 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<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. > > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Jan 30 21:57:26 2013
This archive was generated by hypermail 2.1.8 : Wed Jan 30 2013 - 21:58:04 PST