Our History of Embedding MathWorks Design Flows: How and ... · MATLAB EXPO 2016 Switzerland Zentrum Paul Klee, Bern, 23 June 2016 8 Adoption of new Technology New technology is usually

Enclustra GmbH

Technoparkstr. 1 – CH-8005 Zürich – Switzerland

Phone +41 43 343 39 43 – www.enclustra.com

Our History of Embedding MathWorks Design Flows: How and Why We Use Them

MATLAB EXPO 2016 Switzerland

Zentrum Paul Klee, Bern, 23 June 2016

1

Enclustra GmbH






2

Enclustra GmbH






3

Enclustra GmbH






4

Enclustra GmbH






5

Enclustra GmbH






6

Short Profile

Enclustra is a dynamic, innovative and successful FPGA design service company located in

Zurich, Switzerland.

Our FPGA engineers have in-depth knowledge in various application areas like software

defined radio, drive control, digital signal processing and data acquisition systems.

Investing in employee training and keeping critical knowledge up to date on a regular

basis enables us to find ideal solutions at a minimal expense for our clients.

We’re vendor-independent, and we’re design service partners of Xilinx®, Altera® and

Lattice Semiconductor – this close communication allows us to be forward-looking in our

design process, and remain on the cutting edge of the most advanced FPGA technology.

Enclustra GmbH






7

Enclustra GmbH






8

Adoption of new Technology

New technology is usually adopted to benefit from its increased capabilities. Even though

there is often some benefit provided by the technology alone, the benefits can be

multiplied by adjusting the methodology to the new technology.

Let’s take the replacement of the good old typewriter by computers as an example.

Certainly there is some benefit from just using the computer: Multiple copies of

documents can be printed and work can be stored in other forms than paper, which is no

long-term solution. However, if one still re-types a whole table to just add one row in the

middle (as it was required with a typewriter), big advantages of the new technology are

unused. The same applies for documents which can easily be edited without re-typing –

this was simply not possible in the past.

As a result we changed our methodology. Lists are not growing only at the bottom end

today but are most likely alphabetically sorted and new lines are inserted somewhere in

the middle accordingly. Completely new concepts like the “living document” which is

refined during a whole project popped up and help to improve our efficiency as well as

the quality of results. This nicely shows that the computer not only has replaced the

typewriter in a better way but that we also had to change the methodology to fully profit

from the new features.

On the other hand new technology also rises new problems. Nobody had to care about

anti-virus software for a typewriter.

You are wondering why new technology is emphasized so much? Remember all that

applications where MCUs, DSPs and analog electronics get replaced by FPGAs and SoCs?

Enclustra GmbH






9

FPGAs suffer from Poor Visibility

One of the main problems when prototyping FPGA projects is the very limited visibility in

the error case, even if the error is perfectly reproducible. For processors, single-stepping

through the code and analyzing the content of each variable after every step is possible

and breakpoints can be set. In analog electronics signals can be measured using a scope.

FPGAs don’t provide such kind of an inherent visibility.

There are logic analyzers which can be compiled into an FPGA design to observe what is

happening inside the chip. However, these analyzers have very limited memory and with

compile times of hours, routing an additional signal to the logic analyzer can be quite time

consuming.

When the event of failure could be caught using the logic analyzer, data is often not so

easy to interpret since it is not valid all the time, multiple samples are processed in parallel

or several channels are processed one after the other using the same FPGA resources.

This is a big contrast to software debugging where data is often available as an array and

can be copied away for analysis easily.

Enclustra GmbH






10

Accessibility

Most specialists for signal processing, control theory or other areas where FPGAs are

commonly used are familiar with software development tools as well as the programming

languages C and C++. For software written in these languages, they can analyze problems

on their own and try different modifications in fast iterations.

Unfortunately application specialists are often not familiar with HDL languages and FPGA

tools. Therefore an implementation specialist is required to help capturing data for analysis

and implement changes suggested by the application specialist. This slows down the

development cycle and also introduces more risk for misunderstandings because of the

required communication between the application specialist and the FPGA implementation

specialist.

HDL code generation from more accessible languages such as MATLAB/Simulink® or C

can ease this problem. However, code generation is not applicable in many cases and even

if code can be generated, the FPGA tool flow may involve hand-placement and timing

optimization, which again requires effort of the implementation specialist.

Enclustra GmbH






11

Enclustra GmbH






12

Requirements Specification

The requirements specification phase usually starts with a loose collection of functional,

performance, environmental and user requirements, which are then compiled into a

comprehensive requirements specification. This process usually is driven by the customer‘s

application specialists.

During this phase, MATLAB and Simulink are often used for first high-level evaluations of

candidate algorithms.

Enclustra GmbH






13

System Design

FPGA system design always involves system partitioning considerations both on the

hardware and on the FPGA firmware level. As soon as the partitioning in algorithm blocks

and other functional blocks is done, the algorithm and detailed architecture designs can

be started. Pin assignment as well as clocking and reset strategies are parts of this phase

as well.

MATLAB and Simulink are heavily used for algorithm design. If automated HDL code

generation is employed, detailed architecture design can also involve MATLAB and

Simulink.

Enclustra GmbH






14

Functional Blocks Implementation

The partitioning of the FPGA design in individual functional blocks (amongst others)

breaks down complexity and enables parallel implementation as well as early functional

verification (i.e. unit testing) of the main building blocks of an FPGA design.

MATLAB and Simulink are most likely used for functional verification of algorithm blocks

(i.e. golden models), but can also be involved in the detailed design and design entry

steps, if automated HDL code generation is used.

Enclustra GmbH






15

Top-Level Integration

This phase consists of the integration of all functional blocks into a complete FPGA design

and of the functional verification of the FPGA design by means of HDL simulation.

MATLAB and Simulink are typically used for generating stimuli and expected responses for

the top-level functional simulations.

Enclustra GmbH






16

Physical Implementation

This phase includes all steps required to transform the created VHDL code into a bitstream

that can be downloaded to an FPGA.

The synthesis step interprets the VHDL code and transforms it into a netlist, which is

composed with the available resources of the target FPGA.

The place and route step physically places the netlist resources on the target FPGA and

physically routes the logical connections between the individual resources.

The static timing analysis step calculates propagation delays, clock skew and jitter, etc. and

assesses whether the physical implementation does meet the timing requirements.

If all previous steps have been completed successfully, a configuration bitstream is

generated and downloaded to the FPGA device on the target hardware.

In-Circuit Verification

In-circuit verification basically means running functional test on the target hardware.

MATLAB and Simulink are typically used for generating stimuli and expected responses

and for acquiring and checking the actual responses during the in-circuit verification.

Enclustra GmbH






17

Enclustra GmbH






18

The Case for Model-Based Design

The development of a modern electronics device such as for example a motor controller or

a signal processing system is very complex and only very few engineers have the know-

how to execute all related tasks. Even if one engineer has all the know-how, the time-to-

market requirements cannot be achieved by a single engineer. This led us to a world with

many different engineers participating on a project: signal processing specialists, FPGA

specialists, hardware specialists, software specialists and many more.

The drawback of this setup is that design cycles are slowed down and risk increases with

every additional engineering discipline involved. If signal processing and control theory

specialists can directly bring their simulation results to hardware and test them in real-

world setups, much development time can be saved. This is the point where model based

FPGA design comes into play.

Enclustra GmbH






19

Components of Embedded FPGA/SoC Systems

To understand what model based design is capable of and what it is not, it is very

important to understand that an embedded system consists of different parts with

different requirements and development processes.

Some parts such as interfaces to sensors and actors are unlikely to change after they are

found to work correctly. The same applies for example to protocol stacks of the host

communication. On the other hand processing algorithms tend to be optimized in many

iterations, sometimes even after the product was delivered to the customer.

Some parts can be described efficiently using high abstraction levels such as Simulink

algorithms or object oriented programming languages like Java. Other parts need to be

realized at a low level. Examples for the second category are sensor interfaces and device

drivers.

From the facts above, it becomes clear that the advantages of model based design (fast

iterations, high abstraction level, less low-level error-proneness) can strongly improve

algorithm development but are useless to many other tasks. Nobody would code a sensor

interface in Simulink, even though it would theoretically be possible.

As a result the expectation to model based design should be to improve the efficiency of

algorithm development and not to allow a signal processing specialist to realize a

complete SoC/FPGA system on his own. Placing the border between model based and

conventionally developed parts of the system at the right place during the initial phase of

the project is crucial.

Enclustra GmbH






20

HDL is no Software

People are often heard complaining about HDL (hardware description language)

development for FPGAs/SoCs being so much less intuitive than writing software for a

conventional processor. Similar complaints are heard for code generation. On one hand

this is really true, on the other hand it is comparing apples to … no, not pears … more

something like elephants. It is comparing software to circuit-hardware. These two things

have completely different levels of complexity and abstraction and also of capability and

efficiency. The fact that HDL code for FPGAs can be viewed and edited in a text-editor

does not mean it is software.

In general, if it can be done in software, all the effort and complexity of the FPGA should

be avoided. But what if it cannot be done in software?

The comparison on the slide may look a bit awkward at the first glance. However, the

mentioned details strongly affect the code generation process and the amount of

interaction required. A tool generating HDL requires way more decisions to be taken by

the user than a tool generating software, just because there are many more levels of

freedom for design trade-offs. Also does an algorithm need to be optimized for a

reasonably efficient implementation in HDL in contrast to a software implementation

(floating-point vs. fixed-point is only one of many examples).

All these points make FPGA/SoC design (even model-based design) looking a bit daunting

but it suddenly looks more attractive when you start thinking about getting 30 GMAC/s

filter performance and beyond from an off-the-shelf device.

Enclustra GmbH






21

Algorithm Designers don’t need FPGA Know-How

The project discussed nicely shows that it is possible to give algorithm designers access to

the vast processing power for FPGAs without forcing them to learn HDL languages or

grapple with FPGA architecture details. This approach significantly speeds up the path

from Simulink algorithm to FPGA implementation and prevents time-consuming

debugging of hand-written HDL code.

On the other hand the example project also shows that there is some work required to

convert a pure Simulink algorithm to one implementable on an FPGA. This work is certainly

doable for an algorithm designer without FPGA knowledge but some effort is required.

The conclusion Enclustra reached is that HDL code generation from Simulink is not as

straight forward and out-of-the box as marketing claims but it is working in real world

projects if a bit of effort is invested to create a good framework.

Enclustra GmbH






22

Design Teams need FPGA Know-How

Even though an algorithm can be developed without FPGA know-how, the framework the

algorithm is embedded in requires FPGA know-how. The main responsibility of the

framework is to connect the algorithm to the outer world with all its proprietary digital

and analog interfaces.

As a result, FPGA know-how is required to successfully realize an FPGA design, even if the

algorithm is developed in a model based manner. As a result electronics design still is a

team sport and not a singles discipline.

On the other hand, a flexible framework can stay unchanged even if the algorithm is

changed significantly. This not only reduces the total overall FPGA design effort but also

allows non-FPGA design teams to continuously use FPGAs after they have a framework in

place without relying on the FPGA specialists anymore.

The project discussed is a success story of exactly this setup. The development of the

framework was outsourced to Enclustra as FPGA design house and can now be reused in

many projects.

Enclustra GmbH






23

Enclustra GmbH






24

MATLAB – The Childhood of Signal Processing Algorithms

MATLAB is a de facto industry standard tool for signal processing algorithm development.

This not only includes the development of the algorithm itself but also the implementation

of stimuli generators as well as functions for result analysis and plotting. If subsequent

processing steps (post-processing) are implemented in other parts of the system (existing

or not) they are often also modeled to judge the overall system performance.

MATLAB as User Interface

By establishing a connection between the FPGA implementation and MATLAB, all the data

analysis functions and plotting utilities written during algorithm development can be

reused to analyze the performance of the real implementation of the algorithm and

compare it to simulations. While the figure only shows the data flow, configuration of the

processing within the FPGA is also controlled from MATLAB.

The approach shown makes the FPGA design accessible to the signal processing specialist.

He can play with different parameter sets and analyze the output directly in MATLAB.

Compared to the standard flow with a proprietary software to control the FPGA design

and import/export data via Files from/to MATLAB this speeds up iterations significantly.

Another advantage is that parameters such as filter coefficients can be calculated directly

in MATLAB and the design considerations leading to a given parameter set are therefore

inherently traceable.

Enclustra GmbH






25

Flexible Measurement Infrastructure

By providing a flexible measurement infrastructure with several data acquisition points,

many time consuming iterations can be avoided. If results are not as expected, the signal

processing specialist can locate the point of failure by simply capturing data at several

points.

The effect of various changes to the algorithm can be tested by capturing data before the

point of failure and execute the rest of the processing (including the proposed changes) in

MATLAB. Again, overall algorithm performance analysis can be done easily by using the

existing infrastructure from simulations. A new FPGA implementation iteration is only

required after the behavior of the changes proposed was verified using the combination of

hardware and MATLAB models shown on the slide.

The setup shown provides several advantages over a pure simulation:

All effects caused by the FPGA implementation of all preceding processing steps are

included

Real-world data that led to the misbehavior can be captured

Tests on hardware are possible before the complete algorithm is implemented

Simulation time can drastically be reduced because parts of the algorithm are executed in

the FPGA at real-time.

The last point especially applies if the part of the algorithm executed in the FPGA contains

any form of data rate reduction.

Enclustra GmbH






26

Regression Testing

In many projects it is desirable to have a regression testing environment which allows

running the same sets of test data after every modification of the system. If the

communication between MATLAB and FPGA is not limited to acquiring data but also

allows injecting data, such regression tests can easily be controlled from MATLAB. In terms

of speed, such a setup outperforms every HDL simulation by factors.

A big advantage of using MATLAB instead of any proprietary software to run such

regression tests is that MATLAB provides a lot of functionality to analyze the output. This

allows analyzing the output in a qualitative way (e.g. statistical analysis, constellation

analysis) which is by far more convenient than a bit-by-bit comparison to expected output

data which will produce many false positives.

Enclustra GmbH






27

Development Risk

The approach of MATLAB based Design significantly reduces development risk. It allows

early testing of critical entities on the hardware by the application specialist. This greatly

reduces the risk of finding problems with the system performance late in the project where

changes can be very costly. The accessibility of the system to the application specialist is

very important since this prevents misunderstandings between application and

implementation specialist from not being detected until late in the project.

The availability of all the algorithms and toolboxes MATLAB provides leads to more

thorough testing.

Enclustra GmbH






28

Development Time

MATLAB based prototypes save a lot of time during the bring-up and debug phase of a

project. They not only lead to faster identification of root causes for problems but also

help reducing the number of iterations required to fix issues. Since those iterations are

quite time consuming for FPGA/SoC projects with their long compile times, this is a very

important advantage.

FPGA/SoC projects are also well known for their long simulation times. By running tests on

hardware and only analyzing results in MATLAB, regression tests times can be significantly

reduced.

Enclustra GmbH






29

Enclustra GmbH






30

Documents

Our History of Embedding MathWorks Design Flows: How and ... · MATLAB EXPO 2016 Switzerland Zentrum Paul Klee, Bern, 23 June 2016 8 Adoption of new Technology New technology is usually