New XMOS chips??!

Technical discussions around xCORE processors (e.g. xcore-200 & xcore.ai).
User avatar
segher
XCore Expert
Posts: 844
Joined: Sun Jul 11, 2010 1:31 am
Contact:

Post by segher »

leon_heller wrote:Were Redeye's problems discussed on this forum?
<dig dig dig>

It's buried in the Q&A section.

It's the PCU thing.

The thread there clearly shows that trusting just one source
of information, no matter how trustworthy that source, for
making important design decisions with big consequences
("let's tie this pin to ground, right under the package") is
not such a hot idea. Also that XMOS is not the first (nor
will be the last) making such datasheet mistakes.

I'm not saying this couldn't have been handled better. Of
course it could, should, and hopefully will be in the future.
I'm saying that the posters are not without blame for their
own problems either.

<end rant>


User avatar
Ross
XCore Expert
Posts: 962
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

Random xCORE-200 trivia: peek no longer can raise a resource dependancy exception.
Hagrid
Active Member
Posts: 44
Joined: Mon Jul 29, 2013 4:33 am

Post by Hagrid »

leon_heller wrote:A low-cost kit should soon be available:

https://www.xmos.com/support/boards?pro ... 0&secure=1
digikey has confirmed to me that the price is US $149.

Considering it contains a processor that the press release extols as a sub $5 gigabit ethernet solution, I think there is a very confused message being presented.
User avatar
Ross
XCore Expert
Posts: 962
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

I have nothing to do with that side of the business, but it does mean that other people (i.e. someone on here) can make a living producing alternative dev boards. I don't think XMOS would want to under-cut something like that.
User avatar
infiniteimprobability
XCore Legend
Posts: 1126
Joined: Thu May 27, 2010 10:08 am
Contact:

Post by infiniteimprobability »

Further random xCORE-200 trivia: the scheduler now has a priority mode. You can specify up to 4 priority cores, each of which will get 1/5th of the core speed (ie scheduled as quickly as possible with 5 stage pipeline). All other cores get a share of the remainder.

Example:

Logical core 0,1 - 100MHz each
Logical cores 2..7 - 50MHz each
Guest

Post by Guest »

infiniteimprobability wrote:Further random xCORE-200 trivia: the scheduler now has a priority mode. You can specify up to 4 priority cores, each of which will get 1/5th of the core speed (ie scheduled as quickly as possible with 5 stage pipeline). All other cores get a share of the remainder.
Can you point me to the informtion on how to set the priority of logical cores ?

Thanks
srinie
XCore Addict
Posts: 158
Joined: Thu Mar 20, 2014 8:04 am

Post by srinie »

This info is available in "xs1.h"

- void set_core_high_priority_on(void);
- void set_core_high_priority_off(void);
Guest

Post by Guest »

srinie wrote:This info is available in "xs1.h"

- void set_core_high_priority_on(void);
- void set_core_high_priority_off(void);
Does this mean, all the priority cores have equal priority? or can we set the priority number individually for each logical core?
User avatar
Ross
XCore Expert
Posts: 962
Joined: Thu Dec 10, 2009 9:20 pm
Location: Bristol, UK

Post by Ross »

jangala wrote:
srinie wrote:This info is available in "xs1.h"

- void set_core_high_priority_on(void);
- void set_core_high_priority_off(void);
Does this mean, all the priority cores have equal priority? or can we set the priority number individually for each logical core?
No, two sets, "high" and "normal" priority

Imagine you had a core that required 100MIPS due to some I/O timing requirement (e.g. USB, ethernet, etc). The rest of your code consists of a bunch of other cores with low speed stuff - contrived example: some whacky high-speed USB device with lots of different (but slow) external peripherals.

Previously the only real way to guarantee that your high-speed I/O core gets 100MIPS was to only run (up to) 5 cores on a 500 part. Now you can run all 8 cores but mark one as high-priority.
Guest

Post by Guest »

Ross wrote: No, two sets, "high" and "normal" priority

Imagine you had a core that required 100MIPS due to some I/O timing requirement (e.g. USB, ethernet, etc). The rest of your code consists of a bunch of other cores with low speed stuff - contrived example: some whacky high-speed USB device with lots of different (but slow) external peripherals.

Previously the only real way to guarantee this is to only run 5 cores on a 500 part. Now you can run all 8 cores but mark one as high-priority.
Thanks a lot Ross for clarification.

Cheers.
Post Reply