Effective Communication of Hardware Designs to Software Designers using the Cloud (with Video)

Effective Communication of Hardware Designs to Software Designers using the Cloud (with Video)

By Jakob Engblom


Cloud-based services are great for communication – sending a URL to someone is so much easier than almost all alternative means of getting information in front of colleagues and friends. When we are talking about hardware designs and getting them to software designers, the method most commonly used are still prototype boards. Virtual platforms are also used, but they do require users to install and often build a system locally. When using a virtual lab in the cloud, we can get the benefit of the virtual platform (no physical hardware!) without involving the installation, management, and build steps.

As demonstrated live in a video we posted on Youtube, with Wind River Helix Lab Cloud it is easy to provide access to a virtual platform of future or experimental hardware to software designers – without having to copy and install a virtual platform. Hosting the virtual platform in the cloud means that all a software developer needs to do is to log in to Lab Cloud and upload their software for testing.

In the video, we use a simple example of one dual-core and one eight-core configuration being provided to the software team. Exploring variants with different number of cores and other functional blocks is typical for how families of modern SoCs are created, and hardware designers need to validate the usefulness of the variants with software designers. We use a varying number of processor cores since they are easy to understand and easy to test, but it could just as well have been other hardware features like computational accelerators, network adapter with different speeds, or any other device difference between the two platforms. Using virtual platforms is the standard methodology to communicate such variants to software designers, but distribution and updating of the platforms is a problem.  Each change of the hardware design should result in a new platform version, which in turn needs to be distributed to the users.

Thus, when using virtual platforms to communicate rapidly changing and variable hardware setups to software developers, keeping platforms in sync with the software is very important and also quite difficult. As users get new versions delivered to them, old versions tend to stay around since uninstalling old software is less interesting that installing new, which eventually is almost guaranteed to generate strange errors as software, hardware, and documentation drift out of sync on some particular user’s machine. This management becomes very different when using a cloud-based solution.

For example, as shown in the image below, the HW designers are copying a stream of platform versions to the SW team who then has to manage them and make sure to stop using old versions once they are out of date.


In contrast, if we use Lab Cloud to communicate the design, the hardware team knows that the available version for the software team is the latest version that they have deployed. There is no need to track down old versions inside the SW team – they have nothing local that can get out of sync!


Another benefit is that the HW team is in control of the platform in the cloud, and can provide access to precisely the people they want to. Sometimes, access could be very broad, such as everyone inside a company. In other cases a new platform will be tried out by just a few people. With access control managed in the cloud, this is really easy to do. Each variant and each version of the platform can be individually managed, and old versions can be archived in Lab Cloud for comparison to newer versions.

When issues arise in the combination of hardware and software, the collaboration features of Lab Cloud can be used to precisely communicate and help diagnose the issue. Rather than having a discussing around the particular version of the platform the software team is using, software and hardware designers can collaborate around a specific session with a specific issue in the cloud, no copying needed!

Try it Yourself!

Since access in the cloud is so easy, we have provided the two demo platforms used in the video demo in Lab Cloud! Just create an account on Lab Cloud, login, and create your own test sessions from the platforms:


The platforms are equipped with on-target gcc, so just upload a pthread-based or other parallel Linux programs and run them. The “time” utility on the command-line should be sufficient to judge the efficiency of parallelization at this scale (four times more cores should have an easily measurable impact if the software does indeed scale). Here is an example, running the test program used in the video:


To try your own program on this platform, first locate a suitable C-language or C++-language program that uses multiple threads and runs on Linux using pthreads. The program could be a single C file, or a more complex setup involving makefiles and configuration – it should not matter.

To get your software going on the demo platforms, follow these instructions:

  • Set up an account on Lab Cloud (by going to https://lab.cloud.windriver.com)
  • Start a New Session using either 2-core or 8-core, just look for the icons in the list of platforms.
  • Once a session is set up, start it using the “play” button
  • Once it has started, use the “upload” button to upload your C file or archive of a program. Alternatively, use wget or curl to retrieve an archive from some location on the Internet.
  • Unpack the archive once it has been uploaded.
  • Build the program just like you would build it on your host – configure, make, etc.
  • Once the program has built, time runs using the “time” command, just like shown in the screenshot above. “time <program name and parameters>”.
  • If you have a thread-count parameter, try different values to check scaling using the 8-core target. For programs that try to use the entire host, compare the time on a 2-core and 8-core target. Note that user time tends to stay fairly constant, while the real time will change as the thread count changes.

Happy hacking!

To read more about what you can do with Lab Cloud, please read our previous blog posts:



Tweet about this on TwitterShare on Google+Share on FacebookShare on LinkedInEmail this to someone