Warren Parsons Log Book

Warren_Parsons_MS_Thesis

This tracks My Daily Progress developing the VFAT readout

VHDL files for v1495

GEMReadout.vhd

The main function routines?

GEMReadout_tb.vhd

GEMRxChannel.vhd

GEMRxEventDataFIFO.vhd

a routine controlling the FIFO

GEMRxEventSizeFIFO.vhd

Defines the Event size and structure

GEMTxChannel.vhd

PLLVBlock.vhd

spare_if_rtl.vhd

tristate_if_trl.vhd

v1495usr.vhd

v1495usr_pkg.vhd

v1495usr_hal.vqm

From the v1495 manual this is the v1495 Hardware Abstraction Layer. It is an HDL module provided in Verilog format at the netlist level in order to help interface the hardware.

Reading through this file makes it clear that we are using the Cyclone chip family. I can't find where the "cyclone_lcell" module is defined. I am wondering if it is defined inside of the Quartus II program in a library somewhere. Figuring this out would probably help unravel how our HDL code is actually instantiated in hardware.

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).

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.

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).

0301 h = 001100000001 b

The module address 80110030 is 30 h away from the base address 0x11.

000001 b = 1 d [math]\Rightarrow[/math] 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

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.

-> 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 dumb 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.

Go back User_talk:Parswarr