Constraints file(cst files)

The C3 hardware synthesizer can be driven with the resource constraints which apply to specific modules. Such constraints are placed in a module-specific constraint file (*.cst). Such a constraint file is needed when the user wants to apply constraints that are operator and module specific e.g. schedule the produced coprocessor operations with up to 5 adders ('+') and up to 3 subtractors ('-') for a module called makepoints (which is a subroutine's name in the ADA code), as in the following example of the contents of file "makepoints_constraints.cst":

op_resource("makepoints","+",5)
op_resource("makepoints","-",3)

As in the above example, there should be no spaces between parameters in each "op_resource..." command.

Memory configuration (mem files)

The C3 hardware synthesizer can be driven with the custom hardware interface configuration file. This file must have a filename which is the same as the ADA package name of the source code (i.e. the hardware interface configuration file should have the name “package_name.mem” when the ADA source code contains package “package_name”). Such interface configuration file is needed when e.g. the user wants to generate external memory interfaces so as for her/his coprocessors to access data that are stored on external (to the coprocessor logic) memory banks.

The general syntax of the memory interface configuration statement is as following:

mem_port(Entry, Timing_group_name, Module_name, My_port_parameter_name, My_data_bus_name, My_data_bus_width, My_address_bus_name, My_address_bus_width, My_read_write_selector_output_name, My_read_enable_name, My_write_enable_name, My_base address_for_this_object, Sync_or_async_IF_type)

Where the following object types are used for the positional parameters of mem_port configuration:

Entry   =  integer number index (incremental for every mem_port configuration statement).
Timing_group_name   =  string identifier of the timing group, to avoid conflicting drive of multiple ports.
Module_name   =  the name of the ADA subprogram.
My_port_parameter_name   =  the name of the ADA subprogram I/O parameter .
My_data_bus_name   =  the name of the data bus port
My_data_bus_width   =  the width in number of bits of the data bus
My_address_bus_name   =  the name of the address bus port
My_address_bus_width   =  the width in number of bits of the address bus
My_read_write_selector_output_name   =  the name of the read/write cycle control output
My_read_enable_name   =  the name of the read enable control output
My_write_enable_name   =  the name of the write enable control output
My_base address_for_this_object   =  the base (start) address in the external memory for this data object group)
My_base Sync_or_async_IF_type   =  string with value = “sync” or “async” (synchronous or asynchronous memory protocol type)

there is no need to include the hardware interface configuration filename in the backend command-line. The tool will automatically pick-up the .mem file that has a filename the same as the ADA source package name.

When there are array aggregate writes to array objects, dont include these array objects in the mem port configuration file, otherwise the produced RTL might not work as expected.

Running the frontend compiler

Running “Compile C”

Click on the buttons with the following order:

  1. Choose a file

  2. Upload C

  3. Compile C

Running “Compile ADA”

If you have aleady a .ADA design file then go to the step 2: Compile ADA and click the buttons with the following order:

  1. Choose a File

  2. Upload ADA

  3. If you have a .mem file then click on the respective choose a file button and t

  4. Upload mem, otherwise click directly the 5th item:

  5. Compile ADA

NOTE: The name of the .mem file must match the ADA program package name. E.g. if in your ADA program you use the name my_package1 to define your ADA library (package) name, then the name of the .mem file that you upload must be my_package1.mem, otherwise the .mem file will be IGNORED by the backend compiler.

(The frontend compiler requires only one argument: the name of the ADA design program e.g. mydesign.ada).

Running the backend compiler

The following steps are needed to execute the backend compiler (step 3: Run HLS (High-level Synthesis step):

If you have a .cst (synthesis resource constraints) file then click on the following order:

  1. Click on “Choose a file”
  2. Click on “Upload cst”

Otherwise ignore this step.

If you don't upload a .cst file, then you don't have to provide command-line arguments. In this case the backend compiler will run by default with the massively-parallel option, and with no constraint at all for available resources. The latter means that the CCC compiler will assume that there is an infinite number of parallel operators for all kinds of operations, and will try to parallelise the RTL as much as possible (which is of course allowed by the data dependencies of the ADA program).

Nevertheless, even without a .cst file uploaded, you can provide global constraint limits such as e.g. " 5" which means that a FSM+datapath architecture will be generated with maximum 5 operators in parallel in each control step of the FSM.

If you have a .cus (custom block) file then click on the following order:

  1. Click on “Choose a file”
  2. Click on “Upload custom”

Otherwise ignore this step.

If you want to give the backend synthesizer a global resource constraint number you click and fill in the button “give global resource constraint limit” and fill in the integer number you want.

HDL maker

This step will generate your coprocessor HDL code (for further implementation with the hardware ventor’s CAD tools).

Try and answer the following questions (respective buttons):

  1. Which HDL you prefer? Click on the HDL of your choice (+) . The default answer is VHDL, but you can choose (System)Verilog if you prefer.
  2. Which structure you prefer? Click on the micro-architecture of your choice (+). Mp for massively-parallel operations with redundancy or dp for datapath+FSM architecture.
  3. Which reset type you prefer? Asyncreset for asynchronous style of reset, or syncreset for synchronous type of reset
  4. Which checkstyle you prefer? Click on ckeck to tell the HDLMAKER to perform correct module hierarchy check, or click on nocheck (faster solution) for no check at all.
  5. (Optional) click on Initialize Options to set all the above options to their default settings.

Run HLS button notes:

This will execute the backend compiler. You can click on the button OK that appears in the please wait message if you want. In any case execution of the backend compiler will continue and for large designs it may take a number of minutes, so please wait. When the backend compiler execution completes, a black runtime screen will appear, just on the right side of the backend compiler section and a link to download your synthesis results will appear. If you press on this link, then you can download on your local space the synthesis results and both the frontend and backend log files with useful information. In the .zip file containing the synthesis results, for every subprogram in the ADA program, two VHDL files will appear: One with the name of the subprogram e.g. my_subprogram1.vhd and another one with the name my_subprogram1_parcs.vhd. The first is the unoptimised (more economic in terms of resources) RTL architecture, and the second is the RTL architecture which is optimised by our PARCS scheduler-optimiser. The second contains an aggressively-parallelized operator architecture and it is the fastest that the generated hardware can execute.

After you collect the synthesis results, you can use the same web-page to start another CCC compilation, by going back to step 1.

When you finish your compilations and you don't need anymore our services, please logout and then close the browser window.

Happy CCC compilations!