diff --git a/applications/lofar2/doc/prestudy/station2_sdp_hdl_components.txt b/applications/lofar2/doc/prestudy/station2_sdp_hdl_components.txt
index 86d425c6093b5ff9422589b1dcfc389045216be6..9a7ea1100725ad1e2a3e248198045f817fb91bc4 100755
--- a/applications/lofar2/doc/prestudy/station2_sdp_hdl_components.txt
+++ b/applications/lofar2/doc/prestudy/station2_sdp_hdl_components.txt
@@ -142,221 +142,229 @@ inputs have the same 64 bit sync and BSN.
*******************************************************************************
Assumptions:
-- Per input the Rx packets arrive in order
+- Done: Per input the Rx packets arrive in order
. a packet contains one or more blocks, on the ring every packet contains one block
-- Only allow correct blocks to enter the FPGA processing
+- Done: Only allow correct blocks to enter the FPGA processing
. the block validation is based on Rx packet CRC and BSN at sync
-- Usage schemes:
- . N = 2 inputs aligner with 1 local data and 1 remote data
- . N > 2 inputs aligner with 1 local data and N-1 remote data
- . N >=2 inputs aligner with 0 local data and N remote data (not used on ring, but was used in
+- Done: Usage schemes:
+ . Ignore: N = 2 inputs aligner with 1 local data and 1 remote data
+ . Ignore: N > 2 inputs aligner with 1 local data and N-1 remote data
+ . Ignore: N >=2 inputs aligner with 0 local data and N remote data (not used on ring, but was used in
APERTIF)
- . Treat all inputs equal, so no special role for a local input to suit more general usage
-- The local sync and BSN sources on all FPGAs are synchronous, to avoid additional BSN latency
+ . Do not: Treat all inputs equal, so no special role for a local input to suit more general usage.
+ . Done: Allow using input 0 as reference ouput. This can be a functional local input or an
+ artificial local input.
+- Done: The local sync and BSN sources on all FPGAs are synchronous, to avoid additional BSN latency
between inputs.
-- Static input enable or disable via M&C
- - it is possible to enable or disable any combination of inputs
- - if all inputs are disabled then the output stops.
- - if the input enable or disable setting is changed, then the BSN aligner restarts trying to
+- Done: Static input enable or disable via M&C
+ - Done: it is possible to enable or disable any combination of inputs
+ - Done: if all inputs are disabled then the output stops.
+ - Ignore: if the input enable or disable setting is changed, then the BSN aligner restarts trying to
achieve alignment.
- - disabled inputs are output with zero or flagged data
- - for the ring with 1 local and 1 remote input the static input enable/disable supports the
+ - Done: disabled inputs are output with zero or flagged data
+ - Ignore: for the ring with 1 local and 1 remote input the static input enable/disable supports the
align modes:
. disabled,
. local only,
. remote only,
. local and remote
-- Input latency:
- . the input latencies are fixed by design, so inputs have a maximum BSN latency g_bsn_latency
+- Done: Input latency:
+ . Done: the input latencies are fixed by design, so inputs have a maximum BSN latency g_bsn_latency
that is fixed and that does not have to be programmable via M&C.
- . If all hops on the ring are active then the total latency will be (N-1)*t_hop, where t_hop is
+ . Ignore: If all hops on the ring are active then the total latency will be (N-1)*t_hop, where t_hop is
the transport latency of each hop. The total transport latency on the ring is (N-1)*t_hop.
The total ring latency is covered by g_bsn_latency > (N-1)*t_hop.
-- Lost input blocks:
- . accept that the corresponding output is lost too, or output filler block to replace lost block
- . should not cause subsequent blocks to get lost too
- . must not induce a burst of output blocks due output catch up after late lost block detection
- . If often blocks on one input get lost, then it is not acceptable that the output is lost.
- - insert filler block to replace the lost input blocks, or
- - support dynamic input enable/disable control
-- Only output correct blocks, either with the received input block or with flagged filler block
-- The output passes on the sync and therefore it does not have to pass on the BSN
-- The output should support flow control to:
- . smoothen bursts (only an issue with remote drive output)
- . provide output throttling (requires output FIFOs or data blocks that have sufficient gaps)
-- Stopped input:
- . If after some block periods (e.g. g_bsn_latency) there is no more block pending at any input,
+- Done: Lost input blocks:
+ . Ignore: accept that the corresponding output is lost too, or output filler block to replace lost block
+ . Done: should not cause subsequent blocks to get lost too
+ . Done: must not induce a burst of output blocks due output catch up after late lost block detection
+ . Done: If often blocks on one input get lost, then it is not acceptable that the output is lost.
+ - Done: insert filler block to replace the lost input blocks, or
+ - Do not: support dynamic input enable/disable control
+- Done: Only output correct blocks, either with the received input block or with flagged filler block
+- Done: The output passes on the sync and should also pass on BSN to be able to identify lost blocks
+- Done: The output should support flow control to:
+ . Done: smoothen bursts (only an issue with remote drive output)
+ . Ignore: provide output throttling (requires output FIFOs or data blocks that have sufficient gaps)
+- Done: Stopped input:
+ . Ignore: If after some block periods (e.g. g_bsn_latency) there is no more block pending at any input,
then the output stops and the BSN aligner should restart trying to achieve alignment.
-Notes:
-- In LOFAR and APERTIF the BSN aligner does loose more blocks due to input flush and realign
-- a BSN aligner can align at any BSN, using a sync aligner that can only align at the sync, would
+Done: Notes:
+- Done: In LOFAR and APERTIF the BSN aligner does loose more blocks due to input flush and realign
+- Done: a BSN aligner can align at any BSN, using a sync aligner that can only align at the sync, would
cause loosing an entire sync interval to realign, which is not acceptable
-- in APERTIF the sync_checker looses entire sync intervals to ensure filled sync intervals
-- In LOFAR and APERTIF the output is driven by the remote input to add minimal latency, however
+- Ignore: in APERTIF the sync_checker looses entire sync intervals to ensure filled sync intervals
+- Done: In LOFAR and APERTIF the output is driven by the remote input to add minimal latency, however
this results in loosing more packets and having to realign if input packets get lost.
-- In dp_bsn_align the artifical local data stream was used to ensure that the output block size
+- Ignore: In dp_bsn_align the artifical local data stream was used to ensure that the output block size
was correct, by using extra CRC checking (ETH CRC and DP CRC) and store and forward in Rx it is
already certain that only correct input packets arrive at the BSN aligner input. Therefore an
artifical local data stream is not needed.
Design options:
-- Lost packet detection
- . Rely on next received packet:
+- Done: Lost packet detection
+ . Do not: Rely on next received packet:
- check per input that the BSN increments +1
- requires a timeout or overflow detection on other inputs to detect a burst of lost packets
- after a burst of lost packets, typically the output cannot catch up anymore, so then the BSN
aligner needs to flush its input buffer and restart.
- . Per packet using a local block reference.
+ . Done: Per packet using a local block reference.
The local block reference is offset by at least g_bsn_latency relative to the local BSN
source, to ensure that all inputs should have a new block pending for output. This is
possible, because the input latencies are static and within a fixed range:
- in circular buffer the Wr flag for the lost block remains unset
- in FIFO by no pending input or pending input with higher BSN then current output BSN
- ==> Design decision:
- - Use local block reference to define when to detect lost packets, because one lost block
+ ==> Done: Design decision:
+ - Done: Use local block reference to define when to detect lost packets, because one lost block
should not cause subsequent blocks to get lost too.
-- Output driven by remote input block arrival or by local block reference
- . in case of 1 remote input, the remote input does not need a FIFO if it drives the output
- . in case of > 1 remote input, then the remote inputs also requires FIFOs
- . using local input increases the latency from remote input to output, because fixed to the
+- Done: Output driven by remote input block arrival or by local block reference
+ . Ignore: in case of 1 remote input, the remote input does not need a FIFO if it drives the output
+ . Ignore: in case of > 1 remote input, then the remote inputs also requires FIFOs
+ . Ignore: using local input increases the latency from remote input to output, because fixed to the
T_sub grid
- . using local input at T_sub grid avoids bursts, this can also be handled using flow control
+ . Done: using local input at T_sub grid avoids bursts, this can also be handled using flow control
. with local input driving the output the assumption is that if the local input has M packets,
then all remote inputs will have delivered at least one frame, so there should be a sop
pending from all.
- . if there is no local input, then an artifical local input can be derived when BSN is equal on
+ . Done: if there is no local input, then an artifical local input can be derived when BSN is equal on
all enabled remote inputs.
- . if remote input is lost, then entire output is lost if remote drives output, because there is
+ . Ingore: if remote input is lost, then entire output is lost if remote drives output, because there is
not enough spare time to still output the other input packets
- . For remote driven output a slot can be output when for all active inputs there is a block.
+ . Done: For remote driven output a slot can be output when for all active inputs there is a block.
However if one or a series of packets got lost, then the other inputs will overflow. Hence
remote driven output needs a timeout to keep the output running, so a form of local driven
output. Hence to avoid additional packet loss on other inputs or of subsequent packets in time
it is necessary to have a local driven output. Therefore using a remote driven output is not
feasible.
- ==> Design decision:
+ ==> Done: Design decision:
- Use local block reference to define when aligned blocks should be output, because one lost
block should not cause subsequent blocks to get lost too, which is more important then
adding minimal latency and potentially saving BSN aligner input buffer memory.
-- Generation of local block reference to define the output pace:
- . During initial input alignment it is important that all active inputs are indeed active, because together they
+- Done: Generation of local block reference to define the output pace:
+ . Ignore: During initial input alignment it is important that all active inputs are indeed active, because together they
determine the latency difference between inputs. After initial alignment the data output can continue at at a
fixed rate, driven by a local block reference:
- - The local input or the remote input with the least latency could be used as local output block reference,
+ - Do not: The local input or the remote input with the least latency could be used as local output block reference,
because (N-1)*d << 1. This requires having a local input or detecting the closest remote input.
- - Alternatively a dedicated local block reference can be started with a certain time offset can be started
+ - Ignore: Alternatively a dedicated local block reference can be started with a certain time offset can be started
after achieving input alignment. The time offset sets a margin that ensures that at subsequent block
refererence pulses all inputs will have a new block pending if the block is not lost.
- ==> Design decision:
- - Generate local block reference when initial BSN alignment has been achieved and start it with a certain
+ ==> Done: Design decision:
+ - Do not: Generate local block reference when initial BSN alignment has been achieved and start it with a certain
fixed offset.
+ Done: Alternatively start local block reference input with a certain fixed offset that is
+ fixed to the local sync, assuming that the inputs have started at that sync too.
+ This avoids the complication of having to wait for initial BSN alignment, but may
+ introduce some more latency.
-- Filler data insertion
- . Whether to drop a block or to replace it by a filler block depends on the application
+- Done: Filler data insertion
+ . Ignore: Whether to drop a block or to replace it by a filler block depends on the application
- for BF drop all inputs, because beam is affected
- for XC insert filler data, because visibilities of active inputs are still correct.
- for the output via the Network insert filler data to keep the output at the nominal rate, such that
the destination can distinguish between data blocks that got lost inside Station and packet loss on
the Network.
- . Filler blocks can be flagged using a sosi.channel bit as flag
- . Filler data can be:
+ . Done: Filler blocks can be flagged using a sosi.channel bit as flag
+ . Done: Filler data can be:
- undefined
- forced to zero
- random with similar noise level,
- flagged data using most negative integer in real data
- flagged data most negative integer in complex real part and imag part (or use imag part as cause identifier).
- ==> Design decision:
- - Replace lost blocks by filler blocks, to preserve the nominal output rate
- - Flag the filler block via a sosi.channel bit, to distinguish the block
- - Forced the filler data to some constant dependent on a generic, to support transparant operation
- in e.g. an adder where x + 0 = x or a multiplier where x * 1 = x, or to support flagging per data
- value using most negative integer value.
+ ==> Done: Design decision:
+ - Done: Replace lost blocks by filler blocks, to preserve the nominal output rate
+ - Done: Flag the filler block via a sosi.channel bit, to distinguish the block
+ - Done: Forced the filler data to some constant dependent on a generic, to support transparant operation
+ in e.g. an adder where x + 0 = x or a multiplier where x * 0 = 0 or x * 1 = x, or to support flagging
+ per data value using most negative integer value.
-. dynamic input enable/disable in case of lost packets
- - Scheme:
- . Fine per packet scheme:
+. Done: dynamic input enable/disable in case of lost packets
+ - Ignore: Scheme:
+ . Ignore: Fine per packet scheme:
- Input packets arrive every block period, remote packets can arrive anywhere within a block period,
- If one input stops, then g_sop_timeout occurs in s_align and then that input could be dynamically disabled in s_xoff.
Inputs can dynamically be enabled if they arrive within two block periods, in s_align.
- too nervous, too difficult to debug and monitor
- . Coarse per sync interval scheme:
+ . Ignore: Coarse per sync interval scheme:
- if an input has no lost packets during one (or more) sync interval then it can be dynamically enabled for the next sync interval
- if an input has lost packets during one (or more) sync interval then it can be dynamically disabled for the next sync interval
- This is a suitable scheme because it does not react too fast and it can be monitored via M&C.
- Define number of sync intervals for dynamic input control as a generic
- preferred because it is less active and easier to monitor
- - Is dynamic input enable/disable necessary if a lost packet does not affect next packets?
- . If lost data is replaced by filler data, then only static input enable/disable is necessary, because if an input
+ - Ignore: Is dynamic input enable/disable necessary if a lost packet does not affect next packets?
+ . Ignore: If lost data is replaced by filler data, then only static input enable/disable is necessary, because if an input
becomes inactive it will be flagged and the output can still continue.
- . If lost data causes all inputs to be discarded, then dynamic input enable/disable may be useful to avoid that a
+ . Ignore: If lost data causes all inputs to be discarded, then dynamic input enable/disable may be useful to avoid that a
single input causes all output to stop.
- ==> Design decision:
- - It is not necessary to support dynamic input enable/disable, because lost blocks are replaced by filler blocks.
+ ==> Done: Design decision:
+ - Done:It is not necessary to support dynamic input enable/disable, because lost blocks are replaced by filler blocks.
-. Treat all inputs equal or use local input stream as reference to achieve input alignment:
- - using the local data stream as reference stream can benefit from the fact that the local data stream has no
+. Done: Treat all inputs equal or use local input stream as reference to achieve input alignment:
+ - Done: using the local data stream as reference stream can benefit from the fact that the local data stream has no
packet loss, because internally in the FPGA logic is error free.
- - treating all streams equal is more general and also works when static input enable/disable disables the local
+ - Done: treating all streams equal is more general and also works when static input enable/disable disables the local
input.
- ==> Design decision:
- - Treat all inputs equal. Do not make use of the fact that the ring has a local input. In this way the BSN
+ ==> Done: Design decision:
+ - Done: Treat all inputs equal. Do not make use of the fact that the ring has a local input. In this way the BSN
aligner can also work when there are only remote inputs.
-. sync aligner instead of BSN aligner
- - Using the sosi.sync one packet lost causes whole interval lost, this is too much impact.
+. Done: sync aligner instead of BSN aligner
+ - Done: Using the sosi.sync one packet lost causes whole interval lost, this is too much impact.
- ==> Design decision:
- Do not make or use a dp_sync_aligner, because loosing an entire sync interval is not acceptable.
+ ==> Done:Design decision:
+ Done: Do not make or use a dp_sync_aligner, because loosing an entire sync interval is not acceptable.
-. Assume circular buffer:
- - advantage:
+. Done: Assume circular buffer:
+ - Done: advantage:
. direct access to each word in block
. no need to flush blocks, status bit per block tells whether it is filled
- - buffer is filled and read after certain latency, because then all remote packets should have arrived
+ - Done: buffer is filled and read after certain latency, because then all remote packets should have arrived
. provide CP for active input streams, is this needed ?
- - use MM interface to read from head column (with block for all parallel streams)
- - provide mm to dp component with bsn aligner (= dp_block_from_mm ?)
- - provide MP for nof lost = nof filler blocks / stream ?
- . err at eop indicates lost = filler data, sosi_info could have eop at sop like with crosslets_info
+ - Done: use MM interface to read from head column (with block for all parallel streams)
+ - Done: provide mm to dp component with bsn aligner (= dp_block_from_mm ?)
+ - - Done: provide MP for nof lost = nof filler blocks / stream ?
+ . Done: use channel field MSbit to indicate filler data at sop, sosi_info could have eop at sop like
+ with crosslets_info
+
. Initial alignment:
- - Assume the received packets on the inputs contain one block per packet.
- The maximum input latency between blocks from two inputs is g_bsn_latency number of block periods. If the
+ - Ignore: Assume the received packets on the inputs contain one block per packet.
+ Ignore: The maximum input latency between blocks from two inputs is g_bsn_latency number of block periods. If the
maximum input latency is less than one block period, then use g_bsn_latency = 1.
- Assume that all inputs are active and that all inputs start with empty input buffers. At each input packets
+ Do not: Assume that all inputs are active and that all inputs start with empty input buffers. At each input packets
arrive and fill the input buffers.
- The minimum size of the total input buffer memory is g_nof_inputs * g_bsn_latency blocks, because then
- initial alignment can be declared as soon as there is a block pending in the input buffers with the same
- BSN at all inputs.
- After initial alignment the alignment can be maintained by using a local block reference to time the
- subsequent output of aligned input blocks.
- As long as at least one input buffer still has blocks then output can continue using filler blocks. The
- local block reference ensures that the buffers will read empty if they do not get new input, this ensures
- that any input in the buffers can still be output at the correct instant. If all buffers are empty then
- input realignment is needed.
-
- - The initial alignment becomes easier if:
+ . Done: The minimum size of the total input buffer memory is g_nof_inputs * g_bsn_latency blocks, because then
+ initial alignment can be declared as soon as there is a block pending in the input buffers with the same
+ BSN at all inputs.
+ . Do not: After initial alignment the alignment can be maintained by using a local block reference to time the
+ subsequent output of aligned input blocks.
+ . Done: As long as at least one input buffer still has blocks then output can continue using filler blocks. The
+ local block reference ensures that the buffers will read empty if they do not get new input, this ensures
+ that any input in the buffers can still be output at the correct instant. If all buffers are empty then
+ input realignment is needed.
+
+ - The alignment becomes easier if:
. it is not done on the entire 64 bit BSN, but only on a periodic fraction r of the BSN,
. the periodic BSN has a period that is a power of 2, so r = BSN[R-1:0].