Difference between revisions of "Warren Parsons Log Book"
(→7/2/09) |
(→7/2/09) |
||
| Line 1,136: | Line 1,136: | ||
<pre> | <pre> | ||
| − | MCLK = 40Mhz IPreampIn 0xa8 | + | MCLK = 40Mhz |
| + | IPreampIn 0xa8 | ||
IPreampFeed 0x50 | IPreampFeed 0x50 | ||
IPreampOut 0x96 | IPreampOut 0x96 | ||
Revision as of 17:52, 2 July 2009
This tracks My Daily Progress developing the VFAT readout
VFAT2 Manuals
5/14/09
Firmware
Today we started looking at the VHDL firmware programs from Ben Raydo at JLab. Our goal: To determine what the general description of the firmware program is and determine an outline of its functionality.
Quartus II
Quartus II has a fairly good tutorial for usage. My goal is to complete this tutorial by the end of the week.
I also started to familiarize myself with the VHDL programming language.
5/15/09
Spent vast majority of day learning VHDL syntax.
Spent some time reviewing the GEM Readout Controller Firmware Status
Spent some time reviewing the v1495 instruction manual ( the Quartus II instructions in particular )
Spent some time reviewing the VFAT instruction manual
- Is there a primer somewhere on how to communicate via/with VME?
- How about this http://www.vita.com/vmefaq.html
I need to write down how to get into the DAQ as well as ROC xterm windows.
- Tamuna can show you the above
5/18/09
- From the manual on the VFAT2
- Are we using the Roman Pots or the GEM version for the channel assignments? (I assume the latter.)
GEM version
If I understand the underlying functionality of the output of the VFAT2 then the basic idea is that it transfers the hit data from SRAM1 to SRAM2 as soon as there is a LV1A signal (100) sent to the VFAT2 via the "T1" line (after the latency time programmed into the Latency Register with a default setting of 6.4us).
I thought the max latency is 6.4 us and the default is zero
Once data is transferred from SRAM1 to SRAM2 it immediately starts outputing the information on "DataOut" at the "MCLK" rate of 40Mhz (I assume to be ultimately governed by the v1495). Valid data can be found on the "DataOut" line as long as the "DataValid" line is high. Thus the LV1A signal on "T1" followed by a transition to high on the "DataValid" line should set off the v1495 data capturing routine. Data is clocked out in FIFO order if more LV1A signals are sent to the VFAT2 before all of the data has been transferred out of the VFAT2.
I am unclear if the V1495 firmware is programmed to begin a read when the LV1A trigger transitions or when DataValid transition. I think it should be when DataValid transitions.
Tamuna and I tried to log onto the ROC from scratch, but the ROC keeps saying that it can't find some boot file. I started to look through the ROC file on Dr. Forest's wiki pages, but I do not find this to be a straightforward process of rebooting the ROC. The following entry is related, and it may be helpful.
- Would it be useful to purchase the VMEbus Handbook, 4th Edition by Wade Peterson? I have personally never worked with such a complicated system with so few written resources as the VME system. I have now read quite a bit about the history of the VME system, and yet I have yet to be able to read anything on how to actually use this system. How does one begin to even crack into this system? It is a full-blown microcontroller complete with its own operating system including the complete gamut of hardware and software.
- Where did we get this Quartus II software from and why has the 30-day trial period run out? This may be making it so I cannot compile a project and get it loaded into the v1495 via the ROC. I get this impression from the fact that when I attempt to compile the project only one error comes up and that is that the 30-day evaluation period has expired. Do we have a license for it somewhere?
Licenses are free. see http://wiki.iac.isu.edu/index.php/Qweak_V1495_FPGA_Programming for the download page
5/19/09
Tamuna, Brian, and I worked on trying to fix the MVME6100 but to no avail. I think it's actually getting worse the more we try to get it working. We may need to wait until Dr. Forest returns before attempting to fix it. I plan on reading some more information that I found on the whole VME system as well as the MVME6100 and its associated OS, VXWorks, which is apparently used in a lot more applications than I was previously aware.
I was able to contact Ben Raydo. Thankfully he had given me quite a few suggestions on how to get started with the v1495 side of this project. I am sifting through the information he has given me.
I have found much more information on the VME system today including information on the MVME6100 (as already stated) as well as other documentation.
5/20/09
I had to brush up a bit on Verilog to figure out what was going on in the v1495usr_hal.vqm file because it is written in Verilog HDL. I have added its description above.
By whatever mystical powers the ROC is apparently now working again. I would however like to know exactly what happened to get it working.
I still need a license for Quartus II in order to continue working directly on the v1495. However, I did spend a great deal of time reading how to use the MVME6100 as well as the v1495.
5/21/09
I was able to figure out how to get the license for Quartus II and to compile an .rgb file that can be loaded into the v1495 USER FPGA. I was not aware before that we already had a completely working firmware version for the v1495 USER FPGA.
- In looking through the VHDL code to figure out how it works I have made the following discoveries
- The code in GEMReadout.vhd governs the behavior of the GEMReadout component.
- Code governing the G0 (Gin(0)) and G1 (Gin(1)) Inputs
- In GEMReadout.vhd the signal GIN(1) gets loaded into HARD_TRIGGER. HARD_TRIGGER then gets loaded into the HARD_TRIGGER of the GEMTrigger component as well as the HARD_TRIGGER of a GEMTxChannel component. Thus far I am unclear what is done with this HARD_TRIGGER signal for these components. I will figure this out on Friday, hopefully.
- Still in GEMReadout.vhd the GIN(0) signal gets loaded into the inclk0 value of the PLLBlock component. In PLLBlock.vhd (which governs the behavior of the PLLBlock component), this c0 signal eventually ends up being connected to clk(0) for the altpll component. The altpll component appears to be a predefined cell in Quartus II. I hypothesize that this component is just a pll with user-defined settings. Hopefully on Friday I can find some documentation on this component to figure out exactly how it works. Thus in GEMReadout.vhd we put in our original signal G0 and get out a locked version on PLLCLK.
- This appears to be in GEMReadout.vhd where the process trigger PLLCLK is generated. All other components that take this value in on one of its ports has it as an input rather than an output.
- nLBRES is a system-wide asyncronous reset
- LCKL is a local bus clock
- I cannot figure out where this is being generated because I lose its trail into the v1495usr_hal.vqm file going to
5/22/09
altpll is indeed an Altera Megafunction. inclk0 is the reference clock to the output clocks c0 and c1. c0 is exactly in phase with inclk0 which appears to be running at a nominal frequency of 32Mhz which as stated before ultimately ends up being the PLLCLK signal in the GEMReadout block. c1 is a phase shifted version of inclk0. Although it states that this ends up being PLLCLK_90 in GEMReadout.vhd, it is actually 180 of phase shift, i.e. an inverted clock pulse. I don't know why it was given this name since it doesn't make sense.
These calculation can be done using the input parameters to the altpll plock in the PLLBlock.vhd code from the following lines.
altpll_component : altpll GENERIC MAP (
- clk0_divide_by => 1,
- clk0_duty_cycle => 50,
- clk0_multiply_by => 1,
- clk0_phase_shift => "0",
- clk1_divide_by => 1,
- clk1_duty_cycle => 50,
- clk1_multiply_by => 1,
- ;clk1_phase_shift => "15625", <-- This is the phase shift in ps.
- compensate_clock => "CLK0",
- ;inclk0_input_frequency => 31250, <-- This is the input frequency given as the period in ps.
- intended_device_family => "Cyclone",
- invalid_lock_multiplier => 5,
- lpm_hint => "CBX_MODULE_PREFIX=PLLBlock",
- lpm_type => "altpll",
- operation_mode => "NORMAL",
The units for the frequency cannot be found in the literature. The way I figured this out was to create an altpll Megafunction block with a strange frequency. After it generated the VHDL code for the megafunction I was able to see that the output of the inclk0_input_frequency was in ps.
5/26/09
- On the question of I/O Levels.
- There are two different pin voltage levels to consider here: the I/O levels coming into the board and the I/O levels of the Cyclone chip.
- The input levels going into G0 and G1 are LVTTL (3.3V). This information, as well as the pin output assignments, are located under the menu "Assignments->Pins" in the Quartus II program.
- This information is part of the project that was created for this design. What that means is that it is not enough to just import the text files for this project and compile it. One needs the project file ".qfp" which has all of the proper pin assignments including location and levels.
- The I/O levels going into and out of the v1495 is much more difficult to ascertain. The following is an example from the GEMReadout.vhd file which programs the levels as well as whether a pin is input or output.
- The nOEx signals are whether or not a bidirectional pin is configured as an output or an input. A logic level "0" is an input.
- The SELG signals are whether or not a pin is TTL or NIM on the G I/Os. A logic level "0" indicates that this is a TTL level.
- The preceeding was gleaned from the v1495usr_demo project that can be downloaded for free from CAEN. There must be some hardware external to the Cyclone chip but still on the v1495 that selects these settings.
- Thus far I have not found the documentation that demostrates how this is actually done. Like I said before, at this point I have only been able to glean the information from the v1495user_demo project. Therefore, it would not surprise me if this information was somewhat faulty.
The following code was used to see if I could turn off the Red LED:
RED_PULSE <= SYS_RESET; GREEN_PULSE <= HEART_BEAT_CNT(25); -- SYS_RESET <= not nLBRES or not PLL_LOCK;
After resetting the VME crate, it appears to have worked. I was previously under the impression that one did not have to bump the power on the v1495 to get it to use its new firmware. I will have to explore this.
The rate at which the Green LED blinks is based off of the following code out of GEMReadout.vhd.
signal HEART_BEAT_CNT : std_logic_vector(25 downto 0);
process(LCLK, nLBRES) begin if nLBRES = '0' then HEART_BEAT_CNT <= (others => '0'); elsif rising_edge(LCLK) then HEART_BEAT_CNT <= HEART_BEAT_CNT + 1; end if; end process;
Basically what these lines of code are saying is that HEART_BEAT_CNT is a 26-bit register that originally gets set to '0'. On either a change in LCLK or nLBRES and if LCLK is a rising edge, then the HEART_BEAT_CNT gets incremented by one. From the lines of code shown before this block, GREEN_PULSE is set if the MSB of HEART_BEAT_CNT is set. Therefore, the Green LED should blink at a 50% duty cycle of 2^(25)*(20Mhz)^(-1) = 3.35 s for a 20MHz PLL frequency (i.e. on for 1.67s, off for 1.67 s).
Tomorrow I will need to determine what the signals "SYS_RESET, nLBRES, and PLL_LOCK" actually are and what they mean. As I have alluded to before, I loose the trail for many of these signals at the Cyclone package level and can only infer what their actual purposes are at this point based on the code from the GEMReadout as well as the v1495usr_demo.
5/27/09
I then doubled the PLL frequency to see if it would double the rate at which the LED was blinking. It worked.
- What this means is that the LCLK signal is somehow internal to the chip and has nothing to do with the signal that is being injected on G0.
I then changed the code back on the RED LED to see if I could restore the RED LED status with the new faster GREEN LED rate.
- This worked as well.
I attempted to change the firmware back to the original 20MHz configuration, but it does not seem to have slowed down the blinking GREEN LED at all. I am wondering if the 20MHz version was somehow corrupted. I will recompile and send this over to see if I can slow the blinking GREEN LED down.
Note: This is because the Green LED depends on the system "LCLK" rather than the "PLLCLK" which is supposed to be a reflected version of the G0 input.
The following multipin connector settings can be found in the v1495 user manual and show explicitly where the proper pin connections can be made.
For my last item of the day I attempted to reset the Green LED to blink with "PLLCLK" rather than "LCLK." This only led to the Green LED remaining solid. This, as well as our previously failed attempts to lock with the frequency of the PLL, seems to suggest that the v1495 is not even registering the G0 input.
5/28/09
Today I attempted to get the LED to blink to the LCLK rather than the PLLCLK. It did not work.
Later I attempted to get C(1) to output the LCLK, which drives the Green LED, rather than PLLCLK_90. This also did not work.
Both of these seem to suggest that the Cyclone chip is somehow to communicating to the I/O ports on the v1495.
5/29/09
I was able to fix the firmware uploading code so that the board now resets with the new firmware loaded as well as actually exiting the program. I did this by making the following changes to the functions in v1495.c.
int
v1495reload()
{
volatile V1495 *v1495 = (V1495 *)0xfa510000;
int
v1495reload(unsigned int baseaddr)
{
volatile V1495 *v1495 = (V1495 *)baseaddr;
int
v1495firmware(unsigned int baseaddr, char *filename, int page, int user_vme)
{
.
.
.
v1495reload(baseaddr); // This loads the proper base address it for refresh
return(0); // This used to be an exit(0) command thus never allowing the program to exit properly.
// I suspect that exit(0) is not a VXWorks function.
}
The following line in v1495reload is actually what resets the v1495; I was tipped off to its presence by Ben.
*Conf_Flash = 1;
Before when the address for the reload function was incorrect, the USER Config Reg was never getting a '1' written to it which is what actually resets it.
I was able to inject a 5kHz clock signal in on A(1) (since A(0) was not working on the cable from the POS-to_LVDS board) and have it output from C(3) as well as its inverse on C(5).
To do this I made the following changes to GEMReadout.vhd with which I also generated its associated .rbf file GEMReadout_A1_2_2.rbf.
-- GEM Breakout Box A CLK Signals C(1) <= LCLK; C(3) <= PLLCLK; C(5) <= PLLCLK_90;
PLL_LOCK <= '1'; --PLLCLK <= GIN(0); PLLCLK <= A(1); PLLCLK_90 <= not A(1);
I also made the GREEN LED blink at a rate of 6.55 sec on and 6.55 sec off which was done with the following changes in code. This comes from the calculation 2^(15)*1/(5*10^3)
RED_PULSE <= SYS_RESET; GREEN_PULSE <= HEART_BEAT_CNT(15); -- I changed this line to the 15th bit of HEART_BEAT_CNT SYS_RESET <= not nLBRES or not PLL_LOCK; -- SYS_RESET <= '0';
process(PLLCLK, nLBRES) -- I changed the process sensitivity from LCLK to PLLCLK begin if nLBRES = '0' then HEART_BEAT_CNT <= (others => '0'); elsif rising_edge(PLLCLK) then -- here as well HEART_BEAT_CNT <= HEART_BEAT_CNT + 1; end if; end process;
On the output of the oscilloscope below, Line2 is the output from C(3) and Line3 is the output from C(5).
_to_C(3)C(5).png)
When I doubled the frequency on the function generator I observed the following output on the oscilloscope as well as the GREEN LED blinking twice as fast.
_to_C(3)C(5)_2x.png)
This means that for some reason our input on G0 is not getting taken in. All other I/0s on the board appear to be working though!
6/1/09
I removed the bus power from the I/Os in Quartus II to see if it would kill the I/Os. It appears to not have had any effect. Apparently I did not fix anything by adding I/O bus power in the design.
- I learned today what the actual mistake was that was made on the VFAT breakout board. I have some questions relating to this mistake. There are loads of pins that are now hooked up incorrectly now. I will need to spend some time going through the manual for the VFAT to figure out what some of the settings for these pins need to be. This is most likely related to why we are having trouble getting the VFATs to communicate properly.
- What happens to the VFAT if "ScanEn" (Scan Mode Enable) is held high?
- B22 (DGND) is floating right now. Shorting it to B21 would fix it.
On a slightly different note; I need to figure out how to do a nice table in this wiki so I can enter these pin numbers in.
6/2/09
The following is the successful reading of the VFAT DF test pattern output on the DataValid, DataOut ports along with the MCLK signals ( Line 2, 3, 4 respectively). It must be noted that in order to read all of these signals at once one must disconnect the ground from the MCLK line due to its having a drastically different ground than the DataValid and DataOut signals. Since the grounds of the measured signals are effectively shorted in the oscilloscope, it attempts to balance these ground lines which it turn causes deleterious glitches in all of the signals (the MCLK glitch probably being the worst) quite often upon transistions. The first picture shows the MCLK signal with AC Coupling while the second shows the MCLK signal with DC coupling.
I was able to correct the wiring issues that I discovered yesterday; it has fixed the direct connect from the VFAT board to the breakout board. See the picture below.
The following was taken with the VFAT connected directly to the breakout board.
One disconcerting thing of note is that the bit transitions occur on the rising edge of the MCLK in these pictures, but in the documentation they are clearly supposed to transition on a falling edge. These patterns, however, appear to agree with the pictures taken previously of the DF Test Pattern. I have triple checked the polarities on these for correctness.
For some reason the notches have been taken off of the cables. The notch was originally on the positive side of the connectors. I have them connected on the negative side right now, but in the future we will most likely need to have this corrected.
I was successfully able to pass the LV1A signal through the v1495 and request a formatted data package from the VFAT. The following shows the ChipID isolated between the two cursors. ChipID<1>=150=bin(10010110) ChipID<0>=236=bin(1101100) As per the VFAT manual, only the last four bits from ChipID<1> make it into the formatted data stream along with the full ChipID<0>.
6/3/09
All of the VFAT ports on the breakout board have been rewired and appear to be working except port 80. I still have not been able to observe a good DataOut stream from this one. I have tested several different VFATs in this port and tested the same chips in different ports, so I know that it is just the port itself. I recommend that since we will hopefully be getting a new board soon anyway that we not worry about trying to diagnose why this port is malfunctioning. Also, I noticed that with all of the peripherals disconnected there is only 10kOhm of resistance between VCC and GND. I'm wondering if in all of the resoldering that we haven't accidentally gotten some stringers across some lines somewhere or something to that effect.
The DATout pulses below represent the checksum (just before datavalid goes low) and, after datavalid goes high, the beginning of the EC, BC, flag, and CHIP ID bits.
The VFAT chip ID appears between the vertical yellow lines marked "a" and "b"below. The bits are 1110011011101100. The first 4 bits (1110) are a header and the remaining bits (011011101100 b = 6ec h) represent the CHIP ID as described in Figure 8 of the VFAT 2 manual.
6/4/09
I was able to use the DG535 to send a single pulse to the Agilent 81110A to send out a single Hard Trigger pulse followed by a large number of MCLK pulses (~200).
Port 80 is now working. The MCLK- pin was not properly soldered to the connector. I found it by doing a continuity test on the pins.
The first memory address right after the v1495 base addresses are where all of the data are being stored. I did not realize this before. It is simply a matter of reading these memory locations to get the data after it has gone in. I still don't understand the exact mechanism that stores these values into these registers. It has to do with some primative memory blocks in the Cyclone chip.
This is where the value for the Hard Trigger Word is as well. Three of the bits in this word are the actual bits that get shipped out on LV1A when a Hard Trigger pulse is sent to the v1495. Right now I am just simulating this, but knowing where this value is stored, I should be able to actually get it to fire correctly.
I now understand how the read and writing mechanisms to the local bus work, however, I would probably not be able to set this up from scratch as CAEN holds the secrets as to how the actual pins from the Cyclone chip make their connections to other parts of the board. Fortunately, it is not necessary to now this level of detail for this project, and it is obvious that CAEN did this intentionally.
We were able to query several GEM-specific registers to confirm that we had been able to locate them. We were able to change the Revision number and observe the change from the ROC.
There are only a certain number of registers that are located in the GEMReadout file that are capable of being read and/or written to. If the register is not on the list and if it is written to, nothing will happen, and if it is read, all that will be output is zeros. I am not yet certain if one can add other registers if one wants to be able to query their respective contents such as the HARD_TRIGGER_WORD register which as of right now, one cannot query its contents.
6/5/09
I was successfully able to program the 3-bit HARD_TRIGGER_WORD, i.e. the word that is sent out on T1. It is located at memory location 0xaddr0014(5:3). Below I have shown how to explicitly program these three bits. Here I have programmed it to have a 1-0-1 pattern as shown in the picture below as well.
-> m 0x80110014,2 80110014: 0000-0028 80110016: 0000-. value = 1 = 0x1
I have been able to observe the first three words being entered into the v1495 USER memory.
I created the following function in GEMReadoutCtrl.c:
void GEMSprint(void) // this function prints out my favorite registers
{
UINT32 Addr = 0x80110000;
volatile GEMReadoutCtrlRegs *v1495 = (GEMReadoutCtrlRegs *) Addr;
printf("A0_EVENTDATA Addr: 0x%08x Data: 0x%04x \n",&(v1495->EventData_0[0]),v1495->EventData_0[0]);
printf("A0_FIFOSIZE Addr: 0x%08x Data: 0x%04x \n",&(v1495->FIFOLength[0]),v1495->FIFOLength[0]);
printf("A0_EVENTSIZE Addr: 0x%08x Data: 0x%04x \n",&(v1495->EventSize[0]),v1495->EventSize[0]);
//printf("A0_EVENTDATA Addr:%04h Data:%04h \n",&(),);
printf("\n");
return;
}
This returned the following results when I ran the function three times consecutively:
-> GEMSprint() A0_EVENTDATA Addr: 0x80114000 Data: 0xa4f0 A0_FIFOSIZE Addr: 0x80110030 Data: 0x02c0 A0_EVENTSIZE Addr: 0x80110048 Data: 0x0000 value = 1 = 0x1 -> GEMSprint() A0_EVENTDATA Addr: 0x80114000 Data: 0xc042 A0_FIFOSIZE Addr: 0x80110030 Data: 0x0280 A0_EVENTSIZE Addr: 0x80110048 Data: 0x0000 value = 1 = 0x1 -> GEMSprint() A0_EVENTDATA Addr: 0x80114000 Data: 0xe66c A0_FIFOSIZE Addr: 0x80110030 Data: 0x0240 A0_EVENTSIZE Addr: 0x80110048 Data: 0x0000
The first nibble of each word is it's respective header which are correct per Figure 8 in the VFAT manual. The last word recorded has the ChipID number 66c which is correct for this device.
See below for the oscilloscope results of the values as they are passed through the v1495. The value highlighted between the cursors is the last word recorded.
Although I was able to see this data, I am still not 100% clear on exactly how this memory is stored. It is still somewhat buggy as it will not always correctly reliquish its captured data nor the correct number of words that are in the data FIFO.
6/8/09
Having learned that the SizeFIFO length is the last six bytes of the EVENTSIZE data request (as opposed to the last eight as I previously thought), I can see that every time I request a dump of the data memory the ROC is missing two words per request. See output from ROC below:
-> GEMReset() value = 0 = 0x0
The preceding function resets the v1495 including zeroing out both the data and the size FIFOs.
Trigger the VFAT with one pulse and now display the contents of the ROC memory
-> d 0x80110030 80110030: 0301 *................* value = 21 = 0x15
The preceding function dumps the memory found at 0x80110030. This is the EventSize register which contains the number of words in the dataFIFO(15:6) and the sizeFIFO(5:0).
0x0301 = 001100000001 b
The module address 80110030 is 0x30 away from the base address 0x11.
000001 b = 1 d there is 1 event waiting in the sizeFIFO.
The remaining 10 bits 0000001100 b = 12 d = number of 16 bit words in the dataFIFO.
80110030: 0301 *................* value = 21 = 0x15 -> d 0x80114000 80114000: aa40 *.l..............* value = 21 = 0x15 -> d 0x80110030 80110030: 0241 *.A..............* value = 21 = 0x15
0x2401 = 001001000001 b
After reading only "one" word off of the top of the dataFIFO, the number of words reported to be in the dataFIFO has decreased to 0000001001 b = 9 d.
Is it possible that 3, 16 bit words were taken out of the FIFO?
-> d 0x80114000 80114000: 0000 *................* value = 21 = 0x15 -> d 0x80110030 80110030: 0181 *................* value = 21 = 0x15
Again the number of words in the dataFIFO decreases by 3 since we now have 0000000110 b = 6 d.
If I manually read out the data one at a time using a call to the contents of this register via a C function, I do not have this problem. That is why I was able to access the data last week. However, if I loop in a function to get these contents I am only able to get the first value and the dataFIFO only decrements by one. I am trying a different firmware version which only requires that the "Read Request Bit" be high (rather than a rising edge) to access the data. I'm hoping that this will fix the problem.
- This did not fix the problem; in fact it made it so the memory dump would skip by six words each time! A looping call to the value remains unchanged. I am wondering if because the value of my variable was not declared as a "volatile" that it is not letting the program actually update the value.
I am wondering if the VxWorks function "d" doesn't do some kind of repeat call of the register for bit integrity. That may be what the extra information marked by the *...* is for.
External Connections
| From v1495/ To VFAT | MCLK C(0)=>C(5)
Trig C(10)=>C(15) |
|---|---|
| From VFAT/ To v1495 | DataOut16 A(14) DataValid16 A(13)
DataOut32 A(12) DataValid32 A(11) DataOut48 A(10) DataValid48 A(9) DataOut64 A(8) DataValid64 A(7) DataOut80 A(6) DataValid80 A(5) DataOut96 A(4) DataValid96 A(3) |
| From Signal Generator/ To v1495 | MCLK A(17)->A(22)
Trig A(25)->A(31) |
v1495 Registers
In the registers below "addr" refers to the four-hex base address of the v1495. For our experiments thus far this has had the value 0x8011.
| Member of struct pGEMReadoutCtrl | Address | Bit Format | Description |
|---|---|---|---|
| FIFOLength[0] | 0xaddr0030 | FIFOdataSize<15:6> FIFOLength<5:0> | FIFOSize = number of 16 bit words in Fifio: FIFOLength = number of events of size FIFOdataSize in FIFO: example: 0x0301 = 001100000001 b => FIFOdataSize = 0000001100 d = 12, 16 bit data words, FIFOLength= 000001 b = 1 event of 12, 16 bit words in FIFO. |
| EventSize[0] | 0xaddr0048 | x"000" & EventSize<3:0> | Reading of this register gives the results off of the top of the sizeFIFO. This contains how many words were entered into the dataFIFO from the previous event. |
| EventsSentH[0]/EventsSentL[0] | 0xaddr0080/0xaddr00A0 | Each occupies whole word | This records the number of events that have occurred since the v1495 was last reset. |
| EventData[0][0] | 0xaddr4000 | Whole word | Reading of this register gives the oldest word in the dataFIFO. |
6/9/09
I was successfully able to simultaneously read the formatted data off of all six VFATs (after repairing the DataValid line on PORT 64). For reasons only known to those who programmed the ccppc, if one assigns a register to a variable outside of a for-loop and then assign that contents of that variable to another variable inside of the for-loop, the ROC will not update this original value. One has to explicitly have the final variable read out the contents of the v1495 register, or it will not automatically update them! I even tried to declare all of these variables as "volatile" in an attempt to get them to update but to no avail.
Also, this compiler has a hard time with simple pointers sometimes as well. It's something to watch out for.
In the following printout from the ROC one is able to see that after I reset the v1495 ("v1495Reset()"), I sent two events to the VFATs. These events are read in via "v1495ReadEvent()" and read out via "v1495StatusPrint()".
Right now the data is stored in a static struct on the ROC. It is a relatively simple matter to alter these functions to take in a pointer to an array of UINT32 type variables and hand off the starting address of this struct to this pointer. I can also return the size of the array from the function to communicate the size; either that or I could take a variable in that gives the size. Either way works about the same.
-> v1495Reset() value = 0 = 0x0 -> v1495Sprint() A0_FIFOSIZE Addr: 0x80110030 Data: 0x0602 A0_EVENTSSENT Addr: 0x801100a0 Data: 0x0001 Number of words in dataFIFO : 0024, 0x0018 Number of words in sizeFIFO : 0002 value = 1 = 0x1 -> v1495ReadEvent() value = 1 = 0x1 -> v1495StatusPrint() GEM[0]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A415 C050 E66C 0000 0000 0000 0000 0000 0000 0000 0000 56DC GEM[1]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A1A5 C020 EA6C 0000 0000 0000 0000 0000 0000 0000 0000 E86D GEM[2]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A1A5 C020 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 447C GEM[3]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A275 C030 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 B338 GEM[4]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A1A5 C020 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 447C GEM[5]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A1A5 C020 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 A426 value = 1 = 0x1 -> v1495ReadEvent() value = 1 = 0x1 -> v1495StatusPrint() GEM[0]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A4E5 C060 E66C 0000 0000 0000 0000 0000 0000 0000 0000 A9F8 GEM[1]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A275 C030 EA6C 0000 0000 0000 0000 0000 0000 0000 0000 FF73 GEM[2]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A275 C030 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 5362 GEM[3]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A345 C040 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 0BCB GEM[4]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A275 C030 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 5362 GEM[5]: #B[24] #F[1/2] B/s[24] F/s[1] LastCap[12]: A275 C030 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 B338 value = 1 = 0x1 -> v1495ReadEvent() value = 0 = 0x0 -> v1495StatusPrint() GEM[0]: #B[0] #F[0/2] B/s[0] F/s[0] LastCap[0]: GEM[1]: #B[0] #F[0/2] B/s[0] F/s[0] LastCap[0]: GEM[2]: #B[0] #F[0/2] B/s[0] F/s[0] LastCap[0]: GEM[3]: #B[0] #F[0/2] B/s[0] F/s[0] LastCap[0]: GEM[4]: #B[0] #F[0/2] B/s[0] F/s[0] LastCap[0]: GEM[5]: #B[0] #F[0/2] B/s[0] F/s[0] LastCap[0]: value = 1 = 0x1
From the middle two nibbles in the second word of each output, one can see the Event Counter incrementing by one. Also, from the last three nibbles from the third word of each output one can see the ChipID from each VFAT. I had not noticed it before but these three nibbles are not unique. From the output one can see that one pair shares the ChipID 8EC and another pair shares the ChipID 6EC. This was confirmed by looking up the ChipIDs from each these VFAT's respective website.
6/10/09
I spent the vast majority of the day just figuring out how the v792 files were created so we can create our own v1495 with an extremely similar format.
6/11/09
VxWorks API Reference : OS Libraries
Useful description of the vxMemProbe function for VxWorks:
vxMemProbe( )
NAME
vxMemProbe( ) - probe an address for a bus error
SYNOPSIS
STATUS vxMemProbe
(
char * adrs, /* address to be probed */
int mode, /* VX_READ or VX_WRITE */
int length, /* 1, 2, 4, or 8 */
char * pVal /* where to return value, or ptr to value */
/* to be written */
)
DESCRIPTION
This routine probes a specified address to see if it is readable or writable, as specified by mode. The address is read or written as 1, 2, or 4 bytes, as specified by length (values other than 1, 2, or 4 yield unpredictable results). If the probe is a VX_READ (0), the value read is copied to the location pointed to by pVal. If the probe is a VX_WRITE (1), the value written is taken from the location pointed to by pVal. In either case, pVal should point to a value of 1, 2, or 4 bytes, as specified by length.
Note that only bus errors are trapped during the probe, and that the access must otherwise be valid (i.e., it must not generate an address error).
EXAMPLE
testMem (adrs)
char *adrs;
{
char testW = 1;
char testR;
if (vxMemProbe (adrs, VX_WRITE, 1, &testW) == OK)
printf ("value %d written to adrs %x\n", testW, adrs);
if (vxMemProbe (adrs, VX_READ, 1, &testR) == OK)
printf ("value %d read from adrs %x\n", testR, adrs);
}
MODIFICATION
The BSP can modify the behaviour of vxMemProbe( ) by supplying an alternate routine and placing the address in the global variable _func_vxMemProbeHook. The BSP routine will be called instead of the architecture specific routine vxMemArchProbe( ).
RETURNS
OK, or ERROR if the probe caused a bus error or was misaligned.
I need to study this function as it is one of the only ones left that I don't understand from the c792 code. I should be able to figure out how to use it pretty quickly tomorrow.
I figured out how the addressing works for the v1495: the three dials are the base address settings for the A32<31:16> VMEbus address. I was able to use the function sysBusToLocalAddr() to assertain that the Local address 0x80110000 is 0x78000000 higher than the VMEbus address 0x08110000. Something wasn't quite making sense about this before.
I have also located some truly unique identifiers for our v1495. There is an IEEE OUI (a hex number assigned to CAEN by IEEE), a BoardID number unique to the v1495 card, as well as a serial number (this one I am assuming is the most unique i.e. for our particular board). We should be able to use these values in the init function to make sure we are properly communicating with the v1495. The only difficultly with where these are located is that they are not in the FGPA USER registers. They are in the Configuration ROM which is separated from the base address by quite a ways. I believe it is going to be easier to set up a defined offset to locate these values rather than use reserved values in the struct definition.
6/12/09
I have noticed that if the input to the DataOut and DataValid are left open the signal is interpreted as a high signal. Furthermore, when the VFATs are first plugged in these ports are still left open (or forced high although I can't be sure). We can use this fact to our advantage by sending a dummy LV1A request to the VFATs and then reset the v1495 to see if their EVENTS_SENT > 0. It is a handy "glitch" in the v1495 firmware that if the DATA_VALID line is high after a reset, it increments the EVENTS_SENT value. Therefore, if they are working then the EVENTS_SENT should equal zero.
The reason that the v1495Init(...) function wasn't working immediately after reboot was that the values for the DataValid and DataOut were not being taken into the v1495 until the original MCLK was being run. Furthermore, they start off initialized to zero in the firmware. Making the process that controls reading DataValid and DataOut depend on Reset as well will fix this.
- I cannot remember the syntax for transferring files using the pscp program on the Windows computer. I tried the following but to no avail:
- pscp GEMReadout_All.rbf daq@daq1:134.50.3.210
You need to add a ":" at the end it should look like this
- pscp GEMReadout_All.rbf daq@daq1:134.50.3.210:
I got it to work using the following syntax:
pscp GEMReadout_All.rbf daq@134.50.3.210:
- How does one figure out the IP address of the computer in the tcsh shell, by the way?
/sbin/ifconfig
Ah excellent. This worked nicely.
Also, I was wondering if we shouldn't make reseting the VFATs possible using the v1495. This may be something that we should include into the next breakout board rev if it isn't already there.
6/15/09
Last week I did not anticipate that it would crash the ROC while attempting to debug my array transfer function. Today I am going to practice using another generic 32-bit array to practice with. Hopefully, this won't be as prone to crashing.
This worked as Dr. Forest and I were able to get the data successfully transferred into a CODA data file.
I now have the GIN ports working. There was this nasty Cyclone LE (Logic Element) called cyclone_lcell that the TTL/NIM control bit was going into. Of course there is almost no documentation available on these lcells. I - as did those who wrote the original GEM firmware - assumed that all this did was buffer the signal. I noticed that hidden in this LE was a phrase that hinted that rather than buffer the signal, it inverted it. So after all of that digging, all I ended up having to do was invert the signal going to the TTL/NIM control bit.
Please document how this works in your thesis. Let's set up a logic unit to take the and of a trigger pulse and the clock. The output pulse will go into G1 and trigger the VFATsr G1 Lets use a TTL input for G0 and G1 ca
6/16/09
The following is the output from GEM[0] with an MCLK of 32Mhz. As hoped, the RED LED on the V1495 goes out when the PLL locks with the incoming MCLK from the pattern generator.
I have zoomed in on the ChipID to show that they match (ChipID from GEM[0] is 0x6EC). All of the signals shown are actually buffered signals of the originals as they are passed through the V1495. The HARD_TRIGGER signal does not have to be in sync with the MCLK. As long as it is at least 1.5 periods of the MCLK, I think we will be okay. Also, the CAEN N405 can apparently only produce a maximum pulse width of 200ns (it says 800ns in the manual). Putting all of this together means that we can probably go no slower than 6.5Mhz with this setup.
It was somewhat difficult to time this circuit correctly, but I was able to capture an event that was triggered off of the GEM_Trig_Out: the output of the GEM amplifier.
The following was the printout from the v1495StatusPrint() function corresponding to this cosmic event. It appears that we will most likely have to calibrate the lines as well as set up the pulse-shaping in order to get any valid reads on any of the lines; they are all zero here.
-> v1495StatusPrint() V1495[0]: #B[24] #F[1/22] B/s[24] F/s[1] LastCap[12]: AE18 CCA0 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 9B6A Event Count: 202 ; Chip ID : 0x6EC V1495[1]: #B[24] #F[1/25] B/s[24] F/s[1] LastCap[12]: ACAE C9A2 EA6C 0000 0000 0000 0000 0000 0000 0000 0000 72DF Event Count: 154 ; Chip ID : 0xA6C V1495[2]: #B[24] #F[1/28] B/s[24] F/s[1] LastCap[12]: AA9A C2D2 E66C 0000 0000 0000 0000 0000 0000 0000 0000 3CFC Event Count: 45 ; Chip ID : 0x66C V1495[3]: #B[24] #F[1/30] B/s[24] F/s[1] LastCap[12]: AC14 C9A2 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 BAF1 Event Count: 154 ; Chip ID : 0x8EC V1495[4]: #B[24] #F[1/33] B/s[24] F/s[1] LastCap[12]: ACB5 C993 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 1B25 Event Count: 153 ; Chip ID : 0x6EC V1495[5]: #B[24] #F[1/36] B/s[24] F/s[1] LastCap[12]: A9A3 C1A2 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 F0A8 Event Count: 26 ; Chip ID : 0x8EC
I have zoomed in on the first three words of the data package from GEM[0] to show that they match. Also, ground and cross-talk is showing up particularly when data is being read out of the VFATs. Even with a few minor adjustments we were able to get it mostly under control. With a little more careful planning, I think we should be able to run the MCLK at 32 Mhz without any major issues.
At some point I will need to return the 32 MHz pulse generator. My Stanford pulse generator only goes up to 999 kHz pulse . We need a configuration which will do 500 kHz. I think we can find a way to increase the LV1A trigger pulse width. Let's have 2 firmware versions, one at 32 MHz requiring PLL and one at 500 kHz.
- The limitation on the frequency is a function of the maximum pulse width that the CAEN N405 can do since we need the output pulse for the HARD_TRIGGER to be high for at least one period of the MCLK. If we can trigger the Stanford pulse generator with the NIMs equipment then we are in business to do a much lower frequency. I can't remember off hand what the lower end of the PLL was. Either way works just fine with the timing since I'm sure the designers did their homework to figure out what the lowest frequency was that didn't need a PLL to maintain a clean signal.
I will need to use the Stanford pulse generator as as MCLK. We can send the N405 output pulse into a gate generator and increase the pulse width.
6/17/09
I have been attempting to figure out the algorithm behind the CRC-16 word at the end of the transmission. It is promised on the web and other places that the computation for these are fairly efficient, and we may be able to use this to make sure that our data transmissions are intact.
I was able to add code to the v1495ReadEvent() function that prints off the hits on the individual channels. We can possibly reuse some of this code when we go to implement our GUI with the hits on it. It basically takes a hex number and parses it out into four hex numbers making it appear like a binary number. It actually ends up taking four times more memory to store this information so it is for reading out convenience only. The following shows the output of the new function implemented on the ROC.
I have attempted to make this code very efficient, so reading it to figure out what's going on might be somewhat painful.
-> v1495ReadEvent() v1495ReadEvent: Data entered into v1495Channel[0] Channels 1 -> 32: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 33 -> 64: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 65 -> 96: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 97 -> 128: 0000 0000 0000 0000 0000 0000 0000 0000 v1495ReadEvent: Data entered into v1495Channel[1] Channels 1 -> 32: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 33 -> 64: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 65 -> 96: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 97 -> 128: 0000 0000 0000 0000 0000 0000 0000 0000 v1495ReadEvent: Data entered into v1495Channel[2] Channels 1 -> 32: 0111 0111 1111 0111 0111 0111 0101 0101 Channels 33 -> 64: 1101 1101 1111 1111 0111 1111 1101 0101 Channels 65 -> 96: 1101 0101 0101 1101 0101 1101 1111 0101 Channels 97 -> 128: 0101 0111 1111 0101 0101 1011 0001 0100 v1495ReadEvent: Data entered into v1495Channel[3] Channels 1 -> 32: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 33 -> 64: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 65 -> 96: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 97 -> 128: 0000 0000 0000 0000 0000 0000 0000 0000 v1495ReadEvent: Data entered into v1495Channel[4] Channels 1 -> 32: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 33 -> 64: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 65 -> 96: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 97 -> 128: 0000 0000 0000 0000 0000 0000 0000 0000 v1495ReadEvent: Data entered into v1495Channel[5] Channels 1 -> 32: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 33 -> 64: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 65 -> 96: 0000 0000 0000 0000 0000 0000 0000 0000 Channels 97 -> 128: 0000 0000 0000 0000 0000 0000 0000 1000 value = 84 = 0x54 = 'T' -> v1495StatusPrint() V1495[0]: #B[24] #F[1/2234] B/s[24] F/s[1] LastCap[12]: A025 C870 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 C99B Event Count: 135 ; Chip ID : 0x6EC V1495[1]: #B[24] #F[1/2234] B/s[24] F/s[1] LastCap[12]: A9B9 CD32 EA6C 0000 0000 0000 0000 0000 0000 0000 0000 16CE Event Count: 211 ; Chip ID : 0xA6C V1495[2]: #B[24] #F[1/2234] B/s[24] F/s[1] LastCap[12]: A6C7 C552 E66C 77F7 7755 DDFF 7FD5 D55D 5DF5 57F5 5B14 6D77 Event Count: 85 ; Chip ID : 0x66C V1495[3]: #B[24] #F[1/2234] B/s[24] F/s[1] LastCap[12]: A807 C652 E8EC 0000 0000 0000 0000 0000 0000 0000 0000 0EA1 Event Count: 101 ; Chip ID : 0x8EC V1495[4]: #B[24] #F[1/2234] B/s[24] F/s[1] LastCap[12]: A39A C193 E6EC 0000 0000 0000 0000 0000 0000 0000 0000 30A4 Event Count: 25 ; Chip ID : 0x6EC V1495[5]: #B[24] #F[1/2234] B/s[24] F/s[1] LastCap[12]: A2FE C020 E8EC 0000 0000 0000 0000 0000 0000 0000 0008 8AE2 Event Count: 2 ; Chip ID : 0x8EC value = 33 = 0x21 = '!'
Let's start taking cosmic data overnight I tried to turn everything back on but the V1495 didn't seem to lock with the pulse generator. The left led was blinking red/green I set the VFAT cards up to have different thresholds. We will want to start studying VFAT preamp values and threshold to determine the optimal setting
6/18/09
I have learned how to write programs that work on the Gumstix computer. I have redone the stop.arm and run.arm to turn off and turn on all of the VFATs respectively. I have nearly finished remodeling the flipbit.arm program so that one can flip either a single bit or an entire register at once. I just need to tidy up it's functionality with the extended registers. If one were to use it right now on the extended registers, I'm not sure what it would do actually. I think that it would just try to write on the base register. In any case, I should have this working early tomorrow morning.
Also, I talked to Brian and was wondering if getting the new breakout boards or the better/more interactive website for the VFATs working would be better. My vote is for the website for the VFATs, but I'm not 100% sure on the time lines and other pertinent factors.
I think we want to put priority on getting the new breakout boards in We may still find errors which need to be fixed. Although it is inconvenient we can probably limp along with the VFAT controls we have now programming controls as needed.
6/19/09
I spend the morning debugging why the I2C wasn't working. After having communicated with Brian on the issue, I determined that one of the VFATs - for whatever reason - was holding down the SDA line. This rendered attempted communication by the VFATs moot.
I have rewritten the flipbit.arm program so that one can change an entire register at a time rather than just one bit at a time. The format of the entry has slightly changed but is included in the help documentation for the program itself which is also shown below.
Input file should be of the form:
<mode> <base address> <register address> <bit or hex value> <action>
<mode>: either "p" for primary or "e" for extended
<base address>: this is the base I2C address for the VFAT
<register address>: this is the respective I2C address for the VFAT
<bit or hex value>:
if bit then {1..7}
if hex then {0x00..0xFF}
<mode>: "on" turn the bit(s) on.
"off" turn the bit(s) off.
"flip" flip the bit(s).
"set" set the bits as the hex value.
As an example:
echo "p 32 0 0x01 on" | ./flipbit.arm or echo "p 32 0 0 on" | ./flipbit.arm
Either or these would cause the sleepb mask for VFAT at I2C address 32 to turn on (thus turning on the VFAT).
echo "e 96 134 0x10 on" | ./flipbit.arm or echo "e 96 134 4 on" | ./flipbit.arm
Either of these would turn on the DFTestPattern for the VFAT at I2C address 96.
Where it becomes really nice is in the following example:
echo "p 80 2 0xFF on" | ./flipbit.arm
This would cause the IPreAmpin register to have a value of 0xFF (0d255) in one fell swoop.
There is no equivalent for doing this with one command with the old flipbit.arm program.
echo "p 80 4 0xAA set" | ./flipbit.arm
This would set the value in the IPreampOut register to 0xAA (0b1010_1010) regardless of what the previous value was.
- Important!*
Adding the "-n" suffix to the end of ./flipbit.arm now kills the verbose output. The VFAT.setup script is setup with this, so if one runs it right now, you won't see anything getting printed to the Gumstix xterm window.
Before leaving I turned off all of the VFATs. If you run the script it will turn them back on.
I wasn't sure if everything else was set up and ready to start taking data. If it is I can go back and start up CODA. If all I need to do is hit the "run" button, I'm sure I can manage. If I have to start up any of the other terminals I probably won't know what I'm doing.
I tried to start the DAQ but the ROC appears to be crashing. Perhaps I am downloading the wrong ROC lib. Lets clean up the ROC lib directory and try on Monday Once everything is going lets leave it on.
6/22/09
Location of the test.dat file reader.
/home/daq/CODA/CODAreader/UsingROOTnEVIO/VFAT
6/23/09
The following is the current I2C address with its respective ChipID
| I2C | ChipID |
|---|---|
| 16 | 0x6EC |
| 32 | 0xA6C |
| 48 | 0x66C |
| 64 | 0x8EC |
| 80 | 0x6EC |
| 96 | 0x8EC |
6/24/09
The VFAT threshold tests show an ability to set the threshold high enough that no hits will be recorded. There is definitely a correlation to be seen between the value of Threshold_1 and the number of all zero events and the average number of hits per event. Right now there is a trade off between the targeted .75 all zero hits percentage for VFATS 0, 1, 4, and 5 as well as the .50 all zero hits percentage for VFATS 3 and 4 and the average number of hits recorded for each event where the VFAT has at least one hit recorded.
There are still several areas of concern for me on this project, and that I believe we will be forced to tackle if we are going to get what we want from it.
First, I would personally like to have a much, much better understanding of the processes involved in the triggering signal.
The trigger is currently being generated by the last GEM foil stage. The charge leaving the last GEM foil for the charge collector is sourced by the last GEM foil. This charge loss appear as a current drop on the last GEM foil. This current drop produces a pulse which is inverted by an OP amp and sent to a Constant Fraction Discriminator.
Before I start rambling about specifics let me ask if there is any documentation on this detector or these detectors in general. I suppose I could lump making sure that we intimately understand all of the setting we have for the trigger. For instance, if it is correct that the dE/dx for the particles we are measuring are so similar, then why are we seeing spikes from the trigger line that can be as much as twice the size of each other (i.e. the pulse from the detector can vary as much as 232mV from the detector)? Isn't the varying amplitude of these spikes a function of the varying energy lost by the particles in the detector? What other factor(s) would account for this? If there are other factors I'm not aware of, would it be possible to filter them out?
Second, we need to also intimately understand the settings for the filter and amplifiers on these channels. I have uncovered some documentation on these, but it may not be enough to understand what is going on. Are there contacts at CERN whom we can contact about this device? Is it possible that there are people at JLAB who also know about these parameters? I see lots of names attached to these papers; I wonder if they are reachable.
Finally, what are the future plans for setting up calibration for the VFATs? I see that there is the possibility to externally measure the voltage and current setting for the amplifiers/filters. How important do we reckon these parameters will be in the final design?
The following is the schematic for the VFAT2 front-end. Some of the VFAT parameters accessable via the I2C can be seen in the schematic. There are still many parameters in the registers that are not found on the schematic and I/Os on the schematic that do not appear to have any representation via the registers.
The current version of the v1495Lib files are completely compiled and loaded onto the ROC. This includes the change made to insert the number of the VFAT chip in place of the header for the ChipID word. I have listed them in text format on the following wiki pages. v1495Lib.c and v1495Lib.h
The CODA gen_list.crl file is found at V1495_CODA_CRL_File
6/25/09
In thinking about the noise on the GEM Trigger line I took the following scope picture of the FFT of the GEM trigger line.
(I can't post it yet because the wiki won't let me.)
We can see from this that there is a signification amount of noise being injected on the GEMTrigger line from the MCLK not only at its fundamental frequency but its harmonics.
Warren, check out the "vfat" executable program in my directory on the DAQ computer. It will dislay the hits in all 6 VFAT cards graphically
type "vfat -pause -GUI" to see it work
remember the default input file is temp.dat
6/26/09
After having flipped the MSPOLARITY bit, I have observed that we are still getting a significant number of hits in the VFATs. I'm not 100% convinced that we don't have the voltage on the GEM detector cranked up too high and that we aren't observing ringing in the lines one way or the other. We need to do a little more background research to figure out what is going on in the signal lines for the VFATs. I believe that this includes understanding how the frontend section of the VFAT2 works. Also, it requires a better understanding of the register settings. I also highly recommend we get the VCAL functionality of these chips working and hit the lines with some test voltages to see what happens. I think that I could have this part working within a couple of days next week.
I spend the good portion of the day trying to figure out the circuit schematic from the VFAT2 paper that I found online in the CERN document library. I have highlighted the different sections with colored boxes.
Anyway, the first section (blue) is the transimpedance (i.e. current-to-voltage) conversion section. I'm still a little fuzzy on exactly how this section works, however it appears that Ifeed controls the amplification via a cascode amplifier and Ifeed in conjunction with Vfeed controls the high-pass properties of this section. Again, I'm not 100% certain, but it appears that the higher the difference between the biasing voltage set by Ifeed and the value given to Vfeed, the faster this section will sink the negative charge from the line (i.e. the high-pass filter will have a higher cutoff frequency). This section inverts the polarity of the signal. As of yet, I am still uncertain exactly how these parameters correlate to the parameters that are programmable via the I2C registers of the VFAT.
The second section (red) is another amplifier only this time the negative feedback loop sets the low-pass filter properties. Again, I am not certain how the parameters of this section correlate to the programmable registers of the I2C. My guess is that the current sources in this section on the schematic are related to the parameters IShaper/IShaperFeed. This section again inverts the signal.
The next section (green) is where the threshold voltage settings take effect. Setting VThresh_2, _1 set the biasing points of the two sides of the differential amplifier. C3 capacitively couples the signal from the previous section to this section possibly providing even more low-pass filtering on the signal; depending on the frequency of the signal, value of this capacitance, and the magnitude of the current source from the previous stage. The current source Itrim is most likely the parameter that is altered by the individual channel TrimDAC settings. This setting would help balance the imperfections in the different channels' capacitances as well as the imperfections of the various transistors and resistance values. This section inverts the signal as well as converting it from a single-ended signal to a differential one.
It appears that if Vthreshold_2 > Vthreshold_1 then the tripping threshold will be positive; the greater the difference between the two, the higher the positive tripvoltage will be. If Vthreshold_1 > Vthreshold 2 then the tripping voltage will be negative. For either case, if Vin < Vtrip then the output will be a low (logic 0). If Vin > Vtrip then the output will be a high (logic 1). This makes sense for the positive trip voltage but it is opposite of what I thought for the negative tripping voltage. I believe this is whether the MSPOLARITY bit can be used to flip the logical output of the threshold comparator. I would guess that we have been incorrectly making measurements. Using the calibration pulses will most likely help us determine this.
The comparator section actually has two different sections. The first one (purple) converts the different threshold signal to a AC-coupled digital comparison, the two possible values being a function primarily of the value of the current source and the resistor values.
The second section of the comparator (orange) converts the AC-coupled, digital comparator signal into a DC, digital comparator signal with its voltage now being between the high and low values of the DC voltage supply. Once again, I am not certain how the parameter IComp works with this section. If I had to guess, I would say that this only controls the analogue side of the comparator by swinging the biasing point of this section as well as the bistable values of the output.
One thing that is interesting to note about the comparator section is that this is no indication of how the MSPOLARITY bit in ContReg<0> works. The overall polarity of the comparator in the schematic is the same as that which is coming in. Therefore, it is impossible to tell from this circuit how changing the MSPOLARITY bit has affected the results of our experiment. Ultimately, I believe that we are probably going to have to send some calibration pulses down the lines to determine if all of our polarities are correct.
Let's do the detector off test. I'll lower Vdrift to equal Vgem. This will keep the GEM amps on but turn off the drift. Then lets see what hits we get. We will increase threshold until they go away.
6/29/09
I have successfully been able to write a program, "CalChannels.arm," that will change the CalChan bits for the Even, Odd, or All Channels. To change which of these one uses simply add the option at the end of the program name, e.g. -even, -odd, -on, or -off. The names should speak for themselves at to their functionality. (Right now it only alters the first six channels since that is all one can see on the website.)
I have attempted to use the calibration settings to determine the polarity of the pulses as well as the order of the bits in the data package, but to no avail. I am still a little unclear as to how this works exactly. At first I was trying to use the CalPulse to give me hits I could read out of the VFAT data package, but then I realized that since there was a time delay from sending the CalPulse signal to sending the LV1A pulse on the T1 line, I will probably not be able to use this method unless I set the latency correctly. This may still be an option, although it may take some v1495 firmware tweaking as well since I'm thinking that I may have to send the CalPulse signal immediately before the L1VA signal.
I then tried to send the CalPulse and look at the HitCount register to see if I got a hit or not, but I'm still not exactly sure how the HitCount register is responding to this. I was able to change the value in the HitCount register, but it did not seem to correlate to the Trigger pulses that I was sending. Also, the VFATs do not respond well to single shots of 32Mhz. I tried slowing the MCLK down again to 10kHz, but this did not seem to solve anything.
6/30/09
The following are the questions for Paul Aspel and/or Walt(er?) Snoeys:
The first is a generic question is whether or not there are more reference materials than what we already have (i.e. the VFAT2 Operating Manual and the p292.pdf from the CERN document center). Whether that material would be useful or not most likely depends on whether it addresses the following questions. Of course some of these question might also be answered via a phone call.
What are the relationships between the registers that can be programmed via the I2C, e.g. primary registers 0-9 and extended registers 129-132, and the voltage and current references shown in the front-end schematic of the p292.pdf document? I can somewhat surmise the correlation, but one can see from my previous discussions that there are still too many unanswered questions. Also, can we safely say that this schematic even actually represents the actual circuit used in the design. It seems like there are a lot of missing sections, e.g. how the CalPolarity and MSPolarity bits actually shift things.
Is there more information on exactly how the hit registers work? Where is this information stored in the chip? How do they get set and reset? In particular, if I'm sending a calibration pulse to the channels, shouldn't I see this getting registered as a single hit in the hit counters? (This is with the setup of having HitCountSel<X> all set to zero for fast ORing of the channels, the MSPulseLength<X> set to zero for a one period, and assuming that the VCal is higher than the VThreshold settings.) Also, is there more information on how the calibration timing works and whether it is possible to use the calibration pulse to generate hits on the VFAT2? It would be nice to be able to send a calibration pulse to the outputs and observe these lines getting hits when we call a LV1A command on the T1 line.
Is there a much more detailed discussion somewhere are all of the bit settings in the Control Registers 0,1? I have a lot of questions about these; particularly the most of the MSBs in these registers.
Also, I was wondering if we could find out exactly what algorithm they are using for the CRC on the end of the data package. It claims to be CRC-16, but my efforts to reproduce these checksums using CRC-16 so far have been thwarted.
7/1/09
Although it does not state in the Quartus II help files what the range of acceptable input frequencies is, one is able to get the following error message if too low of a frequency is selected.
Error: Can't implement clock multiplication and clock division parameter values for PLL
"|v1495usr|GEMReadout:I0|PLLBlock:PLL_0|altpll:altpll_component|pll"
Error: inclk0 input frequency of 0.01 MHz for PLL
"GEMReadout:I0|PLLBlock:PLL_0|altpll:altpll_component|pll" must be in the frequency range
of 15.0 MHz to 1000.0 MHz
Therefore, we should probably have two different versions of the firmware: one with the PLL for a target speed of 32Mhz and one without the PLL for a target speeds less than 15Mhz. If we even need to run the v1495 at a speed other than 32Mhz but still higher than 15Mhz, we will have to recompile the firmware with the correct targeted value.
- I'm going to attempt to start writing sections of my thesis today. (I have a feeling that my first attempt will be someone inadequate.)
From the following two pictures I found in the VFAT annals, we can see that the bit order of the channels in the data packet is from the highest down to the lowest channel number. As for figuring out which lines on the GEM detector physically connect to which inputs we need to observe how the lines get routed from the Kapton sheet to the connector. From the connector to the VFAT one can tell by looking in the VFAT manual and subsequently observing the VFAT ASIC and its board where the signals are routed.
ENC = "Equivalent Noise Charge"
The following paper discusses the usage of this term with some simplified noise circuits.
7/2/09
In attempting to figure out exactly how the MCLK works on the VFAT, I finally figured out that not only is MCLK the VFAT synchoronous clock but that the S<1:8> pins are the regional hit trigger output pins that are programmable via the TrigMode<1:0> bits in ContReg<0>. Right now we don't have any connections to these pins so we cannot use them as regional triggers.
I am attempting to reconstruct the CalPulse experiment in order to figure out if our parameters are set correctly. Right now the settings for this experiment are as follows:
MCLK = 40Mhz IPreampIn 0xa8 IPreampFeed 0x50 IPreampOut 0x96 IShaper 0x96 IShaperFeed 0x64 IComp 0x78 MSPulseLength<2:0> = 0x0 // MonoStable pulse length of 1 clock period HitCountSel<3:0> = 0x0 // Fast-OR of all 128 channels Lat 0x21 VCal 0xff VThreshold1 0x10 VThreshold2 0x0 CalPhase 0xc9
The MCLK frequency was chosen because it is the original Calibration pulse frequency at which experiments were run. Also, in the experiment the CalPulse signal supposedly has a peaking time of ~22ns. Thus, if we want to have any hope of catching the calibration pulse, we will most likely need to run at at least 40 Mhz. This, of course, also depends on the peak amplitude of the pulse as well as how long its tail is.
The v1495 firmware performs a straight pass-through of the trigger signal from the pattern generator. Care has been taken to make sure that the signals are passed along while they are stable rather than at a transition. Also, it is known that the MCLK shown in Figure 10 of the VFAT manual is out of phase by 180o; thus care has also been taken to make sure that the T1 signal has the proper phase with respect to MCLK. This whole process causes the signal being output to be one clock cycle behind the signal being injected; this shouldn't be a problem.
The "TRIGGER OUT" signal is used as the MCLK for the VFATs and "OUTPUT1" as the T1 signal for the VFAT. OUTPUT1 is set such that it will output the Calpulse signal followed by a single break pulse and then followed by the LV1A signal. The pattern is long enough that we should be able to see whether we received any hits on the lines that we have CalChan turned on in the respective ChanReg. Right now the experiment is running too quickly and does not have the proper setup to see whether the HitCount registers are working properly with the calibration pulses being sent.
I'm also hoping that I might be able to gate the signal from the pattern generator so that I will be able to use the HitCounter.