Hi All,
a Blog Post on 11 June 2013 wrotes something about CAN FD. Is XMOS working on to
implement the CAN FD protokoll on XMOS devices our otherwise on FlexRay?
Does anyone know nearer information?
Thanks in advance and best greatings
Schorsch
CAN FD on XMOS Silicon
-
- Member
- Posts: 12
- Joined: Sun Feb 16, 2014 8:36 am
-
- Experienced Member
- Posts: 114
- Joined: Fri Dec 11, 2009 10:22 am
Sorry, we did a feasibility study and found that CAN FD although possible to do transfers would not be able to meet the FD specification due to corner cases so are not currently pursuing it.
-
- Member
- Posts: 12
- Joined: Sun Feb 16, 2014 8:36 am
Dear andrew,
first, thanks for your answer. I think, if XMOS would offer the CAN FD and the FlexRay IP the
outsell of XMOS Silicon would strong increasing, especially for the automotive sector. It is
one of the biggest market in the world.
I found it real pity, that XMOS is not working on it.
Best greating
Schorsch
first, thanks for your answer. I think, if XMOS would offer the CAN FD and the FlexRay IP the
outsell of XMOS Silicon would strong increasing, especially for the automotive sector. It is
one of the biggest market in the world.
I found it real pity, that XMOS is not working on it.
Best greating
Schorsch
-
- Member++
- Posts: 28
- Joined: Mon Jul 25, 2016 2:03 pm
Hi all,
Is it possible to get some more information about the feasibility study you made?
With which family of controllern did you made the tests and which corner cases were critical?
Thanks
Charlotte
Is it possible to get some more information about the feasibility study you made?
With which family of controllern did you made the tests and which corner cases were critical?
Thanks
Charlotte
-
- Experienced Member
- Posts: 114
- Joined: Fri Dec 11, 2009 10:22 am
After a cursory study and instruction timing calculations it was decided that CAN FD is infeasible on an xcore. No corner cases were ever investigated nor was any code written.
The corner cases are dealing with the worse case clock drift after long runs of zeros and ones (the 11th bit as 5 zeros + 5 ones + one zero). In that case we won't meet timing.
The corner cases are dealing with the worse case clock drift after long runs of zeros and ones (the 11th bit as 5 zeros + 5 ones + one zero). In that case we won't meet timing.
-
- Member++
- Posts: 28
- Joined: Mon Jul 25, 2016 2:03 pm
Hello Andrew,
Could you give me some more details about your computation (Why aren't you meeting timing?)? I'm not sure I'm able to follow you.
Thanks,
Charlotte
Could you give me some more details about your computation (Why aren't you meeting timing?)? I'm not sure I'm able to follow you.
Thanks,
Charlotte
-
- Experienced Member
- Posts: 114
- Joined: Fri Dec 11, 2009 10:22 am
In order to ascertain if we should implement CAN FD I did some rough calculations. The xcore can execute instruction at 62.5MIPS, CAN can run at 1Mbaud. The hardest case to meet is where our CAN device is sending a message at the same time as another then loses arbitration and has to become a receiver. If this happens at the same time as the worse case clock drift situation then we will have too few instruction to deal with all the required processing to meet the specification, i.e. switch internal state, setup of ports, port counters, error counters, etc. We can just manage CAN 2.0b but the extra requirements of FD mean it would be economically infeasible to pursue this further.
-
- Member++
- Posts: 28
- Joined: Mon Jul 25, 2016 2:03 pm
Juste a few questions:
Why do you assume that the core runs the instructions at 62.5 MIPS? Would the result still be infeasible if we assume that the core runs instructions at 100 MIPS (the best case)?
How many instructions do you need to deal with all the requiered processing in that particular case?
Why do you assume that the core runs the instructions at 62.5 MIPS? Would the result still be infeasible if we assume that the core runs instructions at 100 MIPS (the best case)?
How many instructions do you need to deal with all the requiered processing in that particular case?
-
- Experienced Member
- Posts: 114
- Joined: Fri Dec 11, 2009 10:22 am
I didn't work out the exact number as that would require an almost full implementation. I figured out that the timing would be so tight (even at 125MIPS) that the engineering cost+risk would be too high.