XCore Exchange

Hi all,

We’ll be releasing a new version of our developer tools later this week. There will be a series of betas bringing out many new features, including:
- New multicore extensions to C to make programming multicore even easier and making it easier to write modular code.
- C style pointers with usage rules that maintain memory safety and freedom from data races.
- Support for manually specifying your own XMOS Link network topologies
- Performance improvements to xSCOPE
- Updates to xSCOPE to make it simpler to instrument your applications and access real time data from within your code at runtime.
- External memory support with Overlays to load code from flash (coming in the 2nd beta)
- Bidirectional xSCOPE & host side API (coming in 2nd beta)


We’d love to hear your thoughts and comments on the new tools & features. Of course we’d also love to hear from you about new features and improvements you’d like to see in future versions of the tools.

The beta tools will be available to download from http://www.XMOS.com later this week.

Ali

I'm waiting!
"Support for manually specifying your own XMOS Link network topologies"

I already have a very large custom card with a star configuration of 4 L1's.

With 12.x I can use only 3 L1's of the 4 available.

Is there any documentation to support the new features/topologies etc..

regards
Al

there will be documentation & examples accompanying the release later this week.

Ali

I'm waiting!
"Support for manually specifying your own XMOS Link network topologies"
I already have a very large custom card with a star configuration of 4 L1's.
With 12.x I can use only 3 L1's of the 4 available.

With the new tools if the topology isn't one that can be automatically routed (i.e. it isn't a line, a hypercube or a hypercube with lines attached) then you'll be able to specify the node IDs and routing tables you want in the .xn file. The tools will check that the specified configuration results in a fully routed network (i.e. that you can route messages between every pair of nodes on the network). If the configuration is valid the tools will arrange for the network to be setup as part of the boot process before main.

When booting from JTAG you can use any network topology that is supported by the hardware (which includes star networks along with many others). When booting from flash there is the following additional restriction: the topology must be such that it is possible to draw lines (one per boot site) such that the line passes through the boot site and all its bootees without crossing back on itself.

This restriction means that it still won't be possible to boot a star network from a single flash. In your case (a star network with 3 points) you would be able to boot from flash if you have two flashes (one to boot one of the points on the star and another to boot the other three nodes).

I'm very excited! It will be great to get rid of a lot of those C helper functions my code relies on for pointer stuff.

@lilltroll: I get a 403 Forbidden on that image link.

Richard: What about a bootloader in the OTP, could a bootloader support star configurations ?

lilltroll wrote:Richard: What about a bootloader in the OTP, could a bootloader support star configurations ?

For this to work you would need a way to tell xflash that it shouldn't trying set up a particular node because it has already been configured by the OTP bootloader. There is currently no mechanism for specifying this.

Hi all,

In case you haven't seen it, the beta is now available: https://www.xmos.com/support/downloads/xtimecomposer

Ali

Ali wrote:Hi all,

In case you haven't seen it, the beta is now available: https://www.xmos.com/support/downloads/xtimecomposer

Ali

Ali,

Is there any beta documentation that goes along with this? In particular, I'm interested in knowing more about:

C style pointers with usage rules that maintain memory safety and freedom from data races.

Thanks!
--tim