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

Add and update doc

Browse Source 
Added documentation for MD5 HASH Cacluclation
Updated TODO and REF with new design decisions
This commit is contained in:
Greek 2021-01-11 12:06:18 +01:00
parent a00f942826
commit 35743b6f19
9 changed files with 5912 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5627
doc/Altera/cv_51001.pdf Normal file
View File

File diff suppressed because it is too large Load Diff

BIN
doc/Altera/cv_5v1.pdf Normal file
View File

Binary file not shown.

BIN
doc/Altera/ug_ram_rom.pdf Normal file
View File

Binary file not shown.

BIN
doc/md5-fpga.pdf (Stored with Git LFS) Normal file
View File

Binary file not shown.

BIN
doc/rfc1321.pdf (Stored with Git LFS) Normal file
View File

Binary file not shown.

216
src/REF.txt
View File

@ -86,14 +86,14 @@ RTPS IN/OUT FORMAT
| | | |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
ENDPOINT FIFO PACKET FORMAT ENDPOINT PACKET FORMAT
=========================== ======================
31............24..............16..............8...............0 31............24..............16..............8...............0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------+---------------+---------------+---------------+ +-------------+---------------+-------------------------------+
| OPCODE | FLAGS | SRC_UDP_PORT | | OPCODE | FLAGS | SRC_UDP_PORT |
+-------------+---------------+---------------+---------------+ +-------------+---------------+-------------------------------+
| SRC_IPv4_ADDR | | SRC_IPv4_ADDR |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| | | |
@ -198,9 +198,9 @@ PARTICICPANT DATA
03| META_IPv4_ADDRESS | 03| META_IPv4_ADDRESS |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
04| DEFAULT_IPv4_ADDRESS | 04| DEFAULT_IPv4_ADDRESS |
+-------------------------------------------------------------+ +-----------------------------+-------------------------------+
05| META_UDP_PORT | DEFAULT_UDP_PORT | 05| META_UDP_PORT | DEFAULT_UDP_PORT |
+-------------------------------------------------------------+ +-----------------------------+-------------------------------+
06| | 06| |
+ SPDP_SEQ_NR + + SPDP_SEQ_NR +
07| | 07| |
@ -212,9 +212,9 @@ PARTICICPANT DATA
10| | 10| |
+ LEASE_DEADLINE + + LEASE_DEADLINE +
11| | 11| |
+-------------------------------------------------------------+ +-----------------------------------------------------+-+-+-+-+
12| UNUSED |P|S|M|Q| 12| UNUSED |P|S|M|Q|
+-------------------------------------------------------------+ +-----------------------------------------------------+-+-+-+-+
13| | 13| |
+ ACKNACK_RES_TIME + + ACKNACK_RES_TIME +
14| | 14| |
@ -253,9 +253,9 @@ ENDPOINT MATCH FRAME
04| ENTITYID | 04| ENTITYID |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
05| IPv4_ADDRESS | 05| IPv4_ADDRESS |
+-------------------------------------------------------------+ +-----------------------------+-----------------------------+-+
06| UDP_PORT | UNUSED |Q| 06| UDP_PORT | UNUSED |Q|
+-------------------------------------------------------------+ +-----------------------------+-----------------------------+-+
ENDPOINT UNMATCH FRAME ENDPOINT UNMATCH FRAME
====================== ======================
@ -314,18 +314,141 @@ LOCAL ENDPOINT BUFFER
+ + + +
03| | 03| |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
04| IPv4_ADDRESS | [Reliable only] 04| IPv4_ADDRESS | [Reliable Only]
+-------------------------------------------------------------+ +-----------------------------+-----------------------------+-+
05| UDP_PORT | UNUSED |Q| [Reliable only] 05| UDP_PORT | UNUSED |Q| [Reliable Only]
+-------------------------------------------------------------+ +-----------------------------+-----------------------------+-+
06| | 06| |
+ HIGHEST_SEQ_NR + + LEASE_DEADLINE +
07| | 07| |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
08| | 08| |
+ LEASE_DEADLINE + + RES_TIME + [Reliable Only]
09| | 09| |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
10| |
+ NEXT_SEQ_NR +
11| |
+-------------------------------------------------------------+
12| |
+ HIGHEST_AVAIL_SEQ_NR + [Reliable Only]
13| |
+-------------------------------------------------------------+
HISTORY CACHE
=============
READER
------
31............24..............16..............8...............0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------------------------------------------+
00| STATUS_INFO |
+-------------------------------------------------------------+
01| |
+ +
02| |
+ KEY_HASH +
03| |
+ +
04| |
+-------------------------------------------------------------+
05| ENTITYID |
+-------------------------------------------------------------+
06| |
+ +
07| GUIDPREFIX |
+ +
08| |
+-------------------------------------------------------------+
09| |
+ SEQUENCE_NUMBER +
10| |
+-------------------------------------------------------------+
11| |
+ TIMESTAMP +
12| |
+-------------------------------------------------------------+
13| |
+ LIFESPAN_DEADLINE +
14| |
+-------------------------------------------------------------+
15| PAYLOAD_ADDRESS |
+-------------------------------------------------------------+
16| PREV_ADDRESS |
+-------------------------------------------------------------+
17| NEXT_ADDRESS |
+-------------------------------------------------------------+
STATUS INFO
-----------
31............24..............16..............8...............0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-------------------------------------------------+-+-+-+
|R|K|P| UNUSED |F|U|D|
+-+-+-+-------------------------------------------------+-+-+-+
R...Sample has been Read
K...Key Hash available
P...Sample has associated Payload
F...FilteredFlag
U...UnregisteredFlag
D...DisposedFlag
PAYLOAD MEMORY
==============
31............24..............16..............8...............0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-----------------------------------------------------------+-+
00| NEXT_ADDRESS |O|
+-----------------------------------------------------------+-+
01| |
~ PAYLOAD ~
**| |
+-------------------------------------------------------------+
HISTORY CACHE INPUT
===================
31............24..............16..............8...............0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-------------------------------------------------------------+
00| STATUS_INFO |
+-------------------------------------------------------------+
01| |
+ +
02| |
+ KEY_HASH +
03| |
+ +
04| |
+-------------------------------------------------------------+
05| ENTITYID |
+-------------------------------------------------------------+
06| |
+ +
07| GUIDPREFIX |
+ +
08| |
+-------------------------------------------------------------+
09| |
+ SEQUENCE_NUMBER +
10| |
+-------------------------------------------------------------+
11| |
+ TIMESTAMP +
12| |
+-------------------------------------------------------------+
13| |
+ LIFESPAN_DEADLINE +
14| |
+-------------------------------------------------------------+
15| |
~ PAYLOAD ~
**| |
+-------------------------------------------------------------+
OUTPUT DATA OUTPUT DATA
@ -335,12 +458,12 @@ OUTPUT DATA
00| SRC_IPv4_ADDRESS | 00| SRC_IPv4_ADDRESS |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
01| DEST_IPv4_ADDRESS | 01| DEST_IPv4_ADDRESS |
+-------------------------------------------------------------+ +-----------------------------+-------------------------------+
02| SRC_UDP_PORT | DEST_UDP_PORT | 02| SRC_UDP_PORT | DEST_UDP_PORT |
+-------------------------------------------------------------+ +-----------------------------+-------------------------------+
03| | 03| |
~ RTPS_MESSAGE ~ ~ RTPS_MESSAGE ~
| | **| |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
@ -364,20 +487,20 @@ only be removed when it has been acknowledged by all readers the change was sent
active and alive. active and alive.
8.2.9.2 (DDSI-RTPS) 8.2.9.2 (DDSI-RTPS)
Each matching Writer will attempt to transfer all relevant samples from its HistoryCache to the HistoryCache of the Reader. Each matching Writer will attempt to transfer all relevant samples from its HistoryCache to the HistoryCache
of the Reader.
8.4.3 (DDSI-RTPS) 8.4.3 (DDSI-RTPS)
It is also not able to drop out-of-order samples on the Reader side as this It is also not able to drop out-of-order samples on the Reader side as this
requires keeping track of the largest sequence number received from each remote Writer. requires keeping track of the largest sequence number received from each remote Writer.
8.5.4.2 (DDSI-RTPS) 8.5.4.2 (DDSI-RTPS)
For the purpose of interoperability, it is sufficient that an For the purpose of interoperability, it is sufficient that an implementation provides the required built-in
implementation provides the required built-in Endpoints and reliable communication that satisfies the general Endpoints and reliable communication that satisfies the general requirements listed in 8.4.2.
requirements listed in 8.4.2.
8.5.4.4 (DDSI-RTPS) 8.5.4.4 (DDSI-RTPS)
An implementation of the protocol need not necessarily send all information contained in the DataTypes. If any An implementation of the protocol need not necessarily send all information contained in the DataTypes.
information is not present, the implementation can assume the default values, as defined by the PSM. If any information is not present, the implementation can assume the default values, as defined by the PSM.
8.7.2.2.6 (DDSI-RTPS) 8.7.2.2.6 (DDSI-RTPS)
In order to implement the DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS policy, In order to implement the DDS_BY_SOURCE_TIMESTAMP_DESTINATIONORDER_QOS policy,
@ -391,24 +514,49 @@ DDS_Advanced_Tutorial_2006_00-T1-2_Pardo.pdf
P.16 P.16
OpenDDS Developer's Guide OpenDDS Developer's Guide
It should be noted that if multiple data writers write to the same instance, care should be taken to ensure that clocks are synchronized to prevent incorrect ordering on the data reader. It should be noted that if multiple data writers write to the same instance, care should be taken to ensure
that clocks are synchronized to prevent incorrect ordering on the data reader.
https://community.rti.com/forum-topic/dropping-out-order-messages https://community.rti.com/forum-topic/dropping-out-order-messages
Messages from a single DataWriter always presserve their order when put into the DataReader cache. The middlware would drop a message rather than accept it out of order. Messages from a single DataWriter always presserve their order when put into the DataReader cache. The
If you call the regular read/take APIs then you will get them in the same order as they are in the cache which wil preserve the writer order. But if you start taking them using QueryConditions or read by insance etc. Then you will could be skipping some messages that are in the DataReader cache and access them later out of order. middlware would drop a message rather than accept it out of order.
In "Best efforts" there is a little bit of effort to ensure there are no duplicates or our-of-order samples. Basically the DataReader keeps the higuest accepted sequence number from each DataWriter. If a sample arrives with sequence number less or equal to that higuest accepted sequence number it will be dropped. This avoids both duplicates and out of order samples. If you call the regular read/take APIs then you will get them in the same order as they are in the cache
which wil preserve the writer order. But if you start taking them using QueryConditions or read by insance
etc. Then you will could be skipping some messages that are in the DataReader cache and access them later
out of order.
In "Best efforts" there is a little bit of effort to ensure there are no duplicates or our-of-order samples.
Basically the DataReader keeps the higuest accepted sequence number from each DataWriter. If a sample arrives
with sequence number less or equal to that higuest accepted sequence number it will be dropped. This avoids
both duplicates and out of order samples.
https://community.rti.com/forum-topic/strict-reliability-and-destination-order-qos https://community.rti.com/forum-topic/strict-reliability-and-destination-order-qos
The samples written by each DataWriter are guaranteed to have timestamps that are monotonically increasing (each equal or greater than the previous) and this the DataReader will not reject them based on source timestamp. The fact that a sample may be dropped on the wire and the reliable protocol may repair it does not affect this fact. The out-of-order sample will be staged in the "reliability queue" of the DataReader until the repair comes and by the time they are pushed to the DataReader cache they will be pushed in the correct order and the source timestamps will not cause a problem. The samples written by each DataWriter are guaranteed to have timestamps that are monotonically increasing
(each equal or greater than the previous) and this the DataReader will not reject them based on source
timestamp. The fact that a sample may be dropped on the wire and the reliable protocol may repair it does
not affect this fact. The out-of-order sample will be staged in the "reliability queue" of the DataReader
until the repair comes and by the time they are pushed to the DataReader cache they will be pushed in the
correct order and the source timestamps will not cause a problem.
https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/The_SampleInfo_Structure.htm https://community.rti.com/static/documentation/connext-dds/5.2.3/doc/manuals/connext_dds/html_files/RTI_ConnextDDS_CoreLibraries_UsersManual/Content/UsersManual/The_SampleInfo_Structure.htm
In reliable communication, if DDS data samples are received out received of order, Connext DDS will not deliver them until all the previous DDS data samples have been received. For example, if DDS sample 2 arrives before DDS sample 1, DDS sample 2 cannot be delivered until DDS sample 1 is received. The reception_timestamp is the time when all previous DDS samples has been received—the time at which the DDS sample is committed. If DDS samples are all received in order, the committed time will be same as reception time. However, if DDS samples are lost on the wire, then the committed time will be later than the initial reception time. In reliable communication, if DDS data samples are received out received of order, Connext DDS will not
deliver them until all the previous DDS data samples have been received. For example, if DDS sample 2 arrives
before DDS sample 1, DDS sample 2 cannot be delivered until DDS sample 1 is received. The reception_timestamp
is the time when all previous DDS samples has been received—the time at which the DDS sample is committed.
If DDS samples are all received in order, the committed time will be same as reception time. However, if DDS
samples are lost on the wire, then the committed time will be later than the initial reception time.
2.2.3.16 LIFESPAN (DDS) 2.2.3.16 LIFESPAN (DDS)
This QoS relies on the sender and receiving applications having their clocks sufficiently synchronized. If this is not the case This QoS relies on the sender and receiving applications having their clocks sufficiently synchronized. If
and the Service can detect it, the DataReader is allowed to use the reception timestamp instead of the source timestamp in its this is not the case and the Service can detect it, the DataReader is allowed to use the reception timestamp
computation of the ‘expiration time.’ instead of the source timestamp in its computation of the ‘expiration time.’
8.4.15.6 Reclaiming Finite Resources from Unresponsive Readers (DDSI-RTPS)
For a Writer, reclaiming queue resources should happen when all Readers have acknowledged a sample in the
queue and resources limits dictate that the old sample entry is to be used for a new sample.
There may be scenarios where an alive Reader becomes unresponsive and will never acknowledge the Writer.
Instead of blocking on the unresponsive Reader, the Writer should be allowed to deem the Reader as ‘Inactive’
and proceed in updating its queue. The Writer should determine the inactivity of a Reader by using a
mechanism based on the rate and number of ACKNACKs received.
INVALIDATION INVALIDATION
============ ============

28
src/TODO.txt
View File

@ -66,6 +66,9 @@
- -
* Currently the builtin-endpoint does only acknowledge SN, but does not negatively acknowledge any SN (Bitamp is always empty). * 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. 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 readrs, not depensing if they are VOLATILE or TRANSIENT_LOCAL.
* Assert Heartbeat period > Heartbeat Suppression Period
* Can I request (NACK) SNs that were NOT announced by the writer (> last_sn in Heartbeat)?
* Fast-RTPS doen not follow DDSI-RTPS Specification * Fast-RTPS doen not follow DDSI-RTPS Specification
@ -170,6 +173,31 @@ DESIGN DECISIONS
In order to acoomodate for that, we could store the lowest (and possibly highest) SN of a requested In order to acoomodate for that, we could store the lowest (and possibly highest) SN of a requested
lost SN and always send ALL GAPs in that range. lost SN and always send ALL GAPs in that range.
* The meta_data (sample info) of a cache change is fixed size, and a cache change may be connected to data (payload),
which may be variable in size. For this reason, we store the cache change and payload in separate memories.
The payload size may either be fixed (in which case the memory frame sizes are adjusted according to that),
or may be variable, in which case the payload is stored in a linked list of predefined sized memory frames.
The first word of a payload contains the address of the next linked memory frame. If this is the last frame
(or if the payload is static and there are no linked frames), the address is MAX_ADDRESS.
The last bit of this address is the "occupied" bit. This bit signifies if the memory frame is used or free,
and is used for the insert operation to find a new empty slot. This in effect means that all frame sizes
have to be a multiple of 2 (all frame addresses have to be aligned to 2).
* The History Cache (HC) is the interface between RTPS and DDS. The History Cache contains the Sample Info
and Payload memories. The HC has two input "sides", one is connected to the DDS and one to the RTPS entity.
Housing the memories inside the HC entity and abstracting the direct memory address via opcode requests
allows the memory interface to be replaced in future (e.g. AXI Lite).
Since all memory operations are handled by the same entity, this allows some state keeping to improve
memory bandwidth. More specifically the "linked list" paradigm can be extended to also reference empty
slots (and next unread slots), to allow selecting empty slots without iterating through the whole memory.
Originally the memory was to be implemented in a true dual port fashion, and two seperate procoesses
would each satisfy the requests from one input side. This would allow concurrent RTPS and DDS requests
to be handled. The write concurrency (add and remove change) does not allow for state keeping (first
empty slot address), since it is reset by the "adding" side, by set by the "removing" side.
Because of this, it was decided against concurrent input handling in light of the fact that the history
cache will be most commonly quite large in size, and iterating through all
PROTOCOL UNCOMPLIANCE PROTOCOL UNCOMPLIANCE
===================== =====================
* Partition QoS * Partition QoS

75
src/test.vhd
View File

@ -10,42 +10,81 @@ use work.rtps_package.all;
-- Checksum has to be checked before -- Checksum has to be checked before
entity test is entity test is
generic (
BUILD : boolean := FALSE
);
port ( port (
clk : in std_logic; -- Input Clock clk : in std_logic; -- Input Clock
reset : in std_logic; -- Synchronous Reset reset : in std_logic; -- Synchronous Reset
input : in std_logic_vector(31 downto 0); input : in std_logic_vector(31 downto 0);
cnt : out natural range 0 to NUM_ENDPOINTS output : out std_logic_vector(31 downto 0)
); );
end entity; end entity;
architecture arch of test is architecture arch of test is
signal test_var : natural := 0; type STAGE_TYPE is (IDLE, STATE1, STATE2);
-- Compares argument 'ref' with every element of 'ar', and returns the index of the last match. signal test_var : natural := 0;
-- If no match is found, array length is returned. signal stage, stage_next : STAGE_TYPE := IDLE;
function match_id_endpoint (ref : std_logic_vector(ENTITYID_WIDTH-1 downto 0); ar : ENTITYID_TYPE) return natural is
variable id : natural := 0; function bitmap_converter(input : std_logic_vector) return natural is
variable ret : natural := 0;
begin begin
id := ar'length; for i in 0 to input'length-1 loop
for i in 0 to ar'length-1 loop ret := ret + 1;
if(ref = ar(i)) then if (input(i) = '1') then
id := i; exit;
end if; end if;
end loop; end loop;
return id; return ret;
end function; end function;
begin begin
process(all) output <= std_logic_vector(to_unsigned(bitmap_converter(input), output'length));
begin
cnt <= 0;
if (test_var < to_unsigned(input)) then
cnt <= match_id_endpoint(input, ENTITYID);
end if;
end process;
-- process(all)
-- begin
-- stage_next <= stage;
-- output <= (others => '0');
--
-- case (stage) is
-- when IDLE =>
-- case (input) is
-- when x"00000000" =>
-- if (BUILD) then
-- stage_next <= STATE1;
-- else
-- stage_next <= STATE2;
-- end if;
-- when x"00000001" =>
-- stage_next <= STATE2;
-- when others =>
-- null;
-- end case;
-- when STATE1 =>
-- if (BUILD) then
-- stage_next <= IDLE;
-- output <= x"DEADBEEF";
-- end if;
-- when STATE2 =>
-- stage_next <= IDLE;
-- output <= x"BEEFDEAD";
-- when others =>
-- null;
-- end case;
-- end process;
-- sync : process(all)
-- begin
-- if rising_edge(clk) then
-- if (reset = '1') then
-- stage <= IDLE;
-- else
-- stage <= stage_next;
-- end if;
-- end if;
-- end process;
end architecture; end architecture;

12
syn/DE10-Nano/top.qsf
View File

@ -39,10 +39,16 @@
set_global_assignment -name FAMILY "Cyclone V" set_global_assignment -name FAMILY "Cyclone V"
set_global_assignment -name DEVICE 5CGXFC7C7F23C8 set_global_assignment -name DEVICE 5CGXFC7C7F23C8
set_global_assignment -name TOP_LEVEL_ENTITY rtps_handler set_global_assignment -name TOP_LEVEL_ENTITY test
set_global_assignment -name ORIGINAL_QUARTUS_VERSION 20.1.0 set_global_assignment -name ORIGINAL_QUARTUS_VERSION 20.1.0
set_global_assignment -name PROJECT_CREATION_TIME_DATE "13:33:09 NOVEMBER 02, 2020" set_global_assignment -name PROJECT_CREATION_TIME_DATE "13:33:09 NOVEMBER 02, 2020"
set_global_assignment -name LAST_QUARTUS_VERSION "20.1.0 Lite Edition" set_global_assignment -name LAST_QUARTUS_VERSION "20.1.0 Lite Edition"
set_global_assignment -name MIN_CORE_JUNCTION_TEMP 0
set_global_assignment -name MAX_CORE_JUNCTION_TEMP 85
set_global_assignment -name POWER_PRESET_COOLING_SOLUTION "23 MM HEAT SINK WITH 200 LFPM AIRFLOW"
set_global_assignment -name POWER_BOARD_THERMAL_MODEL "NONE (CONSERVATIVE)"
set_global_assignment -name VHDL_FILE ../../src/test_package.vhd -hdl_version VHDL_2008
set_global_assignment -name VHDL_FILE ../../src/test.vhd -hdl_version VHDL_2008
set_global_assignment -name VHDL_FILE ../../src/user_config.vhd -hdl_version VHDL_2008 set_global_assignment -name VHDL_FILE ../../src/user_config.vhd -hdl_version VHDL_2008
set_global_assignment -name VHDL_FILE ../../src/single_port_ram.vhd -hdl_version VHDL_2008 set_global_assignment -name VHDL_FILE ../../src/single_port_ram.vhd -hdl_version VHDL_2008
set_global_assignment -name VHDL_FILE ../../src/rtps_package.vhd -hdl_version VHDL_2008 set_global_assignment -name VHDL_FILE ../../src/rtps_package.vhd -hdl_version VHDL_2008
@ -50,10 +56,6 @@ set_global_assignment -name VHDL_FILE ../../src/rtps_handler.vhd -hdl_version VH
set_global_assignment -name VHDL_FILE ../../src/rtps_config_package.vhd -hdl_version VHDL_2008 set_global_assignment -name VHDL_FILE ../../src/rtps_config_package.vhd -hdl_version VHDL_2008
set_global_assignment -name VHDL_FILE ../../src/rtps_builtin_endpoint.vhd -hdl_version VHDL_2008 set_global_assignment -name VHDL_FILE ../../src/rtps_builtin_endpoint.vhd -hdl_version VHDL_2008
set_global_assignment -name VHDL_FILE ../../src/math_pkg.vhd -hdl_version VHDL_2008 set_global_assignment -name VHDL_FILE ../../src/math_pkg.vhd -hdl_version VHDL_2008
set_global_assignment -name MIN_CORE_JUNCTION_TEMP 0
set_global_assignment -name MAX_CORE_JUNCTION_TEMP 85
set_global_assignment -name POWER_PRESET_COOLING_SOLUTION "23 MM HEAT SINK WITH 200 LFPM AIRFLOW"
set_global_assignment -name POWER_BOARD_THERMAL_MODEL "NONE (CONSERVATIVE)"
set_global_assignment -name PARTITION_NETLIST_TYPE SOURCE -section_id Top set_global_assignment -name PARTITION_NETLIST_TYPE SOURCE -section_id Top
set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL PLACEMENT_AND_ROUTING -section_id Top set_global_assignment -name PARTITION_FITTER_PRESERVATION_LEVEL PLACEMENT_AND_ROUTING -section_id Top
set_global_assignment -name PARTITION_COLOR 16764057 -section_id Top set_global_assignment -name PARTITION_COLOR 16764057 -section_id Top