-
Notifications
You must be signed in to change notification settings - Fork 2
Data path to the Zynq SM (ZynqMonTask)
This page describes how the monitoring data is sent to the Zynq. The transmission occurs via a unidirectional UART channel that sends data every so often to the zynq. On the Zynq, the data is interpreted via a file in the /fw/CM/CornellCM_MCU/address_table/modules_CM_MCU directory called PL_MEM_CM.xml. This file is generated when you type make release while building the CM FW. This file is different for different CM hardware revisions.
The data for generating this file is stored in a YAML file in the sm_cm_config/data directory. This YAML file is used in two ways: it is used to generate the XML file and also used to generate two source files that are included in the firmware build. The source files that are generated include the data offsets of each block of monitoring data in the YAML file. However, the location within these blocks is determined by the relevant function zm_set_ function and must be manually synchronized with the data in the YAML file.
In the build process you see the YAML file being used here:
PY PL_MEM_CM_rev1.yml PL_MEM_CM_rev2.yml PL_MEM_CM_rev3.yml
CC ZynqMon_addresses.c
The file ZynqMon_addresses.c and the associated header file are generated in this step. A snippet looks as follows:
void zm_fill_structs(void)
{
// firefly, size 25
zm_set_firefly_temps(&zynqmon_data[0], 0);
// psmon, size 64
zm_set_psmon(&zynqmon_data[25], 32);
// adcmon, size 21
zm_set_adcmon(&zynqmon_data[89], 96);
// uptime, size 2
zm_set_uptime(&zynqmon_data[110], 192);
// gitversion, size 10.0
zm_set_gitversion(&zynqmon_data[112], 118);
// fpga, size 4
zm_set_fpga(&zynqmon_data[122], 128);
}The structure of the YAML file is as follows.
- name: clkmon
start: 246
count: 40
type: uint16_t
extra: Table=CM_CLK_MON;Status=1
mcu_call: clock
mcu_extra_call: null
default_col: null
names:
- ROA
- R0B
- R1A
- R1B
- R1C
postfixes:
- PN_BASE
- DEVICE_REV
- I2C_ADDR
- STATUS
- LOL
- LOSXAXB
- LOSOOF_IN
- STICKY_FLGThe mcu_call field determines the C function that will be used, with zm_set_ prepended. If needed, the field mcu_extra_call is appended to the argument list. The start field is where the data is placed in the memory, and the count field is used to make sure that there are no overlaps. This number is cross-compared to the calculated size (number of entries in the names list multiplied by the postfixes list size.) The type and extra fields are used in the XML file; in particular, the extra field defines the table used for displaying the data in BUTool on the Zynq.
In the XML file entries are created for the "names" list with sub-entries for the post-fixes. For instance, for R0A above it looks as follows:
<node id="ROA" address="0x7b">
<node id="PN_BASE" address="0x0" permission="r" mask="0x0000FFFF" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=PN_BASE" />
<node id="DEVICE_REV" address="0x0" permission="r" mask="0xFFFF0000" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=DEVICE_REV" />
<node id="I2C_ADDR" address="0x1" permission="r" mask="0x0000FFFF" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=I2C_ADDR" />
<node id="STATUS" address="0x1" permission="r" mask="0xFFFF0000" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=STATUS" />
<node id="LOL" address="0x2" permission="r" mask="0x0000FFFF" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=LOL" />
<node id="LOSXAXB" address="0x2" permission="r" mask="0xFFFF0000" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=LOSXAXB" />
<node id="LOSOOF_IN" address="0x3" permission="r" mask="0x0000FFFF" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=LOSOOF_IN" />
<node id="STICKY_FLG" address="0x3" permission="r" mask="0xFFFF0000" parameters="Format=u;Row=ROA;Table=CM_CLK_MON;Status=1;Column=STICKY_FLG" />
</node>