By Tom De Schutter
Last month we were all waiting for white smoke to emerge from the chimney on the roof of the Sistine Chapel at the Vatican. I am of course talking about the election of the new pope. I couldn’t help but see a parallel with how software developers are anxiously waiting for their software to run correctly and finally get past the series of seemingly never ending bugs (black smoke). While software might never be bug free, seeing the right functionality for a particular use case is a good feeling.

It is important to consider how to get to working software the quickest. A lot of people are like the dove on the chimney of the Sistine Chapel. Watching from the outside to try to get a sense of if something works or not. However, it is so much better to be an insider and probe what is going on to more quickly determine the outcome. And what is better for a software developer than having a software model of the actual hardware? It takes one to know one. Software can be controlled, probed and analyzed much more easily. So nothing beats having a virtual prototype—a fast, fully functional software model of the system under development that can execute unmodified production code. It is like being a cardinal at a pope election. You still don’t know when exactly the next pope will get elected, but at least you are actively influencing the outcome.

The time at which you start software development will influence when your software will be ready for use in combination with the target SoC or device. So, similarly to how the conclave elects a new pope was moved forward to make sure that there would be a new pope by Easter, you might want to consider starting your software development early to get white smoke by the time you want to release your SoC or device. By using a virtual prototype, you don’t have to wait for a board to be available to start software development. And your chances of getting the software ready by the time the hardware will be ready increase significantly.

— Tom De Schutter is senior product marketing manager for Virtualizer Solutions at Synopsys.

By Tom De Schutter
With their latest Cortex-A processors, and especially the ARMv8 Cortex-A57 processor, ARM has provided the right scalability and performance required for network applications. Porting and developing software for these multicore/multi-cluster designs, however, is not a trivial task and cannot be done as an afterthought. That is the topic that Robert Kaye from ARM and I addressed at SNUG Silicon Valley this week, in a session titled Ease Debug and Control of Network Software Using Virtual Prototypes to Do Full System Simulation. We explained how network software bring up can be accelerated, both by starting much earlier and by having more productive tools, using virtual prototypes.

Software development kits that use a virtual prototype as target provide the ideal set of tools and models for the task as evident in the figure below. They also have the ability to simulate a network setup.

One of Synopsys’ approaches is to connect a VDK to the physical network and to other VDKs through a virtual hub. That way it is not only possible to bring up and test software in the context of a specific SoC, but also in the context of the full system.

In the end you want to test the setup for reliability and security by running real software scenarios. And that is exactly what virtual prototyping is about: bring up of actual software before hardware is available.

It’s also critical to collaborate closely to help customers achieve their goal to create and test devices and infrastructure as quickly as possible. And that means providing solutions parallelizing hardware and software.

To end this blog post with a bang—well in this case with a dunk, because a network is all about enabling communication to achieve a certain goal (share data, make an online call…)—I had to think about my network software presentation when watching this amazing dunk on YouTube.

Enjoy!

— Tom De Schutter is senior product marketing manager for Virtualizer Solutions at Synopsys.

By Nithya Ruff
The quick road to the recommended daily allowance of vegetables and fruits is often a bottle of V8. It’s quick, nutritious, and it makes us feel less guilty about any of our nutritional imbalances. It makes us feel virtuous, because we have done something good for our body today.

So why do we postpone the inevitable? By this I mean developing new software for a new piece of hardware. The whole system is geared to putting it off as long as possible and then working insanely to finish it. Our excuses are many.

— I do not have hardware to start development…

— My software team is busy with the previous program….

To which I say, there is no better time than the present to start software development for ARMv8 processors.

At the 2011 ARMTechCon in Santa Clara, ARM announced the availability of ARMv8 architecture which will allow ARM-based processors to support 64-bit computing while leveraging ARM’s low power processing. The announcement of any new architecture set the ecosystem wheels in motion to support this new architecture.

There were multiple announcements at ARM TechCon 2012 on new licensees such as AMD, which will use the ARMv8 architecture to address their markets. The availability of 64-bit computing combined with the legendary power efficiency from ARM will lead to new market adoption and uses for this architecture such as servers, cloud computing, networking, as well as ARM’s traditional mobile and consumer markets.

With so many new customers adopting this new architecture, tools to allow porting of software and use of legacy software on this new architecture are critical. Tools are an absolute necessity for those very new to the ARM architecture, and even those used to the ARM architecture, to prove their code in the 64-bit processing environment.

ARM has been working hard along with its ecosystem partners to prepare for this migration, adoption of tools, education and communication. At Synopsys, it has been a busy time to extend our already available support for ARMv7 processors and our experience in this area to ARMv8 processors. With the announcement last week, we entered this exciting new world of ARMv8 architecture.

When there is no hardware and you just have to get started, especially with a new architecture, there is nothing better than Virtualizer Development Kits (VDKs) to start the work. What these VDKs do best is to allow you to not feel guilty but to start booting your legacy software now, develop drivers now and get it ready for when that hardware arrives. And when it does, you will be some of the first ones to be able to boot in minutes on the hardware and go to market quickly. Synopsys’ VDK for ARMv8 Processors comes with ARM’s Cortex-A57 Fast Model, popular DesignWare peripherals and IO models included so you can boot your OS or develop drivers. And it plugs into your debugging environment and gives you enhanced hardware/software views to tackle hard bugs. Just like drinking that V8 juice, it feels good and right.

http://www.synopsys.com/Systems/VirtualPrototyping/Virtualizer-Development/Pages/default.aspx
http://news.synopsys.com/index.php?s=43&item=1106

—Nithya Ruff is director of product marketing for Virtualizer Solutions at Synopsys.

By Troy Scott
This month Nithya asked me to contribute a post on hybrid prototyping and add some color to how design teams have been benefiting from integration between virtual and FPGA-based prototypes. It’s been about six months since Synopsys announced the availability of a data exchange, which links a Virtualizer Development Kit (VDK) to the HAPS FPGA-based prototyping system based on AMBA transactors and the HAPS UMRBus interface kit. Since that time we have further validated popular use scenarios for a hybrid prototype. So, what are the cases where there’s a benefit to connecting a SystemC TLM based model to an FPGA-based prototype?

These two approaches to prototyping seem well separated in a SoC design’s project schedule. Because there’s no dependency on RTL, a VDK could be up and operational for software development in a matter of weeks versus the months typically required to create and obtain the RTL and IP required for synthesis and implementation into an FPGA. Bring-up time is even shorter if you are able to leverage a pre-engineered VDK. And if the VDK is serving as the software development platform, then what more utility does the FPGA prototype provide beyond the RTL validation that a simulator or emulator can’t deliver as quickly?

What we now confirm with customers is that model availability of SystemC or HDL is not clear cut along schedule timelines, and some SoC block validations demand high fidelity or clock cycle accuracy that require real world I/O interfaces and hardware to prototype completely. The other common condition is the preponderance of legacy SoC blocks that will be reused from revision to revision of the SoC design. In these scenarios, there’s a desire to have the option to freely mix and integrate the RTL/IP with a SystemC model for the SoC prototype.

At a recent engagement we completed a hybrid prototype implementation that connects a virtual (SystemC TLM) embedded Cortex-A9 CPU, cache and memory to a physical camera module and display. An image-processing engine was implemented in the FPGA resources of a HAPS-60 system with a camera and encoder modules attached as HAPS daughter boards. Interrupt and data transfers between the model domains were accomplished using GPIO and AMBA transactors. Transactors serve to abstract the interface into the familiar Read/Write/Interrupt commands and automatically reconcile the loosely timed virtual model with the cycle-accurate hardware. In the virtual domain, Linux OS and application software layers executed image encode/decode. This was a great example of the validation and software teams collaborating to leverage the best of both prototyping worlds by taking advantage of the high MIPS throughput of the virtual A9 along with test jigs, sensor array and display hardware adjacent to an FPGA for hosting legacy image pipeline logic. We call this application case “in-context” validation because of the way the processor subsystem wraps around the new RTL modules being validated using the OS/firmware stack.

Engineering managers also have observed that this ability to bridge the prototypes helps break down the traditional walls that exist between the software and hardware development organizations, causing them to jointly address system flaws rather than depend on the software team at the end of the project to drop features or apply workarounds due to unexpected silicon limitations and bugs.

What does the future hold for hybrid prototypes and transactor technology?

We are already seeing other scenario implementations where the FPGA-based prototype is attached to a host workstation for data streaming. A C++ based application generating test patterns for validation. Again, a transactor library API delivers an easy way to exercise the prototype by using familiar AMBA bus protocol commands. In the future we will likely see improved cross-triggering of debug features so system events from one domain are detected by the other. This may cause the embedded logic analyzer of the FPGA to sample status registers based on a software breakpoint encountered by the virtual prototype.

Connectivity between virtual, FPGA-based, and emulation tools for ASIC and SoC verification and validation gives more flexibility to engineers to connect design blocks that are most readily available and leverage the unique strengths of each prototyping system.

—Troy Scott is the product marketing manager for FPGA-based prototyping software at Synopsys.

By Nithya Ruff
On a recent trip to Germany, I was a passenger in a car with my colleague Tom De Schutter on the German Autobahn. We had just landed in Frankfurt and were driving to Aachen, Germany. The anticipation of the potential speed at which we would drive created both excitement and anxiety in me. What I learned about driving on the Autobahn was eye opening with how Germany allows for speed, but also enforces rules of the road to ensure safer driving. You need to have a decent car, and a driver who has nerves of steel and is trained with the rules of the road. It does help that the roads are in good shape and you are driving with others who have been trained from childhood to drive on the Autobahn. I don’t claim to be an expert and won’t go into the details of the rules, but will point you to this article on how stuff works on the Autobahn.

It did get me thinking about the parallels of driving on the Autobahn and how we are driving faster and faster in the tech world with getting products to market. The whole product life cycle is shrinking while the complexity is increasing. Lifecycles of 12 months or less are quite common in mobile and consumer, and even automotive and industrial cycles are shrinking. So how do you go fast and still remain sane? You clearly cannot do the same thing you did before and just attempt to do it faster. You need to systematically consider all aspects of the process to adjust for this speed. Going fast without training, rules of the road, better vehicles and better roads can be disastrous. Changes are needed.

Using yet another comparison, innovation in product without innovation in process and methodology, team dynamics and organization, is like driving a Maserati without any training in driving a fast car. So why would you sign up for developing your new product in a much shorter time with the same process as before? Everything from social dynamics—how teams work together, the HW and SW development process, the testing process, the training process and rollout to the field and customers—are all fair game for examination. When I wrote this article, that’s what I had in mind. De-risking a project and working with speed and yet quality is about changing the way we develop:

1. Not just using PowerPoint, spreadsheets and discussions to make design decisions but actually simulating the products and doing what-if analysis.
2. Not waiting till the end of the project to do 50% of the solution development, i.e. software, but instead starting early, incrementally developing and testing against targets available in each phase. For example, starting with models and moving to FPGA boards and sample boards and reserving only the final tests for the final boards. Why risk doing all your development on the final boards? Why not limit use of real hardware for the final test phase?
3. Even HW development can be agile when you have multiple feedback iterations from running actual SW on the models even before RTL is created or committed to. Why depend on SW to work around any HW quirks? Why not change HW design early so both can be optimal?
4. Even when all SW teams are not available to work on the project, start with the sub-groups that are available. Enable them with portion of the prototype that they need to get their work done.
5. Why not do ‘what if’ analysis with models so you can fine-tune performance and power utilization? Why wait till you get complaints from customers to make the adjustments? The more we wait, the more expensive changes become.
6. Multicore designs are one way to get more horsepower into designs. But if you have horsepower without knowing how to use it, that can be a huge waste. Developing software for multicore designs is still an art, and having more runways to do and test it with full visibility into the behavior of different cores is critical to its success.

More than anything, as I get older and smarter I realize that I don’t want to stress my mind and work whenever I don’t need to. Gone are the days when I crammed for an exam the night before and stayed up all night. I plan and spread out my work over the days I have to minimize the risk, stress and wear and tear. It has resulted in better quality work and a happier life. I also am happy to say that I survived the Autobahn and have a healthy respect for speed, and realize that it can be done safely with some planning. I wish all of you speed, safety, happiness and a stress-free holiday season.

—Nithya Ruff is director of product marketing for Virtualizer Solutions at Synopsys.

By Nithya Ruff
I recently attended the Embedded Linux Conference in Barcelona representing Synopsys. I must admit, it is nice to have conferences in beautiful places so you can kill two birds with one stone. When not networking, speaking or sitting in sessions, I enjoyed seeing the beauty of Antoni Gaudi’s architecture, some great vegetarian restaurants like Juicy Jones and, of course, I enjoyed the Sangria. But this is not a travelogue. It’s about what is happening in embedded Linux today and four areas of transformation.

The Sagrada Família, Antoni Gaudí's unfinished masterpiece.

Having been in Embedded for the last six years, I have seen some radical changes. Coming from enterprise Linux and applications, it was a complex world to navigate a small footprint, real-time performance, cross development, a dizzying array of architectures and custom hardware. However, I have seen this industry go from specialized RTOS and hand-rolled OS to more standard embedded distributions and, of course, Android. But when you look at the various sessions at the conference, you realize that we still have a way to go before this world of embedded software development is tamer and easier. Check out the session here and you’ll see a lot of sessions on debugging and words like Apocalypse.

This challenging state is, of course, compounded by the continued rise in hardware complexity, volume of devices and applications to be supported and the volume and pace of embedded devices. So, if the fragmentation and custom nature of embedded Linux was bad before, it is worse now because of the rising complexity. Many tools are suggested; many techniques and guidelines are offered. But this is still nowhere near the simplification needed. In surveying what is happening, four shining areas come to mind that are creating standards and common practices and making a difference.

The first area that is making a real difference is the Linaro organization. Linaro is a not-for-profit engineering organization consolidating and optimizing open source Linux software and tools for the ARM architecture. The reason they make a real difference is the sheer volume of devices being created based on ARM in mobile, consumer and in many other vertical areas, in addition to the hundreds of ARM licensees who each add differentiation to their ARM chip. This made for a large number of ARM processor patches being contributed back upstream and a complexity problem in dealing with the vast variety. But licensees came together in the Linaro organization, which streamlined and standardized the work around ARM software. Their work has paid off. Linus Torvalds has changed his characterization of the “ARM thing” from a “pain” to “an outstanding citizen.”

The second major movement in embedded in the past few years has been the Yocto Project. Processor companies, OS companies, tool companies and services companies all came together to reduce complexity of developing embedded Linux, BSPs and increasing leverage and re-use. The project describes itself as “an open source collaboration project that provides templates, tools and methods to help you create custom Linux-based systems for embedded products regardless of hardware architecture,” helping semis create OSes and BSP formats that can be used by OS companies without having to recreate everything. It also allows customers who start with semi OSes to move to commercial OSes without losing the work and hardware optimization from the semis. These are good objectives for creating more reuse and leverage across supply chains and less islands of work. It is still a young project and has more to do to enable use by semis. But it is a great start and has the right objectives. You can find out more here.

The third area is developing software without hardware, or with more hardware awareness. At the conference, a number of people talked about the black box called hardware. In embedded it is compounded by the custom nature of hardware and the numerous architectures supported. The other aspect of the complexity is just getting access to hardware early enough to do software development and testing software that is specific to that hardware. Moreover, as one person said, the hardware is quirky and still in development. Software developers have always been smart about using emulators and other means of testing their product as hardware has either been expensive, fragile, limited or late to get their hands-on. While a lot of software developers are familiar with QEMU, when we shared what virtual prototyping can do, many were excited and interested because it creates a software prototype of hardware, not just standard hardware but custom hardware.

Even the most complex SoCs can be modeled in the right level of abstraction and speed software development. The benefit of having a prototype on your host or development computer is that it is fast, gives you analysis, profiling and tracing views. Further, when you can control it and make it stop, start and play certain scenarios, all without altering the hardware or software, it’s powerful. As more and more software is being developed at semi vendors, those are the places where prototypes are being created and used extensively. They simply use the specs that already are created for designing the chip into prototypes. This allows them to develop software, upstream contributions, and test the software. One way of beating complexity is to just invest more time and tools into the problem. When tools allow you to peer into what was once a black box for software developers, the problem becomes simpler to tackle. Further, if time is on your side and you can tackle much of the complexity by breaking it down into pieces and solving each, you have a chance to conquer complexity.

The last one is the events themselves that bring developers together. Linux and Android events are like no other. They focus on the developer at the center of the conference and arrange labs, tutorials, discussion groups and social events all around collaboration. These events, which started out informally, are now well organized by the Linux Foundation and other similar organizations. The level of openness and sharing at these events always surprises me in a good way. Going to an event like this, a new developer is often mentored. And, developing a relationship with maintainers helps you understand the optimal way to work with the projects. All together, this is the glue that keeps Linux and innovation moving. The former Consumer Electronics Linux Forum is now part of the Linux Foundation and is the backbone of the Embedded Linux Conference.

Just like the beautiful Sagrada Familia cathedral designed and started by Gaudi, embedded Linux is a work in progress. But it is more complete every time you look—and one day it will be ready for those billions of devices that will be based on it.

The Embedded Linux Conference brings developers together.

—Nithya Ruff is director of product marketing for Virtualizer Solutions at Synopsys.

By Nithya Ruff
Last year, my daughter was a senior in high school, very busy finalizing her college selections and completing college applications. For anyone who has gone through this recently, it is not a trivial task to select a place where you will spend the next four years, a place that will shape your future and where you will be spending a good amount of your parent’s money. This experience got me thinking about how we go about selecting a solution for problems we want to solve at work.

Creating a new SoC or chip and even a derivative chip is not a trivial task. Millions of dollars are at stake and large hardware, software and business teams are all working hard to make this product successful. You need all the help you can get to ensure that you have the best tools, the best partners and ecosystem all lined up and working with you. You cannot afford delays or re-design. Many of my customers face this situation. To me, there are four things that stand out as selection criteria to ensure that you have the right partner in this critical endeavor:

1) Is the supplier a vendor or a strategic partner? For solutions that are critical to our success, we can no longer afford to have suppliers who are just vendors. We need someone who understands what we are trying to do, is an industry leader in that area and able to provide advice, best practices and guidance to ensure our success. For example, thought leadership in a space can be market share, number of successful customers and stability as a company. As a lot of critical solutions like virtual prototyping become a key part of a company’s software development process, our customers tell us that they want a partner who has staying power and leadership in this area.

2) How complete is a technical solution? Does it have all of the pieces we need—product, support, services, training, collateral and documentation? Is there a predictable roadmap that assures me that this solution will continue and be maintained? Is there support for standards and key developments in the industry? How is the usability and quality? If I run into bugs, how does the company respond? In my own product area, solutions consist of such things as:

• A broad library of models that can be used off the shelf. This helps a customer focus on creating models where they add value or differentiate and use off the shelf high-quality models for the non-differentiating parts of the solution.
• Tools for easy creation and debugging of prototypes are also important as many customers create their proprietary models.
• The end game is often the software developers who need to be able to use them just like any other software tool and to be productive from day one.
• Services and training: The ability to jumpstart a program with highly skilled teams till the teams get up to speed is an important buying criterion for many. Training and mentoring programs get the teams ready, but only until they can do their own work so knowing that highly experienced teams can create the prototypes is important.

All of these considerations have us balancing our investment to insure that we make customers lives easier and productive.

Almost all of my customers have teams all over the world. They are no longer are all located in one physical site, which leads to the next point.

3) How well can they be supported worldwide by their partner? Does the partner have offices, services, local language support in the geographies they care about? Even the design of the solutions need to take into mind the notion of global collaboration. Virtual prototypes, being 100% software-based, can be sent and used anywhere without logistical challenges, risk of getting damaged, or being held up in customs. Provisioning licenses for a team in India or anywhere must be easy. Being able to work on a common reference virtual prototype or assemble one from sub-systems across the world is a key deciding factor.

4) How complete is the ecosystem? You also want a solution that is well connected and networked. A solution that supports standards and works with a broad set of companies in the industry, to bring the solution together. You also want a company that participates in technical organizations that help move the industry forward. It provides forums for users, industry players and customers to get together and share practices. We cannot afford to bet on solutions that are islands and not connected. We need solutions that broaden our reach by working with them.

This was something that was of importance to us as we put together the virtual prototyping solution. We wanted to make sure that we had a partner program such as the Catalyst Program. We worked hard to create a TLMCentral site as a forum for models and model practice information. We also ensured that we were working with a broad and great set of model partners to bring models to our customers of high quality. By supporting SystemC and Transaction Level Modeling standards, we make sure that our customers are able to leverage the work of standards and the assurance of interoperability. All of this has helped move virtual prototyping forward to where it is today; a well-established solution for early software development.

Coming back to my college selection story, I am happy to say that my daughter not only got into her first choice school, Vanderbilt University, but is also happy to be there. The size of the school, the quality of the program, the city of Nashville and the variety of experiences the school offers is something that we are happy about. Putting some thought into all aspects of a selection does pay off.

—Nithya Ruff is director of product marketing for Virtualizer Solutions at Synopsys.

By Nithya Ruff
Watching the Olympics this past summer was quite exciting. I enjoyed seeing athletes at the peak of their performance and multiple records broken in many sports. What we don’t see is the years of practice and work behind this excellence. These athletes work at the technique, strength, endurance and mental attitude of winning. To me, this is no different than the work that goes on behind the scenes of a new chip introduction, or for that matter any new product introduction.

Of particular interest to me is new chip development. We have come to accept that software is a key part of the value of new chips that drive innovative embedded devices. Software enablement proves that the chip works and empowers software developers to develop applications on the chip and provide example reference stacks. This is standard operating procedure by all leading semi vendors.

Further, what is becoming inevitable is that this software and the applications developed on the chip are as varied and demanding as its users. It is this complexity, variety and software support that is driving two behaviors. One is to let software drive hardware design and to test it based on application needs. The second is to start developing the software and supporting tests as early as the availability of chip specifications.

Both of these actions are interconnected. Early development of software allows the interactive and joint development of the HW and SW with each improving the other and working out the kinks of the other. For example, an initial architecture model can be used to bring up boot ROM code showing that the chip is alive and works. The writing of device drivers can exercise various peripherals and the bring-up of an OS like Android demonstrates how some of the features and applications work on the hardware. The software process itself can be iterative and incremental. It can start with a small model of some of the SoC and software for that specific piece can start to be written. As more of the models of the SoC emerge, so can the software as the picture below shows.

What this means to many of the users I talk to is the removal of risk in a project and improvement of the quality the product. A bigger benefit is the fact that the prototype of the chip can be delivered to partners, the field and customers at least six to twelve months before the actual chip is available. So why is this interesting? Feedback from one user sums it up nicely: Earlier software development enabled the creation of more than five board support packages along with field training and even won two deals by using an early prototype. All this occurred way before the chip tape-out even came around. So if sales and bookings can be pulled in and product quality increases, why would anyone not want this advantage?

To excel in anything requires the process of excellence to start early, just as the Olympic athletes showed throughout the Games. The bar rises with every Olympics Games and an athlete cannot afford not to take every advantage available. The fierce and competitive world of device development is the same, new winners are announced every day and new records broken. Without the advantage of starting early, testing with the end in mind and delivering innovation—winning may be only a dream.

—Nithya Ruff is director of product marketing for Virtualizer Solutions at Synopsys.

By Achim Nohl
Finally, nine months after the next-generation SoC project was kicked off, the first prototype board has finally arrived! There are just six months left to get Android and Linux up and running. Because Android should take full advantage of the latest hardware additions, let’s make sure we get it ported as quickly as possible.

Unfortunately, it’s not that easy. Before you can care about porting your OS and developing the drivers for your special hardware, you have to deal with the boring, but necessary, initialization of the hardware. This is typically done by a so-called boot monitor. A boot monitor is a software program in ROM that gets launched after pressing the power-on button on your hardware. Even though the boot monitor is not a large piece of software (compared to the OS, etc.), it provides complex functions and interacts with many hardware peripherals. As an example, the classic minimal functions of a boot loader are given below:

1. Start execution on external wake-up event (e.g., power-on)
2. Examine further hardware switches to configure the boot (e.g., debug/interactive mode on/off)
3. Provide a command line interface through a UART to enable interactive mode
4. Provide a USB device driver and SD card driver that allow the user to download his OS kernel image from his PC to an SD card
5. Provide NOR flash drivers in order to move the OS kernel from the SD card into the NOR flash memory where the main CPU can boot the OS from
6. Provide functions to update the boot monitor image in the EEPROM from an SD card
7. Initialize the memory controllers to allow the OS access to DRAM/SRAM
8. Initialize clocks and voltages
9. Handover boot parameters to a second-stage boot loader, hypervisor, secure OS or the main OS
10. Kick off the main CPU to boot the OS from a kernel image in NOR flash

Often, the boot monitor is not executed on the main CPU, but by a small companion controller. With the introduced functions, the boot monitor easily sums up to a few 100KB of highly platform-hardware-dependent source code. So the boot-up effort you thought you wouldn’t need to be concerned about when the first hardware sample board arrives now requires quite some development. Instead, you would prefer to start programming and validating the advanced features of your new product, such as the new GPU, but the hardware initialization step cannot be sidestepped.

Due to the complexity of ROM code development, and because this task is right in the critical path of your time-to-market window, it has evolved to become one of the main use cases for virtual prototyping. After the board arrives, our experience tells us that the bring-up and validation of the OS and higher-level software can start immediately (same day). The ROM code, which has been developed using a virtual prototype (VP), is sufficiently equipped and tested to no longer be a gating task for the main software bring-up.

Interestingly, VPs for ROM code development are relatively easy to build. The hardware peripherals that are used by the ROM code are, to a large extent, commodity peripherals, like UART, timer, clock generator, etc. Here, the necessary TLM models typically exist. Thus, the VP can be easily assembled using the available TLM models, and the respective driver development or porting can start.

Other important components are the various system configuration controllers needed to program the oscillators, voltage regulators, etc. Those models are not complex from a hardware perspective, as they mainly consist of configuration registers that drive certain signals on a configuration bus. However, they are tricky and complex to program. A bad configuration may prevent the system from booting or can even damage the board. Having a VP that models the effects of clock and voltage settings correctly is very helpful in verifying that the ROM code works on the hardware. Summarizing, the return on investment for using a VP has turned out to be relatively high for this type of software development.

The other advantage of using a VP in this early stage of a project is that a VP does not actually need ROM code to boot the OS. Many of the functions that are provided by the boot monitor, such as loading images into RAM/NOR flash, can be done instantly. As a result, a project dependency is broken and OS kernel porting can start simultaneously with ROM code development. We have seen our users booting Android just three days after the sample board has arrived.

After one year of blogging, this is my last post for “A View From the Top.” Going forward, my colleague Nithya Ruff will bring some fresh new thoughts and continue to post for this blog. Thank you for your interest and comments during the past year.

—Achim Nohl is a solutions architect at Synopsys.

By Achim Nohl
Debugging software by adding printf statements in the code is not considered the cleanest and most advanced debugging approach, but when you are searching for the root cause of a problem you often look to the debugging method you are most familiar with and can apply easily.

The hurdle of setting up a complex debug or trace tool is counterproductive when dealing with schedule commitments and printf is the fallback method, which almost always works as long as you are able to modify and rebuild the software source code. I recently was talking to a software engineer who was working on driver development for a new WiFi chip. When I asked how he is debugging the driver, he answered, “I am doing printk debugging” (printk: debug messages inside the Linux kernel).

The reason behind his decision was to avoid the complicated steps involved in setting up a kernel debugger such as kdb. Luckily, the entire Linux kernel is full of printk messages, just like each and every module of the Android source code is instrumented with “log” messages. The beauty of this kind of debugging is that it can be used to expose the semantics of the software and identify what the software is actually doing. Instead of tracing functions like foo and bar you get useful information such as, “Probing device returned false!” message. It becomes immediately clear what is going on, even if the code was written by somebody else.

However, there are limitations, drawbacks and side effects to consider:

1. When using printf statements in low-level software, such as bare metal firmware, boot-loaders and hypervisors, the kernel is often restricted by the number of serial interfaces (UARTs) available. Each software layer on each CPU needs its own UART.
2. Sometimes you cannot modify or recompile the code to add printf statements.
3. Use of printf statements have an intrusive impact on software execution and may hide defects in parallel software, and finally, they are not applicable for performance debugging. In the context of embedded software, “semihosting” is a well-known mechanism to allow embedded software communication directly with the host computer debugger. A special C-library is linked to the code which routes the printf messages to the host side debugger. Here, the semihosting printf implementation triggers a software exception that is trapped and handled by the debugger to display the message. By using semihosting, the number of debug channels is no longer limited. Unfortunately, even semihosting is not always practical. Semihosting requires you to re-link your software and has an intrusive impact on the software. Suddenly, some bugs disappear and maybe new bugs hit the surface. Also, the software performance is impacted and performance sensitive code such as a scheduler cannot be debugged.

Using virtual prototyping semihosting can be implemented in an almost non-intrusive fashion, without changing the original code. When using a virtual prototype, no special software exceptions are needed to trigger the debugger to catch the debug message. Instead, a breakpoint is directly set at the printf function in your embedded software stack. Unlike hardware, breakpoints in software can be set anywhere, even in ROM code; there are no limitations. The breakpoint is not used to stop the simulation, but instead to trigger automated actions on the host. Synopsys Virtual Prototypes provide a TCL based scripting interface to describe such actions.

Below is the code required to add semi hosting:

# Create a breakpoint at the embedded printk function
set vp_breakpoint [create_breakpoint printk]
# Trigger a an action on the host which displays the message
$vp_breakpoint set_callback vp_printk_action
# Define the callback action
proc vp_printk_action {} {
# Get the message address in the memory from the CPU register
set string_address [A15/cpu0/R0 get_value]
# Read the message from memory and display it.
puts [read_string_from_memory_at $string_address]
}

Using this method requires no modifications or recompilation of the embedded software. And yes, even though not shown here, formatted strings are also supported. Still, the printf code is intrusive since the implementation of printf (using a serial interface) is still executed. In order to overcome this drawback, only one additional line of code is needed in our callback action.

# Immediately exit printf by setting the program counter (R15)
# to the return address (R14, linked register)
A15/cpu0/R set_value [ A15/cpu0/R get_value 14 ] 15

Now, our printf semihosting is almost non-intrusive (just the function call is left). Summarizing, you can use printf wherever you want, even when no UART is available or accessible such as with the early bootloader. There is no need to link in a special runtime library for printf semihosting which is ideal for size restricted code, such as ROM code. You can safely add printfs without impacting system performance, making printf semihosting useful for debugging and optimizing software performance of OS schedulers.

The above example works out of the box with any Linux kernel. You can try it using Synopsys’ ARM® Cortex™-A15 MPCore demo in the cloud (see examples). I hope this is not too much code for a blog post during the vacation season☺.

–Achim Nohl is a solutions architect at Synopsys.