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.

You are reporting an issue with the following selected text and/or image within the active document: