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

The firmware needs to be loaded to the SD card.

  1. empty the SD card before
  2. All files, that need to go to the sd card are in the bin directory on svn: https://svnsrv.desy.de/k5websvn/wsvn/General.ScCalo_DAQ/ccc/trunk/bin/
  3. copy BOOT.BIN, image.ub and root.pfs to the root of  the SD card.

How to compile the firmware

Should be done only by the expert. The source code is located on DESY svn here: https://svnsrv.desy.de/k5websvn/wsvn/General.ScCalo_DAQ/ccc/trunk .


 Detailed instructions

Prerequisities:

  • Vivado 2014.2
  • petalinux 2014.2

There is a tcl script (ccc/trunk/vivado/scripts/make_project.tcl), that creates the whole project from the local svn mirror. Following items need a modification before starting vivado: project_name and sccalo_svn_dir. vivado is started with a command:

   vivado -mode tcl -source  make_project.tcl

The compiled bitstream and newly created SDK project need to be compiled in petalinux, in order to program the processor part as well. Instructions on how to compile under petalinux is described here: https://svnsrv.desy.de/k5websvn/wsvn/General.ScCalo_DAQ/ccc/trunk/petalinux/petalinux_instructions.txt .

Finally, following files need to be copied to the SD card:

  • BOOT.BIT (goes to the root of the SD card)
  • images/linux/image.ub (goes to the root of the SD card as well)
  • root.pfs from svn (ccc/trunk/bin/root.pfs

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