-
Skip to most recent entry
-
Updated: $Date: 2002/06/17 21:53:29 $ (UTC)
-
Log book for SVT GhostBuster board
-
Mircea has assembled pieces of TF and FADC schematics to make a first-draft GhostBuster schematic
-
He already has started working on the layout
-
I am starting to flesh out the schematic
-
Mircea has most of one channel placed, thinks we can turn around the design in a week or so, once everything is connected
-
I started a "gb" Quartus project, and assigned most of the 279 (!) available I/O pins
-
We copied L1/L2 interface schematic from PreFRED; copied FRAM from Track Fitter
-
Want to make "spare" bus wide enough for a whole SVT word, plus control signals; want to add LED outputs
-
Added all nets I could think of to Quartus project; followed them through to Mentor Graphics schematic. A few J2 backplane connections still need to be made. But that should be most of the connections.
-
Cleaned up pin assignments a bit for din, dout, fram
-
Added connections for run/error LEDs; added SVT-specific P2 signals
-
Moved VMEDS (CTRL(1)) from pin P3 to pin AE14 on the 20K200 chip, so that one of the two dedicated clock pins is available for PLL use.
-
Simulated data into input FIFO, passing through to output; so far there is no parsing of the data.
-
For a moment, I was worried that the VME I/O was not working. It turns out that I had forgotten the factor of 4 between byte and word addresses, in the program that generates the test data!
-
I am writing the bunch counter number and the L2 buffer number into a FIFO every L1A. I will then hold the input data, and read one event's input per word read from the L1A FIFO, sticking the result into a memory buffer whose location is known before the data arrive. This should allow me (a) to read diagnostic data into the data stream and (b) to implement the flow-control feature of the XTRP emulator.
-
In terms of releasing the prototype, I don't think the detailed event handling logic is necessary. Instead, I want to make sure that I drive/watch connector signals, not internal signals, and that I test every connection.
-
Changed simulation stimuli so that external signals are driven/watched, as much as possible. I confess that I bypassed the LVDS receivers/drivers, out of convenience.
-
Checked connection list. Found some booboos:
-
A13, A15, AF12, P3 are unused dedicated input (or clock) pins, and should have been grounded; fixed
-
TDO from second EPC2 should go to TDI on BGA, but was dangling; fixed
-
_framrp was removed from schematic (long ago), but still has a pin assignment in Altera; I leave it alone for now
-
Got prototype board, stuffed!
-
Plug in L1 test crate (only 5V power on): green LED lights
-
Program VME interface: LED blinks when slot is addressed, doesn't blink when other slots are addressed
-
Detect channel 0 hardware (EPC2, EPC2, 20K200) via JTAG
-
Program channel 0: 3/4 LEDs go off (should correspond to input hold, input DS, output DS, but I haven't checked yet); read 0xdeadbeef from address 0 (hooray!) via VME
-
Unable to detect channel 1 via JTAG (bummer); need to debug
-
Detect channel 2 via JTAG; program; 3/4 LEDs off
-
Move board to SVT test crate
-
When I send a given file of data words (beginning 601c65 601c66 248747 601c67) from HF to TF, I see that in the TF ispy. (There are some things I don't understand about using TF as an HF data sink, with the software I am currently using to talk with the HF and TF, but these are of little concern, because I need to switch to using the svtvme library instead of this prehistoric software that I have been using to test boards in Chicago.) When I send the same data from HF to GB to TF, I see the expected data, but OR'ed with 0x100000. This is as expected from the current firmware, which (as a debug feature) was using bit 20 to latch some FIFO information. I'll fix that. (The current GB program, just for testing in QuickSim, merely reads the input FIFO and writes what it reads to the output connector.) So far so good.
-
Use svtvme library to send test data from HF directly to TF
-
Insert GB in middle and check still OK (except bit 20)
-
Fix bit 20 in firmware; check OK
-
Look through schematics, etc., and try to test as many data paths as possible through board
-
Debug problem with channel 1
-
We are running svtvme library (from Python) directly from B0, instead of making the effort to make it run locally, though this should be fairly easy to do later
-
We wrote a simple program, ~ashmansk/vst/hftotf.py, to send random EE words from HF to TF; it works
-
Uhoh, now we can't detect the JTAG chain on channel 0 or 1, even though we previously programmed channel 0. Need to figure this out soon!
-
We reprogrammed channel 2 of GB so that it no longer modifies bit 20 of the data stream. We then ran hftotf with HF output to GB input and GB output to TF input. We sent bursts of up to 4000 words, different each time, successfully. 10K words didn't work, but I think this is because I haven't programmed the "hold" logic yet in the GB.
-
We added a few words to the end of the data to exercise the EP and EE bits, too, and they are transmitted faithfully.
-
We connected all 4 LEDs on each channel to a particular VME address, as a test. We see that all 4 LEDs on channel 0 blink when this VME address is written, so they're all connected to the chip. Need to look at the schematic to figure out the intended usage (e.g. which ones have monostables, gates in front of them, etc.)
-
Mircea tracked down the "can't configure" problem! It was not a mistake, but rather an unintended consequence of a deliberate action! I made chip (0,1,2) able to control the JTAG port on chip (1,2,0), and when testing this in QuickSim, I made these lines real outputs, instead of tri-stating them. Now I've changed them to inputs, and everything is fine. Much later, we can try using this feature to configure the chips via VME commands.
-
After configuring all 3 channels, we repeated HF-GB-TF data-flow test, which succeeds for all three channels. Now we want to implement the "hold" mechanism ....
-
We implemented hold mechanism. After a comedy of strange events (prototype HF spontaneously lost its configuration; forgot to reload (volatile) GB program after power cycle; forgot to sleep between sending and checking data), we got HF-GB-TF to process bursts of 50K words, at least 25 times in a row, without errors. Hooray!
-
It turns out that I connected the Qbar output instead of the Q output of the HCT123 (monostable) for the input DS LED. Oddly enough, I connected the other 3/4 LEDs correctly. Now, a lot of people would have called it silly to go through the Altera chip for LED control, since it's such a trivial thing. But I've screwed up such trivial things before. Fortunately, it was simple to make a counter inside the Altera chip put out a pulse every millisecond, to keep the monostable firing, and hence turn it off! With this change, all 4 LEDs work for channel 0.
-
Using 32-bit "control" register in each chip (exact use TBD), we checked all 32 VME data bits to all 3 chips; OK. Using a special register to read back previous address value on data lines, we checked VME address lines 2-23, i.e. all of the lines used internally by the board, to all three chips; OK.
-
We have HF-GB0-GB1-GB2-TF cabled, partly to test LEDs, partly to test data flow. Hold LEDs look good, but I don't understand what DS LEDs are doing on channels 1,2. Perhaps monostable RC values are not right on these channels? Ran over 100 passes x 50K words, OK. (On an earlier run, we saw one or two failures scroll off the screen, but were not able to reproduce them in order to debug them.)
-
What we want to implement in firmware:
-
Ultimately, of course, the ghostbusting functionality, but first let's clean up the kludges in crate b0svt07
-
A mode to replace the XTRP emulator (modified HF), by writing out a correct EE word (with bunch ID, L2 buffer ID) every L1A, with bunch ID offset programmable.
-
A mode to copy input to output, checking BC against internal calculation. (Replaces "xtrpcheckbc" Merger.)
-
A mode to play test data read from FRAM, one event per L1A, with correct BC and L2B added. (Replaces HF OSPY and "xtrpemu" Merger.)
-
Pass data through from input to output, but capture it into a L2 buffer for DAQ readout. (Allows e.g. bit-for-bit validation of Hit Finder simulator by reading out one HF directly into data stream.)
-
Apply beam position offset to SVT track list
-
Mircea recently pointed out that the FRAM VCC line was not connected, because we had copied from the Track Fitter, whose name for +3.3V was different, and we forgot to change that
-
Mark put 3 tiny little jumpers on GB #2. I checked that I am able to read ID words (manufacturer ID, chip ID), and I successfully programmed the first 4 words of each of the 3 memories
-
We are now preparing to assemble the final two GBs, which will give us a total of four boards
-
GB boards #3 and #4 are in hand and fully assembled. We loaded the VME interface and current (minimal) firmware on board #3 and were able to read ID PROM and do VME I/O to all 3 APEX chips. We'll do more sophisticated tests next month, when we have more realistic firmware. Ditto for board #4.
-
Checked that I can send a sequence of SVT end-event words through both GB #3 and GB #4 (all three channels), using HF as source and Merger as sink.
-
An incomplete to-do list:
-
Check updates to connection list when Mircea repackages
-
Double-check EPC2/JTAG connections
-
Finish checking conninfo.dat printout
-
Check that things with pullup/down are BIDIR (and that bussed things are BIDIR)