XMOS Link in an AVR

Go To Last Post
12 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Someone at XMOS has implemented an XMOS link in an AVR ATtiny24:

http://www.xmoslinkers.org/node/306

Leon

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMOS Linkers wrote:
This project seeked to implement a serial XMOS Link in an Atmel MCU. The test enviroment consisted of an AVR ATtiny, connected to an XS1-L1 through a link.

A 1-bit DAC output from the XS1-L1 was fed back into the built-in ADCs of the AVR, and this result was used to automatically calibrate the DAC.

I guess I don't understand the purpose of this "link" since I presume that an XS1-L1 would have a serial port of some sort. Is there some reason why this is "cool" (for some value of "cool")?

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can't even figure out what "XMOS" is about!

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

They make very high performance (up to 1600 MIPS) 32-bit controllers:

http://www.xmos.com

They are fast enough to do high-speed (480 Mb/s) USB and 100 Mb/s Ethernet in software, and one of their applications is FPGA replacement. They have up to four 400 MIPs cores, each of which can have up to eight 100/50 MIPS hardware threads. Think of it as a parallel processing engine like the Inmos transputer, which was also designed by David May. Like the transputer, they may be connected together for more processing power.

This application is basically an example of how an XMOS 2-bit inter-chip link can be implemented in software on an AVR. The links are usually used for very fast comms channels between XMOS chips. The 5-bit link speed is 400 Mbit/s (on each of five wires). Here's a good description of this application, and how the links work:

http://electronicdesign.com/Articles/Index.cfm?ArticleID=21693&pg=1

XMOS chips are quite cheap, they start at $7.50 for a 400 MIPS single core device.

I've been playing with them since they first came out, I'm very impressed with them.

The AVR code builds OK with WinAVR, BTW.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMOS is kind of a reincarnation of Inmos.

Inmos was the company building the CPUs called Transputers. The elder among us might just have shivered. Transputers were supposed to be used in bulk - to create multiprocessor supercomputers. Transputers communicated among each other via so called links. Links were hardware bus, plus a communication protocol. Transputers were programmed in a language called Occam.

Inmos created a lot of grief when they didn't manage to get their improved transputer, the T9000, out of the door. A number of companies had gambled on this faster Transputer, but Inmos let them down badly.

The XMOS people try to revive Transputers, but don't call them Transputers and have some more sane programming language than Occam. An AVR programmed to speak the link protocol can participate in XMOS inter-processor, inter-core communication.

However, what on earth a 20 MHz AVR is good for on a multiple hundreds of megabits bus, talking to 400 MHz XMOS cores is beyond me.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I used to develop transputer hardware and sold a lot of systems, including one with 16 of my modules each with a T800 and 1 MB of RAM. They were very popular with universities and research establishments because of the low cost - about £13,000 (GBP)! GCHQ had one but I never found out what they did with it. Plessey Roke Manor had one they used for a fault-tolerant system (I think it was used in a military radar). They'd ask a customer to pull out one or two modules whilst it was running and it didn't miss a beat.

That XMOS application is just one way of calibrating the 1-bit DAC output from the XMOS chip. An SPI ADC could have been used, but the AVR offers a lot more flexibility. The DAC is running at 100 MHz, BTW! XMOS probably developed it for a customer; it looks like a high-end audio application, they are used a lot for that sort of thing.

Here's the DAC code, written in XMOS's own XC language which exploits the parallel processing features of the chip:

#include 

unsigned DACarray[33];

unsigned char lookup[] = {1, 2, 5, 6, 8, 10, 12, 13, 15, 17, 19, 21, 23, 24, 26, 27, 29, 30, 32, 33, 35, 36, 38, 39, 41, 42, 43, 45, 46, 48, 49, 50, 52, 52, 53, 55, 56, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 69, 69, 71, 71, 72, 74, 74, 75, 76, 77, 78, 79, 80, 81, 82, 82, 83, 84, 85, 86, 86, 87, 89, 89, 90, 91, 91, 92, 93, 93, 94, 95, 96, 97, 97, 98, 99, 99, 100, 101, 101, 102, 102, 103, 104, 104, 105, 106, 106, 107, 108, 108, 109, 109, 110, 110, 111, 112, 112, 113, 113, 114, 115, 115, 116, 117, 117, 118, 118, 119, 120, 120, 121, 121, 122, 122, 123, 124, 124, 125, 125, 126, 126, 127, 128, 128, 129, 129, 129, 130, 130, 131, 131, 132, 132, 133, 133, 134, 134, 134, 135, 135, 136, 136, 137, 138, 138, 138, 139, 139, 140, 140, 141, 142, 142, 143, 143, 144, 144, 145, 145, 146, 147, 147, 148, 148, 149, 149, 150, 151, 151, 152, 152, 153, 154, 155, 155, 156, 157, 157, 158, 159, 159, 161, 161, 162, 163, 163, 164, 165, 166, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 184, 185, 186, 187, 189, 190, 191, 192, 194, 195, 196, 198, 199, 200, 202, 203, 205, 206, 208, 209, 211, 213, 214, 216, 218, 220, 222, 224, 225, 228, 229, 231, 234, 236, 238, 241, 242, 246, 248, 249, 252, };


void setUpDACArray() {
     int i;
     DACarray[0] = 0;
     DACarray[32] = ~0;
     for(i=1; i<32; i+=1) {
         unsigned int mask = 0;
         int sum = 0;
         int j;
         for(j=0; j<32; j++) {
             mask = mask<<1;
             sum += i;
             if (sum >= 32) {
                 mask |= 1;
                 sum -= 32;
             }

         }
         DACarray[i] = mask;
     }
}

#define   DACbits  22


/* Signed numbers to be input, range -1<<DACbits .. 1<<DACbits
  * Output creates a stream of zeroes aand ones to be measured relative
  * to ground. The port should be a serialising one bit port.
  * The stream runs at 100 MHz - or slower if you slow the clock of 
that port
  * down. Typically you will upsample the signal.
  */

void dacFast(buffered out port:32 fastPort, clock audclk, streaming chanend inchan) {
   int DACSum = 0;
   int arrayIndex;
   int DACIndex;
   const int one = 1 << (DACbits+1);
   int val=0;
   int count = 0;
   timer t;
   unsigned time;
   int readCount = 0;
   t:> time;
   time += 2083;
     
  setUpDACArray();
  configure_out_port(fastPort, audclk, 0);
  configure_clock_ref(audclk, 0);
  start_clock(audclk);

#pragma unsafe arrays
   while (1) 
   {
      select
      {
  
          case inchan :> val:
              // Receive 29bit signed number
              val >>= 6;
              // Now 23bit
              {
                int lup;
                // Convert to unsigned
                val += (one >> 1);
                // Lookup top 8bits
#if 1
                val = (val & 0x7F) | (lookup[ (val >> 15) ] << 15);
#endif
              }
              break;
      default:
       DACSum += val;
       DACIndex = DACSum >> (DACbits - 4);
       DACSum -= DACIndex << (DACbits - 4);
       //printintln(DACIndex);
       if (DACIndex < 0) {
           arrayIndex = 0;
       } else if (DACIndex > 32) {
           arrayIndex = 32;
       } else {
           arrayIndex = DACIndex;
       }
       fastPort <: DACarray[arrayIndex];
       break;
      }
   }
}

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okey doke, I am now beginning to understand the drive of the processor and why someone may want to have an AVR talk to one (or many).

I like the idea of lots of processors getting together to solve a big problem. After all, the human brain is constructed that way! :twisted: Now, if there was some way to get 1000's of ATtiny processors to do something useful... HHMMMMmmm...

Stu

Engineering seems to boil down to: Cheap. Fast. Good. Choose two. Sometimes choose only one.

Newbie? Be sure to read the thread Newbie? Start here!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You'd be better off using XMOS chips. It'll be a lot cheaper, much faster, and much easier to program. :)

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

leon_heller wrote:
YouI'm new and am reviving this interesting thread. I noticed that xmoslinkers has just been shut down by XMOS, which is not very encouraging. We need all kinds of chips to talk to one another, even little poky ones with nice payloads. I'm an old Transputer guy too, and this interests me because it makes it look like AVR chips can be trained to be Transputers ;-) Can the XMOS load code to the AVR chip?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

XMOS wants users to move over to XCore Exchange:

http://www.xcore.com/forum/

It's a much better forum than Xlinkers, with a lot more facilities.

The purpose of the Xlink on the AVR is to enable easy data transfer between the AVR and an XMOS chip; an AVR can't run XMOS code.

Leon Heller G1HSM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, Leon. What I am wondering is whether the XMOS chip can imitate a host and pass AVR code (which was presumably compiled using gcc-avr on the real host and passed to the XMOS chip previously) down the Xlink to the AVR. What I'm after is deep heterogeneous networks.
Larry Dickson, LAZM

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An AVR with bootloader capability could be used, but that couldn't use the XLink on the XMOS chip. A simple async interface could be used.

Leon Heller G1HSM