Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29458 > unrolled thread
| Started by | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| First post | 2020-04-15 20:51 -0700 |
| Last post | 2020-04-20 18:02 +0200 |
| Articles | 20 on this page of 146 — 15 participants |
Back to article view | Back to comp.arch.embedded
Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-15 20:51 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 11:59 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-16 13:28 +0200
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-16 13:10 +0000
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 22:16 +0100
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-16 22:01 +0000
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-16 17:13 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 18:10 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 18:37 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-16 22:08 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 10:02 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 10:49 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 15:44 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 15:23 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 18:15 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-17 17:49 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 15:06 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 16:08 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:13 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:24 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:00 +0200
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-20 14:32 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 23:55 +0100
Re: Custom CPU Designs Reinhardt Behm <rbehm@hushmail.com> - 2020-04-21 15:14 +0800
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-18 16:51 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 18:06 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:53 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 10:11 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-19 13:19 +0300
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 11:33 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:26 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:59 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 13:37 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 22:02 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-19 22:15 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 15:02 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 02:03 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:44 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:20 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 14:57 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 12:38 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 15:58 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:27 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 17:36 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 14:02 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 06:15 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 17:25 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 16:56 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 12:42 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 23:16 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:10 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 08:09 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 20:07 +0200
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-18 13:09 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-18 21:28 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-21 20:29 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-21 18:10 +0000
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-22 09:54 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 13:19 +0000
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-22 18:09 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:03 +0000
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:16 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 10:48 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 16:57 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-18 14:21 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-18 14:50 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:32 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 18:12 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 10:09 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:31 +0100
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 16:42 +0100
Re: Custom CPU Designs upsidedown@downunder.com - 2020-04-18 00:43 +0300
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-18 17:07 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 09:11 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-17 12:17 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 13:22 -0700
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-17 14:48 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 15:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 16:53 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 17:03 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 19:39 +0200
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 21:25 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 18:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 17:58 +0200
Re: Custom CPU Designs Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-04-21 19:41 +0300
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 14:01 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-21 23:21 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-19 20:53 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 14:47 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 02:11 +0100
Re: Custom CPU Designs Paul Rubin <no.email@nospam.invalid> - 2020-04-19 18:31 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 20:32 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 07:46 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 00:33 -0700
Re: Custom CPU Designs Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-04-20 11:01 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:44 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 19:57 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:02 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 14:56 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-17 16:34 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:57 +0200
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-21 15:20 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 08:26 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:09 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 15:00 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 11:28 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 08:24 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-22 20:18 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 11:45 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-23 17:47 +0200
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-21 15:35 -0700
Re: Custom CPU Designs Przemek Klosowski <przemek@tux.dot.org> - 2020-04-19 18:52 +0000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-19 13:42 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-20 22:59 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-20 17:01 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-21 10:23 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-21 03:47 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-22 09:26 +1000
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-22 22:06 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-22 14:18 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-23 22:35 +0100
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 18:20 +0200
Re: Custom CPU Designs Dimiter_Popoff <dp@tgi-sci.com> - 2020-04-22 18:16 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:06 +0000
Re: Custom CPU Designs Dimiter_Popoff <dp@tgi-sci.com> - 2020-04-22 20:17 +0300
Re: Custom CPU Designs Grant Edwards <invalid@invalid.invalid> - 2020-04-22 17:28 +0000
Re: Custom CPU Designs George Neuner <gneuner2@comcast.net> - 2020-04-23 04:59 -0400
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-20 17:27 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 17:58 +0200
Re: Custom CPU Designs pault.eg@googlemail.com - 2020-04-21 01:00 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-21 19:21 +0200
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-17 17:18 +0100
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 07:40 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 12:28 -0700
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 13:50 -0700
Re: Custom CPU Designs jim.brakefield@ieee.org - 2020-04-16 14:19 -0700
Re: Custom CPU Designs Theo <theom+news@chiark.greenend.org.uk> - 2020-04-16 22:33 +0100
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 11:29 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 18:42 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 12:35 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 20:01 -0700
Re: Custom CPU Designs Clifford Heath <no.spam@please.net> - 2020-04-17 14:54 +1000
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-16 23:54 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-17 10:38 +0200
Re: Custom CPU Designs Rick C <gnuarm.deletethisbit@gmail.com> - 2020-04-17 09:13 -0700
Re: Custom CPU Designs David Brown <david.brown@hesbynett.no> - 2020-04-20 18:02 +0200
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 16:00 +0200 |
| Message-ID | <r7k9tf$t55$2@dont-email.me> |
| In reply to | #29532 |
On 20/04/2020 15:24, Tom Gardner wrote: > On 20/04/20 14:13, David Brown wrote: >> >> (If there were an EtherCAT slave peripheral available for XMOS, I >> might have had an application.) > > Yes, and I'm sure there is a reason you couldn't fall > back on the old ways, and use an external peripheral. There is no reason at all - external peripherals is /exactly/ the solution we have used!
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-20 14:32 -0700 |
| Message-ID | <87mu754zcu.fsf@nightsong.com> |
| In reply to | #29530 |
David Brown <david.brown@hesbynett.no> writes: > Your posts in this thread have renewed my interest in XMOS. If XMOS > run a pyramid scheme for evangelism, you have definitely earned > yourself a few more brownie points. Do you know about the Parallax Propeller and the newer Propeller 2? It is another one of those "hub and cog" designs where there are a bunch of peripheral processors connected to a central one. You can use the peripheral processors to drive individual i/o pins, like with the GA144 and apparently like with XMOS. There is an on-chip crossbar or something of that sort, that allow you to connect the internal processors to external pins any way you want.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 23:55 +0100 |
| Message-ID | <1MpnG.62243$Jj2.15401@fx11.am4> |
| In reply to | #29550 |
On 20/04/20 22:32, Paul Rubin wrote: > David Brown <david.brown@hesbynett.no> writes: >> Your posts in this thread have renewed my interest in XMOS. If XMOS >> run a pyramid scheme for evangelism, you have definitely earned >> yourself a few more brownie points. > > Do you know about the Parallax Propeller and the newer Propeller 2? It > is another one of those "hub and cog" designs where there are a bunch of > peripheral processors connected to a central one. You can use the > peripheral processors to drive individual i/o pins, like with the GA144 > and apparently like with XMOS. There is an on-chip crossbar or > something of that sort, that allow you to connect the internal > processors to external pins any way you want. I remember looking at it in the past, and thinking it looked like a few "boring" cores bolted together. There have been many such devices over the decades. The programming languages and tools are bog-standard, and aren't built with hardware parallelism as a core feature. The attraction (to me) of the XMOS devices was that the hardware and software and tools were designed to be highly parallel, and to interwork smoothly, cleanly and without "random" barriers between them. Parallel hardware is easy. Changing the software and mindset away from single thread sequential program execution has been harder than desirable.
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2020-04-21 15:14 +0800 |
| Message-ID | <r7m6h4$50c$1@dont-email.me> |
| In reply to | #29550 |
On 4/21/20 5:32 AM, Paul Rubin wrote: > David Brown <david.brown@hesbynett.no> writes: >> Your posts in this thread have renewed my interest in XMOS. If XMOS >> run a pyramid scheme for evangelism, you have definitely earned >> yourself a few more brownie points. > > Do you know about the Parallax Propeller and the newer Propeller 2? It > is another one of those "hub and cog" designs where there are a bunch of > peripheral processors connected to a central one. You can use the > peripheral processors to drive individual i/o pins, like with the GA144 > and apparently like with XMOS. There is an on-chip crossbar or > something of that sort, that allow you to connect the internal > processors to external pins any way you want. > I used the Propellor I in several projects. I like this approach where every core run totally independent and undisturbed from all others. This gives total predictability. You write e.g. one module that runs on one core to implement a time critical peripheral and start the some program on several other cores without any worry that your timing gets messed up. As David asked for something serial with unusual format, I implemented ARINC-429 (Avionics bus). This is 32 bit pi-phase serial 100kbit/s. Each input or output runs one one core. One more core implements the interface to the host. That's 4 rx/3 tx much cheaper than using standard chips. Similar ARINC-708 (12 bit, manchester bi-phase, 1 Mbit/s) used for weather radar. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-18 16:51 +0100 |
| Message-ID | <wrB*fISPx@news.chiark.greenend.org.uk> |
| In reply to | #29497 |
David Brown <david.brown@hesbynett.no> wrote: > The real power comes from when you want to do something that is /not/ > standard, or at least not common. > > Implementing a standard UART in a couple of XMOS cores is a pointless > waste of silicon. Implementing a UART that uses Manchester encoding for > the UART signals so that you can use it on a balanced line without > keeping track of which line is which - /then/ you've got something that > can be done just as easily on an XMOS and is a big pain to do on a > standard microcontroller. > > Implementing an Ethernet MAC on an XMOS is pointless. Implementing an > EtherCAT slave is not going to be much harder for the XMOS than a normal > Ethernet MAC, but is impossible on any microcontroller without > specialised peripherals. The Cypress PSoC has an interesting take on this. You can specify (with the GUI) that you want a component. If you specify a simple component (let's say I2C slave) there's a hard IP for that. But if you specify something that's more complicated (say I2C master and slave on the same pins) it builds it with the existing IP plus some of its FPGA-like logic. Takes more resources but allows you to do many more things than they put in as hard cores. Unfortunately they don't provide a vast quantity of cells for that logic, so it's fine if you want to add just a few unusual bits to the regular microcontroller, but not a big system. (PSoC also has the programmable analogue stuff, which presumably constrains the process they can use) It would be quite interesting to combine that with the XMOS approach - more fluid boundaries between hardware and software. I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores - lock down the cores running a task that absolutely needs to be bounded-latency, and then multitask the remaining tasks across the other cores. If that was provided as an integrated service then it wouldn't need messing about running a scheduler. After all, there must be applications with a lot of do-this-once-a-second tasks, that would be wasted using a whole core? Do they have a scheduler where you can tell a task to sleep until a particular time? Or is FreeRTOS intended for that? In which case you presumably have to write the code in a different way compared to the hard-tasks? Theo
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-18 18:06 +0100 |
| Message-ID | <RsGmG.64714$mk2.26219@fx21.am4> |
| In reply to | #29501 |
On 18/04/20 16:51, Theo wrote: > David Brown <david.brown@hesbynett.no> wrote: >> The real power comes from when you want to do something that is /not/ >> standard, or at least not common. >> >> Implementing a standard UART in a couple of XMOS cores is a pointless >> waste of silicon. Implementing a UART that uses Manchester encoding for >> the UART signals so that you can use it on a balanced line without >> keeping track of which line is which - /then/ you've got something that >> can be done just as easily on an XMOS and is a big pain to do on a >> standard microcontroller. >> >> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an >> EtherCAT slave is not going to be much harder for the XMOS than a normal >> Ethernet MAC, but is impossible on any microcontroller without >> specialised peripherals. > > The Cypress PSoC has an interesting take on this. You can specify (with the > GUI) that you want a component. If you specify a simple component (let's > say I2C slave) there's a hard IP for that. But if you specify something > that's more complicated (say I2C master and slave on the same pins) it > builds it with the existing IP plus some of its FPGA-like logic. Takes more > resources but allows you to do many more things than they put in as hard > cores. > > Unfortunately they don't provide a vast quantity of cells for that logic, so > it's fine if you want to add just a few unusual bits to the regular > microcontroller, but not a big system. (PSoC also has the programmable > analogue stuff, which presumably constrains the process they can use) > > It would be quite interesting to combine that with the XMOS approach - more > fluid boundaries between hardware and software. > > I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores - lock > down the cores running a task that absolutely needs to be bounded-latency, > and then multitask the remaining tasks across the other cores. If that was > provided as an integrated service then it wouldn't need messing about > running a scheduler. What scheduler? To a very useful approximation the an RTOS's functions are encoded in hardware. The "select" statement is like a "switch" statement, except that the core sleeps until one of the "case" conditions becomes true. In effect the case conditions are events. Events can be inputs arriving, outputs completing, timeouts, etc. N.B. as far as a core is concerned, receiving input from a pin is the same as receiving a message from another task/core. Ditto output to a pin and sending a message to another task/core. Everything is via the "port" abstraction, and that extends down into the hardware and i/o system. For a short intro to the hardware, software, and concepts see the architecture flyer. https://www.xmos.com/file/xcore-architecture-flyer/ FFI see the XMOS programming guide, which is beautifully written, succinct, and clear. https://www.xmos.com/file/xmos-programming-guide/ I wish all documentation was as good! > After all, there must be applications with a lot of do-this-once-a-second > tasks, that would be wasted using a whole core? Do they have a scheduler > where you can tell a task to sleep until a particular time? See "combinable tasks" in my post in response to David Brown's post. > Or is FreeRTOS intended for that? In which case you presumably have to > write the code in a different way compared to the hard-tasks? I really don't see the point of FreeRTOS running inside an xCORE chip. To be over simplistic, RTOSs are designed to schedule multiple tasks on a single processor and to connect i/o with tasks (typically via interrupts). All that is done in hardware in the xCORE ecosystem.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-18 14:53 -0700 |
| Message-ID | <1d6583ae-457a-4945-97f3-9e9628b0ced6@googlegroups.com> |
| In reply to | #29502 |
On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: > On 18/04/20 16:51, Theo wrote: > > David Brown <david.brown@hesbynett.no> wrote: > >> The real power comes from when you want to do something that is /not/ > >> standard, or at least not common. > >> > >> Implementing a standard UART in a couple of XMOS cores is a pointless > >> waste of silicon. Implementing a UART that uses Manchester encoding for > >> the UART signals so that you can use it on a balanced line without > >> keeping track of which line is which - /then/ you've got something that > >> can be done just as easily on an XMOS and is a big pain to do on a > >> standard microcontroller. > >> > >> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an > >> EtherCAT slave is not going to be much harder for the XMOS than a normal > >> Ethernet MAC, but is impossible on any microcontroller without > >> specialised peripherals. > > > > The Cypress PSoC has an interesting take on this. You can specify (with the > > GUI) that you want a component. If you specify a simple component (let's > > say I2C slave) there's a hard IP for that. But if you specify something > > that's more complicated (say I2C master and slave on the same pins) it > > builds it with the existing IP plus some of its FPGA-like logic. Takes more > > resources but allows you to do many more things than they put in as hard > > cores. > > > > Unfortunately they don't provide a vast quantity of cells for that logic, so > > it's fine if you want to add just a few unusual bits to the regular > > microcontroller, but not a big system. (PSoC also has the programmable > > analogue stuff, which presumably constrains the process they can use) > > > > It would be quite interesting to combine that with the XMOS approach - more > > fluid boundaries between hardware and software. > > > > I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores - lock > > down the cores running a task that absolutely needs to be bounded-latency, > > and then multitask the remaining tasks across the other cores. If that was > > provided as an integrated service then it wouldn't need messing about > > running a scheduler. > > What scheduler? > > To a very useful approximation the an RTOS's functions are > encoded in hardware. > > The "select" statement is like a "switch" statement, except > that the core sleeps until one of the "case" conditions > becomes true. In effect the case conditions are events. > Events can be inputs arriving, outputs completing, timeouts, etc. Isn't that what interrupts are about? Many processors have a "halt and wait for interrupt" instruction. > N.B. as far as a core is concerned, receiving input from a > pin is the same as receiving a message from another task/core. > Ditto output to a pin and sending a message to another task/core. > Everything is via the "port" abstraction, and that extends down > into the hardware and i/o system. That sounds a lot like the Transputer. > For a short intro to the hardware, software, and concepts see the > architecture flyer. > https://www.xmos.com/file/xcore-architecture-flyer/ > > FFI see the XMOS programming guide, which is beautifully written, > succinct, and clear. > https://www.xmos.com/file/xmos-programming-guide/ > > I wish all documentation was as good! > > > > After all, there must be applications with a lot of do-this-once-a-second > > tasks, that would be wasted using a whole core? Do they have a scheduler > > where you can tell a task to sleep until a particular time? > > See "combinable tasks" in my post in response to David Brown's > post. > > > > Or is FreeRTOS intended for that? In which case you presumably have to > > write the code in a different way compared to the hard-tasks? > > I really don't see the point of FreeRTOS running inside an > xCORE chip. To be over simplistic, RTOSs are designed to > schedule multiple tasks on a single processor and to connect > i/o with tasks (typically via interrupts). > > All that is done in hardware in the xCORE ecosystem. That's true of most processors, no? An I/O event happens and an interrupt invokes a task called an interrupt handler. The tricky part is dealing with the real time requirements of handling the I/O events. Which task must be done first, which tasks can be interrupted to deal with other tasks, what resources are required to process an event, etc. This is what makes real time multitasking difficult. -- Rick C. ---+ Get 1,000 miles of free Supercharging ---+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-19 10:11 +0100 |
| Message-ID | <WAUmG.109550$e1n.85307@fx36.am4> |
| In reply to | #29509 |
On 18/04/20 22:53, Rick C wrote: > On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: >> On 18/04/20 16:51, Theo wrote: >>> David Brown <david.brown@hesbynett.no> wrote: >>>> The real power comes from when you want to do something that is /not/ >>>> standard, or at least not common. >>>> >>>> Implementing a standard UART in a couple of XMOS cores is a pointless >>>> waste of silicon. Implementing a UART that uses Manchester encoding >>>> for the UART signals so that you can use it on a balanced line without >>>> keeping track of which line is which - /then/ you've got something >>>> that can be done just as easily on an XMOS and is a big pain to do on >>>> a standard microcontroller. >>>> >>>> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an >>>> EtherCAT slave is not going to be much harder for the XMOS than a >>>> normal Ethernet MAC, but is impossible on any microcontroller without >>>> specialised peripherals. >>> >>> The Cypress PSoC has an interesting take on this. You can specify (with >>> the GUI) that you want a component. If you specify a simple component >>> (let's say I2C slave) there's a hard IP for that. But if you specify >>> something that's more complicated (say I2C master and slave on the same >>> pins) it builds it with the existing IP plus some of its FPGA-like logic. >>> Takes more resources but allows you to do many more things than they put >>> in as hard cores. >>> >>> Unfortunately they don't provide a vast quantity of cells for that logic, >>> so it's fine if you want to add just a few unusual bits to the regular >>> microcontroller, but not a big system. (PSoC also has the programmable >>> analogue stuff, which presumably constrains the process they can use) >>> >>> It would be quite interesting to combine that with the XMOS approach - >>> more fluid boundaries between hardware and software. >>> >>> I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores - >>> lock down the cores running a task that absolutely needs to be >>> bounded-latency, and then multitask the remaining tasks across the other >>> cores. If that was provided as an integrated service then it wouldn't >>> need messing about running a scheduler. >> >> What scheduler? >> >> To a very useful approximation the an RTOS's functions are encoded in >> hardware. >> >> The "select" statement is like a "switch" statement, except that the core >> sleeps until one of the "case" conditions becomes true. In effect the case >> conditions are events. Events can be inputs arriving, outputs completing, >> timeouts, etc. > > Isn't that what interrupts are about? Many processors have a "halt and wait > for interrupt" instruction. Hardware on its own is trivial and has been done many times over the decades. XMOS have integrated the hardware with the software with the conceptual tools, and have provided excellent development tools. That has not been achieved elsewhere. >> N.B. as far as a core is concerned, receiving input from a pin is the same >> as receiving a message from another task/core. Ditto output to a pin and >> sending a message to another task/core. Everything is via the "port" >> abstraction, and that extends down into the hardware and i/o system. > > That sounds a lot like the Transputer. Exactly. And xC is a modern successor to Occam, with CSP a core abstraction. Some of the original Transputer team are in XMOS. >> For a short intro to the hardware, software, and concepts see the >> architecture flyer. https://www.xmos.com/file/xcore-architecture-flyer/ >> >> FFI see the XMOS programming guide, which is beautifully written, succinct, >> and clear. https://www.xmos.com/file/xmos-programming-guide/ >> >> I wish all documentation was as good! >> >> >>> After all, there must be applications with a lot of >>> do-this-once-a-second tasks, that would be wasted using a whole core? Do >>> they have a scheduler where you can tell a task to sleep until a >>> particular time? >> >> See "combinable tasks" in my post in response to David Brown's post. >> >> >>> Or is FreeRTOS intended for that? In which case you presumably have to >>> write the code in a different way compared to the hard-tasks? >> >> I really don't see the point of FreeRTOS running inside an xCORE chip. To >> be over simplistic, RTOSs are designed to schedule multiple tasks on a >> single processor and to connect i/o with tasks (typically via interrupts). >> >> All that is done in hardware in the xCORE ecosystem. > > That's true of most processors, no? An I/O event happens and an interrupt > invokes a task called an interrupt handler. > > The tricky part is dealing with the real time requirements of handling the > I/O events. Which task must be done first, which tasks can be interrupted to > deal with other tasks, what resources are required to process an event, etc. > This is what makes real time multitasking difficult. Those problems mostly disappear with sufficient independent cores. What remains is the logical dependencies which can result in livelock or deadlock. No implementation technology can solve those, since they are inherent in either the problem or the architectural solution.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2020-04-19 13:19 +0300 |
| Message-ID | <ui8o9fp2599rsiv5hq438paj60961l645e@4ax.com> |
| In reply to | #29511 |
On Sun, 19 Apr 2020 10:11:18 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >On 18/04/20 22:53, Rick C wrote: >> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: <clip> >>> For a short intro to the hardware, software, and concepts see the >>> architecture flyer. https://www.xmos.com/file/xcore-architecture-flyer/ >>> >>> FFI see the XMOS programming guide, which is beautifully written, succinct, >>> and clear. https://www.xmos.com/file/xmos-programming-guide/ >>> >>> I wish all documentation was as good! This information seems to be a few years old. <clip> >> The tricky part is dealing with the real time requirements of handling the >> I/O events. Which task must be done first, which tasks can be interrupted to >> deal with other tasks, what resources are required to process an event, etc. >> This is what makes real time multitasking difficult. > >Those problems mostly disappear with sufficient >independent cores. Unfortunately, the xCore tile has only 8 logical cores. It seems hard to find out from XMOS web pages, how many tiles are integrated on recent chips. If there are only 1 or 2 tiles,s there would be only 8-16 logical cores on a chip.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-19 11:33 +0100 |
| Message-ID | <KNVmG.25399$XQ5.11761@fx28.am4> |
| In reply to | #29512 |
On 19/04/20 11:19, upsidedown@downunder.com wrote: > On Sun, 19 Apr 2020 10:11:18 +0100, Tom Gardner > <spamjunk@blueyonder.co.uk> wrote: > >> On 18/04/20 22:53, Rick C wrote: >>> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: > > <clip> > >>>> For a short intro to the hardware, software, and concepts see the >>>> architecture flyer. https://www.xmos.com/file/xcore-architecture-flyer/ >>>> >>>> FFI see the XMOS programming guide, which is beautifully written, succinct, >>>> and clear. https://www.xmos.com/file/xmos-programming-guide/ >>>> >>>> I wish all documentation was as good! > > This information seems to be a few years old. In one sense that is good: it means there has been no fundamental changes recently. Stability (of such things) is good :) Detailed implementations, OTOH, should change regularly. >>> The tricky part is dealing with the real time requirements of handling the >>> I/O events. Which task must be done first, which tasks can be interrupted to >>> deal with other tasks, what resources are required to process an event, etc. >>> This is what makes real time multitasking difficult. >> >> Those problems mostly disappear with sufficient >> independent cores. > > Unfortunately, the xCore tile has only 8 logical cores. > > It seems hard to find out from XMOS web pages, how many tiles are > integrated on recent chips. They do seem to be a less "open" than before, which I don't like. However, although I haven't checked recently, I presume a free registration continues to be all that is needed. > If there are only 1 or 2 tiles,s there > would be only 8-16 logical cores on a chip. 4 tiles. I /believe/ multiple chips can be interconnected so as to transparently extend the internal switch matrix, albeit with a increased latency. NUMA anyone :) See what is stocked by DigiKey... https://www.digikey.co.uk/products/en/integrated-circuits-ics/embedded-microcontrollers/685?k=xmos&k=&pkeyword=xmos&sv=0&sf=0&FV=-8%7C685&quantity=&ColumnSort=-143&page=1&stock=1&nstock=1&pageSize=25 Example: XE232-1024-FB374 Features Multicore Microcontroller with Advanced Multi-Core RISC Architecture • 32 real-time logical cores on 4 xCORE tiles • Cores share up to 2000 MIPS — Up to 4000 MIPS in dual issue mode • Each logical core has: — Guaranteed throughput of between 1 / 5 and 1 /8 of tile MIPS — 16x32bit dedicated registers • 167 high-density 16/32-bit instructions — All have single clock-cycle execution (except for divide) — 32x32→64-bit MAC instructions for DSP, arithmetic and user-definable cryptographic functions
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 15:26 +0200 |
| Message-ID | <r7k7un$fs7$1@dont-email.me> |
| In reply to | #29513 |
On 19/04/2020 12:33, Tom Gardner wrote: > On 19/04/20 11:19, upsidedown@downunder.com wrote: >> On Sun, 19 Apr 2020 10:11:18 +0100, Tom Gardner >> <spamjunk@blueyonder.co.uk> wrote: >> >>> On 18/04/20 22:53, Rick C wrote: >>>> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: >> >> <clip> >> >>>>> For a short intro to the hardware, software, and concepts see the >>>>> architecture flyer. >>>>> https://www.xmos.com/file/xcore-architecture-flyer/ >>>>> >>>>> FFI see the XMOS programming guide, which is beautifully written, >>>>> succinct, >>>>> and clear. https://www.xmos.com/file/xmos-programming-guide/ >>>>> >>>>> I wish all documentation was as good! >> >> This information seems to be a few years old. > > In one sense that is good: it means there has been no > fundamental changes recently. Stability (of such things) > is good :) > > Detailed implementations, OTOH, should change regularly. > > >>>> The tricky part is dealing with the real time requirements of >>>> handling the >>>> I/O events. Which task must be done first, which tasks can be >>>> interrupted to >>>> deal with other tasks, what resources are required to process an >>>> event, etc. >>>> This is what makes real time multitasking difficult. >>> >>> Those problems mostly disappear with sufficient >>> independent cores. >> >> Unfortunately, the xCore tile has only 8 logical cores. >> >> It seems hard to find out from XMOS web pages, how many tiles are >> integrated on recent chips. > > They do seem to be a less "open" than before, which I don't like. > However, although I haven't checked recently, I presume a free > registration continues to be all that is needed. > > >> If there are only 1 or 2 tiles,s there >> would be only 8-16 logical cores on a chip. > > 4 tiles. There are a maximum of 8 logical cores on a tile. There are XMOS devices with different numbers of cores and tiles. A 16-core device will have 2 tiles, a 32-core device will have 4 tiles. AFAIUI, anyway. > I /believe/ multiple chips can be interconnected > so as to transparently extend the internal switch matrix, > albeit with a increased latency. NUMA anyone :) Yes, that has always been part of the idea. And the interconnections can use 1, 2 or 4 wires IIRC. They work exactly the same between virtual cores, between tiles, between chips - but perhaps with different throughputs and latencies. (When I worked with them, the latency for transfer between virtual cores on the same tile was very much slower than you could get with simple sharing of memory - but XC would not let you share the memory. So you had a messy system with inline assembly mixed with XC in order to get fast buffers. I presume this has improved since then.) > > > See what is stocked by DigiKey... > > https://www.digikey.co.uk/products/en/integrated-circuits-ics/embedded-microcontrollers/685?k=xmos&k=&pkeyword=xmos&sv=0&sf=0&FV=-8%7C685&quantity=&ColumnSort=-143&page=1&stock=1&nstock=1&pageSize=25 > > > Example: > > XE232-1024-FB374 Features > Multicore Microcontroller with Advanced Multi-Core RISC Architecture > • 32 real-time logical cores on 4 xCORE tiles > • Cores share up to 2000 MIPS > — Up to 4000 MIPS in dual issue mode > • Each logical core has: > — Guaranteed throughput of between 1 / 5 and 1 /8 of tile MIPS > — 16x32bit dedicated registers > • 167 high-density 16/32-bit instructions > — All have single clock-cycle execution (except for divide) > — 32x32→64-bit MAC instructions for DSP, arithmetic and user-definable > cryptographic > functions
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 14:59 +0100 |
| Message-ID | <eVhnG.93794$QJp.25173@fx08.am4> |
| In reply to | #29533 |
On 20/04/20 14:26, David Brown wrote: > (When I worked with them, the latency for transfer between virtual cores on the > same tile was very much slower than you could get with simple sharing of memory > - but XC would not let you share the memory. So you had a messy system with > inline assembly mixed with XC in order to get fast buffers. I presume this has > improved since then.) I believe so, but I haven't investigated in detail. The programming guide / tutorial has an double buffering example where two tasks swap pointers to the in-memory buffer.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-19 13:37 -0700 |
| Message-ID | <a2eb9b76-96e7-43c0-bb1e-d419b183f422@googlegroups.com> |
| In reply to | #29511 |
On Sunday, April 19, 2020 at 5:11:22 AM UTC-4, Tom Gardner wrote: > On 18/04/20 22:53, Rick C wrote: > > On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: > >> On 18/04/20 16:51, Theo wrote: > >>> David Brown <david.brown@hesbynett.no> wrote: > >>>> The real power comes from when you want to do something that is /not/ > >>>> standard, or at least not common. > >>>> > >>>> Implementing a standard UART in a couple of XMOS cores is a pointless > >>>> waste of silicon. Implementing a UART that uses Manchester encoding > >>>> for the UART signals so that you can use it on a balanced line without > >>>> keeping track of which line is which - /then/ you've got something > >>>> that can be done just as easily on an XMOS and is a big pain to do on > >>>> a standard microcontroller. > >>>> > >>>> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an > >>>> EtherCAT slave is not going to be much harder for the XMOS than a > >>>> normal Ethernet MAC, but is impossible on any microcontroller without > >>>> specialised peripherals. > >>> > >>> The Cypress PSoC has an interesting take on this. You can specify (with > >>> the GUI) that you want a component. If you specify a simple component > >>> (let's say I2C slave) there's a hard IP for that. But if you specify > >>> something that's more complicated (say I2C master and slave on the same > >>> pins) it builds it with the existing IP plus some of its FPGA-like logic. > >>> Takes more resources but allows you to do many more things than they put > >>> in as hard cores. > >>> > >>> Unfortunately they don't provide a vast quantity of cells for that logic, > >>> so it's fine if you want to add just a few unusual bits to the regular > >>> microcontroller, but not a big system. (PSoC also has the programmable > >>> analogue stuff, which presumably constrains the process they can use) > >>> > >>> It would be quite interesting to combine that with the XMOS approach - > >>> more fluid boundaries between hardware and software. > >>> > >>> I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores - > >>> lock down the cores running a task that absolutely needs to be > >>> bounded-latency, and then multitask the remaining tasks across the other > >>> cores. If that was provided as an integrated service then it wouldn't > >>> need messing about running a scheduler. > >> > >> What scheduler? > >> > >> To a very useful approximation the an RTOS's functions are encoded in > >> hardware. > >> > >> The "select" statement is like a "switch" statement, except that the core > >> sleeps until one of the "case" conditions becomes true. In effect the case > >> conditions are events. Events can be inputs arriving, outputs completing, > >> timeouts, etc. > > > > Isn't that what interrupts are about? Many processors have a "halt and wait > > for interrupt" instruction. > > Hardware on its own is trivial and has been done many times > over the decades. > > XMOS have integrated the hardware with the software with > the conceptual tools, and have provided excellent development > tools. > > That has not been achieved elsewhere. Not sure what your point is. XMOS doesn't have programmable hardware, so it's not clear what you are referring to "integrating". The only company I've seen integrate the hardware and software is Cypress and that is fairly crude. What exactly is special or unique about XMOS other than the fact they have N processors with a shared memory on a single chip? The point is if this is not the Goldilocks combination for you, the XMOS is not so great a chip. > >> N.B. as far as a core is concerned, receiving input from a pin is the same > >> as receiving a message from another task/core. Ditto output to a pin and > >> sending a message to another task/core. Everything is via the "port" > >> abstraction, and that extends down into the hardware and i/o system. > > > > That sounds a lot like the Transputer. > > Exactly. > > And xC is a modern successor to Occam, with CSP a core abstraction. > > Some of the original Transputer team are in XMOS. > > > > > >> For a short intro to the hardware, software, and concepts see the > >> architecture flyer. https://www.xmos.com/file/xcore-architecture-flyer/ > >> > >> FFI see the XMOS programming guide, which is beautifully written, succinct, > >> and clear. https://www.xmos.com/file/xmos-programming-guide/ > >> > >> I wish all documentation was as good! > >> > >> > >>> After all, there must be applications with a lot of > >>> do-this-once-a-second tasks, that would be wasted using a whole core? Do > >>> they have a scheduler where you can tell a task to sleep until a > >>> particular time? > >> > >> See "combinable tasks" in my post in response to David Brown's post. > >> > >> > >>> Or is FreeRTOS intended for that? In which case you presumably have to > >>> write the code in a different way compared to the hard-tasks? > >> > >> I really don't see the point of FreeRTOS running inside an xCORE chip. To > >> be over simplistic, RTOSs are designed to schedule multiple tasks on a > >> single processor and to connect i/o with tasks (typically via interrupts). > >> > >> All that is done in hardware in the xCORE ecosystem. > > > > That's true of most processors, no? An I/O event happens and an interrupt > > invokes a task called an interrupt handler. > > > > The tricky part is dealing with the real time requirements of handling the > > I/O events. Which task must be done first, which tasks can be interrupted to > > deal with other tasks, what resources are required to process an event, etc. > > This is what makes real time multitasking difficult. > > Those problems mostly disappear with sufficient > independent cores. Hmmm... the keyword there is "sufficient". That was when I mentioned 144 and the cycle began. > What remains is the logical dependencies which can result in > livelock or deadlock. No implementation technology can solve > those, since they are inherent in either the problem or the > architectural solution. Indeed. However these problems go away once you decompose your problem for independent processors such as in an FPGA. I can't remember ever having to even consider a deadlock other than the most simple of issues when designing in an FPGA. Multitasking on a single processor (or even on several) can open up a design to very complex interactions which have subtle failure modes. -- Rick C. --+- Get 1,000 miles of free Supercharging --+- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-19 22:02 +0100 |
| Message-ID | <d%2nG.79262$fq1.462@fx37.am4> |
| In reply to | #29516 |
On 19/04/20 21:37, Rick C wrote: > On Sunday, April 19, 2020 at 5:11:22 AM UTC-4, Tom Gardner wrote: >> On 18/04/20 22:53, Rick C wrote: >>> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: >>>> On 18/04/20 16:51, Theo wrote: >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> The real power comes from when you want to do something that is /not/ >>>>>> standard, or at least not common. >>>>>> >>>>>> Implementing a standard UART in a couple of XMOS cores is a pointless >>>>>> waste of silicon. Implementing a UART that uses Manchester encoding >>>>>> for the UART signals so that you can use it on a balanced line without >>>>>> keeping track of which line is which - /then/ you've got something >>>>>> that can be done just as easily on an XMOS and is a big pain to do on >>>>>> a standard microcontroller. >>>>>> >>>>>> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an >>>>>> EtherCAT slave is not going to be much harder for the XMOS than a >>>>>> normal Ethernet MAC, but is impossible on any microcontroller without >>>>>> specialised peripherals. >>>>> >>>>> The Cypress PSoC has an interesting take on this. You can specify (with >>>>> the GUI) that you want a component. If you specify a simple component >>>>> (let's say I2C slave) there's a hard IP for that. But if you specify >>>>> something that's more complicated (say I2C master and slave on the same >>>>> pins) it builds it with the existing IP plus some of its FPGA-like logic. >>>>> Takes more resources but allows you to do many more things than they put >>>>> in as hard cores. >>>>> >>>>> Unfortunately they don't provide a vast quantity of cells for that logic, >>>>> so it's fine if you want to add just a few unusual bits to the regular >>>>> microcontroller, but not a big system. (PSoC also has the programmable >>>>> analogue stuff, which presumably constrains the process they can use) >>>>> >>>>> It would be quite interesting to combine that with the XMOS approach - >>>>> more fluid boundaries between hardware and software. >>>>> >>>>> I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores - >>>>> lock down the cores running a task that absolutely needs to be >>>>> bounded-latency, and then multitask the remaining tasks across the other >>>>> cores. If that was provided as an integrated service then it wouldn't >>>>> need messing about running a scheduler. >>>> >>>> What scheduler? >>>> >>>> To a very useful approximation the an RTOS's functions are encoded in >>>> hardware. >>>> >>>> The "select" statement is like a "switch" statement, except that the core >>>> sleeps until one of the "case" conditions becomes true. In effect the case >>>> conditions are events. Events can be inputs arriving, outputs completing, >>>> timeouts, etc. >>> >>> Isn't that what interrupts are about? Many processors have a "halt and wait >>> for interrupt" instruction. >> >> Hardware on its own is trivial and has been done many times >> over the decades. >> >> XMOS have integrated the hardware with the software with >> the conceptual tools, and have provided excellent development >> tools. >> >> That has not been achieved elsewhere. > > Not sure what your point is. XMOS doesn't have programmable hardware, so it's not clear what you are referring to "integrating". The only company I've seen integrate the hardware and software is Cypress and that is fairly crude. > > What exactly is special or unique about XMOS other than the fact they have N processors with a shared memory on a single chip? The point is if this is not the Goldilocks combination for you, the XMOS is not so great a chip. > > >>>> N.B. as far as a core is concerned, receiving input from a pin is the same >>>> as receiving a message from another task/core. Ditto output to a pin and >>>> sending a message to another task/core. Everything is via the "port" >>>> abstraction, and that extends down into the hardware and i/o system. >>> >>> That sounds a lot like the Transputer. >> >> Exactly. >> >> And xC is a modern successor to Occam, with CSP a core abstraction. >> >> Some of the original Transputer team are in XMOS. >> >> >> >> >>>> For a short intro to the hardware, software, and concepts see the >>>> architecture flyer. https://www.xmos.com/file/xcore-architecture-flyer/ >>>> >>>> FFI see the XMOS programming guide, which is beautifully written, succinct, >>>> and clear. https://www.xmos.com/file/xmos-programming-guide/ >>>> >>>> I wish all documentation was as good! >>>> >>>> >>>>> After all, there must be applications with a lot of >>>>> do-this-once-a-second tasks, that would be wasted using a whole core? Do >>>>> they have a scheduler where you can tell a task to sleep until a >>>>> particular time? >>>> >>>> See "combinable tasks" in my post in response to David Brown's post. >>>> >>>> >>>>> Or is FreeRTOS intended for that? In which case you presumably have to >>>>> write the code in a different way compared to the hard-tasks? >>>> >>>> I really don't see the point of FreeRTOS running inside an xCORE chip. To >>>> be over simplistic, RTOSs are designed to schedule multiple tasks on a >>>> single processor and to connect i/o with tasks (typically via interrupts). >>>> >>>> All that is done in hardware in the xCORE ecosystem. >>> >>> That's true of most processors, no? An I/O event happens and an interrupt >>> invokes a task called an interrupt handler. >>> >>> The tricky part is dealing with the real time requirements of handling the >>> I/O events. Which task must be done first, which tasks can be interrupted to >>> deal with other tasks, what resources are required to process an event, etc. >>> This is what makes real time multitasking difficult. >> >> Those problems mostly disappear with sufficient >> independent cores. > > Hmmm... the keyword there is "sufficient". That was when I mentioned 144 and the cycle began. > > >> What remains is the logical dependencies which can result in >> livelock or deadlock. No implementation technology can solve >> those, since they are inherent in either the problem or the >> architectural solution. > > Indeed. However these problems go away once you decompose your problem for independent processors such as in an FPGA. I can't remember ever having to even consider a deadlock other than the most simple of issues when designing in an FPGA. > > Multitasking on a single processor (or even on several) can open up a design to very complex interactions which have subtle failure modes. >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-19 22:15 +0100 |
| Message-ID | <Fb3nG.195827$8qv1.37156@fx12.am4> |
| In reply to | #29516 |
On 19/04/20 21:37, Rick C wrote: > On Sunday, April 19, 2020 at 5:11:22 AM UTC-4, Tom Gardner wrote: >> On 18/04/20 22:53, Rick C wrote: >>> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: >>>> On 18/04/20 16:51, Theo wrote: >>>>> David Brown <david.brown@hesbynett.no> wrote: >>>>>> The real power comes from when you want to do something that is >>>>>> /not/ standard, or at least not common. >>>>>> >>>>>> Implementing a standard UART in a couple of XMOS cores is a >>>>>> pointless waste of silicon. Implementing a UART that uses >>>>>> Manchester encoding for the UART signals so that you can use it on >>>>>> a balanced line without keeping track of which line is which - >>>>>> /then/ you've got something that can be done just as easily on an >>>>>> XMOS and is a big pain to do on a standard microcontroller. >>>>>> >>>>>> Implementing an Ethernet MAC on an XMOS is pointless. Implementing >>>>>> an EtherCAT slave is not going to be much harder for the XMOS than >>>>>> a normal Ethernet MAC, but is impossible on any microcontroller >>>>>> without specialised peripherals. >>>>> >>>>> The Cypress PSoC has an interesting take on this. You can specify >>>>> (with the GUI) that you want a component. If you specify a simple >>>>> component (let's say I2C slave) there's a hard IP for that. But if >>>>> you specify something that's more complicated (say I2C master and >>>>> slave on the same pins) it builds it with the existing IP plus some >>>>> of its FPGA-like logic. Takes more resources but allows you to do >>>>> many more things than they put in as hard cores. >>>>> >>>>> Unfortunately they don't provide a vast quantity of cells for that >>>>> logic, so it's fine if you want to add just a few unusual bits to the >>>>> regular microcontroller, but not a big system. (PSoC also has the >>>>> programmable analogue stuff, which presumably constrains the process >>>>> they can use) >>>>> >>>>> It would be quite interesting to combine that with the XMOS approach >>>>> - more fluid boundaries between hardware and software. >>>>> >>>>> I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores >>>>> - lock down the cores running a task that absolutely needs to be >>>>> bounded-latency, and then multitask the remaining tasks across the >>>>> other cores. If that was provided as an integrated service then it >>>>> wouldn't need messing about running a scheduler. >>>> >>>> What scheduler? >>>> >>>> To a very useful approximation the an RTOS's functions are encoded in >>>> hardware. >>>> >>>> The "select" statement is like a "switch" statement, except that the >>>> core sleeps until one of the "case" conditions becomes true. In effect >>>> the case conditions are events. Events can be inputs arriving, outputs >>>> completing, timeouts, etc. >>> >>> Isn't that what interrupts are about? Many processors have a "halt and >>> wait for interrupt" instruction. >> >> Hardware on its own is trivial and has been done many times over the >> decades. >> >> XMOS have integrated the hardware with the software with the conceptual >> tools, and have provided excellent development tools. >> >> That has not been achieved elsewhere. > > Not sure what your point is. XMOS doesn't have programmable hardware, so > it's not clear what you are referring to "integrating". The only company > I've seen integrate the hardware and software is Cypress and that is fairly > crude. I'm not going to /poorly/ regurgitate XMOS information for you. Start with https://www.xmos.com/download/xCORE-Architecture-Flyer(1.3).pdf and then you will be able to ask more useful questions. > What exactly is special or unique about XMOS other than the fact they have N > processors with a shared memory on a single chip? The point is if this is > not the Goldilocks combination for you, the XMOS is not so great a chip. Sigh, IT ISN'T JUST THE PROCESSOR HARDWARE. Got the point? See the architecture flyer, and then add https://www.xmos.com/software/tools/ >>>> N.B. as far as a core is concerned, receiving input from a pin is the >>>> same as receiving a message from another task/core. Ditto output to a >>>> pin and sending a message to another task/core. Everything is via the >>>> "port" abstraction, and that extends down into the hardware and i/o >>>> system. >>> >>> That sounds a lot like the Transputer. >> >> Exactly. >> >> And xC is a modern successor to Occam, with CSP a core abstraction. >> >> Some of the original Transputer team are in XMOS. >> >> >> >> >>>> For a short intro to the hardware, software, and concepts see the >>>> architecture flyer. >>>> https://www.xmos.com/file/xcore-architecture-flyer/ >>>> >>>> FFI see the XMOS programming guide, which is beautifully written, >>>> succinct, and clear. https://www.xmos.com/file/xmos-programming-guide/ >>>> >>>> I wish all documentation was as good! >>>> >>>> >>>>> After all, there must be applications with a lot of >>>>> do-this-once-a-second tasks, that would be wasted using a whole core? >>>>> Do they have a scheduler where you can tell a task to sleep until a >>>>> particular time? >>>> >>>> See "combinable tasks" in my post in response to David Brown's post. >>>> >>>> >>>>> Or is FreeRTOS intended for that? In which case you presumably have >>>>> to write the code in a different way compared to the hard-tasks? >>>> >>>> I really don't see the point of FreeRTOS running inside an xCORE chip. >>>> To be over simplistic, RTOSs are designed to schedule multiple tasks >>>> on a single processor and to connect i/o with tasks (typically via >>>> interrupts). >>>> >>>> All that is done in hardware in the xCORE ecosystem. >>> >>> That's true of most processors, no? An I/O event happens and an >>> interrupt invokes a task called an interrupt handler. >>> >>> The tricky part is dealing with the real time requirements of handling >>> the I/O events. Which task must be done first, which tasks can be >>> interrupted to deal with other tasks, what resources are required to >>> process an event, etc. This is what makes real time multitasking >>> difficult. >> >> Those problems mostly disappear with sufficient independent cores. > > Hmmm... the keyword there is "sufficient". That was when I mentioned 144 > and the cycle began. Those cores can be regarded as merely "LUTs on steroids" :) >> What remains is the logical dependencies which can result in livelock or >> deadlock. No implementation technology can solve those, since they are >> inherent in either the problem or the architectural solution. > > Indeed. However these problems go away once you decompose your problem for > independent processors such as in an FPGA. I can't remember ever having to > even consider a deadlock other than the most simple of issues when designing > in an FPGA. If you have two independent FSMs sending events to each other, then you can get livelock and deadlock. Whether the FSMs are implemented in hardware, software, wetware, is irrelevant. Proving such systems of FSM are deadlock-free is an active research topic (and probably always will be). > Multitasking on a single processor (or even on several) can open up a design > to very complex interactions which have subtle failure modes. Yup. As I said, the implementation technology is irrelevant.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-19 15:02 -0700 |
| Message-ID | <6f97844e-f8b9-466b-980d-34dda8146aa4@googlegroups.com> |
| In reply to | #29519 |
On Sunday, April 19, 2020 at 5:15:20 PM UTC-4, Tom Gardner wrote: > On 19/04/20 21:37, Rick C wrote: > > On Sunday, April 19, 2020 at 5:11:22 AM UTC-4, Tom Gardner wrote: > >> On 18/04/20 22:53, Rick C wrote: > >>> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote: > >>>> On 18/04/20 16:51, Theo wrote: > >>>>> David Brown <david.brown@hesbynett.no> wrote: > >>>>>> The real power comes from when you want to do something that is > >>>>>> /not/ standard, or at least not common. > >>>>>> > >>>>>> Implementing a standard UART in a couple of XMOS cores is a > >>>>>> pointless waste of silicon. Implementing a UART that uses > >>>>>> Manchester encoding for the UART signals so that you can use it on > >>>>>> a balanced line without keeping track of which line is which - > >>>>>> /then/ you've got something that can be done just as easily on an > >>>>>> XMOS and is a big pain to do on a standard microcontroller. > >>>>>> > >>>>>> Implementing an Ethernet MAC on an XMOS is pointless. Implementing > >>>>>> an EtherCAT slave is not going to be much harder for the XMOS than > >>>>>> a normal Ethernet MAC, but is impossible on any microcontroller > >>>>>> without specialised peripherals. > >>>>> > >>>>> The Cypress PSoC has an interesting take on this. You can specify > >>>>> (with the GUI) that you want a component. If you specify a simple > >>>>> component (let's say I2C slave) there's a hard IP for that. But if > >>>>> you specify something that's more complicated (say I2C master and > >>>>> slave on the same pins) it builds it with the existing IP plus some > >>>>> of its FPGA-like logic. Takes more resources but allows you to do > >>>>> many more things than they put in as hard cores. > >>>>> > >>>>> Unfortunately they don't provide a vast quantity of cells for that > >>>>> logic, so it's fine if you want to add just a few unusual bits to the > >>>>> regular microcontroller, but not a big system. (PSoC also has the > >>>>> programmable analogue stuff, which presumably constrains the process > >>>>> they can use) > >>>>> > >>>>> It would be quite interesting to combine that with the XMOS approach > >>>>> - more fluid boundaries between hardware and software. > >>>>> > >>>>> I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores > >>>>> - lock down the cores running a task that absolutely needs to be > >>>>> bounded-latency, and then multitask the remaining tasks across the > >>>>> other cores. If that was provided as an integrated service then it > >>>>> wouldn't need messing about running a scheduler. > >>>> > >>>> What scheduler? > >>>> > >>>> To a very useful approximation the an RTOS's functions are encoded in > >>>> hardware. > >>>> > >>>> The "select" statement is like a "switch" statement, except that the > >>>> core sleeps until one of the "case" conditions becomes true. In effect > >>>> the case conditions are events. Events can be inputs arriving, outputs > >>>> completing, timeouts, etc. > >>> > >>> Isn't that what interrupts are about? Many processors have a "halt and > >>> wait for interrupt" instruction. > >> > >> Hardware on its own is trivial and has been done many times over the > >> decades. > >> > >> XMOS have integrated the hardware with the software with the conceptual > >> tools, and have provided excellent development tools. > >> > >> That has not been achieved elsewhere. > > > > Not sure what your point is. XMOS doesn't have programmable hardware, so > > it's not clear what you are referring to "integrating". The only company > > I've seen integrate the hardware and software is Cypress and that is fairly > > crude. > > I'm not going to /poorly/ regurgitate XMOS information for you. > > Start with > https://www.xmos.com/download/xCORE-Architecture-Flyer(1.3).pdf > and then you will be able to ask more useful questions. I think this conversation has come to an end. You made a claim that does not fit with what I know about the XMOS. If that claim is in the documentation, just provide a reference. I'm not going to wade through a bunch of docs to research YOUR claim. "XMOS have integrated the hardware with the software with the conceptual tools" Either support that, or don't bother making it. > > What exactly is special or unique about XMOS other than the fact they have N > > processors with a shared memory on a single chip? The point is if this is > > not the Goldilocks combination for you, the XMOS is not so great a chip. > > Sigh, IT ISN'T JUST THE PROCESSOR HARDWARE. Got the point? > See the architecture flyer, and then add > https://www.xmos.com/software/tools/ Then WHAT IS IT? See, you aren't the only one who can shout. Either discuss, or don't discuss. I'm not here to do your research. > >>>> N.B. as far as a core is concerned, receiving input from a pin is the > >>>> same as receiving a message from another task/core. Ditto output to a > >>>> pin and sending a message to another task/core. Everything is via the > >>>> "port" abstraction, and that extends down into the hardware and i/o > >>>> system. > >>> > >>> That sounds a lot like the Transputer. > >> > >> Exactly. > >> > >> And xC is a modern successor to Occam, with CSP a core abstraction. > >> > >> Some of the original Transputer team are in XMOS. > >> > >> > >> > >> > >>>> For a short intro to the hardware, software, and concepts see the > >>>> architecture flyer. > >>>> https://www.xmos.com/file/xcore-architecture-flyer/ > >>>> > >>>> FFI see the XMOS programming guide, which is beautifully written, > >>>> succinct, and clear. https://www.xmos.com/file/xmos-programming-guide/ > >>>> > >>>> I wish all documentation was as good! > >>>> > >>>> > >>>>> After all, there must be applications with a lot of > >>>>> do-this-once-a-second tasks, that would be wasted using a whole core? > >>>>> Do they have a scheduler where you can tell a task to sleep until a > >>>>> particular time? > >>>> > >>>> See "combinable tasks" in my post in response to David Brown's post. > >>>> > >>>> > >>>>> Or is FreeRTOS intended for that? In which case you presumably have > >>>>> to write the code in a different way compared to the hard-tasks? > >>>> > >>>> I really don't see the point of FreeRTOS running inside an xCORE chip. > >>>> To be over simplistic, RTOSs are designed to schedule multiple tasks > >>>> on a single processor and to connect i/o with tasks (typically via > >>>> interrupts). > >>>> > >>>> All that is done in hardware in the xCORE ecosystem. > >>> > >>> That's true of most processors, no? An I/O event happens and an > >>> interrupt invokes a task called an interrupt handler. > >>> > >>> The tricky part is dealing with the real time requirements of handling > >>> the I/O events. Which task must be done first, which tasks can be > >>> interrupted to deal with other tasks, what resources are required to > >>> process an event, etc. This is what makes real time multitasking > >>> difficult. > >> > >> Those problems mostly disappear with sufficient independent cores. > > > > Hmmm... the keyword there is "sufficient". That was when I mentioned 144 > > and the cycle began. > > Those cores can be regarded as merely "LUTs on steroids" :) YES! That's what I try to tell people and they often don't get it. I don't think of the GA144 as a multiprocessor. It's a FPPA, Field Programmable Processor Array. > >> What remains is the logical dependencies which can result in livelock or > >> deadlock. No implementation technology can solve those, since they are > >> inherent in either the problem or the architectural solution. > > > > Indeed. However these problems go away once you decompose your problem for > > independent processors such as in an FPGA. I can't remember ever having to > > even consider a deadlock other than the most simple of issues when designing > > in an FPGA. > > If you have two independent FSMs sending events to each other, > then you can get livelock and deadlock. Not if they are designed correctly. > Whether the FSMs are implemented in hardware, software, wetware, > is irrelevant. Absolutely. Bad design is not dependent on the implementation technology. > Proving such systems of FSM are deadlock-free is an active > research topic (and probably always will be). You must work with pretty large FSMs to worry about such things. > > Multitasking on a single processor (or even on several) can open up a design > > to very complex interactions which have subtle failure modes. > Yup. As I said, the implementation technology is irrelevant. What technology? If you are talking about single vs. multiprocessor I don't agree which should be pretty clear by now. -- Rick C. -+-+ Get 1,000 miles of free Supercharging -+-+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 02:03 +0100 |
| Message-ID | <Nx6nG.61278$nT6.56794@fx23.am4> |
| In reply to | #29521 |
On 19/04/20 23:02, Rick C wrote: > On Sunday, April 19, 2020 at 5:15:20 PM UTC-4, Tom Gardner wrote: >> On 19/04/20 21:37, Rick C wrote: >>> Not sure what your point is. XMOS doesn't have programmable hardware, >>> so it's not clear what you are referring to "integrating". The only >>> company I've seen integrate the hardware and software is Cypress and that >>> is fairly crude. >> >> I'm not going to /poorly/ regurgitate XMOS information for you. >> >> Start with https://www.xmos.com/download/xCORE-Architecture-Flyer(1.3).pdf >> and then you will be able to ask more useful questions. > > I think this conversation has come to an end. You made a claim that does not > fit with what I know about the XMOS. If that claim is in the documentation, > just provide a reference. I'm not going to wade through a bunch of docs to > research YOUR claim. That doc is all of 4 pages long. I'm not going to do your research for you. > "XMOS have integrated the hardware with the software with the conceptual > tools" > > Either support that, or don't bother making it. XMOS have supported it, as indicated. If you can't be bothered to read a 4 page document, you aren't interested in learning. >>> What exactly is special or unique about XMOS other than the fact they >>> have N processors with a shared memory on a single chip? The point is if >>> this is not the Goldilocks combination for you, the XMOS is not so great >>> a chip. >> >> Sigh, IT ISN'T JUST THE PROCESSOR HARDWARE. Got the point? See the >> architecture flyer, and then add https://www.xmos.com/software/tools/ > > Then WHAT IS IT? See, you aren't the only one who can shout. Either > discuss, or don't discuss. I'm not here to do your research. I don't need to research this. You do need to read a 4 page document and think about its contents. I can't do that for you. >>>>>> N.B. as far as a core is concerned, receiving input from a pin is >>>>>> the same as receiving a message from another task/core. Ditto >>>>>> output to a pin and sending a message to another task/core. >>>>>> Everything is via the "port" abstraction, and that extends down >>>>>> into the hardware and i/o system. >>>>> >>>>> That sounds a lot like the Transputer. >>>> >>>> Exactly. >>>> >>>> And xC is a modern successor to Occam, with CSP a core abstraction. >>>> >>>> Some of the original Transputer team are in XMOS. >>>> >>>> >>>> >>>> >>>>>> For a short intro to the hardware, software, and concepts see the >>>>>> architecture flyer. >>>>>> https://www.xmos.com/file/xcore-architecture-flyer/ >>>>>> >>>>>> FFI see the XMOS programming guide, which is beautifully written, >>>>>> succinct, and clear. >>>>>> https://www.xmos.com/file/xmos-programming-guide/ >>>>>> >>>>>> I wish all documentation was as good! >>>>>> >>>>>> >>>>>>> After all, there must be applications with a lot of >>>>>>> do-this-once-a-second tasks, that would be wasted using a whole >>>>>>> core? Do they have a scheduler where you can tell a task to sleep >>>>>>> until a particular time? >>>>>> >>>>>> See "combinable tasks" in my post in response to David Brown's >>>>>> post. >>>>>> >>>>>> >>>>>>> Or is FreeRTOS intended for that? In which case you presumably >>>>>>> have to write the code in a different way compared to the >>>>>>> hard-tasks? >>>>>> >>>>>> I really don't see the point of FreeRTOS running inside an xCORE >>>>>> chip. To be over simplistic, RTOSs are designed to schedule >>>>>> multiple tasks on a single processor and to connect i/o with tasks >>>>>> (typically via interrupts). >>>>>> >>>>>> All that is done in hardware in the xCORE ecosystem. >>>>> >>>>> That's true of most processors, no? An I/O event happens and an >>>>> interrupt invokes a task called an interrupt handler. >>>>> >>>>> The tricky part is dealing with the real time requirements of >>>>> handling the I/O events. Which task must be done first, which tasks >>>>> can be interrupted to deal with other tasks, what resources are >>>>> required to process an event, etc. This is what makes real time >>>>> multitasking difficult. >>>> >>>> Those problems mostly disappear with sufficient independent cores. >>> >>> Hmmm... the keyword there is "sufficient". That was when I mentioned >>> 144 and the cycle began. >> >> Those cores can be regarded as merely "LUTs on steroids" :) > > YES! That's what I try to tell people and they often don't get it. I don't > think of the GA144 as a multiprocessor. It's a FPPA, Field Programmable > Processor Array. A LUT is a long way from being a core. Very few people want to work at the level of individual LUTs. Those that do would probably use one of the original MACH or CPLD devices - very sensibly in my view. >>>> What remains is the logical dependencies which can result in livelock >>>> or deadlock. No implementation technology can solve those, since they >>>> are inherent in either the problem or the architectural solution. >>> >>> Indeed. However these problems go away once you decompose your problem >>> for independent processors such as in an FPGA. I can't remember ever >>> having to even consider a deadlock other than the most simple of issues >>> when designing in an FPGA. >> >> If you have two independent FSMs sending events to each other, then you can >> get livelock and deadlock. > > Not if they are designed correctly. Well, duh. Now /prove/ the design is correct - t'ain't easy. I've dealt with FSMs where different components have been developed by different companies over decades. That's standard in the telecom world. It has also occurred in some LANs. Good luck with some idealistic small-system design concepts those circumstances! >> Whether the FSMs are implemented in hardware, software, wetware, is >> irrelevant. > > Absolutely. Bad design is not dependent on the implementation technology. Not necessarily bad; real-world pragmatism is sufficient. >> Proving such systems of FSM are deadlock-free is an active research topic >> (and probably always will be). > > You must work with pretty large FSMs to worry about such things. I have done, yes. So have many other people. It is in the nature of telecom systems. There are many things in this world that you haven't experienced, but that doesn't mean they don't exist. (Example: European cities, how the infrastructure is built, and the impracticality of each dwelling having its own EV charging point.) >>> Multitasking on a single processor (or even on several) can open up a >>> design to very complex interactions which have subtle failure modes. >> Yup. As I said, the implementation technology is irrelevant. > > What technology? If you are talking about single vs. multiprocessor I don't > agree which should be pretty clear by now. Any technology.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-18 14:44 -0700 |
| Message-ID | <28323edc-6a2d-4f92-869f-1cfec1872120@googlegroups.com> |
| In reply to | #29501 |
On Saturday, April 18, 2020 at 11:51:55 AM UTC-4, Theo wrote: > David Brown <david.brown@hesbynett.no> wrote: > > The real power comes from when you want to do something that is /not/ > > standard, or at least not common. > > > > Implementing a standard UART in a couple of XMOS cores is a pointless > > waste of silicon. Implementing a UART that uses Manchester encoding for > > the UART signals so that you can use it on a balanced line without > > keeping track of which line is which - /then/ you've got something that > > can be done just as easily on an XMOS and is a big pain to do on a > > standard microcontroller. > > > > Implementing an Ethernet MAC on an XMOS is pointless. Implementing an > > EtherCAT slave is not going to be much harder for the XMOS than a normal > > Ethernet MAC, but is impossible on any microcontroller without > > specialised peripherals. > > The Cypress PSoC has an interesting take on this. You can specify (with the > GUI) that you want a component. If you specify a simple component (let's > say I2C slave) there's a hard IP for that. But if you specify something > that's more complicated (say I2C master and slave on the same pins) it > builds it with the existing IP plus some of its FPGA-like logic. Takes more > resources but allows you to do many more things than they put in as hard > cores. It is hard to talk about the PSoC devices because they have so many very different flavors, each different in significant ways. They have some devices that don't actually have any programmable logic, rather just a couple of flexible serial ports that can be a variety of serial devices. Others have logic that is at a lower level of complexity, but typically very different from FPGAs. The comparison is not very useful. The main difference is that while they may support Verilog, I'm pretty sure it is not a very complete implementation in that you can't describe arbitrary logic with it. I don't know this for certain, but the devices are so limited in the logic they contain that it would be hard to do much with them. I'd like to see a FSM implementation of something bigger than a stop light or elevator. > Unfortunately they don't provide a vast quantity of cells for that logic, so > it's fine if you want to add just a few unusual bits to the regular > microcontroller, but not a big system. (PSoC also has the programmable > analogue stuff, which presumably constrains the process they can use) I believe that is correct for a pretty wide range of "big". I don't think the analog logic constrains the programmability so much, but the digital makes it hard to include very good analog. Programmable logic is not silicon efficient which is typically dealt with by using the most advanced processes and smallest feature sizes. That's not compatible with Flash. -- Rick C. ---- Get 1,000 miles of free Supercharging ---- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 15:20 +0200 |
| Message-ID | <r7k7ic$d4u$1@dont-email.me> |
| In reply to | #29501 |
On 18/04/2020 17:51, Theo wrote: > David Brown <david.brown@hesbynett.no> wrote: >> The real power comes from when you want to do something that is /not/ >> standard, or at least not common. >> >> Implementing a standard UART in a couple of XMOS cores is a pointless >> waste of silicon. Implementing a UART that uses Manchester encoding for >> the UART signals so that you can use it on a balanced line without >> keeping track of which line is which - /then/ you've got something that >> can be done just as easily on an XMOS and is a big pain to do on a >> standard microcontroller. >> >> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an >> EtherCAT slave is not going to be much harder for the XMOS than a normal >> Ethernet MAC, but is impossible on any microcontroller without >> specialised peripherals. > > The Cypress PSoC has an interesting take on this. You can specify (with the > GUI) that you want a component. If you specify a simple component (let's > say I2C slave) there's a hard IP for that. But if you specify something > that's more complicated (say I2C master and slave on the same pins) it > builds it with the existing IP plus some of its FPGA-like logic. Takes more > resources but allows you to do many more things than they put in as hard > cores. > > Unfortunately they don't provide a vast quantity of cells for that logic, so > it's fine if you want to add just a few unusual bits to the regular > microcontroller, but not a big system. (PSoC also has the programmable > analogue stuff, which presumably constrains the process they can use) > My impression with PSoC's has always been that they have too few digital blocks. It's been a good many years since I looked at them (I try to keep up with different architectures beyond those that I use, but there are so many!), and no doubt there are bigger devices now. But at the time I tried to figure out if they could work for a couple of boards I was working on, and they would have needed several times as many digital blocks to work. > It would be quite interesting to combine that with the XMOS approach - more > fluid boundaries between hardware and software. XMOS does have some things in hardware - for the IO ports, they have shift registers with parallel/serial conversion and buffering, and a whole lot of timers. (Tom's posts answer the rest of your points.)
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 14:57 +0100 |
| Message-ID | <1ThnG.93793$QJp.31354@fx08.am4> |
| In reply to | #29531 |
On 20/04/20 14:20, David Brown wrote: > On 18/04/2020 17:51, Theo wrote: >> David Brown <david.brown@hesbynett.no> wrote: >>> The real power comes from when you want to do something that is /not/ >>> standard, or at least not common. >>> >>> Implementing a standard UART in a couple of XMOS cores is a pointless >>> waste of silicon. Implementing a UART that uses Manchester encoding for >>> the UART signals so that you can use it on a balanced line without >>> keeping track of which line is which - /then/ you've got something that >>> can be done just as easily on an XMOS and is a big pain to do on a >>> standard microcontroller. >>> >>> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an >>> EtherCAT slave is not going to be much harder for the XMOS than a normal >>> Ethernet MAC, but is impossible on any microcontroller without >>> specialised peripherals. >> >> The Cypress PSoC has an interesting take on this. You can specify (with the >> GUI) that you want a component. If you specify a simple component (let's >> say I2C slave) there's a hard IP for that. But if you specify something >> that's more complicated (say I2C master and slave on the same pins) it >> builds it with the existing IP plus some of its FPGA-like logic. Takes more >> resources but allows you to do many more things than they put in as hard >> cores. >> >> Unfortunately they don't provide a vast quantity of cells for that logic, so >> it's fine if you want to add just a few unusual bits to the regular >> microcontroller, but not a big system. (PSoC also has the programmable >> analogue stuff, which presumably constrains the process they can use) >> > > My impression with PSoC's has always been that they have too few digital > blocks. It's been a good many years since I looked at them (I try to keep up > with different architectures beyond those that I use, but there are so many!), > and no doubt there are bigger devices now. But at the time I tried to figure > out if they could work for a couple of boards I was working on, and they would > have needed several times as many digital blocks to work. > >> It would be quite interesting to combine that with the XMOS approach - more >> fluid boundaries between hardware and software. > > XMOS does have some things in hardware - for the IO ports, they have shift > registers with parallel/serial conversion and buffering, and a whole lot of timers. > > (Tom's posts answer the rest of your points.) FFI about ports, see https://www.xmos.com/download/Introduction-to-XS1-ports(1.0).pdf Overview... Unbuffered ports: - standard clocked: up to 250MHz, independent rate from processor clocks - timed: occurs at a specific counter count (each port has its own counter) - timestamped: records when i/o actually occurred - conditional input: ignore unless == or != a value - 1/4/8/16/32 bits wide Buffered ports: - as above plus single level of buffering - SERDES Strobed ports: - master/slave/bidirectional The i/o setup is also pleasingly simple and orthogonal, effectively declarative. No mucking about with obscure registers :)
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web