Have Quartus II simulation reading both MBus input and SVT input and writing to SVT output; now working on moving to QuickSim

Needed to set "write_smartmodels_vho=ON" in quartus.ini, enable "VSS" EDIF generation, set "flatten buses", remove lines beginning with "-- LUT" (is this an option?)

Hmmmm... I think there may be a decent way to talk to this board, to get around the no-VME problem: write special command words in the SVT input. We could interpet words 0x5XXXXX (EE is set, EP is not set, and the highest data bit is set) as commands. Would this work only when HALT is asserted? What happens in a crate with no CDF J2 signals?

Test setup: MMB + L2/Track board in straight-through slot; two SVT Merger boards in other slots (or one GB if we get around to writing the firmware); also CDF TestClk module. Use one Merger to write commands into the MMB; other Merger to write test data to the L2/Track board and receive the MMB output. If the TestClk module isn't available, it may be possible to work around this by writing commands to simulate the J2 backplane signals.

We did the final checks this past week. Simulated data flow from backplane into APEX in QuickSim.

PCB will ship this Friday. Assembly costs from Hunter: $300=setup, $1280=stencil, $574=assemble 1, $674=assemble 2. This is 2 week assy. So we can have 2 stuffed board around December 26 for $2254.

Programmed chip to make the LEDs blink in sequence Red, Yellow, Green with a 1 second period--works

That was with internal clock. I can also make an LED blink with 1 second period by dividing CDF clock--works. I can also light an LED in response to the CDF recover signal--works.

Programmed chip to write the output of a counter to the SVT output connector. Sucessfully received 4K successive words into Merger board's input FIFO and read over VME.

Earlier this week, I succeeded in sending SVT words in with a HF and reading SVT words out with a Merger. (A temporary problem was that I was not correctly telling the TestClk to send CDF_RECOVER, so the initial state of the FIFOs was bogus.)

Then I made a little microcode that allows me to do both data loopback test and set/read control registers internal to the board, by writing/reading SVT words. I checked this with a write/read test, by reading the DIP switches, and by making the LEDs count under software (not firmware) control.

I also assigned various read/write registers to Magic Bus signals, so that by talking with the MMB's registers, I could talk with the TrackList board in a straight-through J3 slot.

With no board plugged in, read 0 for all backplane signals, except ev_loaded and done_out, which are 1. Plugged in TrackList, same story. Issue MB reset (and perhaps other?), see dstrobe light blink on tracklist.

After some hacking, I issue start load, see doneout change, send an SVT input event to the front, see ev_loaded and bossreq change, assert bossgrin, see boss and bossreq change, then see dstrobes, issue ddones in response, read the MB address and data for each word (see expected patterns of 5's, a's, 0's, f's, etc.), see doneout and bossgrout go high, then send another svt event, and see ev_loaded change to the new event's buffer number. Not a bad day's work!

I see that the board, as I was told by Jane, sometimes sends way too many Magic Bus words. I guess my next job is to track this down ....