Hello
I've got strange error during compilation: xmap: Error: Tile id does not refer to tile declaration.
It's look like my procedure is too big. If I coment few code lines it compile without any errors:
Constraint check for tile[0]:
Cores available: 8, used: 8 . OKAY
Timers available: 10, used: 8 . OKAY
Chanends available: 32, used: 17 . OKAY
Memory available: 262144, used: 76644 . OKAY
(Stack: 23180, Code: 37552, Data: 15912)
Constraints checks PASSED.
Constraint check for tile[1]:
Cores available: 8, used: 8 . OKAY
Timers available: 10, used: 8 . OKAY
Chanends available: 32, used: 26 . OKAY
Memory available: 262144, used: 128220 . OKAY
(Stack: 22596, Code: 99284, Data: 6340)
Constraints checks PASSED.
Is there any restriction for size of procedure running on single core?
xTIMEcomposer 14.3.2
xmap: Error: Tile id does not refer to tile declaration.
-
- New User
- Posts: 3
- Joined: Thu Nov 02, 2017 11:04 am
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
@kc3i,
1) post your XN file for this project
2) which specific XMOS CPU is the target ?
1) post your XN file for this project
2) which specific XMOS CPU is the target ?
-
- New User
- Posts: 3
- Joined: Thu Nov 02, 2017 11:04 am
XEF216-512-TQ128-C20
You do not have the required permissions to view the files attached to this post.
-
- XCore Legend
- Posts: 1913
- Joined: Thu Jun 10, 2010 11:43 am
Your XN file has a target of:
but your hardware is:
XEF216-512-TQ128-C20
This could be an issue. Does the tool chain offer a more suitable match for your target? Test and post your results.
Code: Select all
<Package id="0" Type="XS2-UEnA-512-FB236">
XEF216-512-TQ128-C20
This could be an issue. Does the tool chain offer a more suitable match for your target? Test and post your results.
-
- New User
- Posts: 3
- Joined: Thu Nov 02, 2017 11:04 am
changed to XS2-UEFnA-512-TQ128 (according to XEF216-512-TQ128 Datasheet), stil got errors but sometimes new one (depending how many lines of code I add or remove):
xmap: Error: port or clock "XnDOUT.info" has invalid tile reference.
source code:
on tile[1] : in port XnDOUT = XS1_PORT_1D; //X1D11
Interesting thing is that XnDOUT is first port definition in program, If I comment this definition error will be on next one. Maybe something wrong is with platform.h file? Mine looks like below, I've added #pragma warnings but they never shonw:
/* .....
* Version: Community_14.3.2
*/
#ifndef _platform_h_
#define _platform_h_
#ifdef _PLATFORM_INCLUDE_FILE
#pragma warning "PLATFORM INCLUDED"
#include _PLATFORM_INCLUDE_FILE
#else
#pragma warning "PLATFORM NOT INCLUDED"
#endif /* PLATFORM_INCLUDE_FILE */
#endif /* _platform_h_ */
EDIT:
Amazing thing is that I can comment few lines of code and everything compile without errors, so it looks like xmap bug.
EDIT 2:
Rolling back to 14.2.0 gives flood of errors:
Creating boot_xcore_200_qspi.xe
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section attributes for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section attributes for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
...
EDIT 3:
temporary workaround is to change optimization from -O0 to -O1 in makefile, so it looks like some problem with code size...
xmap: Error: port or clock "XnDOUT.info" has invalid tile reference.
source code:
on tile[1] : in port XnDOUT = XS1_PORT_1D; //X1D11
Interesting thing is that XnDOUT is first port definition in program, If I comment this definition error will be on next one. Maybe something wrong is with platform.h file? Mine looks like below, I've added #pragma warnings but they never shonw:
/* .....
* Version: Community_14.3.2
*/
#ifndef _platform_h_
#define _platform_h_
#ifdef _PLATFORM_INCLUDE_FILE
#pragma warning "PLATFORM INCLUDED"
#include _PLATFORM_INCLUDE_FILE
#else
#pragma warning "PLATFORM NOT INCLUDED"
#endif /* PLATFORM_INCLUDE_FILE */
#endif /* _platform_h_ */
EDIT:
Amazing thing is that I can comment few lines of code and everything compile without errors, so it looks like xmap bug.
EDIT 2:
Rolling back to 14.2.0 gives flood of errors:
Creating boot_xcore_200_qspi.xe
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section attributes for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section attributes for ''
..\.build\src\boot_xcore_200_qspi.xc.o: Error: first set here
..\.build\src\boot_xcore_200_qspi.xc.o: Error: Changed section type for ''
...
EDIT 3:
temporary workaround is to change optimization from -O0 to -O1 in makefile, so it looks like some problem with code size...
-
- XCore Addict
- Posts: 185
- Joined: Tue Mar 26, 2013 12:10 pm
-O0 can lead to some very large executable sizes. I would recommend -Os or -O2.
Note -Os often leads to the most efficient code because boiler plate code is removed very efficiently. -O3 can often lead to higher performance at the expense of larger code size.
John
Note -Os often leads to the most efficient code because boiler plate code is removed very efficiently. -O3 can often lead to higher performance at the expense of larger code size.
John
-
- XCore Addict
- Posts: 169
- Joined: Fri Oct 23, 2015 10:23 am
I would recommend `-Os` as standard.
`-O2` and `-O3` are similar but will attempt to dual issue and other more aggressive optimisation.
Dual issue is very poor at present, so if you really want `-O2` or `-O3` I would turn it off as defauilt with `-mno-dual-issue`.
If you then decide a particular function should be dual-issue, you can turn it on for that function by marking it in code with `[[dual_issue]] void myfunc()`.
And for completeness there is also a flag `-mdual-issue` and an attribute `[[single_issue]]`.
`-O2` and `-O3` are similar but will attempt to dual issue and other more aggressive optimisation.
Dual issue is very poor at present, so if you really want `-O2` or `-O3` I would turn it off as defauilt with `-mno-dual-issue`.
If you then decide a particular function should be dual-issue, you can turn it on for that function by marking it in code with `[[dual_issue]] void myfunc()`.
And for completeness there is also a flag `-mdual-issue` and an attribute `[[single_issue]]`.