taking labview further into the system level design domain

Taking LabVIEW Further into the System Level Design Domain

Kaushik Ravindranand the NI Berkeley System Diagram team

National Instruments, Berkeley, CA

Ptolemy Mini-ConferenceApril 16, 2009

National Instruments: What We Do

Low-Cost Modular Measurement and Control Hardware

Productive Software Development Tools

Highly Integrated Systems Platforms

Used By Engineers and Scientists for Test, Design and Control

2

The NI Approach – Integrated Platforms

High-SpeedDigitizers

High-ResolutionDigitizers and DMMs

Multifunction Data Acquisition

DynamicSignal AcquisitionDigital I/O

InstrumentControl

Counter/Timers

MachineVision

Motion Control

Distributed I/O andEmbedded Control

Laptop PC PDADesktop PCPXI Modular Instrumentation

Keypad

LCDSound

Acoustics

RFSignal

Battery

Body & ChassisAudioEngineDurability

Tire & Brake SafetyEmissions Electronics

TemperatureMonitoring Waste Monitoring

Process ControlMotor and Valve Control

3

4

Graphical System Design

LEGO Mindstorms NXT“the smartest, coolest

toy of the year”

CERN Large Hadron Collider“the most powerful

instrument on earth”

5

Outline

• Introduction to National Instruments

• System Diagram: background and motivation

• Y-chart based disciplined system design methodology– Formal models– Analysis and optimization– Simulation– Verification

• Summary and directions ahead

6

Virtual Instrumentation

7

Distributed Virtual Instrumentation

Challenge: How to efficiently and productively deploy high performance

applications on these multi-target platforms?

8

Challenge: The Implementation GapApplication trends• 1000’s of parallel tasks• Large node/channel counts• High performance requirements• E.g. streaming DSP applications

Platform trends• 100’s of processing elements• Heterogeneous processors and memories• Distributed I/O• E.g. FPGA targets

Implementation Gap

CLIP

Concurrent Application

Multi-Target Platform

How to map the tasks and data in a concurrent application to the

processing and memory resources in a multi-target platform?

9

System Diagram

A single canvas to clearly model hardware and software to increase user productivity and

application performance

Goal: Make graphical system design of distributed high-speed multi-rate applications on heterogeneous multi-target platforms 5-10x easier than current tools

10

The System Diagram Charter

• Deliver a framework with rich visualization of application and platform and support it with an exploration methodology– Hierarchical composition of mixed models of computation– Single canvas to model hardware and software– Support systems with large node and channel counts– Rapid design space exploration

• Tune for high-speed multi-rate streaming applications with asynchronous IP deployed on heterogeneous multi-target platforms

11

Outline





12

Y-Chart: A Disciplined System Design MethodologyApplication Model (and Constraints) Platform Model (and Constraints)

Analysis and Mapping

Performance Evaluation

Deployment

[1] B. Kienhuis, E. F. Deprettere, P. Wolf, K. A. Vissers. “A Methodology to Design Programmable Embedded Systems - The Y-Chart Approach”. SAMOS, p.18-37, Jan 2002.

Representative formal models

Efficient analysis and optimization

Fast and accurate simulation

Reliable verification

13

Analogy: EDA Design Flow for VLSI CircuitsHDL

RTL Synthesis

RTL

Logic Optimization

Netlist

Physical Design

Library / Module

Generators

Layout

HDL Simulation

RTL Simulation

Gate Level Simulation

Circuit Simulation

Behavior verification

Equivalence verification

Circuit/design rule verification





Courtesy: Prof. Kurt Keutzer, EE244 Lecture 1, UC Berkeley

module Full_Adder (sum, c_out, a, b, c_in); output [3:0] sum; output c_out; input [3:0] a, b; input c_in; assign {c_out, sum} = a + b + c_in;endmodule

module Full_Adder (sum, c_out, a, b, c_in); output [3:0] sum; output c_out; input [3:0] a, b; input c_in; wire c_in2, c_in3, c_in4; Full_adder M1(sum[0], c_in2, a[0], b[0], c_in); Full_adder M2(sum[1], c_in3, a[1], b[1], c_in2); Full_adder M3(sum[2], c_in4, a[2], b[2], c_in3); Full_adder M4(sum[3], c_out, a[3], b[3], c_in4);endmodule

14

Bringing EDA to System Diagram

• Objective: Advance a disciplined (possibly automated) design methodology to help designers evaluate large design spaces and create successful system deployments

• Imperatives for disciplined design– Well-defined abstractions, system-level semantics– Systematic flow from specification to deployment

• Imperatives for automation support– Accurate models and constraints– Efficient analysis, simulation, and verification methods

15

Outline





16

System Diagram Application Model

• Application processes streams of data

• Application is composed of tasks– Tasks differ in rate of data produced and consumed– Tasks differ in rate of executions in time

• Application has real-time throughput and latency requirements on its I/O

Goals: (1) Identify formal multi-rate models relevant to System Diagram(2) Propose intuitive multi-rate representations(3) Support integration with 3rd-party libraries and IP

MoCs for Streaming Applications

17

Expressive Analyzable

Process Networks

Kahn Process Networks

Boolean Dataflow

Static Dataflow

Cyclo-static Dataflow

Homogeneous Dataflow

SHIM

Integer Dataflow

Heterochronous Dataflow

No YesDeadlock and boundedness decidable?

No YesStatic scheduling?

Deter-ministic? No Yes

[1] Edward A. Lee, “Concurrent Models of Computation for Heterogeneous Software”, EECS 290, 2004. [2] Stephen Edwards, “SHIM: A Deterministic Model for Heterogeneous Embedded Systems”, UCB EECS Seminar, 2006. [3] Thanks: Abhijit Davare, UCB.

Synchronous? No Yes

Key trade-off: Analyzability vs. Expressibility

18

Language Design Challenge

• How to constrain application models in SD so that they are amenable to efficient analysis, simulation, and synthesis?

• How to balance expressiveness and analyzability of models in an unified framework?

• How to enable heterogeneity in composition of models?

• How to verify model transformations and refinements?

19

Outline





Static Models, Static Methods• Assume knowledge of workload and

parallel tasks at compile time– Viable for rapid design space

exploration– Useful for fast exploration of

“what-if” scenarios

• Desired properties of static methods– Computationally efficient– Easy problem capture– Flexible and extensible– Near-optimal solutions

P1 P2

P3 P4

a

b

c

Static Task Allocation and Scheduling

Implementation and Performance Analysis

Architecture model

Application modeland profiles

The Mapping Step in theY-Chart Methodology

20

Static Task Allocation and Scheduling• Scheduling problem– Fix each task to a processor– Find start time for each task– Enforce dependencies– Minimize makespan

P1 P2

Makespan = 18(sub-optimal)

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

P1 a b f h

P2 e c d g

Time

a

b

c

d

g

h

fe

3

3

3

7

2 35

6

static-level (v) = delay of longest pathfrom v to a sink vertex

Task a b c d e f g h

s-level 13 10 10 7 11 9 5 6

21

List Scheduling Heuristic

Task Dependence Graph(with execution times)

Platform Model

[1] Gilbert. C. Sih and Edward. A. Lee, "A Compile-Time Scheduling Heuristic for Interconnection-Constrained Heterogeneous Processor Architectures," IEEE Transactions on Parallel and Distributed Systems, 4(2):175-187, 1993.

22

Worst Case Execution Time Analysis

• Problem: Given a G program, fixed target (host, RT, FPGA), and timing estimates of primitive blocks, compute average or worst case execution time of the program on the target

Example: Compute worst case number of cycles for FPGA VIs(assume bounded iterations, no recursive behavior)

23

Related Compile Time Analysis Problems

Multi-targetPlatform

Application /Workload

PerformanceEvaluation

Analysis andmapping

Select hardware components given budget

Verify configuration and wiring

Verify determinism Verify liveness Verify boundedness Verify consistency of

multi-rate applications Verify type consistency Verify interface match

Optimize buffer sizes given throughput

Compute worst case task execution times

Compute cycle delay for FPGA-bound tasks

Compute load balance given throughput

Minimize total communication costs

Schedule communications for fixed task allocation

Compute data layout for fixed task allocation

Estimate throughput given schedule

Verify application and platform constraints

Verify timing constraints Verify equivalence of

design refinements

24

Outline





25

Analysis Methods for System Diagram

Static analysisAnalysis without program execution

(compile time)

SimulationAnalysis based on dynamic execution of

restricted application and platform models

SynthesisAnalysis following full system deployment

Accuracy EfficiencyPerformance Analysis Methods

low

high

high

low

26

Simulation Techniques

Computation

Communication

Untimed Approximate-timed

Cycle-timed

Exact-timed

Untimed

Bus-arbitration model

Implementation model

Hybrid Implementation model

VIs w/ cycle accurate timing + CT timing

VIs w/ cycle accurate timing

Untimed VIs

VIs w/ approximated timing

Specmodel

Target independent, behavioral simulation

Target dependent, timed behavioral simulation

Target dependent, cycle accurate simulation

Target dependent, system-plant co-simulationCycle-

timed

Exact-timed

Approximate-timed

More accurate models, slower simulations

Less accurate models, faster simulations

27

Outline





28

Verification Challenges in the Design Flow

Multi-targetPlatform

Application /Workload

PerformanceEvaluation

Mapping model

Allocation/Scheduling PlatformConstraints

ApplicationConstraints

ApplicationModel

PlatformModel


CLIP

Is the application deterministic and

deadlock-free?

Does the mapping satisfy application and platform

constraints?

Are model refinements equivalent?

Does the implementation meet real-time

performance constraints?

Is the implementation accurate for user-defined and auto-generated testbenches?

29

Outline





30

Y-Chart: A Disciplined System Design MethodologyApplication Model (and Constraints) Platform Model (and Constraints)


Performance Evaluation

Implementation





[1] B. Kienhuis, E. F. Deprettere, P. Wolf, K. A. Vissers. “A Methodology to Design Programmable Embedded Systems - The Y-Chart Approach”. SAMOS, p.18-37, Jan 2002.

31

Directions Ahead

• Improved application and platform models– More expressive models of computation– Accurate static performance models

• Other compile time optimization problems– Communication scheduling and data layout– Deadlock, unboundedness detection

• Simulation and verification support– Untimed/timed system level simulation, FPGA co-simulation– Testbench generation, IP interface verification

• Applications and use cases– RF, radios, mobile communications, real-time control

32

NI Berkeley - Cast and Crew

• Hugo Andrade• Sadia Malik• Mike Rauser• Kaushik Ravindran• Trung Tran• Gerald Wang• Guang Yang

taking labview further into the system level design domain

Documents

labview control design

labview fpga

correctness of labview

labview andease

labview compiler

experimental design

measurement applications

future platforms