DSP Design Flows in FPGA

1. DSP Design Flows in FPGA ECE 992 Spring 2007

2. Objectives Describe the advantages and disadvantages of three different design flows Use HDL, CORE Generator, or System Generator for DSP depending on design requirements and familiarity with the tools Explain why there is a need for an integrated flow from system design to implementation Describe the System Generator and the tools it interfaces with Build a model, simulate it, generate VHDL, and go through the design flow Describe how Hardware in the Loop verification is beneficial in complex system design

3. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP HDL Co-Simulation Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

4. HDL Design Verification In the HDL flow, two sets of codes must be written: HDL design and Verification code (testbench) for Behavioral and Functional simulation. The designer is responsible for testing and should create the environment for verification.In the HDL flow, two sets of codes must be written: HDL design and Verification code (testbench) for Behavioral and Functional simulation. The designer is responsible for testing and should create the environment for verification.

5. Synthesis Design Verification

6. ImplementationDesign Verification If the design does not meet performance, the HDL code may have to be modified.If the design does not meet performance, the HDL code may have to be modified.

7. Labs 1-3: Generating a MAC You will be generating the MAC using three different methods Using VHDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP Compare the implementation results Contrast the design methodologies

8. Block Diagram: VHDL MAC The MAC will perform 92 multiply and accumulate operations on 12-bit data and 8-bit coefficients, resulting in 27-bits.The MAC will perform 92 multiply and accumulate operations on 12-bit data and 8-bit coefficients, resulting in 27-bits.

9. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP HDL Co-Simulation Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

10. Xilinx CORE Generator The Xilinx CORE Generator is the delivery vehicle for IP. IP from Xilinx and from Alliance partner are listed in the CORE Generator, although only the Xilinx LogiCORE can be generated from this tool. IP is fully parameterizable via a customization GUI and can be generated for any type of HDL/schematic flow as long as it is officially supported by Xilinx. The Xilinx CORE Generator is the delivery vehicle for IP. IP from Xilinx and from Alliance partner are listed in the CORE Generator, although only the Xilinx LogiCORE can be generated from this tool. IP is fully parameterizable via a customization GUI and can be generated for any type of HDL/schematic flow as long as it is officially supported by Xilinx.

11. CORE GeneratorDesign Verification

12. Synthesize, Implement, DownloadDesign Verification

13. Although continuously increasing, the list of IP is limited and you will not always find the function of interest. Several options are available in that case: build the required function from lower level block IP or choose a mix-mode where part of the function is specified in HDL or schematic and the rest in IP. Although continuously increasing, the list of IP is limited and you will not always find the function of interest. Several options are available in that case: build the required function from lower level block IP or choose a mix-mode where part of the function is specified in HDL or schematic and the rest in IP.

14. Xilinx Smart-IP Technology Pre-defined placement and routing enhances performance and predictability Performance is independent of: With relative placement of the logic within a core, you get logic predictability. Because the logic has consistent internal placement, the performance of a core remains constant regardless of its position in the device. This is the intelligent software part of Smart-IP technology. In addition to the modular routing capability, we can keep track of the relative location of a core’s logic. Hence, we can floorplan the core or fix its placement with respect to the I/O. For guaranteed performance, we can even fix the placement and predefine the routing. For example, the Xilinx DSP CORES use only relative placement, but for the more performance-sensitive PCI design we use the fixed placement and predefined routing strategy. Designs can be migrated to larger devices without any performance degradation. Because of the use of regular local logic and interconnect as well as segmented routing, the IP modules can be placed anywhere on the device without impacting performance. Because the IP modules use regular local logic and interconnect, you can also place multiple copies of the same module on a device and they will ALL continue to function at the published performance speeds. For the same reasons, you can also migrate an IP module from smaller devices to larger devices without degrading the module’s performance.With relative placement of the logic within a core, you get logic predictability. Because the logic has consistent internal placement, the performance of a core remains constant regardless of its position in the device. This is the intelligent software part of Smart-IP technology. In addition to the modular routing capability, we can keep track of the relative location of a core’s logic. Hence, we can floorplan the core or fix its placement with respect to the I/O. For guaranteed performance, we can even fix the placement and predefine the routing. For example, the Xilinx DSP CORES use only relative placement, but for the more performance-sensitive PCI design we use the fixed placement and predefined routing strategy. Designs can be migrated to larger devices without any performance degradation. Because of the use of regular local logic and interconnect as well as segmented routing, the IP modules can be placed anywhere on the device without impacting performance. Because the IP modules use regular local logic and interconnect, you can also place multiple copies of the same module on a device and they will ALL continue to function at the published performance speeds. For the same reasons, you can also migrate an IP module from smaller devices to larger devices without degrading the module’s performance.

15. Outputs .EDN (EDIF implementation netlist) .XCO (core implementation data file / log file) Optional: .ASY Foundation or Innoveda symbols .VEO Verilog instantiation template .V Verilog behavioral simulation model .VHO VHDL instantiation template .VHD VHDL behavioral simulation model The EDIF file is the actual netlist that is used by the place and route implementation tools. The XCO file is a CORE Generation “log” file that contains all of the parameterization options that were used to create the IP Module. This XCO file can be re-run to recreate the IP module. Optional files, the creation of which will depend on the current CORE Generator’s project settings, will be the VHDL and Verilog instantiation templates. These templates point to the behavioral models for this IP module.The EDIF file is the actual netlist that is used by the place and route implementation tools. The XCO file is a CORE Generation “log” file that contains all of the parameterization options that were used to create the IP Module. This XCO file can be re-run to recreate the IP module. Optional files, the creation of which will depend on the current CORE Generator’s project settings, will be the VHDL and Verilog instantiation templates. These templates point to the behavioral models for this IP module.

16. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP HDL Co-Simulation Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

17. The Challenges for a DSP Software Platform Industry Trends Trend towards platform chips (FPGAs, DSP) resulting in greater complexity Highly flexible systems required to meet changing standards Multiple design methodologies - control plane/datapath Challenges in modeling and implementing an entire platform Hardware in the loop verification is useful in complex system design and System Generator supports it System Design Challenges Leveraging legacy HDL code Modeling & implementing control logic and datapath No expert exists for all facets of system design Industry Trends Platform FPGAs - Designers putting more of the system onto a chip to reduce costs Flexibility - self explanatory Multiple design methodologies - e.g., embedded system design for microprocessor and VHDL based design for hardware Challenges in modeling the entire platform - With the integration of processors/dsp/logic/IO there are new challenges in effectively modeling the entire system System Design Challenges Designers want to leverage existing HDL code as they merge bits of a system together. They want the system to have both the control and datapath and this means that there may be multiple experts for each facet of the design tat are used to different environmentsIndustry Trends Platform FPGAs - Designers putting more of the system onto a chip to reduce costs Flexibility - self explanatory Multiple design methodologies - e.g., embedded system design for microprocessor and VHDL based design for hardware Challenges in modeling the entire platform - With the integration of processors/dsp/logic/IO there are new challenges in effectively modeling the entire system System Design Challenges Designers want to leverage existing HDL code as they merge bits of a system together. They want the system to have both the control and datapath and this means that there may be multiple experts for each facet of the design tat are used to different environments

18. MATLAB MATLAB™, the most popular system design tool, is a programming language, interpreter, and modeling environment Extensive libraries for math functions, signal processing, DSP, communications, and much more Visualization: large array of functions to plot and visualize your data and system/design Open architecture: software model based on base system and domain-specific plug-ins The MathWorks has been developing system design tools since 1984. Its latest product is MATLAB 6.5 (from MATLAB tools release 13, July, 2002). Visit The MathWorks website at http://www.mathworks.com for further details. Other vendors of system-level modeling packages are: Visual data flow SPW (Cadence), COSSAP (Synopsys), Ptolemy (UC Berkeley), SystemView (Elanix) Programming language based C++ SystemC, OCAPI (IMEC) C Streams-C (Gokhale et al.), Handel-C (Celoxica) Java JHDL (BYU) Relative success of each approach, at least to date, is indicated by the predominance of commercial offerings in VDF (Visual Data Flow) as compared to research activity.The MathWorks has been developing system design tools since 1984. Its latest product is MATLAB 6.5 (from MATLAB tools release 13, July, 2002). Visit The MathWorks website at http://www.mathworks.com for further details. Other vendors of system-level modeling packages are: Visual data flow SPW (Cadence), COSSAP (Synopsys), Ptolemy (UC Berkeley), SystemView (Elanix) Programming language based C++ SystemC, OCAPI (IMEC) C Streams-C (Gokhale et al.), Handel-C (Celoxica) Java JHDL (BYU) Relative success of each approach, at least to date, is indicated by the predominance of commercial offerings in VDF (Visual Data Flow) as compared to research activity.

19. MATLAB Frequency response of input sound file This is an excellent example of how designers can visualize their signals at any point in their algorithm and analyze the effects their systems are having on their design. This is far more difficult, if not impossible, to do with current FPGA design tools. Another strong reason for these system-level design tools is the speed and ease of implementing algorithms, concepts and ideas. This example was executed in three lines of code in no time at all. To implement such an algorithm in an FPGA design would take large amounts of design work, code, and time. Notice the Workspace Window pane on the left. This window pane is used to view the different variables that have been created by the designer, and are accessible to algorithms. The two variables that can currently be seen are Fw (the frequency response vector from zero to the Nyquist frequency) and voice (the variable which stores the sound information). Other useful windows include the Current Directory window (a navigation window).This is an excellent example of how designers can visualize their signals at any point in their algorithm and analyze the effects their systems are having on their design. This is far more difficult, if not impossible, to do with current FPGA design tools. Another strong reason for these system-level design tools is the speed and ease of implementing algorithms, concepts and ideas. This example was executed in three lines of code in no time at all. To implement such an algorithm in an FPGA design would take large amounts of design work, code, and time. Notice the Workspace Window pane on the left. This window pane is used to view the different variables that have been created by the designer, and are accessible to algorithms. The two variables that can currently be seen are Fw (the frequency response vector from zero to the Nyquist frequency) and voice (the variable which stores the sound information). Other useful windows include the Current Directory window (a navigation window).

20. Simulink Simulink™ - Visual data flow environment for modeling and simulation of dynamical systems Fully integrated with the MATLAB engine Graphical block editor Event-driven simulator Models parallelism Extensive library of parameterizable functions Simulink Blockset - math, sinks, sources DSP Blockset - filters, transforms, etc. Communications Blockset - modulation, DPCM, etc. Simulink, The MathWorks’ visual data flow tool, presents an alternative to using programming languages for system design. This enables designers to visualize the dynamic nature of your system while illustrating their complete system in a realistic fashion with respect to the hardware design. Most hardware design starts out with a block diagram description and specification of the system, very similar to the Simulink design. The main part of Simulink is the Library browser that contains all the available building blocks to the user. This library is expandable and each block is parameterizable. Users can even create their own libraries of functions they have created. An important point of note about Simulink is that it can model concurrency in a system. Unlike the sequential manner of software code, the Simulink model can be seen to be executing sections of a design at the same time (in parallel). This notion is fundamental to implementing a high-performance hardware implementation. Simulink, The MathWorks’ visual data flow tool, presents an alternative to using programming languages for system design. This enables designers to visualize the dynamic nature of your system while illustrating their complete system in a realistic fashion with respect to the hardware design. Most hardware design starts out with a block diagram description and specification of the system, very similar to the Simulink design. The main part of Simulink is the Library browser that contains all the available building blocks to the user. This library is expandable and each block is parameterizable. Users can even create their own libraries of functions they have created. An important point of note about Simulink is that it can model concurrency in a system. Unlike the sequential manner of software code, the Simulink model can be seen to be executing sections of a design at the same time (in parallel). This notion is fundamental to implementing a high-performance hardware implementation.

21. MATLAB/Simulink It is also possible to interface Simulink and MATLAB together, which enables users to bring M files into their Simulink model, save signals to the MATLAB workspace, and vice versa. Use the FIND feature at the top of the library browser to search for blocks. There are many available and it is not easy to remember where they all reside. It is also possible to interface Simulink and MATLAB together, which enables users to bring M files into their Simulink model, save signals to the MATLAB workspace, and vice versa. Use the FIND feature at the top of the library browser to search for blocks. There are many available and it is not easy to remember where they all reside.

22. Traditional Simulink FPGA Flow In the past, if a DSP designer wanted to target an FPGA, he would have no option but a “dual path” of development. The DSP designer writes an algorithm in pseudo-C, using filters, certain C code, certain precision. He may know everything about DSP and Simulink models, but may not know anything about FPGAs. Not only does he not know how to target an FPGA, he doesn’t know how to take advantage of the FPGA architecture, or how to write a design to avoid a bad FPGA implementation. When he’s done with his DSP design, he may have a working model in Simulink, but he must design the same thing in VHDL, or he gives his design to an FPGA implementer (who may know nothing about DSP) who writes the VHDL for him. The implementer might end up using a core that doesn’t do exactly what the designer wants, by not being a DSP expert, the FPGA implementer is just trying to translate the pseudo code that came to him into VHDL for an FPGA. There is also no way to co-simulate: one is simulating in C in MATLAB, the other simulating in VHDL in a behavioral simulation. It’s only when they get into the lab and simulate the board, late in the process, that they find out something’s wrong.In the past, if a DSP designer wanted to target an FPGA, he would have no option but a “dual path” of development. The DSP designer writes an algorithm in pseudo-C, using filters, certain C code, certain precision. He may know everything about DSP and Simulink models, but may not know anything about FPGAs. Not only does he not know how to target an FPGA, he doesn’t know how to take advantage of the FPGA architecture, or how to write a design to avoid a bad FPGA implementation. When he’s done with his DSP design, he may have a working model in Simulink, but he must design the same thing in VHDL, or he gives his design to an FPGA implementer (who may know nothing about DSP) who writes the VHDL for him. The implementer might end up using a core that doesn’t do exactly what the designer wants, by not being a DSP expert, the FPGA implementer is just trying to translate the pseudo code that came to him into VHDL for an FPGA. There is also no way to co-simulate: one is simulating in C in MATLAB, the other simulating in VHDL in a behavioral simulation. It’s only when they get into the lab and simulate the board, late in the process, that they find out something’s wrong.

23. System Generator forDSP v6.1 – An Overview Industry’s system-level design environment (IDE) for FPGAs Integrated design flow from Simulink to bit file Leverages existing technologies MATLAB, Simulink (plug-in to Simulink v6.5 or greater) HDL synthesis IP Core libraries FPGA implementation tools Simulink library of arithmetic, logic operators and DSP functions (Xilinx Blockset) Bit and cycle true to FPGA implementation Arithmetic abstraction Arbitrary precision fixed-point, including quantization and overflow Simulation of double precision as well as fixed point System Generator is a plug-in to the Simulink environment, adding a Blockset to the Simulink library browser: Blockset v3.1, introduced in March 2003, has 61 blocks (47 into hardware) and targets 28 LogiCORES. They are listed in nine categories: Basic Elements Communication Control Logic Data Types DSP Index Math Memory Tools Each block is bit and cycle true. This means that for any injection of data into a SysGen model (via a Gateway In) and any extraction of data from a SysGen model (via a Gateway Out), the bits at the gateways match the corresponding bits in hardware at the sample times defined in Simulink. To provide system-level designers with a portal into the FPGA, System Generator taps into existing technologies, leveraging the MathWorks tool suite to provide the foundations for system design and the Xilinx FPGA design flow to implement the design.System Generator is a plug-in to the Simulink environment, adding a Blockset to the Simulink library browser: Blockset v3.1, introduced in March 2003, has 61 blocks (47 into hardware) and targets 28 LogiCORES. They are listed in nine categories: Basic Elements Communication Control Logic Data Types DSP Index Math Memory Tools Each block is bit and cycle true. This means that for any injection of data into a SysGen model (via a Gateway In) and any extraction of data from a SysGen model (via a Gateway Out), the bits at the gateways match the corresponding bits in hardware at the sample times defined in Simulink. To provide system-level designers with a portal into the FPGA, System Generator taps into existing technologies, leveraging the MathWorks tool suite to provide the foundations for system design and the Xilinx FPGA design flow to implement the design.

24. System Generator for DSP v6.1 – An Overview VHDL code generation for Virtex-II Pro™, Virtex™-II, Virtex™-E, Virtex™, Spartan™-3, Spartan™-IIE and Spartan™-II devices Hardware expansion and mapping Synthesizable VHDL with model hierarchy preserved Mixed language support for Verilog Automatic invocation of CORE Generator to utilize IP cores ISE project generation to simplify the design flow HDL testbench and test vector generation Constraint file (.xcf), simulation ‘.do’ files generation HDL Co-Simulation via HDL C-Simulation Verification acceleration using Hardware in the Loop Along with the VHDL code that gets generated for the Simulink model is: - .npl file: An ISE project file, providing a seamless entry into the FPGA design flow - .xcf: User Constraints File to assist the implementation in obtaining maximum performance - A testbench: The testbench uses the stimulus provided in Simulink and also compares the HDL simulation results with the results from Simulink to verify equivalence. - .do files: For MTI users, scripts are created to make compilation and simulation simple - CORE Generator is automatically invoked for the elements in the design that use COREGen components. See “help” under the parameters GUI to see which Core will be used for a particular block.Along with the VHDL code that gets generated for the Simulink model is: - .npl file: An ISE project file, providing a seamless entry into the FPGA design flow - .xcf: User Constraints File to assist the implementation in obtaining maximum performance - A testbench: The testbench uses the stimulus provided in Simulink and also compares the HDL simulation results with the results from Simulink to verify equivalence. - .do files: For MTI users, scripts are created to make compilation and simulation simple - CORE Generator is automatically invoked for the elements in the design that use COREGen components. See “help” under the parameters GUI to see which Core will be used for a particular block.

25. System Generator for DSP Platform Designs The System Generator 3.1 provides a convenient way to perform HDL co-simulation and Hardware in the loop simulation using Black Box block. The black box can be used to incorporate hardware description language (HDL) models into System Generator. The System Generator 3.1 provides a convenient way to perform HDL co-simulation and Hardware in the loop simulation using Black Box block. The black box can be used to incorporate hardware description language (HDL) models into System Generator.

26. Creating a SystemGenerator Design Invoke Simulink library browser To open the Simulink library browser, click the Simulink library browser button or type “Simulink” in MATLAB console The library browser contains all the blocks available to designers Start a new design by clicking the new sheet button The .mdl (MATLAB Description Language) file is the main design file for Simulink designs. You can also open .mdl files directly through the MATLAB console GUI or from the MATLAB command line. Make sure your MATLAB current directory path is always pointing to your working directory. You can “cd” to the correct directory.The .mdl (MATLAB Description Language) file is the main design file for Simulink designs. You can also open .mdl files directly through the MATLAB console GUI or from the MATLAB command line. Make sure your MATLAB current directory path is always pointing to your working directory. You can “cd” to the correct directory.

27. Creating a SystemGenerator Design Build the design by dragging and dropping blocks from the Xilinx blockset onto your new sheet. Design Entry is similar to a schematic editor The next few slides show the process that a system designer may use to get his design into an FPGA, via the System Generator and Simulink. Right-click on a block to format blocks (rotate, drop shadow, font) and to change foreground color and background color.The next few slides show the process that a system designer may use to get his design into an FPGA, via the System Generator and Simulink. Right-click on a block to format blocks (rotate, drop shadow, font) and to change foreground color and background color.

28. Finding Blocks Use the Find feature to search ALL Simulink libraries Xilinx blockset has nine major sections Basic elements Counters, delays Communication Error correction blocks Control Logic MCode, Black Box Data Types Convert, Slice DSP FDATool, FFT, FIR Index All Xilinx blocks – quick way to view all blocks Math Multiply, accumulate, inverter Memory Dual Port RAM, Single Port RAM Tools ModelSim, Resource Estimator As there are a vast array of blocks already accessible from the Simulink libraries, trying to locate a specific block can be daunting or frustrating. Here are two ways to find a specific block: Use the FIND feature at the top of the Simulink browser. or Go to the MATLAB help and search for a keyword. This will search all the help documents and may find the block you are looking for.As there are a vast array of blocks already accessible from the Simulink libraries, trying to locate a specific block can be daunting or frustrating. Here are two ways to find a specific block: Use the FIND feature at the top of the Simulink browser. or Go to the MATLAB help and search for a keyword. This will search all the help documents and may find the block you are looking for.

29. Configure Your Blocks Double-click or go to Block Parametersto view a block’s configurable parameters Arithmetic Type: Unsigned or twos complement Implement with Xilinx Smart-IP Core (if possible)/Generate Core Latency: Specify the delay through the block Overflow and Quantization: Users can saturate orwrap overflow. Truncate or Round Quantization Override with Doubles: Simulation only Precision: Full or the user can define the number of bits and where the decimal point is for the block Sample Period: Can be inherent with a “-1” or must be an integer value Note: While all parameters can be simulated,not all are realizable Further notes on: Sampling Period: The data streams are processed at a specific sample rate, or clock period, as they flow through a dataflow system such as Simulink. Typically, each block detects the input sample rate and produces the correct sample rate on its output. Xilinx Blockset elements Up Sample and Down Sample provide a means to increase or decrease sample rates. If you select Use Explicit Sample Period rather than the default, you may set the sample period required for all the block outputs. This is useful when implementing features in your design, such as feedback loops. In a feedback loop, it is not possible for the System Generator to determine a default sample rate, because the loop makes an input sample rate dependent on a yet-to-be-determined output sample rate. The System Generator therefore requires you to supply a hint to establish sample periods throughout a loop. Latency: Defines the number of input sample periods required for an input to affect a block output. This sample period may correspond to multiple clock cycles in the corresponding FPGA implementation, for example when the hardware is overclocked with respect to the Simulink model. System Generator does not perform extensive pipelining; additional latency is usually implemented as a shift register on the output of the block. Override with Doubles: This causes the fixed point simulation to be bypassed and the complete simulation is executed in “doubles”. Although not realizable, this can be useful in examining the effects of quantization on your design. Experiment with these parameters on a simple sine wave to gain further insight as to how they affect the results of a system. For details of all the parameters, see the help documentation provided with the System Generator documentation.Further notes on: Sampling Period: The data streams are processed at a specific sample rate, or clock period, as they flow through a dataflow system such as Simulink. Typically, each block detects the input sample rate and produces the correct sample rate on its output. Xilinx Blockset elements Up Sample and Down Sample provide a means to increase or decrease sample rates. If you select Use Explicit Sample Period rather than the default, you may set the sample period required for all the block outputs. This is useful when implementing features in your design, such as feedback loops. In a feedback loop, it is not possible for the System Generator to determine a default sample rate, because the loop makes an input sample rate dependent on a yet-to-be-determined output sample rate. The System Generator therefore requires you to supply a hint to establish sample periods throughout a loop. Latency: Defines the number of input sample periods required for an input to affect a block output. This sample period may correspond to multiple clock cycles in the corresponding FPGA implementation, for example when the hardware is overclocked with respect to the Simulink model. System Generator does not perform extensive pipelining; additional latency is usually implemented as a shift register on the output of the block. Override with Doubles: This causes the fixed point simulation to be bypassed and the complete simulation is executed in “doubles”. Although not realizable, this can be useful in examining the effects of quantization on your design. Experiment with these parameters on a simple sine wave to gain further insight as to how they affect the results of a system. For details of all the parameters, see the help documentation provided with the System Generator documentation.

30. Values Can Be Equations You can also enter equations in the block parameters, which can aid calculation and your own understanding of the model parameters The equations are calculated at the beginning of a simulation Useful MATLAB operators + add - subtract * multiply / divide ^ power ? pi (3.1415926535897.…) exp(x) exponential (ex) This can be very useful for entering the frequency of a sine wave. Instead of calculating the value in radians, which is 2*pi*f, you can enter the complete equation with your value of frequency. MATLAB will calculate the result at the beginning of the simulation. You can even enter f as a variable and specify “f” from the MATLAB workspace. More on that later with the filter lab.This can be very useful for entering the frequency of a sine wave. Instead of calculating the value in radians, which is 2*pi*f, you can enter the complete equation with your value of frequency. MATLAB will calculate the result at the beginning of the simulation. You can even enter f as a variable and specify “f” from the MATLAB workspace. More on that later with the filter lab.

31. Creating a SystemGenerator Design A System Generator design can be dissected into very distinct sections. The “hardware realizable” section is shown in BLUE. This will be the section that will go into the FPGA. The YELLOW blocks represent the gateways into and out of the Xilinx blockset as they must be implemented in fixed point arithmetic. The gateways will also illustrate the inputs and outputs of your VHDL top-level entity (the pins of the device). All Simulink blocks do not have color and most designs will utilize the Simulink/DSP sources and sinks, which will drive and test the design. Any Simulink block (although not hardware-realizable unless manually created in VHDL) can be interfaced to the Xilinx Blockset with the aid of the gateway blocks to convert between “doubles” and “fixed-point numbers.” The System Generator token is required at the top-level design for the design using Xilinx blocks to be simulated.A System Generator design can be dissected into very distinct sections. The “hardware realizable” section is shown in BLUE. This will be the section that will go into the FPGA. The YELLOW blocks represent the gateways into and out of the Xilinx blockset as they must be implemented in fixed point arithmetic. The gateways will also illustrate the inputs and outputs of your VHDL top-level entity (the pins of the device). All Simulink blocks do not have color and most designs will utilize the Simulink/DSP sources and sinks, which will drive and test the design. Any Simulink block (although not hardware-realizable unless manually created in VHDL) can be interfaced to the Xilinx Blockset with the aid of the gateway blocks to convert between “doubles” and “fixed-point numbers.” The System Generator token is required at the top-level design for the design using Xilinx blocks to be simulated.

32. Setting the GlobalSample Period

33. SysGen Token ALL designs must have a System Generator token present in their design. System Generator also offers the option to have numerous System Generator tokens in their designs. This provides the ability to generate and test lower levels of their designs. The Simulink System Period must be set correctly for the simulation to execute. This value reflects the smallest period that the system should run at, so that all other sample periods in the design can be determined from this sample period. In hardware the Simulink System Period equates to the System CLK that drives the design. Hence, the FPGA System CLK Period requires a value in ns to pass on to the timing constraints. These in turn will inform the placer and to implement the design so to achieve the user desired timing performance. System Generator block that lies in the scope of another System Generator block is called a slave. Otherwise, it is called a master. Most system parameters can be set only in a master block; System Generator will automatically synchronize slave blocks to parameters specified in their master block. It is of course possible to have multiple master blocks in a Simulink model. Because the system parameters specified in the System Generator block affect the Simulink behavior, the hardware realization, or the relationship between the two for every block in the Xilinx Blockset, every element in the blockset must lie in the scope of a System Generator block. Consequently, every Simulink model containing any element from the blockset must contain at least one System Generator block.ALL designs must have a System Generator token present in their design. System Generator also offers the option to have numerous System Generator tokens in their designs. This provides the ability to generate and test lower levels of their designs. The Simulink System Period must be set correctly for the simulation to execute. This value reflects the smallest period that the system should run at, so that all other sample periods in the design can be determined from this sample period. In hardware the Simulink System Period equates to the System CLK that drives the design. Hence, the FPGA System CLK Period requires a value in ns to pass on to the timing constraints. These in turn will inform the placer and to implement the design so to achieve the user desired timing performance. System Generator block that lies in the scope of another System Generator block is called a slave. Otherwise, it is called a master. Most system parameters can be set only in a master block; System Generator will automatically synchronize slave blocks to parameters specified in their master block. It is of course possible to have multiple master blocks in a Simulink model. Because the system parameters specified in the System Generator block affect the Simulink behavior, the hardware realization, or the relationship between the two for every block in the Xilinx Blockset, every element in the blockset must lie in the scope of a System Generator block. Consequently, every Simulink model containing any element from the blockset must contain at least one System Generator block.

34. Using the Scope Click Properties to change the number ofaxes displayed and the time range value(X-axis) Use the Data History tab to control how many values are stored and displayed on the scope Also can direct output to workspace Click Autoscale to quickly let the toolsconfigure the display to the correct axisvalues Right-click on the Y-axis to set its value This will be the most frequently used Simulink block. To display multiple signals on one scope, use the “MUX” block to combine signals. (Simulink ? Signals&Systems) For more information on using Simulink blocks, see the help documentation under the parameterization GUI of each block. This will be the most frequently used Simulink block. To display multiple signals on one scope, use the “MUX” block to combine signals. (Simulink ? Signals&Systems) For more information on using Simulink blocks, see the help documentation under the parameterization GUI of each block.

35. Design and Simulatein Simulink This example shows a Costas Loop, which is used in communications to account for Doppler shifts in transmitted signals. The eye from the eye diagram is clearly open and, in the absence of any channel impairments, the receiver can easily make correct symbol decisions using this waveform. This diagram is produced by plotting segments of successive matched filter outputs on top of each other. You can enter “inf” into the end time for the length of simulation so that a simulation will run forever.This example shows a Costas Loop, which is used in communications to account for Doppler shifts in transmitted signals. The eye from the eye diagram is clearly open and, in the absence of any channel impairments, the receiver can easily make correct symbol decisions using this waveform. This diagram is produced by plotting segments of successive matched filter outputs on top of each other. You can enter “inf” into the end time for the length of simulation so that a simulation will run forever.

36. Generate the VHDL Code Select the target device Select to generate the testbench Set the System clock period desired Generate the VHDL Once a design is completed and successfully simulated, double-click the System Generator token, which should reside on highest hierarchy level including Xilinx blocks. Double-clicking opens the Options window, where you can specify the target device, the synthesis tool you will be using, and whether testbench generation is desired. Warning: if “create testbench” is selected, the simulation will be run again to capture the DAT files and create the testbench. The Simulink System Period is the value at which the System Period must work in order to achieve all the respective block’s desired sample period in the design. More on this later (multi-rate systems module). You must set the System Clock Period in this GUI. This value will translate to the period constraint in the UCF file; PAR will shoot for this value when laying out the design. You can also specify whether you want cores to be generated (one may not want to if it has been done before, as to save time) and also globally specify simulation in doubles, if desired. Click the Generate button and the System Generator will create all the files that were outlined earlier. Once a design is completed and successfully simulated, double-click the System Generator token, which should reside on highest hierarchy level including Xilinx blocks. Double-clicking opens the Options window, where you can specify the target device, the synthesis tool you will be using, and whether testbench generation is desired. Warning: if “create testbench” is selected, the simulation will be run again to capture the DAT files and create the testbench. The Simulink System Period is the value at which the System Period must work in order to achieve all the respective block’s desired sample period in the design. More on this later (multi-rate systems module). You must set the System Clock Period in this GUI. This value will translate to the period constraint in the UCF file; PAR will shoot for this value when laying out the design. You can also specify whether you want cores to be generated (one may not want to if it has been done before, as to save time) and also globally specify simulation in doubles, if desired. Click the Generate button and the System Generator will create all the files that were outlined earlier.

37. System Generator Output Files Design files .VHD : VHDL design files .EDN : Core implementation file .XCF : Xilinx constraints file for timing constraints Project files .NPL : Project Navigator project file .TCL : Scripts for Synplify and Leonardo project creation Simulation files .DO : Simulation scripts for MTI .DAT : Data files containing the test vectors from System Generator .VHD : Simulation testbench System Generator generates many different files, the majority of which are VHDL files: .VHD : Apart from the design_name_testbench.vhd these are all the VHDL design files that were generated for your design. Note how the hierarchy of your design is maintained in the names of the modules. .EDN : Core implementation files (see module on CORE Generator for further details). All other core files will be located in the “corework” directory generated. .XCF : This file (the User constraints file) contains the timing constraints for your design. This file is very important if you wish to achieve the performance specified. The xcf file is generated for XST. The ncf file is generated for Synplify and Leonardo Spectrum synthesis tools. .NPL : Project Navigator project file. Crucial to making the flow more “push button” .TCL : These tcl scripts are for Synplify and Leonardo project creation. .DO : There are four DO files for Modelsim. Each individual DO is automatically pointed to by the ISE project and are used to run functional, post-translate, post-map and post-par simulation respectively. .DAT : These are the data files containing the test vectors from System Generator. .VHD : design_name_testbench is the verification testbench. It uses the .DAT files to verify the simulation results.System Generator generates many different files, the majority of which are VHDL files: .VHD : Apart from the design_name_testbench.vhd these are all the VHDL design files that were generated for your design. Note how the hierarchy of your design is maintained in the names of the modules. .EDN : Core implementation files (see module on CORE Generator for further details). All other core files will be located in the “corework” directory generated. .XCF : This file (the User constraints file) contains the timing constraints for your design. This file is very important if you wish to achieve the performance specified. The xcf file is generated for XST. The ncf file is generated for Synplify and Leonardo Spectrum synthesis tools. .NPL : Project Navigator project file. Crucial to making the flow more “push button” .TCL : These tcl scripts are for Synplify and Leonardo project creation. .DO : There are four DO files for Modelsim. Each individual DO is automatically pointed to by the ISE project and are used to run functional, post-translate, post-map and post-par simulation respectively. .DAT : These are the data files containing the test vectors from System Generator. .VHD : design_name_testbench is the verification testbench. It uses the .DAT files to verify the simulation results.

38. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP HDL Co-Simulation Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

39. HDL Co-simulation Allows Import of HDL Code Being able to include new or legacy modules is essential for many DSP system designers HDL modules can be imported Simulink “Black box” function allows designers to import HDL Single HDL simulator for multiple black boxes HDL modules can be simulated in Simulink to significantly reduce development time HDL is co-simulated transparently HDL simulated using industry-standard ModelSim tool from Mentor Graphics directly from Simulink framework Another new frature of SG 3.1 is the ability for designers to import their legacy HDL code into Simulink via a black box and be able to simulate this as part of the system level simulation When the Simulink simulation reaches the black box, the tool automatically invokes Mentor’s ModelSIm and simulates the HDL. Results are stored in memory and then fed back into the Simulink simulation when needed This will save development time, resources and cost as designers no longer need to write S-functions for SimulinkAnother new frature of SG 3.1 is the ability for designers to import their legacy HDL code into Simulink via a black box and be able to simulate this as part of the system level simulation When the Simulink simulation reaches the black box, the tool automatically invokes Mentor’s ModelSIm and simulates the HDL. Results are stored in memory and then fed back into the Simulink simulation when needed This will save development time, resources and cost as designers no longer need to write S-functions for Simulink

40. Import HDL code

41. Co-Simulate with ModelSim

42. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP HDL Co-Simulation Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

43. Hardware in the Loop Reduces Design Time & Cost Hardware Verification Designers can now verify designs in hardware directly from the Simulink tool Mirrors traditional DSP processor design flows Hardware Acceleration Designers can automatically create bit-stream from Simulink Resulting in transparent use of FPGA implementation tools There are 2 main benefits of hardware in the loop 1 Designers can now verify their designers in hardware without leaving Simulink Traditional flow was Simulink > System generator > Synthesis > ISE > bitstream Now, designers can do all this without leaving Simulink and even feed the results from hardware back into Simulink This mirrors traditional DSP design flows like from TI (although their’s is software based) 2. Because of hardware in the loop, designers can accelerate the simulation when needed with out the need for expensive emulation hardwareThere are 2 main benefits of hardware in the loop 1 Designers can now verify their designers in hardware without leaving Simulink Traditional flow was Simulink > System generator > Synthesis > ISE > bitstream Now, designers can do all this without leaving Simulink and even feed the results from hardware back into Simulink This mirrors traditional DSP design flows like from TI (although their’s is software based) 2. Because of hardware in the loop, designers can accelerate the simulation when needed with out the need for expensive emulation hardware

44. Compile For Selected Platform

45. Create Bit-stream

46. Co-Simulate in Hardware

47. Hardware in the Loop Performance Results There are many possible synchronization techniques for the interface between FPGA hardware and Simulink. One technique uses a single step clock to keep the hardware in lockstep with the software simulation. This can be achieved by providing a single clock pulse to the hardware for each simulation cycle. Using this technique enables the user to perform incremental design and verification. On the other hand, when a single step clock is the only method used for clocking the FPGA design, the communication overhead between hardware and Simulink (further exacerbated by bus latency) can for some designs prohibitively limit the effective processing rate. Simulation speed can be greatly increased by allowing the hardware to process more than one set of input samples at a time. One way to accomplish this is to provide a free running clock to the design under test, using an explicit synchronization mechanism (e.g. a flag implemented as a memory mapped register) to coordinate data transfers between Simulink and the hardware. The inputs and outputs of the design can then be written to and sampled asynchronously. There are many possible synchronization techniques for the interface between FPGA hardware and Simulink. One technique uses a single step clock to keep the hardware in lockstep with the software simulation. This can be achieved by providing a single clock pulse to the hardware for each simulation cycle. Using this technique enables the user to perform incremental design and verification. On the other hand, when a single step clock is the only method used for clocking the FPGA design, the communication overhead between hardware and Simulink (further exacerbated by bus latency) can for some designs prohibitively limit the effective processing rate. Simulation speed can be greatly increased by allowing the hardware to process more than one set of input samples at a time. One way to accomplish this is to provide a free running clock to the design under test, using an explicit synchronization mechanism (e.g. a flag implemented as a memory mapped register) to coordinate data transfers between Simulink and the hardware. The inputs and outputs of the design can then be written to and sampled asynchronously.

48. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP HDL Co-Simulation Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

49. Resource Estimator The block provides fast estimates of FPGA resources required to implement the subsystem Most of the blocks in the System Generator Blockset carries the resources information LUTs FFs BRAM Embedded multipliers 3-state buffers I/Os The Xilinx Resource Estimator block provides fast estimates of FPGA resources required to implement a System Generator subsystem or model. These estimates are computed by invoking block-specific estimators for Xilinx blocks, and summing these values to obtain aggregated estimates of lookup tables (LUTs), flip-flops (FFs), block memories (BRAM), 18x18 multipliers, Tri-state buffers, and I/Os. Every Xilinx block that requires FPGA resources has a mask parameter that stores a vector containing its resource requirements. The Resource Estimator block can invoke underlying functions to populate these vectors (e.g. after parameters or data types have been changed), or aggregate previously computed values that have been stored in the vectors. Each block has a checkbox control "Use Area Above for Estimation" that short-circuits invocation of the estimator function and uses the estimates stored in the vector instead. An estimator block can be placed in any subsystem of a model. Blocks that have resource estimation functions Accumulator, Addressable Shift Register, AddSub, CMult (Sequential version not supported), Convert, Counter, Delay, Down Sample, Dual Port RAM, FIFO, FFT, Gateway In, Gateway Out, Inverter, LFSR, Logical, Mult (Sequential version not supported), Mux (3-state version not supported), Negate, Parallel to Serial, PicoBlaze Processor, Register, Relational, ROM, Serial To Parallel, Shift, Single Port RAM, Threshold, Up Sample Blocks that consume zero hardware resources System Generator, Clear Quantization Error, Clock Enable Probe, Clock Probe, Concat, Constant, Discard Subsystem, FDATool, Indeterminate Probe, ModelSim, Quantization Error, Reinterpret, Sample Time, Scale, Simulation Multiplexer, Slice Blocks with special handling Discard Subsystem (Resource Estimator will ignore any resources in a subsystem containing this block) The Xilinx Resource Estimator block provides fast estimates of FPGA resources required to implement a System Generator subsystem or model. These estimates are computed by invoking block-specific estimators for Xilinx blocks, and summing these values to obtain aggregated estimates of lookup tables (LUTs), flip-flops (FFs), block memories (BRAM), 18x18 multipliers, Tri-state buffers, and I/Os. Every Xilinx block that requires FPGA resources has a mask parameter that stores a vector containing its resource requirements. The Resource Estimator block can invoke underlying functions to populate these vectors (e.g. after parameters or data types have been changed), or aggregate previously computed values that have been stored in the vectors. Each block has a checkbox control "Use Area Above for Estimation" that short-circuits invocation of the estimator function and uses the estimates stored in the vector instead. An estimator block can be placed in any subsystem of a model. Blocks that have resource estimation functions Accumulator, Addressable Shift Register, AddSub, CMult (Sequential version not supported), Convert, Counter, Delay, Down Sample, Dual Port RAM, FIFO, FFT, Gateway In, Gateway Out, Inverter, LFSR, Logical, Mult (Sequential version not supported), Mux (3-state version not supported), Negate, Parallel to Serial, PicoBlaze Processor, Register, Relational, ROM, Serial To Parallel, Shift, Single Port RAM, Threshold, Up Sample Blocks that consume zero hardware resources System Generator, Clear Quantization Error, Clock Enable Probe, Clock Probe, Concat, Constant, Discard Subsystem, FDATool, Indeterminate Probe, ModelSim, Quantization Error, Reinterpret, Sample Time, Scale, Simulation Multiplexer, Slice Blocks with special handling Discard Subsystem (Resource Estimator will ignore any resources in a subsystem containing this block)

50. Resource Estimator Three types of estimation Estimate Area This option computes resources for the current level and all sub-levels Quick Sum Uses the resources stored in block directly and sum them up (no sub-levels functions are invoked) Post-Map Area Opens up a file browser and let user select map report file. The design should have been generated and gone through synthesis, translate, and mapping phases. Estimate Area: Clicking on the Estimate Area button invokes block estimation functions top-down for each block and subsystem recursively. If any block has the Use Area Above for Estimation option selected, its estimator function is short-circuited and its current estimate is used. If this option is selected for a Resource Estimation block contained in the hierarchy, this block's estimate will be used for the entire subsystem containing it, and no other block estimation functions will be invoked for that portion of the model hierarchy. Warning messages will be generated for each block encountered that has no underlying estimation function. Quick Sum: Clicking on the Quick Sum button causes the Resource Estimator block to sum all of the FPGA Area fields on the blocks and subsystems at or below the current subsystem. No underlying estimation functions are invoked. Post-Map Area : Clicking on the Post-Map Area button will cause the Resource Estimator to open up a file browser. Estimate Area: Clicking on the Estimate Area button invokes block estimation functions top-down for each block and subsystem recursively. If any block has the Use Area Above for Estimation option selected, its estimator function is short-circuited and its current estimate is used. If this option is selected for a Resource Estimation block contained in the hierarchy, this block's estimate will be used for the entire subsystem containing it, and no other block estimation functions will be invoked for that portion of the model hierarchy. Warning messages will be generated for each block encountered that has no underlying estimation function. Quick Sum: Clicking on the Quick Sum button causes the Resource Estimator block to sum all of the FPGA Area fields on the blocks and subsystems at or below the current subsystem. No underlying estimation functions are invoked. Post-Map Area : Clicking on the Post-Map Area button will cause the Resource Estimator to open up a file browser.

51. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

52. Summary Full VHDL/Verilog (RTL code) Advantages: Portability Complete control of the design implementation and tradeoffs Easier to debug and understand a code that you own Disadvantages: Can be time-consuming Don’t always have control over the Synthesis tool Need to be familiar with the algorithm and how to write it Must be conversant with the synthesis tools to obtain optimized design

53. Summary Full VHDL/Verilog (Instantiating Primitives) Advantages: Full access to all architecture features Carry on further with optimization Best optimization Disadvantages: Not as portable as RTL VHDL/Verilog Must be an FPGA expert and know the architecture Time-consuming

54. Summary CORE Generator Advantages Can quickly access and generate existing functions No need to reinvent the wheel and re-design a block if it meets specifications IP is optimized for the specified architecture Disadvantages IP doesn’t always do exactly what you are looking for Need to understand signals and parameters and match them to your specification Dealing with black box and have little information on how the function is implemented

55. Summary System Generator for DSP Advantages Huge productivity gains through high-level modeling Ability to simulate the complete designs at a system level Very attractive for FPGA novices Excellent capabilities for designing complex testbenches HDL Testbench, test vector and golden data written automatically Hardware in the loop simulation improves productivity and provides quick verification of the system functioning correctly or not Disadvantages Minor cost of abstraction: doesn’t always give the best result from an area usage point of view Customer may not be familiar with Simulink Not well suited to multiple clock designs No bi-directional bus supported Cost of abstraction is covered in later modulesCost of abstraction is covered in later modules

56. Outline Using HDL Using the Xilinx CORE Generator Using the Xilinx System Generator for DSP Hardware Verification Resource Estimator Summary Simulink Tips and Tricks

57. Complete Systems Throughout this course, we will build and study small sections of complete systems To get a flavor of the capability of System Generator, check out the demos Type “demos” from the MATLAB command line to view them Type “demos” at the MATLAB command line to open the Simulink demos section. Click on the Xilinx demos and the following should be available for you to analyze: A/D and delta-sigma D/A conversion Digital Comm: 16-QAM demodulator (sim) Digital Comm: A QAM system with packet framing and FEC for telemetry channels (sim) Digital Comm: Concatenated FEC codec for DVB standard (sim) Digital Comm: Costas loop carrier recovery (sim) Digital Comm: Digital down converter for GSM (sim) FFT/IFFT in streaming mode (sim) FIR filtering: LMS-based adaptive equalization (sim) FIR filtering: Custom reference library (sim) FIR filtering: Polyphase 1:8 filter using SRL16Es (sim) IIR filtering: Multi-channel, folded implementation (sim) IIR filtering: 2nd order Direct Form I implementation (sim) Image processing: Color space converter (sim) Math: CORDIC-based rectangular-to-polar coordinate converter (sim) Math: CORDIC-based divider circuit (sim) Math: CORDIC-based sine and cosine function (sim) PicoBlaze(Tm) Microcontroller (sim)Type “demos” at the MATLAB command line to open the Simulink demos section. Click on the Xilinx demos and the following should be available for you to analyze: A/D and delta-sigma D/A conversion Digital Comm: 16-QAM demodulator (sim) Digital Comm: A QAM system with packet framing and FEC for telemetry channels (sim) Digital Comm: Concatenated FEC codec for DVB standard (sim) Digital Comm: Costas loop carrier recovery (sim) Digital Comm: Digital down converter for GSM (sim) FFT/IFFT in streaming mode (sim) FIR filtering: LMS-based adaptive equalization (sim) FIR filtering: Custom reference library (sim) FIR filtering: Polyphase 1:8 filter using SRL16Es (sim) IIR filtering: Multi-channel, folded implementation (sim) IIR filtering: 2nd order Direct Form I implementation (sim) Image processing: Color space converter (sim) Math: CORDIC-based rectangular-to-polar coordinate converter (sim) Math: CORDIC-based divider circuit (sim) Math: CORDIC-based sine and cosine function (sim) PicoBlaze(Tm) Microcontroller (sim)

58. Combining Signals To be viewed on a scope, multiple signals must first be combined Use the MUX block (Simulink library ? Signals & Systems) to combine signals, thus making a vector out of them Check Format ? Signal Dimensions and Format ? Wide NonScalar Lines to view how many signals are combined Similarly, the DEMUX can be used to separate signals NOTE: No Xilinx block supports VHDL generation for vectors. Use them purely for Simulink signal manipulation. Typically you will see the MUX block used in a System Generator design for analysis of results. It is exceptionally useful for viewing multiple signals on a sink. For example, you may want to see the results of filtering block and compare them with the unfiltered original signal. Once again, it is very important to stress that it is not possible to use vector signals inside of a System Generator design. Type vector to view the example from c:\training\dsp_flow\labs\lab3 folderNOTE: No Xilinx block supports VHDL generation for vectors. Use them purely for Simulink signal manipulation. Typically you will see the MUX block used in a System Generator design for analysis of results. It is exceptionally useful for viewing multiple signals on a sink. For example, you may want to see the results of filtering block and compare them with the unfiltered original signal. Once again, it is very important to stress that it is not possible to use vector signals inside of a System Generator design. Type vector to view the example from c:\training\dsp_flow\labs\lab3 folder

59. Creating Subsystems All large designs will utilize hierarchy Select the blocks to go into the subsystem. Click and drag to highlight a design region Select “Create Subsystem” inthe Edit Menu Ctrl+G has the same effect Use the modelbrowser under the “View” menu to navigate the hierarchy Hierarchy in the VHDL code generated is determined by subsystems As readability is essential in large designs, subsystems are a very useful feature maintaining the readability of a design. Another way to create a new subsystem is to use the “Subsystem” block from the Simulink => Signals and Systems library. This will provide an empty subsystem window for users to add blocks to. Double-clicking on subsystems is another way to view their contents. It displays the contents of the subsystem in a NEW window. We recommend the Modelbrowser for the majority of navigation, otherwise you will have more windows than you know what to do with. A subsystem will also affect the VHDL code generated by System Generator. The subsystems of a design will directly control the hierarchy in the VHDL generated. A further point to make when analyzing a design in the Xilinx implementation tools is that the name of a subsystem will be added to the component and signal names in that subsystem. Thus, a component will have a name like, e.g., subsystem/AddSub in FPGA Editor. As readability is essential in large designs, subsystems are a very useful feature maintaining the readability of a design. Another way to create a new subsystem is to use the “Subsystem” block from the Simulink => Signals and Systems library. This will provide an empty subsystem window for users to add blocks to. Double-clicking on subsystems is another way to view their contents. It displays the contents of the subsystem in a NEW window. We recommend the Modelbrowser for the majority of navigation, otherwise you will have more windows than you know what to do with. A subsystem will also affect the VHDL code generated by System Generator. The subsystems of a design will directly control the hierarchy in the VHDL generated. A further point to make when analyzing a design in the Xilinx implementation tools is that the name of a subsystem will be added to the component and signal names in that subsystem. Thus, a component will have a name like, e.g., subsystem/AddSub in FPGA Editor.

60. Documenting a Design Double-click the background to create a textbox Type in the text Right-click the text to change format Left-click to move the textbox around A masked subsystem can be given “Help” documentation. More on this later Annotating a block diagram is another method of creating a better documented design. Using this simple “double -click on the background” feature is an excellent way of adding major and minor notes to the design. Anything from a description of a complete design to the maximum and minimum values that can come out of block. The later being very useful in analyzing bit growth.Annotating a block diagram is another method of creating a better documented design. Using this simple “double -click on the background” feature is an excellent way of adding major and minor notes to the design. Anything from a description of a complete design to the maximum and minimum values that can come out of block. The later being very useful in analyzing bit growth.

61. Inports and Outports Allow the transfer of signal values between a subsystemand a parent Inport and Outport blocknames are reflected on thesubsystem Can be found in Simulink ? Sinks (for the Outport)and Simulink ? Sources (for the Inport) When Simulink creates a subsystem, additional blocks are added to the subsystem. These are the inport and outport blocks, which can be thought of as hierarchy connectors. Inport blocks cause input ports to appear on the subsystem; similarly, outport blocks cause output ports to appear. The names of the blocks are reflected in the names on the subsystem. Typically, Simulink numbers these blocks sequentially, but their names can be changed if desired. If you are building a subsystem from scratch using the subsystem block, you must insert Inport and Outport blocks manually. These blocks can be found in the Simulink ? Sources or Sinks library. They are named In1 and Out1, respectively. For further reference: Using Simulink: Creating a Model: Labeling a Subsystem PortsWhen Simulink creates a subsystem, additional blocks are added to the subsystem. These are the inport and outport blocks, which can be thought of as hierarchy connectors. Inport blocks cause input ports to appear on the subsystem; similarly, outport blocks cause output ports to appear. The names of the blocks are reflected in the names on the subsystem. Typically, Simulink numbers these blocks sequentially, but their names can be changed if desired. If you are building a subsystem from scratch using the subsystem block, you must insert Inport and Outport blocks manually. These blocks can be found in the Simulink ? Sources or Sinks library. They are named In1 and Out1, respectively. For further reference: Using Simulink: Creating a Model: Labeling a Subsystem Ports

62. Inputting Data from the Workspace “From Workspace” block can be used to input MATLAB data to a Simulink model Format: t = 0:time_step:final_time; x = func(t); make these into a matrix for Simulink Example: In the MATLAB console, type: One way to use a variable in the MATLAB workspace as an input signal in Simulink is to use the “From Workspace” block in the Simulink ? Sources library. The variable to be used should have a specific format. The first column should have the time sequence, and the following columns should include the corresponding signal data. If required, Simulink will linearly interpolate the data for undefined time step. Another example: Type at the MATLAB prompt >> t = [0 3 6 9 10]; >> x = [-1 1 -1 1 1/3]’ >> simin = [t’, x’]; The [t’, x’] command turns the horizontal vector data into a two-column matrix. This will create a triangular waveform. You can view it by typing >> plot(t, x); Type ‘FromWorkspace’ to view the example from c:\training\dsp_flow\labs\lab3 folderOne way to use a variable in the MATLAB workspace as an input signal in Simulink is to use the “From Workspace” block in the Simulink ? Sources library. The variable to be used should have a specific format. The first column should have the time sequence, and the following columns should include the corresponding signal data. If required, Simulink will linearly interpolate the data for undefined time step. Another example: Type at the MATLAB prompt >> t = [0 3 6 9 10]; >> x = [-1 1 -1 1 1/3]’ >> simin = [t’, x’]; The [t’, x’] command turns the horizontal vector data into a two-column matrix. This will create a triangular waveform. You can view it by typing >> plot(t, x); Type ‘FromWorkspace’ to view the example from c:\training\dsp_flow\labs\lab3 folder

63. Outputting Datato the Workspace There are a number of ways that Simulink can write data out to the workspace. The simplest is to use the “To Workspace” block from the Simulink ? Sinks library. The variable name is specified in the parameters window, as well as the number of data points to save. The save format is also worth noting. It can be an array that contains signal value/s at each time step, or a structure, which has the signal values as one of its fields and contains more information, such as the label of the signal. You may also choose to save time information as part of structure. To access a structure, use the following syntax at the command prompt: >> simout.signals.values Help reference: Using Simulink: Analyzing Simulation Results: Using the To Workspace Block Type ‘ToWorkspace’ to view the example from c:\training\dsp_flow\labs\lab3 folder There are a number of ways that Simulink can write data out to the workspace. The simplest is to use the “To Workspace” block from the Simulink ? Sinks library. The variable name is specified in the parameters window, as well as the number of data points to save. The save format is also worth noting. It can be an array that contains signal value/s at each time step, or a structure, which has the signal values as one of its fields and contains more information, such as the label of the signal. You may also choose to save time information as part of structure. To access a structure, use the following syntax at the command prompt: >> simout.signals.values Help reference: Using Simulink: Analyzing Simulation Results: Using the To Workspace Block Type ‘ToWorkspace’ to view the example from c:\training\dsp_flow\labs\lab3 folder