Minutes of CALICE Electronics Meeting, RAL, 06/08/03
====================================================
Present: Adam Baird, Paul Dauncey, Dave Mercer, Matt Warren, Osman Zorba

Minutes: Paul


Matters arising: Photos and schematics of the NIM<-->LVDS module were sent
 to Paul following the last meeting and assembly of a unit has started. Paul
 was asked not to put the schematics on the web but he will distribute them
 by email. Imperial should be able to make a back-of-crate card to connect 
 a SCSI 68-way connectors to the backplane J2.
 
 Dave has received the VME FPGA code from Rob but has not yet had time to
 look into it. His meeting with Rob following the last meeting was very
 productive.

  
Layout status: The frontend module design and layout is now complete and
 handed to the Drawing Office. However, the overall board layout was not
 completed before Chris Day went on holiday, despite this having been stated
 as urgent in the last meeting. Therefore, we have to assume another month
 delay (minimum) to the schedule. The only way it would now be possible to
 make the Mar 2004 deadline for a complete and tested system would be if no 
 redesign and layout are needed, so we gain back those three months. Even then,
 the total prototype and production test period combined is now five months 
 (compared to six months originally for the prototype alone). If some redesign
 is needed, it might be possible to do this in parallel with the prototype 
 tests; this would require identifying all problems with the physical board
 early. Most connectivity errors would be found with the initial JTAG tests.
 Remaining items which might cause a redesign would be insufficient logic 
 in the FPGAs, too much ADC noise and missing VME functionality (the parts 
 which are not needed by CMS and hence not checked by them; specifically DMA 
 and interrupts). The FPGA size is thought to be unlikely to be a problem.
 There will be some early estimate of the ADC noise using Chipscope, but
 without the final timing, it is not clear e.g. the switching noise will be
 known. The VME tests could be done on the existing CMS FEDs, if Paul is able
 to get time with them. This will require him to get the VME interface details
 from Saeed. There are 20 more FEDs in production, although the timescale for
 them becoming available is not known.
 [Note added after the meeting: the schedule on the electronics web page has
 been updated in line with the above.]
 
 The current schedule of the French development was not known at the meeting.
 [Note added after the meeting: Paul has been told that the French groups are
 holding to the schedule and are still aiming for a complete system test with
 cosmics in Apr 2004, with a beam test a few months later.]


BE and trigger status: Matt and Dave have divided the BE work differently;
 Matt will now look at the trigger and VME interface, while Dave concentrates
 on the BE-FE side.

 Adam announced that the 4 MByte memories (two per BE FPGA) which were going
 to be used were no longer available. The default of moving back to the CMS
 memories (two 1 MByte memories, a factor 4 smaller) is not possible as this
 would not store enough events per spill. This is an urgent issue which needs
 to be resolved asap.
 
 Matt had been thinking about getting the trigger data out. The CMS BE design
 has a small header for each event which is stored in the ~100kBytes of FPGA
 RAM, i.e. not the external memory. One possibility might be to modify the
 code which makes the header to include the trigger data. Two potential
 problems are the size of the trigger data (as up to 2000 events will need
 to be buffered) and how the header would be made on the non-trigger boards
 where the same FPGA code is running.

 The issue of running the trigger synchronous or asynchronous was raised.
 If synchronised, it would need to be to a 320MHz clock to minimise
 the jitter; this was thought to be the fastest possible clock with the
 speed grade we are using. There is an issue with the FE FPGA having to
 generate a second 320MHz clock to delay the trigger. These two 320MHz
 clocks will have some (unknown initially) phase offset and so there is a
 possibility that the FE clock will sample just on the trigger rising edge.
 To avoid this, the phase of the trigger relative to the common 40MHz clock
 needs to be read out; specifically a 3-bit value saying how long after the
 last 40MHz rising edge was the 320MHz rising edge with the trigger. Getting
 this information from both the trigger section and the FE will allow any
 jitter from the rising edge to be detected.

 The jitter due to unstable skews in the trigger fanout was also discussed.
 It was thought that using the BE FPGA for the trigger fanout could result
 in more jitter than using dedicated components, e.g. on a back-of-crate
 card.

 Matt showed some slides of his plans and timescale; he is free to work on
 CALICE in Aug and Oct, with Sep for Atlas; this fits in well with DaveM's
 holiday plans also.


FE status: Osman showed some slides with simulations of the trigger delay
 generator and the DAC data loading. His design for the DAC reloads the
 data in a continuous loop so it is continually being clocked. It is not
 clear if this might introduce more noise than loading it once and then
 stopping the clock. The former method would, in principle, allow different
 values to be loaded in a sequence, giving e.g. a sine wave. However, when
 the board can be configured and read with software, then this can be done
 between triggers, so it would only be used in the test period. The effort
 of implementing a data sequence was thought too large at present to be
 worth doing.

 The trigger delay generator has a coarse delay in counts of a 320MHz clock
 (~3ns) and also a fine delay using the DCM to phase shift a copy of the
 320MHz clock. This is in principle accurate to of order 3ns/250 ~ 10ps.

 This raises a related issue of having a configure and run mode for the
 board. Configure mode would allow the configuration data to be modified
 by software and would not allow triggers. Run mode would allow triggers
 but disable all configuration updates except the "Move to configure mode"
 command. Implementing such a switch would prevent the FE from having to
 be continuously able to respond to both configuration commands and triggers
 simultaneously. 
 
 Osman confirmed the number of multiplex channels, i.e. the number of
 shift register clock and ADC read sequences, was software configurable.
 It will be 18 for the ECAL but may be different for the AHCAL.

 He is close to the schedule he showed at the last meeting, with about
 one week slip, but this is not significant given the slip due to the
 drawing office delay.


Board features: Adam showed some figures of the board link array. This will
 be set up using a large jumper to go into one of two positions, depending
 on whether the FE is controlling one 12-VFE chip PCB on the bottom SCSI
 connector or two 6-VFE chip PCBs on the top and bottom connectors.

 For the 12-VFE option, only one of the two DACs is used and all 12 channels
 see the same DAC value. However, for the two 6-VFEs option, each DAC feeds
 to 6 of the channels. Hence, unfortunately it is necessary for the software
 to know the cable configuration to know which DAC to set for a given channel.
 This can be detected by reading the link array detection pins.

 If we use the 500 or 250 size FE FPGAs, then some of the pins to the
 link array will not be present. This affects the DHCAL option only; there
 would be 2 signals per connector which could not be used in this case.

 The exact VFE interface is still not fully defined. It is not clear if there
 will be a shift register output signal to be detected by the FE and, if there
 is, how many will be sent per cable. Also, there may be a constant bit
 pattern, different for each type of VFE board, put onto the unused cable
 lines which would then allow the FE to know which boards are at the other end
 of the cable. However, the exact number of bits and position on the cable of
 this coded number is not fixed.

 Hence the FE has to be prepared to deal with several potential signals in
 addition to those being coded for:
 o) Read the link array detector pins
 o) Read the VFE board ID signals
 o) Read the shift register output signal(s)
 The first two are constant for a given set-up and so should be read out as
 configuration data. The last is for each event and so should be read out with
 the event data.


AOB: Adam will order 10 SCSI cables, 3m long. 
 
 
Next Meeting: This was not arranged and will be organised by email.