XCore Exchange

davelacey: OK that all sounds reasonable. All requirements of reusable objects should be thoroughly documented. Time usage like memory usage. If the timing requirements can be verified with timing scripts all the better. Just like the tools will tell you when you have run out of memory or channel ends or whatever.

I must admit I have been pushing things to the limit for the sake of argument.

Note to self: Must gen up on the timing analysis tool and scripts.

I guess with sufficient tools in place the "100% deterministic operation" claim almost becomes true. At least you can, in an automated way, discover when you have exceed the limits in the completed application.

I am "playing" a little with a deterministic test on the XAI bord since it can create any clock speed between 6 - 75 MHz. If you run the CODEC as the master, the timing req. gets tight.
When you pass 50 MHz - as I understood a in port pin cannot clock that speed -and a loopback of Audio gets destroyed. I have been using it successful at over 45 MHz. (It also uses the "fast thread" to transfer all multichannel data to an other thread.)

Hi,

Leon wrote in an earlier reply

"Fast mode" is described in xs1_en.pdf.

Are there any code examples using fast mode?

John.

I am wondering how many transistors, system gates, asic or whatever,
not counting the memory would be the size of an XMOS core anyway.
Or what I was wondering was at 65nm a 22nm*22nm array, like 3.5 billion
transistors (i think that's the economical maximum substrate)( moore at
45nm 28nm)How many XCores one could stuff ?

MENNE MENNE PARCEE PARCEE

My XMOS has ESP! :P

JohnR wrote:Hi,

Leon wrote in an earlier reply

"Fast mode" is described in xs1_en.pdf.

Are there any code examples using fast mode?

John.

There is code in the XMOS examples found at http://www.xmos.com/support/software that uses it.
The I2S code is one example.

I suppose if your driver is on a single core cpu, you have to optimise the code so that the FPU type ops have a higher priority.
If using multicore, you could use one core, having a single thread only, to just crunch the numbers and kick out a result, while one or more other cores service other aspects of the driver.
:D

Hi,

I found that when measuring time delays in the 10 - 100 nsec range, using fast-mode gave about 10% higher counts than when it was not invoked.

John