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

From ift
(New page: === Overview === thumb|350px|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 RC...)
(No difference)

Revision as of 09:53, 18 February 2009

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

RCU Trigger Receiver Module

Overview

Sketch of RCU Trigger Receiver v1.1

Triggers are used to initiate a read out of data in the TPC/PHOS sub-detector. The triggers and associated data are received on the DCS board from the trigger system via an optical cable interface. The receiver of the data is the TTCrx; an ASIC on the DCS board. The TTCrx chip is directly connected to the onboard FPGA on the DCS board. In addition, two lines – the L1Accept trigger and the serial B channel, are routed to the FPGA on the RCU board. The data on the serial B channel is the raw data coming directly from the Trigger System.

The onboard FPGA on the DCS board cannot be used to receive the trigger data, as it is sensitive to Single Event Functional Errors (SEFIs) because of the radiation environment. If a SEFI occurs in the DCS board FPGA valid events might be lost.

To prevent this, the Trigger Receiver Module is designed. This is a part of the RCU FPGA firmware, instead of using the internal TTCrx logic for this task. The Trigger Receiver Module decodes serial B messages and L0/L1 triggers. In this way, all sensitive data is decoded and stored in the FPGA of the RCU board, on which measures has been developed to prevent the failures due to radioactive effects (see RCU Auxilliary FPGA).

In addition, the Trigger Receiver circuit is to be used on the Trigger Busy Logic Board. The purpose of this board is to let the CTP know when the event-buffers on the FEE are full, i.e. that no more triggers can be accepted. The CTP will not send additional triggers as long as the busy signal is asserted.

To set the busy signal the received event id that is decoded with the Trigger Receiver Module, is compared with the event id that the DRORCs reports to have received. Depending on the size of the buffers, which can be 4 or 8 events, the busy will be asserted if the number of triggers received is 4 or 8 more than the number of events reported to be received by the slowest DRORC.

Version

v1.0

  • Decoding serial B input
    • Broadcast messages
    • Individual addressed messages
  • Hamming decoding of serial B message
    • Repair and count single bit errors
    • Count other errors
  • Generation of Level 2 accept, Level 2 reject and RoI trigger
  • Generation of eventcount reset and bunchcount reset from serial B broadcast messages.
  • Counters: level 1 accept, level 2 accept, level 2 reject and RoI triggers.
  • Verification if L2a+L2r = L1a
  • Testmode that simulates arrival of serial B messages.
  • Handling of transmission errors etc.
  • Memory mapped interface.
  • Trigger info outputs for data assembler


v1.1

  • Redesigned most parts of the module.
  • Supports both RCU and Trigger Busy Logic Board.
  • Decoding serial B input
    • Broadcast messages (bunchcount reset, eventcount reset, pre-pulse)
    • Individual addressed messages (L1a, RoI, L2a, L2r)
  • Decode L1a line to L0 trigger and L1a trigger.
  • Hamming decoding of serial B message.
  • Report, repair and count single bit hamming errors
  • Report and count other errors, including double bit hamming errors, message decoding error and seqeunce validation errors
  • Generation of L0, L1a, L2a and L2r trigger
  • Decoding of RoI is optional and can be enabled in the Control/Status register
  • Status output showing if run is ongoing. (Between vanguard and rearguard trigger.)
  • Counters: Internal bunchcounter, trigger counters, message counters and error counters.
  • Reporting transmission errors etc
  • Reporting timeouts and sequence errors.
  • Memory mapped interface.
    • RCU Version with 32 bit bidir data-bus.
    • Trigger Busy Logic Version with 16 bit bidir data-bus.
  • FIFO with header words and event information for data assembly
  • Generic debug-mode with possibility to read out FIFO from DCS board, more debug registers and a simple simulation of arrival of trigger sequences.


v1.2 (13.12.2007)

  • Sample serial B and L1 accept line on falling edge.
  • Remake of L1a decode module to simplify it.
  • Remake of Adressed message decoder:
    • Added FEE reset decoding
    • It is now possible that messages come in between each other (L2H-L2D-L1H-L1D-L2D .. etc)
  • Remake of Sequence Validator module so that the time windows can overlap to the extreme (this was not possible earlier
  • Some modoifications to the Error and infor register
  • Added Phase check module to store in what phase of the sampling clock the trigger arrives
  • Control registers slighlt changed
  • All latencies now given with respect to L0 trigger instead of BC0


v 1.21 (29.05.2008)

  • Corrected the version information in the CDH.
  • Bugfix in the phase-check module. The stored phase is no longer cleared when an L2 trigger arrives


v 1.22 (30.05.2008)

  • Added input meb_depth and a meb_mask_enable to control register. This will make it possible to constrain the FIFO to store only the number of header as multi event buffers. Any trigger sequences received if MEBs are full are masked completely.


v 1.23 (12.06.2008)

  • Removed input meb_depth and a meb_mask_enable to control register.
  • Removed test for RoC = 0 when physics trigger as this was not correct
  • Added input meb_full and ddl_rdy_rx and enable_trigger_input_mask to control register. The enable_trigger_input mask will enable the meb_full_flag or the ddl_rdy_rx flash to mask out any incoming triggers. In addition it will constrain the FIFO to only be able to store 8 events


v 1.24 (13.01.2009)

  • Changed the sequence validator so that a sequence can only consist of messages. This will generate a CDH to be stored to the FIFO.
    This is done based on request since an L1a trigger with wrong latency may cause a L1r sequence and an orphan L1/L2 message. With this fix the latter will generate a sequence (with errors).



Download Section

Preliminary documentation for Firmware version 1.0
Firmware v 1.0 - VHDL files, including testbench
Xilinx Project used for test - Firmware v 1.0
Xilinx xc2vp7 programming file - Firmware v 1.0


Specification/design document for Firmware version 1.1
Firmware v 1.1 - VHDL files, including testbench
Firmware v 1.1 - HW scripts. Do files for Questasim and Questasim project file.
Xilinx Project used for test - Firmware v 1.1
Xilinx xc2vp7 programming file - Firmware v 1.1 (debug mode)

Note 16.8.2007: Please note that there have been minor updates to version 1.1 so the Xilinx project contain a slightly different version than the source files does.
 The differences are: - Possibility to select what events will be stored in the FIFO in the configuration registers by setting some mask bits
- Changed the readout speed of the FIFO so that it is possible to keep the read_enable high and new data will come on each clock cycle.
- Added read_counter as an output. This counter shows what word in the header is currently being read out by the FIFO.

Specification/design document for Firmware version 1.2 (Updated 13.05.08)
Firmware v 1.2 - VHDL files, including testbench
Xilinx Project used for test - Firmware v 1.2
Xilinx xc2vp7 programming file - Firmware v 1.2 (debug mode)

Firmware v 1.21 - VHDL files, including testbench

Specification/design document for Firmware version 1.22
Firmware v 1.22 - VHDL files, including testbench

Specification/design document for Firmware version 1.23
Firmware v 1.23 - VHDL files, including testbench

Firmware v 1.24 - Only updated sequence validator. Download version 1.23 and replace sequence_validator with this file.


All source files and more can be downloaded from the CVS database.

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