Today’s engineering disciplines are being thrown together into single devices and therein lies one of the biggest challenges facing the industry today - how do you develop and debug an entire system in a single chip?
It seems like natural progression – cramming more into increasingly capable devices. Transistor sizes shrink, silicon becomes more turnkey and you get more device for your buck but what doesn’t shrink is the expertise that’s required to develop these complex devices.
Systems used to be designed by groups of engineers. Integration and test engineers waited on the developers and toes tended to get trodden on, with hidden code picked apart and untouchable historic designs questioned - all for product development. There was certainly no room for ego!
Today, favourite tools may be replaced by those common to the technologies inside a device. Xilinx Zynq devices have two debug ports to allow individual debugging of the Processor Section or Programmable Logic. On Zynq you can chain these ports into one, so tools that are aware of both worlds deliver greater insight. Other devices may only offer specific insight. Vendors will offer a toolset to work with this, but it may be different to what people are used to. Suddenly, this new wonder-device to solve everyone’s design problems is upsetting the engineering apple cart across all engineering disciplines.
One approach is to increase the visibility of some internal sections. Application processors can log more, real-time processors can show events occurring on IO or serial lines, FPGA logic can flag up states and events. With more now handled internally on a heterogeneous device, this frees up what would have been interconnecting busses on the device pins. By making it easier for someone without specialist tools and knowledge to understand when something goes awry, problems can be directed to the appropriate developer.
Can one engineer handle heterogeneous designs? Yes, if they understand the system intention and expected operation. Silicon vendors know this and provide tools to help where possible.
There is a risk as the more a tool automates a task for you, the less is understood. Trying to manually configure and control your system would be a massive task. There is more going on inside these complex devices than your platform needs. Wizards are a great productivity boost, until the point that something goes wrong, and you dig into something you did not create.
Creating a heterogeneous system with minimal people is possible. The trick is good engineering in all areas. Easy to say, hard to do and harder still to explain to a project manager.
Progress will be slow as problems in one area will hold the project up, putting pressure on timescales. Don’t expect fanciful and clever designs. Simpler is better. There is a lot to do just getting the basics up and running.
Consult engineers early in the design process. It can’t be left to project managers who see a heterogeneous device as a short-cut. Both disciplines spend time writing, developing and testing code. They maintain code repositories, perform simulation/emulation and debugging. As soon as hardware is available, the system can be almost ready.
The same cannot be expected of FPGAs. “Reconfigurable hardware” is not about “sorting this out afterwards.” Even worse would be to deliberately plan to have a hardware design with an empty FPGA, assuming that whatever is wanted will fit. It won’t!
Managing security
Security can seem to get in the way of the simplest things. The pressure to get life from a new system is huge. There is a temptation to ignore designing in security features from the start. Working within security restrictions feels difficult, but is the correct thing to do. If we circumvent things now, it’ll never be put right afterwards.
A downside to heterogeneous devices is their ‘attack surface’ can be larger with more potential entry points, especially when moving to a complex system rather than squeezing one into a smaller space. With many types of engineering design at play, real collaboration is required rather than meeting specifications. Don’t assume inwards-facing interfaces provide security from the outside.
The maker community also has a part to play in this story. Adding a rich OS into a system, isn’t the same as bolting a Raspberry Pi with something. This growing community, with systems such as Raspberry Pi and Arduino, along with complimentary kits such as ShieldBuddy, should be welcomed. Hobby electronics was dying as the interesting components are too small to be built with at home so add-on shields have addressed this, enabling a new generation of engineer. Yet it may be glossing over the complexities and subtleties of a real design. Raspbian, the Raspberry Pi operating system, is akin to a desktop computer experience to help people on their way. With a single command line, a complete webserver can be downloaded, installed and started.
Embedded Linux is a different world with many books dedicated to it. As a rule of thumb, if you can’t already do everything you want from a command line, it’s not for you. Very little is instantly available, and everything gets built from the ground up. Great strides have been made to automate the building of custom embedded Linux distributions with the likes of the Yocto Project. This builds itself and the tools required before building for your target.
Above: Complementary kits, such as the Shieldbuddy TC375 should be welcomed
Silicon vendors offer a step-up in trying to build Linux for their device, and may offer a pre-built image to boot from. This will need modifying for your needs. It’s amazing how many common command-line tools don’t show up by default. Don’t be fooled into thinking moving from a Raspberry Pi to another platform will be straightforward.
Even the world of classic embedded microcontrollers and embedded Linux are poles apart. Tools and techniques are available for each, but they differ. The GNU/Linux world evolves as software packages go in and out of fashion. Keeping up with this is a full-time job in itself.
There are tasks engineers cannot do. Specifically, they are not product designers. Enter the artists – graphic designers, musicians, animators… With high expectations on user experience, these people are crucial to your product image.
Engineering and artistry
Normally engineering and artistry are kept apart, with the occasional curious crossover. If product presentation is key, then a good multimedia framework is essential, along with the tools to bridge art and code. Qt is one such framework with tools that can import from Adobe Photoshop.
One project I worked on needed graphical display, webserver over Ethernet, local filesystem and real-time capabilities. One option was a single powerful Cortex-M microcontroller: lean and compact with a low BoM cost plus an RTOS and Keil middleware blocks. The graphical application was developed by the customer. But it was becoming restrictive. They would either have to rebuild the entire system each time, have their application in a mini filesystem, or divide up flash memory.
A heterogeneous alternative of Cortex-M for real-time operations and Cortex-A for Linux together was preferable. The top-level application was developed separately on a desktop PC and graphics were easily changed and uploaded, giving the web developers a familiar working environment. With both Cortex-A and -M being available in a single device, the PCB size was kept to a minimum.
Heterogeneous devices can be wasteful with features, but deliver greater flexibility in development, architecture and costs. It is rare to utilise every section of a complicated chip, and you shouldn’t try.
What makes a successful heterogeneous project:
• Get a good group of people together, not just good engineers.
• Create a functional platform along with any key multimedia elements. New features and shiny bells and whistles can be added later.
• Avoid specification creep. As soon as Linux or FPGA is mentioned, people start dreaming!
• Constrain it to ‘your’ platform. Planning too many future options will never deliver a good platform for the essentials.
• A dedicated technical project leader will steer the project in a clear direction.
• Use tools able to handle the different sections as a whole. For a mix of Cortex-A and Cortex-M work, Arm Developer Studio is ideal.
Heterogeneous devices are here to stay. At the end of the day, it’s critical that hardware, software, project managers, senior developers, junior engineers, and dare I say it – marketing, all working towards one goal.
Author details: Colin Funnell is a Development Engineer, Hitex (UK) Ltd
