IS SOURCEBOOK
DIGITAL EDITION
AMD SOLUTIONS GUIDE
INDUSTRY NEWS
- 2u Programmable-supply Family Delivers 200 W To 800 W
- Fdsoi Gains Three Design Wins
- Invisible Embedded: 4-, 8-, 16-bit Mcus Still Sell
- Serdes Gearbox Phy Simplifies 100-gbit/s Connectivity
- Major Industrial Computer Company Acquires System Integrator
WHITEPAPERS
- Next Generation AdvancedTCA
- New! Serial Fabrics Handbook
- New! Putting FPGAs to Work in Software Radio Systems, 7th Edition
- The Secret to Fast and Accurate Software Builds: Path to Building Smarter Makefiles
- Creating an Embedded Product with Support for UEFI Secure Boot
- New! High-Speed, Real-Time Recording Systems Handbook
- New! Software Defined Radio Handbook, Updated recently
- RTC Group Taps Industry Leader Clarence Peckham Brings His Technology/Market Expertise to Publications Team as Senior Editor
- RTC Group Taps Renowned Defense Programs Editor
- Learn how to quickly validate and troubleshoot USB 3.0 designs with confidence
QUICK DOWNLOADS
ASK THE EDITOR
Did an article get you 90% of the information you need, but still missing that all-important 10%? Let us help you find what you need.
S/W visibility without intruding on real-time execution – Is it feasibly?
S/W visibility without intruding on real-time execution – Is it feasibly? These two things (visibility, non-intrusion) are incompatible for real-time S/W execution. Or are they? We can intrude on a real-time video and examine its minutest details without impacting the real-time characteristics of the video. We can do this because the intrusion is separated from the real-time recording. Of course we cannot practically record the complete execution of embedded S/W. So what is the minimum data rate needed?
Submitted by Robert Coker on October 29, 2009
Any "intrusion" such as code instrumentation will inevitably affect real-time behavior. Thus recording and analyzing code execution will at least give you an accurate picture of what happened (past tense). There are a number of probes on the market with different memory capacities, speeds, etc., to record a stream of execution and then display it in various formats for analysis and debugging.
No, you can't record the complete execution, but using other tools you can home in on where the problem seems to be occuring and record events befor and after the suspected bug and analyze that part of the exectuion stream. The needed data rate is not an absolute number but depends on the speed of the processor.
Submitted by Tom Williams on November 20, 2009
Discuss
|
I appreciate you taking the time to answer this question! And I have to confess that it is a loaded question. Granted the inclusion of code to record the data necessary to re-create the software execution will affect the real-time behavior. But when properly implemented, it has a minimum impact, and becomes part of the real-time process. And debugging can subsequently be performed in replay, where it can be done without affecting the as-recorded execution states. The same bugs that occurred in record will be in replay. And replay can be repeated as many times as needed to find the source of the bugs. I propose that the minimum data rate is on the order of 2 Kb/sec per MHz of CPU clock for most embedded applications. With the obvious exception of the recording medium, I further propose that it can be done in S/W with minimum impact on execution-time and memory. That the debugging can be done in replay mode, without impacting the as-recorded execution states. I also propose that we can significantly close the gap between how we test, and how our products are used. I hate CNDs (could-not-duplicates)! |