Hardware-level model elaboration Igal Yaroslavski, M.Sc. Senior Team Leader - MATLAB & Simulink Application Engineering Signal 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 trends In 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: Past So, 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.

Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Logic Design (Verilog / VHDL code writing) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Logic Design (Verilog / VHDL code writing) Behavioral Simulation (MATLAB / Simulink / C / Pyton / etc) Digital hardware design flow: Past Specs/Requirements (visio, doc, pdf, etc…) Enter behavioral algorithm design in MATLAB/C, 90s-2000s Now 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.

Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Logic Design (Verilog / VHDL code writing) Behavioral Simulation (MATLAB / Simulink / C / Pyton / etc) Digital hardware design flow: Present Specs/Requirements (visio, doc, pdf, etc…) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Logic Design (Verilog / VHDL code writing) Bit exact simulation (MATLAB / Simulink / C / Pyton / etc) Enter bit exact / fixed point algorithm design, 2000s-now For 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.

Behavioral Simulation (MATLAB / Simulink / C / Pyton / etc) Digital hardware design flow: Future Specs/Requirements (visio, doc, pdf, etc…) Bit exact simulation (MATLAB / Simulink / C / Pyton / etc) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Logic Design (Verilog / VHDL code writing) Cycle exact (HW) simulation (MATLAB / Simulink / C / Pyton / etc) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Logic Design (Verilog / VHDL code writing) 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 Background From behavioral to HW-level modelling HW-level modelling and beyond Integrated SW-HW modelling for Xilinx Zynq

Who elaborates the model to HW-level The 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 degree The 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 Verification EDA simulators, test vectors, pre / post-simulation scripts Logic Design (Verilog / VHDL code writing) 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 / VHDL Reference, Prototype or Product level RTL generation FIL Verification Test harness generation for Shelf or Custom FPGA Boards System C / System Verilog Reference 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 Background From behavioral to HW-level modelling HW-level modelling and beyond Integrated SW-HW modelling for Xilinx Zynq

Zynq Design Challenge ARM Processor C-Code Software Interface FPGA HDL Code Hardware

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-Code Software

Zynq Design Challenge - FPGA FPGA HDL Code Hardware 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 TEST & VERIFICATION RESEARCH REQUIREMENTS ARMFPGA 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 & VERIFICATION RESEARCHREQUIREMENTS ARMFPGA VHDL, VerilogC, C++ Environment Models Physical Components Algorithms

Integrated HW / SW design flow HDL IP Core Generation Generation MATLAB ® and Simulink ® Algorithm and System Design MATLAB ® and Simulink ® Algorithm and System Design HDL IP Core Generation Generation

Generation Generation MATLAB ® and Simulink ® Algorithm and System Design MATLAB ® and Simulink ® Algorithm and System Design Embedded System Integration Integration Zynq Platform FPGA Bitstream Xilinx Embedded System Project A X I 4 - L i t e Processing System Programmable Logic IP Core Algorithm from MATLAB/ Simulink AXI Lite Accessible Registers AXI Video DMA AXI4-Stream Video In AXI4-Stream Video Out External Ports Embedded System Integration Integration Integrated HW / SW design flow

HDL IP Core Generation Generation MATLAB ® and Simulink ® Algorithm and System Design MATLAB ® and Simulink ® Algorithm and System Design Embedded System Integration Integration Zynq Platform FPGA Bitstream SW Interface Model Generation SW Interface Model Generation SW Build SW Interface Model Generation SW Interface Model Generation Integrated HW / SW design flow

HDL IP Core Generation Generation MATLAB ® and Simulink ® Algorithm and System Design MATLAB ® and Simulink ® Algorithm and System Design Embedded System Integration Integration SW Interface Model Generation SW Interface Model Generation Zynq Platform SW BuildFPGA Bitstream External Mode PIL PIL  Real-time Parameter Tuning and Verification – External Mode – Processor-in-the-loop  More probe and debug capability in the future Integrated HW / SW design flow

Zynq Work Flow Advisor

Questions?