|
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:
- 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.
- 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.
- 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.
Platform
Generation
You can create the embedded processor
subsystem by using either the Base System Builder wizard, the
GUI selection of peripheral cores, or direct text editing of
the microprocessor hardware specification (MHS) file.
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,
);
PlatGen will generate
system.v (in /implementation), bringing out the tristate
signals as shown in the instantiated ppc_subsystem:
system ppc_subsystem
(
.
.
.ddr_dq_I
( ddr_dq
),
.ddr_dq_O (
ddr_dq_o
),
.ddr_dq_T (
ddr_dq_t),
.
.
);
The
EDK-generated system_stub.v – the file we don’t want to use –
added the IOBUF insertion, as shown here for each bus signal:
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:
- Create a synthesis project
- Add files to the synthesis
project
project_top.v
/ppc_subsystem/hdl/system.v
(EDK-generated
subsystem) - Synthesize and review the synthesized project
- Use the generated output files in the ISE
project
fpga_top.edf (top-level source
file)
fpga_top.ncf (sdc-translated
constraints
file) System.v contains the actual embedded subsystem
with the peripheral wrappers instantiated. At the end of
system.v are black_box definitions for each of the wrappers.
Although Synplify doesn’t recognize these XST synthesis
directives, it does realize that it has to create black boxes
and does so without modification.
Synplify will generate the warnings shown in
Figure 2 because of the XST generated
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:
- 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])
- /constraints/constraints.ucf (Xilinx constraints file)
- /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).
- /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:
- /pcores directory in the project directory
- <library_path>/<Library Name>/pcores if -lp
option set (project options/peripheral repository)
- $EDK/hw/XilinxProcessorIPLib/pcores
Pcore Files
The Pcore HDL source
files must be located in the /verilog or /vhdl directory if
they are to be synthesized by XST with PlatGen. If the Pcore
is provided as a Synplify-generated netlist, the EDIF must be
located in the /netlist directory and indicate its black-box
status in a BBD file. Required MPD, PAO, and BBD files for the
peripheral must be placed in the /data directory.
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 | 
