Electronics for the Time Projection Chamber (TPC)

From ift
Revision as of 10:42, 10 March 2010 by Nfyku (talk | contribs)

Overview

Sketch of the Readout Control Unit



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

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


v 1.3 (11.02.2009)

  • Corrected a bug introuces in v1.24 that lead to the busy timout being worng when a sequence is only a message.
  • Removed ROI decoding (only commented out) because of area constraints on RCU.
  • Added version number in control/status register



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.

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


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

RCU DCS Interface Module

Overview

Sketch of RCU DCS Interface v0.2

The DCS interface is used to have a single interface towards the master module on the DCS board, hence transalating the extarnal asynchrounos bus protocol to a synchronous one internally on the RCU Xilinx.

One important feature of the DCS board firmware when used together with the RCU is to support three different modes of communication: Normal operation, Flash mode, selectMAP mode. The RCu Xilinx should only be active when in Normal operation, and the DCS interface must make sure that the ports from the Xilinx are not driven when other modes have been set. The DCS interface should ack all addresses except certain adresses that is used in the DCS fw and by the Actel device.

Since there are two bus masters on the RCU Xilinx – the DCS and the SIU – the DCS interface will make use of a bus request/grant scheme for most of the available registers/memories in the RCU. The only registers that do not need a bus request/grant scheme are the register belonging to the Monitoring and Safety Module, since SIU do not have any access to this.

Version

v0.1

  • First proper version of DCS interface supporting all features given in overview.


v0.2

  • Adapted to match new mode settings of dcs fw v2.8.


v0.3 (12.02.08)

  • Added seu error line from the Actel as an input. Inverted it aand masked it with mode pins.
  • Added reset registers (0x2000 = global, 0x2001 = fec, 0x2002 = rcu)
  • Changed the register adresses for the grant and interrupt
  • Added we for msm module and separate data input from msm module


Download Section

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

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

PHOS FEC Board Controller

Overview

Sketch of PHOS FEC Board Controller v3.3

The Front End Electronics in PHOS is consisting of one Readout Control Unit (RCU) and 28 Front End Cards (FECs) connected to the RCU via two separate branches. On each FEC an SRAM based FPGA is situated – the Board Controller. Since the Front End Electronics is physically unavailable when PHOS is fully commissioned it must be possible to check the status via software during operation, and quickly respond to any error situation that might occur.

The purpose of the Board Controller is to read crucial values on the FEC, such as voltages, currents and temperatures. If these values exceed given programmable thresholds the RCU will be notified. If the severity level is considered to be potentially damaging to the board, the RCU will turn off the given FEC.

The PHOS FEC also includes a high voltage section. A very important functionality of the PHOS Board Controller is to set the bias voltage to the charge sensitive amplifiers located in the high voltage section. This must be done since the amplification of the APDs that are used for readout is varying from part to part. This variation is cancelled out with the setting of the DACs that are controlling the bias voltage.

This version of the PHOS BC is based on the TPC BC, adding the extra functionality needed for PHOS, and removing some features that are not needed. The basis for the code is the FMD version that is a VHDL implementation of the TPC BC with some modifications. Major changes have been done to this implementation to make the design more robust.

Version

v3.0 (16.08.2007)

  • Functionally based on PHOS PCM v2.0 (hence the version number)
  • Two command interfaces
    • ALTRO bus interface
    • Special I2C interface
  • Setting of DACs for bias voltage for High Voltage region
  • Interface to 3 ADCs for verifying voltage and current-levels as well as temperatures.
  • Programmable thresholds for flagging errors in ADC values.
  • Monitoring error inputs from Power Regulators
  • Interrupt line to RCU for errors of a severity level craving urgent measures
  • Possible to set the FEC in standby mode by turning off voltage regulators and not reporting any warnings/errors.
  • Radiation environment precautions:
    • Hamming coded ADC threshold settings
    • Hamming coded DAC values
    • TMR of configuration/status register
  • Configurable automatic update of DAC
  • Thresholds, ADC values and DAC values stored in memories.


Functional changes from HUST PCM v2.x

  • Removal of USB communication
  • Removal of Board ID register
  • Hamming encoding and TMR of static registers/memories.
  • Some register remapping.
  • Thresholds and ADC values stored in memories


v3.1 (11.09.2007)

  • Added high and low ADC threshold memory
  • Added new module for verifying ADC values
  • Remapped registers.
  • Configurable number of times (1-3) of same threshold error before interrupt is flagged
  • Added two registers to decide if adc values will be treated as current or voltages.
  • Continously reading ADC not default on.
  • Removed the error testing for unlegal adresses (all adresses are ok, but will not return anything if not defined.)
  • Added an unlock register to make it possible to overwrite certain status registers for debug purposes
  • Changed default state of Slow Control Slave dout from 0 to 1 (Bugfix introduced in 3.0).
  • Bugfix of DAC interface in case of hamming error in last channel of each dac


v3.2 (03.10.2007)

  • Problem with Slow Control Communication attemped solved by making the slave more robust:
    • The slow control now decodes all info on the I2C bus no matter if the card address is correct or not. This is done to make the slow control busy hence masking it for any fake start conditions on the bus. The sda_out line and the internal we signal is masked with a card address ok signal.
    • Added timeout counters for Slow Control Transactor and Receiver
    • Rewrote state machine in I2C Slave to reduce the amount of combinatorics.
    • Added sda_out line to csr 3 register for debug
  • Rewrote state machines in ADC interface to reduce the amount of combinatorics.


v3.3 (17.10.2007)

  • Included support for Sparse Readout:
    • Exact copy of TPC version with a minor change to account for the less ALTROs in PHOS and the special ALTRO addressing of PHOS (0, 2, 3 & 4).
    • Hitmap transmitted by the use of dstb that is a gated version of the readout clock.
    • Added the needed functionality on the driver module to support the BC being ALTRO bus master.
    • Added the needed registers adresses for Sparse Readout. Exact copy of TPC version
    • Please note that this has not been verified properely since there are no support for it in the testbench environment nor the hw environment
  • Rewrote ALTRO interface to one single module with the aim of making it more robust.
  • Minor change in driver to make ppr simulation possible
  • Added another timeout counter for the Slow Control Module and made a count of timeout conditions available in the register map
  • Added a debug register with information on the state of the sda line and test_mg input.


v3.4 (31.10.2007)

  • Added debug counters and registers in the ALTRO interface module:
    • Counters for number of received strobes, and number of generated acks.
    • Information stored concerning the last acked address, and last address not acked.
  • Added Metastability Filter on all control signals and address on the ALTRO Bus to make it even more robust.

The problem with the occasional timeout on the ALTRO bus is still present, but testing has shown the the time-out occurs when the Board Controller receives not valid adresses (for some reason). This proves that with a high certainty the problem is not related to the Board Controller.

v3.5 (30.03.2008)

  • Added registers on the GTL bus drivers to remove the possibility of glitches on the drivers
  • Changed start condition of the readout command detect state machine to make it behave better in ppr simulations
  • Removed debug counters and metastabilityfilter on ALTRO if (but kept information concverning lasted acked and last not acked transaction)

Download Section

Specification/design documentation for Firmware version 3.0
Firmware v 3.0 - VHDL files, including testbench
Quartus Project - Firmware v 3.0
Programming files - Firmware v 3.0
Scripts used for testing - Firmware v 3.0
Please note that the scripts used for testing is based on the FEC placed at branch A, slot 9. The scripts are not commented so a bit of manual decoding can be needed by the user.

Specification/design documentation for Firmware version 3.1
Firmware v 3.1 - VHDL files, including testbench
Quartus Project - Firmware v 3.1
Programming files - Firmware v 3.1


Specification/design documentation for Firmware version 3.2
Firmware v 3.2 - VHDL files, including testbench
Quartus Project - Firmware v 3.2
Programming files - Firmware v 3.2


Specification/design documentation for Firmware version 3.3
Firmware v 3.3 - VHDL files, including testbench
Quartus Project - Firmware v 3.3
Programming files - Firmware v 3.3


Specification/design documentation for Firmware version 3.4
Firmware v 3.4 - VHDL files, including testbench
Quartus Project - Firmware v 3.4
Programming files - Firmware v 3.4


Specification/design documentation for Firmware version 3.5
Firmware v 3.5 - VHDL files, including testbench
Quartus Project - Firmware v 3.5
Programming files - Firmware v 3.5

Source files: CVS database

RCU Auxilliary FPGA Firmware for TPC and PHOS

Overview

Schematic Overview of RCU Auxilliary FPGA firmware v1.3 and v1.4

Any SRAM based FPGA will experience errors in the configuration memory when irradiated with a sufficient large dose. These errors are called single event upsets, and the Xilinx FPGA on the RCU board has the the possibility to reload part of or the complete configuration memory without interrupting operation. The Auxiliary FPGA on the RCU board is in charge of the reconfiguration scheme of the Xilinx FPGA. The reconfiguration is important to prevent the errors in the configuration memory of the Xilinx to have a negative effect on the operation of the data readout chain.

To deal with this task, the firmware on the Aux FPGA needs to be simple and efficient, as general as possible and most importantly; 100% working from the day of installation. With this in mind, as much workload as possible is handed over to the DCS board, making the operation of the firmware a bit more tedious, but much more configurable.



Updating the Actel Firmware

Actel FlashPro Lite

The only possible option to update the Actel Firmware is by using the JTAG connector on the board and the FlashPro Lite programmer, together with the flashpro software tool.
Download the correct version of stp file found on the download section, and start a new project in the flashpro software. Select the stp-file and choose action "program". Wait for a couple of minutes and the Actel should be updated. This can be verified by reading the version-number register.




Updating The RCU Flash Device

When one cannot use rcu-sh to access registers after re-powering the RCU board there is no design for the Xilinx device stored on the RCU Board Flash Device. When powering up the Actel device will immediately start to try and configure the RCU Xilinx. If there are no files in the Flash Device this will fail and the Xilinx will remain braindead.

To configure the flash device you will need a recipe, rcuflashprog tool for upgrading the flash Contents, and the bit file you want to use. Please download the first two here: "User manual for Firmware version 1.3" and "rcuflashprog.rar". The recipe is found in the usermanual under chapter 5.1.1. Please be aware that you should NOT choose to enable scrubbing. (Read the full documentation if you are curious what this is)

The rcuflashprog tool is available with configuration files in the rcuflashprog.rar package. This should be copied to a location on the DCS board (or on a mounted network share preferably) and the rcuflashprog file itself should be executable. The bit file for the Xilinx is found at: CERN EP-ED ALICE TPC.

Be aware of the following

  • There is a small bug in the DCS interface of the RCU Xilinx firmware of the bitfiles given above that prevents the rcuflashprog tool to work. If you then want to update the Flash Device with a new Xilinx design, you must do the following before you do as described in the manual:
    rcu-sh w 0xb112 0xa #Disables autoconfiguration from Flash
    rcu-sh w 0xb002 0x1 #Erases the content on the Xilinx
  • If you have have problems with rcuflashprog or rcu-sh are being stalled during or after programming, opening up a new window and running "rcu-sh driver reset" would help. There is a small bug in the rcuflashprog that might stall the driver sometimes.
  • Before running rcuflashprog you need to be sure that the driver is set to mem mapped mode "rcu-sh sm d" or rcu-sh flash d" depending on the mode it is in.

    • Version History

    v1.0

    • Working revision of rcu CPLD firmware.
    • supported in mem mapped mode:
      • read flash
      • write flash
      • erase complete flash
      • erase sector
      • verify flash
      • init configuration
    • direct selctmap mode tested and verified
    • direct flash mode not tested.


    v1.1

    • Bug fix in direct flash mode - tested and verified working
    • Version register added. address = hB200 (b8'Majornumber & b8'Minornumber)
    • Rearranged Xilinx programming to handle 16 bits words instead of 32 bit words as flash reads only 16 bits and speeded up the process
    • Read of Xilinx selectmap interface is verified working using Mem mapped interface.
    • Verify Flash method removed
    • Status register updated with more status/error information.
    • If circuit comes into error condition, then everything is halted until error condition is cleared. (0xb000 = 0x0)
    • Fixed a bug in the mem mapped interface that made the circuit hang after a "no target answer" transaction.
    • Added continously scrubbing and abort command.

    Known issues in v1.1:

    • After doing a scrubbing (single or continously) it is not possible to execute selectmap commands that sends data from the DCS board. Scrubbing command or init config command is not a problem. The Selectmap interface on the Xilinx seems to go into an error state where it hangs. When this error has occured (status register shows 0x4480), the only option is to do a power cycle of the RCU.


    v1.2

    • Made both DCS control over Flash interface and Selectmap interface generic.
    • Init config supported
    • Scrubbing of complete configuration supported
      • single
      • continous until abort
      • continous # number of cycles
    • Readback frame by frame verification and correcting supported
      • Single step. One frame at the time
      • Continous until abort. Runs complete cycles.
      • Continous # number of times. Runs complete cycles.
    • Counters for Number of Readback Verification errors and number of cycles added.
    • Register for frame with last RB error added. (As given by the sequence the frames are stored in the flash)
    • Register for frame being verified added. (As given by the sequence the frames are stored in the flash.)
    • Status register re-arranged
    • Error register added
    • Command register re-arranged
      • Clear error and clear status added.
      • Added Selectmap Command register
      • Added Flash Command register
    • Flash interface (and DCS control) on Actel removed due to space limitations. Can only read now. DCS does the rest.
    • Removed delay when in between scrub cycles

    Known issues v1.2:

    • The RAM parity error will always be asserted on power up, as the memories then is in an unknown state. Doing a write from the DCS board to all memory locations and then send a clr_error command will clear the error.
    • Init config with one specific programming file has been seen to fail (all others tested has worked). The reason is that the design does not run the startup sequence for a sufficient amount of clock cycles. The Xilinx is programmed but the ports have not been set to an operative mode. There are two ways of going around this problem - and it will work as normal : (1) Increase the stop address in the Flash at 50 addresses or so beyond what is calculated - this will make the clock toggle sufficient amount of times. (2) Simply to do an Xilinx abort command after programming (w 0xb002 0x10).
    • Scrubbing and Frame by frame reconfiguration is dependent on the version of the Xilinx ISE the original bit file is generated with. It has been verified working with one given Xilinx design while failing with a different Xilinx design. It seems that there are some bugs in some versions of Xilinx ISE concerning readback and reconfiguration. Investigations are onegoing.


    v1.3

    • Fixed critical timing issues when doing frame by frame read-back verification
      • Cleaned up state machine in Configuration Controller module
      • Added look up tables and pipelined the readback error counter
      • Synchronized the input control lines for the selectmap bus.
      • Relaxed the timing on the selectmap interface
      • A bit slower operation – but timing is now good.
    • Removed register for reading the last address being written to.
    • Changed reset register to 0xb003
    • Fixed a bug when clearing error register
    • Set continuous scrubbing to read pointer between scrub cycles to refresh registers.
    • The Memories are not in the data-path from the Flash Device to the Selectmap Bus anymore – they are only readable from the DCS board.
    • Added power up detection module that start initial configuration
    • Added stop code register for stopping power up detection module from trying to reconfigure.
    • Added address generator module to save area.
    • Added new generic variable to select type of flash device (BB or BT)
    • Added new memory mapped interface module without support for Flash Interface on Actel (selected by generics)
    • Added synchronizers for the control lines of the Flash Device in direct Flash mode to deal with timing issues.
    • Added f_rynby line to DCS board in direct Flash mode
    • Added output seu_error on dcs_ctrl3 in normal operation mode.

    Known issues in v1.3:

    • The RAM parity error can be asserted if reading a memory location that hasn't been written to as the memory in the Actel will come up in an unknown state. Send a clr_error command will clear the error.
    • When using the Active Partial Reconfiguration file as generated by ISE software, NOOPs must be manually added at the end of the file because of a bug in ISE (v8.2).


    v1.4

    • 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.
    • The SEU_error flag is inverted so that default state is high.
    • Extra robustness has been added to reset line so that the reset must be low for at least 125 ns for the Actel to reset. This is done to make sure glitches do not reset the Actel.
    • Corrected a bug that made the scrubbing counter in continuous scubbing mode increment by 2, instead of 1.



    DCS Software Tools for operating the Actel

    Three software tools has been developed by Dominik Fehlker (dfehlker at HTWM.De) for operating the Actel Firmware and the onboard Flash Memory of the RCU. These tools are small command-line tools that does different tasks:

    1. framegen - This tool generates all the frames that shall be stored on the RCU flash and be used for comparison when doing frame by frame reconfiguration. The tool uses a frames.txt configuration file for selecting which frames to generate, and for each frame three files are created: raw frame file, write frame file (raw file including write header and footer) and read frame file (raw file including read header and footer).
    2. framever - This tool making use of step by step frame reconfiguration and is used as a DCS check on the number of errors in the frames, writing an error log that is more detailed than what the actel FW is capable of.
    3. rcuflashprog - This tool is used to program the Flash on the RCU board with the configuration files for the Xilinx. It reads a configuration file to state what will be programmed to where on the flash.

    Detailed instructions on how to use the tools is found in a README file in the tar-archives. The tools should be run on a mounted folder on the DCS board. These tools will eventually be integrated in the FEE server.

    More information on how to use frame by frame reconfiguration to be added.

    Updates of these tools will come in the near future.

    Download Section

    Preliminary documentation for Firmware version 1.1
    Firmware v 1.1 programming file

    Preliminary documentation for Firmware version 1.2
    Firmware v 1.2 programming file

    User manual for Firmware version 1.3
    Preliminary documentation for Firmware version 1.3(Updated 8. Nov 2006)
    Firmware v 1.3 programming file

    User manual for Firmware version 1.3 (and 1.4)
    Preliminary documentation for Firmware version 1.4
    Functional Test report for Firmware version 1.4 (also included in the documentation)
    Firmware v 1.4 programming file

    Source files: CVS database

    For assosiated information concerning software and software tool download section, go to: The Actel software device in the FeeServer CE

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