Blind Implementation of DDS Writer

A Serialized Key Generator Entity Hull (responsible for generating the
serialized Key) was also added.

src/REF.txt

@@ -412,34 +412,6 @@ READER
 10|                         NEXT_ADDRESS                        |
   +-------------------------------------------------------------+
 
-WRITER
-------
-  31............24..............16..............8...............0
-  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-  +-------------------------------------------------------------+
-00|                         STATUS_INFO                         |
-  +-------------------------------------------------------------+
-01|                                                             |
-  +                          TIMESTAMP                          +
-02|                                                             |
-  +-------------------------------------------------------------+
-03|                                                             |
-  +                      LIFESPAN_DEADLINE                      +
-04|                                                             |
-  +-------------------------------------------------------------+
-05|                       PAYLOAD_ADDRESS                       |
-  +-------------------------------------------------------------+
-06|                       INSTANCE_ADDRESS                      |
-  +-------------------------------------------------------------+
-07|                                                             |
-  ~                          ACK_BITMAP                         ~
-**|                                                             |
-  +-------------------------------------------------------------+
-**|                         PREV_ADDRESS                        |
-  +-------------------------------------------------------------+
-**|                         NEXT_ADDRESS                        |
-  +-------------------------------------------------------------+
-  
 STATUS INFO
 -----------
 31............24..............16..............8...............0
@@ -452,10 +424,56 @@ R...Sample has been Read
 P...Sample has associated Payload
 A...Associated Payload is aligned (Payload does extend until end of last Palyload Slot)
 K...Key Hash available
+F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
+U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
+D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
+
+NOTE: The Key Hash Flag is actually only needed during the ADD_CACHE_CHANGE process.
+      Later on it is obsolete, since we always calculate the Key Hash.
+
+WRITER
+------
+  31............24..............16..............8...............0
+  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+  +-------------------------------------------------------------+
+00|                         STATUS_INFO                         |
+  +-------------------------------------------------------------+
+01|                                                             |
+  +                           SEQ_NR                            +
+02|                                                             |
+  +-------------------------------------------------------------+
+03|                                                             |
+  +                          TIMESTAMP                          +
+04|                                                             |
+  +-------------------------------------------------------------+
+05|                                                             |
+  +                      LIFESPAN_DEADLINE                      + [only if LIFESPAN /= INFINITE]
+06|                                                             |
+  +-------------------------------------------------------------+
+07|                       PAYLOAD_ADDRESS                       |
+  +-------------------------------------------------------------+
+08|                       INSTANCE_ADDRESS                      |
+  +-------------------------------------------------------------+
+09|                         PREV_ADDRESS                        |
+  +-------------------------------------------------------------+
+10|                         NEXT_ADDRESS                        |
+  +-------------------------------------------------------------+
+  
+STATUS INFO
+-----------
+31............24..............16..............8...............0
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
++-+-+-+-------------------------------------------------+-+-+-+
+|R|P|A|                      UNUSED                     |F|U|D|
++-+-+-+-------------------------------------------------+-+-+-+
+
+R...Sample has been ACKed
+P...Sample has associated Payload
+A...Associated Payload is aligned (Payload does extend until end of last Palyload Slot)
+F...FilteredFlag (1:1 PID_STATUS_INFO Mapping)
+U...UnregisteredFlag (1:1 PID_STATUS_INFO Mapping)
+D...DisposedFlag (1:1 PID_STATUS_INFO Mapping)
 
-F...FilteredFlag
-U...UnregisteredFlag
-D...DisposedFlag
   
 PAYLOAD MEMORY
 ==============
@@ -536,6 +554,20 @@ READER
 **|                                                             |
   +-------------------------------------------------------------+
 
+STATUS INFO
+-----------
+31............24..............16..............8...............0
++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
++---------------------------------------------------+-+-+-+-+-+
+|                           UNUSED                  |M|V|L|W|D|
++---------------------------------------------------+-+-+-+-+-+
+
+D...NOT_ALIVE_DISPOSED
+W...NOT_ALIVE_NO_WRITERS
+L...LIVELINESS FLAG
+V...VIEW STATE
+M...MARK
+
 WRITER
 ------
   31............24..............16..............8...............0
@@ -563,16 +595,13 @@ STATUS INFO
 -----------
 31............24..............16..............8...............0
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-+---------------------------------------------------+-+-+-+-+-+
++-------------------------------------------------------+-+-+-+
-|                           UNUSED                  |M|V|L|W|D|
+|                           UNUSED                      |L|U|D|
-+---------------------------------------------------+-+-+-+-+-+
++-------------------------------------------------------+-+-+-+
 
-D...NOT_ALIVE_DISPOSED
+D...DISPOSED
-W...NOT_ALIVE_NO_WRITERS
+W...UNREGISTERED
 L...LIVELINESS FLAG
-V...VIEW STATE
-M...MARK
-
 
 OUTPUT DATA
 ===========
@@ -719,6 +748,11 @@ with a source timestamp earlier than the source timestamp of the last data deliv
 be dropped. This ordering therefore works best when system clocks are relatively synchronized among 
 writing machines.
 
+2.2.2.4.2.22 assert_liveliness (DDS)
+NOTE: Writing data via the write operation on a DataWriter asserts liveliness on the DataWriter itself 
+and its DomainParticipant. Consequently the use of assert_liveliness is only needed if the application 
+is not writing data regularly.
+
 INVALIDATION
 ============
 

src/TODO.txt

@@ -63,6 +63,8 @@
 * What happens if we get a sample with a source timestamp earlier than the last sample that was accessed by the DataReader when using DESTINATION ORDER BY_SOURCE_TIMESTAMP? Is the smaple dropped?
 * The spec does not define the serialized Key (KEY=1 DATA MESSAGE)
     - fast-rtps assumes it is the Key Hash
+    - opendds sends Payload Encapsulation with a Key Holder Object (As defined in XType 7.6.8)
+    - opensplice seems todo the same as opendds
 * Currently the builtin-endpoint does only acknowledge SN, but does not negatively acknowledge any SN (Bitamp is always empty).
   A writer usually responds with repqirs only to negative acknowledgements.
 * Currently a RTPS Writer with DURABILITY TARNSIENT_LOCAL does send historical data to all matched readers, not depending if they are VOLATILE or TRANSIENT_LOCAL.
@@ -74,19 +76,27 @@
 * Is a Writer that is Disposing a Instance also Unregistering that instance? (Currently only Unregistering removes the remote Writer)
     - No
 * Since Lifespan is a duration, there is an inherent difference in the expiration time between writer and reader. This in addition to the fact that the reader may use the Reception time for the expiration time calculation could lead to an actual expiration duration almost double in length (If sent right before expiring locally in the writer).
+* The current implementation will sent a second unregister/dispose Sample, if the user does the unregister/dispose operation a second time. Should we handle that specially?
 
-* Fast-RTPS doen not follow DDSI-RTPS Specification
+
+
+* Fast-RTPS does not follow DDSI-RTPS Specification
     - Open Github Issue
         https://github.com/eProsima/Fast-RTPS/issues/1221
     - Seems that Fast-RTPS is also not checking the Validity of Submessages according to Spec
             
 * DDSI-RTPS 2.3 ISSUES
+    - 8.2.2 The History Cache
+        The 'get_change()' operation depicted in 8.3 is not documented.
     - 8.2.2.4 get_seq_num_min
       8.2.2.5 get_seq_num_max
-        This asume a history cache with duplicate-free sequence numbers, but because sequence number are generated per writer, and a reader can be matched with mutliple writers, we can get duplicate sequence numbers of different changes from different writers.
+        This asume a history cache with duplicate-free sequence numbers, but because sequence number are 
+        generated per writer, and a reader can be matched with mutliple writers, we can get duplicate 
+        sequence numbers of different changes from different writers.
         Ergo the functions are non-deterministic.
     - 8.3.7.7 InfoDestination
-        'This message is sent from an RTPS Writer to an RTPS Reader to modify the GuidPrefix used to interpret the Reader entityIds appearing in the Submessages that follow it.'
+        'This message is sent from an RTPS Writer to an RTPS Reader to modify the GuidPrefix used to 
+        interpret the Reader entityIds appearing in the Submessages that follow it.'
         But state is changed as follows 'Receiver.destGuidPrefix = InfoDestination.guidPrefix'.
         Isn't Reader -> Writer also valid? Does it have a specific direction?
     - 9.4.5.3 Data Submessage
@@ -101,9 +111,24 @@
         'This Submessage is invalid when the following is true:
             submessageLength in the Submessage header is too small'
         But if InvalidateFlag is set, Length can be Zero. Since the length is unsigned, there cannot be an invalid length.
+    - 8.4.7 RTPS Writer Reference Implementation
+        According to 8.2.2 the History Cache (HC) is the interface between RTPS nad DDS, and can be invoked
+        by both RTPS and DDS Entities.
+        8.2.9 further states 'A DDS DataWriter, for example, passes data to its matching RTPS Writer through 
+        the common HistoryCache.', implying that a DDS Writer adds changes directly to the HC, which is then
+        read by the RTPS writer and handled accordingly. This means that the DDS Writer is responsible for
+        assigning Sequence Numbers.
+        This goes against 8.4.7, which states that the RTPS Writer is adding the Cache Changes to the HC
+        and is responsible for assigning Sequence Numbers.
     - 8.7.2.2.1 DURABILITY
         'While volatile and transient-local durability do not affect the RTPS protocol'
         But in case of Durability TRANSIENT_LOCAL the writer has to send historical Data.
+    - 8.7.2.2.3 LIVELINESS
+        'If the Participant has any MANUAL_BY_PARTICIPANT Writers, implementations must check periodically 
+        to see if write(), assert_liveliness(), dispose(), or unregister_instance() was called for any of 
+        them.'
+        Elaborate if "any of them" does specify all Writers of the Participant, or only the Writers with
+        MANUAL_BY_PARTICIPANT Liveliness.
     - 8.7.3.2 Indicating to a Reader that a Sample has been filtered
         Text refs 8.3.7.2.2 for DataFlag, but shoudl also ref 8.7.4 for FilteredFlag
     - 9.4.5.1.2 Flags 
@@ -123,6 +148,7 @@
             the BuiltinParticipantMessageReader as if it is configured with RELIABLE_RELIABILITY_QOS.
         which means that the default value is 0.
     
+        
 * DDS 1.4 ISSUES
     - 2.2.3 Supported QoS
         Partition is marked as RxO=No, but should be RxO=Yes? Or not?
@@ -236,6 +262,7 @@ DESIGN DECISIONS
 PROTOCOL UNCOMPLIANCE
 =====================
 * Partition QoS
+* Coherent Sets
 * Built-in Endpoint is NOT the same as a normal Endpoint
     -> No User access to Data
 * Known but unused Submessage IDs are treated as uknown
@@ -243,6 +270,7 @@ PROTOCOL UNCOMPLIANCE
 * Inline QoS validated in Endpoint
     -> Cannot invalidate Rest of Message/Packet
 * RESOURCE_LIMITS applies also to "empty" samples (Samples with no valid data).
+* Write/Dispose/Untergister Operation do not return (TIMEOUT). I.e. the MAX_BLOCKING_TIME is not used.
 
 
 RTPS ENDPOINT

src/serialized_key_generator.vhd

@@ -0,0 +1,24 @@
+library ieee;
+use ieee.std_logic_1164.all;
+use ieee.numeric_std.all;
+
+entity serialized_key_generator is
+    port (
+        clk             : in std_logic;
+        reset           : in std_logic;
+        
+        start           : in std_logic;
+        opcode          : in KEY_GENERATOR_OPCODE_TYPE;
+        busy            : out std_logic;
+        
+        data_in         : in std_logic_vector(WORD_WIDTH-1 downto 0);
+        valid_in        : in std_logic;
+        ready_in        : out std_logic;
+        last_word_in    : in std_logic;
+        
+        data_out        : out std_logic_vector(WORD_WIDTH-1 downto 0);
+        valid_out       : out std_logic;
+        ready_out       : in std_logic; 
+        last_word_out   : out std_logic
+    );
+end entity;