I propose to use the following components:

• SPFEIM100_G optical transceiver from Infineon (I ordered 30 of them [2007-01-29])
• a 100-300Mbits/s SERDES. In this frequency range I know of the SNLV1023A or SN65LV1224B and maybe much better and more flexible the FIN224AC from Fairchild (uSerDes)
• FPGA: LatticeECP2 as it is quite cheap (we need around 400!): e.g.:ECP2-12 in a BGA package (17mmx17mm).

The task-list for Yanyu is the following:

1. design a board with the optical transceivers equipped
2. assemble the board (if you can't assemble SMD components with small pitch we can do the manufacturing here at GSI [PCB+assembly])
3. test the communication between two boards with the FPGA
4. Evaluate the time resolution of an additional optical channel (without SERDES!). This time resolution has to be below 1ns sigma to be usable for the common stop signal. Most likely this measurement can only be done with a high-end oscilloscope and I propose to make it here in the EE department, as we have a 12GHz Oscilloscope with the necessary software to make a jitter analysis.
5. implement the MDC-TDC-readout in the FPGA.
6. develop a method which allows us to boot the FPGA after power-up always with the same code, which only is able to communicate with the TRBv2 Addon and downloads the full-featured FPGA-code and this code is then automatically used by the FPGA (reboot of the FPGA with new code!)
   There are many ways to do this, but one way has to be figured out and implemented. For example, the ECP2-family supports a "golden"-bootimage and a "Dual Boot Image Setup".
7. merge the TDC-readout-VHDL-code with the TRB-Net code from Ingo Frhlich
8. commission the whole system (TRBv2 -> TRBv2_Addon -> MDC-Driver-Card -> Motherboard)

Communication about different options to the project

Hi Yanyu,

yes, you are absolutely right! A modern FPGA will allow us to directly send the data with an included SERDES away. The problem is, that the PLLs in the FPGAs normally only will work down to 500MBit/s. As we want to try to transmit the data only via optical fibres which are affordable and small in size, I don't know any other solution than the "POF" (11€ per transceiver, cable: 40cents per m, no ferrules etc.). Unfortunately, this technology now only goes up to 150MBits/s. Therefore, a normal SERDES will not work.

Yesterday, I had the opportunity to talk to some engineers from Lattice and they promised to me to help me to try to implement a SERDES into a ECP2M-FPGA solely in a digital way (clock recovery and 10b/8b encoding). This would solve our problem.

If we are not successful with this scheme, then we have the fallback solution of using 3 times a POF transceiver, which amounts in 3 transmitters and 3 receivers:

• we can use 1 transmitter for sending the clock and one for the data
• the last transmitter can be used for the common-stop signal
• the receivers do the same thing for the other direction of communication.
• the last receiver can be used for the "common-or"

The disadvantage: 50% more POF-transceivers and 3 cables instead of 2.

Michael

new measurements with the optical transceiver:

Date: Mon, 12 Mar 2007 17:30:03 +0100 (CET) From: Michael Traxler <M.Traxler@gsi.de>

Hi,

from my measurements today I can conclude that the optical-receiver only works correctly if one doesn't transmit any net-DC-signal, so one has to assure that the "same" amount of '1' and '0' are sent, which is automatically done when you use a SERDES.

Whenever I tried to change the duty cycle of the square signal I used for testing to more than 70% (30%) the received signal "deteriorates".

So, either we come up with a very smart time-encoding protocol ontop of a square-wave (Herbert had an idea...) or we discard the idea of optical time-signal transport.

Any more ideas to encode the time-signal into a square-wave?

Michael

-- MichaelTraxler - 02 Feb 2007

3D drawing of the driver-card:

Hi,

here we have a preliminary 3D drawing of the driver-card with the necessary components.. (two more small BGAs are missing)

The actual size of the PCB is: 4.5 x 4.0 cm

• Driver-card:
  

• Driver-Card-real:
  

a Gbit/s-Transceiver for POF solution (polymer optical fiber)

http://hades-wiki.gsi.de/pub/DaqSlowControl/MdcAddonCooperation/GBit_POF_Transceiver_tcm278-76277.pdf

Yanyu 2007.03.16

-- MichaelTraxler - 19 May 2008

ECP2M20E Lattice FPGA

-- AttilioTarantola - 21 May 2008

Main goal: the vhdl design already implemented on the MDC-addonv1 will run (compiled and simulation in progress) in the ECP2M. In addition the VHDL-code with the TRB-Net-protocol, for data transmission will be used.

In a meeting with Vladimir P., I got it might be useful if the MDC Optical end-point could perform the following operation:

- calculate t1-t2 (time cut), which might be done without calibrated data.

- mapping the TDC channel and number with the corresponding wire information, which can be stored in the ECP2M RAM. For each dataword, the ECP2M might generate a second dataword containing the following "mapped information": SECTORS, MODULE, LAYER, CELL. In this way we could generate/prepare the data for the future tracking software.

SECTORS = 3 bits

MODULE = 3 bits

LAYER = 3 bits

CELL = 8 bits

We need to store in the RAM (17 bits x 8 channel x 12 TDCs) = 1632 bits.

The wire information stored in the RAM should be accessible and one should have the possibility to change these parameters.

For the configuration and the readout of 1 BUS the MDC-addonv1 uses 7 RAMs (RAMB16_S18_S18, 16384 bits each) This means 16384 bits x 7 RAMs = 114688 bits

Conclusion: the information we should store in each ECP2M is:

115 Kbits(readout and configuration for one MB) + 1.6 Kbits = 116.6 Kbits

Using the ECP2M20(embedded memory of 1200 Kbits), we shouldn't have problems concerning RAM space.

Soft Errors in ECP2M

-- AttilioTarantola - 03 Jun 2008

* soft_error.pdf: Soft Error Detection(SED) Usage guide