Xilinx Targets Embedded Software Developers with SDSoC - Embedded.com

Xilinx Targets Embedded Software Developers with SDSoC

It appears that Xilinx has discovered the “Holy Grail” with regard to embedded systems development — the ability to create a high-level representation of the system and to then quickly and easily decide which portions are to be implemented in software and which are to be realized in hardware. Furthermore, to have this solution presented in such a way that software developers can use it without having to call in their hardware counterparts.

There are several reasons why such a solution is important, not the least that there are many more software developers than hardware design engineers; also that the number of software developers coming out of university far outweighs the numbers of hardware designers.

There are, of course, many different types of software. In the case of higher-level applications, there could be 1,000 to 10,000 software developers for every hardware designer. In the case of embedded systems, this ratio is probably more like 10-to-1, but that's not insignificant, especially if Xilinx can now make their programmable logic technology easily accessible and usable by the “10” in addition to the “1.”

Let's start by considering the processing and computation performed by a generic embedded system. Generally speaking, we can divide this into control-oriented, decision-making tasks on one side of the fence, contrasted with algorithmic, data-processing tasks on the other.

Still speaking generally, processor cores are well-suited for performing control-oriented, decision-making tasks. However, processors are extremely inefficient when it comes to many algorithmic, data-processing tasks, which are better served by using massively parallel hardware accelerator cores.

One solution is to use a programmable SoC, such as the Zynq from Xilinx. These devices boast a mix of processor cores and programmable logic fabric; also on-chip memory, a wide variety of hard core communication and peripheral functions, high-speed data interfaces, and a large number of general-purpose inputs and outputs (GPIO).

As an aside, the current generation of Zynqs offers 32-bit dual core ARM Cortex-A9 processors; the next generation boasts 64-bit quad core ARM Cortex-A53 processors augmented with 32-bit dual core ARM Cortex-R5 real-time processors and an ARM Mali-400MP graphics processor (see {doclink 1325799}), but we digress…

It's very common to start a new design by creating high-level software representations of the various functional elements comprising the system. The next step is to profile this system to see which functions consume the most processing resources and time. In a traditional design flow, these functions are handed over to the hardware design team to be re-implemented as hardware accelerators. Oftentimes, iteration is required in which various interfaces between the software and hardware are evaluated (different types of data may require different interfaces in order to achieve optimum performance).

It has long been the dream for the system architects and the software developers to be able to simply select one or more functions in the design hierarchy, and to then “toggle” them to say “implement this function in software” or “realize this function in hardware.” Unfortunately, this is not a trivial task, not the least that an appropriated interface has to be implemented in the hardware and a corresponding driver has to be created in the software.

People have been talking about wanting this capability for 20 or 30 years, but it simply wasn't possible… until now. The enabling technology is High Level Synthesis (HLS), which can take a high-level representation in C/C++ and compile/synthesize it into an equivalent RTL (register transfer level) representation that can subsequently be used by traditional synthesis technology to generate the ultimate hardware realization.

Starting in 2014, Xilinx has been introducing a series of SDx development environments, where “SD” stands for “Software Defined.” March, 2014, saw the introduction of 'Softly' Defined Networks in the form of SDNet, which provides a high-level specification environment for software-defined data plane programming. In November, 2014, Xilinx announced Software Defined Acceleration in the form of SDAccel, which provides an OpenCL, C, and C++ environment delivering a CPU/GPU-like programming experience on FPGA accelerators. Now, Xilinx has introduced the concept of a Software Defined SoC in the form of SDSoc, which provides a C/C++ environment delivering an ASSP-like programming experience for software engineers and platform developers.

We start by creating a high-level C/C++ model of the system, upon which we perform system-level profiling to determine those functions that will most benefit from hardware acceleration. Of particular interest is the fact that the environment is based on the Eclipse IDE, which is familiar to software developers. Instructing the environment as to which functions should be implemented in hardware is as easy as right-mouse clicking on that function and toggling between hardware (HW) and software (SW).

In the image above, observe that the highlighted function is currently going to be implemented in hardware, as is indicated by the “[H]” annotation. The system automatically evaluates the type of data to be communicated and implements an appropriate interface in the hardware and a corresponding driver in the software.

The thing that makes this so useful for system architects, platform architects, and software developers is that so much of the magic happens “under the hood.” Following the initial system-level profiling run, once one or more functions have been targeted for hardware implementation, a fast synthesis is performed unseen by the user. As part of this, the system automatically instruments the hardware portions of the system so that — in subsequent profiling runs — the users can be presented with cycle-accurate software/hardware performance and hardware utilization data, including cache, memory, and bus utilization.

It's important to note that, at the time of this writing, SDSoC has been in Beta with select real-world users for over a year, which provides a high-level of confidence that this development environment is ready for “prime time” usage. Speaking of which, a number of SDSoC-enabled Zynq development platforms are available today: ZC702, ZC706, ZedBoard, MicroZed, and ZYBO.

The existing suite of development boards is soon to be augmented with market-specific platforms, — such as software-defined radio (SDR) and Video/Imaging — from Xilinx Alliance partners.

Early access to the SDSoC development environment is available now! You can learn more at www.xilinx.com/sdsoc.

24 thoughts on “Xilinx Targets Embedded Software Developers with SDSoC

  1. “I don't know about you, but if this works as well as the folks at Xilinx say it does, then it's going to be a real game-changer. There are so many software developers who could really benefit from using hardware acceleration to boost their code. 100X spee

    Log in to Reply
  2. “@Max: An interesting article. nI must say I think this is the way forward for a lot of development cycles. nAs a very early hardware TTL blocks user turned software jockey, I have found FPGA development difficult, you know to your cost how many problems

    Log in to Reply
  3. “Tool vendors, particularly FPGA tool vendors try to shoe-horn everything to work via their IDEs.nnForcing software engineers to use FPGA tools is a completely broken concept.nnAltera, for instance, require that you build a dummy FPGA image just to get

    Log in to Reply
  4. ” I find the following statement to be a bit misleading:nn”also that the number of software developers coming out of university far outweighs the numbers of hardware designers.”nn Only a small minority of these “Software Developers” are Embedded

    Log in to Reply
  5. “This is an Eclipse based environment that “sits on top” of the Xilinx SDK”.nnOne of the things I didn't mention is that the hardware guys can go in first and configure things to provide a standard “platform” that the software guys can they use with

    Log in to Reply
  6. “Well, I totally agree that there's a big difference between embedded software developers and the Windows/Web folks — but notwithstanding that, I think my point stands that a lot more folks come out of university knowing (or thinking they know) software

    Log in to Reply
  7. “There was a lot to be said for learning how to program in assembly back in the early days when memory was small and you fought over every clock cycle — I still use the tricks I learned back then to this day.nnIt scares me that so many younger programme

    Log in to Reply
  8. “So, this sounds very much like the EDK (Embedded Developers Kit) from years ago. The EDK was borged into the Vivado tools, right?nAnyone know if it supports building BSP and tools for RTOS? How about getting the drivers setup for Linux?nIf it has a tool

    Log in to Reply
  9. “My understanding is that they have the drivers for Linux and an RTOS — with other OSes coming on line soon.nnI will ask the folks at Xilinx to leap into the fray and answer these questions.”

    Log in to Reply
  10. “The “holy grail” expression applies perfectly: it's a myth. SDAccel is a nice story, as “ready for prime time” as High-Level Synthesis has been for a good decade now. I am ready to believe that it will nicely detect that your multiply-accumulates shou

    Log in to Reply
  11. “just started to look at the development kit prices that can be used with SDSoC. nWell that's another kit that won't get bought on a retirement pension. “

    Log in to Reply
  12. “@Crusty: There is a free tool that will let you design as if you were using TTL blocks. Instead of drawing a schematic, simply define Boolean(bool) variables and then define the logic using Boolean Algebra. You can then observe the values as if you wer

    Log in to Reply
  13. “Finally some progress in this direction. I happened to be on an SoC-related research project about 3 years ago and being a model-based design person, I suggested we needed a tool like this to help with mapping designs to the platform and understand the pe

    Log in to Reply
  14. “I agree — I remember in the 1980s when we created our designs as gate/register-level schematics. When language-driven design (LDD) came along in the form of hardware description languages (HDLs) and register transfer-level (RTL) descriptions coupled wit

    Log in to Reply
  15. “The features of Xilinx EDK were essentially subsumed into Vivado tools suite. In that transition, users gained many features while retaining the large majority of EDK features, including what is highlighted by dougwithau above. EDK (and Vivado) will autom

    Log in to Reply
  16. “What I would call the “Holy Grail” is automatic hardware/software partitioning, and we're not there yet.nnI don't see how SDSoC, which appears to be a wrapper around Vivado HLS, will enable software developers to design efficient hardware. But the sy

    Log in to Reply
  17. “Same with our RSoC Framework. I can see that there are more companies which address “pains of Xilinx” — i.e. looking for some reasonable solution “before SDSoC” :-)”

    Log in to Reply
  18. “its far from holy grail, I'm both software and hardware designer. seem HLS can only do a good job for small chunk of C code. the designer still has to understand some hardware concept in order to use pragma to optimize the C code. and if that part of c

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.