TU0129 Converting an existing FPGA Design to the OpenBus System

Converting an existing FPGA Design to the OpenBus SystemSummaryTutorial TU0129 (v2.0) March 04, 2008This tutorial guides you through the process of taking an existing processor-basedFPGA design and converting it to the OpenBus System format.Until now, processor-based FPGA design has typically been performed with a schematic-bias, with all devices in the system layed out on a single schematic sheet. Such designs suffer an inherent complexity, in terms of readability and, more importantly, from a wiring and configuration perspective.Using Altium Designer's OpenBus System feature can greatly reduce such complexity. The fundamental purpose of this system is to represent the processor-peripheral interconnections – in a much more abstract way. It achieves this by providing an environment in which to create your system that is both highly intuitive, streamlined, and less prone to error.This tutorial takes you on a 'voyage of discovery', as you are introduced to the ins-and-outs of converting an existing schematic-based FPGA design to the OpenBus System.The example OpenBus System created using this tutorial is based on the conversion of the existing example projectDSF_Mandelbrot.PrjFpg . This project can be found in the \Examples\NB2DSK1 Examples\DSF Mandelbrot folder of your Altium Designer installation.Although not a pre-requisite for this tutorial, should you wish to familiarize yourself with the concepts and workings of the OpenBus System, refer to the article AR0144 Streamlining Processor-based FPGA design with the OpenBus System. Initial project preparationAs we are converting an existing design, it is a good idea to have that design open. We will need to jump to it for reference – ensuring that we keep the new OpenBus System design true to the configuration of the original. Navigate to, and open, the existing project DSF_Mandelbrot.PrjFpg .We also need to create a new FPGA project in which to 'house' our new design. This needs to include a single schematic top sheet and a single OpenBus System document (which will hold the description of the design's OpenBus System).1. Create a new FPGA project using the File » New » Project » FPGA Project command.2. Right-click on the name for this new project in the Projects panel and choose the Save Project command. Save the projectwith the name OpenBus_DSF_Mandelbrot.PrjFpg , in a new folder called OpenBus DSF Mandelbrot .3. Add a new schematic document by right-clicking on the FPGA project entry in the Projects panel and choosing the AddNew to Project » Schematic command. Save this document with the name OpenBus_DSF_Mandelbrot.SchDoc , in the same folder as the project.Figure 1. Original and new FPGA projects openside-by-side in the Projects panel.4. Add a new OpenBus System document by right-clicking on the FPGAproject entry in the Projects panel and choosing the Add New to Project »OpenBus System Document command. Save this document with thename System.OpenBus , in the same folder as the project.The OpenBus System document is linked to the top-level schematic through asheet symbol. As part of this initial preparation go ahead and place a sheetsymbol on the schematic. You can either place the symbol manually (Place »Sheet Symbol ) or use the Create Sheet Symbol From Sheet Or HDLcommand from the main Design menu. Ensure that:1. The Sheet Symbol's Designator is System2. The Sheet Symbol' s Filename is System.OpenBus .Perform an initial compilation of the new FPGA project. At this point, the twoprojects open in the Projects panel should appear as shown in Figure 1.Converting an existing FPGA Design to the OpenBus SystemCreating the OpenBus SystemNow we have the FPGA project set up, we can concentrate on building the OpenBus System. Before we do, we should identify just what exactly it is that we want to describe using the OpenBus System document.If you open the schematic document DSF_Mandelbrot.SchDoc, from the original FPGA design project, you will see that the main component of the design is the area summarized in Figure 2. This area contains the processor and peripherals, as well as the interconnect and bus mastering components.The remaining circuitry on the original schematic sheet is simply the interface between the peripherals and the physical pins of the FPGA device, the extents of which are depicted by the use of port components. Any additional logic devices will reside in this area of the design. This is circuitry that will, in fact, remain on the top-level schematic sheet of our new FPGA project. We'll get to that later in the tutorial.Figure 2. Identifying the device content for the OpenBus System.Placing components into the systemThe starting point for any OpenBus System document is the placement of the required devices that will consitute the system. These OpenBus components, as they are called, are placed from the OpenBus Palette panel. Open this panel from the menu associated with the OpenBus panel access button, to the bottom-right of the main design window.The panel contains graphical representations of devices available for FPGA design in Altium Designer, grouped by function: • Connectors• Processors• Processor Wrappers• Memories• Peripherals.Converting an existing FPGA Design to the OpenBus SystemTable 1 identifies the devices used in the original schematic-based design, and the corresponding OpenBus components that we must place in the OpenBus System document.Table 1. Required OpenBus components.Schematic component OpenBus componentTSK3000A (32-bit RISC processor) TSK300AWB_FPU (floating point unit) IEEE754 Floating PointVGA32_TFT (VGA controller with TFT interface) VGA 32-Bit TFT ControllerSPI_W (serial peripheral interface controller, byte addressing) SPIWB_PRTIO (parallel port unit) Port IOWB_MEM_CTRL (memory controller, configured as SRAM controller) SRAM ControllerInterconnect2x WB_INTERCON (Wishbone interconnect) 2xWB_MULTIMASTER (Wishbone multimaster) ArbiterPlacement of OpenBus components is simply a case of clicking the required entry in the OpenBus Palette panel and then placing at the desired location in the workspace. Familiar schematic placement controls, such as flipping and rotating allow for fine tuning as needed.Go ahead and place the components as shown in Figure 3. Change the designator text for each component, as shown, to make the description of the system more readable. For the peripherals and memory controller we will use the same names as those specified when configuring the WB_INTERCON devices in the original design. In this way, we will not have to change identifiers used in the associated embedded software code.Figure 3. All OpenBus components placed in the workspace.You will notice little red and green 'bubbles' attached to each component. These are referred to as OpenBus ports and represent the master (red) and/or slave (green) bus interfaces of the component.Converting an existing FPGA Design to the OpenBus SystemAdding ports to the I/O InterconnectThe Interconnect component that will be used to connect the bank of slave peripheral I/O devices to the processor has only a single master port when initially placed – m0 (hover the cursor over a port to view it's designation). As our system has fourperipheral I/O devices, we need to add another three master ports to the component.Figure 4. Adding a port to an Interconnect component. To add a port, simply click on the button on the OpenBus toolbar (or use the Place »Add OpenBus Port command). A dimmed port shape will appear floating on the cursor.As you move the shape next to the perimeter of a component, it will become solid – darkergray with a blue outline (Figure 4). Position the new port as required and click to effectplacement.Note: Ports can be added in clustered groups around an Interconnect component. To adda new port to an existing group, ensure you place the port directly next to the existing port.Go ahead and add three more master ports – m1, m2 and m3. Rotate the Interconnectcomponent and cluster ports m1 and m2 together at the bottom of the component, as perFigure 5. Ports can be arranged after they have been added by clicking and dragging tothe required position around the component.Figure 5. Component INTERCON_IO made ready with additional master ports.Linking system componentsWe have placed the required devices for the system, now it's time to wire them all together. In the OpenBus System, twocomponents are connected to each other using a single link, referred to as an OpenBus link. Links are made between ports of devices, with direction always being from a master port (red) to a slave port (green).Links can be added by clicking on the button on the OpenBus toolbar (or by using the Place » Link OpenBus Ports command). A link is deleted simply by selecting it and pressing the Delete key.When you enter link addition mode, all currently unlinked ports will be filtered, with all otherelements in the system dimmed. If you click to start a link on a master port, all currently unlinkedslave ports will be filtered and available for choosing the termination point of the link. Conversely, ifyou click to start a link from a slave port, all currently unlinked master ports will be filtered andmade available.Note: A link can be graphically modified by selecting it and using its editing handle(s) to adjust itsshape.Go ahead and add links between the devices, as shown in Figure 6.Converting an existing FPGA Design to the OpenBus SystemFigure 6. All components in the OpenBus System fully linked.Configuring the OpenBus SystemNow we have built the OpenBus System, it is time to configure it. The following is a list of areas that generally need to be configured for any OpenBus System:•Processors, peripherals and memories• Interconnect components• Arbiter components•Clock, Reset and Interrupt lines•Processor address spaceLet's consider each of these areas in turn. In each case we will configure the OpenBus System to be the same as that of the original schematic-based design. Although the correct settings are listed for your convenience, you may like to jump back to the original schematic (DSF_Mandelbrot.SchDoc) for your own reference. In doing so, you will get a better appreciation for how much more streamlined configuration of an OpenBus System actually is!Configuring processors, peripherals and memoriesIn our OpenBus System, we have three components that fall under this category of configuration:•TSK3000A processor (designated MCU)•Parallel Port Unit (designated GPIO)•SRAM Controller (designated XRAM).Let's configure these components now.1. Double-click on the processor component to access the Configure (32-bit Processors) dialog. The only change we need tomake is to set the Internal Processor Memory size to 32K Bytes (8K x 32-Bit Words).Converting an existing FPGA Design to the OpenBus SystemFigure 7. Configured processor.2. Double-click on the parallel port unit component to access the Configure OpenBus Port I/O dialog. The only change we needto make is to set the port Kind to Input/Output.Figure 8. Configured parallel port unit.3. Double-click on the SRAM Controller component to access the Configure (Memory Controller) dialog. The only change weneed to make is to set the Size of Static RAM array field to 1 MB (256K x 32-bit).Figure 9. Configured SRAM Controller.Converting an existing FPGA Design to the OpenBus SystemConfiguring Interconnect componentsConfiguration of an Interconnect component in the OpenBus System is a far more streamlined process in comparison to its schematic-based counterpart, WB_INTERCON. The system handles much of the configuration 'behind the scenes' as it were, so information such as data bus width, addressing mode and device type, no longer require user-definition.There is no manual addition/deletion of devices to/from the Interconnect. If a link exists between a peripheral and the Interconnect, then the device will automatically be added.There is also no manual definition of the Master Address Size. This too is taken care of in the background, dependent on which port of the processor the Interconnect is linked – IO (24-bit) or MEM (32-bit).There are, in fact, only three pieces of information required to complete the configuration of the Interconnect for each slave device – the Base Address, the Decoder Address Width and the Address Bus Size. Default information for each comes directly from the peripheral component itself.For more detailed information on the Interconnect component, refer to the document TR0170 OpenBus Interconnect Component Reference.Peripheral I/O InterconnectWe will now configure the Interconnect component that is linked to the TSK3000A processor's IO port.1. Double-click on the Interconnect component designated INTERCON_IO to access the Configure OpenBus Interconnectdialog. The decoder address width for each peripheral is set to 8 bits by default and we can leave this as it is the same in the original design. The address bus sizes – the number of address bits required to drive each device – are also set correctly.2. In the Address field for the IEEE754 Floating Point Unit (FPU) peripheral, enter the value 0xFF0000003. In the Address field for the VGA 32-Bit TFT Controller (VGA) peripheral, enter the value 0xFF1000004. In the Address field for the SPI (SPI) peripheral, enter the value 0xFF2000005. In the Address field for the Port IO (GPIO) peripheral, enter the value 0xFF300000The settings in the dialog should now appear as those in Figure 10.Figure 10. Configured Interconnect component (INTERCON_IO).Memory InterconnectWe will now configure the Interconnect component that is linked to the TSK3000A processor's MEM port.1. Double-click on the Interconnect component designated INTERCON_MEM to access the Configure OpenBus Interconnectdialog. The decoder address width for the memory controller is set to 8 bits by default and we can leave this as it is the same in the original design. The address bus size – the number of address bits required to drive the controller – is also set correctly.2. In the Address field for the SRAM Controller (XRAM) peripheral, enter the value 0x01000000.The settings in the dialog should now appear as those in Figure 11.Converting an existing FPGA Design to the OpenBus SystemFigure 11. Configured Interconnect component (INTERCON_MEM).Configuring Arbiter componentsConfiguration of an Arbiter component in the OpenBus System is also a more streamlined process, in relation to its schematic-based counterpart, WB_MULTIMASTER. The system again handles much of the configuration for you, so information such as data and address bus widths no longer require user-definition.Only two pieces of information are required through the dialog to configurethe Arbiter – the access Type and the Master With No Delay.Figure 12. Configured Arbiter component.1. Double-click on the Arbiter component to access the Configure OpenBusArbiter dialog.2. In the Type region of the dialog, ensure that the Priority option isselected. In this mode of access, masters access the slave in strictsequence, starting with the master connected to port s0 (highestpriority).3. In the Master With No Delay region of the dialog, ensure that port s0 isselected. As we have connected the VGA Controller to port s0 of theArbiter component, we need to ensure it is nominated to be the masterwithout delay – receiving instant access to the memory when the Arbiteris in an 'idle' state. The master with no delay is distinguished graphically on the Arbiter component by use of red text for its port number. In our system, slave port s0 is the master with no delay, and so its port number text – 0– appears in red.For more detailed information on the Arbiter component, refer to the TR0171 OpenBus Arbiter Component Reference . Configuring clocks, resets and interruptsManagement of the clock, reset and interrupt lines for the system are handled in the OpenBus Signal Manager dialog (Tools » OpenBus Signal Manager ). These lines are handled separately from the main bus link between devices, to simplify the bus. We shall use the tabs available in this dialog to now define each of these areas.1. If you have not already done so, open the OpenBus Signal Manager dialog.2. We shall use a single clock net as input to all applicable devices in the system. On the Clocks tab of the dialog, ensure thatthe Net to connect to field for each device is set to <Default> and that the Default clock field is set to CLK_I.Figure 13. Configured clock lines for the system.Converting an existing FPGA Design to the OpenBus System 3. We shall also use a single reset net as input to all of the applicable devices in the system. On the Resets tab of the dialog,ensure that the Net to connect to field for each device is set to <Default> and that the Default reset field is set to RST_I.Figure 14. Configured reset lines for the system.4. In the original FPGA design, only the SPI Controller and the VGA Controller are capable of generating interrupts. In bothcases, the interrupt lines are not used. We can therefore leave the Interrupts tab of the dialog in its default state, with each individual interrupt line for these two peripheral devices set as Not Connected. The Interrupts tab also lists each of the interrupt pins for the processor, allowing the ability to import interrupts from devices external to the OpenBus System document. As our design has no such external devices, all entries simply remain as Not Exported, meaning that no interrupt lines will be made available on the top-level design schematic.Figure 15. Configured interrupt lines for the system.Wondering what the final tab of this dialog is for, and why it hasn't been mentioned? The External connection summary tab offers just that – a non-editable listing of all devices and the external interface signals associated to them, and which will be made available on the top-level design schematic.Configuring processor address spaceIn the OpenBus System we have built, we have connected slave memory and peripheral devices to the processor's MEM and IO ports respectively. Unlike schematic-based design however, we are not required to manually define the mapping of these devices into the processor's address space, it is handled for us. We have already supplied the mapping information through the respective configuration dialogs. The OpenBus System simply takes this information and maps each device memory or peripheral device accordingly.Within the OpenBus System, defined memories and peripheral I/O devices will be automatically mapped into the processor's address space. The mapping is dynamic – any changes made to physical memory devices or peripheral I/O (e.g. base addresses) will be reflected directly in the associated memory and peripheral configuration dialogs for the processor.Mapping physical memoryLet's take a look at the mapping of physical device memories into the processor's address space.Converting an existing FPGA Design to the OpenBus System1. In the OpenBus System document, right-click on the processor component and choose the Configure Processor Memorycommand from the menu that appears. The Configure Processor Memory dialog appears. Verify that the physical memory (device memory) defined in the OpenBus System has been automatically mapped into the processor's address space. For our system, we have two blocks of device memory mapped into the processor – the internal processor memory (named MCU) and the external SRAM (named XRAM), as shown in Figure 16.Figure 16. Mapping of device memory in the system.2. Ensure that the option to generate hardware.h (C Header File) is enabled.Mapping peripheral I/ONow let's take a look at the mapping of peripheral devices into the processor's address space.1. In the OpenBus System document, right-click on the processor component and choose the Configure ProcessorPeripheral command from the menu that appears. The Configure Peripherals dialog appears. Verify that the peripheral devices defined in the OpenBus System have been automatically mapped into the processor's address space. For our system, we have four mapped peripherals – the Port I/O Unit (named GPIO), the Serial Peripheral Interface Controller (named SPI), the 32-bit VGA Controller with TFT interface (named VGA) and the Floating Point Unit (named FPU), as shown in Figure 17.Figure 17. Mapping of defined peripheral devices in the system.2. The option to generate hardware.h (C Header File) is already enabled, since we enabled it when verifying the devicememory mapping.The UseInDSF parameterEach peripheral component in the OpenBus System has an associated UseInDSF parameter. This parameter essentially tells the embedded software to use the standard device driver code associated with the peripheral. Such code will include various functions related to operation with the peripheral, for example a function to initialize the peripheral.All peripherals in the OpenBus System have this parameter set to True by default. It depends on the design as to whether the standard device driver code is required or whether such driver-related functions are specified explicitly in the embedded software, in which case the standard driver code is not required. In such cases, this parameter should be set to False.In the schematic document of the original FPGA design (DSF_Mandelbrot.SchDoc) only the VGA Controller has this parameter added and set to True. In fact, it is only the SPI Controller in this particular design which has specific driver functions written as part of the embedded code. To enable the standard driver code as well will result in compilation errors and failure to build the embedded software. So although we need only disable use of the standard driver code for this one peripheral, to keep our new OpenBus System version of the design the same as the original, we shall disable use of the standard driver code for the FPU and parallel port unit as well.1. Open the OpenBus Inspector panel. This can be done by selecting the entry for the panel in the menu associated with theOpenBus panel access button, towards the bottom-right of the main design window.2. In the workspace, select the FPU, SPI and GPIO peripheral components.3. In the Parameters region of the OpenBus Inspector panel, locate the UseInDSF parameter and change its value to False(Figure 18).Figure 18. Disabling use of standard device driver code for selected system peripherals.Interfacing to the top-level schematicWith the OpenBus System defined, we now need to interface the OpenBus System document with our top-level schematic. This, as has been mentioned previously, is handled through a sheet symbol placed on the schematic sheet.The sheet entries required to populate the sheet symbol can be obtained through use of the sheet entries and ports synchronization feature. Access this feature through the Sheet Symbol Actions » Synchronize Sheet Entries and Ports command, available from the right-click context menu for the sheet symbol. The Synchronize Ports To Sheet Entries On System dialog will appear (Figure 19).Figure 19. Use the synchronize sheet entries and ports feature to hook-up the OpenBus System.All ports from the OpenBus System document will be initially listed as unmatched ports. The ports themselves actually come from two places:•Ports automatically derived based on the external interfaces of the peripheral devices (I/O peripherals and memory controllers).•Ports derived from the clock and reset line net definitions in the OpenBus Signal Manager dialog.When using the dialog to add sheet entries to the sheet symbol, it is a good idea to select each bank of related ports in turn, rather than all ports at once. This will make placement of the sheet entries within the sheet symbol that much easier. SimplyFigure 20. Sheet entry placement.group select the required ports and click the Add Sheet Entries buttonbeneath the list – the sheet entries will float on the cursor ready forplacement (Figure 20).Go ahead and add sheet entries for all existing ports at this time. Oncesheet entries for all ports have been added, the sheet symbol will be fullysynchronized with the underlying OpenBus System document.Residual schematic wiringThe last stage required to fully hook the OpenBus System into the FPGAdesign is to wire-up the external interface circuitry. This is the circuitry thatruns between the external interfaces of the peripherals in the OpenBusSystem, and the physical pins of the FPGA device in which the design willbe programmed. It includes any additional logic devices used in the design.1. Open the original design schematic document,DSF_Mandelbrot.SchDoc .2. Copy the circuitry relating to the VGA 32-Bit TFT Controller device(Figure 21). Do not include the wiring associated with the Controller'smaster interface as this is already defined as part of the OpenBusSystem. 3. Paste this circuitry into the top-level sheet of our new design, OpenBus_DSF_Mandelbrot.SchDoc .4. Wire this circuitry to the corresponding sheet entries for this peripheral (Figure 21). Note: You may need to rearrange sheetentries for peripheral interfaces in general, in order to match the layout of the port components and thereby make theschematic wiring as neat and as readable as possible.Figure 21. Copying circuitry from the old design to paste and wire in the new design.5. Repeat steps 1-4 for each of the following interface circuitry:-Circuitry relating to the SPI Controller- Circuitry relating to the Parallel Port Unit-Circuitry relating to the SRAM Controller.6. Copy and paste the original circuitry for the external clock and reset lines and then:- Delete the CLK and RST net labels-Move the circuitry to connect directly into the RST_I sheet entry.-Place a new wire from the CLK_BRD side of the FPGA_STARTUP8 device, to the CLK_I sheet entry.7. Copy and paste the required components for implementation of the Soft JTAG chain (NEXUS_JTAG_CONNECTOR andNEXUS_JTAG_PORT).8. Copy and paste the informational note.Your final top-level schematic sheet should appear as shown in Figure 22.Figure 22. Completed top-level schematic.Where to now?That's it! – congratulations, you've just built your first FPGA design incorporating an OpenBus System. From here-on-in, the design is identical in behavior to the original schematic-based design. You can test this for yourself by processing the design and downloading to the physical FPGA device resident on the daughter board plug-in of your Desktop NanoBoard NB2DSK01.This will involve:•Linking the associated Embedded Software project (Mandelbrot.PrjEmb) and ensuring the Application Memory mapping is defined as required. This mapping is defined as part of the embedded project options, and determines how the mapped physical device memory blocks are used by the embedded software.•Configuring the FPGA project to target the required physical FPGA device (including assignment of applicable constraint files). This can be achieved most easily using the auto-configuration feature.•Processing the design using the Devices view (View » Devices View), and downloading the resulting programming file to the target FPGA device on the daughter board.•Observing the Mandelbrot pattern on the NB2DSK01's TFT LCD panel.。