Only reports "Memory available" info

[Henry]

Hi
The tools are XTC Tools 15.2, In "sw_usb_audio" project, when build completed, the tools only report "Memory available" info, like this:

Code: Select all

Creating app_usb_aud_xk_evk_xu316_2AMi2o2xxxxxx.xe
Constraint check for tile[0]:
  Memory available:       524288,   used:      56984 .  OKAY
    (Stack: 3652, Code: 35812, Data: 17520)
Constraints checks PASSED.
Constraint check for tile[1]:
  Memory available:       524288,   used:      11220 .  OKAY
    (Stack: 508, Code: 9556, Data: 1156)
Constraints checks PASSED.
Build Complete

But in some examples, the tools not only show the upon info, but also show the Cores, Timers, Chanends

Code: Select all

Creating AN00156_i2c_master_example.xe
Constraint check for tile[0]:
  Cores available:            8,   used:          1 .  OKAY
  Timers available:          10,   used:          1 .  OKAY
  Chanends available:        32,   used:          0 .  OKAY
  Memory available:       524288,   used:       4600 .  OKAY
    (Stack: 924, Code: 3052, Data: 624)
Constraints checks PASSED.
Build Complete

Is there anyone can tell me how to get the Cores, Timers, Chanends resources usage in "sw_usb_audio" project ?

thanks in advance.

[CousinItt]

Do you have the -report option included in the xcc command line?

[Henry]

Do you have the -report option included in the xcc command line?

No -report option in command line, but it already in Makefile:

TARGET = XK-EVK-XU316
APP_NAME =

# The flags passed to xcc when building the application
# The EXTRA_BUILD_FLAGS variable can be used on the xmake command line to add options
BUILD_FLAGS = $(EXTRA_BUILD_FLAGS) -fcomment-asm -Xmapper --map -Xmapper MAPFILE -Wall -O3 -report -lquadflash -g -fxscope -DXSCOPE -DUSB_TILE=tile[0] -DXUA_QUAD_SPI_FLASH=1 -DADAT_TX_USE_SHARED_BUFF=1


Also, I tried the following command line for building, the issue still present.

Code: Select all

$ xmake CONFIG=2AMi2o2xxxxxx EXTRA_BUILD_FLAGS=-report

[Ross]

If a project uses lib_xcore you will no longer get a full resource report, for the moment, I'm afraid.

The later releases of USB Audio use https://github.com/xmos/lib_sw_pll which is authored in C using lib_xcore, which might explain why you've only experienced this recently.

[infiniteimprobability]

The problem is lib_xcore use allows dynamic allocation of resources like ``chanend_alloc()`` which the mapper can't track and report on. In XC all resources are declared as types so the mapper (part of link stage) can track them. As soon as you include C/lib_xcore it can't do that reliably any more.

One slightly clumsy way to force a resource output is to include a dummy declarations (maybe define guarded) with lots of resources defined up to the point where you exceed the limits. The compiler will tell you how many resources counted (a full report) and you can subtract the dummy ones to work out what you are actually using. Not great but it's possibly an option until the tools are able to allow report generation for your project ASSUMING you don't allocate your own with lib_xcore etc..

[Henry]

Thanks for your guys explanation, it's clearly to me now :)

[Ross]

Just FYI, this is a feature we expect to be available in the future, it's just not available yet. We were living without memory tracking for a while but this is now available, as you've noticed. Lots of work ongoing in this area.

[infiniteimprobability]

Hi, thanks to a colleague, I have just found another and slightly more helpful way of extracting resources when they are disabled in the report due to including lib_xcore functions:

Code: Select all

xobjdump -t --resources <mybin.xe>

This will produce something like:

Code: Select all

Application id number: 0x00000000
Application id string: "".
tile[0] (node "0", tile 0) stack usage,  upper bound: 3708
tile[0] (node "0", tile 0) program size,  upper bound: 61312
tile[0] (node "0", tile 0) free memory,  lower bound: 459268
tile[0] (node "0", tile 0) thread usage,  upper bound: 7
tile[0] (node "0", tile 0) unused threads,  lower bound: 1
tile[0] (node "0", tile 0) timer count,  upper bound: 9
tile[0] (node "0", tile 0) unused timers,  lower bound: 1
tile[0] (node "0", tile 0) channel end usage,  upper bound: 24
tile[0] (node "0", tile 0) unused channel ends,  lower bound: 8
tile[1] (node "0", tile 1) stack usage,  upper bound: 18188+
tile[1] (node "0", tile 1) program size,  upper bound: 503936
tile[1] (node "0", tile 1) free memory,  lower bound: 2164
tile[1] (node "0", tile 1) thread usage,  upper bound: 6+
tile[1] (node "0", tile 1) unused threads,  lower bound: 2
tile[1] (node "0", tile 1) timer count,  upper bound: 2+
tile[1] (node "0", tile 1) unused timers,  lower bound: 8
tile[1] (node "0", tile 1) channel end usage,  upper bound: 5+
tile[1] (node "0", tile 1) unused channel ends,  lower bound: 27
tile[0] (node "0", tile 0) uses port XS1_PORT_1D
tile[0] (node "0", tile 0) uses port XS1_PORT_1F
tile[0] (node "0", tile 0) uses port XS1_PORT_1G
tile[0] (node "0", tile 0) uses port XS1_PORT_1E
tile[0] (node "0", tile 0) uses port XS1_PORT_1H
tile[0] (node "0", tile 0) uses port XS1_PORT_1J
tile[0] (node "0", tile 0) uses port XS1_PORT_1K
tile[0] (node "0", tile 0) uses port XS1_PORT_1I
tile[0] (node "0", tile 0) uses port XS1_PORT_1L
tile[0] (node "0", tile 0) uses port XS1_PORT_1M
tile[0] (node "0", tile 0) uses port XS1_PORT_8A
tile[0] (node "0", tile 0) uses port XS1_PORT_8B
tile[0] (node "0", tile 0) uses port XS1_PORT_8D
tile[0] (node "0", tile 0) uses port XS1_PORT_16B
tile[1] (node "0", tile 1) uses port XS1_PORT_1B
tile[1] (node "0", tile 1) uses port XS1_PORT_1C
tile[1] (node "0", tile 1) uses port XS1_PORT_1D
tile[1] (node "0", tile 1) uses port XS1_PORT_1I
tile[1] (node "0", tile 1) uses port XS1_PORT_1P
Node "0" routing id =  0x8002
Node "0" PLL configuration register value =  0x0000ae02
Node "0" reference clock divider register value =  0x00000006
Node "0" system frequency (Hz) =  700000000

Where you see a + it means either function pointers are detected (and not properly annotated for stack usage) for memory and for resources (Chans, timers etc..) it means lib_xcore is used so there may be more allocated manually and the compiler can't check them.

However if you are largely using XC (eg for sw_usb_audio) then this should provide a fairly accurate guide.