"Writing Platform Independent Code"
The paper will focus on three key aspects of platform independent HDL coding styles: portability, maintainability, and verifiability.
Development focused on the creation of code implemented with multiple architectures, which will be used to demonstrate the difficulties that arise when attempting to implement a single design across multiple architectures. The example design implements FIFOs – one block uses a FIFO to send data from the user logic across the network (emulated RapidIO), and the other block uses a FIFO to receive data from the network and pass it to the user logic. While the top-level designs (entities) remain consistent regardless of platform, the internal designs (architectures) are implemented in different manners. One of these architectures relies upon Xilinx internal memories (BlockRAM), while the other uses indexed arrays of registers to emulate the behavior of a memory element. The BlockRAM design is highly efficient, but not usable outside of a Xilinx platform; while the array design may be less efficient unless the synthesis tool properly infers BlockRAM, but is independent of platform. Both architectures provide identical behavior in simulation and should map to near identical hardware, meaning that the choice of architectures will remain transparent to the user.
The example will show that the BlockRAM-based FIFO blocks are incapable of functioning outside a Xilinx platform, by synthesizing the Xilinx-specific architecture to a different platform, such as Altera. Conversely, the example will show that the array-based FIFO blocks can be synthesized to run on more than one platform. This will illustrate the key concept of portability across platforms, which will be of tremendous benefit to designers who target specific applications toward customers who employ a variety of hardware platforms.
Even if a user does not desire to deploy an application across the hardware platforms of multiple vendors, new platforms will continue to become available within the product families of a single vendor. For example, a user of Xilinx hardware may find it necessary to use Virtex, Virtex-II, and Virtex-4 FPGAs during the life of a specific application. Differences among platforms produced by a single vendor, while not typically as dramatic as differences between platforms produced by different vendors, nonetheless present challenges to the users of the hardware. Thus, applications must exhibit maintainability across platforms of a single vendor. The same FIFO blocks used to demonstrate portability could be used to demonstrate maintainability.
The key concept of verifiability refers to the use of design tools to verify that a particular design meets (or exceeds) the standards required to function properly within the vendor independent methodology. Verifiability relies upon the use of “rules” against which the design will be checked. Rules will specify what constructs, styles, components, etc. are allowable for a design to be considered reusable, and will assist the user in defining platform-independent applications (and will ensure that the user is fully aware of what dependencies exist, should the user decide to use platform-dependent architectures for the sake of efficiency). Rules are grouped into “rule-sets,” which can be further grouped into “policies.” Such verification policies provide a powerful set of tools for finding, interpreting, and fixing violations that occur within a design…before the violations cause problems in real implementation.
2005 MAPLD International Conference Home Page