GithubHelp home page GithubHelp logo

evka85 / gem_amc Goto Github PK

View Code? Open in Web Editor NEW
0.0 4.0 11.0 638.68 MB

GEM uTCA AMC common firmware logic as well as board specific implementations for GLIB (Virtex 6) and CTP7 (Virtex 7)

VHDL 59.90% Python 0.31% Shell 33.64% Tcl 0.19% Makefile 0.01% C++ 0.02% C 0.01% HTML 0.01% Verilog 1.74% V 4.19%

gem_amc's Introduction

GEM AMC Firmware Project

This repository contains sources for common GEM AMC firmware logic as well as board specific implementations for GLIB (Virtex 6) and CTP7 (Virtex 7). Note that this repository excludes ISE / Vivado project directories entirely to avoid generated files, although XISE / XPR files are included in directories called work_dir. Those XISE / XPR files are referencing the source code outside work_dir and once opened will generate an ISE / Vivado project in the work_dir. PLEASE DO NOT COMMIT ANY FILES FROM THE WORK_DIR OTHER THAN XISE / XPR!!!

In scripts directory you'll find a python application which takes an address_table (provided) and inserts the necessary VHDL code to expose those registers in the firmware as well as uHAL address table, documentation and some bash scripts for quick CTP7 testing.

CTP7 Optical Interface

CTP7 has 3 CXP transceivers (the ones that stick out of the board), and 3 MiniPOD receivers, and 1 MiniPOD transmitter, but all 4 MiniPODs are connected to a single MTP48 interface where each of them have a row of 12 fibers.

The CXP transceivers are numbered top to bottom starting at 0, so CXP0 is the top transceiver, and CXP2 is the bottom one.

For the miniPOD channels we'll refer to them as MTP48 row 1-4 channel 1-12. Usually an MTP48-to-4xMTP12 cable is used on this interface, which breaks out each row into a separate MTP12 connector, and normally they are labeled 1-4, referring to the rows as counted from top to bottom, which should match our row numbering here.

Below are the connection tables for the different GEM stations:

GE1/1 map:

OH GBT0 GBT1 GBT2 Trig0 Trig1
OH0 CXP0 ch 1 CXP0 ch 2 CXP0 ch 3 MTP48 row 3 ch 5 MTP48 row 3 ch 6
OH1 CXP0 ch 4 CXP0 ch 5 CXP0 ch 6 MTP48 row 3 ch 7 MTP48 row 3 ch 8
OH2 CXP0 ch 7 CXP0 ch 8 CXP0 ch 9 MTP48 row 3 ch 9 MTP48 row 3 ch 10
OH3 CXP0 ch 10 CXP0 ch 11 CXP0 ch 12 MTP48 row 3 ch 11 MTP48 row 3 ch 12
OH4 CXP1 ch 1 CXP1 ch 2 CXP1 ch 3 MTP48 row 2 ch 1 MTP48 row 2 ch 2
OH5 CXP1 ch 4 CXP1 ch 5 CXP1 ch 6 MTP48 row 2 ch 3 MTP48 row 2 ch 4
OH6 CXP1 ch 7 CXP1 ch 8 CXP1 ch 9 MTP48 row 2 ch 5 MTP48 row 2 ch 6
OH7 CXP1 ch 10 CXP1 ch 11 CXP1 ch 12 MTP48 row 2 ch 7 MTP48 row 2 ch 8
OH8 CXP2 ch 1 CXP2 ch 2 CXP2 ch 3 MTP48 row 2 ch 9 MTP48 row 2 ch 10
OH9 CXP2 ch 4 CXP2 ch 5 CXP2 ch 6 MTP48 row 2 ch 11 MTP48 row 2 ch 12
OH10 CXP2 ch 7 CXP2 ch 8 CXP2 ch 9 MTP48 row 1 ch 9 MTP48 row 1 ch 10
OH11 CXP2 ch 10 CXP2 ch 11 CXP2 ch 12 MTP48 row 1 ch 11 MTP48 row 1 ch 12

GE2/1 map (note that the trigger links are only used on the legacy v1 electronics):

OH GBT0 GBT1 Trig0 Trig1
OH0 CXP0 ch 1 CXP0 ch 2 MTP48 row 3 ch 5 MTP48 row 3 ch 6
OH1 CXP0 ch 3 CXP0 ch 4 MTP48 row 3 ch 7 MTP48 row 3 ch 8
OH2 CXP0 ch 5 CXP0 ch 6 MTP48 row 3 ch 9 MTP48 row 3 ch 10
OH3 CXP0 ch 7 CXP0 ch 8 MTP48 row 3 ch 11 MTP48 row 3 ch 12
OH4 CXP0 ch 9 CXP0 ch 10 MTP48 row 2 ch 1 MTP48 row 2 ch 2
OH5 CXP0 ch 11 CXP0 ch 12 MTP48 row 2 ch 3 MTP48 row 2 ch 4
OH6 CXP1 ch 1 CXP1 ch 2 MTP48 row 2 ch 5 MTP48 row 2 ch 6
OH7 CXP1 ch 3 CXP1 ch 4 MTP48 row 2 ch 7 MTP48 row 2 ch 8
OH8 CXP1 ch 5 CXP1 ch 6 MTP48 row 2 ch 9 MTP48 row 2 ch 10
OH9 CXP1 ch 7 CXP1 ch 8 MTP48 row 2 ch 11 MTP48 row 2 ch 12
OH10 CXP1 ch 9 CXP1 ch 10 MTP48 row 1 ch 9 MTP48 row 1 ch 10
OH11 CXP1 ch 11 CXP1 ch 12 MTP48 row 1 ch 11 MTP48 row 1 ch 12

CTP7 Notes

To run chipscope follow these steps:

  • SSH into CTP7 and run: xvc <ip_of_the_machine_directly_talking_to_ctp7>
  • If running Vivado on a machine that's not directly connected to the MCH, open a tunnel like so: ssh -L 2542:eagle34:2542 <host_connected_to_ctp7>
  • Open Vivado Hardware Manager, click Auto Connect
  • In TCL console run: open_hw_target -xvc_url localhost:2542 (if not using tunnel, just replace localhost with CTP7 IP or hostname)
  • Once you see the FPGA, click refresh device to get all the Chipscope cores in your design

CTP7 doesn't natively support IPbus, but it can be emulated. In this firmware the GEM_AMC IPbus registers are mapped to AXI address space 0x64000000-0x67ffffff using an AXI-IPbus bridge. IPbus address width is 24 bits wide and it's shifted left by two bits in AXI address space (in AXI the bottom 2 bits are used to refer to individual bytes, so they're not usable for 32bit word size). So to access a give IPbus register from Zynq, you should do: mpeek (0x64000000 + (<ip_bus_reg_address> << 2)) for reading and mpoke (0x64000000 + (<ip_bus_reg_address> << 2)) for writing. So e.g. to write 0x1 to IPbus reg 0x300001, you would run mpoke 0x64c00004 0x1 (or simply use the provided ipb_read.sh and ipb_write.sh which will do that for you. You can also use the provided ctp7_status.sh script (generated), which will read and print all the readable registers of a given firmware module. In IPbus address the top 4 bits [23:20] are dedicated to selecing a GEM_AMC module (see scripts/address_table for more info). Module 0x4 is OH reg forwarding where addressing is [19:16] - OH number, [15:12] - OH module, [11:0] - address within modulem (remember to shift 2 bits up when translating to AXI address space). To read and write the IPbus registers using uHAL, you can use an application, developed by WU that can be run on Zynq linux and emulates IPBus master. Compiled binary is included in scripts directory here, the source repository is here: https://github.com/uwcms/uw-appnotes/ (see docs directory for instructions on compiling applications for the Zynq processor)

gem_amc's People

Contributors

andrewpeck avatar evka85 avatar jsturdy avatar mexanick avatar robertdkingjr avatar

Watchers

 avatar  avatar  avatar  avatar

gem_amc's Issues

[Version 3.7.0] Address tables only contain 12OH's

When testing the new CTP7 firmware release (3.7.0), I noticed that the address tables present with the bitfile release do not contain the 12OH's, but only 4.

This can also be seen in the repository code :

<node id="OH${OH_IDX}" address="0x0"
description="Optohybrid ${OH_IDX}"
generate="true" generate_size="4" generate_address_step="0x00010000" generate_idx_var="OH_IDX">

After correcting the "new address table", as it is named is the archive, I was able to communicate with the 12OH's with the gem_reg.py tool.

[feature request] Package scripts into RPM for installation

As discussed with @evka85, and in cms-gem-daq-project/gemctp7user#41, creating an RPM package for the scripts in this repository that are necessary to install on the CTP7 is the best way forward.
In addition, the bitfile and address table can be packaged in this way, and versioned dependencies with, e.g., ctp7_modules can be enforced

  • Should just need a basic Makefile with a make rpm target, and a simple spec template.
  • Probably doesn't need to include gembuild, but could be added as a submodule if necessary

clean_up

The ctp7/apps/* can be removed. All the code is stored elsewhere now. The only remaining thing is where do we keep the rw_reg.py

Bug Report: Divergence Between scripts on CTP7 and XHAL used in Central Repo

Right now for example on eagle60 we have divergent behaviour of apps/reg_interface see for example:

drwxr-sr-x    5 texas    texas         4096 Feb 22 00:00 apps
drwxr-sr-x    5 texas    texas         4096 Feb 16  2017 apps_NOT_WORKING_MISHAS
drwxr-sr-x    7 texas    texas         4096 Feb 16  2017 apps_bkp

Right now it's unclear which set of scripts should be used or supported and how a developer (but non-expert) can use a CTP7 without intervention by @mexanick or @evka85 for tasks (like updating the lmdb).

Additionally the expect format of the address tables has diverged and this is related too #20.

To standardize things and continue central support @evka85 could you:

  1. Make a pull request of scripts you would like supported to the central xhal repository,
  2. Report any bugs with those scripts encountered using bug reports to the xhal repository via this template, and
  3. Migrate this repository into the cms-gem-daq-project umbrella project so that other developers can take advantage the infrastructure setup there.

@jsturdy @andrewpeck @mexanick @evka85

Feature Request: Unify Address Table Format

For the v2b electronics the address table goes as:

"GEM_AMC.OH.OH%d.GEB.VFATS.VFAT%d"%(gtx,chip)

For the v3 electronics the address table goes as:

"GEM_AMC.OH.OH%d.GEB.VFAT%d"%(gtx,chip)

In both cases gtx=OH link number and chip=vfat number.

Request to have the v3 electronics address table format conform to the v2b address table format. This will simplify the task of writing SW that is compatible with both v2b and v3 HW.

Naming conventions with releases

In the gemctp7user tools repo we rely on being able to specify a release version and getting the corresponding files.
Currently, this is muddled by mixing different era files within a given "release".
While understandable from a pre-release perspective, it would be best if when a release becomes "final" it always has the same convention.
The expectation (based on previous releases) is that this will always work:

    then
        echo "CTP7 firmware fw/gem_ctp7_v${ctp7fw//./_}_GBT.bit missing, downloading"
        echo "wget https://github.com/evka85/GEM_AMC/releases/download/v${ctp7fw}/gem_ctp7_v${ctp7fw//./_}_GBT.bit -O fw/gem_ctp7_v${ctp7fw//./_}_GBT.bit"
        wget https://github.com/evka85/GEM_AMC/releases/download/v${ctp7fw}/gem_ctp7_v${ctp7fw//./_}_GBT.bit -O fw/gem_ctp7_v${ctp7fw//./_}_GBT.bit
    fi

    echo "ln -sf gem_ctp7_v${ctp7fw//./_}_GBT.bit fw/gem_ctp7.bit"
    ln -sf gem_ctp7_v${ctp7fw//./_}_GBT.bit fw/gem_ctp7.bit

    if [ ! -f "xml/gem_amc_top_${ctp7fw//./_}.xml" ]
    then
        echo "CTP7 firmware xml/gem_amc_top_${ctp7fw//./_}.xml missing, downloading"
        echo "wget https://github.com/evka85/GEM_AMC/releases/download/v${ctp7fw}/address_table_v${ctp7fw//./_}_GBT.zip"
        wget https://github.com/evka85/GEM_AMC/releases/download/v${ctp7fw}/address_table_v${ctp7fw//./_}_GBT.zip
        echo "unzip address_table_v${ctp7fw//./_}_GBT.zip"
        unzip address_table_v${ctp7fw//./_}_GBT.zip
        echo "cp address_table_v${ctp7fw//./_}_GBT/gem_amc_top.xml xml/gem_amc_v${ctp7fw//./_}.xml"
        cp address_table_v${ctp7fw//./_}_GBT/gem_amc_top.xml xml/gem_amc_v${ctp7fw//./_}.xml
        echo "rm -rf address_table_v${ctp7fw//./_}_GBT"
        rm -rf address_table_v${ctp7fw//./_}_GBT
    fi

If some of this is obsolete (i.e.,, using the _GBT suffix), that's fine, but the general structure needs to be consistent (see also cms-gem-daq-project/xhal#27)

New Bug in UHAL Address Tables?

Seems like there are still a few bugs in the UHAL address table that where not mentioned in issue #37.

$ vfat_info_uhal.py --shelf=1 -s2 -g 11
01 Jul 2019 11:59:10.193 [7f163d870740] INFO - optohybrid_user_functions_uhal::getOHObject <> - gem.shelf01.amc02.optohybrid11: Success!
01 Jul 2019 11:59:10.193 [7f163d870740] INFO - optohybrid_user_functions_uhal::getOHObject <> - gem.shelf01.amc02.optohybrid11: Success!

--=======================================--

Firmware:     Version        Date
AMC     :       3.7.2   23/5/2017
Traceback (most recent call last):
  File "/opt/cmsgemos/bin/vfat_info_uhal.py", line 84, in <module>
    print "OH      :  %10s  %10s"%(getFirmwareVersion(ohboard,options.gtx),
  File "/usr/lib/python2.7/site-packages/gempython/tools/optohybrid_user_functions_uhal.py", line 86, in getFirmwareVersion
    fwver = readRegister(device,"%s.RELEASE.VERSION"%(baseNode),debug)
  File "/usr/lib/python2.7/site-packages/gempython/utils/registers_uhal.py", line 35, in readRegister
    device.getNode(register).getPath(),
uhal._core.exception: No branch found with ID-path "GEM_AMC.OH.OH11.FPGA.CONTROL.RELEASE.VERSION" from node "top"
Partial match "GEM_AMC.OH.OH11" found for ID-path "GEM_AMC.OH.OH11.FPGA.CONTROL.RELEASE.VERSION" from node "top"

@jsturdy points out that:

FPGA node is missing from uhal address tables

This was observed in FW release 3.8.3.

Not sure if this was resolved in 3.8.4 as well.

@evka85 ?

Bug Report: GEM_AMC Address Table Does Not have XInclude Lines

Right now when updating the address table used on a host machine it does not have the appropriate XInclude lines to catch the OH address table as described:

cms-gem-daq-project/xhal#36

This requires a user to undergo tedious actions, e.g. insert the lines by hand each time, when updating address tables.

Specifically:

Remove the lines:

<node id=top>
...
</node>

Then change the GEM_AMC node declaration too:

<node id='GEM_AMC' xmlns:xi="http://www.w3.org/2001/XInclude">

Finally as shown in the xhal pull request above, just following the line in the OH${OH_IDX} node just before the GEB node add:

<xi:include href="optohybrid_registers.xml"/>

The resulting part of xml should look like this:

     <node id="OH${OH_IDX}"  address="0x0"
            description="Optohybrid ${OH_IDX}"
            generate="true" generate_size="2" generate_address_step="0x00010000" generate_idx_var="OH_IDX">

        <!--Insert here the OH FPGA module -->
        <xi:include href="optohybrid_registers.xml"/>

        <node id="GEB"  address="0x100000"
              description="VFAT3 registers"> 

Could the next release of AMC FW include this update to the address table as was requested in the past?

Issue exists in: GEM_AMC release v3.4.3.

@mexanick @jsturdy @evka85 @andrewpeck

Potential Bug When Writing GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN Post 3.8.4??

Looking at the release notes for 3.8.4 I see that:

SCA TTC_HARD_RESET_EN is now an OH mask instead of just one bit

If I call recover.sh on the card I get the following error:

Set ignore TTC hard resets
reg_interface.py -e write GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN 0
Extended prompt module found
Open pickled address table if available  /mnt/persistent/gemdaq/xml/gem_amc_top.pickle...
Initial value to write: 0, register GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN
Writing masked reg GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN failed. Exiting...
wReg output -2
0xfffffffe(0)	written to GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN

Then trying to write it manually from reg_interface.py on the card unsurprisingly fails:

eagle26:/mnt/persistent/gemdaq$ reg_interface.py
Extended prompt module found
Open pickled address table if available  /mnt/persistent/gemdaq/xml/gem_amc_top.pickle...
Starting CTP7 Register Command Line Interface. Please connect to CTP7 using connect <hostname> command unless you use it directly at the CTP7
CTP7 > doc GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN
Name: GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN
Description: When this is set to 1 (default), TTC hard reset commands are forwarded to the SCA to reset the OH FPGA
Address: 0x00b00002
Permission: rw
Mask: 0x00000001
Module: False
Parent: GEM_AMC.SLOW_CONTROL.SCA.CTRL
None
CTP7 > write GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN 0
Initial value to write: 0, register GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN
Writing masked reg GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN failed. Exiting...
wReg output -2
0xfffffffe(0)	written to GEM_AMC.SLOW_CONTROL.SCA.CTRL.TTC_HARD_RESET_EN

Moreover the register documentation does not match the fact that this is now a 12-bit register.

Perhaps this is due to an outdated pickle file? I will try this from the DAQ machine once I have finished my FW update.

@mexanick @jsturdy @evka85

For the record I'm using GEM_AMC 3.8.6

[bug] UHAL address tables generated incorrectly

The current (3.8.3) address tables for uhal introduce syntax errors (in addition to those introduced in #24):
uhal._core.exception: Bit-masked nodes are not allowed to have child nodes
In the following, MGT_CHANNEL_63.RESET can not have a mask because it has child nodes (and many other places in this new block OPTICAL_LINKS)

      <node id="MGT_CHANNEL_63" address="0xfc0" >
        <node id="RESET" address="0x1" permission="rw" mask="0x3">
          <node id="TX_RESET" address="0x0" permission="rw" mask="0x1"/>
          <node id="RX_RESET" address="0x0" permission="rw" mask="0x2"/>
        </node>
        <node id="CTRL" address="0x2" permission="rw" mask="0x7f">
          <node id="TX_POWERDOWN" address="0x0" permission="rw" mask="0x1"/>
          <node id="RX_POWERDOWN" address="0x0" permission="rw" mask="0x2"/>
          <node id="TX_POLARITY" address="0x0" permission="rw" mask="0x4"/>
          <node id="RX_POLARITY" address="0x0" permission="rw" mask="0x8"/>
          <node id="LOOPBACK" address="0x0" permission="rw" mask="0x10"/>
          <node id="TX_INHIBIT" address="0x0" permission="rw" mask="0x20"/>
          <node id="RX_LOW_POWER_MODE" address="0x0" permission="rw" mask="0x40"/>
          <node id="RX_PRBS_SEL" address="0x1" permission="rw" mask="0x7"/>
          <node id="TX_PRBS_SEL" address="0x1" permission="rw" mask="0x70"/>
          <node id="PRBS_CNT_RESET" address="0x2" permission="w" mask="0x1"/>
          <node id="RX_ERROR_CNT_RESET" address="0x3" permission="w" mask="0x1"/>
        </node>
        <node id="STATUS" address="0x0" permission="r" mask="0xf">
          <node id="TX_RESET_DONE" address="0x0" permission="r" mask="0x1"/>
          <node id="RX_RESET_DONE" address="0x0" permission="r" mask="0x2"/>
          <node id="CPLL_LOCKED" address="0x0" permission="r" mask="0x4"/>
          <node id="CPLL_REF_CLK_LOST" address="0x0" permission="r" mask="0x8"/>
          <node id="PRBS_ERROR_CNT" address="0x4" permission="r" />
          <node id="PRBS_ERROR_CNT" address="0x4" permission="r" />
          <node id="RX_NOT_IN_TABLE_CNT" address="0x5" permission="r" />
          <node id="RX_DISPERR_CNT" address="0x6" permission="r" />
        </node>
      </node>
    </node>

Drop `BxmAvO` and Add VFATX vs. VFATY Mismatch Flags in FW & Event Format

Following discussion on Slides 2-5 would like to drop BxmAvO from the GEM Event Data format and any corresponding status bit/flag registers in the FW.

Propose to add BxmVvV to represent BX mismatch VFATX vs VFATY where for all X != Y a check on that VFATX BX is made and compared against VFATY BX. If this is not true a flag is raised.

Also add a FW flag AMC_SEES_VFATX_VFATY_BX_MISMATCH which would be raised high if a two or more VFATs had mismatching BX's. Then in the DAQ.STATUS node I would propose to add a LAST_VFAT_BX_SENT register which for each L1A would store the last BX that was sent by the VFAT so if AMC_SEES_VFATX_VFATY_BX_MISMATCH was raised high you could check which VFATs were showing the mismatch.

@jsturdy @evka85 @mexanick

Bug Report: sca.py wipes FW of all FPGA's regardless of link Mask

When programming OHv3b from CTP7 I noticed the following:

eagle60:~/apps/reg_interface$ python sca.py 0x1 program-fpga bit ~/oh_fw/OH-20180223-3.0.10.A.bit

This will program FW of link 0 but wipes FW of link 1.

eagle60:~/apps/reg_interface$ python sca.py 0x2 program-fpga bit ~/oh_fw/OH-20180223-3.0.10.A.bit

Programs FW of link 1 but wipes FW of link 0.

eagle60:~/apps/reg_interface$ python sca.py 0x3 program-fpga bit ~/oh_fw/OH-20180223-3.0.10.A.bit

Will wipe FW and program FPGA's of both link 0 and 1.

I would have expected the wiping of the FPGA firmware to follow the oh mask, e.g. if a link is not included the FW will not be wiped.

@evka85 @mexanick @jsturdy @andrewpeck

GE2/1 OH promless programming

Brief summary of issue

Currently the CTP7 FW doesn't allow to promlessly program the GE2/1 optohybrid without executing special SCA command. As a consequence, the special script has to be used and the procedure is slightly overcompilcated.

Types of issue

  • Bug report (report an issue with the code)
  • Feature request (request for change which adds functionality)

Expected Behavior

OH promless programming should be triggered by sending a hard reset from the CTP7 (or TTC stream)

Current Behavior

OH programming doesn't happen upon receiving a hard reset.

Your Environment

  • Version used: CTP7 FW release 3.8.0
  • Shell used:

[Version 3.7.0] Trigger links are always reported in an healthy state

When testing the new CTP7 firmware release (3.7.0), I noticed that the trigger links are always reported in an healthy state even if the fibers are not connected or the OH FPGA is not programmed.

In the following case, none of the OH10 fibers were connected :

eagle63 > write GEM_AMC.TRIGGER.CTRL.CNT_RESET  1
Initial value to write: 1, register GEM_AMC.TRIGGER.CTRL.CNT_RESET
0x00000001(1)   written to GEM_AMC.TRIGGER.CTRL.CNT_RESET
eagle63 > kw GEM_AMC.TRIGGER.OH10.LINK
0x66002e80 r    GEM_AMC.TRIGGER.OH10.LINK0_SBIT_OVERFLOW_CNT        0x00000000
0x66002e80 r    GEM_AMC.TRIGGER.OH10.LINK1_SBIT_OVERFLOW_CNT        0x00000000
0x66002e84 r    GEM_AMC.TRIGGER.OH10.LINK0_MISSED_COMMA_CNT     0x00000000
0x66002e84 r    GEM_AMC.TRIGGER.OH10.LINK1_MISSED_COMMA_CNT     0x00000000
0x66002e8c r    GEM_AMC.TRIGGER.OH10.LINK0_OVERFLOW_CNT         0x00000000
0x66002e8c r    GEM_AMC.TRIGGER.OH10.LINK1_OVERFLOW_CNT         0x00000000
0x66002e90 r    GEM_AMC.TRIGGER.OH10.LINK0_UNDERFLOW_CNT        0x00000000
0x66002e90 r    GEM_AMC.TRIGGER.OH10.LINK1_UNDERFLOW_CNT        0x00000000
0x66002e94 r    GEM_AMC.TRIGGER.OH10.LINK0_SYNC_WORD_CNT        0x00000000
0x66002e94 r    GEM_AMC.TRIGGER.OH10.LINK1_SYNC_WORD_CNT        0x00000000

I'll test test if the trigger data content is correctly received, but the status seems wrong. Yet, I would have expected that some of the error counters increase when the trigger links are not connected or the OH FPGA is not programmed.

Adding gbt_ic_controller Read Capability Disscussion

General Description of Task (as I have understood):

The GBTx can have its firmware rewritten in a variety of ways, but the method we are concerned with is Internal Command (IC). The firmware required to communicate and write firmware on particular GBT has already been handled in common/hdl/slow_control/gbtx_ic_controller.vhd. Furthermore a means of read information off of the sca (which could be structurally similar to the means of reading off from the GBTx with the HDLC protocol) have also been written in slow_control.

Resources:

GBT manual: https://espace.cern.ch/GBT-Project/GBTX/Manuals/gbtxManual.pdf

Any manual in the same realm of discussion (including SCA stuff):https://espace.cern.ch/GBT-Project/GBTX/Manuals/Forms/AllItems.aspx

The current steps taken by our group are purely introductory; understanding how frames work as well as downloading a firmware emulator and designing the relevant test bench. For this purpose it would be useful to obtain some real life data, as discussed yesterday.

I expect in pursuit of this goal, we will not make a new vdh file,instead including the read capability in gbt_ic_controller.vhd.

[Version 3.8.3] Sbit monitor always reports wrong clusters

After upgrading the firmwares to the latest versions (CTP7 - 3.8.3 ; OH - 3.2.3C), the Sbit monitor started to report wrong clusters even if the trigger links are properly initialized. More precisely, the least significant byte is always set to 0xff.

On the other hand, the Sbit monitor implemented within the OH reports the expected cluster (see CLUSTER0) :

eagle63 > kw GEM_AMC.TRIGGER.SBIT_MONITOR
0x66000204 rw   GEM_AMC.TRIGGER.SBIT_MONITOR.OH_SELECT                  0x00000000
0x66000208 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER0                   0x000060ff
0x6600020c r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER1                   0x000007ff
0x66000210 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER2                   0x000007ff
0x66000214 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER3                   0x000007ff
0x66000218 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER4                   0x000007ff
0x6600021c r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER5                   0x000007ff
0x66000220 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER6                   0x000007ff
0x66000224 r    GEM_AMC.TRIGGER.SBIT_MONITOR.CLUSTER7                   0x000007ff
0x66000228 r    GEM_AMC.TRIGGER.SBIT_MONITOR.L1A_DELAY                  0x07b36daa
eagle63 > kw GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR
0x65008240 None         GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR
0x65008240 w    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.RESET
0x65008244 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER0          0x00006000
0x65008248 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER1          0x000007ff
0x6500824c r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER2          0x000007ff
0x65008250 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER3          0x000007ff
0x65008254 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER4          0x000007ff
0x65008258 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER5          0x000007ff
0x6500825c r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER6          0x000007ff
0x65008260 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.CLUSTER7          0x000007ff
0x65008280 r    GEM_AMC.OH.OH0.FPGA.TRIG.SBIT_MONITOR.L1A_DELAY         0x975f6ddf

I'm not sure if the issue is in the OH or the CTP7. My current workaround uses the OH Sbit monitor instead of the CTP7 one.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.