Hardware-level model elaboration

1. Hardware-level model elaboration Igal Yaroslavski, M.Sc. (igal@systematics.co.il) Senior Team Leader - MATLAB & SimulinkApplication Engineering Signal Processing and Communication, HDL Code Generation and Verification, FPGA workflow Systematics Limited

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

3. 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!

4. HW project design complexity • Mean number of gates > 6 M • Mean number of embedded processors 2 • Mean number of clock domains per chip > 3

5. Design houses’ response • External code acquisition growth by 138% • Adoption of advanced verification methodologies • FPGA and Emulation prototyping

6. Verification effort • 56% of the project time is spent in verification • 58% increase in verification engineers • Logic flaws account for >50% bugs

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

8. Digital hardware design flow: Past Specs/Requirements (visio, doc, pdf, etc…) 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. Logic Design (Verilog / VHDL code writing) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) 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.

9. 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. Logic Design (Verilog / VHDL code writing) Logic Design (Verilog / VHDL code writing) Behavioral Simulation (MATLAB / Simulink / C / Pyton / etc) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) 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.

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

11. Digital hardware design flow: Future Specs/Requirements (visio, doc, pdf, 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) Logic Design (Verilog / VHDL code writing) Logic Design (Verilog / VHDL code writing) Behavioral Simulation (MATLAB / Simulink / C / Pyton / etc) Bit exact simulation (MATLAB / Simulink / C / Pyton / etc) Cycle exact (HW) simulation (MATLAB / Simulink / C / Pyton / etc) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) Functional Verification (Logic simulators, test vectors, pre / post-simulation scripts) 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.

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

13. 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.

14. 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)

15. Beyond HW-level model usage options 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. Cycle exact (HW) simulation (MATLAB / Simulink / C / Pyton / etc) Verilog / VHDL Reference, Prototype or Product level RTL generation Logic Design (Verilog / VHDL code writing) FIL Verification Test harness generation for Shelf or Custom FPGA Boards System C / System Verilog Reference generation for UVM / other methodologies Functional Verification EDA simulators, test vectors, pre / post-simulation scripts 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

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

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

18. Zynq Design Challenge - ARM • ARM • Processor C-Code Software • 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?

19. 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?

20. Zynq Design Challenge - 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 Interface

21. Traditional Design of a HW/SW System Research & Requirements • Hardware • Software Requirements Requirements Design Design Realization Realization Testing Testing Integration, Test & Certification • The problem: • The testing of the HW/SW integration is performed in the late stage

22. 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 RESEARCH REQUIREMENTS • DESIGN Environment Models Physical Components TEST & VERIFICATION Algorithms • IMPLEMENTATION C, C++ VHDL, Verilog ARM FPGA INTEGRATION

23. Model Based Design Flow for Zynq RESEARCH REQUIREMENTS User defines partitioning • DESIGN Environment Models Physical Components MathWorks automates code and interface-modelgeneration Algorithms TEST & VERIFICATION • IMPLEMENTATION C, C++ VHDL, Verilog MathWorks automates the build and download through the Xilinx tools ARM FPGA INTEGRATION

24. Integrated HW / SW design flow MATLAB® andSimulink® Algorithm and System Design • HDL IP Core • Generation • HDL IP Core • Generation

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

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

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

28. Zynq Work Flow Advisor

29. Questions?