Computer Interface

Purpose

The computer interface reads the pulses from the SPCMs, processes the information, and then transmits if to a LabView program.

Equipment

The SPCM pulses and their coincidences are counted by a Digilent NEXYS3 board. Data from this board is then sent via RS232 and an RS232-to-USB converter (USB Serial Adapter - Ultimate (XS880) $76) to a Windows based PC where the information is processed in LabView.

The PC is the master and initiates all calls and then reads the data back; the board is the slave.

Picture (Unfinished)

NEXYS3 Pinouts

• (From SPCM A to) Counter 0: JA[0], Upper Row, Left Most Pin

• (From SPCM B to) Counter 1: JA[3], Upper Row

• (From SPCM C to) Counter 2: JD[0], Upper Row, Left Most Pin

• (From SPCM D to) Counter 3: JD[3], Upper Row

• RS232 External Module plugs into JC Lower Row. (May need a connecting cable because it interferes with nearby connector JD.) Specifically

  • Input RxD; JC_L[2] Lower Row

  • Output TxD; JC_L[3] Lower Row

Current Software Versions

NEXYS3 Verilog Software / Firmware

The most recent Firmware (Bit File) NEXYS3 board is :

0x1112 or rs232_v3m_Nex3_V1112.bit (see file in attached files below)

(To test the board for the version, set the switches on the NEXYS board to 1011 1111 and it should display its version on the HEX display.)

It was compiled from Xilixn ISE Webpack 14.1 Project RS232_V4.ise using Verilog File:

\\spa-home.spa.umn.edu\SCIPIOUSERS\spawick\Documents\Xilinx\RS232_V4\RS232_V4a.v. The topmost module being RS232_V3m: (sorry about the version confusion)

module RS232_V3m( sysclk, rad_triggers_in, RxD, TxD, Switches, LEDs, sevenSegLED_out, sevenSegPos_out, JB_U);

Status

Version 1112 works and has been tested all summer of 2012 but future updates should:

1. Fix the version numbers for the module names.

2. Get rid of the “CLOCK DEDICATED” line assignment by finding more suitable inputs.

3. Use the clock manager to see if speed on the board could be increased by a factor of at least 2x. (Maximum speed possible on a simple project was 7x but we are not sure if the inputs could hold up at that rate and this needs to be tested separately.)

LabView Interface

The Latest Version of our LabView Interface is: Project: RS232_RadCounterXilinxV4a with RS232_RadCounterXilinxV4b.vi and affiliated sub Vis. It is stored in the U:\Pub\XPeriments\SinglePhotonQuantumInterference\LabView folder.

Verilog Code Description

Overview

The MXP.VerilogCode executes the following tasks:

1. It counts the number of events from the four counter inputs, A, B, C, D.

2. It counts all possible coincidences between the four inputs using an adjustable coincidence window.

3. It provides the system clock for setting the coincidence window length and for the time measurements.

4. It provides the RS232 interface to communicate with the computer.

A flow chart of the code is:

1. The code waits for a byte being transmitted from the computer to the board via RS232. On receiving that byte, the board then:

2. reads all counters

3. resets all counters;

4. sets the coincidence window width corresponding to the byte received;

5. transmits all the timer and counter information back to the computer via RS232 and then returns to state 1. The individual parts of the code are described below in more detail.

Notation

The inputs from the individual counters are sometimes referred to as A, B, C, D but they are also sometimes labeled 0, 1, 2, 3 respectively, with A being 0, B being 1 etc.

Timer

The board runs off its system clock a continuous timer. This timer keeps track of the time elapsed in milliseconds, seconds and minutes and it is reset at the beginning of each measurement cycle. The data from the timer is then prepended to the event counter data and it specifies the exact length of the actual measurement cycle.

Initialization of a Measurement Cycle and Setup of the new Master Clock

At the start of each measurement cycle, the computer sends and ASCII Byte tau_sysclk through RS232 to board specifying coincidence window length, one_shot_clk:

ntau_sysclk <= RxD_data-65;

assign one_shot_clk =( ntau_sysclk == 61 ) ? sysclk: one_shot_clk_reg;

(For a description of how the ASCII Byte corresponds to the coincidence window length read at the bottom of this description.) The one_shot_clk runs then continuously. It increments itself at the specified coincidence window time interval and it becomes the new master clock for all counting events.

Event Trigger

When an (asynchronous) trigger (count) event has been received from one of the SPCM, its One Shot is triggered OneShotV2 and then stays HI for the next synchronous one_shot_clk cycle producing a synchronous signal oneshotX_out. (The X refers to the specific SPCM .)

OneShotV2 OneShotC0( one_shot_clk, rad_triggers_in[0], oneshot0_out);

Note: a finite time interval lapses between the time the asynchronous trigger signal has been received and the synchronous One Shot output signal becomes HI.

Event Counting and Coincidences

Valid events are counted by the 32 bit CECounter32 module. The counter itself runs at the rate of the master clock one_shot_clk and it increments only if the counter has been enabled through its count enable input, i.e., its third argument. (In the example shown below this corresponds to oneshot0_out.)

CECounter32 myCECounter0(one_shot_clk, master_reset, oneshot0_out, finalcount0_out);

For single, non-coincidence counts, in the CECounter32 module, the count enable corresponds to the synchronous One Shot signal created previously from a trigger signal by the SPCM. (Note: (well behaved) trigger signals activate the One Shot output for a single master clock cycle.) For double coincidences the count enable is the coincidence (AND) of two One Shot signals. For example, the coincidence between events from SPCM 0 and SPCM 1 is created by:

assign coinc_01 = oneshot0_out & oneshot1_out;

CECounter32 myCECoincCounter01(one_shot_clk, master_reset, coinc_01, final_coinc_01_out);

Similarly, this procedure is repeated for triple and quadruple coincidences:

assign coinc_012 = oneshot0_out & oneshot1_out & oneshot2_out;

CECounter32 myCECoincCounter012(one_shot_clk, master_reset, coinc_012, final_coinc_012_out);

assign coinc_0123 = oneshot0_out & oneshot1_out & oneshot2_out & oneshot3_out;

CECounter32 myCECoincCounter0123(one_shot_clk, master_reset, coinc_0123, final_coinc_0123_out);

Important: to be a valid coincidence, both trigger events must have occurred within the same (synchronous) coincidence interval, i.e., master clock cycle. What seems counter intuitive is that two trigger events may occur within a time window that is shorter than the coincidence time interval though they still produce an invalid coincidence! For example, if one event one occurs at the very end of the first master clock cycle and the second event 2 at the very beginning of the next cycle then two one shot signals would each be in a different master clock cycle, resulting in an anti-coincidence. See the notes I sent to David Jackson on how to account for this.)

End of the Measurement Cycle and Data Transmission

The counters keep on counting valid events, or tracking the time elapsed since the last reset, till the board receives a new coincidence window byte from its RS232. At that moment, all the count data and time stamps data is stored and all counters and clocks are reset and restarted. Finally, the stored data is concatenated and sent back to the computer via RS232 in the following format:

DataOut <= {16'h0000, days, 16'h0000, hours,16'h0000, minutes,16'h0000, seconds, 16'h0000, miliseconds, 16'h0000, sysclkfreqMHz,

finalcount0_out, finalcount1_out, finalcount2_out, finalcount3_out,

final_coinc_01_out, final_coinc_02_out, final_coinc_03_out,

final_coinc_12_out, final_coinc_13_out, final_coinc_23_out,

final_coinc_012_out, final_coinc_013_out, final_coinc_023_out, final_coinc_123_out,

final_coinc_0123_out };

In other words the serial port of the computer receives 6 blocks of timing information and 15 blocks with counter information in the order shown above, separated by commas. Each block is transmitted in an unsigned 32 bit integer format. See the table below.

Note that each initialization of the coincidence window results in a transmission of the previous count results. Therefore, at startup, the first transmission should always be ignored.

Comment Regarding the Coincidence Window Length and the ASCII Character Sent

The width of the coincidence window is set by the ASCII byte sent to the NEXYS3. The system clock of the board is 100 MHz or 10 nsec. and this is the shortest coincidence window that can be used unless the clock manager is used. (With the clock manger it might be possible to tweak this by a factor of 7.) The ASCII byte corresponds to the number of system clock cycles as follows: etc., i.e., for ASCII Value >= ‘A’, Coincidence Window = 2*(ASCII Value – 64)*system clock cycles

LabView Interface

LabView Code Description

After initializing the RS232 interface, LabView starts a measurement cycle by sending one byte to the NEXYS board via RS232. This action sets the coincidence window length on the board; it also forces the board to resets its counters and to send all the data acquired during the previous measurement cycle back to the PC via RS232.

After a short delay time (to ensure that all the data has been received by the PC) the data is read from its RS232 buffer and decoded according to field position. (See Table 1 above.) All the information is converted into suitable data types and the counts are all divided by the duration of the previous measurement cycle to obtain rates, i.e., counts/sec. The timing and rate information is displayed in the indicators and graphs.

Finally, after waiting a specified gate time interval (which is controlled through the front panel) the measurement cycle will be repeated unless the STOP button has been pressed.

Note that while LabView processes the information from the previous measurement cycle, a new cycles has been started and is running concurrently on the NEXYS board. Therefore, all measurements displayed by the LabView interface correspond to the previous measurement cycle; changes made on its interface will be reflected two measurement cycles later! (It takes one cycle during which the changes are measured and another one to read the data back.)

A more detailed description of the code can be found from the comments in the Block Diagram shown below.

The LabView code consists of three files, the top module and two sub modules consisting of controls or typdefs.