hardware-level model elaboration igal yaroslavski, m.sc. ([email protected]) senior team leader...

Hardware-level model elaboration

Igal Yaroslavski, M.Sc. ([email protected])Senior Team Leader - MATLAB & Simulink Application EngineeringSignal Processing and Communication, HDL Code Generation and Verification, FPGA workflow Systematics Limited

Agenda

• Background• From behavioral to HW-level modelling• HW-level modelling and beyond• Integrated SW-HW modelling for Xilinx Zynq

HW project completion trendsIn 2011, Wilson research Group conducted the largest verification study ever. The study had statistical confidence of 95 ± 1.4% here’s what it showed about the hardware project completion schedule:

More than 65% of the hardware projects are completed behind the schedule!

HW project design complexity

• Mean number of gates > 6 M• Mean number of embedded

processors 2• Mean number of clock domains per

chip > 3

Design houses’ response

• External code acquisition growth by 138%

• Adoption of advanced verification methodologies

• FPGA and Emulation prototyping

Verification effort

• 56% of the project time is spent in verification

• 58% increase in verification engineers

• Logic flaws account for >50% bugs

Agenda

• Background• The flow: From behavioral to HW-level• HW-level modelling and beyond• Integrated SW-HW modelling for Xilinx Zynq

Digital hardware design flow: PastSo, how did we do it back in 80-90s?We would have a spec documents (lot and lots of pages) based on which 2 teams would code. One team would be the Design Team, it would be responsible for the actual “production code” so in addition to the functional correctness of the code, the Design Team would consider timing and footprint issues of the code they write. The other team would be the verification team. That team, would be responsible for the verification environment, with the test vectors, output checkers / assertions, reference design if needed and the pre-post simulation scripts.

Functional Verification(Logic simulators, test vectors, pre / post-simulation scripts)

Specs/Requirements (visio, doc, pdf, etc…)

Logic Design(Verilog / VHDL code writing)

An immediate drawback is that direct “spec to production” code design of DSP intensive algorithms may result in numerous algorithm design changes, which would be performed directly in “low” level production language. Which may lead to time waste or “over engineered” design that uses more resources than the minimum needed.





Behavioral Simulation(MATLAB / Simulink / C /

Pyton / etc)

Digital hardware design flow: PastSpecs/Requirements (visio, doc, pdf, etc…)

Enter behavioral algorithm design in MATLAB/C, 90s-2000sNow we have an additional team, Algorithm designers, who are responsible of designing the algorithm to requirements and validation that the algorithm “performs” as expected. They would run “what if” scenarios to make sure that the algorithm does not fail for reasonable conditions. After the algorithm is ready, they would pass it, together with the specs to the Design and Verification teams. The Design tem would design like before, but ideally they would not have to make sure that the algorithm they design is valid, only that it’s functionally correct and has acceptable performance. The Verification team would sometimes use the behavioral algorithm for reference and/or test vector generation and analysis.

The challenge: The algo team provided an “ideal” floating point algorithm, with no consideration to footprint or timing performance. Digital Design team, designs under strict footprint and performance limitations. Consequently, some algorithms that work in “behavioral” case may fail in implementation, forcing re-design effort.




Pyton / etc)

Digital hardware design flow: PresentSpecs/Requirements (visio, doc, pdf, etc…)



Bit exact simulation(MATLAB / Simulink / C /

Pyton / etc)

Enter bit exact / fixed point algorithm design, 2000s-nowFor last decade (give or take 3 years) the leading Algorithm Design teams design their algorithms with fixed-point math limitations in mind. The algorithms are designed in a way that compensates for “precision loss” that is inherent to the fixed point mathematics. The reference code, as well as detailed algorithm specs passed to the Hardware Design team already contain bit budget and some degree of resource utilization information. The reference design passed to the Verification Team is also more useful, as in some cases it allows for direct bit-exact verification of the Design Under Test using the bit-exact algorithm as a reference or using it as a direct generator and bit-exact analyzer of the output vectors.

The challenge: While fixed point math issues are addressed, the timing, the data latency, and component delays are not addressed in the Simulation. HW Design team works hard to fit algorithm “bar” under strict limitations they have.


Pyton / etc)

Digital hardware design flow: FutureSpecs/Requirements (visio, doc, pdf, etc…)

Bit exact simulation(MATLAB / Simulink / C /

Pyton / etc)


Logic Design(Verilog / VHDL code writing)Cycle exact (HW) simulation

(MATLAB / Simulink / C / Pyton / etc)



Cycle & bit accurate model elaboration, Today – Tomorrow.Cycle accurate, hardware-like modeling performed after the bit exact algorithm design allows us to take into simulation consideration many of the actual implementation parameters. E.g. the latency/delay of certain components can influence the way the “data valid” signal is generated or propagated between the units. That signal can, in turn change the way the algorithm behaves. Furthermore, accounting for the component availability or limitations can influence the design as well e.g. usage of single or dual port RAM banks and etc. In addition, cycle & bit exact modelling allows us the automatic generation of verification environment and production design components (Next Section)

The challenge: Train Algorithm Design team to consider cycle accuracy OR equip Hardware Design / Verification Team with adequate tools for cycle & bit accurate model elaboration, to be done prior to the “production” coding / DUT verification.

Agenda


Who elaborates the model to HW-levelThe Digital hardware design slide describes a challenge: “Train Algorithm Design team to consider cycle accuracy OR equip Hardware Design / Verification Team with adequate tools for cycle & bit accurate model elaboration, to be done prior to the “production” coding / DUT verification”But, who should elaborate bit-exact model to HW-like cycle exact level, the Algo Team the Hardware Design Team or maybe some other team? The answer is…It depends on:• What is the required elaboration level (Next Slide) and what team possesses the

skills needed to elaborate the model to that level • What is the intended use and who should it serve. E.g. If the use is to provide a

rapid FPGA prototype for a “new and thrilling” idea of the CTO Algo Team, then they are more likely to do the proof-of-concept job in-house, rather than wait for the Hardware Design Team resources to be granted for the initiative.

HW-level model elaboration degreeThe next reasonable question is: To a what degree the HW-level model should be elaborated. The answer is… It depends on:• The level of fidelity you are required to simulate. e.g. do you need

to simulate individual gates and Look Up Tables or a hardware-like function with the latency is sufficient. Do need to simulate the peripherals e.g. memory blocks or interfaces, or streaming data I/O is sufficient

• The use you are going to make of the model. Is it to be used as a reference design, a test bench/harness, or for a “live” a prototype or an actual production (Next Slide)

Beyond HW-level model usage options

Cycle exact (HW) simulation(MATLAB / Simulink / C / Pyton / etc)

Functional VerificationEDA simulators, test vectors, pre / post-simulation scripts


Now, that we know where the Cycle & Bit exact model connects to our Design Workflow, let’s see what are the use options that we get from it.

Verilog / VHDLReference, Prototype or Product

level RTL generation

FIL VerificationTest harness generation for

Shelf or Custom FPGA Boards

System C / System VerilogReference generation for

UVM / other methodologies

Beyond the Logic Design to Verification steps discussed earlier, the existence of the HW-level (cycle & bit exact model) enables the generation of:• FPGA in the Loop test harness for fast function and timing verification• System C and System Verilog reference for UVM/Other verification methodologies• RTL Verlog / VHDL code for reference, prototype or production

Agenda


Zynq Design Challenge

ARM Processor

C-CodeSoftware

Interface

FPGAHDL CodeHardware

Zynq Design Challenge - ARM

Properties:• Typically programmed in C• Often runs a Linux-based operating system• Well-established workflows exist

Challenges:• FPGA Designers are not familiar with processor programming• What should run on the processor vs. the FPGA?

ARM Processor

C-CodeSoftware

Zynq Design Challenge - FPGA

FPGAHDL CodeHardware

Properties:• Typically programmed in VHDL/Verilog• Established workflows exist

Challenges:• DSP/Processor programmers are not familiar with FPGA Design• What should run on the FPGA vs. the processor?

Zynq Design Challenge - Interface

Interface

Properties:• Zynq uses “standard” AXI interface between FPGA and ARM

Challenges:• No established rules for hooking up the interface• Different “flavors” of AXI for different bandwidth requirements

Integration, Test & Certification

Traditional Design of a HW/SW System

Research & Requirements

Hardware

Requirements

Design

Realization

Testing

Software

Requirements

Design

Realization

Testing

The problem:The testing of the HW/SW integration is performed in the late stage

Zynq Design Challenge – Solution?

So, how can we address these challenges and get our project onto Zynq quickly?

• Model-Based Design provides a single environment from requirements to prototype

• A guided workflow for hardware and software development INTEGRATION

IMPLEMENTATION

DESIGN

TE

ST

& V

ER

IFIC

AT

ION

RESEARCH REQUIREMENTS

ARM FPGA

VHDL, VerilogC, C++

Environment Models

Physical Components

Algorithms

Model Based Design Flow for Zynq

User defines partitioning

MathWorks automates code and interface-model generation

MathWorks automates the build and download through the Xilinx tools

INTEGRATION

IMPLEMENTATION

DESIGN

TEST & VERIFICATIO

N

RESEARCH REQUIREMENTS

ARM FPGA

VHDL, VerilogC, C++

Environment Models

Physical Components

Algorithms

Integrated HW / SW design flow

HDL IP CoreGeneration

MATLAB® and Simulink®

Algorithm and System Design

Simulink Model

SW

HW

Programmable Logic IP Core

Algorithmfrom

MATLAB/Simulink

AXI LiteAccessibleRegisters

AXI4-Stream Video In

AXI4-Stream Video Out

External Ports





Embedded SystemIntegration

Zynq Platform

FPGA Bitstream


Algorithmfrom

MATLAB/Simulink




External Ports

Xilinx Embedded System Project

AX

I 4- L

it e

ProcessingSystem


Algorithmfrom

MATLAB/Simulink


AXI Video DMA



External Ports







Zynq Platform

FPGA Bitstream

SW Interface Model Generation

SW Build

Simulink Model

SW

HW

SW Interface Model

SW

SW I/O DriverBlocks








Zynq Platform

SW BuildFPGA Bitstream

External ModePIL

Real-time Parameter Tuning and Verification

– External Mode

– Processor-in-the-loop

More probe and debug capability in the future


Zynq Work Flow Advisor

Questions?

hardware-level model elaboration igal yaroslavski, m.sc. ([email protected]) senior team leader...

Documents