-
Notifications
You must be signed in to change notification settings - Fork 797
[SYCL][DOC] Create spec for Pipe Properties extension #9027
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 1 commit
258abfd
f9e8769
e0e3816
c487148
a09d91d
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,274 @@ | ||
= sycl_ext_intel_data_flow_pipes_properties | ||
|
||
:source-highlighter: coderay | ||
:coderay-linenums-mode: table | ||
|
||
// This section needs to be after the document title. | ||
:doctype: book | ||
:toc2: | ||
:toc: left | ||
:encoding: utf-8 | ||
:lang: en | ||
:dpcpp: pass:[DPC++] | ||
:blank: pass:[ +] | ||
|
||
// Set the default source code type in this document to C++, | ||
// for syntax highlighting purposes. This is needed because | ||
// docbook uses c++ and html5 uses cpp. | ||
:language: {basebackend@docbook:c++:cpp} | ||
|
||
// This is necessary for asciidoc, but not for asciidoctor | ||
:cpp: C++ | ||
|
||
NOTE: Khronos(R) is a registered trademark and SYCL(TM) and SPIR(TM) are | ||
trademarks of The Khronos Group Inc. OpenCL(TM) is a trademark of Apple Inc. | ||
used by permission by Khronos. | ||
|
||
NOTE: This document is better viewed when rendered as html with asciidoctor. | ||
GitHub does not render image icons. | ||
|
||
This document describes an extension that adds compile-time constant properties | ||
to pipes. | ||
|
||
== Notice | ||
|
||
Copyright (c) 2022-2023 Intel Corporation. All rights reserved. | ||
|
||
== Status | ||
|
||
This is an experimental extension specification, intended to provide early | ||
access to features and gather community feedback. Interfaces defined in this | ||
specification are implemented in {dpcpp}, but they are not finalized and may | ||
change incompatibly in future versions of {dpcpp} without prior notice. | ||
*Shipping software products should not rely on APIs defined in this | ||
specification.* | ||
|
||
== Version | ||
|
||
Built On: {docdate} + | ||
Revision: A | ||
|
||
== Contact | ||
|
||
Robert Ho, Intel (robert 'dot' ho 'at' intel 'dot' com) | ||
|
||
== Contributors | ||
|
||
Bo Lei, Intel + | ||
Marco Jacques, Intel + | ||
Joe Garvey, Intel + | ||
Aditi Kumaraswamy, Intel + | ||
Robert Ho, Intel + | ||
Sherry Yuan, Intel + | ||
Peter Colberg, Intel + | ||
Zibai Wang, Intel | ||
|
||
== Dependencies | ||
|
||
This extension is written against the SYCL 2020 specification, Revision 6 and | ||
the following extensions: | ||
|
||
- link:../supported/sycl_ext_intel_dataflow_pipes.asciidoc[SYCL_INTEL_data_flow_pipes] | ||
- link:../experimental/sycl_ext_oneapi_properties.asciidoc[sycl_ext_oneapi_properties] | ||
|
||
== Overview | ||
|
||
This extension introduces properties that establish differences in the | ||
implementation of `sycl::ext::intel::experimental::pipe`. These properties are FPGA specific. An example | ||
of the syntax can be seen below. | ||
|
||
[source,c++] | ||
---- | ||
using pipe = pipe<class some_pipe, int, min_capacity, decltype(properties{uses_valid<true>})>; | ||
---- | ||
|
||
== Feature test macro | ||
|
||
This extension provides a feature-test macro as described in the core SYCL | ||
specification section 6.3.3 "Feature test macros". Therefore, an implementation | ||
supporting this extension must predefine the macro | ||
`SYCL_EXT_INTEL_FPGA_PIPE_PROPERTIES` to one of the values defined in the table | ||
below. Applications can test for the existence of this macro to determine if | ||
the implementation supports this feature, or applications can test the macro's | ||
value to determine which of the extension's APIs the implementation supports. | ||
|
||
[%header,cols="1,5"] | ||
|=== | ||
|Value |Description | ||
|1 |Initial extension version. Base features are supported. | ||
|=== | ||
|
||
=== Pipe properties | ||
|
||
Below is a list of compile-time-constant properties which `pipe` supports. | ||
|
||
```c++ | ||
namespace sycl::ext::intel::experimental { | ||
|
||
struct ready_latency_key { | ||
template <int Latency> | ||
using value_t = oneapi::experimental::property_value< | ||
ready_latency_key, std::integral_constant<int, Latency>>; | ||
}; | ||
|
||
struct bits_per_symbol_key { | ||
template <int Bits> | ||
using value_t = | ||
oneapi::experimental::property_value<bits_per_symbol_key, | ||
std::integral_constant<int, Bits>>; | ||
}; | ||
|
||
struct uses_valid_key { | ||
template <bool Valid> | ||
using value_t = | ||
oneapi::experimental::property_value<uses_valid_key, | ||
std::bool_constant<Valid>>; | ||
}; | ||
|
||
struct first_symbol_in_high_order_bits_key { | ||
template <bool HighOrder> | ||
using value_t = | ||
oneapi::experimental::property_value<first_symbol_in_high_order_bits_key, | ||
std::bool_constant<HighOrder>>; | ||
}; | ||
|
||
enum class protocol_name : std::uint16_t { | ||
AVALON_STREAMING = 0, | ||
AVALON_STREAMING_USES_READY = 1, | ||
AVALON_MM = 2, | ||
AVALON_MM_USES_READY = 3 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Upper-case enum values is a little unorthodox for a SYCL enum. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see that we already have them in the headers with the upper-case names. @gmlueck - Do you have a preference here? Should we keep the uppercase names or rename it here and in the headers? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I agree that lower case is the norm for SYCL. If we are just developing this extension now, I think it would be better to change to lower case. If the extension has already been released and customer code is using the upper case spelling, we could just keep that. I think it's somewhat up to the FPGA team. If they want this extension to match stylistically, we could deprecate the upper case spellings and add the lower case spellings now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. There's no existing customer code as this is the first release, so I think we're fine with changing the header to use lower case now. Does the header change need to be part of a different PR? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm fine with either having it as part of this or as a follow-up patch. 😄 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok, I've added the protocol switch to lower-case in the header to this PR. The header also contained a couple of extraneous properties that came out of an earlier draft of the spec, so I removed those as well. |
||
}; | ||
|
||
struct protocol_key { | ||
template <protocol_name Protocol> | ||
using value_t = oneapi::experimental::property_value< | ||
protocol_key, std::integral_constant<protocol_name, Protocol>>; | ||
}; | ||
|
||
template <int Latency> | ||
inline constexpr ready_latency_key::value_t<Latency> ready_latency; | ||
|
||
template <int Bits> | ||
inline constexpr bits_per_symbol_key::value_t<Bits> bits_per_symbol; | ||
|
||
template <bool Valid> | ||
inline constexpr uses_valid_key::value_t<Valid> uses_valid; | ||
|
||
template <bool HighOrder> | ||
inline constexpr first_symbol_in_high_order_bits_key::value_t<HighOrder> | ||
first_symbol_in_high_order_bits; | ||
|
||
template <protocol_name Protocol> | ||
inline constexpr protocol_key::value_t<Protocol> protocol; | ||
|
||
} // namespace sycl::ext::intel::experimental | ||
``` | ||
|
||
-- | ||
[options="header"] | ||
|==== | ||
| Property | Description | ||
|
||
|`ready_latency` | ||
| Valid values: Non-negative integer value. | ||
|
||
Default value: 0 | ||
|
||
The number of cycles between when the ready signal is deasserted and when the | ||
pipe can no longer accept new inputs. | ||
|
||
This property is not guaranteed to be respected if the pipe is an inter-kernel | ||
pipe. The compiler is allowed to optimize the pipe if both sides are visible. | ||
|
||
|`bits_per_symbol` | ||
| Valid values: A positive integer value that evenly divides by the data type size. | ||
|
||
Default value: 8 | ||
|
||
Describes how the data is broken into symbols on the data bus. | ||
|
||
Data is broken down according to how you set the first_symbol_in_high_order_bits | ||
rho180 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
property. By default, data is broken down in little endian order. | ||
|
||
This property is not guaranteed to be respected if the pipe is an inter-kernel | ||
pipe. The compiler is allowed to optimize the pipe if both sides are visible. | ||
|
||
|`uses_valid` | ||
| Valid values: true or false | ||
rho180 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Default value: true | ||
rho180 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Controls whether a valid signal is present on the pipe interface. If false, the | ||
rho180 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
upstream source must provide valid data on every cycle that ready is asserted. | ||
|
||
This is equivalent to changing the pipe read calls to tryRead and assuming that | ||
steffenlarsen marked this conversation as resolved.
Show resolved
Hide resolved
|
||
success is always true. | ||
|
||
If set to false, the min_capacity pipe class template parameter and ready_latency | ||
rho180 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
property must be 0. | ||
|
||
This property is not guaranteed to be respected if the pipe is an inter-kernel | ||
pipe. The compiler is allowed to optimize the pipe if both sides are visible. | ||
|
||
|`first_symbol_in_high_order_bits` | ||
| Valid values: true or false | ||
|
||
Default value: false | ||
|
||
Specifies whether the data symbols in the pipe are in big-endian | ||
order. | ||
|
||
This property is not guaranteed to be respected if the pipe is an inter-kernel | ||
pipe. The compiler is allowed to optimize the pipe if both sides are visible. | ||
|
||
|`protocol` | ||
| Specifies the protocol for the pipe interface. Currently, the protocols supported | ||
are: *AVALON_STREAMING*, *AVALON_STREAMING_USES_READY*, *AVALON_MM*, and *AVALON_MM_USES_READY*. | ||
|
||
*AVALON_STREAMING* | ||
|
||
Provide an Avalon streaming interface as described in https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-the-interface-specifications.html[Intel® Avalon Interface Specifications]. | ||
|
||
With this choice of protocol, no ready signal is exposed by the host pipe, and the sink cannot backpressure. | ||
|
||
*AVALON_STREAMING_USES_READY* | ||
|
||
Provide an Avalon streaming interface as described in https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-the-interface-specifications.html[Intel® Avalon Interface Specifications]. | ||
|
||
This protocol allows the sink to backpressure by deasserting the ready signal asserted. The sink signifies that it is ready to consume data by asserting the ready signal. | ||
|
||
*AVALON_MM* | ||
|
||
Provide an Avalon memory mapped interface as described in https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-the-interface-specifications.html[Intel® Avalon Interface Specifications]. | ||
|
||
With this protocol, an implicit ready signal is held high, and the sink cannot backpressure. | ||
|
||
*AVALON_MM_USES_READY* | ||
|
||
Provide an Avalon memory mapped interface as described in https://www.intel.com/content/www/us/en/docs/programmable/683091/22-3/introduction-to-the-interface-specifications.html[Intel® Avalon Interface Specifications]. | ||
|
||
With this protocol, an additional memory mapped location is created to hold the ready signal. You must set the uses_valid property to true. | ||
rho180 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
The default protocol is *AVALON_STREAMING_USES_READY* | ||
|==== | ||
-- | ||
|
||
== Revision History | ||
|
||
[cols="5,15,15,70"] | ||
[grid="rows"] | ||
[options="header"] | ||
|======================================== | ||
|Rev|Date|Author|Changes | ||
|1|2022-03-18|Peter Colberg|*Initial public working draft* | ||
|2|2023-04-06|Robert Ho|Removal of unused properties, update protocols | ||
|======================================== | ||
|
||
//************************************************************************ | ||
//Other formatting suggestions: | ||
// | ||
//* Use *bold* text for host APIs, or [source] syntax highlighting. | ||
//* Use +mono+ text for device APIs, or [source] syntax highlighting. | ||
//* Use +mono+ text for extension names, types, or enum values. | ||
//* Use _italics_ for parameters. | ||
//************************************************************************ |
Uh oh!
There was an error while loading. Please reload this page.