HF Luminosity Logbook

Spying via Wisconsin connector

For the mapping between TPGs and pins on the HLX look here

Click here to go up to the page above.

Notes on RAM enable

To enable Rams go into RAMS menu

set the fiber number (remember that each fiber drives 3 QIEs)
generate 3 0 0 (this sets all the QIEs for this fiber to have mant=0 and exp=0, and sets up the structure so that it looks like real data with capids, etc)
fwrite 4 31 3 31 3 31 3 (this sets the data for the 3 QIEs for the fiber for LHC bucket 4 to 31/3 mant/exp)
control 1 0 (this turns on using the rams, but not in repeat mode, see below)

Then go into TTC mode and turn on broadcasting once per orbit of the test enable command, 0x20:

vi 1 1 20

Careful!!! The HTR will do the peak finding, and if you want to debug, this might confuse things. You can turn this off in the XILINX (XFPGA) menu via:

SETCSRBIT 9

HLX cookbook:

Emulator at Maryland:

Use firmware in c:\cms\firmware\fewithgol\orbits\fee1. Note that this firmware doesn't send any idles, so after a powerup of the HTR you will have to push the reset button on the emulator box to synchronize. Then you have to check the TLK2501's to synchronize them (see below). Anyway, this firmware will put all mantissa's to 0, and all exponents to 0 except once in the orbit it will set the exponent of qie0 to 3. This emulator has a 1:8 fanout of the optical signals, so you should see qie0 set to mant=0, exp=3 once per orbit on each fiber.

On HTR side:

Make sure you have the right HTR firmware downloaded!!!!
Make sure that all of the deserializers are aligned. Do this in the XILINX menu, use the DELAY command (DELAY 2 will automatically fix things). After you fix this you can go into the SPY menu and issue the ALL 1 command. You should see the data aligned to within 1 bucket. Remember though that the DELAY fix works on 40MHz buckets, while the SPY menu looks at the 80MHz data fifo's. If the SPY/ALL 1 command shows that there is an offset of no more than 1 per fiber and the DELAY 2 command was already issued, this is ok - it means that the firmware code that puts 2 successive 80MHz data into a single 40MHz data has done the right thing.

On the HLX side:

For the HLX, use firmware 700F or higher.
Be sure that you are getting a "BC0" signal in the HLX. The early (fall 05) versions of the firmware used the TTC strobe as BC0. Version 0xF or higher uses a downloadable TTC pattern (see register 0x44). The firmware will match this pattern to a TTC broadcast pattern and issue a pulse which will be used for "BC0". Note that what you download is an 8-bit pattern, but only 4 bits are active (7,6,5,3). Also note that you should check the appropriate register that counts the different patterns (0x20-0x2F). A common setting is to write 0x20 to this register (register 0x44) and then set the TTCvi to broadcast this (which you can do in the HTR TTC menu by issing the command "vi"). To check that it’s working, go into the XILINX menu and issue the “TTC” command. This will printout a counter for each of the 16 various 4-bit TTC codes that the HTR will use. Verify that the value for code 0x2 (3^rd one from the top) is changing, indicating that the 0x20 is being sent once per orbit.
In the HLX menu, type "sumspy". It will printout a spy collection of the sums as they arrive. The spy fifo is not very deep so it will not capture an entire orbit - only a fraction of it (511 to be exact). What you should see for most buckets is this: 328 0 sum 0/1/2/3: 00 24 00 00. The 1st number is the fifo read, the 2nd number is 0 unless the fifo is empty, so you should only see a 1 there on the last read. Then comes the sums. The first sum (00 here) is number of channels that are disabled. The 2nd sum is number of channels below the first threshold. It's 24 because each channel has a 00 for the mantissa and 0 for the exponent except on the "special bucket". To capture the "special bucket", you will have to look for the words "yup" at the end of the printout. If you find it, that means that it found the particular bucket with a nonzero sum and it should look like this: sum0/1/2/3: 00 16 00 08 if all is well.
To do the histogramming:

setbc0 20

This tells the HLX to look at the TTC broadcast command 0x20 to interpret as BC0. You need to setup the TTC to do this:

In TTC menu issue vi 1 1 20

start

Sets the HLX in START state

hmode

Tells the firmware to fill the histograms. It'll stop after 1024 orbits.

status

You should see the histogram done bit set. If not, probably the TTC, or maybe the data is crap

hmode

Tells the firmware to disable filling.
MODE (CSR, see above). That will start the histogramming. It will stop after 1024 orbits. Then you have to clear HMODE and put the HLX in STOP state

to read:

manually: you write the bin number to address 0x50, then read the 16 bit bin contents from 0x50,0x54,0x58,0x60 for histograms 0,1,2,3
issue hread command (can do hread 1 and see the 4 histograms on root display)

For ethernet operation:

Destination MAC and IP numbers

/sbin/ifconfig will tell you what is on your machine. You have to set these for the HLX for the UDP packets to arrive via:

DESTMAC 1 00E0 8125 F4AE (this sets the destination MAC address to 00:E0:81:25:F4:AE, the machine at Princeton called quasar)
IPDEST 1 192.168.1.100 (this sets the destination IP address to 192.168.1.100, the machine at Princeton called quasar)

Source MAC and IP numbers

SRCMAC 2 (this sets the source MAC to a legitimate default, 02:40:10:AA:BB:CC)
IPSOURCE 1 192.168.1.101 (also legitimate IP source address)

Be sure to set the histogram number you want to send:

HSEL 1 3 (tells it that we wish to send histogram 3, the one with the highest threshold level)

Each "ESEND" command will send 1 of 7 packets that make up the histogram as selected via HSEL.

Addressing:

wire [15:0] histogram_output_addr

driven by transmitter_bundle, controls clocking of data into transmitter's block ram buffer. bits are:
lower 12 bits [11:0] are directly mapped to the histogram bin number
bits [14:12] are the histogram number (there are 5 histograms: 0-3 for occupancy, 4 for sumET)

15-Feb-06 (drew)

Test ethernet output: selected histogram 1 (of 5, this is the one that will have some non-zero data in it) and tried to send the first packet ("esend" in the HLX menu). Here is the result:

ethTransmit triggers the transmission (issued over VME). J5 is the histogram_output_addr[15:0] lines. The 1000 is right, that's hex and it means bit 12 is asserted, which means histogram 1 and packet 0. What happens here is that the transmission is not seen by tcpdump and the light on the switch doesn't blink. Notice that "slavestate" is stuck in 1. Here's the relevant code from ethernet_packet_manager:

  wire slave_start_cond;

  assign slave_start_cond=(slave_state==SLAVE_IDLE && (wb_strobe && wb_cycle) && global_enable);

  always @(posedge wb_clk)

    case (slave_state)

    SLAVE_IDLE : if (slave_start_cond) slave_state<=SLAVE_LATCH;

                 else slave_state<=SLAVE_IDLE;

    SLAVE_LATCH : slave_state <= SLAVE_REPORT;

    SLAVE_REPORT : slave_state <= SLAVE_IDLE;

    default : slave_state <= SLAVE_IDLE;

  endcase

So it looks like (wb_strobe && wb_cycle) is not being satisfied. At least not on the first try!

Drew Baden - Feb 2006
Return to Maryland HCAL CMS page.