INFN-FE, 2014-04-07
Angelo Cotta Ramusino
GTKRO-side controller of the TDCpix serial configuration link: software description
last modified 2014-04-07
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“ The main configuration block (tdcpix_config_block) through which all configuration functions are accessed
exists as one monolithic block that spans almost the whole width of the chip, leaving 50m on either side for test
signals to be passed. The block is 500um high and occupies metal layers M1, M2 and M3. Within this block
the configuration is organised into several logically distinct
components, listed below:
 the interface to the outside world;
 main loop controller state machine and control loop;
 global chip configuration;
 quarter chip configuration;
 column pair configuration;”
Fig. 1 An overview of the control loop showing the individual blocks, the order in which they are linked together to form the
loop, and the position of the control state machine (Ctrl FSM). The control bus is also shown, broadcast to all slave block. (from:
“The TDCPix Design Manual”, v. 1.2, 24 Feb 2013)
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“Main Configuration State Machine and Main Control loop
Commands reaching the configuration state machine are
immediately echoed to the controller via the serial output. This
enables a data/link integrity check to be performed. Once executed,
most commands evoke a reply that is also sent. scheme implies that
the output bandwidth of the configuration block is necessarily twice
the input bandwidth and sending commands too quickly will
overflow the input buffer causing commands to be lost.”
Structure of the 9-bit command word
Structure of the 9-bit command word:
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“
 SRST: when the SRST bit in the command word is set,
the controller state machine will assert the SRST
control line for 1 SCLK cycle, clearing all registers in
the control loop. All ancilliary functions are also reset.
Note that this does not affect the serialiser or
deserialiser, and that any other command bits set in the
command word with the SRST bit will be ignored. No
reply is generated for this command and other
commands may follow immediately.
 SAS: when set, all SS0/1 commands and SD0/1 data apply to the bypass register. This command has no
meaning for PLF and PLB commands, and also has no meaning if set alone.
 PLF: when set, the contents of the shift register are loaded into the storage register. This command takes a
single SCLK cycle to execute and has no effect on Read-Only registers. The reply generated from this
command will have the top 4 bits set to “1000", and the bottom 4 bits may be set to anything.
 PLB: when set, the contents of the storage register for Write/Read-Back registers, and the values present at
the status bit input for the Read-Only registers, are loaded into the shift register. Note that the state machine
takes care of asserting the SSE0 and PLB signals in the design: it is sufficient to set the PLB command bit.
The reply generated from this command will have the top 4 bits set to “1000", and the bottom 4 bits may be
set to anything.
 SS0 and SS1: these commands are functionaly identical: two are included to accelerate access to the
control loops, hence both may be set at the same time. When set, the corresponding datum (i.e. SD0 for SS0
and SD1 for SS1) is shifted into the loop. In the event of both being set, SD0 is shifted into the loop first,
followed by SD1. The reply generated by this command has the top 4 bits set to “1000" and the bottom 4
bits will contain the command bit that was set and, the corresponding datum that was shifted out of the loop.
 Command Priority: serial commands (SS1/0) and parallel commands are mutually exclusive, and parallel
commands take priority, i.e. setting both together will result in the PLB/PLF commands being executed and
the SS0/1 commands being ignored. PLF and PLB may occur together, and if so, PLF is executed first and
then PLB. For multiple commands, only one reply is sent.
”
question to Matt: is it true that replies for PLF/PLB/SS0/SS1 have “1000” in the top 4 bits? what
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“Main Control Loop
All registers, and consequently all configuration functionality in the chip, are accessed via the control loop. This
is an array of registers joined together into a shift register, with the input and output connected to the
configuration state machine. Each register performs either the storage of a value, or provides readback
capability, introducing the value into the
shift register. These two basic building
blocks are shown in figure 6.5. These
registers are grouped together into
Write/Read-Back registers, used for the
storage of values, and Read-Only registers,
used to read back status information. Once
grouped, a bypass function has been
included, that allows the register group to be
excluded from the main control loop. These
bypass registers are also joined into a shift
register and this is separately accessible. Pairs of Write/Read-Back and Read-Only registers are aggregated
together to form the basis of the three groups previously mentioned (global, quarter chip and column pair
controllers). In addition to these registers additional functionality is also included in some cases to provide full
control of the chip's resource.”
Note: whenever a register group is bypassed, a single register is inserted in its place to break the combinatorial
path from input to output (in order to simplify setup/hold constraints).
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“Control State Machine
The control bus comprises six signals that
operate on the shift register loop and these are in
turn controlled from the configuration state
machine (see Fig.1)… The control state machine
has no details programmed into it about the
global structure of the loop, or what state it is in
at any moment during the operation, but merely
reacts to the commands it receives. The internal
state of the loop must be maintained by the
external controller (FPGA and software).”
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“QChip Configuration Interface
The QChip configuration interface
contains only the bits required to drive
and read-back the serial configuration
registers in the QChip, as well as a
reset command:
 Load Operation
An operation loading a new value into the qchip register comprises a series of load transactions on the main
control loop that serve to manipulate this interface. Each bit to be loaded into the QChip must be presented
to the SDATA FROM pin, whilst the EN SSHIFT is asserted. A subsequent STROBE CTRL assertion causes
the clock-domain-crossing interface within the QChip to generate a serial shift operation shifting this bit
into the load shift register. This must be repeated in a loop until the desired number of bits have been shifted
into the load shift register. Following this, these bits must be parallel loaded into the storage part of the
configuration registers. This is achieved by asserting EN PLOAD and STROBE CTRL.
 Read-Back Operation
To read back the contents of the QChip control register and/or the QChip status register, the values must
first be parallel loaded into the shift register by asserting EN RDEN, EN SSHIFT, EN PLOAD and STROBE
CTRL. Once this is done, the data are in the load/unload shift register and may be serial shifted out. This is
done in a similar manner to the load operation, except that the value present on the SDATA FROM pin must
be latched into the main control loop and read back from there.
 Acceleration of the interface
The QChip control interface block contains a circuit designed to accelerate access to the QChip and other
similar interfaces. The circuit comprises six registers organised in two sets of three. The STROBE
GENERATOR input causes an active high pulse to be generated when its value changes. … The external
controller is responsible for
maintaining the state of the
STROBE GENERATOR to be
consistent, although it would be
relatively simple to resynchronise
the two. The reset functionality
comes from the ENABLE signal,
which, inverted, serves as a reset
to the registers. This circuit
enables a single bit to be shifted into the shift register from a single load operation of the main control loop
rather than taking two (note that the QChip and the configuration subsystems operate in different clock
domains).
This is an array of registers joined together into a shift register, with the input and output connected to the
configuration state machine. Each register performs either the storage of a value, or provides readback
capability, introducing the value into the shift register. These two basic building blocks are shown in figure
6.5. These registers are grouped together into Write/Read-Back registers, used for the storage of values,
and Read-Only registers, used to read back status information. Once grouped, a bypass function has been
included, that allows the register group to be excluded from the main control loop. These bypass registers
are also joined into a shift register and this is separately accessible. Pairs of Write/Read-Back and ReadOnly registers are aggregated together to form the basis of the three groups previously mentioned (global,
quarter chip and column pair controllers). In addition to these registers additional functionality is also
included in some cases to provide full control of the chip's resource.”
Fig. 2 The column pair configuration loop. (from: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013)
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“…The clocks (PCLK and SCLK) and level sensitive control signals (SCE and PLOAD) are fed from pixel to
pixel and relayed from the last pixel to the end of column controller. The error input (EI) to the column is fed
through the chained OR gate tree. The data values are passed through the array of serial registers that forms a
shift register with the input signal (SDIN) connected to the input of the rst register in the chain, and the output
(SDOUT) being driven by the data output of the last serial register in the chain. This scheme enables the
connectivity as well as the propagation delay for automatically generated signals to be measured. In the end of
column controller, both the input and output versions of these signals are made available for control and readback and this possibility is exploited in the test bench and will be exploited in the real chip.”
cell is the same as that of the pixel array
Fig. 2 The column pair configuration loop. (assembled from contents of: “The TDCPix Design Manual”, v. 1.2, 24 Feb
2013). Non capisco perche’ parlano di 39 bit io ne conto 38
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“…There are two separate blocks, one for the left (even) column, and the other for the right (odd) column. These
use exactly the same scheme to store each bit as the pixel, and thus the control signals are identical... The left
(even) column configuration is driven by the end of column controller and in turn drives the inputs to the left
(even) hand column pixel configuration, whilst the right (odd) column configuration block is driven by the
outputs of the right hand column pixel configuration. The outputs of the right column configuration drive the end
of column controller inputs.”
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
“…There are two separate blocks, one for the left (even) column, and the other for the right (odd) column. These
use exactly the same scheme to store each bit as the pixel, and thus the control signals are identical... The left
(even) column configuration is driven by the end of column controller and in turn drives the inputs to the left
(even) hand column pixel configuration, whilst the right (odd) column configuration block is driven by the
outputs of the right hand column pixel configuration. The outputs of the right column configuration drive the end
of column controller inputs.”
acr 2014-05-04 understanding function:
int TDCPixCommander::LoadDLLSMConfig(const DLLSMConfigurationArray & dllsmconf)
From: “The TDCPix Design Manual”, v. 1.2, 24 Feb 2013):
6.7 Column Pair Configuration Interface
The column pair configuration interface contains
interfaces to the TDC configuration (two per column
pair), the DLL State Machine configuration and the
column pair configuration bits.
Additionally, there is an SEU detection and correction
mechanism and some non-overlapping signal generators.
The block contains 33 write/read-back configuration bits
and 18 read-only status bits. The allocation of the
configuration and status bits is detailed in tables 6.9 and
6.10.
The configuration registers in the TDCs and the DLL
state machine are identical to those in the QChip.
Likewise, the interface to these configuration registers
is implemented in the same way and to avoid repetition
of the description in section 6.5 will not be described in
detail. Additionally, these three interface all have an
identical control strobe generator to the one described in
section 6.5.1. This will also not be described again.
“The TDCPix Design Manual”, v. 1.2, pag.179
“The TDCPix Design Manual”, v. 1.2, 24 Feb 2013)
pag.162
The column configuration is required to parameterise
certain functions common to the column pair, such as
the discriminator threshold.
“The TDCPix Design Manual”, v. 1.2, pag.178
“The TDCPix Design Manual”, v. 1.2, 24 Feb 2013) pag.132
The column pair configuration default values are set by the function:
ColumnPairConfig.cc(986): int ColumnPairConfig::SetupDefaultValues():
int ColumnPairConfig::SetupDefaultValues()
{
int rv=0;
/* right column control defaults: */
rv=this->SetRightMuxAddress(0xb);
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetIBDIF(0x8);
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetIBPB(0x8) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetVCD(0x8);
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetVB(0x8) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetVC(0x8) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetIPRE(0x8) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
//rv=this->SetTRANGE(0x10) ;
rv=this->SetTRANGE(0x0) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetCAL(0x40) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetPOLCAL(1) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetUnused(1) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
/* left column control defaults: */
rv=this->SetVT2(0) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetVT1(0x20) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetICOM_HIGH(0) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetITL_HIGH(0) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetIRX_HIGH(0) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetLeftMuxAddress(0x6) ;
RG_CHECK_ZERO_RETURN(rv,"Error");
//
for(int col(0); col!=2; col++){
for(unsigned int idx(0); idx!=P_PixelsPerColumn(); idx++){
rv=this->SetPixelTrim(col, idx, 0/*0x1f&idx*/);
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetPixelPolarity(col, idx, col);
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetPixelDisable(col, idx, 1);
RG_CHECK_ZERO_RETURN(rv,"Error");
rv=this->SetPixelCalEnable(col, idx, 0);
RG_CHECK_ZERO_RETURN(rv,"Error");
}
}
return 0;
}
XCVR
“…The clocks (PCLK and SCLK) and level sensitive control signals (SCE and PLOAD) are fed from pixel to pixel and
relayed from the last pixel to the end of column controller. The error input (EI) to the column is fed through the chained
OR gate tree. The data values are passed through the array of serial registers that forms a shift register with the input
signal (SDIN) connected to the input of the rst register in the chain, and the output (SDOUT) being driven by the data
output of the last serial register in the chain. This scheme enables the connectivity as well as the propagation delay for
automatically generated signals to be measured. In the end of column controller, both the input and output versions of
these signals are made available for control and read-back and this possibility is exploited in the test bench and will be
exploited in the real chip.”
module, created by the “ALTERA MegaWizard plug-in manager” instantiates 4 independent transmitter and receiver
channels capable of 3.2Gbps operation (actually 40.08 * 8 * 10 = 3206.4 Mbps) belonging to the same ALTGX
ALTERA macrofunction.
In principle the module could feature just the 4 receivers for the 4 high speed serial data output of one “TDCpix”
but the “XCVR” module implements also 4 transmitter channels in order to allow the GTKRO board to perform self
testing by generating 4 simulated “TDCpix” serial streams.
The 4 channels are not bound and have individual control/status ports. The MegaWizard tool was setup to create
VHDL wrapper files for the XCVR design hierarchy. In order to simulate the XCVR operation the Verilog option was
chosen for the wrapper files in order to overcome some simulation model issues (appendix B).
Fig.1 instantiation of the “XCVR” module (from: “Sx4GX70_GTKRO_NIOS_test_top.v”)
The XCVR module is accompanied by the auxiliary modules “reconfig”, created by the “ALTERA MegaWizard
plug-in manager” and “ALTGXReset_XCVR4x”. The first handles the receivers’ offset cancellation process while the
second handles the generation of the proper reset timing for the receivers and the transmitters in the ALTGX block.
Fig.2 instantiation of the “reconfig” module (from: “Sx4GX70_GTKRO_NIOS_test_top.v”)
Fig.3 instantiation of the “ALTGXReset_XCVR4x” module (from: “Sx4GX70_GTKRO_NIOS_test_top.v”)
The XCVR module
The description of the ALTGX module creation sequence is given in appendix A (TODO: detail the meaning of
at least the main parameters).
The operation of the module is quite straightforward: when the TX pll is locked each transmitter is ready to send
out the 16-bit data received at its input port, coded as data or control code according to the accompanying “control
enable” bit. On the GTKRO board the TX outputs are looped back to the RX inputs of the XCVR module either inside
the FPGA or (current default) by actually connecting to the on-board Finisar FTLF8524P2BNV optical transceivers and
by employing a 1330nm multi-mode fiber patch to connect the FTLF8524P2BNV output and the input ports.
// synopsys translate_off
`timescale 1 ps / 1 ps
// synopsys translate_on
module xcvr_verilog (
cal_blk_clk,
gxb_powerdown,
pll_inclk,
pll_powerdown,
reconfig_clk,
reconfig_togxb,
rx_analogreset,
rx_datain,
rx_digitalreset,
rx_seriallpbken,
tx_ctrlenable,
tx_datain,
tx_digitalreset,
tx_dispval,
tx_forcedisp,
pll_locked,
reconfig_fromgxb,
rx_byteorderalignstatus,
rx_clkout,
rx_ctrldetect,
rx_dataout,
rx_disperr,
rx_errdetect,
rx_freqlocked,
rx_patterndetect,
rx_pll_locked,
rx_runningdisp,
rx_syncstatus,
tx_clkout,
tx_dataout)/* synthesis synthesis_clearbox = 2 */;
input
input
input
input
input
input
input
input
input
input
input
input
input
input
input
output
output
output
output
output
output
output
output
output
output
output
output
output
output
output
cal_blk_clk;
[0:0] gxb_powerdown;
pll_inclk;
[0:0] pll_powerdown;
reconfig_clk;
[3:0] reconfig_togxb;
[3:0] rx_analogreset;
[3:0] rx_datain;
[3:0] rx_digitalreset;
[3:0] rx_seriallpbken;
[7:0] tx_ctrlenable;
[63:0] tx_datain;
[3:0] tx_digitalreset;
[7:0] tx_dispval;
[7:0] tx_forcedisp;
[0:0] pll_locked;
[16:0] reconfig_fromgxb;
[3:0] rx_byteorderalignstatus;
[3:0] rx_clkout;
[7:0] rx_ctrldetect;
[63:0] rx_dataout;
[7:0] rx_disperr;
[7:0] rx_errdetect;
[3:0] rx_freqlocked;
[7:0] rx_patterndetect;
[3:0] rx_pll_locked;
[7:0] rx_runningdisp;
[7:0] rx_syncstatus;
[3:0] tx_clkout;
[3:0] tx_dataout;
entity GTK_DataGenerator is
generic ( tx_trlr0_HI_byte: unsigned := X"AB";
tx_trlr0_LO_byte: unsigned := X"CD";
LOOPCOUNT_MAX_INDEX: integer := 8;
NUMBER_OF_HIT_PER_FRAME: integer := 320;
COUNT_LINK_SINCH_K28_5_MAXINDEX: integer := 32;
NUM_48bit_LINK_SINCH_K28_5: integer := 140000 );
port (
tx_clkout: IN STD_LOGIC;
-- the frequency of "tx_clkout_TX" should be: serializer_clk (3.2G) / 10 (8b/10b encoding) / 2 (byte serializer) = 160MHz
reset: IN STD_LOGIC;
frame_generation_enable: IN STD_LOGIC;
frame_rollover_pulse_40MHz: IN STD_LOGIC;
tx_dataout: OUT STD_LOGIC_VECTOR(15 DOWNTO 0);
tx_ctrlenable: OUT STD_LOGIC_VECTOR(1 DOWNTO 0) );
end entity;
The module instantiates a CRC generator for 16 bit words with a 16 bit CRC-16-CCITT output: The
GTK_DataGenerator module includes the full (48bit) first trailer word in the calculation of the checksum, which is
transmitted then with the second trailer word in the range 31..16.
screenshot from functional simulation of “sim_test_assembly_oct_slave_ta1” (exploiting an abstract model for the
UNIPHY controller)
Please note that in the “test_assembly_oct_slave_ta1”module the 16-bit wide output data port of the
“GTK_DataGenerator” is connected to the input data port of the “GTK_DataReceiver” via the testbench
“test_assembly_oct_slave_ta1_tb”.
how the packets are built in the real TDCpix (from the “TDCpix manual” Feb 24 th 2013): data word
how the packets are built in the GTKRO simulator TDCpix: data word
In the simulator each channel produces 320 hits per frame and thus the hit counter is 9 bit wide. The constant
LOOPCOUNT_MAX_INDEX is 8
-- Data format-hit word (48 bit) -----------------------------------------------------------------bits
variable name
47..40: tx_data_data2_int( 15 downto 8) <= X"00";
39..32: tx_data_data2_int( 7 downto 0) <= std_logic_vector(tx_trlr0_HI_byte);
31.. 28: tx_data_data1_int(15 downto 12) <= X “0”;
27.. 25: tx_data_data1_int(11 downto 9) <= ('0','0','0');
24.. 21: tx_data_data1_int( 8 downto 5) <= fake_coarse_time(3 downto 0);  real “Leading_coarse_time” [7:4]
20: tx_data_data1_int(
4) <= ‘0’;
19.. 16: tx_data_data1_int( 3 downto 0) <= PRBSOut(3 downto 0); the PRBSOut is from a pseudorandom generator
15.. 12: tx_data_data0_int(15 downto 12) <= frame_count ( 3 downto 0);
11.. 9: tx_data_data0_int(11 downto 9) <= ('0','0','0');
8.. 0: tx_data_data0_int( 8 downto 0) <= hit_count(LOOPCOUNT_MAX_INDEX downto 0);
NOTE: bits 24-21 are analyzed by the “GTK_DataLinksToDDRBuffer” module of the GTKRO FPGA firmware to
bucket-order the incoming hit data into the DPRAM input buffer. In the “sim_test_assembly_oct_slave_ta1” debug
suite I have used the least significant bits of the “fake_coarse_time” signal to spread the hits records evenly across all
16 “time buckets”.
how the packets are built in the real TDCpix (from the “TDCpix manual” Feb 24 th 2013): frame word
how the packets are built in the GTKRO simulator TDCpix: frame word
In the simulator each channel produces, AFTER THE END OF A FRAME IS DETECTED, two frame words
The tokens for channel_0 of the test_assembly_ta1 are tx_trlr0_HI_byte = X"FE" and tx_trlr0_HI_byte = X"DE".
The tokens for channel_1 of the test_assembly_ta1 are tx_trlr0_HI_byte = X"CE" and tx_trlr0_HI_byte = X"CA".
-- Frame word 1 format: (48 bit) -----------------------------------------------------------------bits
variable name
47: tx_data_trlr5_int(15) <=’1’;
46..41: tx_data_trlr5_int( 14 downto 9) <= b”000000”;
40..37: tx_data_trlr5_int( 8 downto 5) <= std_logic_vector(tx_trlr0_HI_byte);
36..32: tx_data_trlr5_int( 4 downto 0) <= hit_count(LOOPCOUNT_MAX_INDEX downto 4);
31.. 28: tx_data_trlr4_int(15 downto 12) <= hit_count( 3 downto 0);
27.. 16: tx_data_trlr4_int(11 downto 0) <= frame_count (27 downto 16);
15.. 0: tx_data_trlr3_int(15 downto 0) <= frame_count (15 downto 0);
-- Frame word 0 format: (48 bit) -----------------------------------------------------------------bits
variable name
47: tx_data_trlr2_int(15) <=’1’;
46..44: tx_data_trlr2_int( 14 downto 12) <= b”000”;
43..32: tx_data_trlr2_int( 11 downto 0) <= X"a5a";
31.. 16: tx_data_trlr1_int(15 downto 12) <= checksum_from_CRCgen[15..0];
15.. 8: tx_data_trlr0_int(15 downto 8) <= std_logic_vector(tx_trlr0_HI_byte);
7.. 0: tx_data_trlr0_int( 7 downto 0) <= std_logic_vector(tx_trlr0_LO_byte);
Appendix A.: XCVR module creation through the Altera WegaWizard plug-in manager tool
The images refer to the creation of the XCVR module for the Stratix4GX70 (-3 speed option) based protytpe
The word alignment pattern of K28.5 is the default proposed by the MegaWizard plug-in manager tool
The byte ordering pattern of K27.7 is the default proposed by the MegaWizard plug-in manager tool
The default byte ordering pad pattern is D0.0; preferring to use a control code as a padding character I had chosen the
same K28.5 code used as the word alignment pattern.
Appendix B.: XCVR module creation through the Altera WegaWizard plug-in manager tool
The images refer to the creation of the “xcvr_verilog” module used for RTL simulation with Modelsim to
overcome some simulation model issues occurred with the VHDL wrapper files. The parameter entered in the creation
of the Verilog based design hierarchy are the same as above
Appendix C: ALTERA documentation on StratixIV transceivers:
- webpage_alteradoc\transceiver_setup_stx4_siv53001.pdf
- transceiver_conf_stx4_5v3_01.pdf
- transceiver_architecture_stx4_5v2_01.pdf
- stx4_siv53002_transceiver.pdf
- stx4_xcvr_user_guide.pdf
// BEGIN XCVR assignments
`ifdef XCVR_ENABLE
wire rx_syncstatus_1_0_and, rx_syncstatus_3_2_and, rx_syncstatus_5_4_and, rx_syncstatus_7_6_and; // acr 201203-27
reg rx_syncstatus_1_0_and_sample2, rx_syncstatus_1_0_and_sample1;
reg rx_syncstatus_3_2_and_sample2, rx_syncstatus_3_2_and_sample1;
reg rx_syncstatus_5_4_and_sample2, rx_syncstatus_5_4_and_sample1;
reg rx_syncstatus_7_6_and_sample2, rx_syncstatus_7_6_and_sample1;
assign HSMB_GXB_TX_p[0]
= tx_dataout_lines[0];
assign HSMB_GXB_TX_p[1]
= tx_dataout_lines[1];
assign HSMB_GXB_TX_p[2]
= tx_dataout_lines[2];
assign HSMB_GXB_TX_p[3]
= tx_dataout_lines[3];
assign rx_datain_lines[0] = HSMB_GXB_RX_p[0];
assign rx_datain_lines[1] = HSMB_GXB_RX_p[1];
assign rx_datain_lines[2] = HSMB_GXB_RX_p[2];
assign rx_datain_lines[3] = HSMB_GXB_RX_p[3];
// acr 2013-11-29 assign rx_seriallpbken_sw = 1'b1; // acr 2013-11-21 debugging not needed anymore; disable
transceiver serial_loopback; ethSW[2]; // acr 2013-01-23 temporarily use this switch
assign rx_seriallpbken_sw = ethSW_rearranged[0]; // temporarily using switch with double function: the PLL
external control is not needed anymore anyhow.
assign rx_seriallpbken[2] = ~rx_seriallpbken_sw;
assign rx_seriallpbken[1] = ~rx_seriallpbken_sw;
assign rx_seriallpbken[0] = ~rx_seriallpbken_sw;
assign tx_4_digitalreset[3]
=
tx_digitalreset[0];
assign tx_4_digitalreset[2]
=
tx_digitalreset[0];
assign tx_4_digitalreset[1]
=
tx_digitalreset[0];
assign tx_4_digitalreset[0]
=
tx_digitalreset[0];
assign rx_4_analogreset[3]
=
rx_analogreset[0];
assign rx_4_analogreset[2]
=
rx_analogreset[0];
assign rx_4_analogreset[1]
=
rx_analogreset[0];
assign rx_4_analogreset[0]
=
rx_analogreset[0];
assign rx_4_digitalreset[3]
=
rx_digitalreset[0];
assign rx_4_digitalreset[2]
=
rx_digitalreset[0];
assign rx_4_digitalreset[1]
=
rx_digitalreset[0];
assign rx_4_digitalreset[0]
=
rx_digitalreset[0];
assign rx_syncstatus_1_0_and
=
rx_syncstatus[1] & rx_syncstatus[0]; // acr 2012-03-27
assign rx_syncstatus_3_2_and
=
rx_syncstatus[3] & rx_syncstatus[2]; // acr 2012-03-27
assign rx_syncstatus_5_4_and
=
rx_syncstatus[5] & rx_syncstatus[4]; // acr 2012-03-27
assign rx_syncstatus_7_6_and
=
rx_syncstatus[7] & rx_syncstatus[6]; // acr 2012-03-27
always @ (posedge rx_4_clkout[0]) // acr 2012-03-27
begin
rx_syncstatus_1_0_and_sample1 <=
rx_syncstatus_1_0_and;
rx_syncstatus_1_0_and_sample2 <=
rx_syncstatus_1_0_and_sample1;
rx_enabyteord_sig[0]
~rx_syncstatus_1_0_and_sample2;
<=
rx_syncstatus_1_0_and_sample1 &
end
always @ (posedge rx_4_clkout[1]) // acr 2012-03-27
begin
rx_syncstatus_3_2_and_sample1 <=
rx_syncstatus_3_2_and;
rx_syncstatus_3_2_and_sample2 <=
rx_syncstatus_3_2_and_sample1;
rx_enabyteord_sig[1]
~rx_syncstatus_3_2_and_sample2;
<=
rx_syncstatus_3_2_and_sample1 &
end
always @ (posedge rx_4_clkout[2]) // acr 2012-03-27
begin
rx_syncstatus_5_4_and_sample1 <=
rx_syncstatus_5_4_and;
rx_syncstatus_5_4_and_sample2 <=
rx_syncstatus_5_4_and_sample1;
rx_enabyteord_sig[2]
~rx_syncstatus_5_4_and_sample2;
<=
rx_syncstatus_5_4_and_sample1 &
end
always @ (posedge rx_4_clkout[3]) // acr 2012-03-27
begin
rx_syncstatus_7_6_and_sample1 <=
rx_syncstatus_7_6_and;
rx_syncstatus_7_6_and_sample2 <=
rx_syncstatus_7_6_and_sample1;
rx_enabyteord_sig[3]
~rx_syncstatus_7_6_and_sample2;
<=
rx_syncstatus_7_6_and_sample1 &
end
//
`ifdef XCVR_DEBUG
assign tx_ctrlenable[7 : 6] =
generator of test_assembly_ta1
ta1_tx_ctrlenable_ch1; // acr 2013-03-20; use only data from the
assign tx_ctrlenable[5 : 4] =
generator of test_assembly_ta1
ta1_tx_ctrlenable_ch0; // acr 2013-03-20; use only data from the
assign tx_ctrlenable[3 : 2] =
generator of test_assembly_ta1
ta1_tx_ctrlenable_ch1; // acr 2013-03-20; use only data from the
assign tx_ctrlenable[1 : 0] =
generator of test_assembly_ta1
ta1_tx_ctrlenable_ch0; // acr 2013-03-20; use only data from the
assign tx_64_datain[63 : 48]
from the generator of test_assembly_ta1
=
ta1_tx_16_datain_ch1; // acr 2013-03-20; use only data
assign tx_64_datain[47 : 32]
from the generator of test_assembly_ta1
=
ta1_tx_16_datain_ch0; // acr 2013-03-20; use only data
assign tx_64_datain[31 : 16]
from the generator of test_assembly_ta1
=
ta1_tx_16_datain_ch1; // acr 2013-03-20; use only data
assign tx_64_datain[15 : 0]
from the generator of test_assembly_ta1
=
ta1_tx_16_datain_ch0; // acr 2013-03-20; use only data
`else
assign tx_ctrlenable[7 : 6] =
ta2_tx_ctrlenable_ch1; // acr 2013-01-23;
assign tx_ctrlenable[5 : 4] =
ta2_tx_ctrlenable_ch0; // acr 2013-01-23;
assign tx_ctrlenable[3 : 2] =
ta1_tx_ctrlenable_ch1; // acr 2013-01-23;
assign tx_ctrlenable[1 : 0] =
ta1_tx_ctrlenable_ch0; // acr 2013-01-23;
assign tx_64_datain[63 : 48]
=
ta2_tx_16_datain_ch1; // acr 2013-01-24
assign tx_64_datain[47 : 32]
=
ta2_tx_16_datain_ch0; // acr 2013-01-24
assign tx_64_datain[31 : 16]
=
ta1_tx_16_datain_ch1; // acr 2013-01-24
assign tx_64_datain[15 : 0]
=
ta1_tx_16_datain_ch0; // acr 2013-01-24
`endif //`ifdef XCVR_DEBUG
//
XCVR XCVR_Inst
(
.cal_blk_clk
(cal_blk_clk),
// IN STD_LOGIC;
.gxb_powerdown
(gxb_powerdown),
// IN STD_LOGIC_VECTOR (0 DOWNTO 0);
.pll_inclk
(pll_ref_clk),
// IN STD_LOGIC; // TTC_clk x 2 (80.16MHz) pins: AD33(+)/AD34(-)
reference clock for the XCVR. generated by U39, pin 27(+)/26(+)
.pll_powerdown
.reconfig_clk
(pll_powerdown),
(cal_blk_clk),
// IN STD_LOGIC_VECTOR (0 DOWNTO 0);
// IN STD_LOGIC;
.reconfig_togxb
(reconfig_togxb),
.rx_analogreset
(rx_4_analogreset), // IN STD_LOGIC_VECTOR (3 DOWNTO 0);
.rx_datain
.rx_digitalreset
(rx_datain_lines), // IN STD_LOGIC_VECTOR (3 DOWNTO 0);
(rx_4_digitalreset), // IN STD_LOGIC_VECTOR (3 DOWNTO 0);
.rx_seriallpbken
.tx_ctrlenable
.tx_datain
// IN STD_LOGIC_VECTOR (3 DOWNTO 0);
(rx_seriallpbken), // IN STD_LOGIC_VECTOR (3 DOWNTO 0);
(tx_ctrlenable),
(tx_64_datain),
// IN STD_LOGIC_VECTOR (7 DOWNTO 0);
// IN STD_LOGIC_VECTOR (63 DOWNTO 0);
.tx_digitalreset
(tx_4_digitalreset), // IN STD_LOGIC_VECTOR (3 DOWNTO 0);
.pll_locked
(tx_pll_locked),
.reconfig_fromgxb
// OUT STD_LOGIC_VECTOR(0 DOWNTO 0); // era pll_locked
(reconfig_fromgxb), // OUT STD_LOGIC_VECTOR (16 DOWNTO 0);
.rx_clkout
(rx_4_clkout),
// OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
.rx_ctrldetect
(rx_4_ctrldetect), // OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
.rx_dataout
(rx_dataout),
.rx_disperr
(rx_disperr),
// OUT STD_LOGIC_VECTOR (63 DOWNTO 0);
// OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
//acr 2013-03-31 try the byte aligner operation in auto mode
(rx_enabyteord_sig), // IN STD_LOGIC_VECTOR (3 DOWNTO 0);
.rx_enabyteord
// acr 2011-03-01 User-Controlled Byte Ordering: after a rising edge on
the rx_enabyteord signal,
//
that matches the programmed
if the byte ordering block finds the first data byte
//
position of the byte-deserialized data,
byte ordering pattern in the MSByte
//
to push the byte ordering pattern in the LSByte
it inserts one programmed PAD pattern
//
the first data byte that matches the
position. If the byte ordering block finds
//
LSByte position of the byte-deserialized
programmed byte ordering pattern in the
//
ordered and does not insert any PAD byte.
data, it considers the data to be byte
//
asserts the rx_byteorderalignstatus signal.
In either case, the byte ordering block
.rx_byteorderalignstatus (rx_byteorderalignstatus_sig), // OUT STD_LOGIC_VECTOR (3
DOWNTO 0);
.rx_errdetect
(rx_errdetect),
// OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
.rx_freqlocked
(rx_freqlocked),
// OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
.rx_patterndetect
(rx_patterndetect), // OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
// acr 2011-03-01 in single width mode with Automatic Synchronization
State Machine: Asserted high for one
//
alignment pattern appears in the current word boundary
parallel clock cycle when the word
// acr 2013-03-21 This is an output status signal that the word aligner forwards to the FPGA
fabric to indicate that the
//
word alignment pattern programmed has been detected in the current word
boundary
.rx_pll_locked
(rx_pll_locked),
.rx_syncstatus
(rx_syncstatus),
// OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
// OUT STD_LOGIC_VECTOR (7 DOWNTO 0);
// acr 2013-03-21 "This is an output status signal that the word aligner
forwards to the FPGA fabric to indicate that synchronization has been achieved"
//
"Signal width is 2 for a channel width of 16-bits/20-bits"
.tx_clkout
(tx_4_clkout),
.tx_dataout
(tx_dataout_lines)
// OUT STD_LOGIC_VECTOR (3 DOWNTO 0);
// OUT STD_LOGIC_VECTOR (3 DOWNTO 0)// HSMB_GXB_TX_p
);
//
// acr 2012-03-27
//The rx_syncstatus and rx_patterndetect status signals have the same latency as the
//datapath and are forwarded to the FPGA fabric to indicate word aligner status. On
//receiving the first word alignment pattern after the assertion of the
//rx_enapatternalign signal, both the rx_syncstatus and rx_patterndetect signals
//are driven high for one parallel clock cycle synchronous to the most significant byte
//(MSByte) of the word alignment pattern. Any word alignment pattern received
//thereafter in the same word boundary causes only the rx_patterndetect signal to go
//high for one clock cycle.
//Any word alignment pattern received thereafter in a different word boundary causes
//the word aligner to re-align to the new word boundary only if there is a rising edge in
//the rx_enapatternalign signal (in the 8-bit word aligner) or if the
//rx_enapatternalign signal is held high (in 10-bit word aligner). The word aligner
//asserts the rx_syncstatus and rx_patterndetect signals for one parallel clock cycle
//whenever it re-aligns to the new word boundary.
//
// acr 2013-03-21 NOTE about the "byte ordering block":
// As soon as the byte ordering block sees the rising edge of the appropriate signal, it compares the LSByte
coming out of the byte
// deserializer with the byte ordering pattern. If they do not match, the byte ordering block inserts the pad
character that you enter
// in the "What is the byte ordering pad pattern?" option such that the byte ordering pattern is seen in the
LSByte position.
// Inserting this pad character enables the byte ordering block to restore the correct byte order.
//
// acr 2013-03-21 NOTE about the "What do you want the byte ordering to be based on?" field of the XCVR
setting panel
// This option allows you to trigger the byte ordering block on the rising edge of either the "rx_syncstatus"
signal or
// the user-controlled "rx_enabyteord" signal from the FPGA fabric.
//
// acr 2013-03-21 NOTE about the "What is the byte ordering pattern?"
// Basic single-width mode with:
// â– 16-bit FPGA fabric-transceiver interface:
// â– 8B/10B decoder
// â– Word aligner in automatic synchronization state machine mode
// Byte Ordering Pattern Length:
9 bits (1)
// Byte Ordering PAD Pattern Length: 9 bits
// (1) If a /Kx.y/ control code group is selected as the byte ordering pattern, the MSB of the 9-bit byte ordering
pattern
// must be 1'b1. If a /Dx.y/ data code group is selected as the byte ordering pattern, the MSB of the 9-bit byte
ordering
// pattern must be 1'b0. The least significant 8 bits must be the 8B/10B decoded version of the code group used
for byte ordering.
// In the GTKRO application the byte ordering block is triggere by the "rx_enabyteord" (which I generate from
the "rx_syncstatus" signal
// as a first approach)
//
//-- ACR 2011-12-11 IN OUR CASE ONLY OPERATION REQUIRED FROM THE DYNAMIC
RECONFIGURATION DEVICE IS OFFSET CANCELLATION
//-//--
Offset Cancellation Duration
When the device powers up, the busy signal remains low for the first reconfig_clk clock cycle.
//--
Offset cancellation control is only for the receiver channels.
//--
The ALTGX_RECONFIG instance takes:
//-Transmitter channels.
* 18500 reconfig_clk clock cycles per channel for Receiver only and Receiver and
//--
* 900 reconfig_clk clock cycles per channel for Transmitter only channels to determine if the
//--
under reconfiguration is a receiver channel or not.
channel
//-take effect.
The ALTGX_RECONFIG requires an additional 130,000 clock cycles for these values to
//-The ALTGX_RECONFIG instance takes approximately two reconfig_clk clock cycles per
channel for the unused logical channels.
reconfig reconfig_inst
(
.reconfig_clk
(cal_blk_clk),
.reconfig_fromgxb
.busy
.reconfig_togxb
);
// in
(reconfig_fromgxb), // in 17
(busy),
(reconfig_togxb)
// out
// out 4
// acr 2013-03-28 BEGIN instantiate a newer version of the XCVR reset manager
//
// acr 2013-03-31 BEGIN conditional definition of signals to the ALTGX reset controller
wire
rx_pll_locked_to_altgxreset; // acr 2013-03-31
wire
rx_freqlocked_to_altgxreset; // acr 2013-03-31
`ifdef TEST_ASSEMBLY_2_ENABLE
`ifdef TEST_ASSEMBLY_1_ENABLE
assign rx_pll_locked_to_altgxreset = &rx_pll_locked; // acr 2013-03-31 note: wire [3:0]
rx_pll_locked;
assign rx_freqlocked_to_altgxreset = &rx_freqlocked; // acr 2013-03-31 note: wire [3:0]
rx_freqlocked;
`else
assign rx_pll_locked_to_altgxreset = rx_pll_locked[3] & rx_pll_locked[2]; // acr 2013-03-31 note:
wire [3:0] rx_pll_locked;
assign rx_freqlocked_to_altgxreset = rx_freqlocked[3] & rx_freqlocked[2]; // acr 2013-03-31 note:
wire [3:0] rx_freqlocked;
`endif //`ifdef TEST_ASSEMBLY_1_ENABLE
`else
`ifdef TEST_ASSEMBLY_1_ENABLE
assign rx_pll_locked_to_altgxreset = rx_pll_locked[1] & rx_pll_locked[0]; // acr 2013-03-31 note:
wire [3:0] rx_pll_locked;
assign rx_freqlocked_to_altgxreset = rx_freqlocked[1] & rx_freqlocked[0]; // acr 2013-03-31 note:
wire [3:0] rx_freqlocked;
`else
assign rx_pll_locked_to_altgxreset = 1'b0; // acr 2013-03-31 note: wire [3:0] rx_pll_locked;
assign rx_freqlocked_to_altgxreset = 1'b0; // acr 2013-03-31 note: wire [3:0] rx_freqlocked;
`endif //`ifdef TEST_ASSEMBLY_1_ENABLE
`endif // `ifdef TEST_ASSEMBLY_2_ENABLE
// acr 2013-03-31 END conditional definition of signals to the ALTGX reset controller
//
ALTGXReset_XCVR4x ALTGXReset_Inst // acr 2013-03-28
(
.Reset_In
(~global_reset_n | ~dram_init_done), // in acr 2013-03-14 adding control on DDR2
calibration done
//acr 2014-02-11 .ExtraRxRst_from_switch (ResetfromS2),
// in
.ExtraRxRst_from_switch (ResetfromS2_shaped_40MHz), // in
.clk
(cal_blk_clk),
50MHz clk to generate proper timing for resets
.pll_locked
// in // acr 2011-02-28 watch! assumes
(tx_pll_locked),
// in // acr 2012-03-26
.rx_pll_locked
(rx_pll_locked_to_altgxreset),
& rx_pll_locked[2] & rx_pll_locked[3]), // in
.rx_freqlocked
.Busy
.pll_powerdown
.gxb_powerdown
.tx_digitalreset
.rx_analogreset
.rx_digitalreset
// in // acr 2013-01-29 (rx_pll_locked[0] & rx_pll_locked[1]
(rx_freqlocked_to_altgxreset),
// in // acr 2013-01-29 in
(busy),
// in
(pll_powerdown),
// out
(gxb_powerdown[0]),
(tx_digitalreset[0]),
(rx_analogreset[0]),
(rx_digitalreset[0])
// out
// out
// out
// out
);
//
// acr 2013-03-28 END instantiate a newer version of the XCVR reset manager
//
`endif // `ifdef XCVR_ENABLE