PC/MCM

notes about the PC/MCM

Note added 16-Sept-1999: These notes are now out of date. Most of the problems described here were caused by xilinx software problems (including problems with Xilinx spped grades) and have now been solved. I have kept this note because some of the descriptions may be useful for other purposes. The information which follows was last updated 20-Oct-1999.

The work described in the following section was done using an FPGA code dated Aug 24, 1998 -- MCM8_24.RBT.

The biggest problem we are having with the PC/MCM has to do with the correlator on/off mode. The MCM seems to work with with correlator off (i.e. it sends out a pre-sample and a post-sample), but not with the correlator on (where it should send out the post-pre sample difference). The following plot of ADC distributions shows the (post-sample) - (pre-sample) from data taken in raw mode:

These tests were done with a series of 5 consecutive level-1 accepts shortly after one another. In the fourth of these 5 level-1 accepts, we inject a charge into the ADC channel which is plotted. So, we should see a non-zero ADC value in the fourth plot (which comes from the 4th of the 5 accepts in each set) and no signal in the other 4 plots. This is what we see. The following plot shows that the post-pre ADC difference in raw mode does depend on the size of the input signal. The plot shows the ADC difference as a function of the size of the input pulse:

This is clearly not perfect. The signal does increase as the input is increased, but not very smoothly or very linearly. We hope this has to do with the crude method used in inject the pulse. However, we think this proves that the PC/MCM does respond to an input signal.

The plots above come from work we did sometime around September 4, 1998. At that time, we incorrectly concluded that the PC/MCM sends out the "post sample" when the correlator was turned on. Actually, we were running with AMU/ADC in raw mode and the Heap manager in correlated mode (these are independent bits in the serial string). The result was that the PC/MCM always appeared send out just the post sample.

When the AMU/ADC and heap manager serial bits were both set to correlated mode, there was a different problem (on September 4). The problem was that the ADC value which came out was approximately the same for every channel and no longer depended on the input.

The work done in this section was done around September 9-10, 1998. We used FPGA files dated Aug 24, 1998 -- MCM8_24.RBT and September 9, 1998 -- MCM9_9.RBT. Melissa's note which came with the new file (9_9) said "I hope it will correct the order of the amu cell addresses." My notes say I did not notice a change in the data we read out with the file in either raw or correlated mode. My notes also say I did not understand what should have been difference.

On September 9th, Melissa Smith also sent us this picture of the expected behavior of some of the signals related to the correlator:

SangKoo Hahn (mostly) and I measured these signals and saw the following:

The measured results are not in perfect agreement with the simulation. Mike Emery said (Sept 10): "I took a look at your timing figure and I do see some diferences between yours and what we are running here for correlator mode. The difference is with the CONN signal. When it goes low (approximately aligning with the falling edge of the first RENA pulse) ours stays low until well into the second RENA pulse."
When we look at the PC/MCM, we see that the CONN signal goes low about 0.5 microsec before the falling edge of the first RENA pulse and goes back high between 0 and 0.5 microsec _before_ the rising edge of the second RENA pulse. So, the discrepency you note seems to be real -- the CONN pulse does not stay low into the RENA pulse.

Mike Emery also said: "Running at 40 MHz, our first RENA is about 4 us, the valley in between is about 5 or 6 us, and the second pulse lasts about 16 us. The CONN signal returns high about 6 us into the second RENA pulse." On the PC/MCM, the two RENA pulses are not the same length, but the difference is smaller than in Mike's simulation. Actually, this part looks like Melissa's simulation. The first RENA pulse is high for 9 microsec and the second is high for 12 microsec. If we were running with a 40 MHZ clock there would be about 3 and 4 microseconds. The valley between them is 17 microseconds, which would fall to about 5-6 microseconds with a 40MHz clock.

Mike also said "AMPRST looks OK relative to RENA."

Summarizing, here is a comparison of what Mike says we should see and what we actually see on the PC/MCM.

time difference:	Mike's value (micro sec)	PC/MCM value (microsec)	commnent
CONN signal low until falling edge of 1st RENA	approx 0	0.5	maybe OK?
CONN signal back to high until 2nd RENA pulse	something negative	+0.5	they seem to disagree
width of first RENA	4	3	maybe OK?
width of 2nd RENA	16	4	they disagree
valley between RENA pulses	5-6	5-6	OK

Somewhere around this time, SangKoo Hahn realized that the Correlator Reset signal is always high. In Melissa's simulated results (see above) it is also always high. Here is what Mike Emery told us about this: "Sangkoo told me the reset was always high, and that would be a problem. I think it would always convert the Correlator DAC voltage in this case. It should be low in the correlator mode, don't care in raw mode. I would expect it gets pulsed for a few microsecs prior to starting a read, but I will have to go look at the circuit board with a scope to tell exactly what is going on. ..." Next, Mike looked at the state of the Correlator reset in his test setup. The results are shown below:

Correlator Mode, 40 MHz Xilinx clock, Top signal = RENA, Bottom Signal = CorrReset, Vertical Scale 2V / Div, Horizontal Scale = 5us / Div.

The correlator reset should not be high during the second RENA.

We tested Mike's suggestion ("it would always convert the Correlator DAC voltage") by measuring the output ADC value for several values of the correlator DAC setting. If the correlator amp is is permanent reset mode, as we seem to see, then we expect that the digitized ADC value we see should correspond to just the CORR_OFF_IN voltage, which is controlled by the CORR_OFF_DAC. We just tried changing CORR_OFF_DAC to see if this was true -- it is. Here are the measurements:

CORR_OFF_DAC (volts)	ADC value (channels)
0.10 (minimum)	70
1.62 (standard)	379
2.49 (maximum)	580

This is with Vref=4.80V.

In an effort to solve this problem, Melissa produced a new version of the FPGA file on September 14th -- MCM9_14.RBT.

This version had a new problem. When you trigger one event (using the bench cal or phenix-cal-enable) the heap manager sends events off the board continuously until we reset it. We see this from

our code reads events endlessly,

we looked at the clk_out pin on the heap manager xilinx and it runs constantly after the first trigger.

This did not happen with the previous (9_9) file. We looked at the RENA and CORR_RESET signals at the AMU/ADC. They do not look like Mike's picture (see above). So, a trigger causes the board to send out an endless stream of data. However, the first trigger does cause the CORR_RESET line to be exercised. Here is a "sketch" of what we see with the new (9_14) xilinx file:

CORR_RESET stays low until (approximately) the leading edge of the next RENA pair (i.e. until the next event) So, the differences from Mike's sketch are:

In Mike's diagram CORR_RESET is high before the event and goes low at the leading edge of second RENA high pulse in the pair.

In Mike's diagram CORR_RESET stays low from about 17 microseconds after RENA goes low the second time. Then it goes back high. Currently, we see CORR_RESET low until the next event -- no matter how long that is.

In Mike's diagram the second RENA high period is a lot longer than the first one. Here the second one is just 20% or so longer. This was true in previous versions of the FPGA code too.

On September 15, Melissa sent us a new FPGA file, MCM9_15.RBT. It still sent out an endless stream of data after the first trigger, but it was different in some respects. Here are my notes in the subject:

I tried the new mcm9_15.rbt file. I could not get the system to work with this version either. The most annoying problem continues to be that the pc/mcm starts sending data out after the first trigger and never stops sending data. Today, I noticed that the data consist of a test pattern --
channel 1 returns 1
channel 2 returns 2
... etc

The results seem to have nothing to do with the setting of the COR_SEL bit. The packet headers have one AMU number and a 3FF for the two AMU cell numbers, which looks like it is returning data in uncorrelated mode, but the COR_SEL bit is set to correlated mode.

Looking on the scope at RENA and CORR_RESET, CORR_RESET is always high. RENA is a little strange. The first trigger after doing an MCM_RESET (or reloading the fpga's) results in RENA going high twice. Each time the pulse is about 15 microseconds wide (therefore about 5 microseconds if we used the full clock speed) and the two pulses are separated by about 150 microsec (therefore about 50 microsec for a full speed clock). One all subsequent triggers the two pulses are about the same widths (but the first one is longer than the second) as on the first trigger, but they are only separated by about 25 microseconds -- compared to 150 for the first trigger.

The next new FPGA files was dated September 16 -- MCM9_16.RBT. The following report (to Melissa) about that file comes from Bernd Schlei:

"After a (successful) download, the single issuance of either a LVL-1, BenchCal, or PhenixCal trigger brings the HM into a mode, where it fires permanently. The following FPGA files of yours show this behaviour: mcm9_15.rbt & mcm9_16.rbt.

The file mcm9_9.rbt allows us to send a PhenixCal trigger once or twice, then we have to do a MCM-Reset in order to see a packet generated by another (any) trigger."