Re: ADC125, signal dist module, 2eSST tests

["Fernando J. Barbosa" <barbosa@jlab.org>]

Hi Gerard,

The VME spacing of 8 mm between modules is very wide by today's 
standards, given the low profiles of the SMT components. Good heat 
transfer, via forced convection, is accomplished by turbulent flow 
around the components and so most of the air in the ~8 mm gap doesn't 
contribute much to the cooling of the components. That is, the cross 
section of the air flow responsible for cooling is small and a small 
percentage of the total flow. Therefore, the use of mezzanine boards is 
a very good approach to increasing  packaging density while maintaining 
proper cooling of the components. Packages such as QFN provide great 
heat transfer efficiency to the board but are not available on your ADCs 
but increasing the mass connected to the chips will also help.

In any case, I can perform the thermal simulations for your layout once 
you have settled on the placement. All I need is the PCAD PCB file, 
power dissipation per component and type and layer metal content 
(#layers, percentage of metal, thickness, etc.) Just let me know when 
you have all these information.

Regards,
Fernando




Gerard Visser wrote:
> Hall D Electronics:
>
> Hi Chris,
>     I'll respond below --->
>
>     Gerard
>
> C. Cuevas wrote:
>> Gerard,
>>
>> Well it certainly looks like the circuitry will fit on the main board
>> and mezzanine, and it looks like the design is progressing.  I have a
>> few questions and list them below.
>>
>> 1.  Overflow bit -- is it omitted or no plans to use?
>
> No plans to use. And as you may note from the layout I have not much 
> free routing space or FPGA pins for it anyway. According to LT, the 
> ADC data output stays reliably saturated in overflow, so by omitting 
> the overflow bit and declaring code=0 and code=4096 an overflow we 
> sacrifice 0.049% of the dynamic range but simplify the board. This is 
> my plan.
>
>> 2.  Power supplies -- 3v from the bus directly to the ADCs or is this
>> regulated to 2.5 or filtered?
>
> The ADC's run from 3.0V, derived with a (polyphase) buck converter 
> from the VME 5V. Total ADC supply current is about 12 A at 3.0 V.
>
>> 3.  How much 2.5v current  will be needed and where will the 2.5v be
>> generated close to the loads?
>
> The 2.5V is used for all digital interfaces on the board, except for 
> the ADC outputs which run at 1.2V and the VME transceiver chip 
> connections which run at 3.3V. The latter will be connected directly 
> (with fuse of course) to VME64x 3.3V. The first two are derived from 
> (probably) VME64x 3.3V with buck converters. The details are still 
> being worked on.
>
>>
>> Comments/Thoughts:
>> Looks like you have plenty of notes for the sections that need to be
>> developed and I noticed that several of the components have not been
>> fully 'packaged' into gates yet, but once you have the pin assignments
>> it should be easy enough to add these gates to the FPGA symbol.  This
>> comment points to the FE readout/data processor and trigger handling
>> section.
>
> Yes, in general I have a dummy part on the layout, and make 
> connections manually on the layout to optimize the routing, and then 
> back-annotate it to the schematic. This worked well at the FE FPGA, I 
> am now working on this at the processor and VME FPGA's.
>
>>
>> I know you have thought about power dissipation and will the mezzanine
>> create a restricted air flow area above the circuitry on the main
>> board?  
>
> This is certainly a concern that I have been keeping front and center. 
> Mainly, it is addressed by ~equal spacing of mezzanine board to main 
> board (8 mm) and to next slot (9.12 mm), and by ensuring that wide 
> open "air channels" are maintained in the layout wherein only thin 
> components (generally <1.4mm) are used). Also, the ADC's are back 
> about as far from the front panel as I can have them, where they 
> should sit in the prime airflow region. (Ok, I admit, they also have 
> to be this far back to leave room for the analog signal processing, 
> but it fits together nicely this way.)
>
> The Spartan Fpgas are separated nicely and the 18 ADCs on the
>> main board and 18 on the mezzanine will be generating a good deal of
>> heat.  
>
> Yep.
>
> Any plans for heat-sinking fins?  I might be looking at this
>> incorrectly, but all the ADCs (main an mezzanine) will be lined up, so
>> the  mezzanine could be used (mechanically) to support heat extraction
>> components. (Foam,fins, etc)
>
> It's possible... I don't have any tools here to simulate the heat 
> transfer, nor any particular expertise with such tools. My best guess, 
> and I really do trust it, is that we will be better served by keeping 
> the airflow unobstructed. As you know, the overwhelming best path for 
> getting heat out of the ADC package is through the ground pad and into 
> the board ground planes. The boards have 3 independent ground planes 
> each 1 oz copper, I believe it should spread the heat pretty well. If 
> it does succeed in becoming a uniform heat load over a large portion 
> of the board, it should be transferred to the air without too much 
> temperature rise.
>
>>
>> P0:
>> We have not altered the net names on the FADC250 and the pair
>> assignments are as follows:
>> DP23  LVDS        Trig0      Input          (Trig_In on FADC250)
>> DP24  LVDS        Trig1      Input          (SYNC on FADC250)
>> DP25  LVPECL    CLK      Input
>> DP26  LVDS        Trig2       Input         (Spare_In on FADC250)
>> DP27  LVDS        TokenIN
>> DP28  LVDS        TokenOUT
>> DP29  LVDS        BUSY     Output      (Status_Out on FADC250)
>> DP30  LVDS        TrigOut
>
> I'll double check, I think I am complying with the relevant ones.
>
>>
>> I will send you the latest schematic for the SD card.  Keep in mind that
>> the backplane connectors for the switch card are different and that the
>> net names will end up on different pins.  Its all part of the VXS
>> standard and we will be checking this twice before the CTP and SD boards
>> are sent for manufacturing.
>>
>> I know you have generated a schedule for the FADC125 and I do not have
>> to tell you that you have large amount of work to complete before you
>> are ready to send the boards to the assembly house. 
>
> Yep.
>
>  Within a week or
>> two, all eight of the FADC250 boards will have passed through the
>> LabView test stand, and we will begin trigger rate and data readout
>> testing with the modules in a full 20 slot VXS crate.  I agree with you
>> about accelerating the effort for 2eVME readout, because it will be
>> close to August until we have the full SD and CTP prototype assemblies,
>> and we can discuss this at our regular 'trigger' meeting.  As you get
>> closer to completing your VME register map, let me know because it may
>> be useful for us to develop a  low level LabView test program for the
>> FADC125 for future testing plans.
>
> Certainly. The DAQ gang will also need this info to develop a driver, 
> I am expecting. I don't have any specific info yet, I know basically 
> what I want to do with this but no implementation details yet. I have 
> to concentrate on the schematic and layout, obviously, or this will 
> never get done...
>
>>
>> Regards,
>> Chris
>> ~~~~~~~~~~~~~~~~~~~~~~~~
>> Gerard Visser wrote:
>>> Hi Chris,
>>> -->
>>>
>>>     Gerard
>>>
>>> C. Cuevas wrote:
>>>> Hi Gerard,
>>>>
>>>> The schematics for the SD board are close to complete and I will send
>>>> you the latest file.  The board layout activities will start within a
>>>> week or so, due to personnel on vacation etc.
>>>>
>>>> I talked with Ed about the 2eSST and it has not been exercised on the
>>>> FADC250 nor F1TDC for that matter.  All of the critical control 
>>>> lines to
>>>> the transceivers (22501's) have been connected to the Altera Fpga, and
>>>> the devices are operated in transparent mode for normal VME64
>>>> transfers.
>>> Yes this is my plan as well. I think I mentioned before, the Tsi148
>>> also operates the 22501's in transparent mode for all transfers, so
>>> this is clearly feasible. I plan to do so as well, i.e, the clock pins
>>> are just tied.
>>>
>>> I believe at one point during the F1TDC development Ed had
>>>> implemented the 2eVME transfer firmware, but it was not a pressing
>>>> requirement and the resources in the Fpga were needed for other
>>>> features.
>>> Ok - but for the ADC125 I think it is going to have to be considered a
>>> priority because of the larger contribution to the experiment's data
>>> volume. My initial plan would be to implement single A32:D32 transfers
>>> and 2eSST A32:D64 block transfers. Other stuff in between can be
>>> implemented at a later date. I'm sure that the real system will use
>>> the Tsi148 or some sucessor as master...
>>>
>>> I believe we only have a few single board computers that will
>>>> manage the 2eSST protocol, and the testing of this readout mode is not
>>>> the highest priority at this time.  So the hooks are correct and
>>>> implemented on the hardware
>>> Not for F1TDC-v1 right, I mean I think RETRY is not connected there,
>>> for instance. Unless I do not have the correct final schematic.
>>>
>>> , but the firmware for the 2eSST and 2eVME
>>>> are only in the development stage.  We have the nice Vmetro 
>>>> Vanguard VME
>>>> analyzer so we can fully test the FADC250 (and any other board) to
>>>> verify compliance with those transfer modes.
>>> Does this have a "protocol checker" or something like that? I have
>>> also a Vanguard but it is just like a logic analyzer doesn't verify
>>> anything automatically...
>>>
>>>> All P0 I/O have been tested thoroughly and we now have a very nice
>>>> LabView program that completely tests all sections of the FADC250
>>>> boards.  This will be useful for any required troubleshooting.
>>> This sounds great - when my preliminary testing is complete we should
>>> talk about the possibilities, maybe your guys can make an ADC125 
>>> version?
>>>
>>>> I have a few comments/questions on your FADC125 design and I will send
>>>> those soon.
>>> Sounds good, it will be helpful to discuss details, make sure they are
>>> right and that you will get what you want.
>>>
>>> Is the goal to complete the layout of the FADC125 by end
>>>> of FY08?
>>> Not tied to FY in particular, the contract is running past that (I
>>> think) - but the goal is certainly to get the boards fabricated and
>>> assembled in early August. There is a lot of layout work still to be
>>> completed (as you can see), but I will try my best on this.
>>>
>>>> Talk to you soon,
>>>> Chris
>>
begin:vcard
fn:Fernando J. Barbosa
n:Barbosa;Fernando J.
org:Jefferson Lab
adr:Suite #10, 12B3;;12000 Jefferson Ave.;Newport News;VA;23606;USA
tel;work:757-269-7433
version:2.1
end:vcard