Electronics for the Time Projection Chamber (TPC): Difference between revisions

From ift
No edit summary
No edit summary
Line 326: Line 326:
The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported.
The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported.
<br><br>
<br><br>
== DCS board Lattice CPLD-firmware for TPC and PHOS ==
=== Overview ===
The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board. <br><br>
To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage. <br>
To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software. <br><br>
=== Download Section ===
Complete Project: [http://www.ift.uib.no/~alme/wiki/vreg_2006_04_23.zip vreg_2006_04_23.zip]<br>
Programming File: [http://www.ift.uib.no/~alme/wiki/vreg.jed vreg.jed]<br>
ispVM System Project File: [http://www.ift.uib.no/~alme/wiki/vreg.xcf vreg.xcf]<br><br>

Revision as of 09:56, 18 February 2009

DCS board firmware for TPC and PHOS

Overview

Schematic Overview of the DCS firmware for TPC/PHOS

The communication to the firmware in both the Xilinx FPGA and the Actel FPGA on the RCU board is done with the RCU Communication Module. This is done by using a memory mapped interface. The Linux driver writes blocks of data down to a memory in the RCU Communication Module where it is decoded and executed; hence data is being written to or read from the RCU Firmware.

Historically the RCU Communication Module only consisted of the Memory Mapped Communication Mode, but as the reconfiguration circuitry on the RCU board was designed, the need of using the bus lines in different ways arose. In addition to this normal communication path, two other ways to communicate is added, namely the RCU flash interface or the Selectmap interface of the RCU. There are several reasons for having these two interfaces on the DCS board.

  • Speed. Using the default memory mapped mode to communicate with the flash memory is not very efficient. Simply moving the flash interface and the selectmap interface to the DCS board, using the Actel as a route-through firmware makes it much faster.
  • Space. The Actel APA075 has limited capacity. To be able to fit in all the needed functionality, all modules that is not needed in the Actel should be removed.
  • Robustness. Since the Actel is not possible to update after installation, doing potential bugfixes is impossible. Moving firmware modules to the DCS board ensures that communication paths to the Selectmap Interface and the Flash Device will always be available.


Update of the DCS Board Flash Device

There are two ways of updating the DCS board. The cards that are properly set up should read firmware version 2.6uib when logging in, if intended to use together with the RCU. For the Trigger OR and the BusyBox a special firmware has been made. This firmware is available here so in principle is possible to do the updates when needed, but if any questions, please don't hesitate to ask us. If you get cards directly from Heidelberg where they are produced, updates are needed if intended to use with TPC/PHOS.

The ways of updating the boards are given at the DCS page of Tobias Krawutschke. The important thing is that the .hex file is generated here in Bergen. It should be matching the board number written on the board with felt pen.

    Updating the DCS boards:
  1. Using the exc_flash_programmer tool from Altera together with the Byteblaster programmer.
    Then you do as described in under Firmware download - exc_flash_programmer in the link given above. In addition it is of high importance that you use Quartus II versions older or equal to 4.1. At least this is the last version of Quartus II that support the device on the DCS board. Unfortunately Altera won't support us on this any longer since the device is outdated so it is hard to give a precise answer to what might be wrong in case it fails.
  2. Using the tool remoteupdate4.sh
    This is to be run on a remote linux system in the same network as the dcs system. "Srec cat" tool is mandatory. (Can be downloaded from the page of Tobias) The important thing here is that the DCS board needs to be running "correctly" in the first place to be able to do this. Correctly means that you have the network working seamlessly.

Please note that these two ways update the complete Flash Memory, meaning the firmware, the boot section, the Kernel and the file system (the last way makes it possible to choose what part to update). This is sometimes mandatory depending on the firmware version - and it is a lot more "safe" since you then get the latest drivers and software etc...

Version history

1.0 (~april 2004)

  • Made based upon TRD DCS FW version 011.
  • Messagebuffer v1.0 (Torsten Alts orginal version)
  • Virtex driver for programming RCU FPGA included


2.0 (~may 2005)

  • Updated Messagerbuffer
    • new header format


2.1 (12.12.2005)

  • Updated messagebuffer:
    • Fixed the bug of multiread/multiwrite that was introduced with new header format in v2.0.
    • compressing possible (2x16, 3x10, 4x8)


2.2 (05.01.2006)

  • Updated messagebuffer:
    • Bugfix of reset state a state machine in rcu_master module
    • Bugfix in configuration controller on checking the command/address on multiread
    • Bugfix in configuration controller on multiwrite with compressing
    • Fix in the compressing so that the way to count words matches the requirements.
    • When compressing, writing/reading is switched from Big Endian to Little Endian.
    • Included version, mode_select module and flash interface in messagebuffer module
    • Made new set of commands for flash communication
    • Synthesized using precission - using an edf file in Quartus.
    • fw r also resets certain fw modules on the dcs board.
    • Flash interface is reseted whenever flash mode is not selected.
  • Updated ARM stripe
    • Removed Direct PIO Flash interface


Known issues in v2.2:

  • Flash interface can hang. (precautions taken but error may still be there.) FW reset (rcu-sh fw r) or changing mode will clear this problem.


2.3 (27.02.2006)

  • Updated messagebuffer:
    • Multiplexer that chooses to send BunchCount Reset or EventCount Reset to RCU using the Aux4 line. Select by using memory mapped interface on DCS board. Reg addr 0x4A00 selects BunchCount Reset. Reg addr 0x4A01 selects EventCount Reset
    • Mem Mapped Version register added: 8b'day & 4b'Month & 4b'Year & 8b'MajorNumber & 8b'MinorNumber: Reg addr 0xBF00
    • Interrupt (negative polarity) from Slow Control moved to RegFile Address of ARM stripe (0x80000060). Stripe Interrupt address IRW_INT_PLD[5]
    • ComStat register is made more robust using triple redundancy.


2.4 (19.03.2006)

  • RCU Communication Module:
    • Memory size is made generic.
    • Added tristate select input for selectmap mode.
    • Increased timeout period of RCU mem mapped communication to 32 clks
    • Increased length of WE and CE pulses of flash interface
    • Changed tristate select for Flash interface
    • Increased wait time for flash read


2.5 (08.05.2006)

  • VREG Module updated with new version from KIP
  • Timing warnings removed with correct constraints settings
  • Removed all "sensitivity list" warnings in ethernet, jtag, vreg and i2c module.
  • All controlable outputs to RCU (except dcs_ctrl[7:6] = "00") is set to high impedance if output_enable_n = 1 is high.
  • output_enable_n is set by bit 4 in ComStat register


2.6 (01.08.2006)

  • RCU Flash Interface rebuilt to match latest version of Actel FW (v1.3)
  • Better error handling in Flash interface. Checks for RynBy line, as well as bit q(5) of flashdata.
  • Added Comstat(5) as DCS FW reset.
  • Changed rcu_data(15) in Flash mode to input f_rynBy
  • Made a new generic that makes it possible to select the type of Flash of the RCU board. BB = boot sector in the beginning, BT = boot sector at the end.


2.61 Trigger-OR

  • Pinning on DCS-RCU connector changed to match Trigger OR board.
  • Added sm_enable register that is enabled by writing to 0xBF01.
  • Bus data width reduced to 16 bits. The remaining 16 bits are used for SelectMAP interface.
  • SelectMAP interface can be accessed simultaneously as memory mapped interface.


2.62 BUSYBOX

  • Equal to v2.61 but with slightly different pinning on dcs-rcu (busy-logic) connector


Known issues in v2.6x:

  • Minor bug in RCU Master Module. It does not check on mode bit if a new transaction is started on the same clock cycle that the previous is ended.
  • Bug if an error is found in the format of the data block. The next block will not be automatically read if an error condition arises.

As long as the driver is behaving correctly, these bugs will never cause any trouble. They are corrected in the source files, but as for now - a new firmware version will not be built.

2.7 (03.08.2007)

  • Ethernet Module upgraded to increase speed of Ethernet link as described here. Please be aware that this upgrade also means updating the Kernel of the board. If this is not done, the Board will not work.
  • Minor bugs mentioned in v2.6x corrected.

2.71 (12.09.2007) Trigger-OR

  • Same as v2.61, but inlcuding the upgrades given in v2.7

2.72 (12.09.2007) BUSYBOX

  • Same as v2.62, but inlcuding the upgrades given in v2.7


2.8 (14.11.2007)

  • Bugfix concerning the mode settings. The error lead the Actel to go into selectmap mode when rebooting the DCS board. This also lead the prog_b line to go low long enough to sometimes erase the Xilinx. The mode settings has been changed to:
    • "11"/"00" Memory mapped mode
    • "01" Flash mode
    • "10" Selectmap mode.

    The most important is that memory mapped mode is now “11”. This is default state of these lines when the DCS board do not drive the lines during reboot.

  • Removed a register on the reset line (dcs_Ctrl5) to avoid the 80 ns reset pulse whenever the DCS board reboots
  • added a shiftregister on the mode and reset to make sure the lines are stable and asserted at least 8 clks to increase robustness
  • Added register 0xbf02 for setting the system back to old mode settings (by writing 0x01d) for backward compabitility.

2.81 (30.11.2007) Trigger-OR

  • Same as v2.71, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)

2.82 (30.11.2007) BUSYBOX

  • Same as v2.72, but inlcuding the upgrades given in v2.8 (where only the reset bug matters in this setup)

2.83 (15.05.2008) BUSYBOX

  • Routed ttcrx_rdy out on dcs_ctrl7 (otherwise equal to 2.82)

2.84 (08.10.2008) BUSYBOX

  • Added a register on ttcrx_rdy to reduce the load on the net, hence removing the problem with channel A/channel B errors. (otherwise equal to 2.83)



Download Section

Specification document:
RCU_comm_specification_v2.6x.pdf
RCU_comm_specification_v2.8x.pdf

Source files: CVS database

Please note that the armboot.bin file is not supplied with version 2.7 as the Kernel MUST be updated as well. The hex file can be used together with the remoteupdate4.sh script in the following way:
./remoteupdate4.sh dcsflash_boardrev164_firmware2.7uib_dcs0031.hex <board IP/name> armboot | kernel
For detailed instuctions on using the remotesetup look here.

When using remotesetup one should also upgrade:

  • The text-file /etc/version on the DCS board so that the correct FW version is reported on boot up.
  • The text-file /etc/md5sums with the correct checksums. The correct checksums are found on the DCS board like this:
    • Kernel: md5sum /dev/mtd/2
    • Armboot: md5sum /dev/mtd/0



Please note that a different update script has been made for TPC RCU DCS. Contact Dag Toppe Larsen (dagtl at ift.uib.no) for questions.

The bin file can be used directly to change the firmware of the board. This can be done in the following way:

  1. Log onto DCS board.
  2. Remove old firmware: eraseall /dev/mtd/0
  3. Upload new firmware: cat armboot_x.x.bin > /dev/mtd/0
  4. Reboot board

The firmware version is reported when starting the rcu-sh.

The sbi-file is used when building the complete DCS project. This should only be used by experts.

The Quartus project needs to be opened with a version of Quartus prior to 4.2, or else the Excalibur device is not supported.

DCS board Lattice CPLD-firmware for TPC and PHOS

Overview

The Lattice CPLD on the DCS board is in charge of controlling the clock distribution as well as the power regulators on the RCU board. A special design has been made by Venelin Angelov at KIP Heidelberg for use by the TPC and PHOS DCS boards. In this design, the default value of the vreg outputs are X"FFFFF7". This value makes the RCU power up together with the DCS board, as well as feeding a 40 MHz system clock to the RCU board.

To program the CPLD, a Lattice programmer that has the correct pinning to match the DCS board JTAG connector is needed. The ispVM System software is also mandatory. This can be downloaded from the Lattice Homepage.
To program it download the xcf file and the jed file from this site. Open the xcf file with ispVM System and make sure the link in the xcf file points to the location of your harddrive where the jed file is found. Then follow the instructions of the ispVM system software.

Download Section

Complete Project: vreg_2006_04_23.zip
Programming File: vreg.jed
ispVM System Project File: vreg.xcf

Retrieved from "http://ift.wiki.uib.no/index.php?title=Electronics_for_the_Time_Projection_Chamber_(TPC)&oldid=9"