Power Play

It occurred to me when leaving yesterday that I should check the +2.5V power supply of the DACs, how it is wired in the OrCAD schematics, where it comes from...  It might be sagging for some reason, possibly explaining the delayed output.  E.g., perhaps there is a short between it and an FPGA pin; or perhaps some other device on the board (an ADC) is drawing a lot of power from it; or perhaps the voltage regulator that is supposed to supply it is not being turned on.  I'll check that today.

OK, in the OrCAD schematics, the name of the +2.5V supply going to the DACs is "+2.5VCC".  Let's do a search to see where else that is used.

OK, interestingly, on page B4POWER_PROGRAM, the +2.5V supply is connected to the FPGA on 8 pins with four port names:  VCCIO1 (M22+AA22), VCCIO2 (L22+B22), VCCIO5 (B1+L1), VCCIO6 (M1+AA1).  Not sure yet if the FPGA is supposed to be supplying, or consuming this level.

On that same page, +2.5VCC also appears to be used by the JTAG interface IC, ref. des. U7, on its VCC port (pin 4).

The FPGA is probably just consuming the level, because on the B7Regulators page, +2.5VCC appears to be produced by voltage regulator U40 on pin 4.  A handy place to measure the level near the source looks to be JP14 (a SIP-2P), pin 1.

There do not appear to be any other connections to this node, except for capacitors.

So, let's check the original design to see what it does with the VCCIO1-2,5-6 ports.  These appear to be all hard-wired pins (upward triangles) for driving I/O banks.  So, maybe it is the VREF groups that are the problem.  At some point I should spend some time trying to better comprehend VREF groups and I/O banks.

After powering up the board, JP14 (+2.5VCC) reads at 2.416V.  (A bit less than +2.5V - perhaps this is why the DAC outputs don't get closer to +2.5V in any tests?)

Programmed in the new project.  Hm, no change in the +2.5V supply level.

Let's go back to the I/O banks.  Each I/O bank has an associated VCCIO pin.

In the old project, the I/O banks were:

• OSC100MHzin (3.3V LVCMOS) - Pin AB13, I/O bank 8, VREF group B8_N1.
  
• PULSE[1] - (FILL THE REST IN LATER AS NEEDED)
• PULSE[2]
• TVTH[5]
• TVTH[3]
• P1VTH[3]
• PULSE[6]
  
• P2VTH[6]
• P4VTH[5]
• P2VTH[3]
• P1VTH[1]
• P1VTH[5]
• P4VTH[6]
• TEST[6]
• TEST[7]
  
• TVTH[6]
• FIFO_FULL
• P1VTH[6]
• DACCLK
• DACCS
• DACIN

VCCIO8 is pins AB12+AB20, which go to +3.3VDOWN, and VREFB8N1 is pin AA14, which goes to +1.2VCC, which comes from voltage regulator U39. 

VCCIO7 is pins AB3+AB11, and VREFB7N1 is pin W6, which goes to +1.2VCC, which comes from voltage regulator U39.

I noticed a couple of synthesis/fitting settings that were different between the two projects, and made them the same... Now recompiling.  Nope, that didn't help.

Let me try copying Darryl's new modules over and including them...  Also their version of the controller.

dac_cpu_test.{vhd,bsf}, dac_cpu_if.{vhd,bsf}, dac_control.{vhd,bsf}

The reason being, it will be easier to inspect the DAC output signals on the scope to diagnose what's wrong there with a periodic signal.

Couldn't find anything wrong with the DAC outputs.  And reverting to David's version didn't help.

Next I tried importing the old top-level file and the instance assignments into my new folder.  No dice.

Then I tried importing my new design files into the old folder.  That worked.

So next I tried importing global assignments from the old folder into the new folder.  That worked, but now I have all the pin assignments again.  Plus a bunch of other stuff that I don't understand.  Anyway, it works now.

Next I deleted the unused pin assignments manually.  While doing this, we noticed various "altera_reserved_" ports that were being used in the old assignments - we kept these, as well as the other global assignments, and that works still.

Next things we can work on:

• Share the new folder
• Test with external pulses
• Write C driver to set DAC levels
• Write the rest of the C code (pump pulses on interrupts, generate output stream to Wi-Fi, eventually also handle input commands) 

OK, I put the new project into the shared folder, and David mounted it from the other computer.

We hooked up a signal generator to generate approximate triangle waves, and confirmed that the number of thresholds crossed was appropriate for the pulse height.  However, we saw a lot of noise in the digital pulse width values.  This appears to be primarily due to timing errors, perhaps due to the timing constraints file not having been set up properly.  Tomorrow I will see if I can fix this and get a little better performance.  For now, we turned down the system clock speed by a factor of 2, and are getting reasonably stable outputs.  For example:

Here as an input pulse produced by a waveform generator, with nominal pulse height of +2.6V, 20/60 ns leading/trailing edge transition times, and 58 ns pulse width.   (In this trace, the horizontal scale is 20 ns/division and vertical is 0.5V/div.)

Test input pulse produced by our waveform generator.

 And, here is the corresponding output from our test bench:

The purple line at the top is the input pulse, zoomed out to a wider timescale.  The six threshold levels used in this test were 0.24, 0.50, 1.00, 1.50, 2.00, and 2.41V respectively.  The time resolution used for input capture in this test was 4 ns.

The output digitally reported (streamed out under control of the light blue pump signal) is: All 6 threshold levels were crossed, with crossing times (in hexadecimal): 0, 1, 2, 3, 5, 6, 8, 11, 15, 19, 23, 25.  Multiplying these time counts by the 4 ns resolution, and plotting them against the known threshold voltages, we obtain the following chart,

Which appears to be a reasonably faithful representation of the original pulse, given the limited time resolution used in this test.  (We could do even better if we were reconstructing a best-fit pulse shape from an analytical model of real input pulses from a PMT.)

All in all, I'd say it was a day of pretty good successes...