V1495 Module by CAEN - Revision history

Oborn: /* Verilog Modules */

2010-04-12T22:35:53Z

Verilog Modules

Oborn at 03:16, 28 March 2010

2010-03-28T03:16:03Z

Oborn: /* GEMReadout Firmware */

2010-03-28T03:14:58Z

GEMReadout Firmware

Show changes

Oborn: /* Addressing the V1495 */

2010-03-28T03:08:48Z

Addressing the V1495

Oborn at 03:05, 28 March 2010

2010-03-28T03:05:16Z

Show changes

Oborn: /* Overview of V1495 Module */

2009-10-29T02:12:24Z

Overview of V1495 Module

Oborn: /* Overview of V1495 Module */

2009-10-29T02:04:15Z

Overview of V1495 Module

Oborn: /* V1495 Module by CAEN */

2009-10-25T04:17:22Z

V1495 Module by CAEN

Oborn: /* V1495 Module by CAEN */

2009-10-25T03:20:29Z

V1495 Module by CAEN

Oborn: /* V1495 Module by CAEN */

2009-10-13T19:24:49Z

V1495 Module by CAEN

Show changes

← Older revision		Revision as of 22:35, 12 April 2010
Line 179:		Line 179:

	http://www.altera.com/support/software/nativelink/synthesis/synplicity/eda_view_using_synplty.html		http://www.altera.com/support/software/nativelink/synthesis/synplicity/eda_view_using_synplty.html
		+
		+
		+
		+
		+
		+	[[Warren_Parsons_MS_Thesis]]

← Older revision		Revision as of 03:16, 28 March 2010
Line 1:		Line 1:
	[[Warren_Parsons_MS_Thesis]]		[[Warren_Parsons_MS_Thesis]]
		+
		+	<pre> In preparing this section I noticed that some of the variable references got confused. I will update these shortly.</pre>

	=Chapter 2=		=Chapter 2=

@@ Line 42: / Line 42: @@
 It is important to note that the VME bus address is different than the memory-mapped logical address for the board as referred to by the PowerPC controller. For most of the functions written  for the Read Out Controller (ROC), these will reference the PowerPC logical address rather than the VME bus address. The one major exception for this is the v1495Init() function which uses the VME bus address to check for the presence of the V1495 and then returns the logical memory address. More on this function is described in the sections on the ROC software.
 For this project we have set the address lines of the V1495 to the hex values “0811” respectively. As can be seen in the silk screen print on the board in Figure 2-3: HEX Address Switches on V1495, this is the base address for the 32 most significant bits in the VME bus address (BASE ADDRESS [31:16]). This, of course, signifies that the V1495 uses a 32-bit addressing scheme. According to the V1495 User Manual 24-bit addressing should also be possible, but we have not used this.
 Determining the exact relationship between the VME bus address and the ROC memory address has proven difficult and at best one can only surmise that the two are related by a simple offset of 0x7800_0000. With the VME bus address of 0x0811_0000 this gives a memory address of 0x8011_0000.
 All register addresses in the V1495 are located using this offset plus their respective addresses. These registers can essentially be divided into to different classes: Register addresses 0x0000 – 0x7FFC are the USER FPGA Access registers and register addresses 0x8000 – 0x801FE contain the V1495 CAEN interface r©egisters.
 The USER FPGA registers are determined in the v1495usr_pkg.vhd module. Table 2-1: USER FPGA Registers and “struct” Equivalents shows these registers with their “struct” equivalents in the ROC software. These registers contain most of the pertinent information being communicated between the V1495 and the ROC: for example, A_GEMA0_EVENTDATA, address 0x4000, contains the information from the top of the DataFIFO for the first VFAT detector when requested.
 The V1495 CAEN interface registers contain information on the V1495 board itself as well as controlling how to reflash and reset the VME and USER FPGAs. A discussion of these functions would be superfluous and as such the reader is referred to the V1495 User Manual pg. 17-21.
 Brief Overview of FPGAs
 FPGAs or “Field Programmable Gate Arrays” are electronic ICs -- typically digital -- that have the ability to be reprogrammed for different purposes. Quite often these circuits are used in the initial design phases of an IC when a hardwired circuit would be much more costly to produce for each revision of the product. Once the IC has been proven to work correctly, the design can then become hardwired onto an IC that can be mass produced.
 In our experiment, we also use FPGAs for their ability to be reprogrammed, but we do not intend on mass-producing a hardwired version of our IC. We simply use its reprogrammable abilities to perform our highly specialized functionality. In this instance, we control the LVDS T1 signal going to the VFATs, extract the LVDS packets from the VFAT, store the data, and then pass it on to the ROC.
 When referring to electronics, HDL stands for “Hardware Description Language”. It is the term used for the code that describes hardware layout. For this reason it is also commonly referred to as “firmware” as it is neither completely software nor hardware. There are many different HDL languages, but the only two utilized for this project are VHDL (Very High Speed HDL) and Verilog. Most of the modules that the user will even want to change are those in VHDL; it is therefore recommended that if one wants to alter the user firmware for the V1495 that one spends most of one’s time learning VHDL. There is only one module in Verilog, V1495usr_hal.vqm, the purpose of which is described in its respective section.
 HDL’s utility lies in its ability to describe hardware using a behavioral, a dataflow, or a structural model to describe the circuit one wants to build.
 A behavioral model is one in which the user uses more traditional software flow-control statements to control the logical properties of the circuit; at this level in VHDL, these include “Process” statements, “If” statements, “Case” statements, Loop statements (e.g. “Do”, ”While”), “Next”/”Exit” statements, as well as “NULL” statements. It is at this level that the classic Mealy and Moore state machines are implemented.
 Dataflow modeling is similar to behavioral modeling except instead of using flow-control similar to other traditional programs, one uses concurrent assignment operators to control the logical flow of data with operators such as “OR”, “AND”, “XOR”, etc. It has some conditional control like behavioral modeling, but it remains more low-level. It is conceivable that we could have used this form of modeling for the register-access modules, but these modules are in behavioral form of modeling.
 Structural modeling is virtually a literal translation of traditional digital logic symbols (e.g. AND-gates, OR-gates, etc) into a software format. In structural modeling one uses previously-defined components to create the necessary logical operations by connecting their I/O’s properly. This form of modeling is very similar to Object Oriented Programming; the components can be thought of as the classes and the logical flow can be thought of as using the specific instantiations of the classes/components. For this thesis, we do not utilize this form of modeling either.
 Brief Overview of Quartus II
 Instructions for Downloading and running Quartus II
 For this project we use the free Quartus II Web Edition Software. At the time of publication for this thesis, it is available at the following web address:  http://www.altera.com/products/software/quartus-ii/web-edition/qts-we-index.html
 Fortunately, for the purposes of this project, we only need to use it for its ability to handle and compile modules for the Cyclone family of FPGAs. It is, however, also useful for viewing the “Help” files on a number of modules in this project as well as viewing the pinouts for the FPGA (Assignments->Pins menu in Quartus). Although this level of detail is not necessary for this project, it does help one understand which signals are internal to the FPGA and therefore capable of being altered by the user firmware on the v1495, and which signals are external to the FPGA and not capable of being altered by the user firmware.
 V1495_USR_firmware
-Overview
+==V1495_USR_firmware==
 The V1495_USR_firmware is provided by CAEN for the purpose of demonstrating how to use the v1495 module. This firmware is provided as well on the CD included with this thesis but can also be found on CAEN’s website. A number of functions are provided to introduce the V1495 user to the utilities of the V1495.
 GEMReadout Firmware
-VHDL Modules
+==GEMReadout Firmware==
 v1495usr.vhd
 This is the lowest hierarchical level for V1495 user firmware. It includes all of the I/Os as can be seen on the Pinout for the project. The Pinout for any project in Quartus II can be found in the Assignments->Pins menu.
 tristate_if_rtl.vhd
 This module simply contains the logic necessary to control the direction of the FPGA data bits found in v1495usr.vhd and the logic to control the direction of the bidirectional I/Os associated with the VME data bus. Although there is probably little reason to change this section of code a brief description is provided below.
 By default the FPGA data bits are set at High-Z (as can be seen by following the signal into v1495usr_hal.vqm). Since these bits are not used in this project this is of little consequence.

@@ Line 8: / Line 8: @@
 ===Overview of V1495 Module===
-The CAEN V1495 is a VME 6U board, 1U wide, suitable for various digital Gate/Trigger/Translate/Buffer/Test applications, which can be directly customized by the User, and whose management is handled by two Field Programmable Gate Arrarys (FPGA’s): FPGA “Bridge”, which is used for the VME interface and for the connection between the VME interface and the 2nd FPGA (FPGA “User”) through a proprietary local bus. FPGA “Bridge” manages also the programming via VME of the FPGA “User”. FPGA “User”, which manages the front panel I/O channels. FPGA “User” is provided with a basic firmware which allows to perform coincidence matrix, I/O register and asynchronous timers functions.
+The CAEN V1495 is a VME 6U board, 1U wide, suitable for various digital Gate/Trigger/Translate/Buffer/Test applications, which can be directly customized by the User, and whose management is handled by two Field Programmable Gate Arrarys (FPGA’s): FPGA “Bridge”, which is used for the VME interface and for the connection between the VME interface and the 2nd FPGA (FPGA “User”) through a proprietary local bus. FPGA “Bridge” manages also the programming via VME of the FPGA “User”. FPGA “User”, which manages the front panel I/O channels. FPGA “User” is provided the basic firmware needed set up a coincidence matrix on the input signals as well as I/O register and asynchronous timers functions.
 FPGA “User” can be also free reprogrammed by the user with own custom logic function (see § 5.1). It is connected as slave to the FPGA “Bridge” via CAEN Local Bus, whose protocol shall be used in order to communicate with the FPGA “Bridge” and thus with the VME bus.<ref>From the V1495 User Manual</ref>

@@ Line 8: / Line 8: @@
 ===Overview of V1495 Module===
-The Mod. V1495 is a VME 6U board, 1U wide, suitable for various digital Gate/Trigger/Translate/Buffer/Test applications, which can be directly customised by the User, and whose management is handled by two FPGA’s: FPGA “Bridge”, which is used for the VME interface and for the connection between the VME interface and the 2nd FPGA (FPGA “User”) through a proprietary local bus. FPGA “Bridge” manages also the programming via VME of the FPGA “User”. FPGA “User”, which manages the front panel I/O channels. FPGA “User” is provided with a basic firmware which allows to perform coincidence matrix, I/O register and asynchronous timers functions.
+The CAEN V1495 is a VME 6U board, 1U wide, suitable for various digital Gate/Trigger/Translate/Buffer/Test applications, which can be directly customized by the User, and whose management is handled by two Field Programmable Gate Arrarys (FPGA’s): FPGA “Bridge”, which is used for the VME interface and for the connection between the VME interface and the 2nd FPGA (FPGA “User”) through a proprietary local bus. FPGA “Bridge” manages also the programming via VME of the FPGA “User”. FPGA “User”, which manages the front panel I/O channels. FPGA “User” is provided with a basic firmware which allows to perform coincidence matrix, I/O register and asynchronous timers functions.
 FPGA “User” can be also free reprogrammed by the user with own custom logic function (see § 5.1). It is connected as slave to the FPGA “Bridge” via CAEN Local Bus, whose protocol shall be used in order to communicate with the FPGA “Bridge” and thus with the VME bus.<ref>From the V1495 User Manual</ref>

← Older revision		Revision as of 04:17, 25 October 2009
Line 6:		Line 6:


−	Overview of V1495 Module	+	===Overview of V1495 Module===

	The Mod. V1495 is a VME 6U board, 1U wide, suitable for various digital Gate/Trigger/Translate/Buffer/Test applications, which can be directly customised by the User, and whose management is handled by two FPGA’s: FPGA “Bridge”, which is used for the VME interface and for the connection between the VME interface and the 2nd FPGA (FPGA “User”) through a proprietary local bus. FPGA “Bridge” manages also the programming via VME of the FPGA “User”. FPGA “User”, which manages the front panel I/O channels. FPGA “User” is provided with a basic firmware which allows to perform coincidence matrix, I/O register and asynchronous timers functions.		The Mod. V1495 is a VME 6U board, 1U wide, suitable for various digital Gate/Trigger/Translate/Buffer/Test applications, which can be directly customised by the User, and whose management is handled by two FPGA’s: FPGA “Bridge”, which is used for the VME interface and for the connection between the VME interface and the 2nd FPGA (FPGA “User”) through a proprietary local bus. FPGA “Bridge” manages also the programming via VME of the FPGA “User”. FPGA “User”, which manages the front panel I/O channels. FPGA “User” is provided with a basic firmware which allows to perform coincidence matrix, I/O register and asynchronous timers functions.