THIS PAGE CURRENTLY UNDER CONSTRUCTION!!

The Design Flow

1. Enter Design in VHDL
2. Simulate and Debug
3. Compile and Optimize
4. Export EDIF Netlist
5. MAP, Place and Route
6. Configuration File Generation

A customized Makefile template is created to facilitate the design flow from vhdl source code to bit file generation. Note that in the Makefile, some tools need setup files in the same directory for it to work correctly.

A top level VHDL template for each boswell or johnson should be used when creating application. This template file may be updated as time progresses. Therefore, be sure to add modification history to the template file whenever modification is made. A template file undergoing modification should never be used in real designs. You should create a file name that is obvious to others. When the template is stable enough that you think it should be used for designs from there on. Then give it a new version number. For designs that use these templates, the designers should provide information in the design file as to which template it originates from. Following these rules will help us track down bugs quickly later.

A pin assignment preference file is created for each boswell and johnson .

No user should change these files without consultation with Ken. Wrong pin assignment and I/O port type can severely damage the ORCA chips and state machine board.

Design Entry, Simulation, Compilation, Netlist Output (1, 2, 3, 4)

The code should be written as portable as possible unless speed, area, timing issues become important. In that case, you can instantiate ORCA specific components from the ORCA library. In the end, an EDIF should be generated to be used by the AT&T foundary tools for map, place, route, and generation configuration bitfile.

MAP, PLACE, ROUTE, and BIT File Generation (5, 6)

• MAPSH ( EDIF -> NCD ): Mappig is the process of converting a design represented as a network of device-independdent components (for example, gates and flip-flops) into a network of device-specific components (for example, comfigurable logic blocks).
  • EDIF2NGD: translates EDIF netlists into .ngo files that describe designs based on the hierachy and components contained in the input design files.

  • NGDBUILD: takes the .ngo file and expands each component in the design to its underlying ORCA primitives. The resulting .ngd file (logical) contains both the original hierachy and aditional lower hierachical levels (an elaboration of the user design down to primitive terms).

  • MAP: takes a .ngd file and reimplments the design using availabel resources in the target device and builds four files:
    • Circuit Design file (.ncd)
    • ASCII preference file (.prf) containing constraints
    • A .ngm file containing both logical and physical data relative to the target device.
    • An ASCII report file (.mrp) containing information on the particular mapping operation

• PAR: place and route an .ncd file cost-based or timing-driven. timing constraints and pin assignment can be specified in preference file. it also generates three ASCII files:
  • .log file describing a particular PAR run
  • a delay file (.dly) containing delay information for each net in the design
  • .pad file listing all PICs used in the design and their associated pins

• BITGEN: produces a file (.bit or .rbt) that contains configuration information including a definition of all internal logic and interconnections of the FPGA (contained in the .ncd file), plus device-specific information from other files associated with the target device.