greek64/rtps-fpga
2
1
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Code Refactoring

Browse Source
This commit is contained in:
Greek 2022-01-24 15:10:48 +01:00
parent 59bff52832
commit a99b8f13c8
4 changed files with 82 additions and 80 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

142
src/IDL-VHDL_Ref.txt
View File

@ -16,25 +16,25 @@ If there is no next declared member, stage 'SKIP_PAYLOAD' is selected.
The signal 'align_offset' keeps track of the current alignement offset (Basically byte_count mod 8). The signal 'align_offset' keeps track of the current alignement offset (Basically byte_count mod 8).
The general procedure is that the input is latched ('data_in_latch') allowing to work Byte-oriented, since The general procedure is that the input is latched ('data_in_latch') allowing to work Byte-oriented, since
the input is word-sized. Each time the 'align_offset' reaches "x11" a new input word is latched. the input is word-sized. Each time the 'align_offset' reaches b"X11" a new input word is latched.
The CDR Encodings of all types are Byte aligned. The CDR Encodings of all types are Byte aligned.
PRIMITIVES TYPES PRIMITIVES TYPES
================ ================
Primitive Types are directly latched into registers of equal size (name <TYPENAME>_lach), that are Primitive Types are directly latched into registers of equal size (name <NAME>_lach), that are
accesible directly via a port of the same name (i.e. <TYPENAME>). accesible directly via a port of the same name (i.e. <NAME>).
The name of the generated decode_stage is GET_<TYPENAME>. The name of the generated decode_stage is GET_<NAME>.
The generated decode_stage first checks the alignement and aligns the stream using the 'ALIGN_STREAM' stage. The generated decode_stage first checks the alignement and aligns the stream using the 'ALIGN_STREAM' stage.
* Primitive size 1 * Primitive size 1
The input is directly latched using the get_sub_vector function together with the current 'align_offset', The input is directly latched using the get_sub_vector function together with the current 'align_offset',
1 is added to the 'align_offset', the decode_stage of the next declared member is taken, and the 'FETCH' 1 is added to the 'align_offset', the decode_stage of the next declared member is taken, and the 'FETCH'
stage is called if the current 'align_offset' is "x11". stage is called if the current 'align_offset' is b"X11".
* Primitive size 2 * Primitive size 2
The input is directly latched using the get_sub_vector function together with the current 'align_offset', The input is directly latched using the get_sub_vector function together with the current 'align_offset',
2 is added to the 'align_offset', the decode_stage of the next declared member is taken, and the 'FETCH' 2 is added to the 'align_offset', the decode_stage of the next declared member is taken, and the 'FETCH'
stage is called if the current 'align_offset' is "x1x". stage is called if the current 'align_offset' is b"X1X".
* Primitive size 4 * Primitive size 4
The input is directly latched, 4 is added to the 'align_offset', the decode_stage of the next declared The input is directly latched, 4 is added to the 'align_offset', the decode_stage of the next declared
member is taken, and the 'FETCH' stage is called. member is taken, and the 'FETCH' stage is called.
@ -44,12 +44,14 @@ The generated decode_stage first checks the alignement and aligns the stream usi
and the last sub-stage is for latching the final signal in it's final place. In the last sub-stage 8 is and the last sub-stage is for latching the final signal in it's final place. In the last sub-stage 8 is
added to the 'align_offset' and the decode_stage of the next declared member is taken. added to the 'align_offset' and the decode_stage of the next declared member is taken.
NOTE: The extra sub-stage is used to push the signal to a memory in a single operation NOTE: The extra sub-stage is used to push the signal to a memory in a single operation
NOTE: If there is no next declared member, the second-to-last stage should NOT call the "FETCH" stage
* Primitive size 16 * Primitive size 16
The decode_stage is divided with the help of 'cnt' in 5 sub-stages. A helper quad-word latch 'qw_latch' The decode_stage is divided with the help of 'cnt' in 5 sub-stages. A helper quad-word latch 'qw_latch'
is used. The first 4 sub-stages latch the word into the helper latch (calling 'FETCH' stage each time), is used. The first 4 sub-stages latch the word into the helper latch (calling 'FETCH' stage each time),
and the last sub-stage is for latching the final signal in it's final place. In the last sub-stage 16 is and the last sub-stage is for latching the final signal in it's final place. In the last sub-stage 16 is
added to the 'align_offset' and the decode_stage of the next declared member is taken. added to the 'align_offset' and the decode_stage of the next declared member is taken.
NOTE: The extra sub-stage is used to push the signal to a memory in a single operation NOTE: The extra sub-stage is used to push the signal to a memory in a single operation
NOTE: If there is no next declared member, the second-to-last stage should NOT call the "FETCH" stage
The alignements and sizes for IDL primitive types are following: The alignements and sizes for IDL primitive types are following:
@ -89,51 +91,51 @@ the contents.
SEQUENCE SEQUENCE
-------- --------
The name of the generated memory is <TYPENAME>_mem, and the memory signals are connected via signals of The name of the generated memory is <NAME>_mem, and the memory signals are connected via signals of
name <TYPENAME>_mem_<SIGNALNAME>. The generated memory uses a MAX_BURST_LENGTH of 1. name <NAME>_mem_<SIGNALNAME>. The generated memory uses a MAX_BURST_LENGTH of 1.
Following Port signals are defined: Following Port signals are defined:
NAME DIRECTION CONNECTED NAME DIRECTION CONNECTED
<TYPENAME>_len out <TYPENAME>_len_latch <NAME>_len out <NAME>_len_latch
<TYPENAME>_addr in <TYPENAME>_mem_addr in 'IDLE' stage <NAME>_addr in <NAME>_mem_addr in 'IDLE' stage
<TYPENAME>_ready out <TYPENAME>_mem_ready_in in 'IDLE' stage, else '0' [NOTE: ANDing for aggregated elment types (see Structures below)] <NAME>_ready out <NAME>_mem_ready_in in 'IDLE' stage, else '0' [NOTE: ANDing for aggregated elment types (see Structures below)]
<TYPENAME>_ren in <TYPENAME>_mem_read and <TYPENAME>_mem_valid_in in 'IDLE' stage <NAME>_ren in <NAME>_mem_read and <NAME>_mem_valid_in in 'IDLE' stage
<TYPENAME>_valid out <TYPENAME>_mem_valid_out [NOTE: ANDing for aggregated elment types (see Structures below)] <NAME>_valid out <NAME>_mem_valid_out [NOTE: ANDing for aggregated elment types (see Structures below)]
<TYPENAME>_ack in <TYPENAME>_mem_ready_out in 'IDLE' stage <NAME>_ack in <NAME>_mem_ready_out in 'IDLE' stage
<TYPENAME> out <TYPENAME>_mem_data_out <NAME> out <NAME>_mem_data_out
2 decode_stages are defined: 2 decode_stages are defined:
* GET_<TYPENAME>_LENGTH * GET_<NAME>_LENGTH
The first decode_stage is similar to a 4-byte primitive decode stage and latches the length of the The first decode_stage is similar to a 4-byte primitive decode stage and latches the length of the
sequence into the <TYPENAME>_len_latch. If the length is equal zero, the decode_stage of the next sequence into the <NAME>_len_latch. If the length is equal zero, the decode_stage of the next
declared member is taken, instead of the GET_<TYPENAME>. A special <TYPENAME>_cnt counter (used to declared member is taken, instead of the GET_<NAME>. A special <NAME>_cnt counter (used to
index the type specific memory) is initialized to 0. index the type specific memory) is initialized to 0.
* GET_<TYPENAME> * GET_<NAME>
This stage is similar to the respective primitive decode_stage with following valiations: This stage is similar to the respective primitive decode_stage with following valiations:
The <TYPENAME>_cnt is used to set the current <TYPENAME>_mem_addr. On sucessful latch The <NAME>_cnt is used to set the current <NAME>_mem_addr. On sucessful latch
(<TYPENAME>_mem_valid_in and <TYPENAME>_ready_in = '1') the align_offset is incremented by the (<NAME>_mem_valid_in and <NAME>_ready_in = '1') the align_offset is incremented by the
respective size, the <TYPENAME>_cnt is incremented, and if the current <TYPENAME>_cnt is equal to respective size, the <NAME>_cnt is incremented, and if the current <NAME>_cnt is equal to
<TYPENAME>_len-1, the decode_stage of the next declared member is taken. <NAME>_len-1, the decode_stage of the next declared member is taken.
ARRAY ARRAY
----- -----
Array is similar to the sequence, but has no length encoding (since it always has the smae size). Array is similar to the sequence, but has no length encoding (since it always has the smae size).
That means that there is no <TYPENAME>_len port signal, <TYPENAME>_len_latch latch, and also no That means that there is no <NAME>_len port signal, <NAME>_len_latch latch, and also no
GET_<TYPENAME>_LENGTH stage. GET_<NAME>_LENGTH stage.
The initialization of the <TYPENAME>_cnt has to be done in the previous decode_stage. The initialization of the <NAME>_cnt has to be done in the previous decode_stage.
The <TYPENAME>_cnt is compared against the fixed array length consatnt form the type package. The <NAME>_cnt is compared against the fixed array length consatnt form the type package.
MAP MAP
--- ---
Maps are basically sequences of aggregated element type [4]: Maps are basically sequences of aggregated element type [4]:
struct <TYPENAME>_Entry { struct <NAME>_Entry {
<key_type> key; <key_type> key;
<value_type> value; <value_type> value;
}; };
sequence<<TYPENAME>_Entry> <TYPENAME>; sequence<<NAME>_Entry> <NAME>;
For simplicity the name of the structure is ignored. For simplicity the name of the structure is ignored.
(I.e. the generated names are <TYPENAME>_key, <TYPENAME>_value instead of (I.e. the generated names are <NAME>_key, <NAME>_value instead of
<TYPENAME>_<TYPENAME>_Entry_key and <TYPENAME>_<TYPENAME>_Entry_value) <NAME>_<NAME>_Entry_key and <NAME>_<NAME>_Entry_value)
AGGREGATED TYPES AGGREGATED TYPES
================ ================
@ -141,21 +143,21 @@ AGGREGATED TYPES
STRUCTURE STRUCTURE
--------- ---------
If a type member is in itself another structure, the generated <TYPENAME> ports,signals,memories.stages,etc If a type member is in itself another structure, the generated <NAME> ports,signals,memories.stages,etc
are split into <TYPENAME>_<SUB-TYPENAME> signals,ports,memories,stages,etc. are split into <NAME>_<SUB-NAME> signals,ports,memories,stages,etc.
In case the element type of a collection type is an aggregated type, a new decode_stage called In case the element type of a collection type is an aggregated type, a new decode_stage called
<TYPENAME>_MEMBER_END is generated, which handles the <TYPENAME>_cnt increment and check which <NAME>_MEMBER_END is generated, which handles the <NAME>_cnt increment and check which
normally be handled in the GET_<TYPENAME> decode_stage. The <TYPENAME>_ready and <TYPENAME>_valid normally be handled in the GET_<NAME> decode_stage. The <NAME>_ready and <NAME>_valid
port signals are generated by ANDing the respective memory signals of all sub-elements. port signals are generated by ANDing the respective memory signals of all sub-elements.
UNION UNION
----- -----
Due to the dynamic nature of unions, all defined sub-types have to be handled equally. Due to the dynamic nature of unions, all defined sub-types have to be handled equally.
Similar to structures the generated <TYPENAME> objects are split into <TYPENAME>_<SUB-TYPENAME> objects, Similar to structures the generated <NAME> objects are split into <NAME>_<SUB-NAME> objects,
including the special <TYPENAME>_d objects, which handle the value of the discriminator itself. including the special <NAME>_d objects, which handle the value of the discriminator itself.
In contrast to structures, the first decode_stage (GET_<TYPENAME>_D) selects the next decode_stage In contrast to structures, the first decode_stage (GET_<NAME>_D) selects the next decode_stage
according to the discriminator value itself. The rest of the generated decode_stages select the according to the discriminator value itself. The rest of the generated decode_stages select the
decode_stage of the next declared member. decode_stage of the next declared member.
@ -166,16 +168,16 @@ NESTED COLLECTIONS
If a collection type has in itself another collection type, an array of memories is generated, and the If a collection type has in itself another collection type, an array of memories is generated, and the
respective memory connection signals are also multidimensional (Meaning that custom types have to be respective memory connection signals are also multidimensional (Meaning that custom types have to be
created). created).
The <OUTER_COLLECTION_TYPENAME>_cnt of the outer collection is used to index the multidimensional signals The <OUTER_COLLECTION_NAME>_cnt of the outer collection is used to index the multidimensional signals
of the inner collection. of the inner collection.
The <OUTER_COLLECTION_TYPENAME>_ready and <OUTER_COLLECTION_TYPENAME>_valid ports of the outer collection The <OUTER_COLLECTION_NAME>_ready and <OUTER_COLLECTION_NAME>_valid ports of the outer collection
are no longer dependant on the inner collection (If the outer array has no other elements type except the are no longer dependant on the inner collection (If the outer array has no other elements type except the
inner collection the ports have to be hardwired). inner collection the ports have to be hardwired).
A new <OUTER_COLLECTION_TYPENAME>_addr_latch helper latch is defined, that latches the A new <OUTER_COLLECTION_NAME>_addr_latch helper latch is defined, that latches the
<OUTER_COLLECTION_TYPENAME>_addr port when the <OUTER_COLLECTION_TYPENAME>_<INNER_COLLECTION_TYPENAME>_ren <OUTER_COLLECTION_NAME>_addr port when the <OUTER_COLLECTION_NAME>_<INNER_COLLECTION_NAME>_ren
port signal is '1'. This address latch is used to connect the correct memory to the port signal is '1'. This address latch is used to connect the correct memory to the
<OUTER_COLLECTION_TYPENAME>_<INNER_COLLECTION_TYPENAME> and <OUTER_COLLECTION_NAME>_<INNER_COLLECTION_NAME> and
<OUTER_COLLECTION_TYPENAME>_<INNER_COLLECTION_TYPENAME>_valid port signals. <OUTER_COLLECTION_NAME>_<INNER_COLLECTION_NAME>_valid port signals.
OPTIONALS OPTIONALS
@ -184,13 +186,13 @@ OPTIONALS
If a type member is specified as optional, a special header is preceding the CDR encoding.[5] If a type member is specified as optional, a special header is preceding the CDR encoding.[5]
Generally the same procedure as the type of the optional member is followed with following Generally the same procedure as the type of the optional member is followed with following
modifications. modifications.
A new <TYPENAME>_opt port signal is defined, that is connected to a <TYPENAME>_opt_latch latch. A new <NAME>_opt port signal is defined, that is connected to a <NAME>_opt_latch latch.
The previous decode_stage selects the 'GET_OPTIONAL_HEADER' decode_stage, and sets the 'return_stage' The previous decode_stage selects the 'GET_OPTIONAL_HEADER' decode_stage, and sets the 'return_stage'
to the actual next decode_stage (The decode_stage of the optional member). to the actual next decode_stage (The decode_stage of the optional member).
The first generated decode_stage of the <TYPENAME> (i.e. the stage that was in return_stage) checks The first generated decode_stage of the <NAME> (i.e. the stage that was in return_stage) checks
the 'optional' signal before anything else (even before the alignement). If 'optional' is '0', it sets the 'optional' signal before anything else (even before the alignement). If 'optional' is '0', it sets
the <TYPENAME>_opt_latch to '0' and selects the decode_stage of the next declared member. Otherwise the <NAME>_opt_latch to '0' and selects the decode_stage of the next declared member. Otherwise
the <TYPENAME>_opt_latch is set to '1'. the <NAME>_opt_latch is set to '1'.
@ -205,7 +207,7 @@ In General the writer_interface is a similar layout to the reader_interface with
All "GET_*" stages are renamed to "WRITE_*". All "GET_*" stages are renamed to "WRITE_*".
The "FETCH" stage is renamed to "PUSH". The "FETCH" stage is renamed to "PUSH".
'write_sub_vector' is used to write into 'data_out_latch' (instead of 'get_sub_vector' and 'data_in_latch'). 'write_sub_vector' is used to write into 'data_out_latch' (instead of 'get_sub_vector' and 'data_in_latch').
The direction of the <TYPENAME> port signals are inverted (i.e. in). The direction of the <NAME> port signals are inverted (i.e. in).
Instead of calling 'SKIP_PAYLOAD' stage on the last declared member, the 'PUSH' stage is explicitly called Instead of calling 'SKIP_PAYLOAD' stage on the last declared member, the 'PUSH' stage is explicitly called
and the 'encode_done' and 'finalize_payload' signals are set. and the 'encode_done' and 'finalize_payload' signals are set.
@ -214,35 +216,35 @@ COLLECTION TYPE
The port signals of all collection types are modified as follows: The port signals of all collection types are modified as follows:
MOD NAME DIRECTION CONNECTED MOD NAME DIRECTION CONNECTED
remove <TYPENAME> out - remove <NAME> out -
add <TYPENAME>_r out <TYPENAME>_mem_data_out add <NAME>_r out <NAME>_mem_data_out
add <TYPENAME>_w in <TYPENAME>_mem_data_in add <NAME>_w in <NAME>_mem_data_in
add <TYPENAME>_wen in <TYPENAME>_mem_valid_in in 'IDLE' stage [NOTE: ORed together with <TYPENAME>_ren] add <NAME>_wen in <NAME>_mem_valid_in in 'IDLE' stage [NOTE: ORed together with <NAME>_ren]
change <TYPENAME>_len in Used in <TYPENAME>_cnt checks, and to see if collection is empty change <NAME>_len in Used in <NAME>_cnt checks, and to see if collection is empty
The <TYPENAME>_len_latch is removed (Since the Length is now an input). The <NAME>_len_latch is removed (Since the Length is now an input).
The 'WRITE_<TYPENAME>' encode_stage is divided with the help of 'cnt' into 2 sub-stages. The 'WRITE_<NAME>' encode_stage is divided with the help of 'cnt' into 2 sub-stages.
The first sub-stage is responsible for requesting the value from the memory (Memory READ request). The first sub-stage is responsible for requesting the value from the memory (Memory READ request).
The second sub-stage waits until the value is valid (<TYPENAME>_mem_valid_out) and does the usual write The second sub-stage waits until the value is valid (<NAME>_mem_valid_out) and does the usual write
procedure. On sucessfull write the <TYPENAME>_mem_ready_out has to be pulsed high to finalize the memory procedure. On sucessfull write the <NAME>_mem_ready_out has to be pulsed high to finalize the memory
operation. operation.
NOTE: If the encode_stage already is divided into sub-stages (due to the primitive type), a single NOTE: If the encode_stage already is divided into sub-stages (due to the primitive type), a single
sub-stage is added that does the Memory fetch operation, and the <TYPENAME>_mem_ready_out is pulled high sub-stage is added that does the Memory fetch operation, and the <NAME>_mem_ready_out is pulled high
in the last sub-stage. in the last sub-stage.
OPTIONALS OPTIONALS
========= =========
The direction of the <TYPENAME>_opt port signal is inverted (in) and the <TYPENAME>_opt_latch is removed. The direction of the <NAME>_opt port signal is inverted (in) and the <NAME>_opt_latch is removed.
The memory width is extended by 1 bit, and the <TYPENAME>_opt is prepended The memory width is extended by 1 bit, and the <NAME>_opt is prepended
(i.e. <TYPENAME>_mem_data_in <= <TYPENAME>_opt & <TYPENAME>;) (i.e. <NAME>_mem_data_in <= <NAME>_opt & <NAME>;)
No 'optional' check is done in the respective encode_stage. No 'optional' check is done in the respective encode_stage.
An extra sub-stage is added after the memory fetch operation, that writes the optional header depending An extra sub-stage is added after the memory fetch operation, that writes the optional header depending
on the highest bit of the returned memory value (i.e. the optional bit). If the highest bit is '0' the on the highest bit of the returned memory value (i.e. the optional bit). If the highest bit is '0' the
optional header gets a length of zero and the encode_stage of the next declared member is selected, else optional header gets a length of zero and the encode_stage of the next declared member is selected, else
the actual size of the optional member type is written. The parameter ID of the optional header is the actual size of the optional member type is written. The parameter ID of the optional header is
hardcoded to the actual member ID of the optional member. hardcoded to the actual member ID of the optional member.
NOTE: If the optional is part of a collection type, the <TYPENAME>_opt signals are also split into NOTE: If the optional is part of a collection type, the <NAME>_opt signals are also split into
<TYPENAME>_opt_r and <TYPENAME>_opt_w port signals. <NAME>_opt_r and <NAME>_opt_w port signals.
KEY_HOLDER KEY_HOLDER
@ -261,20 +263,20 @@ The 'ALIGN_STREAM' stage is split into 'ALIGN_IN_STREAM' (for decode_stage) and
The decode procedure (decode_stage stages) follows 2 different decoding procedures. The decode procedure (decode_stage stages) follows 2 different decoding procedures.
The first - taken on a 'PUSH_DATA' opcode - follows the reader_interface procedure of the <TOPIC> type until The first - taken on a 'PUSH_DATA' opcode - follows the reader_interface procedure of the <TOPIC> type until
the last declared member that is also member of the KeyHolder(<TYPENAME>)[6] Type (i.e. the last decalred the last declared member that is also member of the KeyHolder(<NAME>)[6] Type (i.e. the last decalred
key of the type), after which the 'SKIP_PAYLOAD' stage is taken. key of the type), after which the 'SKIP_PAYLOAD' stage is taken.
(Since the serialized key only uses the KeyHolder(<TYPENAME>) members, the rest is ignored) (Since the serialized key only uses the KeyHolder(<NAME>) members, the rest is ignored)
The second - taken on a 'PUSH_SERIALIZED_KEY' opcode - follows the reader_interface procedure of the The second - taken on a 'PUSH_SERIALIZED_KEY' opcode - follows the reader_interface procedure of the
KeyHolder(<TYPENAME>) directly. KeyHolder(<NAME>) directly.
Since the decode_stages for the second decoding procedure are a subset of the first decoding procedure, Since the decode_stages for the second decoding procedure are a subset of the first decoding procedure,
the same decode stages are used, and only the 'decode_stage_next' signal is set depending on the the same decode stages are used, and only the 'decode_stage_next' signal is set depending on the
'opcode_latch' signal. The 'GET_PAYLAOD_HEADER' stage selects the correct first decode stage. 'opcode_latch' signal. The 'GET_PAYLAOD_HEADER' stage selects the correct first decode stage.
Similarly the encode procedure also follows 2 different encoding procedures. Similarly the encode procedure also follows 2 different encoding procedures.
The first - taken on a 'READ_SERIALIZED_KEY' opcode - follows the write_interface procedure of the The first - taken on a 'READ_SERIALIZED_KEY' opcode - follows the write_interface procedure of the
KeyHolder(<TYPENAME>) Type. KeyHolder(<NAME>) Type.
The second - taken on a 'READ_KEY_HASH' opcode (if the key is not already calculated) - follows the The second - taken on a 'READ_KEY_HASH' opcode (if the key is not already calculated) - follows the
write_interface procedure of the <TYPENAME>KeyHolder[7] Type. Note that this encoding is in PLAIN_CDR2 write_interface procedure of the <NAME>KeyHolder[7] Type. Note that this encoding is in PLAIN_CDR2
Big Endian, meaning that types wich have an ALIGN_8 in PLAIN_CDR have a ALIGN_4 in PLAIN_CDR2. Big Endian, meaning that types wich have an ALIGN_8 in PLAIN_CDR have a ALIGN_4 in PLAIN_CDR2.
Both encoding procedures share the same encode_stages, and the 'encode_stage_next' signal is Both encoding procedures share the same encode_stages, and the 'encode_stage_next' signal is
set depending on the 'opcode_latch' signal. On a 'READ_SERIALIZED_KEY' opcode the set depending on the 'opcode_latch' signal. On a 'READ_SERIALIZED_KEY' opcode the
@ -286,7 +288,7 @@ PITFALLS
######## ########
* Make sure to initialize the 'cnt' signal to zero before calling a decode_stage/encode_stage with sub-stages * Make sure to initialize the 'cnt' signal to zero before calling a decode_stage/encode_stage with sub-stages
* Keep in mind the ALIGN difference between PLAIN_CDR and PLAIN_CDR2 * Keep in mind the ALIGN difference between PLAIN_CDR and PLAIN_CDR2
* Note that the order of the <TYPENAME>KeyHolder[7] members is in ascending member ID and may not be the same as KeyHolder(<TYPENAME>)[6] * Note that the order of the <NAME>KeyHolder[7] members is in ascending member ID and may not be the same as KeyHolder(<NAME>)[6]
[1] DDS_XTYPES v1.3, 7.4.3.1 [1] DDS_XTYPES v1.3, 7.4.3.1
[2] DDS_XTYPES v1.3, 7.4.1.1.1 [2] DDS_XTYPES v1.3, 7.4.1.1.1

14
src/TEMPLATE_reader_interface.vhd
View File

@ -110,7 +110,7 @@ architecture arch of TYPENAME_reader_interface is
signal optional, optional_next : std_logic; signal optional, optional_next : std_logic;
signal abort_mem : std_logic; signal abort_mem : std_logic;
signal ready_in_dds_sig : std_logic; signal ready_in_dds_sig : std_logic;
signal valid_latch, valid_latch_next : std_logic; signal valid_sig, valid_sig_next : std_logic;
signal decode_stage, decode_stage_next : DECODE_STAGE_TYPE; signal decode_stage, decode_stage_next : DECODE_STAGE_TYPE;
signal return_stage, return_stage_next : DECODE_STAGE_TYPE; signal return_stage, return_stage_next : DECODE_STAGE_TYPE;
-- ###GENERATED START### -- ###GENERATED START###
@ -159,7 +159,7 @@ begin
eoc_user <= eoc_dds; eoc_user <= eoc_dds;
status_user <= status_dds; status_user <= status_dds;
valid <= valid_latch; valid <= valid_sig;
decode_error <= decode_error_latch; decode_error <= decode_error_latch;
ready_in_dds <= ready_in_dds_sig; ready_in_dds <= ready_in_dds_sig;
@ -181,7 +181,7 @@ begin
align_offset_next <= align_offset; align_offset_next <= align_offset;
target_align_next <= target_align; target_align_next <= target_align;
optional_next <= optional; optional_next <= optional;
valid_latch_next <= valid_latch; valid_sig_next <= valid_sig;
data_in_latch_next <= data_in_latch; data_in_latch_next <= data_in_latch;
align_op_next <= align_op; align_op_next <= align_op;
abort_mem <= '0'; abort_mem <= '0';
@ -202,7 +202,7 @@ begin
stage_next <= GET_PAYLOAD_HEADER; stage_next <= GET_PAYLOAD_HEADER;
-- RESET -- RESET
decode_error_latch_next <= '0'; decode_error_latch_next <= '0';
valid_latch_next <= '0'; valid_sig_next <= '0';
abort_mem <= '1'; abort_mem <= '1';
else else
-- ###GENERATED START### -- ###GENERATED START###
@ -275,7 +275,7 @@ begin
-- If no Decode Error, mark output as valid -- If no Decode Error, mark output as valid
if (decode_error_latch = '0') then if (decode_error_latch = '0') then
valid_latch_next <= '1'; valid_sig_next <= '1';
end if; end if;
-- Reset -- Reset
@ -365,7 +365,7 @@ begin
last_word_in_latch <= '0'; last_word_in_latch <= '0';
decode_error_latch <= '0'; decode_error_latch <= '0';
optional <= '0'; optional <= '0';
valid_latch <= '0'; valid_sig <= '0';
align_op <= '0'; align_op <= '0';
align_offset <= (others => '0'); align_offset <= (others => '0');
data_in_latch <= (others => '0'); data_in_latch <= (others => '0');
@ -382,7 +382,7 @@ begin
last_word_in_latch <= last_word_in_latch_next; last_word_in_latch <= last_word_in_latch_next;
decode_error_latch <= decode_error_latch_next; decode_error_latch <= decode_error_latch_next;
optional <= optional_next; optional <= optional_next;
valid_latch <= valid_latch_next; valid_sig <= valid_sig_next;
align_op <= align_op_next; align_op <= align_op_next;
align_offset <= align_offset_next; align_offset <= align_offset_next;
data_in_latch <= data_in_latch_next; data_in_latch <= data_in_latch_next;

4
src/TEMPLATE_user_config.vhd
View File

@ -24,7 +24,7 @@ package user_config is
-- Unicast IPv4 Address used by all RTPS Entities [Default 192.168.0.128] -- Unicast IPv4 Address used by all RTPS Entities [Default 192.168.0.128]
constant DEFAULT_IPv4_ADDRESS : std_logic_vector(IPv4_ADDRESS_WIDTH-1 downto 0) := x"C0A80080"; constant DEFAULT_IPv4_ADDRESS : std_logic_vector(IPv4_ADDRESS_WIDTH-1 downto 0) := x"C0A80080";
-- Number of RTPS Writer Endpoints -- Number of RTPS Writer Endpoints
constant NUM_WRITERS : natural := 0; constant NUM_WRITERS : natural := 1;
-- Number of RTPS Reader Endpoints -- Number of RTPS Reader Endpoints
constant NUM_READERS : natural := 1; constant NUM_READERS : natural := 1;
-- Number of RTPS Endpoints (Do not modify) -- Number of RTPS Endpoints (Do not modify)
@ -66,7 +66,7 @@ package user_config is
-- *ENDPOINT CONFIG* -- *ENDPOINT CONFIG*
constant ENDPOINT_CONFIG : CONFIG_ARRAY_TYPE(0 to NUM_ENDPOINTS-1) := ( constant ENDPOINT_CONFIG : CONFIG_ARRAY_TYPE(0 to NUM_ENDPOINTS-1) := (
0 to NUM_READERS-1 => DEFAULT_READER_CONFIG, 0 to NUM_READERS-1 => DEFAULT_READER_CONFIG,
NUM_READERS to NUM_WRITERS-1 => DEFAULT_WRITER_CONFIG NUM_READERS to NUM_ENDPOINTS-1 => DEFAULT_WRITER_CONFIG
); );
-- Set to TRUE for Simulation Testing (Extra Code generated) -- Set to TRUE for Simulation Testing (Extra Code generated)

2
src/rtps_config_package.vhd
View File

@ -101,7 +101,7 @@ package rtps_config_package is
end record; end record;
constant READER_ENDPOINT_DATA : OUTPUT_DATA_TYPE; --Deferred to package body constant READER_ENDPOINT_DATA : OUTPUT_DATA_TYPE; --Deferred to package body
constant WRITER_ENDPOINT_DATA : OUTPUT_DATA_TYPE; --Deferred to package body constant WRITER_ENDPOINT_DATA : OUTPUT_DATA_TYPE; --Deferred to package body
constant LOCAL_PARTICIPANT_DATA : OUTPUT_DATA_TYPE; --Deferred to package body constant LOCAL_PARTICIPANT_DATA : OUTPUT_DATA_TYPE; --Deferred to package body
type STRING_WORD_ARRAY_TYPE is array (0 to (256/(WORD_WIDTH/8))-1) of std_logic_vector(WORD_WIDTH-1 downto 0); type STRING_WORD_ARRAY_TYPE is array (0 to (256/(WORD_WIDTH/8))-1) of std_logic_vector(WORD_WIDTH-1 downto 0);
type ENDPOINT_STRING_TYPE is array (0 to NUM_ENDPOINTS-1) of STRING_WORD_ARRAY_TYPE; type ENDPOINT_STRING_TYPE is array (0 to NUM_ENDPOINTS-1) of STRING_WORD_ARRAY_TYPE;