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 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-15 20:51 -0700 |
| Subject | Custom CPU Designs |
| Message-ID | <abb9b585-5a14-45d0-b617-543a009a176c@googlegroups.com> |
In the Forth language group there are occasional discussions of custom processors. This is mostly because a simple stack processor can be designed to be implemented in an FPGA very easily, taking little resources and running at a good speed. Such a stack processor is a good target for Forth. I know there are many other types of CPU designs which are implemented in FPGAs. I'm wondering how often these are used by the typical embedded developer? -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
[toc] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-16 11:59 +0100 |
| Message-ID | <xrB*I6GPx@news.chiark.greenend.org.uk> |
| In reply to | #29458 |
Rick C <gnuarm.deletethisbit@gmail.com> wrote: > In the Forth language group there are occasional discussions of custom > processors. This is mostly because a simple stack processor can be > designed to be implemented in an FPGA very easily, taking little resources > and running at a good speed. Such a stack processor is a good target for > Forth. > > I know there are many other types of CPU designs which are implemented in > FPGAs. I'm wondering how often these are used by the typical embedded > developer? It's not uncommon when you have an FPGA doing some task to need a processor in there to manage it - for example to handle error conditions or to report status over some software-friendly interface like I2C, or classical printf debugging on a UART. Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit legacy (toolchains aren't that great, etc), although designed to be fairly small. There's increasing interest in small 32-bit RISC-V cores for this niche, since the toolchain is improving and the licensing conditions more liberal (RISC-V itself doesn't design cores, but lots of others - including ourselves - have made open source cores to the RISC-V specification). I don't see that Forth has much to speak to this niche, given these cores are largely offloading work that's fiddly to do in hardware and people just want to write some (usually) C to mop up the loose ends. I can't see what Forth would gain them for this. If you're talking using these processors as a compute overlay for FPGAs, a different thing entirely, I'd suggest that a stack processor is likely not very efficient in terms of throughput. Although I don't have a cite to back that up. Theo
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-16 13:28 +0200 |
| Message-ID | <r79fgp$9tj$1@dont-email.me> |
| In reply to | #29459 |
On 16/04/2020 12:59, Theo wrote: > Rick C <gnuarm.deletethisbit@gmail.com> wrote: >> In the Forth language group there are occasional discussions of custom >> processors. This is mostly because a simple stack processor can be >> designed to be implemented in an FPGA very easily, taking little resources >> and running at a good speed. Such a stack processor is a good target for >> Forth. >> >> I know there are many other types of CPU designs which are implemented in >> FPGAs. I'm wondering how often these are used by the typical embedded >> developer? > > It's not uncommon when you have an FPGA doing some task to need a processor > in there to manage it - for example to handle error conditions or to report > status over some software-friendly interface like I2C, or classical printf > debugging on a UART. > > Xilinx provides Microblaze and Intel/Altera provide NIOS, which are a bit > legacy (toolchains aren't that great, etc), although designed to be fairly > small. There's increasing interest in small 32-bit RISC-V cores for this > niche, since the toolchain is improving and the licensing conditions more > liberal (RISC-V itself doesn't design cores, but lots of others - including > ourselves - have made open source cores to the RISC-V specification). > > I don't see that Forth has much to speak to this niche, given these cores > are largely offloading work that's fiddly to do in hardware and people just > want to write some (usually) C to mop up the loose ends. I can't see what > Forth would gain them for this. > > If you're talking using these processors as a compute overlay for FPGAs, a > different thing entirely, I'd suggest that a stack processor is likely not > very efficient in terms of throughput. Although I don't have a cite to back > that up. > That matches what I have seen from customers. Very few people design their own cpus - it is rarely worth the effort. (People do it for fun, which is a different matter.) They want off-the-shelf cores and off-the-shelf tools. And they want off-the-shelf programmers to work with them. There was a time when FPGA's were smaller and more limited, where you might want an absolute minimal sized CPU core. Then a stack-based core with a small decoder would be a good choice, and Forth a good fit. Those days are long gone. Modern programmable logic is bigger and have architectural features that are a better fit for "standard" 32-bit RISC cores than older devices. And the design tools make it easy - you pick your core, your peripherals, your memories, your interfaces from the libraries and let the tools make the buses, C header files, and everything else. I can appreciate that Forth can be a very efficient language, and Forth-oriented cpus can be small and fast. But efficiency of the hardware is not the only goal of a design. I would expect that Forth and stack processors are almost exclusively used by developers who have been using them for the last twenty years already.
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-16 13:10 +0000 |
| Message-ID | <r79lfe$j7d$2@reader2.panix.com> |
| In reply to | #29459 |
On 2020-04-16, Theo <theom+news@chiark.greenend.org.uk> wrote: > It's not uncommon when you have an FPGA doing some task to need a processor > in there to manage it - for example to handle error conditions or to report > status over some software-friendly interface like I2C, or classical printf > debugging on a UART. I worked on a project using a NIOS2 CPU core in an Altera FPGA. It was a complete disaster. The CPU's throughput (running at 60MHz) was lower than the 40MHz ARM7 we were replacing. The SDRAM controller's bandwidth was so low it couldn't keep up with 100Mbps full duplex Ethernet. The SW development environment was incredibly horrible and depended on some ancient version of Eclipse (and required a license dongle) and a bunch of bloated tools written by some incompetent contractor. There were Java apps that generated shell scripts that generated TCL programs that generated C headers (or something like that). The JTAG debugging interface often locked up the entire CPU. After spending a year developing prototype products that would never quite work, we abandoned the NIOS2 in favor of an NXP Cortex M3. -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-16 22:16 +0100 |
| Message-ID | <urB*mlJPx@news.chiark.greenend.org.uk> |
| In reply to | #29461 |
Grant Edwards <invalid@invalid.invalid> wrote: > On 2020-04-16, Theo <theom+news@chiark.greenend.org.uk> wrote: > > > It's not uncommon when you have an FPGA doing some task to need a processor > > in there to manage it - for example to handle error conditions or to report > > status over some software-friendly interface like I2C, or classical printf > > debugging on a UART. > > I worked on a project using a NIOS2 CPU core in an Altera FPGA. It > was a complete disaster. The CPU's throughput (running at 60MHz) was > lower than the 40MHz ARM7 we were replacing. The SDRAM controller's > bandwidth was so low it couldn't keep up with 100Mbps full duplex > Ethernet. The SW development environment was incredibly horrible and > depended on some ancient version of Eclipse (and required a license > dongle) and a bunch of bloated tools written by some incompetent > contractor. There were Java apps that generated shell scripts that > generated TCL programs that generated C headers (or something like > that). The JTAG debugging interface often locked up the entire CPU. That's a pretty good summary of the experience. A few things have improved slightly: - if you have the space it's better to use an on-chip BRAM rather than SDRAM, given the SDRAM is often running at ~100MHz x 16 bits, which makes even instruction fetch multi-cycle. DDR is better but the memory controllers are much more complex, and life gets easier when you have cache. - they've upgraded to a plugin for a modern version of Eclipse rather than a fork from 2005, but it's still Eclipse :( I just drive the shell scripts directly (although the pile of Make they generate isn't that nice). I've never had it need a dongle. - the JTAG interface is horrible and I've spent way too much time reverse engineering it[1] and working around its foibles, in particularly the JTAG UART which is broken in several ways (google 'JTAG Atlantic' for some workarounds) > After spending a year developing prototype products that would never > quite work, we abandoned the NIOS2 in favor of an NXP Cortex M3. These days a RISC-V CPU in FPGA solves a lot of the horrible proprietaryness, although you still have to glue the toolchain together yourself (git clone riscv-gcc). But if you can do the job with a hard MCU I can't see why you'd want an FPGA. Personally I much prefer the ARM cores on FPGAs these days - they're a Proper CPU that Just Works. And the Cortex A-class cores can boot Linux which makes the software development workflow a lot nicer. Although they aren't that beefy (a $10000 Stratix 10 has a quad core A53, which is a Raspberry Pi 3), often hard to get parts with them in, and the bandwidth between ARM and soft logic often isn't very good. Theo [1] Did you know the Altera product codenames were based on dragons from How to Train Your Dragon? Interesting what you find out when running strace(1) on the binary...
[toc] | [prev] | [next] | [standalone]
| From | Grant Edwards <invalid@invalid.invalid> |
|---|---|
| Date | 2020-04-16 22:01 +0000 |
| Message-ID | <r7akkb$i37$1@reader2.panix.com> |
| In reply to | #29465 |
On 2020-04-16, Theo <theom+news@chiark.greenend.org.uk> wrote: > - if you have the space it's better to use an on-chip BRAM rather > than SDRAM, given the SDRAM is often running at ~100MHz x 16 bits, > which makes even instruction fetch multi-cycle. DDR is better but > the memory controllers are much more complex, and life gets easier > when you have cache. I don't remember if we ever got it to work reliably at 100M full-duplex. I know it was close, and it worked OK half-duplex. I do remember there was a _lot_ of messing around with interleave, burst length, etc. > - they've upgraded to a plugin for a modern version of Eclipse > rather than a fork from 2005, but it's still Eclipse :( I just > drive the shell scripts directly (although the pile of Make they > generate isn't that nice). I've never had it need a dongle. IIRC, we eventually got to the point where we only needed the dongle when the HW guys changed something and the register map changed. I ended up writing several scripts so we could use plain old Makefiles after the register maps had been generated. > - the JTAG interface is horrible and I've spent way too much time > reverse engineering it[1] and working around its foibles, in > particularly the JTAG UART which is broken in several ways (google > 'JTAG Atlantic' for some workarounds) Once I got a UART working so I count print messages, I just gave up on the JTAG BS. Another interesting quirk was that the Altera USB JTAG interface only worked right with a few specific models of powered USB hubs. >> After spending a year developing prototype products that would never >> quite work, we abandoned the NIOS2 in favor of an NXP Cortex M3. > > These days a RISC-V CPU in FPGA solves a lot of the horrible > proprietaryness, although you still have to glue the toolchain > together yourself (git clone riscv-gcc). > > But if you can do the job with a hard MCU I can't see why you'd want > an FPGA. We needed a pretty decent-sized FPGA for custom peripherals and an I/O processor. So, Altera sold somebody on the idea of moving the uC into the FPGA also. > Personally I much prefer the ARM cores on FPGAs these days - they're a > Proper CPU that Just Works. Definitely. The M-class parts are so cheap, there's not much point in thinking about doing it in an FPGA. > [1] Did you know the Altera product codenames were based on dragons from How > to Train Your Dragon? Interesting what you find out when running strace(1) > on the binary... I did not know that. :) -- Grant
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-16 17:13 -0700 |
| Message-ID | <878sivdl56.fsf@nightsong.com> |
| In reply to | #29468 |
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.
[toc] | [prev] | [next] | [standalone]
| From | jim.brakefield@ieee.org |
|---|---|
| Date | 2020-04-16 18:10 -0700 |
| Message-ID | <3d92f2b3-5b62-4632-b660-efae0114a376@googlegroups.com> |
| In reply to | #29469 |
On Thursday, April 16, 2020 at 7:13:45 PM UTC-5, 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. If you need only a little programmable logic consider the Cypress PSoC series. The Microchip SmartFusion2 is relatively low cost. Both have Cortex M3 or M4 uP.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-16 18:37 -0700 |
| Message-ID | <83042f0d-e68a-479d-bb67-d2d635ca60d4@googlegroups.com> |
| In reply to | #29469 |
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. 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. I recall a rather old Xilinx line, Virtex II Pro had Power PC CPUs I think. Either two or only one or none in the smallest device. Pre-ARM days I guess. Atmel had a line of not very well received FPGAs. They had a version which incorporated an 8 bitter, possibly a AVR, but I don't think it was that. Too long ago to remember. It had a 4-5 letter acronym for a name. SLIC or something like that. ActelxxxxxMicrosemixxxxxxxxxMicrochip has some FPGAs with an ARM CPU. A bit pricey for me and they only come in large packages or very fine pitch BGAs. -- 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-16 22:08 -0700 |
| Message-ID | <874ktiem2e.fsf@nightsong.com> |
| In reply to | #29472 |
Rick C <gnuarm.deletethisbit@gmail.com> writes: > 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. Right, but the idea is to have both.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-17 10:02 +0200 |
| Message-ID | <r7bnri$pf$1@dont-email.me> |
| In reply to | #29472 |
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 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. 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. 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.) > > 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. > > I recall a rather old Xilinx line, Virtex II Pro had Power PC CPUs I > think. Either two or only one or none in the smallest device. > Pre-ARM days I guess. > Yes, PPC cores used to be popular on FPGAs and ASICs. MIPS were also popular in ASICs, especially in the communications and network industry, but I don't remember ever hearing about them on an FPGA. I wonder why not - they would be at least as good a fit as PPC. > Atmel had a line of not very well received FPGAs. They had a version > which incorporated an 8 bitter, possibly a AVR, but I don't think it > was that. Too long ago to remember. It had a 4-5 letter acronym for > a name. SLIC or something like that. I remember those, though I never used them. Yes, you had an AVR core with an FPGA fabric. I'm guessing there was a big customer that used them - a great deal of AVR devices, especially in their earlier days, came from Atmel's big ASIC customers. They basically made parts to order, with the combination of core, memories, peripherals and packaging that a customer wanted for a mass production, and then they generalised some of the parts and made them available for public purchase. > > ActelxxxxxMicrosemixxxxxxxxxMicrochip has some FPGAs with an ARM CPU. > A bit pricey for me and they only come in large packages or very fine > pitch BGAs. >
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-17 10:49 +0100 |
| Message-ID | <mYemG.8363$V%3.1670@fx35.am4> |
| In reply to | #29479 |
On 17/04/20 09:02, 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 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. > > 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. > > 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.) Yes indeed. I was beguiled by the concept of the GA144, but felt the per-core limitations were too significant when compared with an FPGA or more conventional processor. I was neither put off nor attracted by programming it in Forth. OTOH those that think Forth is the bees knees will gravitate to the GA144. 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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-17 15:44 +0200 |
| Message-ID | <r7cbrf$26l$1@dont-email.me> |
| In reply to | #29481 |
On 17/04/2020 11:49, Tom Gardner wrote: > On 17/04/20 09:02, 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 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. >> >> 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. >> >> 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.) > > Yes indeed. > > I was beguiled by the concept of the GA144, but felt the > per-core limitations were too significant when compared > with an FPGA or more conventional processor. > > I was neither put off nor attracted by programming it in > Forth. OTOH those that think Forth is the bees knees will > gravitate to the GA144. Perhaps Rick knows of people who have actually used the devices? (While I have only programmed a little in Forth, and that was decades ago, I appreciate it is a language with a number of nice features. But I expect Forth programmers to prefer modern Forth tools - writing the code in files using a good editor, laying it out well, picking good names, adding sensible comments, using static analysis, etc. I can't see the appeal in a based on blocks designed to fit on floppy drives and screens that were outdated 30 years ago.) > > 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-17 15:23 +0100 |
| Message-ID | <PZimG.97886$Kji.69961@fx15.am4> |
| In reply to | #29482 |
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: >>> 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 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. >>> >>> 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. >>> >>> 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.) >> >> Yes indeed. >> >> I was beguiled by the concept of the GA144, but felt the >> per-core limitations were too significant when compared >> with an FPGA or more conventional processor. >> >> I was neither put off nor attracted by programming it in >> Forth. OTOH those that think Forth is the bees knees will >> gravitate to the GA144. > > Perhaps Rick knows of people who have actually used the devices? > > (While I have only programmed a little in Forth, and that was decades ago, I > appreciate it is a language with a number of nice features. But I expect Forth > programmers to prefer modern Forth tools - writing the code in files using a > good editor, laying it out well, picking good names, adding sensible comments, > using static analysis, etc. I can't see the appeal in a based on blocks > designed to fit on floppy drives and screens that were outdated 30 years ago.) > >> >> 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 :) > 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. 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. 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 :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-17 18:15 +0200 |
| Message-ID | <r7ckn2$1pj$1@dont-email.me> |
| In reply to | #29483 |
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. 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. > >> 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. > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-17 17:49 +0100 |
| Message-ID | <d6lmG.14487$Gv6.8602@fx42.am4> |
| In reply to | #29487 |
On 17/04/20 17:15, 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. Oh I agree! However, being able to do it in software is a good demonstration of the device's unique characteristics, and that "you aren't in Kansas anymore" > 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. I didn't know they had a FreeRTOS port, and it sounds like having a dog and barking :) Sounds like it would combine the disadvantages and negate the advantages! Having said that, they did have a chip where one of the processors was an ARM. Perhaps it was intended that the ARM run FreeRTOS? > 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. There is a half-way house. If you adopt a certain coding style, the IDE will combine several processes to run on a single processor. Basically it is equivalent to appending all the process' "startup" code into a single block, and all the "forever loop" code into a single block. The key bit is combining all the process' select statements into as single select statement. With that understanding, the coding style requirements become obvious, not onerous, and they are checked by the compiler. >>> 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...) What is this "Windows" of which you speak? >> 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. Yebbut, the toolset won't analyse and predict worst case performance. So you are back to "run it and hope we stumble upon the worst case". Yes, that is sufficient in many cases, but it is /inelegant/, dammit! >> 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. There's no doubt it is niche. The world will go parallel. A major difficulty will be finding people that can think that way. (Just look at how difficult softies find it when they try to "program" VHDL/Verilog) We need all the tools and concepts we can muster; my fear is that CSP is the best! :)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-18 15:06 +0200 |
| Message-ID | <r7eu1d$j6c$1@dont-email.me> |
| In reply to | #29489 |
On 17/04/2020 18:49, Tom Gardner wrote: > On 17/04/20 17:15, 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. > > Oh I agree! However, being able to do it in software is a > good demonstration of the device's unique characteristics, > and that "you aren't in Kansas anymore" > Indeed. The real power comes from when you want to do something that is /not/ standard, or at least not common. Implementing a standard UART in a couple of XMOS cores is a pointless waste of silicon. Implementing a UART that uses Manchester encoding for the UART signals so that you can use it on a balanced line without keeping track of which line is which - /then/ you've got something that can be done just as easily on an XMOS and is a big pain to do on a standard microcontroller. Implementing an Ethernet MAC on an XMOS is pointless. Implementing an EtherCAT slave is not going to be much harder for the XMOS than a normal Ethernet MAC, but is impossible on any microcontroller without specialised peripherals. > >> 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. > > I didn't know they had a FreeRTOS port, and it sounds > like having a dog and barking :) Sounds like it would > combine the disadvantages and negate the advantages! > Some real-time stuff needs microsecond or sub-microsecond precision - XMOS lets you do that in software on a core, while normally you'd do it in dedicated peripherals on a microcontroller. But a lot needs millisecond or sub-second precision, and FreeRTOS is absolutely fine for that. (As are other methods, such as software timers.) > Having said that, they did have a chip where one of the > processors was an ARM. Perhaps it was intended that the > ARM run FreeRTOS? I haven't seen such a chip. Do you have a link? It could be an interesting device. > > >> 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. > > There is a half-way house. > > If you adopt a certain coding style, the IDE will combine > several processes to run on a single processor. > > Basically it is equivalent to appending all the process' > "startup" code into a single block, and all the "forever > loop" code into a single block. The key bit is combining > all the process' select statements into as single select > statement. > > With that understanding, the coding style requirements > become obvious, not onerous, and they are checked by the > compiler. I understand the principle, but you'd lose some of the modularity here. How well does it work if you want to have your UART, your CAN, your PWM, etc., defined in different files - and then you want to put them on the same core? I guess it will be possible. > > >>>> 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...) > > What is this "Windows" of which you speak? > Something some customers have. It is a system designed to be as inconvenient for developers as humanly possible. > >>> 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. > > Yebbut, the toolset won't analyse and predict worst case > performance. So you are back to "run it and hope we stumble > upon the worst case". > The peripherals are independent, and specified in documentation. If the PWM timer block can do 16-bit precision at 120 MHz, then you know its limits - and it doesn't matter how many UARTs you use or how fast you want your SPI bus to run. You don't need to analyse the timings - that was done when the chip was designed. You need to check the speeds of your high-level software that uses the modules, but that applies to XMOS code too. > Yes, that is sufficient in many cases, but it is /inelegant/, > dammit! > There is always room for improvement and extra tools! > >>> 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. > > There's no doubt it is niche. > > The world will go parallel. A major difficulty will be finding > people that can think that way. (Just look at how difficult > softies find it when they try to "program" VHDL/Verilog) > > We need all the tools and concepts we can muster; my fear > is that CSP is the best! :) I'd like a good way to do CSP stuff in C or C++. I've been looking at passing std::variant types in message queues in FreeRTOS, but I'm not happy with the results yet. I think I'll have to make my own alternative to std::variant, to make it more efficient for the task. It's fun. A different kind of fun from playing with the XMOS, but fun. If I ever get time, I will dig out my old XMOS kit and see how the current tools are looking. If I can find a neat way to get your "half-way house" system working, it will increase a good deal in its attractiveness for me.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-18 16:08 +0100 |
| Message-ID | <KJEmG.125957$8qv1.106987@fx12.am4> |
| In reply to | #29497 |
On 18/04/20 14:06, David Brown wrote:
> On 17/04/2020 18:49, Tom Gardner wrote:
>> On 17/04/20 17:15, 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.
>>
>> Oh I agree! However, being able to do it in software is a
>> good demonstration of the device's unique characteristics,
>> and that "you aren't in Kansas anymore"
>>
>
> Indeed.
>
> The real power comes from when you want to do something that is /not/ standard,
> or at least not common.
>
> Implementing a standard UART in a couple of XMOS cores is a pointless waste of
> silicon. Implementing a UART that uses Manchester encoding for the UART signals
> so that you can use it on a balanced line without keeping track of which line is
> which - /then/ you've got something that can be done just as easily on an XMOS
> and is a big pain to do on a standard microcontroller.
>
> Implementing an Ethernet MAC on an XMOS is pointless. Implementing an EtherCAT
> slave is not going to be much harder for the XMOS than a normal Ethernet MAC,
> but is impossible on any microcontroller without specialised peripherals.
Agreed.
>>> 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.
>>
>> I didn't know they had a FreeRTOS port, and it sounds
>> like having a dog and barking :) Sounds like it would
>> combine the disadvantages and negate the advantages!
>>
>
> Some real-time stuff needs microsecond or sub-microsecond precision - XMOS lets
> you do that in software on a core, while normally you'd do it in dedicated
> peripherals on a microcontroller. But a lot needs millisecond or sub-second
> precision, and FreeRTOS is absolutely fine for that. (As are other methods,
> such as software timers.)
>
>> Having said that, they did have a chip where one of the
>> processors was an ARM. Perhaps it was intended that the
>> ARM run FreeRTOS?
>
> I haven't seen such a chip. Do you have a link? It could be an interesting
> device.
Not offhand, and I don't think it is made anymore.
I pegged it as "seems nice at first glance, but
/two/ toolchains and what are the limitations on
the ARM?" -- and decided I didn't want to bother.
>>> 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.
>>
>> There is a half-way house.
>>
>> If you adopt a certain coding style, the IDE will combine
>> several processes to run on a single processor.
>>
>> Basically it is equivalent to appending all the process'
>> "startup" code into a single block, and all the "forever
>> loop" code into a single block. The key bit is combining
>> all the process' select statements into as single select
>> statement.
>>
>> With that understanding, the coding style requirements
>> become obvious, not onerous, and they are checked by the
>> compiler.
>
> I understand the principle, but you'd lose some of the modularity here. How well
> does it work if you want to have your UART, your CAN, your PWM, etc., defined in
> different files - and then you want to put them on the same core? I guess it
> will be possible.
Yup, see bottom of post, and for a different optimisation:
distributable functions.
>>>> 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.
>>
>> Yebbut, the toolset won't analyse and predict worst case
>> performance. So you are back to "run it and hope we stumble
>> upon the worst case".
>>
>
> The peripherals are independent, and specified in documentation. If the PWM
> timer block can do 16-bit precision at 120 MHz, then you know its limits - and
> it doesn't matter how many UARTs you use or how fast you want your SPI bus to
> run. You don't need to analyse the timings - that was done when the chip was
> designed.
>
> You need to check the speeds of your high-level software that uses the modules,
> but that applies to XMOS code too.
>
>> Yes, that is sufficient in many cases, but it is /inelegant/,
>> dammit!
>>
>
> There is always room for improvement and extra tools!
And that's recursive, iterative and fractal, and probably
another few woo-words as wwell :)
>>>> 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.
>>
>> There's no doubt it is niche.
>>
>> The world will go parallel. A major difficulty will be finding
>> people that can think that way. (Just look at how difficult
>> softies find it when they try to "program" VHDL/Verilog)
>>
>> We need all the tools and concepts we can muster; my fear
>> is that CSP is the best! :)
>
> I'd like a good way to do CSP stuff in C or C++. I've been looking at passing
> std::variant types in message queues in FreeRTOS, but I'm not happy with the
> results yet. I think I'll have to make my own alternative to std::variant, to
> make it more efficient for the task.
It always amazed me that Boehm had to write his paper
indicating that you couldn't write threads as a library.
I presume that is not longer the case.
> If I ever get time, I will dig out my old XMOS kit and see how the current tools
> are looking. If I can find a neat way to get your "half-way house" system
> working, it will increase a good deal in its attractiveness for me.
From my copy of The Programming Guide version F (there
may be a later variant).
That guide has the usual succinct and relevant examples
and pictures illustrating what is happening. If only
all documentation was as short and sweet.
*2.3 Creating tasks for flexible placement*
xC programs are built up from several tasks running in
parallel. These tasks can be of several different types
that can be used in different ways. The following [table]
shows the different types:
Normal tasks run on a logical core and run independently
to other tasks. The tasks have predictable running time
and can respond very efficiently to external events.
Combinable tasks can be combined to have several tasks
running on the same logical core. The core swaps context
based on cooperative multitasking between the tasks driven
by the compiler.
Distributable tasks can run over several cores, running
when required by the tasks connected to them. Using
these different tasks types you can maximize the resource
usage of the device depending on the form and timing
requirements of your tasks.
*2.3.1 Combinable functions*
If a tasks ends in an never-ending loop containing a
select statement, it represents a task that continually
reacts to events:
void task1 ( args ) {
.. initialization ...
while (1) {
select {
case ... :
break ;
case ... :
break ;
...
}
}
}
If a function complies to this format then it can be marked
as combinable by adding the combinable attribute:
[[ combinable ]]
*2.3.2 Distributable functions*
Sometime tasks contain state and provide services to other tasks,
but do not need to react to any external events on their own.
These kinds of tasks only run any code when communicating with
other tasks. As such they do not need a core of their own but
can share the logical cores of the tasks they communicate with
(as shown in Figure 12).
More formally, a task can be marked as distributable if:
- It satisfies the conditions to be combinable (i.e. ends
in a never-ending loop containing a select)
- The cases within that select only respond to interface
transactions
...
A distributable task can be implemented very efficiently if
all the tasks it connects to are on the same tile. In this
case the compiler will not allocate it a logical core of
its own.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 15:13 +0200 |
| Message-ID | <r7k75r$ae1$1@dont-email.me> |
| In reply to | #29500 |
On 18/04/2020 17:08, Tom Gardner wrote: > On 18/04/20 14:06, David Brown wrote: >> I'd like a good way to do CSP stuff in C or C++. I've been looking at >> passing std::variant types in message queues in FreeRTOS, but I'm not >> happy with the results yet. I think I'll have to make my own >> alternative to std::variant, to make it more efficient for the task. > > It always amazed me that Boehm had to write his paper > indicating that you couldn't write threads as a library. It always seemed obvious to me that you can't write thread support purely in standard C (C11 provides threading functions, but these can't be implemented in pure standard C). > I presume that is not longer the case. It is still the case. With C11 (or C++11) you can write code that /uses/ threads in pure C (or C++), but you can't write the implementation of the threads. > > >> If I ever get time, I will dig out my old XMOS kit and see how the >> current tools are looking. If I can find a neat way to get your >> "half-way house" system working, it will increase a good deal in its >> attractiveness for me. > > From my copy of The Programming Guide version F (there > may be a later variant). > > That guide has the usual succinct and relevant examples > and pictures illustrating what is happening. If only > all documentation was as short and sweet. > > *2.3 Creating tasks for flexible placement* > <snip details> Thank you for that. This is a significant new feature since I used XMOS, and one that I see as a major step forward. Your posts in this thread have renewed my interest in XMOS. If XMOS run a pyramid scheme for evangelism, you have definitely earned yourself a few more brownie points. Now all I need to do is find a customer with an application that fits... (If there were an EtherCAT slave peripheral available for XMOS, I might have had an application.)
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 14:24 +0100 |
| Message-ID | <9ohnG.50219$Jj2.31205@fx11.am4> |
| In reply to | #29530 |
On 20/04/20 14:13, David Brown wrote: > On 18/04/2020 17:08, Tom Gardner wrote: >>> If I ever get time, I will dig out my old XMOS kit and see how the current >>> tools are looking. If I can find a neat way to get your "half-way house" >>> system working, it will increase a good deal in its attractiveness for me. >> >> From my copy of The Programming Guide version F (there >> may be a later variant). >> >> That guide has the usual succinct and relevant examples >> and pictures illustrating what is happening. If only >> all documentation was as short and sweet. >> >> *2.3 Creating tasks for flexible placement* >> > > <snip details> > > Thank you for that. This is a significant new feature since I used XMOS, and > one that I see as a major step forward. Arguably it is merely syntactic sugar, but clarity isn't to be underestimated. > Your posts in this thread have renewed my interest in XMOS. If XMOS run a > pyramid scheme for evangelism, you have definitely earned yourself a few more > brownie points. Regrettably not; I'm merely a fanboy :) > Now all I need to do is find a customer with an application that fits... > > (If there were an EtherCAT slave peripheral available for XMOS, I might have had > an application.) Yes, and I'm sure there is a reason you couldn't fall back on the old ways, and use an external peripheral.
[toc] | [prev] | [next] | [standalone]
Page 1 of 8 [1] 2 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web