IP-XACT Incremental HLS Extensions

The IP-XACT schema allows digital electronic subsystems to be described in terms of their bus interfaces and configurable parameters. It provides basic support both for physical wiring (net-level) interconnection between components and for transactional method calling between component models. But in order to dynamically select pre-compiled subsystems for instantiation by an augmented high-level synthesis HLS flow, additional information about these components needs to be recorded.

The new information includes the presence of combinational paths, deadlocking or conflicting sequences of operations, power-up sequences, whether the component contains internal state and basic timing parameters, such as the expected processing latency and required re-initiation interval.

Two specific new use cases enabled are:

Incremental HLS - use a prior compilation inside a current one,
Multi-FPGA deployment auto partition and inter-wiring generation.

This document is very much presenting work-in-progress. We have made useful experiments with many of the following topics already.

List of Topics

The missing details that we are addressing in our proposal and demonstration implementations include:

Net-level port-structure and formal model of per-port protocol: a standard formalism to encompass pipelined and tokenised FUs that helps map transactional (TLM-style) method calling to various net-level manifestations.
Some child IP blocks may also require access to centralised memory resources and management/debug infrastructure. The layout of their data in shared memories needs orchestrating to avoid clashes, as in software link editing. Child IP blocks may also require other blocks to support them in an overall dependency tree.
For FPGA in the cloud: whether an FU is freely portable between FPGAs or locally bonded out,
Whether stateless (so can be freely mirrored for load balancing),
Combinational delays for overall pipeline design in the instantiating parent,
Sequential dependencies documented (for deadlock avoidance),
Claim space and bandwidth needed in off-chip DRAM memory (using addition of a constant with an adder, the parent can allocate fresh base addresses to each FU instance),
Mutually-exclusive/non-rentrant entry points in the method set,
EIS (an end in itself) tainting to avoid logic trimming of writes that are seemingly never read but important for side effects (eg write to framestore pixels),
Expected area, power and other non-functional attributes,
GUI icon and URLs for further data, as is already widely practiced,
Perhaps license cost/conditions for adding up the cost of use!

This is broad. Individual parts of this vision need to be split of and discussed seperately for any standardisation.

IP-XACT

IP-XACT is an XML schema from Accellera that allows digital electronic subsystems to be described in terms of their bus interfaces and configurable parameters. It was originally targeted for automated configuration and integration of assemblies of IP blocks and one might imagine it captures most of the information needed for this to be done as part of an HLS flow. However, it fails to document many of the fine details required for the optimised schedulling of operations. This is because it was intended mainly as the underlying representation for a GUI tool where port connections are made by hand. The standard has seen relatively wide adoption (e.g. in Socrates from Arm and IP Integrator from Xilinx and it has been successful in its aims.

IP-XACT allows for, so-called, vendor-extensions, which are heavily used in practice. It is the purpose of this note to kick off discussion leading to community adoption and a submission to Accellera.

The forms of IP-XACT document we need to consider are:

a bus specification, giving its signals etc;
a leaf IP block data sheet with links to the design files;

The bus specification (or abstraction as it is called) provides both for transactional modelling and net-level interconnection. It supports point-to-point port connections and broadcast connections. It describes whether a bus needs to be connected and the default tie-off logic values to apply when it is left disconnected.

The current implementation and precise definition of the IP-XACT extensions is being developed in the src files for the HPR L/S logic synthesiser library.

    https://bitbucket.org/djg11/bitbucket-hprls2/src/master/

IP-XACT Extension Element Names

Proposed Component-level Extensions

Per-block (component) attributes used for incremental compilation: Property Element Name Abbreviated Description Units Combinational matrix comb-path Logic delays along Mealy routes. Clock-to-output times can also be noted where the clock is named as an input. This is useful for pipelining in the parent component. FO4 delays Handshake sequential dependencies matrix seq-dependencies Which output handshake nets depend on which input handshake nets. Cross-port dependencies typically arise in arbiters: this matrix is needed for deadlock avoidance. boolean No-re-enter matrix excluded-method For a method (put/aout pair), which others may not be councurrently invoked. These prohibitions arise mainly owing to structural hazards but could also be for locking reasons. method names

Per-block (component) attributes used by HPR System Integrator:

Property Element Name Abbreviated Description Units

Area nfa:area IP Block Silicon Area. NAND2 equivalents

Static Power nfa:static-power Power consumed when idle. nW

Frequency nfa:maxclock Maximum Clock Frequency Estimate. Hz

Portable/Nailed nailed Whether the block must be on a named die. Otherwise it can be dynamically deployed. For instance, video output might only be possible one blade. Physical \FPGA{ name

Mirrorable mirrorable Whether the component may be freely replicated (or concentrated) for load balancing. A ROM is freely mirrorable since it is stateless, whereas reads must be served from the RAM that was written to. arity or `true'

Off-chip memory space required heapspace:size_bytes For each named logical address space, the amount of store needed. bytes

Off-chip lane structure heapspace:lanes For each named logical address space, the amount of store needed. bytes

Logical Memory Bank memgroup For each load and store port, name of logical address space. logical bank id

Bandwidth ... TBD ... For a port, the expected average data transfer rate. bits per second

Priority priority For a port, how important it is that this port has low latency. dimensionless

Domain name domain Name of an equivalence class within which data conservation must be maintained. string

Allocation granularity granularity Round up to be applied when summing disjoint shared uses of a resource (memoryspace normally). bytes

Property	Element Name	Abbreviated Description	Units
Area	nfa:area	IP Block Silicon Area.	NAND2 equivalents
Static Power	nfa:static-power	Power consumed when idle.	nW
Frequency	nfa:maxclock	Maximum Clock Frequency Estimate.	Hz
Portable/Nailed	nailed	Whether the block must be on a named die. Otherwise it can be dynamically deployed. For instance, video output might only be possible one blade.	Physical \FPGA{ name
Mirrorable	mirrorable	Whether the component may be freely replicated (or concentrated) for load balancing. A ROM is freely mirrorable since it is stateless, whereas reads must be served from the RAM that was written to.	arity or `true'
Off-chip memory space required	heapspace:size_bytes	For each named logical address space, the amount of store needed.	bytes
Off-chip lane structure	heapspace:lanes	For each named logical address space, the amount of store needed.	bytes
Logical Memory Bank	memgroup	For each load and store port, name of logical address space.	logical bank id
Bandwidth	... TBD ...	For a port, the expected average data transfer rate.	bits per second
Priority	priority	For a port, how important it is that this port has low latency.	dimensionless
Domain name	domain	Name of an equivalence class within which data conservation must be maintained.	string
Allocation granularity	granularity	Round up to be applied when summing disjoint shared uses of a resource (memoryspace normally).	bytes

Proposed FU Protocol Description Extensions

The basis of the protocol taxonomy is presented in this document: Terminology and Definitions for Multiported Functional Units (PDF).

We propose a wide-coverage, parameterisable net-level protocol model where a port normally has one direction of data, but a port in the other direction may piggy-back on its handshaking arrangements with implicit (in the hardware) timing offset.

This encompasses pipelined, fully-pipelined, put-get, AXI, locallink. Credit-based flow control can be integrated in the future.

It enables black boxes to be wrapped up and deployed (for example, the CAM in the traffic monitor below).

The document encompasses FUs with port protocols like these three:

Although IP-XACT has notions of TLM and net-level ports, detail lacks on how these are mapped to each other. Our work makes this concrete in various ways, such as port sharing.

With port shaing, several methods may be invokable on one port (or port pair). The subfields (busses) of the port then become the union of the subfields of the sharing methods. A further command subfield is added to the put side of the port which carries a method enumeration type whose binary coding is defined in the accompanying IP-XACT.

Per-Port attributes used for incremental compilation:

Property Element Name Abbreviated Description Units

Protocol Class protocol Protocol library, kind, version. This reveals whether it is fixed or variable latency. VLNV quad.

Expected latency expected-latency How long between args and result. clock cycles

Reinit period reinit-latency Minimum interval between new args being presented. clock cycles

Reinit patterm reinit-latency Modulo schedulling arg pattern (eg 101000) unary cycle mask

Postable postable Whether a response needs collecting (the response to a write may need to be read to avoid backup). boolean

Cacheable reftans For a method, whether will always return same answer for same args. boolean

Side-effecting end-in-self A constraint on skipping and order preservation group. For instance, a read of a register can be deleted if the value is ignored, whereas a write to a PIO pin that drives a LED cannot be stripped even if it is not read back, since controlled the LED is an 'end in itself'. Moreover, within groups of side-effecting writes, order may or may not be important, so this is documented. EIS group

Abortable abortable Whether the target is happy to only receive the first words of a put packet. This is important when a reiteration predicate is late arriving: data can eagerly be sent to the FU but the transaction aborted. bool

Abort dynamic energy nfa:dynamic-one Energy used if aborted. fJ

Complete dynamic energy nfa:dynamic-full Energy used if completed. fJ

Input hold inhold Whether inputs need to be held while the unit is busy. For instance, a long-multiplier might read its inputs repeatedly while computing. This falls outside our SSI generic framework however. boolean

Output hold outhold Whether outputs hold their value until they next need to change. This can avoid the parent having to instantiate a holding register. boolean

Property	Element Name	Abbreviated Description	Units
Protocol Class	protocol	Protocol library, kind, version. This reveals whether it is fixed or variable latency.	VLNV quad.
Expected latency	expected-latency	How long between args and result.	clock cycles
Reinit period	reinit-latency	Minimum interval between new args being presented.	clock cycles
Reinit patterm	reinit-latency	Modulo schedulling arg pattern (eg 101000)	unary cycle mask
Postable	postable	Whether a response needs collecting (the response to a write may need to be read to avoid backup).	boolean
Cacheable	reftans	For a method, whether will always return same answer for same args.	boolean
Side-effecting	end-in-self	A constraint on skipping and order preservation group. For instance, a read of a register can be deleted if the value is ignored, whereas a write to a PIO pin that drives a LED cannot be stripped even if it is not read back, since controlled the LED is an 'end in itself'. Moreover, within groups of side-effecting writes, order may or may not be important, so this is documented.	EIS group
Abortable	abortable	Whether the target is happy to only receive the first words of a put packet. This is important when a reiteration predicate is late arriving: data can eagerly be sent to the FU but the transaction aborted.	bool
Abort dynamic energy	nfa:dynamic-one	Energy used if aborted.	fJ
Complete dynamic energy	nfa:dynamic-full	Energy used if completed.	fJ
Input hold	inhold	Whether inputs need to be held while the unit is busy. For instance, a long-multiplier might read its inputs repeatedly while computing. This falls outside our SSI generic framework however.	boolean
Output hold	outhold	Whether outputs hold their value until they next need to change. This can avoid the parent having to instantiate a holding register.	boolean

A snapshot from the HPR L/S src files (coded in FSharp), uses the following example data structure that is one part of what is serialised to/from IP-XACT extensions.

type fun_semantic_t =
    {
        // We add both of these flags, which should normally be inverses, in case some ambiguity arises in certain future definitions.
       fs_nonref:          bool          // Non-referentially transparent (calling it more/less often than intended would be wrong)
       fs_reftran:         bool          // Referentially transparent - same result for same arg always.
       fs_eis:             bool          // An end in itself: ie calling this function has useful side effects (generally the opposite of reftran)
       fs_yielding:        bool          // aka blocking: Values of volatile variables may be changed meantimes.
       fs_mirrorable:      bool          // For load balancing, instances of this FU may be freely mirrored (i.e. further instances created and used instead)
       fs_asynch:          bool          // Happy to be posted (only normally relevant for actions that will typically be eis and have void result).
    // H/W level                     
       fs_inhold:          bool          // This is set when a (non-pipelined) FU can rely on its caller holding its inputs stable throughout the computation.
       fs_outhold:         bool          // Whether an FU implementation maintains its output valid for as long as possible until a new result needs be returned.
       fs_overload_disam:  bool          // Include types in names to distinguish overloaded method variants.
       fs_tlm:             bool          // First argument is an object/instance name.
    }

We shall collect together further aspects of this and write it up, accompanied with concrete examples.

There is one small example here, but we shall shortly replace it with a more complete example. example.zip.

Parent page cards.html.

END.