You know you shouldn’t, but you do. I do. We all do. Though we don’t like to admit it. Yes, I use print statements to debug my code. And I work on debug tools for programmers and hardware engineers. I guess that makes me even guiltier.
Despite having a plethora of debugging tools and scripting languages, I’ll admit it - one of the first things I do to try to get a handle on a bug is to throw in a few printfs. Even though I can use valgrind with the best of ‘em, there is something comforting about seeing exactly where your code is as it makes progress (or doesn’t).
But what about embedded folks? If you’re putting an application together for a desktop machine, you have a file system and terminal windows – you can create log files and printouts galore. In the embedded world you may not have that luxury. You might have a display or a file system, but more likely you don’t. Many of today’s embedded systems do have a serial port where you can connect it to a terminal (usually virtually). One common alternative I’ve seen used – especially with systems based on embedded Linux - is to create a file system in flash memory. This can later be accessed by the debug system.
ARM has put together an approach called “semi-hosting” that they have integrated into their debugger and compiler tools. Semi-hosting allows the embedded developer to put printfs in their embedded code. The linker redirects these calls to the host system (for simulated designs) or to the debugger (for prototype boards) for output. Not only can you use printfs with semi-hosting, but you can call just about any standard I/O function. You can open log files – or even input files. I’m not going to teach you all about ARM’s semi-hosting capability in this post, but you can read about it here.
So ARM has you covered if you are running one of their “programmer’s view” virtual prototypes or one of their development boards, but what about running the processor in a logic simulation? ARM never bothered to add support for the semi-hosting in their logic simulation models. And I don’t think they should – these are silicon sign-off models that need to perform exactly as the real gates will. Tweaking them to support debug features would not be a good idea. But if you’re designing hardware for an ARM processor, at some point you’re going to need to run some code on that simulation model. And – thanks to Murphy’s Law – it’s not going to run the first time. Then you’re going to need to debug it. While my company has a fancy debugger that solves this problem, your first instinct is probably to “throw in a few printfs.”
One common way to support some kind of a print statement is to add a virtual character device to the logic simulation of the design. Basically, this is just an address where you can write a series of characters which, through the magic of HDL, will end up in the simulation transcript. With this you can write a “P” if the test passes or an “F” if the test fails. Of course, you now need to hunt through your simulation transcript to find all your characters.
One clever approach I saw one of my customers using was to grep the log.eis file for writes to that address. In his software he wrote a series of characters to address 0×80000000. This was done with a simple modification to the retarget.c file supplied by ARM. After the program ran in the logic simulation he did a grep of the log.eis file (on newer processors this is now the “tarmac.log” file - I really wish ARM could be consistent with these things).
% grep –i –e “Write Byte.*80000000” log.eis > foo
Then he lined up the characters using cut and a simple filter program.
% cat foo | cut –c 111- | to_string > bar
Now the file “bar” has a nicely formatted set of characters as they were written to address 0×80000000. For reference, here is the listing of the “to_string” program:
% cat to_string.c
while (EOF != scanf(“%x”, &n))
One of my engineers found a way to add a virtual terminal to an ARM processor that works with this same approach – and with the semi-hosting, too - to put the characters in a terminal window live during the simulation (rather than post processing, as above). It’s a pretty neat approach, and it lets you keep track of what that pesky code is doing as the simulation proceeds. It works with no changes in the software at all; it just gives the printf a place to go. However, with a slight modification to the code he can eliminate all the printf processing (which is really sloooow) in the logic simulation. If you’re interested, shoot me an e-mail and I can set you up with it.
Printfs and log files are often used as debug tools. They are particularly useful when you don’t want to stare at a debugger while a system is running for long periods of time. Although the computer science purists may denigrate them, they are simple, easy, and they work. With a bit of ingenuity you can use them on a wide variety of targets.
More Blog Posts
- Part 1: The 2012 Wilson Research Group Functional Verification Study
- Those nasty wire’s and reg’s in Verilog
- Getting AMP’ed Up on the IEEE Low-Power Standard
- Prologue: The 2012 Wilson Research Group Functional Verification Study
- Even More UVM Debug in Questa 10.2
- IEEE Approves New Low Power Standard
- Verification Horizons DVCon Issue Now Available
- Get your IEEE 1800-2012 SystemVerilog LRM at no charge
- IEEE 1800™-2012 SystemVerilog Standard Is Published
- See You at DVCon 2013!
- May, 2013
- April, 2013
- March, 2013
- February, 2013
- January, 2013
- December, 2012
- November, 2012
- October, 2012
- July, 2012
- June, 2012
- May, 2012
- March, 2012
- February, 2012
- January, 2012
- December, 2011
- November, 2011
- October, 2011
- September, 2011
- July, 2011
- June, 2011
- Intelligent Testbench Automation Delivers 10X to 100X Faster Functional Verification
- Part 9: The 2010 Wilson Research Group Functional Verification Study
- Verification Horizons DAC Issue Now Available Online
- Accellera & OSCI Unite
- The IEEE's Most Popular EDA Standards
- UVM Register Kit Available for OVM 2.1.2
- May, 2011
- April, 2011
- User-2-User’s Functional Verification Track
- Part 7: The 2010 Wilson Research Group Functional Verification Study
- Part 6: The 2010 Wilson Research Group Functional Verification Study
- SystemC Day 2011 Videos Available Now
- Part 5: The 2010 Wilson Research Group Functional Verification Study
- Part 4: The 2010 Wilson Research Group Functional Verification Study
- Part 3: The 2010 Wilson Research Group Functional Verification Study
- March, 2011
- February, 2011
- January, 2011
- December, 2010
- October, 2010
- September, 2010
- August, 2010
- July, 2010
- June, 2010
- The reports of OVM’s death are greatly exaggerated (with apologies to Mark Twain)
- New Verification Academy Advanced OVM (&UVM) Module
- The Dog That Didn’t Bark
- DAC: Day 1; An Ode to an Old Friend
- UVM: Joint Statement Issued by Mentor, Cadence & Synopsys
- Static Verification
- OVM/UVM at DAC 2010
- DAC Panel: Bridging Pre-Silicon Verification and Post-Silicon Validation
- Accellera’s DAC Breakfast & Panel Discussion
- May, 2010
- Easier UVM Testbench Construction – UVM Sequence Layering
- North American SystemC User Group (NASCUG) Meeting at DAC
- An Extension to UVM: The UVM Container
- UVM Register Package 2.0 Available for Download
- Accellera’s OVM: Omnimodus Verification Methodology
- High-Level Design Validation and Test (HLDVT) 2010
- New OVM Sequence Layering Package – For Easier Tests
- OVM 2.0 Register Package Released
- OVM Extensions for Testbench Reuse
- April, 2010
- SystemC Day Videos from DVCon Available Now
- On Committees and Motivations
- The Final Signatures (the meeting during the meeting)
- UVM Adoption: Go Native-UVM or use OVM Compatibility Kit?
- UVM-EA (Early Adopter) Starter Kit Available for Download
- Accellera Adopts OVM 2.1.1 for its Universal Verification Methodology (UVM)
- March, 2010
- February, 2010
- January, 2010
- December, 2009
- A Cliffhanger ABV Seminar, Jan 19, Santa Clara, CA
- Truth in Labelling: VMM2.0
- IEEE Std. 1800™-2009 (SystemVerilog) Ready for Purchase & Download
- December Verification Horizons Issue Out
- Evolution is a tinkerer
- It Is Better to Give than It Is to Receive
- Zombie Alert! (Can the CEDA DTC “User Voice” Be Heard When They Won’t Let You Listen)
- DVCon is Just Around the Corner
- The “Standards Corner” Becomes a Blog
- I Am Honored to Honor
- IEEE Standards Association Awards Ceremony
- ABV and people from Missouri...
- Time hogs, blogs, and evolving underdogs...
- Full House – and this is no gamble!
- Welcome to the Verification Horizons Blog!
- November, 2009
- October, 2009
- September, 2009
- August, 2009
- July, 2009
- May, 2009
RT @CalyptoDesign: Read Shawn McCloud's article "Raising the Bar for Power Optimization" in Chip Design. #DAC50 #Power #EDA #SemiEDA http:/… 6:30 AM May 18
RT @dave_59: What's the deal with those wire's and reg's in #Verilog and #SystemVerilog. http://t.co/520olnyog4 6:26 AM May 18
What's the deal with those wire's and reg's in #Verilog and #SystemVerilog. http://t.co/520olnyog4 7:20 AM May 13