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. Hallelujah!

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 is, however, 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 on March 26. We explained how network software bring up can be accelerated, both by starting much earlier and by having more productive tools, using virtual prototypes. Not only do Virtualizer Development Kits, which are 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.

The Synopsys DesignWare transaction-level model for Ethernet has the ability 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.

ARM and Synopsys continue 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 such as these Virtualizer Development Kits with ARM Fast Models and Synopsys DesignWare models.

To end this blog post with a bang, well in this case with a dunk: since 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: http://www.youtube.com/watch?feature=player_embedded&v=cylFQ7-K2IE#!

Enjoy!

The quick road to the recommended daily allowance of vegetables and fruits is often a bottle of v8. It is quick, nutritious and makes us feel less guilty about any of our nutritional imbalances. It makes us feel virtuous, that 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 like AMD who will use 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 markets like mobile and consumer.

With so many new customers adopting this new architecture, tools to allow porting of software and use of legacy software on this new architecture is critical.  Tools are an absolute need 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.  

These two approaches to prototyping seem well separated in a SoC design’s project schedule. Since 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 one of the pre-engineered VDKs offered by Synopsys. 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 that 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 have also 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

Product Marketing Manager

FPGA Based Prototyping Software

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 Antonio Gaudi’s architecture, some great vegetarian restaurants like Juicy Jones and of course enjoyed the Sangria.  But this is not a travelogue.  It is about what is happening in embedded Linux today and four areas of transformation.

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 at http://elinux.org/ELCE_Europe_2012_Presentations 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.  Now 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 contributed back to 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 and have recently earned a very different comment from Linus.

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 reuse.  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 OS’s and BSP formats that can be used by OS companies without having to recreate everything.  It also allows customers who start with Semi OS’s to move to commercial OS’s 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 re at www.yoctoproject.org.

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, is 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 are already created for designing the chip into prototypes.  This then 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 them, 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 helped along.  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.

For example, of 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 way before the chip tape-out even comes 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.

• Start execution on external wake-up event (e.g., power-on)
• Examine further hardware switches to configure the boot (e.g., debug/interactive mode on/off)
• Provide a command line interface through a UART to enable interactive mode
• 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
• 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
• Provide functions to update the boot monitor image in the EEPROM from an SD card
• Initialize the memory controllers to allow the OS access to DRAM/SRAM
• Initialize clocks and voltages
• Handover boot parameters to a second-stage boot loader, hypervisor, secure OS or the main OS
• 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 side stepped.

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 as 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 3 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.

1. When using printf statements in low level software such as bare metal firmware, boot-loaders, 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 semihosting:

# 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 via: http://www.synopsys.com/Systems/VirtualPrototyping/Pages/VP-Learn-Experience.aspx (see examples). I hope this is not too much code for a blog post during the vacation season.

We in the Virtual Prototyping industry assume that the most logical action for today’s software developer is to use models which allow the creation of an exact virtual prototype (VP). The reality is that use of models is growing but largely dominated by a small segment of the software community who work in semiconductor companies.  The concept of models is the accepted way ESL/EDA/CAD- centric engineers address the lack of hardware problems. This industry is still the primary source for Virtual Prototypes which have evolved as a use model for SystemC/TLM, next to hardware-centric design tasks such as high-level synthesis and verification. However, this may not completely fit into a software developer’s comfort zone yet.  Back to the EDA/ESL/CAD world, there is a long-standing debate about model timing accuracy versus actual hardware.  I contend that more  important than timing accuracy, is the understanding of the constraints in which the results are useful or needed.  This is an engineering skill that often differentiates the good from the great engineers.  The presenter of the above Linaro example has identified a key shortcoming and points out that only the user space software performance is scaled down and the OS kernel performance is not impacted. And yet the approach is accurate enough, if this constraint or shortcoming is taken into account when interpreting the results.  A software-centric perspective needs to be applied to what is “good enough” when using models for software development purposes and not applying an EDA perspective.

Those of us who work with virtual prototypes (VP) know that virtual prototypes would have been a very good choice in the example above. Specifically, a VP would have addressed the key shortcoming around the performance scaling of the kernel routines. Using a VP, the performance asymmetry of the CPUs could have been reflected by simply changing the clock frequencies. Furthermore, even the real binary big.LITTLE software stack could have been simulated. VPs were built for easy controls and non-intrusive debugging. But, in order to get VPs used by embedded software developers, we need to put them into a software developer’s comfort zone. In order to get there, VPs have to be as “out-of-the-box” as other software development targets, such as physical development boards. And it also needs to support reference embedded software stacks like Android and Linux. Finally, the VP tools need to be seamlessly integrated into the software developer’s standard tools (IDEs, debuggers, configuration management, testing frameworks).   Understanding how the software developer uses  tools are critical to the adoption of VPs becoming a natural choice.   Once VPs are software friendly, developers will realize the full benefit of visibility, control and convenience of VPs as a development kit and not just for bare-metal simulation.

To take tangible steps in understanding the software developer, a step we’ve taken at Synopsys, is our focus on a well-known development board for ARM CPUs within the embedded software community, the “Versatile Express” prototyping system.  Similar to a software development kit which is very familiar to a software developer, a “Virtualizer Development Kit” or VDK puts together in one convenient kit, a Virtual Prototype or target, tools and an installer so software development can begin without too much work.    An advantage of our VDK is that we support new CPUs much faster than hardware ever could. ARM’s FastModels for the Cortex CPU family typically have a head-start of at least twelve months compared to hardware availability. By pairing models with a virtual motherboard and a comprehensive set of peripheral IP, such as USB 3.0 a path to earlier software development emerges.  The result for the software developer is a huge head start on developing an ever increasing amount of software solutions. To complete the story I started with, I am seeing an increasing number of developers at Linaro use ARM’s FastModels to do more of their development.  As models deliver on their development value, they will become the pragmatic solution for early software development.