Show page
Old revisions
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
coram_files [2012/11/29 15:06] gweisz |
coram_files [2012/11/30 13:58] (current) gweisz Page name changed from coram_file_walkthrough to coram_files |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| Three files are required to build a system with CoRAM: | Three files are required to build a system with CoRAM: | ||
| - | - The compute component source code file, commonly Verilog, that describes the hardware performing computation | + | - The core logic source code file, commonly Verilog, that describes the hardware performing computation |
| - The control thread source code, written in C, that coordinates data transfers and synchronization | - The control thread source code, written in C, that coordinates data transfers and synchronization | ||
| - The system specification file, a configuration file that describes how the system will be built, and is often standard to the output platform | - The system specification file, a configuration file that describes how the system will be built, and is often standard to the output platform | ||
| Line 8: | Line 8: | ||
| In addition to these files, there may also be a memory image file containing input data. | In addition to these files, there may also be a memory image file containing input data. | ||
| - | ==== Compute Component Source Code ==== | + | ==== Core Logic Source Code ==== |
| This file contains HDL descriptions of the hardware components that implement computation. It is generally written in Verilog, but can also be written in Bluespec System Verilog (if the Bluespec compiler is available) and compiled to Verilog. | This file contains HDL descriptions of the hardware components that implement computation. It is generally written in Verilog, but can also be written in Bluespec System Verilog (if the Bluespec compiler is available) and compiled to Verilog. | ||
| Line 18: | Line 18: | ||
| The compute components may link to other modules defined in external tools. These modules can be any modules supported by the toolset used for simulation and synthesis, and may even be created by high level synthesis tools such as [[http://www.jacquardcomputing.com/|ROCCC]], [[http://www.xilinx.com/products/design-tools/vivado/index.htm|Xilinx Vivado High Level Synthesis]], or [[http://www.altera.com/devices/processor/nios2/tools/ni2-development_tools.html|Altera C2H]], and linking the block memory connections from the cores created by these tools to CoRAM modules. | The compute components may link to other modules defined in external tools. These modules can be any modules supported by the toolset used for simulation and synthesis, and may even be created by high level synthesis tools such as [[http://www.jacquardcomputing.com/|ROCCC]], [[http://www.xilinx.com/products/design-tools/vivado/index.htm|Xilinx Vivado High Level Synthesis]], or [[http://www.altera.com/devices/processor/nios2/tools/ni2-development_tools.html|Altera C2H]], and linking the block memory connections from the cores created by these tools to CoRAM modules. | ||
| - | [[Detailed CoRAM Hardware Instantiation]] | + | [[http://www.ece.cmu.edu/~coram/coram-examples/Coprims.v|Primitive declarations]] |
| + | |||
| + | [[detailed_coram_hardware_instantiation]] | ||
| ==== Control Thread Source Code ==== | ==== Control Thread Source Code ==== | ||
| + | CoRAM Control Threads coordinate data transfers between CoRAM modules and DRAM (or to off chip entities). In addition to memory operations, they can communicate with hardware modules via Channel FIFOs and Channel Registers, which allows them to perform synchronization tasks, and can perform I/O at the board level through memory mapped serial or PCI Express interfaces. Control threads support a subset of the C programming languages, including loops and other control flow and "printf"-like test formatting in simulation. Important parts of the Control Thread API are: | ||
| + | - cpi_register_thread - Must be called at the beginning of every CoRAM control thread to ensure that the framework processes it correctly | ||
| + | - cpi_get_ram - get a handle to a CoRAM | ||
| + | - cpi_get_channel get a handle to a Channel FIFO or Channel Register | ||
| + | - cpi_write_ram - Blocking write from DRAM to a CoRAM | ||
| + | - cpi_read_ram - Blocking read from CoRAM to DRAM | ||
| + | - cpi_nb_write_ram - Nonlocking write from DRAM to a CoRAM (returns a tag) | ||
| + | - cpi_read_ram - Non-blocking read from CoRAM to DRAM (returns a tag) | ||
| + | - cpi_wait - wait for a Non-blocking access (using a tag) | ||
| + | - cpi_write_channel - write to a Channel FIFO or Channel Register. | ||
| + | - cpi_read_cannel - read from a Channel FIFO or Channel Register - blocks if a FIFO is empty | ||
| + | - cpi_printf - [SIMULATION ONLY] print formatted text | ||
| + | |||
| + | [[http://www.ece.cmu.edu/~coram/coram-examples/cpi.h|Actual header file]] | ||
| + | [[detailed_coram_control_thread]] | ||
| + | ==== System Specification File ==== | ||
| + | The system specification file can be used for advanced tuning, to provide more control over how the system is built. In general, it does not have to be modified, as a default file for each supported platform is often sufficient. Important parameters are: | ||
| + | - platform - Determines general built type. Use "ml605" for hardware (either the Xilinx ML605 or Terasic/Altera DE4), "ml605sim" for simulation with icarus, or "vsim" for simulation with isim. Simulation targets model dram accesses as having a fixed delay (specified in cycles) | ||
| + | - num_mc - Determines the number of memory controllers (and caches) to use. This should be 1 for the ML605, can be 1 or 2 for the DE4, and can be any number for simulation | ||
| + | - topology - Network topology to use. Can be "xbar" for a crossbar, or "ring" for a unidirectional ring | ||
| + | - ports_per_mc - Network ports connected to the memory controller. Must be 4 to reach maximum bandwidth, but may be reduced to create smaller designs. | ||
| + | - dram_delay_cycles - Fixed DRAM delay for simulations | ||
