Difference: MdcAddonCooperation (1 vs. 17)

Revision 17
27 Oct 2009 - Main.JanMichel
Line: 1 to 1
Changed:
<
<
META TOPICPARENT name="DaqUpgradeMDCOverview"
>
>
META TOPICPARENT name="MDCDevelopmentAndTesting"
 

MDC-Upgrade: Cooperation with Yanyu Wang


Revision 16
04 Aug 2009 - Main.AttilioTarantola
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 108 to 108
 

Conclusion: the LDO, which Yanyu is looking for, might drop down to 4.85V. In this case the MB(TDC+CPLD) will not be affected.
Added:
>
>
-- AttilioTarantola - 04 Aug 2009 Jan and me: additional current measurement. Setup: 1 long MB, 2 DB stack, connected to 10 cm cable to a power distributor board (v1 bridged). We read the current on the voltages power suppllies:
 
Added:
>
>
The voltages measured on the OEPB(input connector): 5.59V, 3.66V, 1.93V, +3.130V, -3.190V
 
Added:
>
>
OEPB(oputput LDO): 1.198V,3.342V, 1,000V, 5.007V,
 
Added:
>
>
On MB(TDC side): -3.17V,+3.10V
 
Added:
>
>
Long MB:
 
Added:
>
>
Th *Nr.dataword I(+5V) I(3.5V) I(1.5V) I(3.0V) I(-3.0V) comment
before init - 144 176 468 560 582  
x"00" - 1440 176 472 568 580   LDO limit to 4.45V
x"05" - 1440 @ 4.45V 176 472 568 580   LDO limits reached, voltage dropping with time and temperature
x"10" 100-120 1440 176 472 568 580   LDO limit to 4.45V
x"20" - 668 176 472 568 558  
x"70" ~10 550 176 472 568 580  
 
Added:
>
>
Short MB:

Th *Nr.dataword I(+5V) I(3.5V) I(1.5V) I(3.0V) I(-3.0V) comment
x"00" - 1255 175 384 392 391  
x"10" - 980 175 394 392 391  
x"20" - 460 175 394 392 391  
x"30" - 385 175 394 392 391  
x"40" - 385 176 396 378 389  
 

META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
META FILEATTACHMENT attr="" comment="Driver-card" date="1174015228" name="driver-card1.jpg" path="D:\2007GSI\driver-card1.jpg" size="82291" user="YanyuWang" version="1.1"
Revision 15
19 May 2008 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 45 to 45
  In total we need around 400 new driver cards (with FPGA). The following picture illustrates the project. Each TRBv2-MDC-AddonV2 will have 32 optical transceivers as this is the maximum number of motherbaords for one MDC sector.
Changed:
<
<
Optical Transmission

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.

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.
>
>
2008-05-19 It turned out in October 2007, that it is not possible to transmit a good timing signal via the cheap optical trasceivers.
 
Changed:
<
<
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

  • Driver-Card-real:
    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
>
>
Optical Transmission
 
Changed:
<
<

ECP2M20E Lattice FPGA

>
>
More details about the project progess can be found here.
 

-- AttilioTarantola - 16 May 2008
Revision 14
16 May 2008 - Main.AttilioTarantola
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 146 to 146
 

http://hades-wiki.gsi.de/pub/DaqSlowControl/MdcAddonCooperation/GBit_POF_Transceiver_tcm278-76277.pdf
Deleted:
<
<
  Yanyu 2007.03.16
Added:
>
>

ECP2M20E Lattice FPGA

-- AttilioTarantola - 16 May 2008
 

MB and DC Current measurement:

-- AttilioTarantola - 22 Apr 2008
Line: 191 to 194
 
short 10 (all DBs) 250mA 370mA 67 45
short 60 (all DBs) 250mA 250mA not enabled 1
Changed:
<
<
Observations:..
>
>

+5Volts study:

-- AttilioTarantola - 16 May 2008

14 May 2008 Yanyu and me tried to see the working mode of one short MB changing the +5V. The +5V(normal operating voltage for one short MB) is needed by the 8 TDCs, the CPLD and 2 transceivers. The results are:

* Operating voltage (5V-4.7V): the readout is not affected by the voltage drop. This means we were able to get normal data (60 datawords per event) and calibration data (all channels calibrated). The MB worked as expected:no changes in DST (data strobe), AOD(address/data) and RDY(token back to Addon) signals.

* Operating voltage (4.4V): the event size for normal data does not change (60 datawords per event) but the data is always 0 and the calibration still is working fine (all channels calibrated). (Speaking with Joern, he suggested this behavior is due to the fact that the CMS does not reach the TDCs. At this operating voltage the TDCs should work without any problem and this we see in the calibration events where the common stop is not needed by TDCs). No changes in DST(data strobe), AOD(address/data) and RDY(token back to Addon) signals.

Conclusion: the LDO, which Yanyu is looking for, might drop down to 4.85V. In this case the MB(TDC+CPLD) will not be affected.

 

META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
Revision 13
22 Apr 2008 - Main.AttilioTarantola
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 149 to 149
 

Yanyu 2007.03.16
Added:
>
>

MB and DC Current measurement:

-- AttilioTarantola - 22 Apr 2008

Today Yanyu and me measured the MB+DC currents. We measured the following currents for long and short MB with all threshold fixed to 10. The calibration trigger was enabled such that we had one normal trigger and one calibration trigger. The Driver card were plugged onto the MB(as in normal operation): this means the TDCs, the CPLD and the 2 transceivers have the same common voltage +5VD.

Motherboard Voltage Current(readout stopped) Current(readout running)
short +1V(green) 150 mA 160 mA
short -3.3V(yellow) -360 mA -360 mA
short +3.3V(orange) 360 mA 360 mA
short +5V(red) 440 mA 850 mA
long +1V(green) 220 mA 230 mA
long -3.3V(yellow) -520 mA -520 mA
long +3.3V(orange) 510 mA 510 mA
long +5V(red) 540 mA 700 mA

Here the same measurement changing thresholds:

Motherboard Threshold Dataword number(calibration) Dataword number(normal trigger-noise) Current relative +5V
short 60 (all DBs) 67 1 500mA
short 10 (all DBs) 67 52 850mA
long 10 (all DBs) 577 50 970mA
long 60 (all DBs) not enabled 2 970mA
long 10 (all DBs) not enabled 60 1,03A
long 60 (all DBs) not enabled 2 650mA
long 10 (all DBs) 530 60 1,03A

We powered the MB(+5V,+3V,-3V,+1V) and the driver card (+5V) individually. Here the current relative +5V for the DC:

Motherboard Threshold Current for DC(+5V)(readout stopped) Current for DC(+5V)(readout running) Dataword number(calibration) Dataword number(normal trigger-noise)
short 10 (all DBs) 250mA 370mA 67 40
short 60 (all DBs)   260mA not enabled 2

Here the current relative +5V for needed by the TDCs+CPLD:

Motherboard Threshold Current for TDCs(+5V)(readout stopped) Current for TDCs(+5V)(readout running) Dataword number(calibration) Dataword number(normal trigger-noise)
short 10 (all DBs) 250mA 370mA 67 45
short 60 (all DBs) 250mA 250mA not enabled 1

Observations:..
 
META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
META FILEATTACHMENT attr="" comment="Driver-card" date="1174015228" name="driver-card1.jpg" path="D:\2007GSI\driver-card1.jpg" size="82291" user="YanyuWang" version="1.1"
META FILEATTACHMENT attr="" comment="Driver-Card-real" date="1174034095" name="driver-card-real1.jpg" path="D:\2007GSI\driver-card-real1.jpg" size="67035" user="YanyuWang" version="1.1"
Revision 12
25 Jul 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 124 to 124
 

-- MichaelTraxler - 02 Feb 2007
Changed:
<
<

Imagination picture for Driver-Card:

>
>

3D drawing of the driver-card:

 

Hi,
Changed:
<
<
I draw a imagination picture for Driver-Card it includes those necessary components I think.
>
>
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
Revision 11
16 Mar 2007 - Main.YanyuWang
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 134 to 134
  Driver-card
Added:
>
>
  • Driver-Card-real:
    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

META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
META FILEATTACHMENT attr="" comment="Driver-card" date="1174015228" name="driver-card1.jpg" path="D:\2007GSI\driver-card1.jpg" size="82291" user="YanyuWang" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="" comment="Driver-Card-real" date="1174034095" name="driver-card-real1.jpg" path="D:\2007GSI\driver-card-real1.jpg" size="67035" user="YanyuWang" version="1.1"
META FILEATTACHMENT attr="" comment="GBit_POF_Transceiver_tcm278-76277.pdf" date="1174037510" name="GBit_POF_Transceiver_tcm278-76277.pdf" path="D:\2007GSI\coopration\pof\GBit_POF_Transceiver_tcm278-76277.pdf" size="137728" user="YanyuWang" version="1.1"
Revision 10
16 Mar 2007 - Main.YanyuWang
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 75 to 75
  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
Changed:
<
<
"POF" (11€ per transceiver, cable: 40cents per m, no ferrules etc.).
>
>
"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.
Line: 124 to 124
 

-- MichaelTraxler - 02 Feb 2007
Added:
>
>

Imagination picture for Driver-Card:

Hi,

I draw a imagination picture for Driver-Card it includes those necessary components I think.

  • Driver-card:
    Driver-card

Yanyu 2007.03.16
 
META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
Added:
>
>
META FILEATTACHMENT attr="" comment="Driver-card" date="1174015228" name="driver-card1.jpg" path="D:\2007GSI\driver-card1.jpg" size="82291" user="YanyuWang" version="1.1"
Revision 9
14 Mar 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 52 to 52
 

  • 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)
Changed:
<
<
  • FPGA: LatticeECP2 as it is quite cheap (we need around 400!): e.g.:ECP2-12 in a BGA package.
>
>
  • 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:

Line: 96 to 96
 

Michael
Added:
>
>

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
Revision 8
15 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 66 to 66
 
  1. commission the whole system (TRBv2 -> TRBv2_Addon -> MDC-Driver-Card -> Motherboard)
Added:
>
>

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
  -- MichaelTraxler - 02 Feb 2007

META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
Revision 7
09 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Line: 51 to 51
  I propose to use the following components:

  • SPFEIM100_G optical transceiver from Infineon (I ordered 30 of them [2007-01-29])
Changed:
<
<
  • a 100-300Mbits/s SERDES. The only one I know of in this frequency range is the SNLV1023A or SN65LV1224B.
>
>
  • 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.

The task-list for Yanyu is the following:

Revision 6
05 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang

Added:
>
>


 

Introduction

In the HADES-DAQ-Upgrade project the MDC-Upgrade is an essential part. The expected data rates for heavy ion systems can not be handled any more
Changed:
<
<
with the original MDC-DAQ-system.
>
>
with the original MDC-DAQ.
 
Changed:
<
<
A description of the concept of the DAQ-upgrade and new DAQ-system can
>
>
A description of the concept of the DAQ-upgrade and the new DAQ-system can
  be found at:

http://hades-wiki.gsi.de/cgi-bin/view/DaqSlowControl/DaqUpgradeOverview
Line: 33 to 36
 
  • crosstalk and "ringing" of the MDC-FEE due to copper cables squeezed between motherboards
  • heat disspation
  • missing possibility to reprogramm the motherboard-CPLD
Added:
>
>
  • hassle with the chains of motherboards
 

Project definition

Therefore, the project was started to evaluate and build a prototype board for the TRBv2 -> MDC-Driver-Card -> Motherboard communication.
Changed:
<
<
The idea is to use only optical transmission for the data and the clock. The data should be tranmitted via the optical transceivers and SERDES bidirectionally. Also the common or-signal can be transported via the data-stream (with high priority which is forseen in the TRB-Net protocol). Only the "Common-Stop" signal needs a good time resolution, so a dedicated optical transmitter has to be put on the driver-card and a receiver on the TRBv2-MDC-Addon_v2. In total we need around 400 new driver cards (with FPGA)
>
>
The idea is to use only optical transmission for the data and the clock (only point-to-point connections). The data should be tranmitted via the optical transceivers and SERDES bidirectionally. Also the common or-signal can be transported via the data-stream (with high priority which is forseen in the TRB-Net protocol). Only the "Common-Stop" signal needs a good time resolution, so a dedicated optical transmitter has to be put on the driver-card and a receiver on the TRBv2-MDC-Addon_v2. In total we need around 400 new driver cards (with FPGA). The following picture illustrates the project. Each TRBv2-MDC-AddonV2 will have 32 optical transceivers as this is the maximum number of motherbaords for one MDC sector.

Optical Transmission
 

I propose to use the following components:
Line: 46 to 54
 
  • a 100-300Mbits/s SERDES. The only one I know of in this frequency range is the SNLV1023A or SN65LV1224B.
  • FPGA: LatticeECP2 as it is quite cheap (we need around 400!): e.g.:ECP2-12 in a BGA package.
Changed:
<
<
The task-list for Yanyu is the following:
>
>

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])
Line: 60 to 68
 

-- MichaelTraxler - 02 Feb 2007
Added:
>
>
META FILEATTACHMENT attr="" comment="Optical Transmission" date="1170711023" name="Optical_Transmission.jpg" path="Optical_Transmission.jpg" size="29699" user="MichaelTraxler" version="1.1"
Revision 5
05 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang


Line: 37 to 37
 

Project definition

Therefore, the project was started to evaluate and build a prototype board for the TRBv2 -> MDC-Driver-Card -> Motherboard communication.
Changed:
<
<
The idea is to use only optical transmission for the data and the clock.
>
>
The idea is to use only optical transmission for the data and the clock. The data should be tranmitted via the optical transceivers and SERDES bidirectionally. Also the common or-signal can be transported via the data-stream (with high priority which is forseen in the TRB-Net protocol). Only the "Common-Stop" signal needs a good time resolution, so a dedicated optical transmitter has to be put on the driver-card and a receiver on the TRBv2-MDC-Addon_v2.
  In total we need around 400 new driver cards (with FPGA)

I propose to use the following components:
Line: 48 to 48
 

The task-list for Yanyu is the following:
Changed:
<
<
  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)
>
>
  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)
 

-- MichaelTraxler - 02 Feb 2007
Revision 4
05 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang


Line: 38 to 38
 

Therefore, the project was started to evaluate and build a prototype board for the TRBv2 -> MDC-Driver-Card -> Motherboard communication. The idea is to use only optical transmission for the data and the clock.
Added:
>
>
In total we need around 400 new driver cards (with FPGA)
 

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. The only one I know of in this frequency range is the SNLV1023A or SN65LV1224B.
Changed:
<
<
>
>
  • FPGA: LatticeECP2 as it is quite cheap (we need around 400!): e.g.:ECP2-12 in a BGA package.
 

The task-list for Yanyu is the following:
Line: 51 to 52
 
  1. ) assemble the board (if you can't assemble SMD components with small pitch we can do the manufacturing here at GSI [PCB+assembly])
  2. ) test the communication between two boards with the FPGA
  3. ) 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.
Changed:
<
<
  1. )
>
>
  1. ) implement the MDC-TDC-readout in the FPGA.
  2. ) 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".
  3. ) merge the TDC-readout-VHDL-code with the TRB-Net code from Ingo Fröhlich
  4. ) commission the whole system (TRBv2 -> TRBv2_Addon -> MDC-Driver-Card -> Motherboard)
 

-- MichaelTraxler - 02 Feb 2007
Revision 3
05 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"

MDC-Upgrade: Cooperation with Yanyu Wang


Added:
>
>

Introduction

  In the HADES-DAQ-Upgrade project the MDC-Upgrade is an essential part. The expected data rates for heavy ion systems can not be handled any more with the original MDC-DAQ-system.
Line: 32 to 34
 
  • heat disspation
  • missing possibility to reprogramm the motherboard-CPLD
Added:
>
>

Project definition

  Therefore, the project was started to evaluate and build a prototype board for the TRBv2 -> MDC-Driver-Card -> Motherboard communication. The idea is to use only optical transmission for the data and the clock.
Added:
>
>
I propose to use the following components:
 
Changed:
<
<
>
>
  • SPFEIM100_G optical transceiver from Infineon (I ordered 30 of them [2007-01-29])
  • a 100-300Mbits/s SERDES. The only one I know of in this frequency range is the SNLV1023A or SN65LV1224B.

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. )
 

-- MichaelTraxler - 02 Feb 2007
Revision 2
05 Feb 2007 - Main.MichaelTraxler
Line: 1 to 1
 
META TOPICPARENT name="DaqUpgradeMDCOverview"
Changed:
<
<

MDC-Upgrade: Cooperation with Yan Yu


>
>

MDC-Upgrade: Cooperation with Yanyu Wang


 

In the HADES-DAQ-Upgrade project the MDC-Upgrade is an essential part. The expected data rates for heavy ion systems can not be handled any more
Line: 28 to 28
 

As this board is just using RS484 drivers for the communication the known problems will stay:
Changed:
<
<
- crosstalk and "ringing" of the MDC-FEE due to copper cables squeezed on the
>
>
  • crosstalk and "ringing" of the MDC-FEE due to copper cables squeezed between motherboards
  • heat disspation
  • missing possibility to reprogramm the motherboard-CPLD

Therefore, the project was started to evaluate and build a prototype board for the TRBv2 -> MDC-Driver-Card -> Motherboard communication. The idea is to use only optical transmission for the data and the clock.
 

 
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)