The availability of embedded processor subsystems in FPGAs opens the door to a myriad of applications, including embedded network processors, flexible sandbox prototyping, control plane and data path subsystems, and exception handling processors. Today’s FPGAs integrate existing IP cores, interfaces, custom processing engines, and now embedded processor subsystems. You can easily instantiate these subsystems into a top-level HDL design just as you would integrate off-the-shelf IP.

Xilinx® Virtex-4™ FX FPGAs integrate a higher performance IBM™ PowerPC™ core with the new Auxiliary Processor Unit interface. The direct connection to the FPGA fabric facilitates advanced coprocessor designs.

You can use Xilinx Platform Studio/EDK software to design embedded processor subsystems in FPGAs with embedded PowerPC hard processor cores or with Xilinx MicroBlaze™ soft processor cores. Although off-the-shelf peripheral cores and MicroBlaze soft cores are synthesized using XST during EDK platform generation, the overall FPGA project and custom peripheral cores are synthesized with Synplicity® Synplify Pro® 8.0, leveraging new features and superior quality of results.

EDK Subsystem Project Flow
All projects begin by defining an overall FPGA directory structure. The embedded subsystem should reside in its own subdirectory. For example:

fpga_project
/doc	spec and documentation
/src	RTL source code files
/constraints	.ucf, .sdc files
/sim	simulation files
/syn	synthesis project files
/pnr	place and route files
/ppc_subsystem	embedded processor subsystem

Creating a new EDK project in /ppc_subsystem results in a system.xmp project file. Next, EDK Project Options must indicate that it is a subsystem by setting:

1. Design Hierarchy to SubModule
   Specifying the top-instance name of the embedded subsystem (ppc_subsystem). The indicated top-instance name will be used when instantiating the subsystem in the overall top-level design.
2. Synthesis Tool to None
   This indicates that no synthesis tool is used to synthesize the overall design within EDK (the instantiated subsystem will be included later in the Synplify Pro project), although EDK will have used XST (and possibly Synplify Pro) in the platform creation of the subsystem and its peripherals.
3. Implementation Tool Flow to ISE™
   Although Synplify Pro supports mixed languages, you can select Verilog™ or VHDL for EDK output files in Project Options/HDL and Simulation.

Once the MHS file has been constructed, Generate Netlist invokes Platform Generation. PlatGen constructs the netlist, builds and interconnects indicated peripherals, runs DRC checking for errors and warnings, and generates output files.

The EDK Platform generated directories and files include:

ppc_subsystem	top-level instance of the subsystem
/hdl
system_stub.[vhd|v]	HDL subsystem with Xilinx I/O primitives inserted
system.[vhd|v]	HDL subsystem without Xilinx I/O primitives
wrappers.[vhd|v]	implementation netlist peripheral files with instantiated wrappers
/implementation
system_stub.bmm	BMM file with top-level subsystem instance in path
system.bmm	BMM file without the top-level subsystem instance in path
peripherals.ngc files	XST-generated peripheral files

PlatGen will generate two top-level files in /hdl: system_stub.v and system.v. System_stub.v instantiates system.v and adds I/O insertion as Xilinx primitives for all top-level ports. With the processor as a subsystem, system_stub.v is not used because there are other cores, subsystems, and logic in the design. For example, clock signals could be generated by top-level instantiated DCMs and subsystem signals could go to other modules at the same level of hierarchy instead of off-chip.

Also, using Synplify Pro, the I/O insertion is automatic; you don’t need to explicitly instantiate BUFG, IBUF, or OBUF primitives for most I/O standards. Choosing to instantiate system_stub.v as our subsystem would then require editing, removing, or modifying the I/O insertion for the ports not directly connected to an external pin. Once modified, rerunning PlatGen would overwrite this file once again. Another choice might be to rename system_stub.v after editing the file; the downside to this approach is that port/subsystem modifications would require you to recreate the modified/edited file.

A better approach is to instantiate system. v directly in the top-level HDL. Synplify will take care of the necessary I/O insertion where required or, for I/O standards requiring I/O primitive instantiation (for example, LVDS), this should be done directly in the top-level HDL file. System.v is always correct as generated by EDK PlatGen and never needs to be modified. The one additional step required is at the top level, in the case of tri-state signals.

For example, you can define the project top-level ports as:

module fpga_top
     (
     inout        [31:0] ddr_dq,
);

system ppc_subsystem (
       .
       .
       .ddr_dq_I ( ddr_dq ),
       .ddr_dq_O ( ddr_dq_o ),
       .ddr_dq_T ( ddr_dq_t),
       .
       .
       );

IOBUF
       iobuf_28 (
       .    I ( ddr_dq_O[0] ),
       .    .IO ( ddr_dq[0] ),
       .    .O ( ddr_dq_I[0] ),
       .    .T ( ddr_dq_T[0] )
       );

Because we want to be able to instantiate system.v directly into our top level, we must also add the required HDL to control the bidirectional signals:

genvar i;
generate
       for(i=0; i<=31; i=i+1)
       begin: ddrtri
       assign ddr_dq[i] = ddr_dq_t[i] ? 1’bZ : ddr_dq_o[i];
       end
endgenerate

Now EDK-generated subsystem Verilog files do not need to be modified – only instantiated. Bi-directional signals are handled correctly and I/O insertion is either handled automatically by Synplify or explicitly instantiated as Xilinx primitives when required.

Memory Generation
PlatGen will also generate the required memory initialization files for the specified block RAMs coupled with DSOCM, ISOCM (PowerPC only), LMB (MicroBlaze soft processor core only), OPB, and PLB block RAM controllers.

PlatGen will produce two BMM (block RAM memory map) files in the /implementation directory: system.bmm and system_stub.bmm. A BMM file will be used in the ISE flow to indicate the logical data space used by the embedded subsystem and organization of the block RAM memory. In the case of our subsystem, system_stub.bmm would be used, as it contains the complete hierarchical path (because we specified the top-level instance of our subsystem in the project options).

During the ISE bitgen phase of the flow, a system_stub_bd.bmm file will be created in the /implementation directory, indicating the physical location of the block RAMs.

Synplify Project Flow
While XPS/EDK generates the embedded processor subsystem (/implementation/system.v), once created the ppc_subsystem is instantiated exactly as any IP block by adding it to the overall Synplify synthesis project. Whether the underlying embedded processor subsystem used XST, Synplify, or both to create the peripherals and generate the subsystem is irrelevant to the overall Synplify synthesis project.

A typical synthesis project flow, as shown in Figure 1, would follow this order:

1. Create a synthesis project
2. Add files to the synthesis project
   project_top.v
   /ppc_subsystem/hdl/system.v
   (EDK-generated subsystem)
   
3. Synthesize and review the synthesized project
4. Use the generated output files in the ISE project
   fpga_top.edf (top-level source file)
   fpga_top.ncf (sdc-translated
   constraints file)

Synplify will generate the warnings shown in Figure 2 because of the XSTgenerated synthesis directives and empty black box modules. Once reviewed and accounted for, these warnings can now be “hidden” using the Synplify Pro warnings filter, as shown in Figure 3. The filter creates a project.prf file (Figure 4). This file can also be sourced in the Tcl window (source filename).

ProjNav ISE Flow
The /pnr directory is used for the Xilinx ProjNav ISE flow. The fpga_project.npl file is created by ProjNav indicating ISE project options.

The following source files are added to the ISE project:

1. fpga_top.edf (Synplify top-level netlist with ppc_subsystem) fpga_top.ncf (not added as an explicit source file; created from the Synplify contraints [.sdc])
2. /constraints/constraints.ucf (Xilinx constraints file)
3. /ppc_subsystem/implementation/ system_stub.bmm
   This file requires no modification, assuming that the subsystem instantiated in the top-level module uses the same instance name as generated by system_stub.v (that is, the top instance name indicated in the project options).
4. /ppc_subsystem/ppc405_0/code/ executable.elf
   An .elf file (pronounced “elf ”) is a binary data file that contains an executable CPU code image ready for running on a CPU. These files are produced by software compiler/linker tools. Data2BRAM uses .elf files as its basic data input form.

ISE Translate Properties must set the Macro Search Path to point to the /ppc_subsystem/implementation directory for it to find the .ngc peripherals that were black-boxed by Synplify, referenced in fpga_top.edf. These peripherals were created by XST during PlatGen.

Project implementation then follows a normal ProjNav flow producing translate, map, place and route, and timing reports.

You can easily incorporate embedded processor software changes made by the EDK GNU compiler into the final .bit file without hardware recompiles by running Generate Programming File, or alternatively, the Data2Mem utility. When using Data2Mem, the BMM file specified (-bm) must use the BitGen-generated system_stub_bd.bmm in the /implementation directory.

Custom Peripheral Cores
XPS provides a Create Peripheral Wizard that generates core description files and ensures that custom peripherals comply with the Xilinx implementation of the IBM CoreConnect PLB and OPB bus standard. The PLB and OPB buses will connect to an IPIF, allowing user logic to connect to the IPIC side of the interface. Unfortunately, the wizard currently supports only VHDL. Peripheral cores can also be created in Verilog, but cannot take advantage of the templates created by the wizard.

DCR and OCM bus IP cores are not currently supported through a template or wizard. DCR and OCM bus protocols are simple to understand, however, and you can easily create Pcores for these buses either in VHDL or Verilog. The current EDK-provided OCM buses now allow configurable multi-slave capabilities, providing an easy way to create lowlatency slave-only peripherals.

You can integrate custom IP cores into the EDK project either as a black box synthesized with Synplify or as an XST netlist. The Synplify-generated IP core requires associated MPD (microprocessor peripheral definition) and BBD (black box definition) files. The XST netlist is synthesized by PlatGen along with the system and requires MPD and PAO files.

Directory Structure
Figure 5 shows the required Pcore directory structure. PlatGen searches for IP according to the following priorities:

1. /pcores directory in the project directory
2. <library_path>/<Library Name>/pcores if -lp option set (project options/peripheral repository)
3. $EDK/hw/XilinxProcessorIPLib/pcores

The .mpd file specifies PORTs, PARAMETERs, BUS_INTERFACEs, and OPTIONs. For Verilog files, the HDL option specified is OPTION HDL = VERILOG.

If XST is used as the synthesis tool for creation of the peripheral, the netlist option is OPTION IMP_NETLIST = TRUE.

If Synplify is used for the creation of the peripheral, the netlist option is OPTION IMP_NETLIST = FALSE. This would tell PlatGen to not run XST synthesis for this peripheral. A peripheral wrapper is still created and instantiated in system.v and the project synthesis run in Synplify would again create a black box for this peripheral.

Conclusion
You can easily integrate Xilinx embedded processor subsystems created using EDK into a Synplicity flow by instantiating the EDK-generated embedded subsystem into the top-level HDL design. You can use Synplicity tools not only as the overall project synthesis tool but also as the peripheral core synthesis tool in the creation of custom peripherals.

For more information, visit www.CommLogicDesign.com. Comm Logic Design is a Xilinx XPERTS partner focused on architecting, building, and delivering system solutions for wired-network, telecom, and storage applications.

Printable PDF version of this article with graphics.  (1/15/05) 270 KB