Skip to content
Snippets Groups Projects
Commit 0d4e8c36 authored by Eric Kooistra's avatar Eric Kooistra
Browse files

Wrapped lines.

parent 10a196a3
No related branches found
No related tags found
No related merge requests found
...@@ -17,11 +17,17 @@ may provide a monitoring point that allows the master to monitor the progress. O ...@@ -17,11 +17,17 @@ may provide a monitoring point that allows the master to monitor the progress. O
events that originate in the device it may be necessary to use the publish-subscribe pattern, whereby events that originate in the device it may be necessary to use the publish-subscribe pattern, whereby
the slave self-generates an event message. the slave self-generates an event message.
The Station Control (SC) distinguishes between Control and Monitoring and Control (M&C). The Control in SC determines the behaviour of the Station in time. Via M&C the SC can control the Station Digital Processor (SDP) and monitor whether SDP behaves as expected. The SC uses OPC-UA over TCP/IP as standard Station M&C access interface. From SDP point of view all data access points are considered part of SDP M&C, however from SC point of view only a subset of these SDP M&C data points are part of Station M&C, and these are defined in the ICD SC-SDP. The Station Control (SC) distinguishes between Control and Monitoring and Control (M&C). The Control
The SC M&C of SDP concerns two seperate parts: in SC determines the behaviour of the Station in time. Via M&C the SC can control the Station Digital
Processor (SDP) and monitor whether SDP behaves as expected. The SC uses OPC-UA over TCP/IP as standard
Station M&C access interface. From SDP point of view all data access points are considered part of
SDP M&C, however from SC point of view only a subset of these SDP M&C data points are part of Station
M&C, and these are defined in the ICD SC-SDP. The SC M&C of SDP concerns two seperate parts:
* The SDP Hardware is controlled via OPC-UA in the Control subrack in the STCA (STCACO). * The SDP Hardware is controlled via OPC-UA in the Control subrack in the STCA (STCACO).
* The SDP Firmware is controlled via OPC-UA in the SDP Translator (SDPT). The complete memory map of all data access points in the SDP Firmware is defined by a configuration file that can be read from the SDP Firmware. * The SDP Firmware is controlled via OPC-UA in the SDP Translator (SDPT). The complete memory map of
all data access points in the SDP Firmware is defined by a configuration file that can be read from
the SDP Firmware.
******************************************************************************* *******************************************************************************
* M&C of SDP firmware * M&C of SDP firmware
...@@ -41,7 +47,14 @@ Relevant L2 requirements for SDP monitoring points (BH): ...@@ -41,7 +47,14 @@ Relevant L2 requirements for SDP monitoring points (BH):
* Update scheme for the beamlet weigths * Update scheme for the beamlet weigths
******************************************************************************* *******************************************************************************
For the beamformer weights an update period of about once every 4.5 s is fast enough for all astronomical observations [AD-2f] --> BH partioniong rationale for LOFAR2-4392. In LOFAR1 the beamlet weights were applied at every pulse per second (PPS), so every 1 s [RD-8]. The required update rate of the beamlet weigths depends on the beamlet pointing, however all beamlet weigths are controlled as a set, and the beamlets may point in any direction, so therefore the update rate needs to be at least once every 4.5 s. Using a faster update rate makes the beamformer more robust to occasionally loosing an update, because then the previous weigths will still apply well. Table 3.1 lists beamlet weight update schemes that are all suitable for a LOFAR2.0 Station. For the beamformer weights an update period of about once every 4.5 s is fast enough for all
astronomical observations [AD-2f] --> BH partioniong rationale for LOFAR2-4392. In LOFAR1 the beamlet
weights were applied at every pulse per second (PPS), so every 1 s [RD-8]. The required update rate
of the beamlet weigths depends on the beamlet pointing, however all beamlet weigths are controlled
as a set, and the beamlets may point in any direction, so therefore the update rate needs to be at
least once every 4.5 s. Using a faster update rate makes the beamformer more robust to occasionally
loosing an update, because then the previous weigths will still apply well. Table 3.1 lists beamlet
weight update schemes that are all suitable for a LOFAR2.0 Station.
Table Possible beamlet weigths update scheme options for the SC-SDP ICD Table Possible beamlet weigths update scheme options for the SC-SDP ICD
...@@ -52,13 +65,20 @@ Option Beamlet weights update scheme SDP weigths memory ...@@ -52,13 +65,20 @@ Option Beamlet weights update scheme SDP weigths memory
Comparison of the beamlet weigths update schemes in Table: Comparison of the beamlet weigths update schemes in Table:
* The advantage of scheme A and C compared to scheme B of LOFAR is that they are less time critica, because they are not tight to thefixed 1 s grid of the PPS. * The advantage of scheme A and C compared to scheme B of LOFAR is that they are less time critica,
* The advantage of scheme A compared to scheme B and C is that it takes less weights memory in SDP, but the weights memory is not a critical resource for SDP because they are not tight to the fixed 1 s grid of the PPS.
* The advantage of scheme C compared to scheme A is that the weights can be send in advance, which relaxes the real time constraints on the SC to about 4.5 s. * The advantage of scheme A compared to scheme B and C is that it takes less weights memory in SDP,
but the weights memory is not a critical resource for SDP
* The advantage of scheme C compared to scheme A is that the weights can be send in advance, which
relaxes the real time constraints on the SC to about 4.5 s.
All schemes in Table can be applied via the SDP Translator as well as via the bypass control path. Scheme C is the most relaxed regarding the real time constrains on the SC and scheme C is quite feasible to realize in the SDP Firmware. Therefore assume that the SC-SDP ICD will specify using scheme C to update the beamlet weights (note that in [AD-2f] a mix of scheme A and scheme B was proposed, so SC sends control every 1 s and SDP applies immediately when received). All schemes in Table can be applied via the SDP Translator as well as via the bypass control path.
Scheme C is the most relaxed regarding the real time constrains on the SC and scheme C is quite
feasible to realize in the SDP Firmware. Therefore assume that the SC-SDP ICD will specify using
scheme C to update the beamlet weights (note that in [AD-2f] a mix of scheme A and scheme B was
proposed, so SC sends control every 1 s and SDP applies immediately when received).
Design decision: Use option C. Design decision: Use option C. --> No, we use schema A because it is simplest and sufficient.
******************************************************************************* *******************************************************************************
...@@ -97,8 +117,8 @@ FPGAs in parallel. The synchronous M&C can be for a single PPS instant or for ev ...@@ -97,8 +117,8 @@ FPGAs in parallel. The synchronous M&C can be for a single PPS instant or for ev
PPS and then read the monitoring to ensure that it relates to the same interval on all FPGAs. PPS and then read the monitoring to ensure that it relates to the same interval on all FPGAs.
- Use single event BSN timestamp scheduler - Use single event BSN timestamp scheduler
. Gemini M&C protocol does not have timestamp activated control yet, therefore use separate BSN scheduler . Gemini M&C protocol does not have timestamp activated control yet, therefore use separate BSN
control point. scheduler control point.
. SCU can read the statistics after the scheduled BSN . SCU can read the statistics after the scheduled BSN
. The next integration lasts until the next scheduled BSN . The next integration lasts until the next scheduled BSN
. The programmable interval allows arbitrary intergration intervals, which avoid the need for the . The programmable interval allows arbitrary intergration intervals, which avoid the need for the
...@@ -197,7 +217,8 @@ Behaviour of the data points: ...@@ -197,7 +217,8 @@ Behaviour of the data points:
. Sync, dual page monitor, periodic event latch sum values and restart integration at every sosi.sync . Sync, dual page monitor, periodic event latch sum values and restart integration at every sosi.sync
- ST_SST - ST_SST
. SYnc, dual page control, periodic event page swap at sync when last value was written (so only then swap) . Sync, dual page control, periodic event page swap at sync when last value was written (so only
then swap)
- DP_FRINGE_STOP_OFFSET - DP_FRINGE_STOP_OFFSET
******************************************************************************* *******************************************************************************
...@@ -208,7 +229,8 @@ Behaviour of the data points: ...@@ -208,7 +229,8 @@ Behaviour of the data points:
[2] TCP = Transmission Control Protocol (RFC 793) [2] TCP = Transmission Control Protocol (RFC 793)
[3] UDP = User Datagram Protocol (RFC 768) [3] UDP = User Datagram Protocol (RFC 768)
TCP is a connection oriented protocol and is used when the data transfer needs to be intact and complete (e.g. files). TCP is a connection oriented protocol and is used when the data transfer needs to be intact and
complete (e.g. files).
- retransmit corrupt or lost datagrams - retransmit corrupt or lost datagrams
- remove duplicate datagrams - remove duplicate datagrams
...@@ -216,7 +238,9 @@ TCP is a connection oriented protocol and is used when the data transfer needs t ...@@ -216,7 +238,9 @@ TCP is a connection oriented protocol and is used when the data transfer needs t
- rate adaption dependent on the throughput capacity of the network and the receiver - rate adaption dependent on the throughput capacity of the network and the receiver
- fragmentation of application data into datagrams [1] - fragmentation of application data into datagrams [1]
UDP is a transaction oriented and connectionless protocol and is used when the data transfer needs low latency and lost data may remain lost (e.g. video). The data interface to the application is discrete packets. UDP is a transaction oriented and connectionless protocol and is used when the data transfer needs
low latency and lost data may remain lost (e.g. video). The data interface to the application is
discrete packets.
IP takes care of: IP takes care of:
...@@ -231,7 +255,11 @@ Ethernet ...@@ -231,7 +255,11 @@ Ethernet
- medium access control - medium access control
A socket pair identifies both ends of a connection, i.e. the virtual circuit [3]. For UDP the end-to-end connection identified by the source MAC, IP and UDP port tuple and destination MAC, IP and UDP port is sufficient, because UDP operates per datagram [3]. For TCP in addition a connection needs to be setup, because TCP needs to maintain the state of multiple datagrams that are communicated [2]. A socket pair identifies both ends of a connection, i.e. the virtual circuit [3]. For UDP the
end-to-end connection identified by the source MAC, IP and UDP port tuple and destination MAC,
IP and UDP port is sufficient, because UDP operates per datagram [3]. For TCP in addition a
connection needs to be setup, because TCP needs to maintain the state of multiple datagrams
that are communicated [2].
To make a reliable transport protocol involves: To make a reliable transport protocol involves:
...@@ -248,7 +276,8 @@ MM transaction ...@@ -248,7 +276,8 @@ MM transaction
Verify flash Verify flash
- using readback is necessary with UCP due to that it uses a MM-DP fifo. - using readback is necessary with UCP due to that it uses a MM-DP fifo.
- the transaction from FPGA to flash on UniBoard should preferrably have been readback already for each write request. - the transaction from FPGA to flash on UniBoard should preferrably have been readback already
for each write request.
******************************************************************************* *******************************************************************************
* Conclusion: * Conclusion:
...@@ -257,5 +286,5 @@ Verify flash ...@@ -257,5 +286,5 @@ Verify flash
- Identify casue of error preferrably via a single monitoring point - Identify casue of error preferrably via a single monitoring point
- With proper monitoring no test time is needed - With proper monitoring no test time is needed
- Support writing status fields in a test mode for SW - FW interface testing - Support writing status fields in a test mode for SW - FW interface testing
- Use 1 s sync interval of PPS to time period M&C events for all. Optionally support a local BSN scheduler - Use 1 s sync interval of PPS to time period M&C events for all. Optionally support a local
for the XST. BSN scheduler for the XST.
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment