diff --git a/applications/lofar2/doc/prestudy/station2_sdp_m_and_c.txt b/applications/lofar2/doc/prestudy/station2_sdp_m_and_c.txt
index 65b134f8b4b61b6fea6866d814b58da3bf2f4f14..c3caa48420577f11a63bae87f23026680f7acb19 100755
--- a/applications/lofar2/doc/prestudy/station2_sdp_m_and_c.txt
+++ b/applications/lofar2/doc/prestudy/station2_sdp_m_and_c.txt
@@ -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
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 SC M&C of SDP concerns two seperate parts:
+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 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 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
@@ -41,7 +47,14 @@ Relevant L2 requirements for SDP monitoring points (BH):
* 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
@@ -52,13 +65,20 @@ Option Beamlet weights update scheme SDP weigths memory
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 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.
+* 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 the fixed 1 s grid of the PPS.
+* 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
PPS and then read the monitoring to ensure that it relates to the same interval on all FPGAs.
- Use single event BSN timestamp scheduler
- . Gemini M&C protocol does not have timestamp activated control yet, therefore use separate BSN scheduler
- control point.
+ . Gemini M&C protocol does not have timestamp activated control yet, therefore use separate BSN
+ scheduler control point.
. SCU can read the statistics after the scheduled BSN
. The next integration lasts until the next scheduled BSN
. The programmable interval allows arbitrary intergration intervals, which avoid the need for the
@@ -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
- 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
*******************************************************************************
@@ -208,7 +229,8 @@ Behaviour of the data points:
[2] TCP = Transmission Control Protocol (RFC 793)
[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
- remove duplicate datagrams
@@ -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
- 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:
@@ -231,7 +255,11 @@ Ethernet
- 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:
@@ -248,7 +276,8 @@ MM transaction
Verify flash
- 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:
@@ -257,5 +286,5 @@ Verify flash
- Identify casue of error preferrably via a single monitoring point
- With proper monitoring no test time is needed
- 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
- for the XST.
+- Use 1 s sync interval of PPS to time period M&C events for all. Optionally support a local
+ BSN scheduler for the XST.