Forum Discussion

Ric2's avatar
Ric2
Icon for New Contributor rankNew Contributor
2 years ago

HLS Avalon interface data width implementable only with 2^N numbers

Hi, this is about a second issue we have while migrating an IP core from HLS workflow to new sycl HLS tools (first is here, might be related but this one stand s for its own as well) .

The HLS defined core has an Avalon streaming interface definition of

using InputStream = ihc::stream_in<ac_int<96, false>;, ihc::bitsPerSymbol<16>, ihc::usesPackets<true>>;
InputStream g_in_stream; // global

After HLS implementation the component tcl script defines a 96 width bus as expected:

#### Streaming interface for g_in_stream
add_interface g_in_stream avalon_streaming sink
...
set_interface_property g_in_stream dataBitsPerSymbol 16
set_interface_property g_in_stream symbolsPerBeat 6
set_interface_property g_in_stream firstSymbolInHighOrderBits 0
set_interface_assignment g_in_stream hls.cosim.name {@g_in_stream}
add_interface_port g_in_stream g_in_stream_data data input 96
...

The migrated sycl HLS core has this aquivalent interface definition

// StreamingBeat struct enables sideband signals in Avalon streaming interface
using StreamingBeatT = sycl::ext::intel::experimental::StreamingBeat<
    ac_int<96, false>, // type carried over this Avalon streaming interface's data signal
    true,           // enable startofpacket and endofpacket signals
    false>;         // disable the empty signal

// Pipe properties
using PipePropertiesT = decltype(sycl::ext::oneapi::experimental::properties(
    sycl::ext::intel::experimental::ready_latency<0>,
    sycl::ext::intel::experimental::bits_per_symbol<16>,
    sycl::ext::intel::experimental::uses_valid<true>,
    sycl::ext::intel::experimental::first_symbol_in_high_order_bits<true>,
    sycl::ext::intel::experimental::protocol_avalon_streaming_uses_ready));

// Image streams
using InPixelPipe = sycl::ext::intel::experimental::pipe<
    InStream,       // An identifier for the pipe
    StreamingBeatT, // The type of data in the pipe
    0,              // The capacity of the pipe
    PipePropertiesT // Customizable pipe properties
    >;

The implementation results in this error:

Compiler Error: The data type carried by _InStream exceeds the bits per symbol. You can either enable the sideband signal 'use empty' or increase the bits per symbol.

Only power of 2 numbers for equal number couples of streamingBeatT data width and PipePropertiesT:bits_per_symbol are implementable.

For e.g. 32bit the component tcl scripts is

#### Channel (Avalon_ST) interface avm_channel_id_acl_c_InStream_pipe_channel_read
add_interface avm_channel_id_acl_c_InStream_pipe_channel_read avalon_streaming sink
...
set_interface_property avm_channel_id_acl_c_InStream_pipe_channel_read  symbolsPerBeat 1
set_interface_property avm_channel_id_acl_c_InStream_pipe_channel_read  dataBitsPerSymbol 32
...

Attached is a reproducer based on streaming data interface example.

Is there any new restriction for Avalon interfaces in the sycl HLS style? How to get the initial interface definition implemented?
Thanks for any suggestion!

oneAPI DPC++/C++ Compiler 2024.1.0 (2024.1.0.20240308), Ubuntu 22.04.4 LTS

Compilation

9 Replies

  • aikeu's avatar
    aikeu
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Ric2,


    I will close the thread if no further question.


    Thanks.

    Regards,

    Aik Eu


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

      Hi Aik,

      there are pending question from above. It would be good to understand if using empty signal is mandatory now (as it was not required for the same interface definition in i++ HLS).

      The second, related question is about conformability to the Avalon ST definition.
      Digging deeper in this I see some long time pending changes which may have influence to the above interface definition requirement:

      To create production designs with this feature it is necessary to have clear and consistent documentation and specifications.

      Any outlook on what is going on in sycl HLS for this topic?

      Thanks,
      Ric.

  • aikeu's avatar
    aikeu
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Ric2,


    Probably I will need some time to consult the team again to have a better understanding referring to your latest questions.


    Anyway, from the current information which I have. Referring to the this document which touch on the Avalon Steaming Sideband Signals:

    "https://www.intel.com/content/www/us/en/docs/oneapi-fpga-add-on/developer-guide/2024-0/host-pipes-rtl-interfaces.html"


    There is a statement which says "You must set use_empty for all packet interfaces that carry more than one symbol of data that have a variable length packet format." following with some example of StreamingBeatstruct to be set for your reference.


    Thanks.

    Regards,

    Aik Eu


  • aikeu's avatar
    aikeu
    Icon for Regular Contributor rankRegular Contributor
    2 years ago

    Hi Ric2,


    Sorry for the late reply, I have consulted the team regarding the issue.

    According to the compiler error: Compiler Error: The data type carried by _InStream exceeds the bits per symbol. You can either enable the sideband signal 'use empty' or increase the bits per symbol.


    Try to set the sideband signal to empty as below will avoid the error:

    false>; // disable the empty signal

    to

    true>; // enable the empty signal


    Thanks.

    Regards,

    Aik Eu


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

      Hi Aik,

      thank you for providing feedback! And yes, the proposed change make the implementation of non power of 2 data width possible.

      However I have two concerns:

      1) Is this a workaround or intended behaviour?

      From the Avalon ST specification I got

      The empty signal is required on all packet interfaces whose data signal carries more than one symbol of data and have a variable length packet format. The size of the empty signal in bits is ceil[log2(<symbols per cycle>)].

      From the tcl build script I see

      set_interface_property avm_channel_id_acl_c_InStream_pipe_channel_read symbolsPerBeat 1

      which I interprete to be a data signal that just carries one symbol of data. This in turn will NOT require the empty signal to be required.

      2) The proposed solution will change the interface of a production design which was originally designed in i++ HLS. I need to be sure that this change is required and consistent.

      May I ask you to elaborate the two concerns from above.

      Thank you! Ric.

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

    Hi again, I'm going to add some more specifics to the problem decribed above. As said, we intend to implement an Avalong Streaming interface with the sycl HLS (icpx) workflow.
    The Avalon Streaming specification has this definition for the dataBitsPerSymbol parameter:

    The icpx error (Report generation) for non power of 2 numbers is

    [ 66%] Building CXX object CMakeFiles/report.dir/src/streaming_data_interfaces.cpp.o
[100%] Linking CXX executable streaming_data_interfaces.report
Compiler Error: The data type carried by _InStream exceeds the bits per symbol. You can either enable the sideband signal 'use empty' or increase the bits per symbol.
Error: Optimizer FAILED.

    Note 1: The error is generated after compilation of the source files while linking.

    Note 2: EMU generation of non power of two numbers works.

    Note 3: With Intel HLS (i++) project it was no problem to generate this non power of two width Avalon Streaming interfaces.

    Hope that helps to identify (and resolve) the problem reported.

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

      Hi Aik Eu,

      thank you for responding. Unfortunatelly the link provided do not reveal any relevant information to the specific problem from above. Anyway, it was helpfull for some other work I'm doing!

      Regards,

      Ric.