Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!swrinde!ucsd!telesoft!rlk From: rlk@telesoft.com (Bob Kitzberger @sation) Newsgroups: comp.realtime Subject: Re: Measuring timing of Realtime Systems Summary: It would be nice if... Message-ID: <1037@telesoft.com> Date: 30 Aug 90 02:22:51 GMT References: <9724@tekigm2.MEN.TEK.COM> <15630007@hp-lsd.COS.HP.COM> Organization: TeleSoft, San Diego, CA. Lines: 89 In article <15630007@hp-lsd.COS.HP.COM>, dave@hp-lsd.COS.HP.COM (David C. Mueller) writes: > > However, you should look to your emulator (assuming one is available). > In addition to making the normal state analysis measurements, some emulators > (read HP's emulators) have a class of measurements called "Software > Performance Measurements". The type of measurement you're making is > included in that class. > > Statistics on the latency you're measuring can be given as > well so that you can get a feel for the max/min latency as well as the > average and distribution of particular latency measurements. This is a nice feature, but as you say, it IS statistical, i.e. sampled. Unless things have changed in the past few months, HP's performance measurement feature sampled the instruction/address stream, filling the trace buffer. Once the trace buffer was full, the input stream is ignored and the samples are merged with the rest of the statistical sample. Hence, potentially critical information may be lost. If this is wrong, I'm sure someone at HP will correct me (and please accept apologies in advance). What would be a GREAT feature for timing analysis would be to add the ability to trigger on TIME DELTAS in addition to address/data bus values, etc. For example, define event A and event B. Then, set the analyzer to trigger whenever B occurs > 200 usecs after A. _That_ would be immensely usefull in determining when timing constraints are missed. HP, cabn this be done? Please? Back to the original request... hardened real-time developers tend to develop a toolbox full of timing techniques, each applicable to differing situations. Here's a couple of mine, though I'm not hardened too much yet ;-) Ordering is from high-budget to low-budget. 1. Logic analyzer / emulator monitoring events (as others have attested to) + allows max/min measurements (for a given analyzer buffer size) + very flexible in defining events + high-resolution measurements (in the nsec range for some) + no need to instrument your code - expensive - emulators sometimes introduce wait states that skew timings 2. Toggle pins on an output port, measure with oscilloscope + visual representation + cheap, easy - hard to get a decent trace for jittery cycles - non-cyclic events require a storage scope - can't meassure max/min, only average 3. Hardware timer chip. Start the timer at the start of the event of interest, stop it at the end. Shove the resulting time into an event timestamp array somewhere in RAM. You can timestamp as many events as you have available RAM. Then, perform a post-mortem dump of the timestamp array, and shove into a spreadsheet for analysis. - intrusive, though this can be kept low - requires a couple words of RAM for each measurement + easy to code + can get every measurement, not just a sample (given enough RAM) + can easily add other events into the log, each with a unique tag and timestamp. A simple procedural interface to the logging facility makes this easier: procedure Log_Event( Event: in Event_Types ) is ... Variation: keep track of min/max/average on the fly, avoiding the need for a large RAM event buffer. - additional overhead due to run-time calculations + cuts down on RAM. No need for post-mortem analysis. 4. Flash a red LED on and off, and use a stopwatch ;-) Good luck! .Bob. -- Bob Kitzberger Internet : rlk@telesoft.com TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Court West San Diego, CA 92121-9891 "There's too much caffeine in your bloodstream..." (619) 457-2700 x163 -- The Smiths ------------------------------------------------------------------------------