The CCC is a mezzanine card designed and manufactured by the University of Mainz, which is hosted on the Zedboard. It interfaces subdetectors via 3 HDMI connectors. Based on the busy states of the subdetectors, spill signal and configuration, the CCC controls the acquisition by sending synchronous commands to all subdetectors (start and stop of the acquisition)

CCC_schematic.svg

Port description

  • Lemos are TTL positive level
  • The Async hdmi port provides a direct path for the trigger (the trigger doesn't go through the FPGA, but through the discrete logic on the mezzanine). Preferred connection point to BIF
  • The Sync hdmi port has the trigger signal synchronized with the 40 MHz chlock in the FPGA. This is the preferred connection point to AHCAL
  • The User hdmi port works same way as Sync hdmi port in the normal configuration. For special configuration (running with HGCAL, TLU) this interface is used as a slave input for that purpose
  • Trigger: trigger input, that is distributed through the HDMI ports. The Sync and User hdmi ports have same trigger signal latency, Async port has shorter latency (only few ns)
  • Spill: TTL input, 1=spill active, 0=no spill
  • Clock out: 40 MHz TTL out
  • acq out: acquisition state (1=acquiring data, 0=not taking data). Signal is NOT delayed. Can be compiled with a delay in order to delay other detectors until DIF passes the startup phase

Trigger and spill inputs have to be terminated, otherwise the pullup will drive the inputs to '1'


LEDs

LEDs visualise the internal states of the CCC. Since some signals are too short (trigger), the LED extends the light pulse so that it is visible by human eye.

LEDs on the mezzanine:

  • busy: one of the enabled HDMI ports has active busy
  • trigger: a trigger was registered (that requires the trigger to be actually enabled in configuration)
  • Acquisition: Acquisition was started and not yet finished. 
  • Communication: configuration was loaded (happens also during the boot)

LEDs on board

when all switches SW0 .. SW7 are at the bottom position (as shown at the picture), the led have following meaning:

  • LD0: acquisition;

  • LD1: busy;

  • LD5: alive signal (internal clock is running) is blinking

HDMI Pinout

  • pair 1-3: clk out
  • pair 4-6: command out
  • pair 7-9: busy in
  • pair 10-12: (not used)
  • pair 15-16: trigger

Simplified schematics

The internal vhdl code is rather hard to read, as most of operations is happening in a single process. To get a quick understanding of how the CCC works, here is a schematic:

CCC_schematic.svg


Configuration

The default address is is 192.168.1.61. The configuration is done by sending xml snippets terminated with 0 and with preceding 4 bytes of size. The typical configuration looks like this:

CCC xml configuration example
<conf>
	<action>
		<stop_acquisition>1</stop_acquisition>
		<halt_trigger>0</halt_trigger>
		<pass_trigger>1</pass_trigger>
		<start_acquisition>0</start_acquisition>
		<send_trigger>1</send_trigger>
		<reset>0</reset>
		<send_sync>0</send_sync>
	</action>
	<acquisition_mask>
		<start_on_falling_edge_of_spill>0</start_on_falling_edge_of_spill>
		<stop_on_rising_edge_of_spill>0</stop_on_rising_edge_of_spill>
		<stop_on_rising_edge_of_busy>1</stop_on_rising_edge_of_busy>
		<start_on_falling_edge_of_busy>0</start_on_falling_edge_of_busy>
		<autostart_outside_spill>1</autostart_outside_spill>
	</acquisition_mask>
	<peripherals_mask>
		<evaluate_asynchronous>0</evaluate_asynchronous>
		<evaluate_synchronous>1</evaluate_synchronous>
		<evaluate_user>0</evaluate_user>
		<evaluate_rj45>0</evaluate_rj45>
	</peripherals_mask>
	<trigger_mask>
		<pass_when_acquisition_starts>1</pass_when_acquisition_starts>
		<halt_when_acquisition_stops>0</halt_when_acquisition_stops>
		<halt_when_acquisition_starts>0</halt_when_acquisition_starts>
		<pass_when_acquisition_stops>1</pass_when_acquisition_stops>
	</trigger_mask>
	<fcmd>1</fcmd>
	<fast_zeroes>0</fast_zeroes>
	<suppression_mask>
		<falling_edge_of_spill_inside_acquisition>0</falling_edge_of_spill_inside_acquisition>
		<rising_edge_of_spill_outside_acquisition>0</rising_edge_of_spill_outside_acquisition>
		<falling_edge_of_busy_outside_acquisition>1</falling_edge_of_busy_outside_acquisition>
		<rising_edge_of_busy_inside_acquisition>0</rising_edge_of_busy_inside_acquisition>
	</suppression_mask>
</conf>

The peripheral mask has to be consistent with the actual connection in the setup. The rest of the setup is usually taken care of in the Labview.

It is important to send the trigger ( <send_trigger>1</send_trigger> ) once after all connected DIFs are switched on, otherwise the DIF might not register the validation signal.  :

some of the xml tags have opposite meaning of falling and rising edge!

mistakes in the xml
<suppression_mask>
	<falling_edge_of_spill_inside_acquisition>0</falling_edge_of_spill_inside_acquisition>
	<rising_edge_of_spill_outside_acquisition>0</rising_edge_of_spill_outside_acquisition>
	<falling_edge_of_busy_outside_acquisition>1</falling_edge_of_busy_outside_acquisition>
	<rising_edge_of_busy_inside_acquisition>0</rising_edge_of_busy_inside_acquisition>
</suppression_mask>
<acquisition_mask>
	<start_on_falling_edge_of_spill>0</start_on_falling_edge_of_spill>
	<stop_on_rising_edge_of_spill>0</stop_on_rising_edge_of_spill>
</acquisition_mask>

Expert section: script encapsulating low-level xml commands is available here: https://svnsrv.desy.de/k5websvn/wsvn/General.ScCalo_DAQ/ccc/trunk/bin/root.pfs/home/root/configure.sh

Firmware

Firmware project is hosted at https://gitlab.desy.de/jiri.kvasnicka/calice-ccc/. Compilation is done automatically via a gitlab runner with VIVADO 2014, but can be also done manually. Details are in the readme.md of the gitlab.

SD card images are stored in the releases of the project: https://gitlab.desy.de/jiri.kvasnicka/calice-ccc/-/releases . the default is version 1.0.2:https://gitlab.desy.de/jiri.kvasnicka/calice-ccc/-/releases/v1.0.2  All files from the zip files need to be copied to the (warning)empty SD card.

Fast commands

Fast commands are 10 MBit/s UART-like. 1 start bit, 16 data bit (LSB first), no parity bit, 2 stop bits. All outgoing transmissions are synchronized with internal 5MHz slow clock.

CCC knows these commands:

  • 0xE311 - start of acquisition
  • 0xE313 - stop of acquisition
  • 0xE000 - synchronization fast command (DIF synchronizes its internal 5MHz divided clock to the arrival of this command)
  • 0x0000 - command to reset the LVDS buffer (not needed anymore).
  • No labels