-
Skip to most recent entry
-
Updated: $Date: 2002/04/12 00:31:59 $ (UTC)
-
Log book for "COT signal analyzer" board
-
Mircea's suggested schedule:
-
Calculate power for APEX chip(s) immediately
-
Finish Altera part of schematic by Aug 25
-
Altera chips could be in next week (if we order them)
-
DC/DC converters in December
-
Straight through 125 MHz works in 20K100E-1 (165 MHz OK), but not in 20K100-1 (105 MHz OK)
-
20K100E-1 isn't available yet and isn't 5V tolerant (and we thought it was expensive, $320, but that was a mistake, really $120)
-
dividing to 62.5 MHz works in 20K200-2 (not sure about 20K100-2), but simulator has weird preferences for clock edge/data timing
-
straight through 62.5x64 is rated for 115 MHz on 20K100-1 ($120), 101 MHz on 20K100-2 ($84), 95 MHz on 20K100-3 ($60)
-
Want to explore idea of stepping down to 62.5MHz x 64 bits externally
-
Data capture speed (16 bits, 1 clock):
EP20K100BC356-1, TCO = 1 ns: 171 MHz
-1, 2 ns: 162 MHz
-1, 3 ns: 139 MHz
-1, 4 ns: 122 MHz (X)
EP20K100BC356-2, TCO = 1 ns: 134 MHz
-2, 2 ns: 134 MHz
-2, 3 ns: 120 MHz (X)
EP20K200BC356-1, TCO = 1 ns: 162 MHz
-1, 2 ns: 162 MHz
EP20K200BC356-2, TCO = 1 ns: 129 MHz (X?)
-2, 2 ns: 129 MHz
-
Plan is to try the following, determine speed, for 20K100 and 20K100E:
-
capture data, 1 clock in , 1 clock out
-
align data, 2 clocks in, 1 clock out
-
buffer data for VME readout
-
Harold says maybe try using MAX 7000B as extra layer of registers?
-
Got all of the following working (incrementally) on 100-2 chip:
-
Capture/divide 2x8 at 125 MHz
-
Capture/divide/delay 2x8 at 125 MHz
-
Capture/divide/delay 4x8 at 125 MHz
-
This does everything except VME buffering; uses 10% LE, 40% IO pins, 61% ESB bits
-
Altera chip availability:
EP20K200BC356-2 in stock $224
EP20K100BC356-2 8 weeks $83
EP20K100BC356-1 4-6 weeks $119
EP20K200BC356-1 8-10 weeks $317
EP20K100EBC356-1 will advise $119
EP20K100EBC356-2 2-4 weeks $84
-
data delay devices programmable 0.5ns delay is $16, 8-10 weeks
-
capdelbuf.tdf worked in 20K200-1 but not in 20K200-2, with TCO=2ns in simulation vectors
-
ESB depth is 128 words, so using a VME buffer that is only 256ns x (sample / 2ns) x (word / 8 samples) = 16 words deep wastes ESBs by a factor of 8. That is why project fits in 20K100 at 125 MHz but not at 62.5 MHz.
-
(1) use 20K100E at 125 MHz
-
(2) use 20K200 at 62.5 MHz
-
(3) use 20K100 at 62.5 MHz with restriction on overlap of L1A to different buffers
-
Lately I have been pursuing (2). When I try (2) with 4 separate data phases (2ns apart), I am unable to make it work, even with 1ns clock-to-output time (TCO) on input, even with 20K200-1. (This assumes that stepdown to 62.5 MHz occurs inside the 20K200.)
-
Uhoh, now I'm no longer certain that waveform vector input file was saved before I ran on 20K200 with 1ns TCO, so I need to re-check that some time. Statement is still true for 2ns TCO.
-
I could probably make (2) work by doing the stepdown externally, either with discrete flipflops or with a second Altera chip. But the 20K200 chips are also rather expensive: $224 for -2 and $317 for -1.
-
So I think (2) is ruled out.
-
Plan (1) has two disadvantages:
-
The 20K100EBC356-1 is not available yet. But it is expected to be cheap ($119) once it is out.
-
The 20K100E is not 5V-tolerant, so one needs to use series resistors between 5V outputs and the 20K100E. That doesn't seem like such a big deal.
-
I would like to prove that (1) will really work at 125 MHz, and I would like to show in more detail why (2) will not work. But in the short term, I think I want to try to make (3) work.
-
Actually, there may be a (3'), which is to use 20K100E-2 at 62.5 MHz with L1A restriction, then migrate to 20K100E-1 when it is available.
-
So I decided to go with plan (2) after all. The ACEX EP1K30TC144-1 is in stock, costs only $34, and can do the 125-to-62.5 stepdown easily. Then I use the 20K200BC356-2 (though -3 would work fine, so far, for $80/channel less than -2) at 62.5 MHz. For the prototype, I decided to chicken out and buy the -2, to have some contingency. I think we should use the -3 for production unless we learn in the meantime that it won't work.
-
Project "capdiv4x8max" in ACEX EP1K30TC144-1 works at 125 MHz (rated for 230 MHz!?) with TCO=1ns, 2ns, 3ns, but not 4ns. This is with compiler's pin assignments.
-
OK, now I assign input pins to be nicely in a row, but leave output pin assignments free. Now I have setup time problems at tco=2ns, OK at 1ns.
-
ffbq1 tsu=6.4ns; ffbq4 tsu=6.4ns. Eliminated stage jj; now only ffbq1=6.3ns exceeds 5ns. Free up dedicated input pins by moving inbq6 to pin 22; no change. Shuffle some pins; now inbp1=6.1ns. OK, after more pin shuffling, now all tsu=5.4ns or less.
-
Now I'm rechecking Quartus delbuf64 project. Using 20K200-3 chip, it does 66.7 MHz, limited by input register delay, when I use 8ns external input delay. When I reduce external input delay to 4ns, I get 87.7 MHz, limited by VME buffer write address time. When I register the VME buffer write address, the bottleneck gets slightly worse: 85.4 MHz! When I set write-enable to VCC (instead of !idle), I get 91.1 MHz, limited by input registering.
-
Power estimate: 10mA/channel at 3.3V for I/O; 20mA/channel at 2.5V for EP1K30; 240mA/channel at 2.5V for APEX 20K200
-
OK, made first ~1/4 of 20K200 pin assignments, and speed is still 91.1 MHz. OK, all pin assignments for input data are in, and still 91.1 MHz. (Seems too good to be true.)
-
Oops, stupid compiler pin syntax is different in Quartus than in MAX+Plus (uses brackets for inp[0], not just inp0, etc.); fixed that.
-
OK, input pin assignments are in, and now I get 75.3 MHz, limited by input registering.
-
Fleshing out bus definitions, parts, to-do items
-
My pin assignments going from ECL/TTL D-flops to EP1K30 were basically upside-down, so I had to redo them. Compiler reports same fmax, even with output pin assignments fixed at previous values.
-
Mircea generated new connection_list yesterday; pin assignments looked quite nice.
-
I tried to run quicksim on the schematic with one "data buffer" instance set up
-
Actually, I was trying first to use only the 1K30 chip, which is compiled with MAX+Plus; I don't yet know how to generate an EDO file from Quartus
-
Mysteriously, I get either "ground" or "unknown" output from every pin on the 1K30. I am trying a "test" schematic with just the 1K30 on it, to see if that works any better for me.
-
Tech support call to Altera. My Altera ID number is 502 564. Fiyaz says nativelink is the way to do this sort of thing in 2000-05 release of Quartus. I'm using 2000-03 release. Support call ID number is 10021967.
-
My problem with the 1K30 was that I was calling the clocks "clockp" and "clockq" in Altera but "clkp" and "clkq" in Mentor. Now it works!
-
Last Friday, I wrote "place.py" to copy the placement of components automatically from first channel to the other five channels. Mircea and Harold were ecstatic.
-
Mircea has succeeded in copying the traces between channels, except for minor booboo described below
-
It turns out that there were about half a dozen components (most if not all were capacitors) for which the identities were mixed up with other instances of the same part; Mircea says it's easy to fix these by hand
-
I got magic incantation from synopsys smartmodel datasheet, and with that I was able to get quicksim to recognize the 20K200 chip, but now I run out of memory trying to load it; Mary is trying to add swap space
-
On Tuesday, I got "place.py" to use a report file generated from PCB design viewpoint to associate instance numbers with reference numbers, which then made the matching problem trivial, so there are no more booboos in copying the placement.
-
Even with lots more virtual memory, the 20K200 barfs in quicksim. Service call is in, but unanswered. Looks as if we'll have to use Quartus for that.
-
Mircea is following up with Synopsys on the 20K200 Quicksim issue
-
Drew some simple timing diagrams using "typical" values for everything from FADC output to 1K30; maybe need to formalize this, experiment with full range of values allowed in specs, cook up a way to feed this into simulation of 1K30
-
Updated Custom_P2 schematic, to remove SVT-specific connections, add TDC_DONE; need to remember to check all this stuff on connection_list
-
Mircea is working on EPC2s, JTAG, etc.
-
I need over the weekend to redo the auto-placement, this time with one monster report file from layout
-
I tried transplanting data-vs-clock timing from output of 1K30 in MaxPlus to input of 20K200 in Quartus, and got setup/hold violations on the "p" inputs but not the "q" inputs. After unsuccessfully screwing with the clocking of the "p" outputs of the 1K30 (e.g. trying to latch everything to the same clock), I decided just to invert the clock coming out of the 1K30, which seems to work.
-
Now the clock is approximately right on top of the "P" transitions, and the "Q" transitions are about 2ns later than that.
-
Maybe one "reset" line from 20K200 to 1K30 would be a good idea, e.g. to clear flip-flops
-
I think 3 test points between 1K30 and 20K200 would be good, for checking timing: clock, p0, and q0
-
Adding an extra JTAG-like connector next to each 20K200 is OK with Mircea, so I need to do it
-
In Quicksim, as in Altera simulation and compilation report, there is a 3.5 ns window in which the clock can come to the 1K30 chip (with respect to the data), out of the 8.0 ns clock period.
-
"Auto fast I/O" option in 1K30 chip causes it not to work above 105 MHz, so I leave it off
-
Quicksim now works with data flowing into 1K30, out "debug" output of 20K200
-
vme interface chip has 30% logic used, so we have some room to play; also currently has 9 unused pins
-
not-so-useful vme pins: GA4..0, _vme_err, address26..24, vme_address26..24, AM2
-
I want to add tapped delay outputs (10), vme_ctrl bus (4), and ability to drive nCONFIG lines (1)
-
I re-ran the auto-placement program for Mircea; had to break flip and rotate into separate steps to get rotated back-side components right
-
I reassigned a bunch of pins (mostly the bussed vme address and data lines) on the 20K200, to make routing easier
-
Something is bogus in logic analyzer connector on schematic; Mircea thinks he fixed it
-
Got VME interface working. The Altera program and its pin assignments have some minor changes from the L1 boards, so that I don't have to put in a "control" chip that is separate from the "vme interface" chip. Next step is to create a few R/W registers within each 20K200 chip.
-
Fixed up pin assignments for clkqsel, clkpsel, debug, for better routing.
-
Uhoh, contrary to the prior belief of Mircea and me, EP20K200 chips are only 5V-tolerant if they have a V at the end of the part number, e.g. 20K200BC356-3V or 20K200BC356-1XV. The -2V doesn't exist, and the -3V is still vaporware. So we'll order 7 of the -1XV chips ($330, in stock), return the 15 -2 chips ($220), and try out the design on -3V chips (probably $165) when they appear. Then the prototypes are conservative, but there is a cost-saving option for producing a larger set.
-
I have been working full-time on SVT commissioning, and Mircea has been at a conference, so the project was on hold for a couple of weeks. Anyway, once it became clear that it was impossible to have the board before the end of the commissioning run, it was possible to take a more careful, rational approach to finishing up the board.
-
Mircea has the entire board routed, except for some VME lines. We want to change some VME pin assignments, to make the routing cleaner.
-
Need to tell Mircea which pins are -5.2V (cal vs trk crate)
-
Moved dip[0] on BGA from F2 to R5 to make routing easier
-
Completely re-did VME chip pin assignments, to simplify routing
-
Put schematics and layout on web page
-
Mircea has everything routed
-
Trying to dot i's, check things, etc.
-
Sprinkled test points around the board
-
Added DIP switch bank for board serial number
-
Added JTAG for configuring VME interface chip
-
Mircea added analog input connectors; I added connector and HCT buffer for external trigger (no need for speed)
-
Sent copy of 62.5 MHz clock signal to logic analyzer connector's "clock" inputs, so that we can clock the analyzer instead of letting it freely sample
-
Added "reset" line from 20K (which is VME addressable) to 1K (which is not), just in case it's needed
-
OK, I'm back, after an unbelievably long recovery from CDF commissioning run
-
I have Quartus 2000.09 installed on my desktop PC, and it runs like greased lightning, even under VMware. Compiles FADC APEX 20K200 project in 2.5 minutes! This is even when all of the Quartus project files (including database) reside on Linux disk, served via Samba (which never worked before this release). Fat city!
-
Upon re-reading latest smartmodel documentation for 20K200 chip, I see that I am supposed to install service pack 2000.10.1 or higher, so I installed 2000.10.2. Upon reading release notes for said service pack, I see that I need to look in the simulation/vss subdirectory of the project directory for the .vho and .sdo files that are needed for QuickSim. Now I've got 'em.
-
Updated chip model in both Mentor Graphics and Quartus to 20K200BC356-1X (from -2), because that's the one we were able to get, and it's faster, and we're now at a stage where we're more interested in getting the prototype working than in optimizing the firmware to minimize parts cost; that can be done later.
-
Quartus now reports an fmax of 165 MHz, well above 62.5! Am trying it in QuickSim at nominal frequency.
-
Even though 5 of the 6 channels had "NULL" for a "Model" property for the "data buffer" block on the schematic, QuickSim wanted to initialize all six 20K200 Synopsys models (which it never used to do), so I had to create a "default" design viewpoint, which assigns NULL Model properties to 5/6 instances of the 20K200 chip; else I run out of memory starting QuickSim.
-
Data now pass through the board in QuickSim from input of 1K30 chip all the way to "debug" output of 20K200 chip (about 5.5 usec later)! And no warning messages from the simulator.
-
Implemented VME readout of one data buffer, in 20K200 firmware.
-
Simulated external trigger (successfully)
-
There is a bug in the Synopsys model for the 20K200 chip, such that bi-directional pins are not handled correctly. We should have an update tomorrow. When I do VME reads from a data buffer, they work in Quartus but in QuickSim, the bidir pins remain in high-Z state when addressed.
-
Began checking connection list for unconnected pins
-
This afternoon, Mircea will mail out Gerber files to Twin Hunter for quote on partial assembly of one board; tomorrow, he will mail out final Gerber files to Lugen Industries for production of 3 PCBs, delivery in 10 working days (after film approval). Lugen says $4775 for 5 days, $4580 for 10 days, $4430 for 15 days; at 10-day rate, the marginal cost per board is $810.
-
Continuing to check connection list
-
Found that pins 54,56 on 1K30 chip and pins 140,141 on VME interface chip must be grounded (were n/c), because that is the prescribed configuration for unused "dedicated input" pins. Fixed on schematic. Affects tomorrow's output, but today's (for assembly quote) is not affected.
-
Found that "nCONFIG" pin on 20K200 chip was n/c, but should be connected to nINIT_CONF on EPC2.
-
Oops, I think I installed Quartus service pack "1999.10.2" when I thought it was "2000.10.2"; I really wanted "2000.09.1". I'm not sure that it matters, but it's embarrassing.
-
Found "r224" floating resistor on VME_P1 schematic; it must have been copied and then forgotten. It is of no consequence. Score is now 3-to-1 (Bill vs Mircea).
-
Updated Synopsys model did not fix VME I/O issue; needs further investigation, after xmas. It is fine in Altera's own simulation.
-
Oops, yes it did! I just needed to delete the synopsys compiler output, so that it would re-process the Quartus netlist with the new software. I can now read out the L2 buffer over VME!!
-
Also grounded unused "dedicated input" pins A13, A15, AE14, AF12 on the 20K200 chip.
-
The "reset" line from the 20K200 to the 1K30 appeared not to be connected, but the problem is that I entered the wrong pin assignment in the Quartus software; changed it from "F26" to "U3" in Quartus
-
Checked all pins on 20K200 chip, Mentor connection_list vs Altera .pin file; same for 1K30; same for VME interface
-
Mircea is sitting with his finger on the trigger, waiting for me to give the OK to send the gerber files to Lugen for PCB production
-
Checking configuration pins:
-
data buffer JTAG chain (first channel) looks good: f1(conn) - epc2_1 - epc2_2 - epc2_3 - u235(1k30) - u258(20k200) - f1
-
20k200 FLEX chain: epc2_1, epc2_2, u258 and 1k30 FLEX chain: epc2_3, u235; look good
-
I don't think that the pullup to 3.3 on DATA0 is needed (or recommended by Altera), but I can't see it doing any harm, especially since one always has the option of replacing the resistor with one of larger value
-
VME interface (via JTAG): chip=u257, connector=f7; looks good
-
Note that while this is the same chip we use for VME interface on other UofC boards, and the VME-specific code is the same, I changed all the pin assignments (to make traces easier to route), and made good use of all of the previously unused pins, so we absolutely MUST NOT load the Level1/TrackFitter VME interface firmware into this chip, or it will fry!!
-
Checked diffs in connection_list (today final vs earliest yesterday); all differences are consistent with comments in logbook for last two days.
-
The two most significant things that I think we could have done, given more time to check things, are (1) to think hard about the power sequencing issues when the board is first plugged in and (2) to do a worst-case analysis of clock-vs-data timing at each stage, from FADC output all the way to 20K200 input. Quicksim claims 1K30 to 20K200 is OK, and anyway, there are infinite ways to tinker with timing of FPGA-to-FPGA signals, so I'm not too worried. For 1K30 input, we have the option of installing the (dreaded) programmable delay lines if the timing stinks; there is also the fact that we have two clocks 2ns apart, which gives us four phases between which to choose, if you count inverted clocks, so I sleep OK. For input to ECL/TTL latches, the traces are miniscule, and we're using the schematic straight out of an Intersil FADC application note, so I don't see how we could do any better. So I only lose sleep over the power-up issues, for which Altera chips and ABTE transceivers are designed to be hardy. It's protecting our $100 FADC chip I worry most about. Merry Xmas to all, and to all a good night.
-
Three bare boards arrived. Mircea tested his voltage regulators on one of them, and checked that power distribution was OK.
-
One board back from Hunter, with 2/6 channels (+ VME interface) stuffed. Mark then installed voltage regulators, plus various small components, e.g. capacitors on back of board. Meanwhile, Mircea checked out front-end amplifier circuit on the board on which he had previously checked the voltage regulators. He is happy with amplifiers' response to pulse (pulse generator's mimic of Fe55 pulse shape), but a little less happy if analog mux (for Harold's calibration signal) is in series.
-
We learned (probably should have expected) that 500 MHz FADC chip requires a heat sink and lots of air flow to work properly. We installed heat sink, and aimed a little fan at the chip on the bench.
-
There was an amusing error in the schematic: D and Q interchanged for the ECL/TTL flip-flops that do the first division of the data coming out of the FADC. Fortunately, Mircea has an easy fix: rotate the chip 180 degrees, and only a few lines need to be jumpered. This is further proof that the trivial thing that you don't bother simulating is always where you find the mistake.
-
We stuck in the 500 MHz (!!) oscillator. Saw FADC output 250 MHz clock, as expected! Saw ECL flip-flop output 125 MHz clock, as expected!
-
We put a sine wave into the front end; looked at output of ECL/TTL flip-flops that double-buffer the FADC output; saw bits toggling. Looked at high-order bits, saw their period scale as we changed period of input sine wave.
-
We programmed the Altera chips. Saw output on logic analyzer connector, which records output of 5.5usec delay chain. For this to work, data must be going through both small, fast Altera chip and big Altera chip!
-
After replacing a faulty delay line, we were able to do VME I/O to the board, i.e. DTACK LED blinks when correct slot is addressed; doesn't blink when incorrect slot is addressed.
-
We still need to check clock vs data timing with scope at every stage, to un-greycode the output, to check that even the LSb looks good, to read buffered data over VME, but this is very encouraging for a first day of testing!
-
I tried to implement un-graycoding of FADC data, so that we could see on the logic analyzer a signal changing very slowly. But so far results are unclear. It seems that the low four bits are changing pretty continuously at the FADC output. This is consistent with ~100mV noise, 16ns period, seen with scope. Not sure what this is; we're going from the crate back to the bench to see if we see it there.
-
I implemented a special VME address in the big Altera chip which, when read, returns 0xdeadbeef on the data lines. It works.
-
The noise is most likely coming from the little Altera chip. It goes away when we remove the oscillator. We could also try disabling the little Altera chip. Of course that would not make the board very usable. I think instead I will look into the "slow slew rate" option on the output pins. (Hmmm, that seems to have a dramatic effect on the setup-time requirements at the chip's input; anyway, it appears that the noise may be from the ECL/TTL latches, as significant noise is still present on a board without the Altera chips installed.)
-
In the crate, with the 500MHz osc, low 4 bits are noisy. On the bench, with the 500MHz osc .... On the bench, with no Altera chips, with 500MHz osc, low two bits are noisy. (Need to quantify this with a rate.) On the bench, with no Altera chips, with 70MHz osc, even the LSb is quiet.
-
My first attempt at a gray code decoder was in fact an encoder (oops!). I got the decoder working in the firmware, and saw understandable output on the logic analyzer.
-
Using 70MHz oscillator, I put in a 175kHz triangle wave, and see with the logic analyzer a local minimum every 50 clocks (where each clock corresponds to 8 samples; 50*8*175=70000). Now I want to try it in the VME crate.
-
Hmmmmm, now the hard disk on the logic analyzer died after I moved the analyzer across the room.
-
Changed VME buffer depth from 32*8 samples to 128*8 samples (about 2us), since otherwise the memory was wasted, and it makes a nicer graph; implemented "VME trigger" (do a write to trigger the scope). Got VME readout of scope data working!! See e.g. this graph.
-
I think now the highest priorities are
-
Quantify the noise, at low and high oscillator frequencies, and see whether analog noise at FADC chip input fully explains large scatter in output data.
-
Measure clock-vs-data timing at each stage. Verify that it is within specs (ECL latches) or consistent with what is assumed in the simulation (Altera chips).
-
Search for source of noise; find a way to reduce it.
-
We put the board into the crate with input open (i.e. just the 50 ohm internal termination), 500 MHz osc. Read out via VME. Looks flat, as expected, with mean 145 counts and rms 6.0 counts.
-
Removed first amplifier. Now mean 130 counts, rms 1.0 counts.
-
Reconnected first amplifier, and reduced its gain from 5 to 1. Noise has mean 146 counts, rms 6.2 counts. (This is w/ 500 MHz osc.)
-
Try 70 MHz: mean 144 counts, rms 2.2 counts. Hmmm, what kind of noise scales like sqrt(f)?
-
Mircea changes first amplifier's gain to 2. Mean 144, rms 2.1. Gain has no effect. (This is 70 MHz osc still.)
-
Short inputs together: 2.0 counts rms, i.e. no change.
-
Short both inputs to ground: 0.6 counts rms! Try 500 MHz osc: 2.9 counts rms. So it's much better, but still not great.
-
Ferrite bead between local AGND and global DGND: 3.0 counts rms, i.e. no change. (By the way, the first amplifier was, unintentionally, not powered.)
-
Try ferrite beads on the amplifier power leads: 2.9 counts rms. (This was on only 2 of the 4 power leads, as it turns out.)
-
Harold wants 10 ohm resistors on the power pins of the amplifier: 3.0 counts rms.
-
Ferrite beads on all 4 power leads: hmmm, bad news, ADC always reads 0 now.
-
Install a fresh amplifier, no beads. 4.1 counts rms. Short amplifier inputs to analog ground on the pin; change ferrite beads between AGND and DGND. 2.8 counts rms.
-
Between second amp and FADC, we currently have 22 ohm and (interally) 30 pF; change to 50 ohm and add 27 pF: 1.9 counts rms. Remove input shorts: 1.8 counts. Add long coax cable: 1.9 counts. Replace 27 pF with 100 pF: 1.4 counts.
-
OK, 1.4 counts rms is still not as quiet as we'd like, but we'll live with it for now. By reading out a 1 MHz sine wave, we figured out that I have the time slices (groups of 8) permuted somewhat. For now, I fixed that in the readout software. Now we have a beautiful pulse digitized!
-
Noise is still 1.5 counts rms. The pulse shape seems a bit distorted, though, i.e. the rise and fall times coming out are not what we put in. Needs some study.
-
Now we have 1.5 counts rms noise with better bandwidth, as 100 pF cap went back to 27 pF. See better pulse. The big change was to replace the input traces with a twisted pair. (A shielded twisted pair was worse, about 3 counts.)
-
Changing R94 (from input of 2nd amp to gnd) from 150 ohms to 1K seemed to have no effect: 1.6 counts vs 1.5 counts rms noise.
-
Investigating synchronization problem (startup sometimes works, sometimes fails; we think we understand, are checking): U171 clock output is 2ns ahead of U172, and we find that data are captured correctly but the VME readout order is slightly scrambled. We reset the Altera chips 10 times, and saw the same thing every time. So I think the timing of the input clocks is what matters, not the initial state of the Altera chips. We cycled the power, and it started up the same way (U171 ahead), and we still saw the problem. We cycled the power again, and the clocks reversed (U172 ahead), and it worked.
-
We patched the board so that flipflop A's D is fed from flipflop B's Q instead of from flipflop A's Qbar. Now the two 8nsec clocks (QA and QB), which are 2nsec apart, have a well defined relative phase. (A is 2ns behind B.) With this change, we powered up the board, and had no readout problem. Time will tell whether this is the complete solution. (It wasn't; see below.)
-
There is an identical problem inside the small (1K30) Altera chip: two independent divide-by-two operations. I changed capdiv4x8max.tdf to feed divideq.d from dividep.q. So far, it has worked every power-up. (Again, time will tell.)
-
OK, I think I fixed the overwrite bug at the low end of the VME buffer; need to look at a nice, slow, periodic signal to be sure I got it right. Hmmmm, it's better but still not perfect.
-
Mircea tinkered a bit more with resistor and capacitor values. Bandwidth (3dB) is 75 MHz for signals centered at zero. Noise is about 1 count RMS. Full scale range is +50mV to -160mV. We put a signal with 5ns leading edge, 10ns trailing edge, -150mV amplitude into the board.
-
I moved the VME data buffers to the location specified in CDF 2388, and simplified the VME decoding logic a bit (inside the APEX chip)
-
per channel: APEX $320, FADC $160, regulator $92, EPC2s $60, ACEX $35
-
per board: $5K parts, $700 PCB, $700 assy
-
Parts on hand: 12 DC/DC converters, 12 FADCs, 5 APEX; ordered 2 fast + 2 slow APEX; also have small parts
-
Parts + PCB + assembly cost for two existing prototypes: $17K (predicted $10-15K in July)
-
Cost per board for further production: $6-6.5K (predicted $4-5K in July)
-
Mircea has updated the layout to make input traces shorter. He can put in the remaining changes in a matter of days.
-
Yesterday, I succeeded in counting CDF_CLK, CDF_B0, CDF_L1A, and CDF_L1A in coincidence with each of the four L2 buffer numbers. The board noticed L1A and generated a trigger in response. I have not yet succeeded, though, in recording a calibration pulse via the CDF L1A signal. I need to look with the logic analyzer to understand what is going on.
-
No need for logic analyzer. After two seconds of looking at the Altera simulation, it was obvious to me that the window in which I was recording pulse data did not include the pulse (which was 6us before L1A). I adjusted the delay in del64.tdf, and was then able to record the NIM logic pulse (from the DDG) that normally fires the COT calibration lines. So the L1A signal causes the pulse to be properly recorded in the buffer.
-
Had PCB review last Wednesday. Here is what we decided should be done before we submit the Rev B PCB design.
-
Try wrong crate/fuse combination with unstuffed board; see how fast the fuse blows, with a scope.
-
Make one good attempt to reduce digital noise, e.g. by reducing slew rate; measure setup/hold times.
-
See if we make any noise that interferes with TDC operation.
-
Widen (3x?) traces to DC/DC converter filter capacitors.
-
Spread holes a bit, so that ferrite bead can be fully inserted into PCB.
-
Finish P0 jumpers on prototype.
-
Move capacitor away from oscillator; remove socket; insert oscillator fully into board.
-
Remove VME interface JTAG connector from front panel.
-
Change connector to isolated BNC single-ended (or maybe isolated lemo)
-
Mechanical support for 2.5V, 3.3V supplies (move traces, use nylon screw)
-
Meanwhile, Mircea says he's ready with PCB changes, and what remains at this point is to check everything, think things over.
-
We are making an attempt to understand digital noise on the Rev A prototype, before we call the Rev B PCB design "final."
-
Doing nothing, noise on channel 2 (third from top, first one we tested) is 1.5 counts rms. (Also on channel 1, which is 2nd from top.) Recompiling capdiv4x8max, without changes, and reloading, it still works, and noise doesn't change. (Reality check.) Disabling all data outputs (but not clock output) from 1K30 on channel 1 has no effect on channel 2 noise level. Within a single channel, if I disable half of the 1K30 data outputs (i.e. every other sample), then the noise on that same channel (for the other half of the samples) is 1.24 counts rms. Disabling 3/4 of the outputs brings the noise down to 1.06 counts rms on the remaining 1/4. Enabling the slow slew rate option on all output lines (except clock) seems to make little, if any, difference. Definitely less than 0.1 count difference in the rms. So I think we should forget about slow slew.
-
We did trace analysis on a sample of high-fanout lines, e.g. on-board VME strobe, address, and data signals. The VME strobes look much better when SLOW_SLEW_RATE is enabled on the driver, so we did so. The VME data lines are stable after about 50ns; we should keep this in mind if we decide later to tinker with the VME readout timing (which is firmware programmable). The VME address lines look fine, but have a -1V undershoot, which would go away if we turned on slow slew on those lines on the VME interface chip (we have not yet done so).
-
We now have an ingenious scheme by which the big Altera chip can inject T-zero markers at the FADC input, synchronous with CDF_CLOCK, so that we needn't worry about board clock being independent of CDF clock.
-
We are making a last pass at checking the connection list, so that we can finally mail off the Rev B PCB design. Here are the changes I detected, by staring at the connection list
-
Many components moved left by 0.6"
-
Programmable delay lines are gone
-
FP connectors were renamed from cn_X to X; connector style changed
-
Per-channel LEDs added (Mircea is working on making one member of each pair be Altera-controllable)
-
Schottky diode added at FADC input
-
T-zero reference marker added to FADC input, controllable by Altera
-
Amplifier filter networks adjusted
-
Analog switches removed at FADC input
-
Relative FF phase now deterministic
-
Mircea has added a BCT760 (O/C buffer) for driving LEDs from logic, and run the "test1" Altera lines to the buffers, for controlling one LED on each channel. Connection list changes look good.
-
Checked connection_list for ECL flipflops (now rotated), new clock-divide connections (to make relative phase deterministic), new LEDs and drivers: OK.
-
I thought FADC clock output connections had changed from proto to final, but in fact they had changed from few-days-before-proto to proto; what I checked in December was before Mircea made the following tiny changes:
-
Exchanged DRA with NDRA; DRB with NDRB
-
Changed ECL/TTL FF OE from ECL pulldown to TTL GND
-
First Rev B board has all six channels fully stuffed, except for two FADC voltage references, which were misplaced--will be installled tomorrow. Noise is about 1 count rms on each channel, but varies from sweep to sweep between about 0.8 and 1.4 counts rms. Pulse looks quite clean!
-
There are bursts of noise (just a few counts amplitude) every ~10 usec. We think it is chopping noise. Hmmm...
-
5V current for fully stuffed board is 17.5A, which is right at the limit (as expected).
-
We see pulses sampled correctly on all four channels on which the FADC voltage references are installed. The others will be tried tomorrow.
-
The timing marker resistors still need to be installed.
-
Final three Rev B boards are now assembled. I never assigned serial numbers. Let's call the Rev A board serial #1, the first Rev B board, currently at B0, serial #2, and these three boards #3, #4, and #5.
-
Powered up board #3. Programmed VME interface. See LED blink on VME read.
-
Programmed channel 0. Read 0xdeadbeef from address 0. No ID PROM; this must be the firmware before ID was implemented. Run FADC readout script with no input; see timing markers every 125 counts, see noise 1.5 counts. Quiescent value is about 135 counts, when I expect 192; maybe a wrong resistor value? Plug in pulse generator; looks good.
-
Programmed channel 1. See timing markers every 125 counts. Mean 135 counts, RMS 1.4 counts. See pulse!
-
Programmed channel 2. Mean 133, rms 1.8. See timing markers, but every 250 counts, i.e. they come half as often as on channels 0,1?!?! (Note that this firmware uses VME sysclk, not cdfclk, as the reference marker source; we may not have done trace analysis for sysclk.) See pulse!
-
Programmed channel 3. Mean 134 rms 1.8. See timing markers every 250 counts. See pulse!
-
Programmed channel 4. Mean 134 rms 1.4. See timing markers every 250 counts. See pulse!
-
Programmed channel 5. Mean 134 rms 1.4. See timing markers every 250 counts. See pulse!
-
R82 was marked 12.5K on the schematic and parts list, but should have been 2.5K (as indicated on Mircea's hand-annotated schematic). This resistor sets the FADC reference voltages.
-
Now on board 3, I see 197 counts mean on channel 4. Noise is 1.3 counts rms if I unplug the input and look in a 400ns window between timing markers, 0.9 counts rms if look in a 60ns window between two pulses from the generator. Mean values for the 6 channels range from 191 to 197 counts.
-
Board 4: program VME interface and channel 0. Can read out. See timing markers, but not signal pulse. This was traced to bad connections between board and BNC connectors; fixed by Mark. All 6 channels have quiescent value between 192 and 194 counts. On all 6 channels, we see timing marks, see signal pulses. Channel 0 rms 1.0 counts between timing marks. Other channels similar. Same pattern with sysclk marks twice as fast on channels 0,1 as on channels 2-5.
-
Board 5: program VME interface and channel 0. Can read out, see timing markers. On all 6 channels, we see timing markers and signal pulse. But channel 5 seems to have a bit error: every other sample is wrong by about 13 counts (13 = graycode artifact?). Defective ECL pulldown resistor RE177! Replaced. Now all 6 channels good.
-
Some front-panel adjustments were needed to reduce interference with BNC connectors.
-
Checking that boards are compatible with boards in neighboring slots. Solder side (slot N-1) will require some caution in inserting/removing boards. Board 4: component side OK, solder side OK. Board 3: both sides OK. Board 5: both sides OK.
-
By the way, 001c5cf0 is the checksum of the FADC/GB VME_interface.pof, which uses different pin assignments from the L1/TF program.
-
Put boards 3,4,5 in b0puls00 with board 2 to bake in.
-
Set board ID switches on boards 3,4,5. Checked response to 8 kHz sine wave with flashing LED for all 18 channels.
-
Set board ID switches on board 2. Mark installed timing-marker resistors on board 2. Mark made a front panel for board 2 that looks like the front panels for boards 3,4,5. Re-checked board with signal pulses in shop.
-
Decreased _dtack delay by 160 nsec on board 5. Before the change, I saw a _dtack every 500 nsec when reading out with Run_Control. Now I see a _dtack every 340 nsec. (This is in the COT pulser crate.)
-
An incomplete to-do list:
-
Change 10K200 firmware to make samples readout in time order (remove permutation within groups of 8 samples)
-
Check power sequencing/protection, both analog and digital
-
Try out "external trigger" input
-
Can we model timing of ECL latches, ECL/TTL converters?
-
Need to model full range of clock vs data timing at each stage
