Contents ======== 1. Purpose 2. License 3. Overall design goals 4. Protocol descriptions 5. Clock distribution considerations 5a. PLL-friendly 5b. Transmission frequency 5c. Phase-alignment - which clock cycle (PLL mode) 6. VHDL interface 6a. Clock and time distribution 6b. Signal distribution 6d. Additional pipe-lining 7. Examples 8. Performance 9. Compilation and testing 10. Acknowledgements (referencing) 11. Contact 1. Purpose ========== Rataser is a collection of unidirectional single-wire signal transmission protocols, suitable for use over various (dispersion) qualities of cables and fibres. The implementation of the sender and receiver functions is in generic VHDL. The protocols support clock and time distribution, general signal distribution and (todo) trigger distribution. 2. License ========== Rataser is free software; distributed under the 3-clause BSD license. For details, see the accompanying LICENSE file. 3. Overall design goals ======================= The two main boundary conditions of design are to make the protocols unidirectional and single-wire. These requirements come from an ease-of-use perspective, and also from the low-latency requirements for the signal and trigger distribution, where the use-cases simply do not allow the time for any re-transmissions or similar. (If they had allowed, then e.g. plain Ethernet would be used.) The designed-for use cases are in accelerator-based physics experiments, but the protocols may of course be suitable also elsewhere. The boundary conditions also allow to achieve several other goals: - Resilience against (small) amounts of transmission errors. - Monitoring of transmission quality. - Suitability for optical fibre transmission. - PLL-friendly clock distribution. - Continuous timestamp distribution without reset signals. - Efficiency (bandwidth / latency). - Embedded signal (wire) labelling (todo). The use of forward error correction, mainly through Hamming encoding, together with the transmission of each bit as itself and its inverse achieves immunity against small errors, where any triple-bit error in the transmission can be handled. The forward error correction also allows the receiver to continuously monitor the transmission for errors. Thus, connections with occasional faults can be identified and hopefully exchanged or improved before they impact operation. The protocols are designed to be short-term DC-balanced with frequent level changes, thus making them suitable for optical fibre transmission, as well as differential or unipolar cables. 4. Protocol descriptions ======================== The protocols use multiple layers of logical encoding steps, which are combined in selected ways for the different protocols to achieve the various performance goals. The layers are (ordered lower to higher levels): 1.a) Raw bit-slots, encoded as either low or high. This is used for signal transmission, and the (to-be) trigger distribution. .----. .---------. .---------. .----. .---- 0 | 1 | 0 | 1 1 | 0 | 1 1 | 0 0 | 1 | 0 | 1 ----' '----' '----' '---------' '----' 1.b) Raw bit-slot pulses, encoded as either long or short pulses, with (fixed) period leading edge of each pulse. .----. .--. .----. .----. .----. .--. .--. .--. | 1 | | 0| | 1 | | 1 | | 1 | | 0| | 0| | 0| -' '--' '----' '--' '--' '--' '----' '----' '---- <-------> <----> <--> <-------> Long pulse. Short pulse. <-------> Fixed period between rising edges. This scheme is used for the clock transmission, since the strictly periodic leading edge of the pulse is a requirement to be fed to a PLL, and also simplifies timestamp tracking when no PLL is used to recover the clock itself. 1.c) As an extension to 1.b), 8-fold groups of such pulses can be transmitted. Each group starts with 2 fixed (one short and one long), followed by a 6-fold repetition of the actual bit value (with every second slot value inverted (short <-> long). This is used for the clock transmission when intended for PLL consumption, since it allows the difference between long and short pulses to be minimised, causing less clock jitter after the PLL. The length of all 6 pulses are taken into account together when the receiver decides if the payload bit is a 0 or 1. Thus, the 8-fold group can be described as 10QqQqQq where q is the bit value and Q its inverse. Since the higher-level pattern (see 2) below) ensures DC-balance, the fixed '10' pattern can be used to synchronise to the start of such 8-fold groups in the stream of pulses, since only the start bits will occur regularly with a cycle of 8 pulses. 2) All protocols then use a 24-slot pattern with 8+1 data bits (a-h and v below) encoded in 18 slots, and 6 fixed slot values: 0 1 2 Slot index: 012345678901234567890123 Entire pattern: 1aAbB0vcCdD01eEfFV0gGhH1 Data bits: .a.b...c.d...e.f...g.h.. Inverse data bits: ..A.B...C.D...E.F...G.H. Auxiliary bit: ......v..........V...... Fixed slots: 1....0.....01.....0....1 Each data-bit is followed by its inverse (A-H), thereby ensuring most of the DC-balance. The auxiliary bit is also balanced in the same way, although over a longer distance, and the fixed slots have an equal number of 0s and 1s. The pattern is designed such that the fixed slots and pairwise inverses allow the alignment of its start in a bit-stream to be uniquely determined, also if the entire bit-stream has been inverted. (This particular pattern was found with an exhaustive search evaluating several desirable pattern features, see the pattern/singlexor5.c program.) 3) The parent step feeding the 24-slot pattern is Hamming encoding data, which allows forward error correction such that single-bit errors can be corrected and double-bit errors detected. By treating the plain and inverted data bits separately, the error recovery capabilities are increased, such that any three-bit errors can be handled. 3.a) For signal transmission, a Hamming(7,4) code with additional parity bit is employed, such that the 8 raw data bits allow transmission of 4 payload bits. Thus for each 24-slot pattern, four signal values are transmitted (updated). 3.b) To allow signal transmission which require more frequent updates than is allowed by having only one update each 24-slot pattern, the protocol can be dedicated to send only one signal, with an update for each data bit. The output signal is updated every three slots. In this case, Hamming encoding is not used. This naturally has less margin against transmission errors. The output signal is however only updated if the data bit and its inverse agree. 3.c) For timestamp distribution, pairs of 24-slot symbols are grouped together (identified by the auxiliary bit v being 0 for the first 24-slot symbol of the group and 1 for the second), giving 16 raw data bits. This allows a Hamming(15,11) code with additional parity bit. Of the 11 payload bits, 4 are used for timestamp data, 5 for auxiliary signals and 2 to identify the type of the group. The 64 bits of timestamp data thus require 16 such groups. Four additional groups carry extra information (mainly the pulse period length in ns, which is known by the sender, but unknown by non-PLL receivers). The first group of a timestamp transmission has group marker 0, the following groups are marked 1, and the last group of full timestamp transmission cycle is marked 2. Filler groups with mark 3 are then emitted until the sender time has passed the next transmission time, after which a new cycle of groups is started. 3.d) (Not yet implemented) For the trigger distribution, where the latency to deliver the trigger message matters by contributing to the event-wise dead-time, the 24-slot pattern is used to indicate that an transmission is coming. Normally (when no trigger is sent), all data bits (a-h) are sent as 0 (inverses are still inverses). To indicate an imminent trigger transmission, either bits a-d or e-h (depending on which are about to be sent when the sender gets the trigger transmission request) are all sent as 1 instead (with inverses 0). Directly following these 12 transmission slots, a direct sequence of 11 bits of trigger information. The data is encoded with Hamming(15,11) code with additional parity bit. Each bit is encoded pairwise with its inverse in two slots, using 32 slots in total. This gives an average latency of 5.5+12+32 = 49.5 bit-slots, with a worst-case latency of 11+12+32 = 55 bit-slots. 5. Clock distribution considerations ==================================== The clock and timestamp protocol is designed to give repeatable results, without the use of e.g. reset signals to synchronise local counters at the receivers. Also after power-cycling the electronics, it should be as well-aligned as it was in any previous run, since the time message is continously sent, decoded and verified. By directly having absolute timestamps there is also no extra work during analysis. In PLL-mode, a unique labeling of each clock cycle is established. In non-PLL mode, the time uncertainty is +/- 2 receiver clock cycles (regardless of the period of the rataclock signal). The continuous distribution of the timestamp information also allows for automatic monitoring of the timestamp continuity within each receiver. 5a. PLL-friendly ================ Instead of sending a pure bit-stream with the timestamp information, pulses with a fixed period between the leading edges are transmitted. The payload data bits are encoded as the length of the pulses, i.e. the time of the trailing edge is modulated between short and long for 0 and 1. With the fixed leading edges, this should be acceptable to most PLLs. Naturally, some effect on the timing jitter on the PLL output clocks is unavoidable. This determines if the protocol signal can be used for a PLL input in a specific application, depending on the required precision. When needed, a dedicated clock signal can also be used, in which case the phase-related rataclock signal can used to label the clock cycles. It should be noted that the PLL must repeatably lock on to, and maintain, a stable phase relationship between its input and output clock signals. This is the case for all tested FPGA-internal PLLs, but not for some high-precision PLLs, e.g. the Si5325. Without this repeatability, timing between different receiver systems can jump by one clock cycle when the phase relationship changes (usually on new lock). 5b. Transmission frequency ========================== When the rataclock signal is used to drive a PLL, the main limitation on the rataclock signal is the need to deliver a clock signal which has high enough frequency to be accepted by the PLL. This lower limit is often 10 or 20 MHz for FPGA PLLs. At the same time, a high frequency gives less room to encode and recover pulse length differences for the payload short/long data, and may also be more demanding to transmit. A PLL-generated clock which shall be labelled can be any integer multiple of the rataclock pulse frequency. It is suggested to use a pulse transmission frequency of 25 MHz or 12.5 MHz, since they can both be generated from, and recovered into the popular frequencies of 100, 125 and 200 MHz, and multiples thereof. (For calculations it is however generally easier to consider the period times, i.e. 40 and 80 ns for the pulse periods, and 10, 8, and 5 ns for the mentioned popular clock frequencies..) When the rataclock signal is not used to drive a PLL on the receiving end, the receiver can use any unrelated clock (phase and/or frequency). In this case, the transmitted pulse period can also be much larger. The timestamp precision achievable at the receiver is not determined by the rataclock signal itself, but is +/- 2 clock cycles of the receiver. 5c. Phase-alignment - which clock cycle (PLL mode) ================================================== How to ensure that the cycle labelling is exact? I.e. how to avoid ambiguity when the labelling protocol edge comes right at the clock edge in the FPGA? Note! As far as we have been able to figure out, this issue is fundamental; it also applies to reset-based solutions, and it does not matter if the protocol itself or a pure (phase-related) clock is sent to the PLL. In PLL-labelling mode, the protocol is sampled at four times the frequency of the FPGA clock which shall be labelled. Thus it is determined in which 'quadrant' the phase-alignment is. If (by cable-length / propagation delay between the PLL and the sampling), the leading edge is just at one of the sampling edges, this assignment may jitter between two neighbouring quadrants. But at e.g. a 125 MHz FPGA clock, i.e. 500 MHz over-sampling = 2 ns intervals, there should be no drifts between three quadrants. The main occurring quadrant can thus be used to set a 'setup' parameter designating a nominal quadrant for each FPGA receiver. Pulses ending up in that quadrant, or in its neighbours before or after are then handled unambiguously. If the receiver (repeatedly) sees the leading edge in the opposite (forbidden) quadrant however, it needs to report/consider it as failure. Either someone changed the cabling (if separate clock and protocol cables are used), or a very severe (2 ns) temperature drift occurred. 6. VHDL interface ================= The interfaces to the different protocols are entities with names rataser_[protocol]_[send|recv] 6a. Clock and time distribution =============================== The interface to send a rataclock signal: entity rataser_clock_send is generic (period_bits: integer ); port (clk: in std_logic; tick_ns: in std_logic_vector(63 downto 0); aux_sigs: in std_logic_vector(4 downto 0); info_bit: in std_logic; pulse_period_clks: in std_logic_vector(period_bits-1 downto 0); duty_low_min_clks: in std_logic_vector(period_bits-1 downto 0); duty_low_max_clks: in std_logic_vector(period_bits-1 downto 0); eight_slot: in std_logic; pulse_period_ns: in std_logic_vector(9 downto 0); message_delay_ns: in std_logic_vector(21 downto 0); transmit: out std_logic; transmit_sync: out std_logic ); clk The clock network signal that drives the sender. tick_ns The timestamp at the sender side. Although not necessary, it is assumed to count ns. Updated each clk cycle. The high 32 bits can be updated one cycle after the low 32 bits, i.e. be driven by a carry from the low 32 bits. They are never latched when the low 32 bits wrap. aux_sigs A set of auxiliary signals that are embedded in the transmission of each group (i.e. each Hamming encoded block). info_bit (Not yet implemented.) To be used to send an identifying message. pulse_period_clks The period of each transmitted pulse, in clock cycles. duty_low_min_clks The length of the low level signal after a long pulse, in clock cycles. (I.e., the long pulse length is pulse_period_clks - duty_low_min_clks.) This definition is a bit backwards, due to the implementation. A reasonable value is 25 % of pulse_period_clks. duty_low_max_clks The length of the low level signal after a short pulse, in clock cycles. (I.e., the short pulse length is pulse_period_clks - duty_low_max_clks.) A reasonable value is 75 % of pulse_period_clks. eight_slot Encode each bit as eight transmitted pulses, with a 10QqQqQq pattern, where q is the bit value, and Q its inverse. This is used for PLL reception, since the differences between long and short can be combined from the six data-carrying pulses, and thus allow larger separation between 0/1 than for single pulses, while keeping a small pulse length difference between short and long. pulse_period_ns The pulse period in ns. I.e., this value should be the clk cycle length in ns times pulse_period_clks. This is needed by the non-PLL receiver to adjust to correctly increment the time tracking. The value can also be automatically calculated by the sender from tick_ns when use_pulse_period_ns is 0. use_pulse_period_ns Use the provided pulse_period_ns value. message_delay_ns The delay between the start of full timestamp message cycle and its end. This is how old the time would look at a receiver if not corrected (and no cables or reception decoding latency is included; c.f. the receiver receive_delay_ns port). This value is added to the transmitted timestamp to compensate for this effect. The value should be: (16 + 4) * 2 * 24 * (eight_slot ? 8 : 1) * pulse_period_ns i.e. the product of: - Number of groups per full time message (16 + 4). - Number of bits per Hamming coded group (2 * 24). - Number of pulses per bit, 8 if eight_slot, otherwise 1. - The length of each pulse. When the pulse_period and/or eight_slot are user- configurable parameters, it might be useful to also have the controlling CPU code deliver this value, since FPGA multipliers can be expensive. transmit The output rataclock signal. transmit_sync A mark indicating the start of each full transmission cycle. Useful for scope debugging. Note that this is only roughly periodic, since the group length is fixed, but not a multiple of the timestamp transmission interval. The interface to receive a rataclock signal: entity rataser_clock_recv is generic(period_bits: integer; num_last_edges: integer; max_skew_4phase_sample: string ); port (clk: in std_logic; clk90: in std_logic; receive: in std_logic; eight_slot: in std_logic; expect_edge: in std_logic_vector(1 downto 0); last_edges: out std_logic_vector(num_last_edges*2-1 downto 0); use_auto_edge: in std_logic; auto_edge: out std_logic_vector(1 downto 0); receive_delay_ns: in std_logic_vector(15 downto 0); tick_ns_lo: out std_logic_vector(31 downto 0); tick_ns_hi: out std_logic_vector(63 downto 32); aux_sigs: out std_logic_vector(4 downto 0); info_bit: out std_logic; msg_strobe: out std_logic; sync_status: out std_logic_vector(2 downto 0); sync_lost: out std_logic_vector(2 downto 0); bad_signals: out std_logic_vector(4 downto 0); clear_status: in std_logic; pulse_period_clks: in std_logic_vector(period_bits-1 downto 0); clk_period_ns: in std_logic_vector(9 downto 0); pulse_length_min: out std_logic_vector(9 downto 0); pulse_length_max: out std_logic_vector(9 downto 0); pulse_length_diff6: out std_logic_vector(10 downto 0) ); end; period_bits Number of bits for the period arguments. num_last_edges Number of edges to report for the receive phase (edge detector). max_skew_4phase_sample In PLL-mode, the signal is over-sampled four times each clock cycle. When this is done with four independent flip-flops, i.e. without a dedicated primitive (like iserdes), the synthesier/place-and-route needs to be directed to ensure that the signal arrives with not more skew than a quarter of the clock period at the different flip-flops. To allow for some more uncertainty, it is suggested to choose a value about <= 1/8 of the clock period. In non-PLL mode, or when a primitive is used, this option can be ignored (/ be made large). Default is "0.5 ns". clk The clock network signal that drives the sender. When used in PLL-mode (eight_slot = 1), this clock shall come from a PLL driven by the rataclock signal, i.e. be phase-stable relative to it. clk90 90 degree phase-shifted clock signal. Only needed for PLL reception. receive The rataclock signal itself. For PLL-mode, it must be the direct input signal, i.e. it must not be latched. eight_slot The received rataclock signal uses the 8-slot encoding of each transmitted bit. Used for and selects PLL-mode decoding. expect_edge Tell the decoder in PLL-mode at what quadrant the rising edge is expected. Also neighbouring edges are accepted, but the opposite edge is forbidden. In order to avoid off-by-1 clock cycle ambiguity in assigning the timestamp label, this value should be a configuration parameter. last_edges can be used to determine the most common edge detected. last_edges Reports the num_last_edges most recent rising edge quadrants detected. use_auto_edge In case the user does not want to set expect_edge, an internal heuristic to determine a frequently occur rising edge quadrant can be used. A fresh result of the routine is applied whenever the timestamp reception looses sync. This may therefore cause clock cycle label shifts by one cycle!! Thus it is *only* suggested to use this option for quick tests and debugging, as it is likely to complicate later analysis. auto_edge The edge currently selected by the above heuristic. receive_delay_ns Offset value added to the received timestamp. By setting this value appropriately, the effects of the cable length, as well as the internal latency of the decoding process can be compensated, such that different receivers report (almost) the same time for simultaneous events. Also see the sender message_delay_ns port. tick_ns_lo The low 32 bits of the timestamp for the current clock cycle. tick_ns_hi The high 32 bits of the timestamp for the previous clock cycle. This is updated one cycle later in order to split the internal 64-bit adder. The split in low and high part is only to make the delayed latching of the high part explicit. It can however be useful if the timestamp data shall be latched into a 32-bit memory, as the corresponding high 32 bits then are available in the following clock cycle. aux_sigs The received auxiliary signals. They are updated regularly - when each (good) Hamming block of data is received. If reception sync is lost, they are forced to zero (TODO: check this!). info_bit (Not yet implemented.) To be used to receive an identifying message. msg_strobe (TODO: Check this!) Strobe when aux_sigs is updated? sync_status Synchronisation status of the reception. (TODO: some bits will be added for the non-PLL mode.) - 0x01 - 8-slot decoder in sync. - 0x02 - 24-slot symbol decoder in sync. - 0x04 - Timestamps in sync (incl. matching previous!). For PLL mode: shall be 0x7. Do not use timestamps unless this is the case! sync_lost Bit-mask if synchronisation status that has been at any point lost since last clear. Shall be 0 for good connections. Note that quite some bad bits might be handled before sync is lost at any stage. An ongoing sync loss means that timestamps are not usable. bad_signals Bit-mask of bad bits or ill conditions detected at various stages of the decoding chain. Shall be 0 for good connections. This is more sensitive than the sync status checks, since already individual bad bits are detected. - 0x01 - Bad period of the 8-slot symbols. - 0x02 - Start index change of the 8-slot symbol. - 0x04 - Bad bit in 24-slot pattern. - 0x08 - Bad bit in Hamming message. - 0x10 - Timestamp mismatch vs. counted timestamp set by previous messages. clear_status Clear the sync_lost and bad_signals bit-masks. pulse_period_clks The pulse period of the rataclock signal in clock cycles. This is needed by the PLL decoder. clk_period_ns The period of the clk in ns. This is needed by the PLL decoder. sender_period_ns (For debugging.) The value of pulse_period_ns transmitted by the sender. It is used by the non-PLL decoder. track_incr_per_clock (For debugging.) The per-clock increment used by the incoming pulse/bit tracker. Eight bits are fractional. When locked, the following holds: track_incr_per_clock * rcp = sender_period_ns * 256, where rcp is the receiver clock cycles per pulse. Note: if sender_period_ns < 8 (due to not having been received), then internally the bit for 8 is or'ed into the value used. pulse_length_min (For debugging.) The minimum pulse length continously determined by a max-of-min filter. pulse_length_max (For debugging.) As above, but maximum length. Bit values are decoded as '1' when their length is larger than the average of these filtered minimum and maximum pulse lengths. For stable operation, the pulse length difference must be large enough that the lowest value of pulse_length_max is never <= the largest value of pulse_length_min. (Not necessarily simultaneously.) In PLL-mode, the pulse length is counted for each of the 4 super-samples. I.e. each clock cycle can contribute 4 units to the counting. pulse_length_diff6 (For debugging.) In PLL-mode: the difference between the long and short pulses, for groups of six pulses that encode the same payload bit. The three inverted pulses are counted with negative sign. 6c1. Examples ============= 6d. Additional pipe-lining ========================== The achievable minimum clock cycle period for an FPGA depends on the length of the longest logic chain between register latches. Which logic expression becomes the longest depends on the model and grade of FPGA which is targeted. In order to allow some flexibility in inserting pipeline stages in the code, a few generic parameters (pipeline_... in the interfaces above) control some optional pipeline stages. Generally, introducing a pipeline stage will cause more LUTs to be used, as well as flip-flops. Minimum period values for some FPGA kinds are extracted from synthesis of the code for those FPGA modules. They can be found in ... (TODO). The VHDL code will generally easily be configured to run the minimum period of the clock well below .. ns (i.e. ... MHz) even on 10-year old FPGAs, and reaching .. ns with pipelining stages. (TODO :) ) 7. Examples =========== Rataclock sender examples: signal send_tick_ns : unsigned(63 downto 0) := (others => '0'); signal send_aux_sigs : std_logic_vector(4 downto 0); -- Additional signals. -- All ports are either std_logic or std_logic_vector. -- See the interface definition in Section 6 for appropriate vector sizes. clock_sender : rataser_clock_send generic map(period_bits => 6) -- Number of bits in period arg. port map(clk => sender_clk, tick_ns => std_logic_vector(send_tick_ns), aux_sigs => send_aux_sigs, info_bit => send_info_bit, pulse_period_clks => csend_pulse_period_clks, -- Config. duty_low_min_clks => csend_duty_low_min_clks, -- Config. duty_low_max_clks => csend_duty_low_max_clks, -- Config. eight_slot => csend_eight_slot, -- Config. transmit => out_rataclock, -- Output serial signal. transmit_sync => out_rataclock_sync -- For debug/scope only. ); send_info_bit <= '0'; -- Not used yet. -- Sender local clock is 50 MHz (20 ns). -- Emitted rataclock period 80 ns, for PLL receiver. -- Rataclock period 4 clock cycles. -- The short pulse is 2 cycles, and the long pulse is 3 cycles. -- send_tick_ns shall increase by 20 every clk50MHz rising edge, for -- the distributed time value to represent ns. csend_pulse_period_clks <= std_logic_vector(to_unsigned(4, 6)); -- Period. csend_duty_low_min_clks <= std_logic_vector(to_unsigned(1, 6)); -- Long 4-1. csend_duty_low_max_clks <= std_logic_vector(to_unsigned(2, 6)); -- Short 4-2. csend_eight_slot <= '1'; -- For PLL reception. -- Sender local clock is 125 MHz (8 ns). -- Emitted rataclock period 40 ns, for PLL receiver. -- Rataclock period 5 clock cycles. -- The short pulse is 2 cycles, and the long pulse is 3 cycles. csend_pulse_period_clks <= std_logic_vector(to_unsigned(5, 6)); -- Period. csend_duty_low_min_clks <= std_logic_vector(to_unsigned(2, 6)); -- Long 5-2. csend_duty_low_max_clks <= std_logic_vector(to_unsigned(3, 6)); -- Short 5-3. csend_eight_slot <= '1'; -- For PLL reception. -- Sender local clock is 125 MHz (8 ns). -- Emitted rataclock period 256 ns, for PLL receiver. -- Rataclock period 32 clock cycles. -- The short pulse is 12 cycles, and the long pulse is 20 cycles. csend_pulse_period_clks <= std_logic_vector(to_unsigned(32, 6)); --Period. csend_duty_low_min_clks <= std_logic_vector(to_unsigned(12, 6)); --Long 5-2. csend_duty_low_max_clks <= std_logic_vector(to_unsigned(20, 6)); --Short 5-3. csend_eight_slot <= '0'; -- For non-PLL reception. Rataclock receiver examples: -- All ports are either std_logic or std_logic_vector. -- See the interface definition in Section 6 for appropriate vector sizes. clock_receiver : rataser_clock_recv generic map(period_bits => 6, -- Number of bits in period arg. num_last_edges => 1) -- Number of edges reported. port map(clk => pll_clk, clk90 => pll_clk_90, receive => in_rataclock, -- Input serial signal. eight_slot => crecv_eight_slot, -- Config. expect_edge => crecv_expect_edge, last_edges => recv_last_edges, use_auto_edge => crecv_use_auto_edge, auto_edge => recv_auto_edge, tick_ns_lo => timestamp(31 downto 0), -- Output timestamp, tick_ns_hi => timestamp(63 downto 32), -- hi in 2nd cycle. aux_sigs => recv_aux_sigs, info_bit => recv_info_bit, msg_strobe => recv_strobe, sync_status => recv_sync_status, -- Current sync status. sync_lost => recv_sync_lost, -- Sticky sync status. bad_signals => recv_bad_signals, -- Sticky protocol issues. clear_status => clear_status, -- Clear sticky status. pulse_period_clks => crecv_pulse_period_clks, -- Config. clk_period_ns => crecv_clk_period_ns, -- Config. sym8_debug => recv_sym8_debug); -- With PLL reception, the clock signals (pll_clk and pll_clk_90) -- must come from a PLL driven by the in_rataclock signal, or -- another phase-related clock signal. -- Receiving a 80 ns period rataclock signal, with a local PLL that -- generates a 50 MHz (20 ns) receiver clock: crecv_eight_slot <= '1'; crecv_pulse_period_clks <= std_logic_vector(to_unsigned(4, 6)); -- Period. crecv_clk_period_ns <= std_logic_vector(to_unsigned(20, 10)); -- Period. -- Instead letting the PLL generate a 100 MHz local clock: crecv_eight_slot <= '1'; crecv_pulse_period_clks <= std_logic_vector(to_unsigned(8, 6)); -- Period. crecv_clk_period_ns <= std_logic_vector(to_unsigned(10, 10)); -- Period. -- For PLL reception testing, the easiest is to use the internal -- edge (phase) detection. This is however not necessarily stable, -- and may yield a shift of one clock cycle if lock is lost. crecv_use_auto_edge <= '1'; crecv_expect_edge <= "00"; -- Dummy value. -- For non-PLL reception, there is no requirement on the receiver -- clock period relative to the rataclock signal (except that it -- must be fast enough to distinguish short and long pulses). crecv_eight_slot <= '0'; -- All other configuration ports are not used and can be set to 0. crecv_pulse_period_clks <= (others => '0'); crecv_clk_period_ns <= (others => '0'); crecv_use_auto_edge <= '0'; crecv_expect_edge <= "00"; 8. Performance ============== 9. Compilation and testing ========================== Usage of the code as such does not involve any separate compilation steps. The code is intended to be included into other projects either by symlinking or copying. The distribution includes a machinery to test the routines using sample and random data, as well as determining approximate minimum clock periods achievable using different pipelining options. (TODO) For tests, the VHDL code is compiled using ghdl (http://ghdl.free.fr/). To perform the tests: To-write. 10. Acknowledgements (referencing) ================================== A paper describing Rataser is in preparation. Please check for the latest information: http://fy.chalmers.se/~f96hajo/rataser/ Meanwhile, refer to the above URL. The author is very interested in both success reports, and, in particular, any problems encountered when using Rataser. 11. Contact =========== Håkan T. Johansson e-mail: f96hajo@chalmers.se Subatomic, High Energy and Plasma Physics Department of Physics Chalmers University of Technology 412 96 Göteborg Sweden