HxS Annotations

The HxS language uses annotations as a way to provide specific directions to the HxS compiler backend which is provided by HxS extensions. The following sections give an overview of the available annotations and some guidance for their usage.

Annotation Syntax

Annotations are always attached to a specific HxS object. The following code listing shows the general syntax of a generator annotation that is attached to a interface object.

    @Generator('key', 'value')
    interface MyInterface {}
                        

The syntax shown above can be applied to any HxS object. The tables below give an overview of the available annotations for each generator.

VHDL Annotations

The following table gives an overview of the available annotations for the VHDL generator.

Key	Value (default is bold)	Object	Description
vhdl.letter_case	camel_case, snake_case	interface	Determines the letter case to use for VHDL generated code.
vhdl.file_header	none, eccelerators	interface	Determines whether to generate a file header.
vhdl.bus_reset	none, sync, async	register	Determines whether there is a bus reset and if it is synchronous or asynchronous.
vhdl.use_generic	false, true	value, reset	Determines whether the value should be provided using a constant or generic.
vhdl.preinit_signals	false, true	interface	Determines whether to pre-initialize VHDL signals.
vhdl.naming.scope	interface, block, register, delegate, data, enum, reserved, select, reset, value, none	interface	Determines the scope to use for generated names. By default, the generator decides how to extend names in order to prevent duplicates. The generators aim is to use the shortest possible name that is unique.
vhdl.comments.doxygen	none, brief, detailed	interface	Determines whether to generate Doxygen comments for the generated VHDL package.

Docs Annotations

The following table gives an overview of the available annotations for the Docs generator.

Key	Value (default is bold)	Object	Description
docs.file_header	none, eccelerators	interface	Determines whether to generate a file header.
docs.file_type	rst, docx, ReStructured Text, Microsoft Word	interface	Determines the file type to generate. It is possible to use the abbreviation rst or full name ReStructured Text.

C Annotations

The following table gives an overview of the available annotations for the C generator.

Key	Value (default is bold)	Object	Description
c.letter_case	camel_case, snake_case	interface	Determines the letter case to use for C generated code.
c.file_header	none, eccelerators	interface	Determines whether to generate a file header.
c.naming.scope	interface, block, register, delegate, data, enum, reserved, select, reset, value, none	interface	Determines the scope to use for generated names. By default, the generator decides how to extend names in order to prevent duplicates. The generators aim is to use the shortest possible name that is unique.
c.comments.doxygen	none, brief, detailed	interface	Determines whether to generate Doxygen comments for the generated C header file.
c.comments.native	none, brief, detailed	interface	Determines whether to generate native C comments for the generated C header file.

Python Annotations

The following table gives an overview of the available annotations for the Python generator.

Key	Value (default is bold)	Object	Description
python.letter_case	camel_case, snake_case	interface	Determines the letter case to use for Python generated code.
python.file_header	none, eccelerators	interface	Determines whether to generate a file header.
python.naming.scope	interface, block, register, delegate, data, enum, reserved, select, reset, value, none	interface	Determines the scope to use for generated names. By default, the generator decides how to extend names in order to prevent duplicates. The generators aim is to use the shortest possible name that is unique.
python.comments.native	none, brief, detailed	interface	Determines whether to generate native Python comments for the generated files.