When I run multi uart multiple port (8bit ports) on XU316 I get ET_ILLEGAL_INSTRUCTION see below....
xrun: Program received signal ET_ILLEGAL_INSTRUCTION, Unable to decode instruction.
0x00082144 in uart_tx_assemble_word (info=..., uart_char=<optimized out>) at source/lib_uart/lib_uart/src/multi_uart_tx.xc:87
the actual assembly seems to be 0x82144 <uart_rx_loop_8>: entsp (u6) 0xc
Seems lib_uart in multiple uart mode does not work on XU316 using XTC tools version 15.3...
entsp is XS3 instruction that would be illegal if it were run on earlier silicon but this is XU316 that is XS3 instruction... so I am confused.. or maybe root cause is not this acutal line...
How to fix??
lib_uart ET_ILLEGAL_INSTRUCTION on XU316 XTC 15.3
-
- Member++
- Posts: 20
- Joined: Mon Jun 04, 2018 4:26 am
-
Verified
- Member++
- Posts: 22
- Joined: Wed May 22, 2024 3:30 pm
This is interesting..
entsp by itself is a perfectly legal instruction in xs3a (just like in xs2a and xs1b)
regarding illegal instruction exception, this is what the ISA guide tells us
. .
this is a bit vague and there are actually 2 things happening here, so I'll explain a bit more:
First, the easiest, somehow somewhere your code uses a special debug instruction (6 that are shown in the picture) without the debug flag -g compiled into the binary.
Note that the trapper doesn't always give you the exact line from where an exception is happening (could be +- 2), so it might not happen exactly at entsp
Second, more complicated, which is a bit vague in the ISA document is a single issue vs a double issue. I don't know how much you know about the details of xcore architecture but the processor can handle instruction differently.
For example in dual-issue mode, the processor can execute a packet of 2 16-bit instructions (with some packeting rules), whereas in a single-issue mode processor only executes 16 or 32-bit instructions one after the other.
The issueanes can be different for every function and can be changed at runtime with entsp and dualentsp, the catch there is when you're executing entsp and dualentsp, you're still in the previous mode (won't go into processor pipeline here)
If this is the case, what might be happening is that you're executing something in the double-issue mode and then make a call to your function which starts with an entsp.
The processor is still in a double-issue mode, if your entsp is short and the next instruction is short it will try to execute them in a double-issue packet (single issue will happen only after executing entsp)
So then the double-issue packing rules kick in. You can't pack 2 memory lane instructions together (entsp is memory lane), and this is where you can also get an illegal instruction exception.
(This is obviously only one possibility that I could come up with on the spot, there might be more combinations of single vs double-issue clashes)
If it is actually coming from uart_rx_loop_8 then you can see that the entsp is followed by a stw which in this form is also 16-bit and memory lane...
I don't know which version of tools you were using before but I know that with -O3 the compiler should compile C/XC in double-issue by default (assembly code stays as it is), maybe it was different in the previous versions of the toolchain
(also note that xs1b only supports a single issue mode)
As for fixing this...
You can add -mno-dual-issue as a flag and it will force the compiler to only generate single issue binaries. There are some trade-offs of single vs double issue modes.
A single issue will make your binary smaller and a dual issue should make it faster. if you still want to utilize dual issue mode for the rest of the library, you can add something like:
add r0, r0, 0
after (or before?) your entsp which is a short instruction that can be used in the resource lane. It will pair with entsp if you're entering from a dual issue mode or add one cycle that does nothing if entering from a single issue.
There's also a way to make the explicit call to a longer version of entsp but that is uglier and I'm not gonna go through it here.
Sorry for the lengthy explanation, you gave me a chance to remember some architectural details :)
Hope it helps,
entsp by itself is a perfectly legal instruction in xs3a (just like in xs2a and xs1b)
regarding illegal instruction exception, this is what the ISA guide tells us
. .
this is a bit vague and there are actually 2 things happening here, so I'll explain a bit more:
First, the easiest, somehow somewhere your code uses a special debug instruction (6 that are shown in the picture) without the debug flag -g compiled into the binary.
Note that the trapper doesn't always give you the exact line from where an exception is happening (could be +- 2), so it might not happen exactly at entsp
Second, more complicated, which is a bit vague in the ISA document is a single issue vs a double issue. I don't know how much you know about the details of xcore architecture but the processor can handle instruction differently.
For example in dual-issue mode, the processor can execute a packet of 2 16-bit instructions (with some packeting rules), whereas in a single-issue mode processor only executes 16 or 32-bit instructions one after the other.
The issueanes can be different for every function and can be changed at runtime with entsp and dualentsp, the catch there is when you're executing entsp and dualentsp, you're still in the previous mode (won't go into processor pipeline here)
If this is the case, what might be happening is that you're executing something in the double-issue mode and then make a call to your function which starts with an entsp.
The processor is still in a double-issue mode, if your entsp is short and the next instruction is short it will try to execute them in a double-issue packet (single issue will happen only after executing entsp)
So then the double-issue packing rules kick in. You can't pack 2 memory lane instructions together (entsp is memory lane), and this is where you can also get an illegal instruction exception.
(This is obviously only one possibility that I could come up with on the spot, there might be more combinations of single vs double-issue clashes)
If it is actually coming from uart_rx_loop_8 then you can see that the entsp is followed by a stw which in this form is also 16-bit and memory lane...
I don't know which version of tools you were using before but I know that with -O3 the compiler should compile C/XC in double-issue by default (assembly code stays as it is), maybe it was different in the previous versions of the toolchain
(also note that xs1b only supports a single issue mode)
As for fixing this...
You can add -mno-dual-issue as a flag and it will force the compiler to only generate single issue binaries. There are some trade-offs of single vs double issue modes.
A single issue will make your binary smaller and a dual issue should make it faster. if you still want to utilize dual issue mode for the rest of the library, you can add something like:
add r0, r0, 0
after (or before?) your entsp which is a short instruction that can be used in the resource lane. It will pair with entsp if you're entering from a dual issue mode or add one cycle that does nothing if entering from a single issue.
There's also a way to make the explicit call to a longer version of entsp but that is uglier and I'm not gonna go through it here.
Sorry for the lengthy explanation, you gave me a chance to remember some architectural details :)
Hope it helps,
You do not have the required permissions to view the files attached to this post.
Pavel
xmos software engineer
xmos software engineer