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 Fröhlich
  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.


new measurements with the optical transceiver:

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


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?


-- MichaelTraxler - 02 Feb 2007

3D drawing of the driver-card:


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)


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.

Chip's temperatures

-- AttilioTarantola and Yanyu - 23 May 2008

In the attached document we record the temperature of the chips. The test's conditions are described in the document.

Level adapters: U1, U2, U3

-- AttilioTarantola and Yanyu - 23 May 2008

Introduction: the voltage translators U1, U2, U3 translate 5V<->3.3V. The stay in between the Lattice and the CLPD on the MB.

In the picture:

- yellow signal: clk (50 MHz) produced in the lattice. Input for U2 (pin 1), 2.6V.

- green signal: output for U2(pin 20), 4.2V

The time difference between the two signals is 3.1 ns. Enlarging the picture one can see the ground line stays 1V below the signal's minima (1,2)

* U2 I/O:

In the following pictures:

- yellow DRA: clk (50 MHz) produced in the lattice. Input for U3 (pin 9).

- green signal: output for U3 (pin 20).

* U3 I/O :

The time difference between the two signals is 1.8 ns

* U3 I/O:

Obs: we didn't observe strange behaviors of U1,U2,U3.

They are always pretty warm and the temperature changes as described in the previous document (it depends of the I/O in use). Even with fast signals (clk 50 MHz) the output is present and delayed by few ns.

In the real case the fastest signal which will pass through the level adapter will be DST (data strobe 1-10 MHz).

Topic attachments
I Attachment Action Size Date Who Comment
chip_temperature.pdfpdf chip_temperature.pdf manage 35.1 K 23 May 2008 - 20:32 AttilioTarantola chip temperature
print_000.bmpbmp print_000.bmp manage 2304.1 K 23 May 2008 - 20:45 AttilioTarantola level adapter I/O
print_001.bmpbmp print_001.bmp manage 2304.1 K 23 May 2008 - 20:57 AttilioTarantola U3 I/O
print_002.bmpbmp print_002.bmp manage 2304.1 K 23 May 2008 - 20:58 AttilioTarantola U3 I/O
Edit | Attach | Print version | History: r6 | r4 < r3 < r2 < r1 | Backlinks | View wiki text | Edit WikiText | More topic actions...
Topic revision: r3 - 23 May 2008, AttilioTarantola
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Hades Wiki? Send feedback
Imprint (in German)
Privacy Policy (in German)