V1495 notes¶
Loading the a3818 kernel module¶
The a3818 kernel module does not seem to load on boot, even though the CAEN installation procedure should take care of that. My guess is that kernel updates break the autoload.
[kordosky@lariat-daq01 ~]$ modprobe a3818 FATAL: Module a3818 not found.
Someone deleted the module? Reinstall it.
[kordosky@lariat-daq01 A3818Drv-1.4]$ make make -C /lib/modules/2.6.32-358.23.2.el6.x86_64/build M=/home/nfs/kordosky/A3818Drv-1.4 LDDINCDIR=/home/nfs/kordosky/A3818Drv-1.4/include modules make[1]: Entering directory `/usr/src/kernels/2.6.32-358.23.2.el6.x86_64' CC [M] /home/nfs/kordosky/A3818Drv-1.4/src/a3818.o Building modules, stage 2. MODPOST 1 modules CC /home/nfs/kordosky/A3818Drv-1.4/src/a3818.mod.o LD [M] /home/nfs/kordosky/A3818Drv-1.4/src/a3818.ko.unsigned NO SIGN [M] /home/nfs/kordosky/A3818Drv-1.4/src/a3818.ko make[1]: Leaving directory `/usr/src/kernels/2.6.32-358.23.2.el6.x86_64' [kordosky@lariat-daq01 A3818Drv-1.4]$ ksu Authenticated kordosky@FNAL.GOV Account root: authorization for kordosky@FNAL.GOV successful Changing uid to root (0) [root@lariat-daq01 A3818Drv-1.4]# make install installing a3818 driver.. please wait installation done [kordosky@lariat-daq01 A3818Drv-1.4]$ lsmod | grep a3818 a3818 11091 0
This created /etc/modules with one entry a3818 in it. I think this should make the module load on boot. At least, it does on my ubuntu machine.
Firmware versions, board numbers and addresses¶
A3818 = 0.04
V2718 = 2.13 link=1 boardnumber = 16
A2719 = 1.03 link=1 boardnumber = 16
V1495 = 01.00 link=1 boardnumber =16 BaseAddress=0x04800000
I can also read the board info off the 1495, but it's not very interesting.
A reminder¶
Matt reminds me that the readout registers for input A are only implemented for channels 16-31, rather than what one might guess 0-15, for 16 channels. I can't recall why he did that...
When do we readout?¶
The 1495 sits there dumbly counting along. When should it be read out? First, we have a record of begin spill and end spill which are used (in NIM) to make a spill gate. That's the first bit input to the 1495 since it will be a vital ingredient in any beam trigger. So, the 1495 could look at that bit and, when it goes high, reset itself (assuming that the start spill is a bit early), then when the bit goes low "request readout". Two issues with this: first, there is a register and front panel LEMO which can supply the reset pulse, so that logic is already taken care of and we should use that input. Second, the clearest way for the 1495 to request readout would seem to be to assert an IRQ on the VME bus. That would be transmitted all the way to the PCI card, which can wait on interrupts. Unfortunately, it's not clear that the 1495 can do that. The functionality would be in the VME FPGA and there is nothing about asserting IRQs documented in the 1495 manual. We have a question in to CAEN about this.
So, what to do? The V2718 has two front panel LEMO inputs. These inputs can feed into the START of either or both of two pulse generators on the board. The pulse generators can provide pulses with timebase units of 26ns, 1.6us, 400us, and 104ms. You can select the width of the pulse (8-bits = 256) and period (8-bits) and number of pulses (which, if set to zero, is infinite). So, we could have the end of spill signal start a 104ms * 2^8 = 26.2sec long pulse. This is, essentially, a latch. That pulse can be connected to one of the lemo outputs on the V2718 for monitoring purposes and, critically, can be sent to an output register which is readable over the PCI link. The computer program sits there and polls that latch register every few ms. When it goes high, the computer reads out the 1495, the 1495 could then be reset, and then the program resets the latch. Ready to take data again.
Notes- This scheme is basically a CAMAC LOOK-AT-ME approach.
- it's not clear what happens if you set the period to zero. My hope is that it will do the thing you'd think it should do: generate a continuous pulse. If so, we have a real latch, not just a very long pulse.
- This scheme could easily be used to readout any 1740's connected to the same computer. If the 1740s were connected to another computer the "let's readout" signal will have to be transmitted somehow. I think this is artdaq's job? Note, this doesn't have to be a fast ns level signal and the other computers would need to reply with a "done" before any resets are issued.
- There is no reason why this scheme cannot be generalized to take other types of triggers, such as from an LED or cosmics. Those would be other trigger patterns, not requiring the beam spill bit. In addition to a spill gate we'd have LI and cosmic gates which would be generated by the computer asking the V2718 to send a pulse out on one of its other LEMOs. Those pulses would go to a gate-delay generator and generate a readout window. In principle, if we want this easily programmable then the 1495 could act as a gate generator. Might be easier to just use NIM though.
- How would the computer know to send out an LI or COSMIC gate signal vs. waiting for beam? Hmmm. Perhaps it has states like WAITBEAM, LI, COSMIC and it just progresses?
- One of the V2718 LEMO outputs could be used for a common reset of all modules. It would be sent to a logic fan out, then to all the modules. This could be used, e.g., to restart clocks. The computer can fire this via software, but the timing of the signal is all hardware.
Issue with V1495Driver.reset()¶
This is an account of debugging on July 22, 2014.
The board was not issuing triggers. Prior to that, I'd run Reset1495, which does this:
int main(int argc, char *argv[])
{
V1495Configuration trigger_conf("/home/nfs/kordosky/lariat-online/daq/config/V1495.config");
trigger_conf.print();
const LariatConfiguration* lariat=0;
V1495Driver trigger(lariat,&trigger_conf);
trigger.reloadFirmware();
trigger.reset();
trigger.configureCommon();
return 0;
}
The configureCommon() function call was throwing a VME bus error when I tried to read the control register. I've since experimentally determined that if I wait for 2 seconds following the reloadFirmware() call the problem goes away. Presumably I was catching the board while it was being reflashed. I've asked CAEN about this. Seems like a long time.
The trigger.reset() call does this:
void V1495Driver::reset(){
uint32_t cregval = readRegister(config->controlReg); // our user defined control register
std::cout<<"V1495Driver::reset(): control Register Reads: "<<std::hex<<cregval<<std::dec<<std::endl;
// I believe this will issue a reset without changing the
// channel pulse width or trigger width
// first we set a 0 on bit zero
writeRegister(config->controlReg,cregval&0xFFFFFFFE);
// then we set a 1 on bit zero
writeRegister(config->controlReg,cregval|0x00000001);
}
After some additional work, I now understand how the reset works. It's a little subtle:
- This is how the reset inputs are defined in VHDL.
reset_ctrlis writable via the VME bus.reset_extis connected to registerD(2)which maps to the lowest LEMO connector. CRUCIAL: When using those LEMOS as inputs, the logic is inverted. See Trigger inputs for more details.reset_inis just the logicalandof the two reset signals.
alias reset_ctrl : std_logic is REG_RW1(0);
reset_ext <= D(2);
reset_in <= reset_ctrl and reset_ext;
- The
reset_intsignal is sent to most of the firmware modules:
i_bitcounter0 : bitcounter
port map(
LCLK => clk100,
reset => reset_in,
bitIn => raw_input(0),
outWidth => outWidth_in,
bitcount => REG_R1,
outPulse => sync_input(0)
);
- This is an example of how the reset signal is utilized to reset the number of counts on an input channel:
-- This process counts the rising edges of the bitIn input and
-- stores the number in the resgister r_bitcount
bitIn_counter : process(reset, LCLK)
BEGIN
if (reset = '0') then
r_bitcount <= (others => '0');
elsif (LCLK'event and LCLK = '1') then
if (bitpulse = '1') then
r_bitcount <= r_bitcount + 1;
end if;
end if;
END process bitIn_counter;
Summary: In order to assert a reset one needs reset a.k.a. reset_in <== reset_ctrl and reset_ext to go to zero. Holding it at zero maintains the reset. We can assert a reset in two ways. First, a write of 0 to REG_RW1(0). Second, by holding reset_ext at NIM logical low. This is because the LEMO inputs to the board have inverted logic. This resolves a longstanding confusion I had about the board.
V1495 Register Table -- Run 1¶
REGISTER ADDRESS PURPOSE ======== ======= ======= REG_R1 x1030 Ch. 0 counts REG_R2 x1034 Ch. 1 counts REG_R3 x1038 Ch. 2 counts REG_R4 x103C Ch. 3 counts REG_R5 x1040 Ch. 4 counts REG_R6 x1044 Ch. 5 counts REG_R7 x1048 Ch. 6 counts REG_R8 x104C Ch. 7 counts REG_R9 x1050 Ch. 8 counts REG_R10 x1054 Ch. 9 counts REG_R11 x1058 Ch. 10 counts REG_R12 x105C Ch. 11 counts REG_R13 x1060 Ch. 12 counts REG_R14 x1064 Ch. 13 counts REG_R15 x1068 Ch. 14 counts REG_R16 x106C Ch. 15 counts REG_R17 x1070 Good pattern 1 counts REG_R18 x1074 Good pattern 2 counts REG_R19 x1078 Good pattern 3 counts REG_R20 x107C Good pattern 4 counts REG_R21 x1080 Good pattern 5 counts REG_R22 x1084 Good pattern 6 counts REG_R23 x1088 Good pattern 7 counts REG_R24 x108C Good pattern 8 counts REG_R25 x1090 Good pattern 9 counts REG_R26 x1094 Good pattern 10 counts REG_R27 x1098 Good pattern 11 counts REG_R28 x109C Good pattern 12 counts REG_R29 x10A0 Good pattern 13 counts REG_R30 x10A4 Good pattern 14 counts REG_R31 x10A8 Good pattern 15 counts REG_R32 x10AC Good pattern 16 counts REG_R33 x10B0 Bad pattern 1 counts REG_R34 x10B4 Bad pattern 2 counts REG_R35 x10B8 Bad pattern 3 counts REG_R36 x10BC Bad pattern 4 counts REG_R37 x10C0 Bad pattern 5 counts REG_R38 x10C4 Bad pattern 6 counts REG_R39 x10C8 Bad pattern 7 counts REG_R40 x10CC Bad pattern 8 counts REG_R41 x10D0 Bad pattern 9 counts REG_R42 x10D4 Bad pattern 10 counts REG_R43 x10D8 Bad pattern 11 counts REG_R44 x10DC Bad pattern 12 counts REG_R45 x10E0 Bad pattern 13 counts REG_R46 x10E4 Bad pattern 14 counts REG_R47 x10E8 Bad pattern 15 counts REG_R48 x10EC Bad pattern 16 counts REG_R49 x1190 FIFO Number of entries REG_R50 x1194 Pattern FIFO readout REG_R51 x1198 Timestamp FIFO readout REG_RW1 x1100 Control Register REG_RW2 x1104 Good pattern & bitmask 1 REG_RW3 x1108 Good pattern & bitmask 2 REG_RW4 x110C Good pattern & bitmask 3 REG_RW5 x1110 Good pattern & bitmask 4 REG_RW6 x1114 Good pattern & bitmask 5 REG_RW7 x1118 Good pattern & bitmask 6 REG_RW8 x111C Good pattern & bitmask 7 REG_RW9 x1120 Good pattern & bitmask 8 REG_RW10 x1124 Good pattern & bitmask 9 REG_RW11 x1128 Good pattern & bitmask 10 REG_RW12 x112C Good pattern & bitmask 11 REG_RW13 x1130 Good pattern & bitmask 12 REG_RW14 x1134 Good pattern & bitmask 13 REG_RW15 x1138 Good pattern & bitmask 14 REG_RW16 x113C Good pattern & bitmask 15 REG_RW17 x1140 Good pattern & bitmask 16 REG_RW18 x1144 Bad pattern & bitmask 1 REG_RW19 x1148 Bad pattern & bitmask 2 REG_RW20 x114C Bad pattern & bitmask 3 REG_RW21 x1150 Bad pattern & bitmask 4 REG_RW22 x1154 Bad pattern & bitmask 5 REG_RW23 x1158 Bad pattern & bitmask 6 REG_RW24 x115C Bad pattern & bitmask 7 REG_RW25 x1160 Bad pattern & bitmask 8 REG_RW26 x1164 Bad pattern & bitmask 9 REG_RW27 x1168 Bad pattern & bitmask 10 REG_RW28 x116C Bad pattern & bitmask 11 REG_RW29 x1170 Bad pattern & bitmask 12 REG_RW30 x1174 Bad pattern & bitmask 13 REG_RW31 x1178 Bad pattern & bitmask 14 REG_RW32 x117C Bad pattern & bitmask 15 REG_RW33 x1180 Bad pattern & bitmask 16 REG_RW34 x1184 Delay time REG_RW35 x1188 Veto time REG_RW36 x118C Pattern Disabling Masks
V1495 Register Table -- Run 2¶
REGISTER ADDRESS PURPOSE ======== ======= ======= REG_R0 x1100 Ch. 0 counts REG_R1 x1104 Ch. 1 counts REG_R2 x1108 Ch. 2 counts REG_R3 x110C Ch. 3 counts REG_R4 x1110 Ch. 4 counts REG_R5 x1114 Ch. 5 counts REG_R6 x1118 Ch. 6 counts REG_R7 x111C Ch. 7 counts REG_R8 x1120 Ch. 8 counts REG_R9 x1124 Ch. 9 counts REG_R10 x1128 Ch. 10 counts REG_R11 x112C Ch. 11 counts REG_R12 x1130 Ch. 12 counts REG_R13 x1134 Ch. 13 counts REG_R14 x1138 Ch. 14 counts REG_R15 x113C Ch. 15 counts REG_R16 x1140 Ch. 16 counts REG_R17 x1144 Ch. 17 counts REG_R18 x1148 Ch. 18 counts REG_R19 x114C Ch. 19 counts REG_R20 x1150 Ch. 20 counts REG_R21 x1154 Ch. 21 counts REG_R22 x1158 Ch. 22 counts REG_R23 x115C Ch. 23 counts REG_R24 x1160 Ch. 24 counts REG_R25 x1164 Ch. 25 counts REG_R26 x1168 Ch. 26 counts REG_R27 x116C Ch. 27 counts REG_R28 x1170 Ch. 28 counts REG_R29 x1174 Ch. 29 counts REG_R30 x1178 Ch. 30 counts REG_R31 x117C Ch. 31 counts REG_R32 x1200 Good pattern 1 counts REG_R33 x1204 Good pattern 2 counts REG_R34 x1208 Good pattern 3 counts REG_R35 x120C Good pattern 4 counts REG_R36 x1210 Good pattern 5 counts REG_R37 x1214 Good pattern 6 counts REG_R38 x1218 Good pattern 7 counts REG_R39 x121C Good pattern 8 counts REG_R40 x1220 Good pattern 9 counts REG_R41 x1224 Good pattern 10 counts REG_R42 x1228 Good pattern 11 counts REG_R43 x122C Good pattern 12 counts REG_R44 x1230 Good pattern 13 counts REG_R45 x1234 Good pattern 14 counts REG_R46 x1238 Good pattern 15 counts REG_R47 x123C Good pattern 16 counts REG_R48 x1300 Bad pattern 1 counts REG_R49 x1304 Bad pattern 2 counts REG_R50 x1308 Bad pattern 3 counts REG_R51 x130C Bad pattern 4 counts REG_R52 x1310 Bad pattern 5 counts REG_R53 x1314 Bad pattern 6 counts REG_R54 x1318 Bad pattern 7 counts REG_R55 x131C Bad pattern 8 counts REG_R56 x1320 Bad pattern 9 counts REG_R57 x1324 Bad pattern 10 counts REG_R58 x1328 Bad pattern 11 counts REG_R59 x132C Bad pattern 12 counts REG_R60 x1330 Bad pattern 13 counts REG_R61 x1334 Bad pattern 14 counts REG_R62 x1338 Bad pattern 15 counts REG_R63 x133C Bad pattern 16 counts REG_R64 x1010 FIFO Number of entries REG_R65 x1014 Pattern FIFO readout REG_R66 x1018 Timestamp FIFO readout REG_R67 x1020 Version register REG_RW0 x1000 Control Register REG_RW1 x1400 Good pattern 1 REG_RW2 x1404 Good pattern 2 REG_RW3 x1408 Good pattern 3 REG_RW4 x140C Good pattern 4 REG_RW5 x1410 Good pattern 5 REG_RW6 x1414 Good pattern 6 REG_RW7 x1418 Good pattern 7 REG_RW8 x141C Good pattern 8 REG_RW9 x1420 Good pattern 9 REG_RW10 x1424 Good pattern 10 REG_RW11 x1428 Good pattern 11 REG_RW12 x142C Good pattern 12 REG_RW13 x1430 Good pattern 13 REG_RW14 x1434 Good pattern 14 REG_RW15 x1438 Good pattern 15 REG_RW16 x143C Good pattern 16 REG_RW17 x1500 Bad pattern 1 REG_RW18 x1504 Bad pattern 2 REG_RW19 x1508 Bad pattern 3 REG_RW20 x150C Bad pattern 4 REG_RW21 x1510 Bad pattern 5 REG_RW22 x1514 Bad pattern 6 REG_RW23 x1518 Bad pattern 7 REG_RW24 x151C Bad pattern 8 REG_RW25 x1520 Bad pattern 9 REG_RW26 x1524 Bad pattern 10 REG_RW27 x1528 Bad pattern 11 REG_RW28 x152C Bad pattern 12 REG_RW29 x1530 Bad pattern 13 REG_RW30 x1534 Bad pattern 14 REG_RW31 x1538 Bad pattern 15 REG_RW32 x153C Bad pattern 16 REG_RW33 x1004 Delay time REG_RW34 x1008 Veto time REG_RW35 x1030 Pattern Disabling Masks REG_RW36 x1600 Good bitmask 1 REG_RW37 x1604 Good bitmask 2 REG_RW38 x1608 Good bitmask 3 REG_RW39 x160C Good bitmask 4 REG_RW40 x1610 Good bitmask 5 REG_RW41 x1614 Good bitmask 6 REG_RW42 x1618 Good bitmask 7 REG_RW43 x161C Good bitmask 8 REG_RW44 x1620 Good bitmask 9 REG_RW45 x1624 Good bitmask 10 REG_RW46 x1628 Good bitmask 11 REG_RW47 x162C Good bitmask 12 REG_RW48 x1630 Good bitmask 13 REG_RW49 x1634 Good bitmask 14 REG_RW50 x1638 Good bitmask 15 REG_RW51 x163C Good bitmask 16 REG_RW52 x1700 Bad bitmask 1 REG_RW53 x1704 Bad bitmask 2 REG_RW54 x1708 Bad bitmask 3 REG_RW55 x170C Bad bitmask 4 REG_RW56 x1710 Bad bitmask 5 REG_RW57 x1714 Bad bitmask 6 REG_RW58 x1718 Bad bitmask 7 REG_RW59 x171C Bad bitmask 8 REG_RW60 x1720 Bad bitmask 9 REG_RW61 x1724 Bad bitmask 10 REG_RW62 x1728 Bad bitmask 11 REG_RW63 x172C Bad bitmask 12 REG_RW64 x1730 Bad bitmask 13 REG_RW65 x1734 Bad bitmask 14 REG_RW66 x1738 Bad bitmask 15 REG_RW67 x173C Bad bitmask 16 REG_RW68 x1800 Good pattern 1 prescaler ratio REG_RW69 x1804 Good pattern 2 prescaler ratio REG_RW70 x1808 Good pattern 3 prescaler ratio REG_RW71 x180C Good pattern 4 prescaler ratio REG_RW72 x1810 Good pattern 5 prescaler ratio REG_RW73 x1814 Good pattern 6 prescaler ratio REG_RW74 x1818 Good pattern 7 prescaler ratio REG_RW75 x181C Good pattern 8 prescaler ratio REG_RW76 x1820 Good pattern 9 prescaler ratio REG_RW77 x1824 Good pattern 10 prescaler ratio REG_RW78 x1828 Good pattern 11 prescaler ratio REG_RW79 x182C Good pattern 12 prescaler ratio REG_RW80 x1830 Good pattern 13 prescaler ratio REG_RW81 x1834 Good pattern 14 prescaler ratio REG_RW82 x1838 Good pattern 15 prescaler ratio REG_RW83 x183C Good pattern 16 prescaler ratio