Design Portability, Configurations and Constraints

The design for an FPGA is captured in a set of schematic and/or HDL source files. As well as the symbols, wiring and HDL source that makes up the design, there is other essential information that must be captured.

This can be broadly labeled as implementation information, and could include:

• the target FPGA,
• pin configuration details,
• device constraints such as place and route information, and
• design timing requirements.

Rather than locking the design to a specific FPGA-on-PCB combination, separating this information allows design portability. There are other factors that must be considered to ensure that a design is portable, as detailed below.

Maintaining Design Portability

Designs that are created within the system have a high degree of portability, allowing them to be retargeted to different device and board environments with the minimum of difficulty.

This portability is achieved by a combination of:

• Designing with generic components, that can be implemented in all supported device families.
• Altium Designer's plug-in device driver model that allows support for new devices to be dropped in.
• Integrated PCB libraries that support bi-directional data linking from the FPGA design to the PCB design.
• Separating the design – captured in the source documents – from the device-specific and implementation-specific requirements, stored in constraint files.

Generic Components

All of the logical components that are available for designing within an FPGA are targeted for all of the FPGAs supported by the system.

This includes everything from simple gates, all the way up to FPGA microprocessors and other high-level functional blocks. These components are pre-synthesized in a way that is optimized for the target architecture. In some cases, the implementation may be quite different, depending on the capabilities of the underlying target architecture. This allows a new 'high-level' device-independent design methodology to be adopted.

The system also supports designing from vendor-specific primitive libraries, but this is inherently device specific and will result in the design being 'trapped' within the target architecture. This is not recommended unless the highest level of optimization is required. If specific areas of the design do need to use features that are specific to a particular device, then these should be isolated as much as possible in order to avoid unnecessarily compromising the portability of the design.

Nexus Driver Files

There is a large amount of information that must be known about each FPGA device family that is supported by the system. This information is 'plugged into' Altium Designer's underlying DXP integration platform in the form of a Nexus file. These files serve as 'drivers' within the system and contain all of the information, or references to it, that are required to utilize and interact with the chosen device. The Nexus file includes physical information about the device, such as details about the capabilities of each pin (including pin-banking data), boundary scan (JTAG) information and details on how to program the device – everything needed to interact with the device while it is online.

Integrated PCB Libraries

Each device family also includes a PCB-level integrated library. This library contains schematic symbols, PCB footprints and 3D models for all of the devices within the family. For programmable devices such as CPLDs and FPGAs the library includes generic 'un-programmed' symbols that serve as templates for the final fully-programmed device.

These libraries are linked to the device descriptions with the Nexus files to allow all aspects of the device, from the internals of FPGAs to the high-level board level design process, to be fully integrated into the design and debug flow.

Constraining the Design

Rather than storing device and implementation data in the source documents, this information is stored in separate files. These files constrain the design to the target device and PCB layout, allowing the same design to be re-targeted quickly and easily.

Configuring the Constraints

Configurations provide a way for an Altium Designer project to be managed parametrically. For embedded projects this could allow a separate set of settings to be maintained for a debug version and a release version of the product. For a PCB project configurations create the scope for rules to be specified in a separate file, allowing different versions of the board to be developed with different rules.

Focusing specifically on FPGA projects, configurations allow the design to be developed without the need to specify either tool settings or target-device settings, such as project port to device pin mappings, on the source documents.

There are a number of classes of configuration information within an FPGA project, as detailed below:

Specific to the Device and Board

This is where pin information is considered. The physical location of a pin on a device is specific to the combination of a given device and a given board.

Each logical port at the top level of an FPGA design is given a logical name which can be used to reference the pin in a device-independent way. This logical port must be mapped to a physical pin on the target device. The final location of this pin on the device will be driven by board-level issues, such as how the pin best connects to other resources on the board.

For example a data pin, say DATA3, for a particular board may be implemented as pin 21 on a Xilinx QFP package, and as pin H7 on an Altera BGA package. So the same port may be connected through a different pin on a different device, or even if the device is the same, the port may be connected through a different pin on a different board layout. From the logical design perspective, there would be multiple configurations, one for each of these scenarios. Each would have a pin description that included the logical name DATA3, but the physical pin being described would be different.

Another example of device/board specific requirements is pin configuration constraints. For example, if the FPGA device is connected to a 2.5 volt device on one board and a 3.3 volt device on another, then the setup data for the pin can be defined as a constraint for that device and target board.

These constraints could be defined as a description of how a specific device is connected to the resources on a specific PCB.

Specific to a Certain Device

This would include specifications for how to use internal features of the particular device. A good example would be place and route controls for FPGA tools – these are very device specific, but do not have any impact on the way the device is connected to the outside world.

These constraints could be defined as a description of how to configure a specific device's internal resources for a specific FPGA design.

Specific to a Project or Design

This would include requirements which are associated with the logic of the design, as well as constraints on its timing. For example, specifying that a particular logical port must be allocated to a global clock net, and must be able to run at a certain speed. This class of constraint could be added directly to the source documents of the FPGA design. Defining them as separate from the source documents allows the design itself to be more parametric.

These constraints could be defined as a description of how to configure a specific FPGA design.

See Also