Forum Discussion

romabo's avatar
romabo
Icon for New Contributor rankNew Contributor
2 years ago
Solved

HLS i++ style IP generation with oneAPI for RTL IP integration in Quartus

Hello, I am new to the tool chain and was wondering if there was a method to generate RTL IP to integrate in Quartus Prime Pro in similar way to HLS i++ compiler but with oneAPI, as the former is be...
High-level Design Tools
  • whitepau_altera's avatar
    whitepau_altera
    2 years ago

    > To take a concrete example, I adapted the add_oneapi example to compute a single precision floating-point mul add (that would use only 1 DSP in Quartus using the dedicated IP). So to the best of my knowledge, the invocation and data interface should be streaming pipes, but it creates some extra logic shown in the report (to handle pipes or avalon mm supposedly as with directive -Xsdsp-mode=prefer-dsp it should use internal registers of the DSP and perform all computation in the DSP slice).

    Can you please share the code you wrote? I am not sure I understand what you are trying to describe.

    In general though, in i++, you could describe a simple adder like this:

    component
int add(int a, int b) {
    return a + b;
}

    This would give you an IP that had two inputs synchronized to a start/busy handshake, and a single output synchronized to a done/stall handshake.


    If you want to get a similar IP with SYCL HLS, you specify a streaming invocation interface using a kernel property, and streaming data interfaces using pipes.


whitepau_altera's avatar
whitepau_altera
Icon for Contributor rankContributor
2 years ago

Thanks for your question.

The SYCL boilerplate is required even for the SYCL HLS IP-authoring mode of our oneAPI DPC++/C++ compiler. We have a number of code samples that can help you create and customize IP.

To quickly get started, there is a platform_designer code sample that walks you through a minimal design that can be exported to platform designer. A video walkthrough is available on our YouTube channel: https://www.youtube.com/watch?v=-f2LA_dyQg0

We have a more complete customer journey in the design hub:
oneAPI Guided Journey

You may be interested in the code samples that pertain to HLS interface customization:
HLS Flow Interfaces Code Samples

  • romabo's avatar
    romabo
    Icon for New Contributor rankNew Contributor
    2 years ago

    Hello,

    Thank you for the clarification and links.

    I took some time to play a bit with examples and look at the different interfaces but I am still uncertain about what interface would be best for my applications.

    I basically want to use the HLS tools to generate optimized computation modules operating and communicating only with RTL. The main idea is to save development time by having HLS automatically enabling registers in DSP and synchronize the intermediate computations. I find this method more practical than generating the DSP IPs in Quartus, that would require to code some HDL to synchronize intermediate computations and estimation of registers to enable for the target fmax. With HLS I could simply describe the operations to be computed and obtain the latency of the module and fmax quickly.

    To take a concrete example, I adapted the add_oneapi example to compute a single precision floating-point mul add (that would use only 1 DSP in Quartus using the dedicated IP). So to the best of my knowledge, the invocation and data interface should be streaming pipes, but it creates some extra logic shown in the report (to handle pipes or avalon mm supposedly as with directive -Xsdsp-mode=prefer-dsp it should use internal registers of the DSP and perform all computation in the DSP slice).

    So I was wondering what was the most suited streaming data interface for RTL communication with minimal logic inference (basically just register input/output with start/done control) instead of the pipe implementing avalon_mm protocol of the example.

    Thank you for your time.