Only reports "Memory available" info

Discussions about USB Audio on XMOS devices
Henry
Junior Member
Posts: 4
Joined: Mon Jun 03, 2024 10:19 am

Only reports "Memory available" info

Post by 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.
User avatar
CousinItt
Respected Member
Posts: 366
Joined: Wed May 31, 2017 6:55 pm

Post by CousinItt »

Do you have the -report option included in the xcc command line?
Henry
Junior Member
Posts: 4
Joined: Mon Jun 03, 2024 10:19 am

Post by Henry »

CousinItt wrote: Mon Jun 17, 2024 9:42 am 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
User avatar
Ross
Verified
XCore Expert
Posts: 1006
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by 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.
Technical Director @ XMOS. Opinions expressed are my own.
User avatar
infiniteimprobability
Verified
XCore Legend
Posts: 1133
Joined: Thu May 27, 2010 10:08 am

Post by 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..
Engineer at XMOS
Henry
Junior Member
Posts: 4
Joined: Mon Jun 03, 2024 10:19 am

Post by Henry »

Thanks for your guys explanation, it's clearly to me now :)
User avatar
Ross
Verified
XCore Expert
Posts: 1006
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by 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.
Technical Director @ XMOS. Opinions expressed are my own.
User avatar
infiniteimprobability
Verified
XCore Legend
Posts: 1133
Joined: Thu May 27, 2010 10:08 am

Post by 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.
Engineer at XMOS