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 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-22 17:03 +0000 |
| Message-ID | <r7ptdp$h8v$2@reader2.panix.com> |
| In reply to | #29591 |
On 2020-04-22, upsidedown@downunder.com <upsidedown@downunder.com> wrote: > My main point was that if you are going to transfer a significant > number of bytes/node (say at least 10 bytes), why use EtherCAT in > the first place ? Because that's what the rest of the plant is using. Not all EtherCAT nodes are identical. Many may only be exchanging a few bits. Some need to do more. The nodes that need to do more may need more processing power. > You could then use any standard garden variety RS-422/485 or > 10/100/1000BaseT hardware with some standard protocol, even Modbus > RTU/UDP/TCP. That requires a whole new cabling infrascture. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-22 11:16 +0200 |
| Message-ID | <r7p21i$iqt$1@dont-email.me> |
| In reply to | #29575 |
On 21/04/2020 19:29, upsidedown@downunder.com wrote: > On Sat, 18 Apr 2020 15:06:53 +0200, David Brown > <david.brown@hesbynett.no> wrote: > >> >> 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. > > Traditional industrial protocols, like Profibus and Modbus (with all > their variants) have a quite high overhead Thus, if a slave only > wants to communicate a few bits or a single byte over the network, it > will suffer a very low transfer efficiency using standard protocols. > > With EtherCAT, it is possible to make very small nodes with only a few > bits added/removed from the frame circulating around the industrial > plants with only a few bit time additional propagation delay in each > node. So it looks good. > Yes. > However, EtherCAT nodes are still quite expensive and if you add/drop > only a few bits in each node doesn't make economical sense. It does make sense in the automation world. A key point is that the bits get added or dropped where you want them dropped. > > What is the point of using multicore processors, if a single core can > perform the basic EtherCAT node functionality. You can't cut the > multicore chip and distribute it to multiple physically separate > nodes:-). An EtherCAT slave would take more than one virtual core on an XMOS - probably 3-6, I would guess, depending on the features you want. But if you only want a few bits of data you'd use a simple EtherCAT peripheral with digital IO, not a microcontroller at all. > > > In addition, if there are dozens of series connected twisted pair > connectors, what is the electromechanical reliability of each > connection ? A single fault will prevent the Ethernet frame > circulating back to the master. > EtherCAT is always logically a ring, and you can (if you want) have both ends connected back to the master. That means you can break the ring - either by accident, or while changing the live network - and things carry on as before. > I much more prefer a dual layer approach, with CANbus (or CAN FD) up > to a few meters transferring a few bits or a byte or two around the > CAN bus and using concentrator nodes with communicate to a higher > level systems using some traditional protocols, transferring perhaps > 100 bytes in a single transaction. > Different solutions work best in different circumstances. EtherCAT is not for everyone.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-17 10:48 -0700 |
| Message-ID | <01a3df3f-c74f-4201-bfd2-a4570bbf19d0@googlegroups.com> |
| In reply to | #29487 |
On Friday, April 17, 2020 at 12:15:37 PM UTC-4, David Brown wrote: > On 17/04/2020 16:23, Tom Gardner wrote: > > On 17/04/20 14:44, David Brown wrote: > >> On 17/04/2020 11:49, Tom Gardner wrote: > >>> On 17/04/20 09:02, David Brown wrote: > > >>> As you say, the XMOS /ecosystem/ is far more compelling, > >>> partly because it has excellent /integration/ between the > >>> hardware, the software and the toolchain. The latter two > >>> are usually missing. > >> > >> Agreed. And the XMOS folk have learned and improved. With the first > >> chips, they proudly showed off that you could make a 100 MBit Ethernet > >> controller in software on an XMOS chip. Then it was pointed out to > >> them that - impressive achievement though it was - it was basically > >> useless because you didn't have the resources left to use it for much, > >> and hardware Ethernet controllers were much cheaper. So they brought > >> out new XMOS chips with hardware Ethernet controllers. The same thing > >> happened with USB. > > > > It looks like a USB controller needs ~8 cores, which isn't > > a problem on a 16 core device :) > > > > I've had another look, and I was mistaken - these devices only have the > USB and Ethernet PHYs, not the MACs, and thus require a lot of processor > power, pins, memory and other resources. It doesn't need 8 cores, but > the whole thing just seems so inefficient. No one is going to spend the > extra cost for an XMOS with a USB PHY, so why not put a hardware USB > controller on the chip? The silicon costs would surely be minor, and it > would save a lot of development effort and release resources that are > useful for other tasks. The same goes for Ethernet. Just because you > /can/ make these things in software on the XMOS devices, does not make > it a good idea. > > Overall, the thing that bugs me about XMOS is that you can write very > simple, elegant tasks for the cores to do various tasks. But when you > do that, you run out of cores almost immediately. So you have to write > your code in a way that implements your own scheduler, losing a major > part of the point of the whole system. Or you use the XMOS FreeRTOS > port on one of the virtual cores - in which case you could just switch > to a Cortex-M microcontroller with hardware USB, Ethernet, PWM, UART, > etc. and a fraction of the price. Too bad the XMOS doesn't have more CPUs, like maybe 144 of them? > If the XMOS devices and software had a way of neatly multi-tasking > /within/ a single virtual core, while keeping the same kind of > inter-task communication and other benefits, then they would have > something I could see being very nice. Is a "virtual core" one CPU? Multitasking a single CPU is the thing the XMOS is supposed to eliminate, no? Why bring it back? Oh, because there aren't enough CPUs on the XMOS for some applications! So it's back to the fast ARM processors and multitasking. I seem to recall there being asymmetric multicores from various ARM makers with one fast CPU for multitasking and a smaller CPU for handling the lesser real time tasks without interference. That's a good combination, but again, a more specific target market. It seems that is how the CPU market has gone. The volumes are so high there are many niche areas justifying their own type of SoC to address it. > >> There is a lot to like about XMOS devices and tools, but they still > >> strike me as a solution in search of a problem. An elegant solution, > >> perhaps, but still missing a problem. We used them for a project many > >> years ago for a USB Audio Class 2 device. There simply were no > >> realistic alternatives at the time, but I can't say the XMOS solution > >> was a good one. The device has far too little memory to make sensible > >> buffers (this still applies to XMOS devices, last I looked), and the > >> software at the time was painful (this I believe has improved > >> significantly). If we were making a new version of the product, we'd > >> drop the XMOS device in an instant and use an off-the-shelf chip instead. > > > > I certainly wouldn't want to comment on your use case. > > As I said, it was a while ago, when XMOS were relatively new - I assume > the software, libraries and examples are better now than at that time. > But for applications like ours, you can just get a CMedia chip and wire > it up - no matter how good XMOS tools have become, they don't beat that. > > (And then all the development budget can be spent on trying to get > drivers to work on idiotic Windows systems...) > > > > > To me a large part of the attraction is that you can > > /predict/ the /worst/ case latency and jitter (and hence > > throughput), in a way that is difficult in a standard MCU > > and easy in an FPGA. > > For standard MCU's, you aim to do this by using hardware peripherals > (timers, PWM blocks, communication controllers, etc.) for the most > timing-critical stuff. Then you don't need it in the software. And all that hardware costs chip space which you may or may not use. That's why they have so many flavors, to give the "perfect" combination of memory, peripherals and analog to minimize cost for each project. FPGAs have a cost overhead which is fading into the background as they become more and more efficient. For many designs an FPGA provides a good trade off between cost and flexibility. In many cases it also provides a functionality that can't be duplicated elsewhere. > > To that extent it allows FPGA-like performance with "traditional" > > software development tools and methodologies. Plus a little > > bit of "thinking parallel" that everybody will soon /have/ to > > be doing :) > > It's a nice idea, and I'm sure XMOS has some good use-cases. But I > can't help feeling they have something that is /almost/ a good system - > with a bit more, they could be very much more useful. It's good, it just has it's own niche of applications where it is the best solution. Nothing wrong with that! -- 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-18 16:57 +0200 |
| Message-ID | <r7f4hf$18t$1@dont-email.me> |
| In reply to | #29490 |
On 17/04/2020 19:48, Rick C wrote: > On Friday, April 17, 2020 at 12:15:37 PM UTC-4, David Brown wrote: >> On 17/04/2020 16:23, Tom Gardner wrote: >>> On 17/04/20 14:44, David Brown wrote: >>>> On 17/04/2020 11:49, Tom Gardner wrote: >>>>> On 17/04/20 09:02, David Brown wrote: >> >>>>> As you say, the XMOS /ecosystem/ is far more compelling, >>>>> partly because it has excellent /integration/ between the >>>>> hardware, the software and the toolchain. The latter two are >>>>> usually missing. >>>> >>>> Agreed. And the XMOS folk have learned and improved. With the >>>> first chips, they proudly showed off that you could make a 100 >>>> MBit Ethernet controller in software on an XMOS chip. Then it >>>> was pointed out to them that - impressive achievement though it >>>> was - it was basically useless because you didn't have the >>>> resources left to use it for much, and hardware Ethernet >>>> controllers were much cheaper. So they brought out new XMOS >>>> chips with hardware Ethernet controllers. The same thing >>>> happened with USB. >>> >>> It looks like a USB controller needs ~8 cores, which isn't a >>> problem on a 16 core device :) >>> >> >> I've had another look, and I was mistaken - these devices only have >> the USB and Ethernet PHYs, not the MACs, and thus require a lot of >> processor power, pins, memory and other resources. It doesn't need >> 8 cores, but the whole thing just seems so inefficient. No one is >> going to spend the extra cost for an XMOS with a USB PHY, so why >> not put a hardware USB controller on the chip? The silicon costs >> would surely be minor, and it would save a lot of development >> effort and release resources that are useful for other tasks. The >> same goes for Ethernet. Just because you /can/ make these things >> in software on the XMOS devices, does not make it a good idea. >> >> Overall, the thing that bugs me about XMOS is that you can write >> very simple, elegant tasks for the cores to do various tasks. But >> when you do that, you run out of cores almost immediately. So you >> have to write your code in a way that implements your own >> scheduler, losing a major part of the point of the whole system. >> Or you use the XMOS FreeRTOS port on one of the virtual cores - in >> which case you could just switch to a Cortex-M microcontroller with >> hardware USB, Ethernet, PWM, UART, etc. and a fraction of the >> price. > > Too bad the XMOS doesn't have more CPUs, like maybe 144 of them? > 144 cpus is far more than would be useful in practice - as long as you have cores that can do useful work in a flexible way (like XMOS cores). When you have very limited cores that can barely do anything themselves, you need lots of them. (Arguably that's what you have on an FPGA - lots of tiny bits that do very little on their own. But the key difference is the tools - FPGA's would be a lot less popular if you had to code each LU individually, do placement manually by numbering them, and write a routing file by hand.) > >> If the XMOS devices and software had a way of neatly multi-tasking >> /within/ a single virtual core, while keeping the same kind of >> inter-task communication and other benefits, then they would have >> something I could see being very nice. > > Is a "virtual core" one CPU? Multitasking a single CPU is the thing > the XMOS is supposed to eliminate, no? Why bring it back? Oh, > because there aren't enough CPUs on the XMOS for some applications! > So it's back to the fast ARM processors and multitasking. > When you are writing multi-tasking code, you often want a lot of tasks. More than 8. (Sometimes, just to be more awkward, you want them to be created dynamically.) Any specific limit is an inconvenient limit. There are always ways to get round this - like using an RTOS on one virtual core of the XMOS. But you lose some of the symmetry and convenience that way. (I understand why the XMOS is designed the way it is - any system is going to be a compromise between what the hardware designers can do practically, and what the software designers want.) > I seem to recall there being asymmetric multicores from various ARM > makers with one fast CPU for multitasking and a smaller CPU for > handling the lesser real time tasks without interference. > Yes - you have a Cortex-A cpu that can handle high throughtput, perhaps with several cores, combined with a Cortex-M device that is more deterministic and can give more real-time control. > That's a good combination, but again, a more specific target market. > It seems that is how the CPU market has gone. The volumes are so > high there are many niche areas justifying their own type of SoC to > address it. > These are becoming increasingly common - they are no longer niche. If you have a system that needs the processing power of a bigger cpu (for screens, image handling, embedded Linux, the convenience and low development costs of high-level languages and off-the-shelf libraries, etc.) then having a small cpu for handling ADC's, timers, PWM, UARTs, power management, keys, and that kind of thing is a big win. Even combinations of fast M7 or M4 cores with an M0 core are common, especially if you have a specific task for the small core (like running a Bluetooth stack for an embedded wireless device). > >>>> There is a lot to like about XMOS devices and tools, but they >>>> still strike me as a solution in search of a problem. An >>>> elegant solution, perhaps, but still missing a problem. We >>>> used them for a project many years ago for a USB Audio Class 2 >>>> device. There simply were no realistic alternatives at the >>>> time, but I can't say the XMOS solution was a good one. The >>>> device has far too little memory to make sensible buffers (this >>>> still applies to XMOS devices, last I looked), and the software >>>> at the time was painful (this I believe has improved >>>> significantly). If we were making a new version of the >>>> product, we'd drop the XMOS device in an instant and use an >>>> off-the-shelf chip instead. >>> >>> I certainly wouldn't want to comment on your use case. >> >> As I said, it was a while ago, when XMOS were relatively new - I >> assume the software, libraries and examples are better now than at >> that time. But for applications like ours, you can just get a >> CMedia chip and wire it up - no matter how good XMOS tools have >> become, they don't beat that. >> >> (And then all the development budget can be spent on trying to get >> drivers to work on idiotic Windows systems...) >> >>> >>> To me a large part of the attraction is that you can /predict/ >>> the /worst/ case latency and jitter (and hence throughput), in a >>> way that is difficult in a standard MCU and easy in an FPGA. >> >> For standard MCU's, you aim to do this by using hardware >> peripherals (timers, PWM blocks, communication controllers, etc.) >> for the most timing-critical stuff. Then you don't need it in the >> software. > > And all that hardware costs chip space which you may or may not use. > That's why they have so many flavors, to give the "perfect" > combination of memory, peripherals and analog to minimize cost for > each project. The silicon costs of basic peripherals like timers and UARTs is tiny - generally close to irrelevant. Ethernet is a bit more costly, and some kinds of peripherals have additional cost such as royalties (this used to be the case for CAN controllers until the patents ran out). Analogue parts can be most costly in silicon space, especially if they need calibrating in some way. Much of the cost of peripherals is in the IO blocks and drivers, and the multiplexing and signal routing to support them. Memory blocks - while simple - usually take up a much bigger part of the die area. > > FPGAs have a cost overhead which is fading into the background as > they become more and more efficient. For many designs an FPGA > provides a good trade off between cost and flexibility. In many > cases it also provides a functionality that can't be duplicated > elsewhere. Sure, FPGAs have their uses - including areas where they are the only sensible solution, and areas of overlap where either microcontrollers or FPGAs could do the job. When looking at the cost of making these choices, there are three main parts. The development costs, the production costs, and the lifetime costs. How you balance these will depend on the type of product, the quantities you make, the use of the product, and its expected lifetime. So no single answer is every going to be "right". But one thing is very clear - for developers and companies that have done a lot of FPGA development, the costs of developing a new FPGA-based device will be far smaller than for a company that has not done such systems before. Don't assume that because FPGA design is cheap for /you/ to do, that it is necessarily cheap for others. The opposite is true as well - there are plenty of boards made where an FPGA (or other programmable logic) would make things simpler and cheaper, but is not seriously considered because programmable logic is often viewed as expensive and difficult. About the only thing you can be sure of in embedded development is that there are many possible answers. And for any serious project, by the time you have a finished product there will be new devices and new answers that could have made the whole thing cheaper! > > >>> To that extent it allows FPGA-like performance with >>> "traditional" software development tools and methodologies. Plus >>> a little bit of "thinking parallel" that everybody will soon >>> /have/ to be doing :) >> >> It's a nice idea, and I'm sure XMOS has some good use-cases. But >> I can't help feeling they have something that is /almost/ a good >> system - with a bit more, they could be very much more useful. > > It's good, it just has it's own niche of applications where it is the > best solution. Nothing wrong with that! > Indeed. I think what bugs me most is that those niches haven't yet turned up in the projects my customers are asking for!
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-18 14:21 -0700 |
| Message-ID | <387cadbe-b7d5-48d3-bb88-5c567f4078c1@googlegroups.com> |
| In reply to | #29498 |
On Saturday, April 18, 2020 at 10:57:55 AM UTC-4, David Brown wrote: > On 17/04/2020 19:48, Rick C wrote: > > On Friday, April 17, 2020 at 12:15:37 PM UTC-4, David Brown wrote: > >> On 17/04/2020 16:23, Tom Gardner wrote: > >>> On 17/04/20 14:44, David Brown wrote: > >>>> On 17/04/2020 11:49, Tom Gardner wrote: > >>>>> On 17/04/20 09:02, David Brown wrote: > >> > >>>>> As you say, the XMOS /ecosystem/ is far more compelling, > >>>>> partly because it has excellent /integration/ between the > >>>>> hardware, the software and the toolchain. The latter two are > >>>>> usually missing. > >>>> > >>>> Agreed. And the XMOS folk have learned and improved. With the > >>>> first chips, they proudly showed off that you could make a 100 > >>>> MBit Ethernet controller in software on an XMOS chip. Then it > >>>> was pointed out to them that - impressive achievement though it > >>>> was - it was basically useless because you didn't have the > >>>> resources left to use it for much, and hardware Ethernet > >>>> controllers were much cheaper. So they brought out new XMOS > >>>> chips with hardware Ethernet controllers. The same thing > >>>> happened with USB. > >>> > >>> It looks like a USB controller needs ~8 cores, which isn't a > >>> problem on a 16 core device :) > >>> > >> > >> I've had another look, and I was mistaken - these devices only have > >> the USB and Ethernet PHYs, not the MACs, and thus require a lot of > >> processor power, pins, memory and other resources. It doesn't need > >> 8 cores, but the whole thing just seems so inefficient. No one is > >> going to spend the extra cost for an XMOS with a USB PHY, so why > >> not put a hardware USB controller on the chip? The silicon costs > >> would surely be minor, and it would save a lot of development > >> effort and release resources that are useful for other tasks. The > >> same goes for Ethernet. Just because you /can/ make these things > >> in software on the XMOS devices, does not make it a good idea. > >> > >> Overall, the thing that bugs me about XMOS is that you can write > >> very simple, elegant tasks for the cores to do various tasks. But > >> when you do that, you run out of cores almost immediately. So you > >> have to write your code in a way that implements your own > >> scheduler, losing a major part of the point of the whole system. > >> Or you use the XMOS FreeRTOS port on one of the virtual cores - in > >> which case you could just switch to a Cortex-M microcontroller with > >> hardware USB, Ethernet, PWM, UART, etc. and a fraction of the > >> price. > > > > Too bad the XMOS doesn't have more CPUs, like maybe 144 of them? > > > > 144 cpus is far more than would be useful in practice - as long as you > have cores that can do useful work in a flexible way (like XMOS cores). > When you have very limited cores that can barely do anything > themselves, you need lots of them. The point of the XMOS concept is to not have to do multitasking on a single core. As soon as your task number exceeds the number of cores you have to do multitasking on a single core. No one ever complains about having too many resources. The design process for many small CPUs is not the same as a few larger CPUs. But the point is it can be simpler, more like designing hardware. Atmel had an FPGA with a simple logic element equivalent to a 3 input LUT and FF (done with a small number of gates rather than the larger LUT structure). It had relatively little routing, connecting logic elements to adjacent logic elements almost as the only routing. The theory was the simplicity of the logic elements meant you could have a lot more of them for a given amount of real estate/$$$ so you could afford to use them for routing. In practice they never kept up with state of the art process technology, so this didn't pan out. But that is the concept of the many small cores. You don't have to focus on being highly efficient with your CPU resources since you have so many. > (Arguably that's what you have on an FPGA - lots of tiny bits that do > very little on their own. But the key difference is the tools - FPGA's > would be a lot less popular if you had to code each LU individually, do > placement manually by numbering them, and write a routing file by hand.) Huh? Why can't any of that be automated in the many CPU chip? Certainly the issue is not so important with only 144 processors, but the same size chip would have many thousands of processors in a more modern technology. I think the GA144 is 180 nm. Bring that down to 15 nm and you have 15,000 nodes on a chip just 5 mm square!!! That will require better tools for sure. Some of your use of language is interesting. "lots of tiny bits that do very little on their own". That sounds like the way people write software. They decompose a large, complex design into lots of tiny routines that individually do little on their own. How can you manage all that complexity??? Yes, I think the Zeno paradox must apply so that no large program can ever be finished. That certainly happens sometimes. > >> If the XMOS devices and software had a way of neatly multi-tasking > >> /within/ a single virtual core, while keeping the same kind of > >> inter-task communication and other benefits, then they would have > >> something I could see being very nice. > > > > Is a "virtual core" one CPU? Multitasking a single CPU is the thing > > the XMOS is supposed to eliminate, no? Why bring it back? Oh, > > because there aren't enough CPUs on the XMOS for some applications! > > So it's back to the fast ARM processors and multitasking. > > > > When you are writing multi-tasking code, you often want a lot of tasks. > More than 8. (Sometimes, just to be more awkward, you want them to be > created dynamically.) Any specific limit is an inconvenient limit. > > There are always ways to get round this - like using an RTOS on one > virtual core of the XMOS. But you lose some of the symmetry and > convenience that way. "Some of the symmetry and convenience"? That's supposed to be the whole point! > (I understand why the XMOS is designed the way it is - any system is > going to be a compromise between what the hardware designers can do > practically, and what the software designers want.) > > > I seem to recall there being asymmetric multicores from various ARM > > makers with one fast CPU for multitasking and a smaller CPU for > > handling the lesser real time tasks without interference. > > > > Yes - you have a Cortex-A cpu that can handle high throughtput, perhaps > with several cores, combined with a Cortex-M device that is more > deterministic and can give more real-time control. That's also the idea to CPUs in FPGAs. > > That's a good combination, but again, a more specific target market. > > It seems that is how the CPU market has gone. The volumes are so > > high there are many niche areas justifying their own type of SoC to > > address it. > > > > These are becoming increasingly common - they are no longer niche. If > you have a system that needs the processing power of a bigger cpu (for > screens, image handling, embedded Linux, the convenience and low > development costs of high-level languages and off-the-shelf libraries, > etc.) then having a small cpu for handling ADC's, timers, PWM, UARTs, > power management, keys, and that kind of thing is a big win. > > Even combinations of fast M7 or M4 cores with an M0 core are common, > especially if you have a specific task for the small core (like running > a Bluetooth stack for an embedded wireless device). I was talking in general, not just to asymmetric multiprocessors, peripherals, memory, I/O... > >>>> There is a lot to like about XMOS devices and tools, but they > >>>> still strike me as a solution in search of a problem. An > >>>> elegant solution, perhaps, but still missing a problem. We > >>>> used them for a project many years ago for a USB Audio Class 2 > >>>> device. There simply were no realistic alternatives at the > >>>> time, but I can't say the XMOS solution was a good one. The > >>>> device has far too little memory to make sensible buffers (this > >>>> still applies to XMOS devices, last I looked), and the software > >>>> at the time was painful (this I believe has improved > >>>> significantly). If we were making a new version of the > >>>> product, we'd drop the XMOS device in an instant and use an > >>>> off-the-shelf chip instead. > >>> > >>> I certainly wouldn't want to comment on your use case. > >> > >> As I said, it was a while ago, when XMOS were relatively new - I > >> assume the software, libraries and examples are better now than at > >> that time. But for applications like ours, you can just get a > >> CMedia chip and wire it up - no matter how good XMOS tools have > >> become, they don't beat that. > >> > >> (And then all the development budget can be spent on trying to get > >> drivers to work on idiotic Windows systems...) > >> > >>> > >>> To me a large part of the attraction is that you can /predict/ > >>> the /worst/ case latency and jitter (and hence throughput), in a > >>> way that is difficult in a standard MCU and easy in an FPGA. > >> > >> For standard MCU's, you aim to do this by using hardware > >> peripherals (timers, PWM blocks, communication controllers, etc.) > >> for the most timing-critical stuff. Then you don't need it in the > >> software. > > > > And all that hardware costs chip space which you may or may not use. > > That's why they have so many flavors, to give the "perfect" > > combination of memory, peripherals and analog to minimize cost for > > each project. > > The silicon costs of basic peripherals like timers and UARTs is tiny - > generally close to irrelevant. Ethernet is a bit more costly, and some > kinds of peripherals have additional cost such as royalties (this used > to be the case for CAN controllers until the patents ran out). Analogue > parts can be most costly in silicon space, especially if they need > calibrating in some way. Much of the cost of peripherals is in the IO > blocks and drivers, and the multiplexing and signal routing to support them. > > Memory blocks - while simple - usually take up a much bigger part of the > die area. Yes, memory is the big dog. Peripherals aren't quite irrelevant though, in total they are often as large or larger than the CPU. > > FPGAs have a cost overhead which is fading into the background as > > they become more and more efficient. For many designs an FPGA > > provides a good trade off between cost and flexibility. In many > > cases it also provides a functionality that can't be duplicated > > elsewhere. > > Sure, FPGAs have their uses - including areas where they are the only > sensible solution, and areas of overlap where either microcontrollers or > FPGAs could do the job. > > When looking at the cost of making these choices, there are three main > parts. The development costs, the production costs, and the lifetime > costs. How you balance these will depend on the type of product, the > quantities you make, the use of the product, and its expected lifetime. > So no single answer is every going to be "right". But one thing is > very clear - for developers and companies that have done a lot of FPGA > development, the costs of developing a new FPGA-based device will be far > smaller than for a company that has not done such systems before. Don't > assume that because FPGA design is cheap for /you/ to do, that it is > necessarily cheap for others. > > The opposite is true as well - there are plenty of boards made where an > FPGA (or other programmable logic) would make things simpler and > cheaper, but is not seriously considered because programmable logic is > often viewed as expensive and difficult. Yeah, that's why I get work. I make it easy. -- Rick C. +++ Get 1,000 miles of free Supercharging +++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-18 14:50 -0700 |
| Message-ID | <87zhb84g6k.fsf@nightsong.com> |
| In reply to | #29506 |
Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Some of your use of language is interesting. "lots of tiny bits that
> do very little on their own". That sounds like the way people write
> software. They decompose a large, complex design into lots of tiny
> routines that individually do little on their own. How can you manage
> all that complexity???
Use abstractions to reason about large chunks of the code, and encode
the abstractions and the reasoning into the code itself so that the
compiler can check the reasoning's validity. Checking reasoning is
basically what a static type system does.
There is something of a "wheel of karma" going on, where bigger
abstractions make reasoning simpler, decreasing the amount of compiler
checking needed. So unchecked languages like assembler and Forth led to
checked ones like C, but then Python delivered bigger abstractions which
got rid of the need for some checking, but then Python programs got
bigger so now Python has grown a static checking feature ("mypy").
After that is probably something like Wolfram Alpha, which I haven't used.
> Yes, I think the Zeno paradox must apply so that no large program can
> ever be finished. That certainly happens sometimes.
The sayign I'm used to is that no program is ever finished til the last
user is dead. ;)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 16:32 +0200 |
| Message-ID | <r7kbpr$btb$1@dont-email.me> |
| In reply to | #29506 |
On 18/04/2020 23:21, Rick C wrote: > On Saturday, April 18, 2020 at 10:57:55 AM UTC-4, David Brown wrote: >> On 17/04/2020 19:48, Rick C wrote: >>> On Friday, April 17, 2020 at 12:15:37 PM UTC-4, David Brown >>> wrote: >>>> On 17/04/2020 16:23, Tom Gardner wrote: >>>>> On 17/04/20 14:44, David Brown wrote: >>>>>> On 17/04/2020 11:49, Tom Gardner wrote: >>>>>>> On 17/04/20 09:02, David Brown wrote: >>>> >>>>>>> As you say, the XMOS /ecosystem/ is far more compelling, >>>>>>> partly because it has excellent /integration/ between >>>>>>> the hardware, the software and the toolchain. The latter >>>>>>> two are usually missing. >>>>>> >>>>>> Agreed. And the XMOS folk have learned and improved. With >>>>>> the first chips, they proudly showed off that you could >>>>>> make a 100 MBit Ethernet controller in software on an XMOS >>>>>> chip. Then it was pointed out to them that - impressive >>>>>> achievement though it was - it was basically useless >>>>>> because you didn't have the resources left to use it for >>>>>> much, and hardware Ethernet controllers were much cheaper. >>>>>> So they brought out new XMOS chips with hardware Ethernet >>>>>> controllers. The same thing happened with USB. >>>>> >>>>> It looks like a USB controller needs ~8 cores, which isn't a >>>>> problem on a 16 core device :) >>>>> >>>> >>>> I've had another look, and I was mistaken - these devices only >>>> have the USB and Ethernet PHYs, not the MACs, and thus require >>>> a lot of processor power, pins, memory and other resources. It >>>> doesn't need 8 cores, but the whole thing just seems so >>>> inefficient. No one is going to spend the extra cost for an >>>> XMOS with a USB PHY, so why not put a hardware USB controller >>>> on the chip? The silicon costs would surely be minor, and it >>>> would save a lot of development effort and release resources >>>> that are useful for other tasks. The same goes for Ethernet. >>>> Just because you /can/ make these things in software on the >>>> XMOS devices, does not make it a good idea. >>>> >>>> Overall, the thing that bugs me about XMOS is that you can >>>> write very simple, elegant tasks for the cores to do various >>>> tasks. But when you do that, you run out of cores almost >>>> immediately. So you have to write your code in a way that >>>> implements your own scheduler, losing a major part of the point >>>> of the whole system. Or you use the XMOS FreeRTOS port on one >>>> of the virtual cores - in which case you could just switch to a >>>> Cortex-M microcontroller with hardware USB, Ethernet, PWM, >>>> UART, etc. and a fraction of the price. >>> >>> Too bad the XMOS doesn't have more CPUs, like maybe 144 of them? >>> >> >> 144 cpus is far more than would be useful in practice - as long as >> you have cores that can do useful work in a flexible way (like XMOS >> cores). When you have very limited cores that can barely do >> anything themselves, you need lots of them. > > The point of the XMOS concept is to not have to do multitasking on a > single core. As soon as your task number exceeds the number of cores > you have to do multitasking on a single core. No one ever complains > about having too many resources. Agreed. That is why I have been pleased to hear Tom's description of how you can deal with multitasking within a core on XMOS, for when you have more tasks than cores. > > The design process for many small CPUs is not the same as a few > larger CPUs. Agreed. > But the point is it can be simpler, more like designing > hardware. Disagreed. Well, sort-of disagreed. /Some/ things can be easier on small and simple cpus - other things are harder. But when a cpu is small enough and limited enough, almost everything gets harder. And no, hardware design is /not/ simpler. It is /different/. > > Atmel had an FPGA with a simple logic element equivalent to a 3 input > LUT and FF (done with a small number of gates rather than the larger > LUT structure). It had relatively little routing, connecting logic > elements to adjacent logic elements almost as the only routing. The > theory was the simplicity of the logic elements meant you could have > a lot more of them for a given amount of real estate/$$$ so you could > afford to use them for routing. In practice they never kept up with > state of the art process technology, so this didn't pan out. But > that is the concept of the many small cores. You don't have to focus > on being highly efficient with your CPU resources since you have so > many. You equate "having more of resource X than you need" with "it's easy". That simply isn't the case. It doesn't matter how many cpus you have if they can't do what you need - or if it takes a ridiculous effort to make them do what you need. Ten thousand mice weigh less than a horse - they will eat less, provide redundancy, and have a much higher combined strength. Which do you think is better for pulling a cart? > > >> (Arguably that's what you have on an FPGA - lots of tiny bits that >> do very little on their own. But the key difference is the tools - >> FPGA's would be a lot less popular if you had to code each LU >> individually, do placement manually by numbering them, and write a >> routing file by hand.) > > Huh? Why can't any of that be automated in the many CPU chip? That's a very good question. And if it /were/ automated for the GA144, maybe it would be a much more useful chip. > Certainly the issue is not so important with only 144 processors, but > the same size chip would have many thousands of processors in a more > modern technology. I think the GA144 is 180 nm. Bring that down to > 15 nm and you have 15,000 nodes on a chip just 5 mm square!!! That > will require better tools for sure. Tools are critical. I think the biggest failing of the GA144 is the tools. With a completely different philosophy of toolset, maybe the device would become a realistic and exciting new architecture. > > Some of your use of language is interesting. "lots of tiny bits that > do very little on their own". That sounds like the way people write > software. They decompose a large, complex design into lots of tiny > routines that individually do little on their own. How can you > manage all that complexity??? Yes, I think the Zeno paradox must > apply so that no large program can ever be finished. That certainly > happens sometimes. In normal (serial, or multi-threaded) software, the programming language you use lets you combine the bits. It checks at least some aspects of how they fit together, it lets you use the different bits from where you want, it lets you split them up or combine them, write big bits and small bits. The same applies to FPGA design with Verilog, VHDL, or higher level languages. The GA144 - judging from the application notes and examples - requires you to figure out the tiniest details and split things up manually. It is a level of micromanagement beyond what is needed for assembly programming. It's the tools. >> >> Yes - you have a Cortex-A cpu that can handle high throughtput, >> perhaps with several cores, combined with a Cortex-M device that is >> more deterministic and can give more real-time control. > > That's also the idea to CPUs in FPGAs. > Yes.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-20 18:12 -0700 |
| Message-ID | <24f37d8c-61a3-4419-9782-74d06f95036c@googlegroups.com> |
| In reply to | #29538 |
On Monday, April 20, 2020 at 10:32:31 AM UTC-4, David Brown wrote: > On 18/04/2020 23:21, Rick C wrote: > > On Saturday, April 18, 2020 at 10:57:55 AM UTC-4, David Brown wrote: > >> On 17/04/2020 19:48, Rick C wrote: > >>> On Friday, April 17, 2020 at 12:15:37 PM UTC-4, David Brown > >>> wrote: > >>>> On 17/04/2020 16:23, Tom Gardner wrote: > >>>>> On 17/04/20 14:44, David Brown wrote: > >>>>>> On 17/04/2020 11:49, Tom Gardner wrote: > >>>>>>> On 17/04/20 09:02, David Brown wrote: > >>>> > >>>>>>> As you say, the XMOS /ecosystem/ is far more compelling, > >>>>>>> partly because it has excellent /integration/ between > >>>>>>> the hardware, the software and the toolchain. The latter > >>>>>>> two are usually missing. > >>>>>> > >>>>>> Agreed. And the XMOS folk have learned and improved. With > >>>>>> the first chips, they proudly showed off that you could > >>>>>> make a 100 MBit Ethernet controller in software on an XMOS > >>>>>> chip. Then it was pointed out to them that - impressive > >>>>>> achievement though it was - it was basically useless > >>>>>> because you didn't have the resources left to use it for > >>>>>> much, and hardware Ethernet controllers were much cheaper. > >>>>>> So they brought out new XMOS chips with hardware Ethernet > >>>>>> controllers. The same thing happened with USB. > >>>>> > >>>>> It looks like a USB controller needs ~8 cores, which isn't a > >>>>> problem on a 16 core device :) > >>>>> > >>>> > >>>> I've had another look, and I was mistaken - these devices only > >>>> have the USB and Ethernet PHYs, not the MACs, and thus require > >>>> a lot of processor power, pins, memory and other resources. It > >>>> doesn't need 8 cores, but the whole thing just seems so > >>>> inefficient. No one is going to spend the extra cost for an > >>>> XMOS with a USB PHY, so why not put a hardware USB controller > >>>> on the chip? The silicon costs would surely be minor, and it > >>>> would save a lot of development effort and release resources > >>>> that are useful for other tasks. The same goes for Ethernet. > >>>> Just because you /can/ make these things in software on the > >>>> XMOS devices, does not make it a good idea. > >>>> > >>>> Overall, the thing that bugs me about XMOS is that you can > >>>> write very simple, elegant tasks for the cores to do various > >>>> tasks. But when you do that, you run out of cores almost > >>>> immediately. So you have to write your code in a way that > >>>> implements your own scheduler, losing a major part of the point > >>>> of the whole system. Or you use the XMOS FreeRTOS port on one > >>>> of the virtual cores - in which case you could just switch to a > >>>> Cortex-M microcontroller with hardware USB, Ethernet, PWM, > >>>> UART, etc. and a fraction of the price. > >>> > >>> Too bad the XMOS doesn't have more CPUs, like maybe 144 of them? > >>> > >> > >> 144 cpus is far more than would be useful in practice - as long as > >> you have cores that can do useful work in a flexible way (like XMOS > >> cores). When you have very limited cores that can barely do > >> anything themselves, you need lots of them. > > > > The point of the XMOS concept is to not have to do multitasking on a > > single core. As soon as your task number exceeds the number of cores > > you have to do multitasking on a single core. No one ever complains > > about having too many resources. > > Agreed. That is why I have been pleased to hear Tom's description of > how you can deal with multitasking within a core on XMOS, for when you > have more tasks than cores. > > > > > The design process for many small CPUs is not the same as a few > > larger CPUs. > > Agreed. > > > But the point is it can be simpler, more like designing > > hardware. > > Disagreed. Well, sort-of disagreed. > > /Some/ things can be easier on small and simple cpus - other things are > harder. But when a cpu is small enough and limited enough, almost > everything gets harder. > > And no, hardware design is /not/ simpler. It is /different/. I very much disagree there... for most design work. When you are designing something very complex it can be hard to do in hardware or software. Those are the minority of designs, at least in my experience. I designed a test fixture in an FPGA that included a text based comms to control all the testing capabilities. 3,000 LUT device and still not full. Could have been done in an MCU, but it would have been hard to meet all the speed requirements of synthesizing data, driving data out, receiving data, verifying data. No, I was happy to use an FPGA for that. Simulation was much easier with the FPGA too. I am probably a bit behind on knowing the tools available, but how would you verify timing of the code to make all this work in any CPU in any language? I stand by my statement of hardware design being easier... with the qualification of not trying to do things that are inherently hard to do in hardware, like a TCP/IP stack. > > Atmel had an FPGA with a simple logic element equivalent to a 3 input > > LUT and FF (done with a small number of gates rather than the larger > > LUT structure). It had relatively little routing, connecting logic > > elements to adjacent logic elements almost as the only routing. The > > theory was the simplicity of the logic elements meant you could have > > a lot more of them for a given amount of real estate/$$$ so you could > > afford to use them for routing. In practice they never kept up with > > state of the art process technology, so this didn't pan out. But > > that is the concept of the many small cores. You don't have to focus > > on being highly efficient with your CPU resources since you have so > > many. > > You equate "having more of resource X than you need" with "it's easy". > That simply isn't the case. That's not what I said. I was addressing the comms issue in the GA144. The Atmel device was similar, mostly comms to neighbors and using not so valuable resources for comms. i.e. different mindset. > It doesn't matter how many cpus you have if they can't do what you need > - or if it takes a ridiculous effort to make them do what you need. The example designs by the GA group have been to illustrate that this is not a barrier. People find the device hard to use because it requires a different manner of decomposing a design. No, you can't implement a complex function in a single F18A CPU. But you can't implement a complex function in a single code routine either. At least everyone tells you not to in order to make it maintainable. If code can be modularized, it can be broken into separately executed units for the GA144. Not rocket science, just different from what you are used to. > Ten thousand mice weigh less than a horse - they will eat less, provide > redundancy, and have a much higher combined strength. Which do you > think is better for pulling a cart? I use a truck. Every application has an appropriate tool. > >> (Arguably that's what you have on an FPGA - lots of tiny bits that > >> do very little on their own. But the key difference is the tools - > >> FPGA's would be a lot less popular if you had to code each LU > >> individually, do placement manually by numbering them, and write a > >> routing file by hand.) > > > > Huh? Why can't any of that be automated in the many CPU chip? > > That's a very good question. And if it /were/ automated for the GA144, > maybe it would be a much more useful chip. You mean it would be a more useful development tool. The GA144 would be no different. The problems with the GA144 don't come from a lack of automatic partitioning in the tools. Many of them come from the limits of designers to think. The guys in SED who design analog circuits do amazing things with the devices they use. They would be right at home with partitioning a design across multiple small processors. That's the big advantage of a single, big, fast CPU, it makes the problem about having enough speed and then managing all the complexities of multitasking on a single processor, a problem that has been solved in the general case. It's just the implementation details that can be difficult. > > Certainly the issue is not so important with only 144 processors, but > > the same size chip would have many thousands of processors in a more > > modern technology. I think the GA144 is 180 nm. Bring that down to > > 15 nm and you have 15,000 nodes on a chip just 5 mm square!!! That > > will require better tools for sure. > > Tools are critical. With 15,000 CPUs, absolutely. > I think the biggest failing of the GA144 is the tools. With a > completely different philosophy of toolset, maybe the device would > become a realistic and exciting new architecture. I don't agree because the present state of the GA144 is such that there is no real problem with coding in the Forth provided and the partitioning problems are not so great with just 144 CPUs. The problem is the blank slate issue really. A new designer sits down to think of how to do a design in the chip and he has to figure it all out from ground zero. The first few designs require multiple iterations I'm sure. There aren't going to be automated tools for this chip. We'll see if they have something new out the door before the doors close... not that it takes much to keep them open. > > Some of your use of language is interesting. "lots of tiny bits that > > do very little on their own". That sounds like the way people write > > software. They decompose a large, complex design into lots of tiny > > routines that individually do little on their own. How can you > > manage all that complexity??? Yes, I think the Zeno paradox must > > apply so that no large program can ever be finished. That certainly > > happens sometimes. > > In normal (serial, or multi-threaded) software, the programming language > you use lets you combine the bits. It checks at least some aspects of > how they fit together, it lets you use the different bits from where you > want, it lets you split them up or combine them, write big bits and > small bits. The same applies to FPGA design with Verilog, VHDL, or > higher level languages. I never have trouble with partitioning designs. It's the testing that is awkward. In Forth I can test any function I want as soon as it is written. In HDL I have to write a test bench for every module. Tons of extra work. > The GA144 - judging from the application notes and examples - requires > you to figure out the tiniest details and split things up manually. It > is a level of micromanagement beyond what is needed for assembly > programming. Yes, but I'm not sure what you mean by "tiniest details". Most programs just aren't that hard to write. It's assembly code and a very simple one at that. What were you thinking about when you looked at it? > It's the tools. If you want it to be the tools for you, then it's the tools. For the people who designed the chip, they never felt the need for the tools to do the things you are describing. I don't know much about parallel programming languages (other than HDL) but for the most part don't they require you to decide how to partition the design and set up tasks, etc.? While FPGA tools will do much of the work for you, they make a lot of really crappy decisions when it comes to placement. They are only useful because there is a plethora of routing resources and most people don't care about optimization... until they do. Then FPGAs can be a bit of a PITA. But those designs are far beyond anything a CPU is capable of. -- 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-21 10:09 +0100 |
| Message-ID | <9LynG.99223$dx4.51990@fx05.am4> |
| In reply to | #29556 |
On 21/04/20 02:12, Rick C wrote: > On Monday, April 20, 2020 at 10:32:31 AM UTC-4, David Brown wrote: >> It's the tools. > > If you want it to be the tools for you, then it's the tools. > > For the people who designed the chip, they never felt the need for the tools > to do the things you are describing. I don't know much about parallel > programming languages (other than HDL) but for the most part don't they > require you to decide how to partition the design and set up tasks, etc.? An unprogrammed processor (or FPGA) is merely sand. That's why the tools are /vital/. Most hardware designers grossly underestimate the difficulty of producing application software and tools. The traditional refrain is "it is only software". That's why the XMOS hardware/software combination is so important and different. But you have decided not to be interested in finding that out; your loss. > While FPGA tools will do much of the work for you, they make a lot of really > crappy decisions when it comes to placement. They are only useful because > there is a plethora of routing resources and most people don't care about > optimization... until they do. Then FPGAs can be a bit of a PITA. I normally end up pushing the technology I use. All technologies have pinch points. > But those designs are far beyond anything a CPU is capable of. Only in some respects. In others CPUs far outstrip hardware. The last time I heard of a hardware "database" was in the early 80s, with ICL's DAP machine. It sunk without a trace.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 16:31 +0100 |
| Message-ID | <ZejnG.59687$oS7.47567@fx39.am4> |
| In reply to | #29506 |
On 18/04/20 22:21, Rick C wrote: > On Saturday, April 18, 2020 at 10:57:55 AM UTC-4, David Brown wrote: >> (Arguably that's what you have on an FPGA - lots of tiny bits that do >> very little on their own. But the key difference is the tools - FPGA's >> would be a lot less popular if you had to code each LU individually, do >> placement manually by numbering them, and write a routing file by hand.) > > Huh? Why can't any of that be automated in the many CPU chip? Certainly the issue is not so important with only 144 processors, but the same size chip would have many thousands of processors in a more modern technology. I think the GA144 is 180 nm. Bring that down to 15 nm and you have 15,000 nodes on a chip just 5 mm square!!! That will require better tools for sure. > > Some of your use of language is interesting. "lots of tiny bits that do very little on their own". That sounds like the way people write software. They decompose a large, complex design into lots of tiny routines that individually do little on their own. How can you manage all that complexity??? Yes, I think the Zeno paradox must apply so that no large program can ever be finished. That certainly happens sometimes.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 16:42 +0100 |
| Message-ID | <upjnG.121097$e1n.2819@fx36.am4> |
| In reply to | #29506 |
On 18/04/20 22:21, Rick C wrote: > On Saturday, April 18, 2020 at 10:57:55 AM UTC-4, David Brown wrote: >> (Arguably that's what you have on an FPGA - lots of tiny bits that do >> very little on their own. But the key difference is the tools - FPGA's >> would be a lot less popular if you had to code each LU individually, do >> placement manually by numbering them, and write a routing file by hand.) > > Huh? Why can't any of that be automated in the many CPU chip? Good question; if it is easy, why /hasn't/ it been automated? The software tools are key; they have to exist and be usable. If you get that wrong you end up with the Itanium (a.k.a. Itanic) disaster where the hardware's performance was predicated on the compilers being sufficiently good - but they never were and people with decades of experience said they never would be. Or, in the FPGA world, why aren't Pilkington's "sea of gates" FPGAs around now - because the tools weren't available. The tools have to be usable; with software (inc XMOS) developers are used to instant compile-download-debug cycles. FPGA tools can be much slower (arguably an advantage, but that's a separate discussion!). > Some of your use of language is interesting. "lots of tiny bits > that do very little on their own". That sounds like the way people > write software. They decompose a large, complex design into lots > of tiny routines that individually do little on their own. How > can you manage all that complexity??? Yes, I think the Zeno > paradox must apply so that no large program can ever be finished. > That certainly happens sometimes. Take that to the limit and you end up with dataflow machines. They have been around since the early 80s, and there are good reasons why they have never become popular. The programming style for the GA144 may well have to end up being close to a dataflow machine. But I've forgotten the relevant details of the GA144.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2020-04-18 00:43 +0300 |
| Message-ID | <eq7k9fp7r0u2uchvkga4bj2ccepj6ub850@4ax.com> |
| In reply to | #29482 |
On Fri, 17 Apr 2020 15:44:15 +0200, David Brown
<david.brown@hesbynett.no> wrote:
>
>>
>> As you say, the XMOS /ecosystem/ is far more compelling,
>> partly because it has excellent /integration/ between the
>> hardware, the software and the toolchain. The latter two
>> are usually missing.
The XCALE architecture is nice, if you are comfortable implementing
whole applications mainly with interrupts. Just assign one core for
each ISR. When an external HW signal ("interrupt") occurs, restart the
program in that core. The program needs to be executed before the next
"interrupt" occurs. Thus implementing e.g. audio or video sampled
system is nice. The core task just needs to be fast enough to handle
one sample.
>Agreed. And the XMOS folk have learned and improved. With the first
>chips, they proudly showed off that you could make a 100 MBit Ethernet
>controller in software on an XMOS chip. Then it was pointed out to them
>that - impressive achievement though it was - it was basically useless
>because you didn't have the resources left to use it for much, and
>hardware Ethernet controllers were much cheaper. So they brought out
>new XMOS chips with hardware Ethernet controllers. The same thing
>happened with USB.
On the Ethernet, the minimum MAC frame is 64 bytes, thus new short
frames may appear every 6,4 us, thus the "ISR" must execute in less
than 6.4 us. If not possible, let one task just split the frame into
header and actual payload and use separate cores e.g. to handle the
MAC and IP headers, Still 8 cores sounds a quite large number,
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-18 17:07 +0200 |
| Message-ID | <r7f52s$529$1@dont-email.me> |
| In reply to | #29493 |
On 17/04/2020 23:43, upsidedown@downunder.com wrote:
> On Fri, 17 Apr 2020 15:44:15 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
>
>>
>>>
>>> As you say, the XMOS /ecosystem/ is far more compelling,
>>> partly because it has excellent /integration/ between the
>>> hardware, the software and the toolchain. The latter two
>>> are usually missing.
>
> The XCALE architecture is nice, if you are comfortable implementing
> whole applications mainly with interrupts. Just assign one core for
> each ISR. When an external HW signal ("interrupt") occurs, restart the
> program in that core. The program needs to be executed before the next
> "interrupt" occurs. Thus implementing e.g. audio or video sampled
> system is nice. The core task just needs to be fast enough to handle
> one sample.
I have made some microcontroller programs where the main loop is nothing
more than a "sleep until interrupt" opcode. I'm fine with such designs.
>
>> Agreed. And the XMOS folk have learned and improved. With the first
>> chips, they proudly showed off that you could make a 100 MBit Ethernet
>> controller in software on an XMOS chip. Then it was pointed out to them
>> that - impressive achievement though it was - it was basically useless
>> because you didn't have the resources left to use it for much, and
>> hardware Ethernet controllers were much cheaper. So they brought out
>> new XMOS chips with hardware Ethernet controllers. The same thing
>> happened with USB.
>
> On the Ethernet, the minimum MAC frame is 64 bytes, thus new short
> frames may appear every 6,4 us, thus the "ISR" must execute in less
> than 6.4 us. If not possible, let one task just split the frame into
> header and actual payload and use separate cores e.g. to handle the
> MAC and IP headers, Still 8 cores sounds a quite large number,
>
8 cores is more than the XMOS documentation says, as far as I can see.
I think it was 3 or 4, but it can depend on the features you want. And
I'm sure that at least some of these could be combined with other tasks
if you don't mind the loss of modularity.
Your timings are a little off - you need to include the preamble, start
of frame and interpacket gap, so the minimum packet time is 8.4 µs.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-17 09:11 -0700 |
| Message-ID | <bdee508d-74fd-44e4-a821-12834f31564f@googlegroups.com> |
| In reply to | #29479 |
On Friday, April 17, 2020 at 4:03:06 AM UTC-4, David Brown wrote: > On 17/04/2020 03:37, Rick C wrote: > > On Thursday, April 16, 2020 at 8:13:45 PM UTC-4, Paul Rubin wrote: > >> Grant Edwards <invalid@invalid.invalid> writes: > >>> Definitely. The M-class parts are so cheap, there's not much > >>> point in thinking about doing it in an FPGA. > >> > >> Well I think the idea is already you have other stuff in the FPGA, > >> so you save a package and some communications by dropping in a > >> softcore rather than using an external MCU. I'm surprised that > >> only high end FPGA's currently have hard MCU's already there. Just > >> like they have DSP blocks, ram blocks, SERDES, etc., they might as > >> well put in some CPU blocks. > > > > There's a chip that goes the other direction. The GA144 has 144 very > > fast, very tiny CPUs in an FPGA fashion with no FPGA fabric. > > > > It's not a popular chip because most people are invested in the > > single CPU, lots of memory paradigm and focusing their efforts on > > making a single CPU work like it's many CPUs doing many different > > things. Using this chip requires a very different mindset because of > > the memory size limitations which are inherent in the CPU design. > > Could it be that the chip is not popular because it is not a good fit > for many applications? A signal fast core is more flexible and useful > than many small cores, while an FPGA can do far more than the tiny CPUs > in the GA144. You are the poster child for my statement about mindset. A single, fast CPU is harder to program than many, fast CPUs. Programmers have to learn a lot in order to perform multitasking on a single CPU. It's a difficult and error prone design exercise. Transition that to many CPUs and the vast majority of those problems go away. I recall one designers complaining there was not nearly enough I/O capability to keep all the CPUs supplied with data, completely missing the idea that the CPUs are no longer a precious resource that you must squeeze every last drop of performance from. > You need outstanding benefits of something like the GA144 > before it makes sense to use it - and that's not something I have seen > when I have looked through the website and read the information. It is > not enough to simply be an interesting idea - it is not even enough to > be useful or better than alternatives. In order to capture customers, > it has to be so hugely better that it is worth the cost for people to > learn a very different type of architecture, a very different > programming language, and a very different way of looking at problems. Yes, you are agreeing with me I think. Designers are comfortable with the present paradigm and have trouble even conceiving of how to use this device. That's not the same thing as the device not being suitable for applications... although it is definitely not a shoe that fits every foot. However, there are many, many uses for it. One area where it fits very well is a signal processing app where data flows through the chip. This would be a nearly perfect match to the architecture allowing even a designer with little imagination to use the device. I considered some apps for this device. One was an attached oscilloscope. I believe a design would suit this device pretty well. My preference would be to ship the data over USB to a PC for display which would require a USB interface which no one has yet developed, but connecting to an attached display would be simple. An external memory would only be needed if advanced processing functions were required. Most could be done right on the chip. > And frankly, the GA144 is not impressive or better at all. Look at the > application notes and examples - you've got a 10 Mbit Ethernet > controller that requires a third of the hardware of the GA144. An MD5 > hash takes over a tenth of the hardware and has a speed similar to a > cheaper microcontroller from the year the GA144 was made, 2012. And it > all requires programming in a language where the /colour/ of the words > is semantically and syntactically critical. Yes, very clearly showing your bias and lack of imagination. I remember the first time I used an IDE for code development. The damn thing barely worked and was horribly slow. I was happy with manually tracing code on printouts. lol > It is nice to see people coming up with new ideas and new kinds of > architectures, but there has to be big benefits if it is going to be > anything more than an academic curiosity. GA144 is not it. > > (The XMOS is far more realistic and with greater potential - that's a > family of devices that people can, and do, use.) Ah, yes, the ever so niched XMOS. An expensive replacement for the many faster and simpler devices that everyone is comfortable with. These devices have the same issues of user comfort the GA144 has and on top of that are only suited to a small niche where they have any real advantage over CPUs or FPGAs. I believe we've had this discussion before. > > That said, FPGA makers are rather stuck in the -larger is better- rut > > mostly because their bread and butter customer base, the comms > > vendors, want large FPGAs with fast ARM processors if any. > > It is those customers that pay for the development of the whole thing. > Small customers then get the benefits of that. Not if FPGAs that suit them are never developed. That's the problem. The two large FPGA makers aren't interested in the (I assume) smaller markets which require smaller devices in smaller, easy to use packages, potentially combined with CPUs such as ARM CM4 or RISC-V. I have seen devices from Microchip with a RISC-V but they are typically far too pricey to end up in any of my designs. This device will be out later this year. -- Rick C. --+ Get 1,000 miles of free Supercharging --+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-17 12:17 -0700 |
| Message-ID | <871rolzzts.fsf@nightsong.com> |
| In reply to | #29485 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > A single, fast CPU is harder to program than many, fast CPUs. > Programmers have to learn a lot in order to perform multitasking on a > single CPU. Really it's the other way around. A typical programmer these days might not know how to implement a multitasker or OS on a bare machine, but they do know how to spawn processes and use them on a machine with an OS. Organizing a parallel or distributed program is much harder.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-17 13:22 -0700 |
| Message-ID | <387c667c-ae86-413e-b973-65a3fb3db7fc@googlegroups.com> |
| In reply to | #29491 |
On Friday, April 17, 2020 at 3:17:55 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.deletethisbit@gmail.com> writes: > > A single, fast CPU is harder to program than many, fast CPUs. > > Programmers have to learn a lot in order to perform multitasking on a > > single CPU. > > Really it's the other way around. A typical programmer these days might > not know how to implement a multitasker or OS on a bare machine, but > they do know how to spawn processes and use them on a machine with an > OS. Organizing a parallel or distributed program is much harder. Really? Multitasking is a lot more complex than just spawning tasks. There are potential conditions that can lock up the computer or the tasks. Managing task priorities can be a very complex issue and learning how to do that correctly is an important part of multitasking. In real time systems it becomes potentially the hardest part of a project. Breaking a design down to assign tasks on various processors is a much simpler matter. It's much like hardware design where you dedicate hardware to perform various actions and simply don't have the many problems of sharing a single CPU among many tasks. Do I have it wrong? Is multitasking actually simple and the various articles I've read about the complexities overstate the matter? -- Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-17 14:48 -0700 |
| Message-ID | <87zhb9dbr4.fsf@nightsong.com> |
| In reply to | #29492 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > Do I have it wrong? Is multitasking actually simple and the various > articles I've read about the complexities overstate the matter? Multitasking isn't exactly simple, but we (programmers) are used to it by now. The stuff you read about lock hazards is mostly from multi-threading in a single process. If you have processes communicating through channels, there are still ways to mess up, but it's usually simpler than dealing with threads and locks.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-17 15:27 -0700 |
| Message-ID | <d16d2810-2382-4bbc-bd9d-0386f19bbeba@googlegroups.com> |
| In reply to | #29494 |
On Friday, April 17, 2020 at 5:48:50 PM UTC-4, Paul Rubin wrote: > Rick C <gnuarm.deletethisbit@gmail.com> writes: > > Do I have it wrong? Is multitasking actually simple and the various > > articles I've read about the complexities overstate the matter? > > Multitasking isn't exactly simple, but we (programmers) are used to it > by now. The stuff you read about lock hazards is mostly from > multi-threading in a single process. If you have processes > communicating through channels, there are still ways to mess up, but > it's usually simpler than dealing with threads and locks. Exactly, the mindset it to use multitasking... but it can still be complex. That's my point... what you are used to is what you use even when it's not the best approach. Splitting a design to run on independent processors is just as easy if not more so because of the lack of sharing issues. The stuff you are thinking of with distributed processing is when your application doesn't suit multitasking and it needs to be distributed over a lot of processors to speed it up. That's not the same issue at all of simply getting the job done. That's the sort of stuff they have problems with on super computers. I think we've been down this road before. -- 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 16:53 +0200 |
| Message-ID | <r7kd1p$kum$1@dont-email.me> |
| In reply to | #29492 |
On 17/04/2020 22:22, Rick C wrote: > On Friday, April 17, 2020 at 3:17:55 PM UTC-4, Paul Rubin wrote: >> Rick C <gnuarm.deletethisbit@gmail.com> writes: >>> A single, fast CPU is harder to program than many, fast CPUs. >>> Programmers have to learn a lot in order to perform multitasking >>> on a single CPU. >> >> Really it's the other way around. A typical programmer these days >> might not know how to implement a multitasker or OS on a bare >> machine, but they do know how to spawn processes and use them on a >> machine with an OS. Organizing a parallel or distributed program >> is much harder. > > Really? Multitasking is a lot more complex than just spawning tasks. > There are potential conditions that can lock up the computer or the > tasks. Managing task priorities can be a very complex issue and > learning how to do that correctly is an important part of > multitasking. In real time systems it becomes potentially the > hardest part of a project. > > Breaking a design down to assign tasks on various processors is a > much simpler matter. It's much like hardware design where you > dedicate hardware to perform various actions and simply don't have > the many problems of sharing a single CPU among many tasks. > > Do I have it wrong? Is multitasking actually simple and the various > articles I've read about the complexities overstate the matter? > Nah, it's mostly the same whether you have one processor or many. /If/ you follow one basic rule, that is. One thing that people often get wrong is they try to control something or set a variable from different places in the code. They get this wrong with single-tasking software, and lose their overview of the control flow and data flow (often without knowing that it is lost). It becomes impractical or impossible to see that the code is actually correct, and you usually can't find your problems in testing. A common "solution" to this is to ban global variables. This is a mere band-aid, and usually unhelpful - the problem exists whether you set variable "foo" directly or call "set_foo()". And when you have multiple threads or tasks, the problem is bigger - it is not just different bits of the program that can get mixed up, they can be in different contexts too, and can be interrupt in the middle. The answer is to think like a hardware designer - think separate modules that communicate by signals. If you have different hardware modules that all access a shared resource, you need a multiplexer or prioritising system, possibly with locks or gates. The same applies in software. A single hardware output can drive many inputs, but an input can only be driven by one output - again you need a multiplexer, combination gate, or other selection system do to otherwise. The same applies in software. Bidirectional or tristate signals can be useful to cut down on resources, but are much harder to get right. The same in software. If you have individually compiled programs for different cpus, it is harder to get this wrong - you have no choice but to have a clear interface between the parts. And if you use XC on XMOS, you have an advantage too - the tools won't let you set the same data from different virtual cores. (This used to be an irritating limit for cases when the programmer knows better than the tools about what is safe, but I believe this has improved.) And of course FPGA tools won't let you drive a signal from multiple sources. Beyond that, you have mostly the same issues. Deadlock, livelock, synchronisation - they are all something you have to consider whether you are making an FPGA design, multi-tasking on one cpu, or running independent tasks on independent processors. Task prioritising is an important issue. But it is not just for multitasking on a single cpu. If you have a high priority task A that sometimes has to wait for the results from a low priority task B, you have an issue to deal with. That applies whether they are on the same cpu or different ones. On a single cpu, you have the solution of bumping up the priority for task B for a bit (priority inheritance) - on different cpus, you just have to wait.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 17:03 +0100 |
| Message-ID | <wJjnG.83028$fq1.41301@fx37.am4> |
| In reply to | #29539 |
On 20/04/20 15:53, David Brown wrote: > Beyond that, you have mostly the same issues. Deadlock, livelock, > synchronisation - they are all something you have to consider whether you are > making an FPGA design, multi-tasking on one cpu, or running independent tasks on > independent processors. > > Task prioritising is an important issue. But it is not just for multitasking on > a single cpu. If you have a high priority task A that sometimes has to wait for > the results from a low priority task B, you have an issue to deal with. That > applies whether they are on the same cpu or different ones. On a single cpu, > you have the solution of bumping up the priority for task B for a bit (priority > inheritance) - on different cpus, you just have to wait. Multiple task priorities is too often used as a sticking plaster to cure livelock/deadlock problems - or more accurately /appear/ to cure them. I much prefer to have two priorities: normal and interrupt, and then to have a supervisor of some sort which specifies which task runs at any given time. Any such supervisor is probably application specific, coded explicitly, and can be inspected/debugged/modified like any ordinary task. One I've used in the past is to have a "demultiplexer" which directs job fragments into different FIFOs, for processing by worker threads. That was naturally scalable and can be made "highly available", which is mandatory in telecom applications.
[toc] | [prev] | [next] | [standalone]
Page 4 of 8 — ← Prev page 1 2 3 [4] 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web