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 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 19:39 +0200 |
| Message-ID | <r7kmpd$rsi$1@dont-email.me> |
| In reply to | #29547 |
On 20/04/2020 18:03, Tom Gardner wrote: > 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. A better solution, I think, is that it should not matter which task is running at any given time - because these tasks run to handle a specific situation then yield waiting for an event. Multiple priorities are convenient to express which tasks should be handled with lower latencies. I'm not keen on multiple tasks that have some kind of time-sharing switching between them, or round-robin pre-emptive multitasking. (Unless by "supervisor" here you just mean a "while (true)" loop that calls the tasks one after the other, which is fine.) > > 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]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 21:25 +0100 |
| Message-ID | <jznnG.57645$fD4.10530@fx09.am4> |
| In reply to | #29548 |
On 20/04/20 18:39, David Brown wrote: > On 20/04/2020 18:03, Tom Gardner wrote: >> 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. > > A better solution, I think, is that it should not matter which task is running > at any given time - because these tasks run to handle a specific situation then > yield waiting for an event. If there are many tasks with event(s) that have arrived, it becomes necessary to choose which to run. The choice of which to run is, of necessity, application dependent. Applications can emphasise forward progress, mean or 95th percentile latency, earliest deadline first, priority, etc. > Multiple priorities are convenient to express which > tasks should be handled with lower latencies. I'm not keen on multiple tasks > that have some kind of time-sharing switching between them, or round-robin > pre-emptive multitasking. (Unless by "supervisor" here you just mean a "while > (true)" loop that calls the tasks one after the other, which is fine.) In one form or another, yes. But the word "task" has too many different meanings in this context. Many would map a task onto a process, thread or fibre. That frequently leads to "suboptimal behaviour" sooner or later, and it can be a problem sorting out the cause and effect. To expand on my previous comment below... My preference is that an event is encapsulated in an object when it arrives. The scheduler puts the object in a FIFO, and worker threads (approx one per core) take the object and process the event. Priority can be via multiple queues, and there are other obvious techniques to ensure other properties are met. >> 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]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-20 18:27 -0700 |
| Message-ID | <869be946-a22c-4bd9-b3ef-d0180b960343@googlegroups.com> |
| In reply to | #29539 |
On Monday, April 20, 2020 at 10:53:49 AM UTC-4, 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. I've never heard of livelock until this discussion. Reading about it I have no idea what the parallel would be in hardware design. I don't even know of an example of deadlock in hardware design. So clearly these are not such important issues in hardware design. I expect the difference is that while hardware design uses signals (in fact that is the term for a "variable" in VHDL, not to be confused with a variable in VHDL which has limited scope and other limitations) it does not have resources to be allocated or seized or whatever the correct term is. If it does for synthesis, I don't know what that would be. > 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. How is that an issue? Isn't task A stalled when it is waiting which allows task B to run? I recall reading about priority issues such as "priority inversion" some time back. But not having written any multitasking software in a long time it has all vanished. I'm pretty glad of it too. It was just a lot of ugly stuff I thought. My biggest problem writing VHDL is trying to manage the verbosity. But then there are issues in the language I have simply internalized and don't think about. I have thought many times about the contradiction of my liking VHDL, a rather restrictive (in theory) and verbose language as well as a much simpler, easy and concise language as Forth. Coding for Forth is like working in my basement with hand tools. Coding in VHDL is like working on a sculpture for a museum. Never the twain shall meet. -- 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-21 17:58 +0200 |
| Message-ID | <r7n57f$mlr$1@dont-email.me> |
| In reply to | #29557 |
On 21/04/2020 03:27, Rick C wrote: > On Monday, April 20, 2020 at 10:53:49 AM UTC-4, 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. > > I've never heard of livelock until this discussion. Reading about it I have no idea what the parallel would be in hardware design. Livelock is when bits of a system are running fine, but the overall system is not making progress. Often it is temporary and resolves itself (unlike deadlock). A hardware example might be if you have a crossbar for multiple bus masters to access a single slave device. You need some way of deciding which master gets access when both want it simultaneously. Perhaps you decide that master A is more important, and always gets priority. Then if master A hogs the bus, master B never gets a chance - livelock. Often these kinds of things are straightforward to avoid as long as you think about what can happen. That applies to software and hardware. > > I don't even know of an example of deadlock in hardware design. The simplest way to get a deadlock is to have two shared resources, and two processes (hardware modules, software tasks, whatever) that need both the resources, but acquire them in different orders. But you don't usually get such simple cases, as they are so obvious. > > So clearly these are not such important issues in hardware design. If your designs don't involve much in the way of shared resources, you're not going see them. (The same applies in software.) It is also perfectly possible that the way you design your systems, they naturally don't occur - or that you think of them as bugs, hangs, blocks or stops rather than as "deadlocks". (The same applies in software.) It is also possible, though of course /highly/ unlikely, that your systems /do/ have the risk of deadlocks and they just haven't happened yet. (The same applies in software.) > > I expect the difference is that while hardware design uses signals (in fact that is the term for a "variable" in VHDL, not to be confused with a variable in VHDL which has limited scope and other limitations) it does not have resources to be allocated or seized or whatever the correct term is. If it does for synthesis, I don't know what that would be. > You can have shared resources in hardware too. It is perhaps fair to say that the way you design hardware makes shared resources stand out a bit more - you have explicit sharing with cross-switches, multiplexors, etc. And that might mean that deadlock-free solutions are mostly so obvious that you don't see them as a potential problem. I discussed previously about thinking the "hardware way" for shared data in software development - that also makes it very easy to avoid deadlock. > >> 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. > > How is that an issue? Isn't task A stalled when it is waiting which allows task B to run? Yes. But it means task A - the high priority task - can't be completed as fast as you had wanted. > > I recall reading about priority issues such as "priority inversion" some time back. But not having written any multitasking software in a long time it has all vanished. I'm pretty glad of it too. It was just a lot of ugly stuff I thought. My biggest problem writing VHDL is trying to manage the verbosity. But then there are issues in the language I have simply internalized and don't think about. > > I have thought many times about the contradiction of my liking VHDL, a rather restrictive (in theory) and verbose language as well as a much simpler, easy and concise language as Forth. Coding for Forth is like working in my basement with hand tools. Coding in VHDL is like working on a sculpture for a museum. Never the twain shall meet. > I program mostly in C and Python. It's hard to pick two software languages that are further apart - so I understand what you mean here.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2020-04-21 19:41 +0300 |
| Message-ID | <hg8m25FojujU1@mid.individual.net> |
| In reply to | #29569 |
On 2020-04-21 18:58, David Brown wrote:
> On 21/04/2020 03:27, Rick C wrote:
>> On Monday, April 20, 2020 at 10:53:49 AM UTC-4, David Brown wrote:
[snip]
>>> 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.
There are similar multi-core priority-bumping schemes, but they are more
complex and have more overhead, of course.
>> How is that an issue? Isn't task A stalled when it is waiting which
>> allows task B to run?
>
> Yes. But it means task A - the high priority task - can't be completed
> as fast as you had wanted.
If there are no other tasks on this core, there is no extra delay for A
-- it waits just long enough for B to complete the/a result for A.
The real problem occurs when there is some other task C, _not_ logically
connected to A or B, with a priority higher than B but lower than A.
Task C can then delay B, and therefore also A, for whatever duration C
runs. As David said, this priority inversion can be solved by
temporarily increasing B's priority to A's priority until B has executed
far enough to let A continue.
In the Ada language, the "protected object" inter-task communication
mechanism implements this priority juggling automatically. The
programmer only has to define the basic task priorities and the "ceiling
priorities" for the protected objects.
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-21 14:01 -0700 |
| Message-ID | <49c33c5b-6136-44e1-b645-5437fd8c8361@googlegroups.com> |
| In reply to | #29569 |
On Tuesday, April 21, 2020 at 11:58:43 AM UTC-4, David Brown wrote: > On 21/04/2020 03:27, Rick C wrote: > > On Monday, April 20, 2020 at 10:53:49 AM UTC-4, 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. > > > > I've never heard of livelock until this discussion. Reading about it I have no idea what the parallel would be in hardware design. > > Livelock is when bits of a system are running fine, but the overall > system is not making progress. Often it is temporary and resolves > itself (unlike deadlock). > > A hardware example might be if you have a crossbar for multiple bus > masters to access a single slave device. You need some way of deciding > which master gets access when both want it simultaneously. Perhaps you > decide that master A is more important, and always gets priority. Then > if master A hogs the bus, master B never gets a chance - livelock. > > Often these kinds of things are straightforward to avoid as long as you > think about what can happen. That applies to software and hardware. Ok, but that is very simple and doesn't sound like an issue that is very hard to deal with. In general I would not even think of it as a category of problems I need to think about. It's just an obvious issue in a given design. There are many of those. > > I don't even know of an example of deadlock in hardware design. > > The simplest way to get a deadlock is to have two shared resources, and > two processes (hardware modules, software tasks, whatever) that need > both the resources, but acquire them in different orders. But you don't > usually get such simple cases, as they are so obvious. That was my point, I've never designed hardware that had "resources" to allocate. Maybe my designs are just too simple. I do like to keep things simple when I design. I've never not been able to do that when designing hardware. I'm familiar with deadlock from software design, just don't see it in hardware so far. > > So clearly these are not such important issues in hardware design. > > If your designs don't involve much in the way of shared resources, > you're not going see them. (The same applies in software.) It is also > perfectly possible that the way you design your systems, they naturally > don't occur - or that you think of them as bugs, hangs, blocks or stops > rather than as "deadlocks". (The same applies in software.) It is also > possible, though of course /highly/ unlikely, that your systems /do/ > have the risk of deadlocks and they just haven't happened yet. (The > same applies in software.) I understand the issues and both my hardware and software don't have such problems. My software has never been multitask. My hardware has always had simple relationships. I guess I just don't design complicated things. > > I expect the difference is that while hardware design uses signals (in fact that is the term for a "variable" in VHDL, not to be confused with a variable in VHDL which has limited scope and other limitations) it does not have resources to be allocated or seized or whatever the correct term is. If it does for synthesis, I don't know what that would be. > > > > You can have shared resources in hardware too. > > It is perhaps fair to say that the way you design hardware makes shared > resources stand out a bit more - you have explicit sharing with > cross-switches, multiplexors, etc. And that might mean that > deadlock-free solutions are mostly so obvious that you don't see them as > a potential problem. I discussed previously about thinking the > "hardware way" for shared data in software development - that also makes > it very easy to avoid deadlock. Or just not using multiple tasks accessing the same data. I've never found the need. > >> 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. > > > > How is that an issue? Isn't task A stalled when it is waiting which allows task B to run? > > Yes. But it means task A - the high priority task - can't be completed > as fast as you had wanted. If task A is waiting for task B and you don't like the delay, that's bad design. If it has to wait on task B by definition of the problem, then that's a limitation you have to live with. This isn't deadlocking unless task B is also waiting on task A. If you have this problem then you have not decomposed the problem correctly. > > I recall reading about priority issues such as "priority inversion" some time back. But not having written any multitasking software in a long time it has all vanished. I'm pretty glad of it too. It was just a lot of ugly stuff I thought. My biggest problem writing VHDL is trying to manage the verbosity. But then there are issues in the language I have simply internalized and don't think about. > > > > I have thought many times about the contradiction of my liking VHDL, a rather restrictive (in theory) and verbose language as well as a much simpler, easy and concise language as Forth. Coding for Forth is like working in my basement with hand tools. Coding in VHDL is like working on a sculpture for a museum. Never the twain shall meet. > > > > I program mostly in C and Python. It's hard to pick two software > languages that are further apart - so I understand what you mean here. -- 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 23:21 +0100 |
| Message-ID | <MlKnG.42999$hQ3.32147@fx26.am4> |
| In reply to | #29578 |
On 21/04/20 22:01, Rick C wrote: > On Tuesday, April 21, 2020 at 11:58:43 AM UTC-4, David Brown wrote: >> The simplest way to get a deadlock is to have two shared resources, and >> two processes (hardware modules, software tasks, whatever) that need >> both the resources, but acquire them in different orders. But you don't >> usually get such simple cases, as they are so obvious. > > That was my point, I've never designed hardware that had "resources" to allocate. Maybe my designs are just too simple. I do like to keep things simple when I design. I've never not been able to do that when designing hardware. > > I'm familiar with deadlock from software design, just don't see it in hardware so far. Here's a real-life example which has subtle problems. Consider a token ring network in the presence of failures which split and reconnect the ring. Your task is to have exactly one token circulating, not zero, not two. Prove your solution meets that criteria.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-19 20:53 +0200 |
| Message-ID | <r7i6mc$8o1$1@dont-email.me> |
| In reply to | #29485 |
On 17/04/2020 18:11, Rick C wrote: > 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. You don't think that I /do/ understand that a different mindset is needed for a chip like the GA144? I think it is a design that will be of little use in most cases, and a poor fit for many applications. That is not because I don't understand how to work with such a device, or how it is different from other devices, or that I can't get into the right "mindset". Please stop assuming that the only reason someone might disagree with you is that they are ignorant. > A single, > fast CPU is harder to program than many, fast CPUs. Even if this were true, it is irrelevant, because the GA144 cores are not "fast CPUs". They can each do almost nothing. It really doesn't matter if they can do it quickly. Clearly these cores can do /some/ things, but they are not comparable to a normal cpu when they have so limited memory. A single very fast CPU can do single-tasking things very quickly. It can also do many small and simple tasks, because it can run a multitasking system. But if a task can't be split up into parallel or pipelined activities, then smaller or slower cpus can't do it as well, no matter how many you have. > Programmers have > to learn a lot in order to perform multitasking on a single CPU. Sure. But if they want to perform multitasking with more than one CPU, they have to learn the same things - and then more. And if they need to do manual partitioning of tasks on many parts, they have even more to learn. > It's a difficult and error prone design exercise. Transition that to > many CPUs and the vast majority of those problems go away. > No, they don't. (Let's be clear here - the majority of programmers /use/ multitasking systems rather than designing them.) > 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 almost always have one resource that is the limit first - it may be cpu power, or ram, or flash, or IO, or any other kind of resource. And it's fair to say that a lot of designers and programmers are not particularly good at judging what that resource might be - resulting in a lot of effort wasted in optimising for one resource when others are more significant. > > >> 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. In this case, it appears to be a shoe that fits almost no foot. A good indication of this is that the whole company apparently stopped in 2012, judging by their website - only a short time after they got the whole thing going. By my reckoning (from what I see on their site), they spent about a year or two after making the chip, making examples and application notes, and trying to sell the thing, and then collapsed through lack of interest. > > 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. Where would be the advantage? Let's assume a company's design team are happy to spend the time learning the programming language (which would be a leap backwards in time compared to modern Forths), the tools from a pre-DOS era, and the unusual system architecture. And we'll assume that their management are happy investing the time and effort with a unique product from a dead company run by a guy who was undoubtedly a pioneer and a genius in his time, but has been increasingly disconnected from reality for several decades. What can this chip do that an FPGA can't do better? What can it do that a DSP can't do better? You have all these processing elements that can work fairly fast, but with almost no resources and very limited communication. You can't connect freely across the chip, like you can with an FPGA. You can't use much memory - you couldn't do anything but the smallest of filters. The cores are weak - they may be able to run quickly, but any multiplication needs to be written out manually as loops of additions and shifts. A DSP or FPGA will be capable of handling massively more data in and out of the chips. And a normal cpu with SIMD will probably handle most jobs as well. Don't get me wrong here - I am not saying there are no applications for such a device, or no applications for which it is a good fit. I am not even saying there are no applications for which it is a /better/ fit - faster, smaller, cheaper or lower power than alternatives. I am saying that its suitable use-cases are so small, and its disadvantages so big, that it is not going to be an appropriate choice in more than a tiny handful of systems. The GA144 is not the first "big array of tiny processors" chip. I have heard of several others over the years. I haven't heard of any that have been big successes. (That does not, by any means, prove that there /haven't/ been big successes.) I think it is a good thing that people come along with some wildly different architectures, or totally out-of-the-box ideas. But if it is ever going to be a success, such ideas need a "killer application". If the GA144 really is useful for DSP work, then the company should have been making demo boards that did something amazing in DSP. They should have looked at a Texas Instruments DSP running 720p30 MPEG encoding in real time (this was a decade ago), and make a GA144 board that did 1080p60 encoding with a tenth of the power consumption, and shown how you could scale it with four GA144's to do 2160p60. /Then/ they would have had something they could sell - something that would give companies a reason to spend multiple man-years teaching their development team a new way of designing. Instead, they give an expensive and incomprehensible way to get make an Ethernet MAC at speeds that hadn't been seen for a decade. > > 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 wonder if you are thinking of the same things. The GA144 cores do very little each, and are programmed with all the user friendliness of a Spectrum ZX81, complete with hand assembling the machine code and manually counting addresses. This is primarily a result of the fanaticism of the people behind the device and tools - the insistence that it all be able to run on this chip. And it has a user community consisting of a dozen or so disciples of Chuck Moore who apparently haven't talked to anyone else since the 1980's. XMOS takes a bit of changed ideas and some new ways of thinking to get the best from them. But the (virtual) cores are solid devices, programmed in decent modern languages (after some very frustrating limitations in their early days) with a good IDE and tools, and a large community of users well supported by the company. There are some things about the chips that I think are downright silly limitations, and I think a bit less "purism" would help, but they are a world apart from the GA144. > 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. > I think we can all agree that every customer would be happier with lower prices here! Still, there are devices from Efinix (I know almost nothing about the company) and Lattice for a dollar or so. Yes, these are fine-pitch BGA packages, but the range of companies that can handle these is much greater than it used to be (even if it is by outsourcing the board production).
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-19 14:47 -0700 |
| Message-ID | <4429be4e-964c-47b3-9a55-252ebdc26544@googlegroups.com> |
| In reply to | #29515 |
On Sunday, April 19, 2020 at 2:53:04 PM UTC-4, David Brown wrote: > On 17/04/2020 18:11, Rick C wrote: > > 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. > > You don't think that I /do/ understand that a different mindset is > needed for a chip like the GA144? I think it is a design that will be > of little use in most cases, and a poor fit for many applications. That > is not because I don't understand how to work with such a device, or how > it is different from other devices, or that I can't get into the right > "mindset". > > Please stop assuming that the only reason someone might disagree with > you is that they are ignorant. I'm only going by what you write. I never said anyone was ignorant. I'm talking about preconceptions and the tendency to appreciate the familiar. I may not have built anything for the GA144, but I have written programs for it. It's not as hard to use or inflexible as you think. Is it the right tool to construct a Raspberry Pi, no. But it has a lot of potential for a wide array of tasks. The main issue is that people continue to judge it in the same manner as other devices which are not really comparable. Hence "mindset". This reminds me of a time when I was trying to discuss a digital oscillator. People often will use a digital inverter to act as a (relatively) linear amplifier in a crystal circuit. What I was talking about was detecting the voltage on the crystal and giving it a "ping" from a digital circuit to keep it oscillating. Someone insisted I had to analyze it with the Barkhausen criterion and tried to tell me this would never work. The design had already been done for a slower oscillator, 32 kHz. So clearly he was wrong. But this guy refused to consider the design from a different angle than the analog oscillators he knew. That's mindset. So please stop being indignant when I point it out. I'm pretty sure you don't really know the limitations of the device. > > A single, > > fast CPU is harder to program than many, fast CPUs. > > Even if this were true, it is irrelevant, because the GA144 cores are > not "fast CPUs". They can each do almost nothing. It really doesn't > matter if they can do it quickly. Clearly these cores can do /some/ > things, but they are not comparable to a normal cpu when they have so > limited memory. True, they are not comparable to typical CPUs. But they do have adequate memory for many applications because of the way they are used in combination. How much memory does the ALU in the CPU have? Very little or perhaps none depending on how you look at it. Use it in combination with the rest of the functions in the CPU and it accomplishes a great deal. You seem to be used to thinking of problems at higher levels with very complex solutions. The GA144 requires decomposing a problem in a different way... which is not so different from working in FPGAs. > A single very fast CPU can do single-tasking things very quickly. It > can also do many small and simple tasks, because it can run a > multitasking system. As long as those tasks don't interfere with one another. > But if a task can't be split up into parallel or pipelined activities, > then smaller or slower cpus can't do it as well, no matter how many you > have. Absolutely right, except for when it is wrong. What task can you think of that can't be partitioned in any way??? I've never seen one. It is hard to partition many tasks for asynchronous, parallel execution on independent processors. In general if you can partition a programming problem into subroutines, you can usually partition it in a way that can be executed on multiple coordinating processors. That was the thinking behind the Transputer. > > Programmers have > > to learn a lot in order to perform multitasking on a single CPU. > > Sure. But if they want to perform multitasking with more than one CPU, > they have to learn the same things - and then more. And if they need to > do manual partitioning of tasks on many parts, they have even more to learn. Not really. Every design I've ever done in an FPGA was essentially multitasking on multiprocessors with a 1 to 1 mapping. I never consider the issues I face when multitasking on a single processor. VHDL programs consist of processes. Even concurrent statements are each processes that run on independent processors. Easy, peasy. > > It's a difficult and error prone design exercise. Transition that to > > many CPUs and the vast majority of those problems go away. > > > > No, they don't. (Let's be clear here - the majority of programmers > /use/ multitasking systems rather than designing them.) Which means nothing. You still have to program being mindful of the many limitations. I know I was burned many times. > > 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 almost always have one resource that is the limit first - it may be > cpu power, or ram, or flash, or IO, or any other kind of resource. And > it's fair to say that a lot of designers and programmers are not > particularly good at judging what that resource might be - resulting in > a lot of effort wasted in optimising for one resource when others are > more significant. Not sure how that is relevant. The guy was criticizing the GA144 for not being able to extract the full MIPS potential of all 144 CPUs. He was stuck in the mindset that CPUs are all about MIPS rather than considering how well the chip may suit any given application. I think I said in another discussion that FPGA makers tried to fight the mindset that every LUT and FF in the FPGA should be usable without restriction from the routing. They would say, "We sell you the routing and throw in the logic for free" which was largely true because the lion's share of the real estate was routing. Much like the lion's share of MCUs is memory, they throw in the CPU and peripherals for free. > >> 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. > > In this case, it appears to be a shoe that fits almost no foot. A good > indication of this is that the whole company apparently stopped in 2012, > judging by their website - only a short time after they got the whole > thing going. By my reckoning (from what I see on their site), they > spent about a year or two after making the chip, making examples and > application notes, and trying to sell the thing, and then collapsed > through lack of interest. Not sure what you are looking at. GA is as alive as they've ever been which is not saying a lot. At one point they were promoting people to explore their devices by coming to their facility and working on an application. They would put you up at someone's home. lol This was a literal shoestring operation from the word 'go'. They have potential customers interested in a 32 bit version from time to time, but so far it has not materialized. Whatever lack of interest there is, you can't blame is solely on the chip. There are so many other reasons to not use this device in a real design. Support is rather limited. Longevity is questionable. The development system is... 'unique' to put it mildly. Even if the GA144 were the perfect device for your application, it is very unlikely you would design it in. One application the company talks about is for a hearing aid. It used new theories of how we hear to improve hearing for people what traditional "filtered" amplifiers don't work. The algorithms were complex requiring two TMS320C6xxx devices in the prototype. They got it working in a single GA144 at a huge power savings. I've never heard of it coming to market. Clearly not a problem with the chip itself. > > 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. > > Where would be the advantage? Let's assume a company's design team are > happy to spend the time learning the programming language (which would > be a leap backwards in time compared to modern Forths), I think you aren't familiar with the tools or programming language. > the tools from a > pre-DOS era, and the unusual system architecture. And we'll assume that > their management are happy investing the time and effort with a unique > product from a dead company run by a guy who was undoubtedly a pioneer > and a genius in his time, but has been increasingly disconnected from > reality for several decades. You clearly know nothing about the company. Who is it you think "runs" it? Besides, we were discussing the architecture, now you are bringing everything into the conversation but the kitchen sink. Is that what you want to talk about, the company finances? What does that have to do with multitasking on multiprocessors? > What can this chip do that an FPGA can't do better? Many people don't like working with FPGAs, but even so, this chip has a lot more MIPS/watt than any chip I've ever seen. If you need lots of horsepower and few Watts (or should I say watt?) this could be a good device. But again, we are straying from the original topic. > What can it do that a DSP can't do better? Again, the watts are a big advantage. It's also very small. The TMS320C6xxx family is a beast in comparison. > You have all these processing elements that can > work fairly fast, but with almost no resources and very limited > communication. You can't connect freely across the chip, like you can > with an FPGA. You can't use much memory - you couldn't do anything but > the smallest of filters. The cores are weak - they may be able to run > quickly, but any multiplication needs to be written out manually as > loops of additions and shifts. A DSP or FPGA will be capable of > handling massively more data in and out of the chips. And a normal cpu > with SIMD will probably handle most jobs as well. You are showing your mindset limitations. You can say many of the same things about the TMS320C6xxx line. Little memeory, limited connectivity, limited performance. You claim about limited I/O performance is not valid. The device has fast serial interfaces and each I/O pin is a high speed interface. Then there is a parallel bus intended for memory interfacing, but usable for many things. Still, why go into all this? We were discussing multitasking architectures. > Don't get me wrong here - I am not saying there are no applications for > such a device, or no applications for which it is a good fit. I am not > even saying there are no applications for which it is a /better/ fit - > faster, smaller, cheaper or lower power than alternatives. > > I am saying that its suitable use-cases are so small, and its > disadvantages so big, that it is not going to be an appropriate choice > in more than a tiny handful of systems. I agree that the GA144 finds very few sockets when the entire package is considered. But the problem is not because the multiprocessing is not an easy way to do multitasking. > The GA144 is not the first "big array of tiny processors" chip. I have > heard of several others over the years. I haven't heard of any that > have been big successes. (That does not, by any means, prove that there > /haven't/ been big successes.) > > I think it is a good thing that people come along with some wildly > different architectures, or totally out-of-the-box ideas. But if it is > ever going to be a success, such ideas need a "killer application". If > the GA144 really is useful for DSP work, then the company should have > been making demo boards that did something amazing in DSP. The company should have done a LOT of things like produce a data sheet with full timing specs. I asked them about a timing parameter equivalent to clock to output for an FPGA. They said they would not provide that as it might reveal internal design details!!! WTF! They suggested I measure it for myself by getting an eval board and writing my app. Needless to say I didn't do that. > They should > have looked at a Texas Instruments DSP running 720p30 MPEG encoding in > real time (this was a decade ago), and make a GA144 board that did > 1080p60 encoding with a tenth of the power consumption, and shown how > you could scale it with four GA144's to do 2160p60. /Then/ they would > have had something they could sell - something that would give companies > a reason to spend multiple man-years teaching their development team a > new way of designing. Instead, they give an expensive and > incomprehensible way to get make an Ethernet MAC at speeds that hadn't > been seen for a decade. Great ideas! Why not go out there and do that for them? They will give you room and board... maybe. > > 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 wonder if you are thinking of the same things. > > The GA144 cores do very little each, and are programmed with all the > user friendliness of a Spectrum ZX81, I'm pretty sure you know pretty much nothing of programming one of these CPUs. They are actually very easy to program. I bet it is a lot easier to learn than the XMOS mass of documentation. > complete with hand assembling the > machine code and manually counting addresses. ??? what are you talking about ??? > This is primarily a > result of the fanaticism of the people behind the device and tools - the > insistence that it all be able to run on this chip. Again, what??? The tools run on a PC. > And it has a user > community consisting of a dozen or so disciples of Chuck Moore who > apparently haven't talked to anyone else since the 1980's. lol > XMOS takes a bit of changed ideas and some new ways of thinking to get > the best from them. But the (virtual) cores are solid devices, > programmed in decent modern languages (after some very frustrating > limitations in their early days) with a good IDE and tools, and a large > community of users well supported by the company. There are some things > about the chips that I think are downright silly limitations, and I > think a bit less "purism" would help, but they are a world apart from > the GA144. Yes, too bad the XMOS is the best solution in only a tiny part of the market. > > 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. > > > > I think we can all agree that every customer would be happier with lower > prices here! That's not what I said. Prices are qualifiers for a CPU just like many other aspects. If your cost budget allows $2 for the CPU, no $5 CPUs pass the first cut. in this case the equivalent devices from Microchip are in the $50 and up range. They don't fit on any of my boards no matter what size they are. Last time I built boards my cost from the contract assembler was $60. > Still, there are devices from Efinix (I know almost nothing about the > company) and Lattice for a dollar or so. Yes, these are fine-pitch BGA > packages, but the range of companies that can handle these is much > greater than it used to be (even if it is by outsourcing the board > production). Lattice has some more "friendly" packages for their low end parts. As soon as I have a need I expect to be using one. Currently they don't do anything better (that I need) than the 10+ year old part I'm currently using. Lattice is always on my radar because they are the only company who seems to be taking the low end seriously. -- Rick C. -+-- Get 1,000 miles of free Supercharging -+-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 02:11 +0100 |
| Message-ID | <3F6nG.92889$QJp.31231@fx08.am4> |
| In reply to | #29520 |
On 19/04/20 22:47, Rick C wrote: > One application the company talks about is for a hearing aid. It used new > theories of how we hear to improve hearing for people what traditional > "filtered" amplifiers don't work. If true, that marks them as being completely unrealistic. The chances of some softies coming up with novel valid hearing aid algorithms without having previous experience is effectively zero. Even if they had, the chances of getting one of their chips into an ear canal are effectively zero.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2020-04-19 18:31 -0700 |
| Message-ID | <87r1wj3pu8.fsf@nightsong.com> |
| In reply to | #29523 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > The chances of some softies coming up with novel valid hearing aid > algorithms without having previous experience is effectively zero. I don't think they developed the algorithms themselves. IIRC the method was developed by some medical types who do that sort of thing. It used a bunch of filter banks simultaneously, and the claim was that the GA144 or its 28-core predecessor could do this using less electrical power than conventional MCU's or DSP's, at least at the time. I don't know if the approach ever went anywhere. I don't think it purported to fit inside the ear canal. It may have been a behind-the-ear type of hearing aid, or even a pocket device.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-19 20:32 -0700 |
| Message-ID | <09fe921a-7a6a-4ca7-8552-1050ec951ff1@googlegroups.com> |
| In reply to | #29523 |
On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote: > On 19/04/20 22:47, Rick C wrote: > > One application the company talks about is for a hearing aid. It used new > > theories of how we hear to improve hearing for people what traditional > > "filtered" amplifiers don't work. > > If true, that marks them as being completely unrealistic. > > The chances of some softies coming up with novel valid > hearing aid algorithms without having previous experience > is effectively zero. > > Even if they had, the chances of getting one of their chips > into an ear canal are effectively zero. There you go, proving my point of mindset, over and over. No, I don't care enough about the XMOS to read more of their marketing docs. If you have a point to make, either make it or not. I don't care. -- Rick C. -++- Get 1,000 miles of free Supercharging -++- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 07:46 +0100 |
| Message-ID | <azbnG.41114$TB.17307@fx16.am4> |
| In reply to | #29525 |
On 20/04/20 04:32, Rick C wrote: > On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote: >> On 19/04/20 22:47, Rick C wrote: >>> One application the company talks about is for a hearing aid. It used >>> new theories of how we hear to improve hearing for people what >>> traditional "filtered" amplifiers don't work. >> >> If true, that marks them as being completely unrealistic. >> >> The chances of some softies coming up with novel valid hearing aid >> algorithms without having previous experience is effectively zero. >> >> Even if they had, the chances of getting one of their chips into an ear >> canal are effectively zero. > > There you go, proving my point of mindset, over and over. What are you on about? That point has nothing whatsoever to do with XMOS! > No, I don't care enough about the XMOS to read more of their marketing docs. > If you have a point to make, either make it or not. I don't care. So why did you write elsewhere?... On 19/04/20 23:02, Rick C wrote:> I think this conversation has come to an end. You made a claim that does not > fit with what I know about the XMOS. If that claim is in the documentation, > just provide a reference. I'm not going to wade through a bunch of docs to > research YOUR claim. I provided a reference to a 4 page information dense document. Your refusal to read a indicates that /you/ are the one with the mindset that you are not prepared to change! Yes, I and others have read the GAL document, thought about how to use it, and chosen not to.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-20 00:33 -0700 |
| Message-ID | <f1aaec0b-3b2a-4ad6-98ac-39dd628be88f@googlegroups.com> |
| In reply to | #29526 |
On Monday, April 20, 2020 at 2:46:34 AM UTC-4, Tom Gardner wrote: > On 20/04/20 04:32, Rick C wrote: > > On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote: > >> On 19/04/20 22:47, Rick C wrote: > >>> One application the company talks about is for a hearing aid. It used > >>> new theories of how we hear to improve hearing for people what > >>> traditional "filtered" amplifiers don't work. > >> > >> If true, that marks them as being completely unrealistic. > >> > >> The chances of some softies coming up with novel valid hearing aid > >> algorithms without having previous experience is effectively zero. > >> > >> Even if they had, the chances of getting one of their chips into an ear > >> canal are effectively zero. > > > > There you go, proving my point of mindset, over and over. > > What are you on about? > > That point has nothing whatsoever to do with XMOS! You are uniquely obsessed with XMOS. The quoted conversation is about the GA144. Why are you bringing XMOS into it??? You are making assertions about a design team that you know nothing about being unable to be innovative in a useful way on a product you know nothing about. Then you talk about not being able to put a chip in an ear canal as if that was the only way to use a hearing aid. What is going on with you? Is the Corona-confinement getting to you? > > No, I don't care enough about the XMOS to read more of their marketing docs. > > If you have a point to make, either make it or not. I don't care. > > So why did you write elsewhere?... > > On 19/04/20 23:02, Rick C wrote:> I think this conversation has come to an end. > You made a claim that does not > > fit with what I know about the XMOS. If that claim is in the documentation, > > just provide a reference. I'm not going to wade through a bunch of docs to > > research YOUR claim. > > I provided a reference to a 4 page information dense > document. Your refusal to read a indicates that /you/ > are the one with the mindset that you are not prepared > to change! > > Yes, I and others have read the GAL document, thought > about how to use it, and chosen not to. No, I'm not going to read four pages of "information dense document" to figure out what you are trying to say when I don't even know what to look for. "IT ISN'T JUST THE PROCESSOR HARDWARE" is way to vague for me to go digging to support. Actually you said I should review "the architecture flyer" then add https://www.xmos.com/software/tools/. Sounds like a lot of digging to figure out what I am even supposed to be looking for. Either say it or don't. If you have nothing to say about your claim, I don't care. Actually, let's call this dead. You have gotten far too hostile over a simple matter. So much that your posts aren't even fully coherent. Signing off. -- Rick C. -+++ Get 1,000 miles of free Supercharging -+++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-04-20 11:01 +0100 |
| Message-ID | <MpenG.49873$Jj2.9049@fx11.am4> |
| In reply to | #29527 |
On 20/04/20 08:33, Rick C wrote: > On Monday, April 20, 2020 at 2:46:34 AM UTC-4, Tom Gardner wrote: >> On 20/04/20 04:32, Rick C wrote: >>> On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote: >>>> On 19/04/20 22:47, Rick C wrote: >>>>> One application the company talks about is for a hearing aid. It >>>>> used new theories of how we hear to improve hearing for people what >>>>> traditional "filtered" amplifiers don't work. >>>> >>>> If true, that marks them as being completely unrealistic. >>>> >>>> The chances of some softies coming up with novel valid hearing aid >>>> algorithms without having previous experience is effectively zero. >>>> >>>> Even if they had, the chances of getting one of their chips into an >>>> ear canal are effectively zero. >>> >>> There you go, proving my point of mindset, over and over. >> >> What are you on about? >> >> That point has nothing whatsoever to do with XMOS! > > You are uniquely obsessed with XMOS. The quoted conversation is about the > GA144. Why are you bringing XMOS into it??? The same reason you bang on about the GA144 and Forth: they are different to the usual run-of-the-mill processors. Besides, you don't own the thread and several other processors have been mentioned. > You are making assertions about a design team that you know nothing about > being unable to be innovative in a useful way on a product you know nothing > about. Learn to read and comprehend: which bit of "if true..." did you not understand? > Then you talk about not being able to put a chip in an ear canal as if that > was the only way to use a hearing aid. As someone that wears a BTE hearing aid and will soon be eligible for a cochlea implant, I know how little most people understand about hearing aids - and the key points to force them to think about the practicalities. >>> No, I don't care enough about the XMOS to read more of their marketing >>> docs. If you have a point to make, either make it or not. I don't care. >> >> So why did you write elsewhere?... >> >> On 19/04/20 23:02, Rick C wrote:> I think this conversation has come to an >> end. You made a claim that does not >>> fit with what I know about the XMOS. If that claim is in the >>> documentation, just provide a reference. I'm not going to wade through a >>> bunch of docs to research YOUR claim. >> >> I provided a reference to a 4 page information dense document. Your refusal >> to read a indicates that /you/ are the one with the mindset that you are >> not prepared to change! >> >> Yes, I and others have read the GAL document, thought about how to use it, >> and chosen not to. > > No, I'm not going to read four pages of "information dense document" to > figure out what you are trying to say when I don't even know what to look > for. "IT ISN'T JUST THE PROCESSOR HARDWARE" is way to vague for me to go > digging to support. Actually you said I should review "the architecture > flyer" then add https://www.xmos.com/software/tools/. Sounds like a lot of > digging to figure out what I am even supposed to be looking for. Either say > it or don't. If you have nothing to say about your claim, I don't care. There would be no point saying anything since you have clearly and explicitly stated you won't listen and can't be bothered to do your own research. That is ironic coming from someone that complains that other people have fixed mindsets!
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-04-20 17:44 +0200 |
| Message-ID | <r7kg1i$am7$1@dont-email.me> |
| In reply to | #29520 |
On 19/04/2020 23:47, Rick C wrote: > I agree that the GA144 finds very few sockets when the entire package > is considered. But the problem is not because the multiprocessing is > not an easy way to do multitasking. I don't want to go through the whole post, because the thread is getting long and time-consuming. (I'm reading all your posts - but practical considerations are against my replying to everything.) I agree that multiprocessing is a viable technique, and not necessarily harder than other ways of solving problems. However, I don't think it is necessarily easier than multitasking on one (or a few) cores. I agree that the hardware of this chip is interesting, and has some smart and efficient ideas - and from a purely hardware perspective, it could be a very good choice in a number of types of application. I believe there are two key issues with the GA144 that outweigh the hardware itself or the learning and alternative thinking needed to make use of a multi-processor design. One is the company - their size, their attitude, their documentation, their support, etc. You've mentioned several of these yourself. The other is the software tools. I haven't tried them, but I've read several of their application notes and information about them. Either the company have done an amazingly bad job of showing them, or they are the biggest pile of **** I've seen this century. And I have seen (and used) some really bad tools over the years. Even if both these points were fixed - they had a live and active company that understood customers and their needs, and had realised that most developers have access to a modern computer and don't need a development environment that runs from a floppy disk, there would still be a huge obstacle to overcome - almost no developers use Forth. Any large enough embedded development department is going to have people with FPGA experience. Finding new employees to build up FPGA competence is not much harder than finding new experts in embedded software - and there are plenty of consulting companies ready to help. But for Forth, how many programmers are there? How many will not have retired in the next 10 years? Of course any programmer can /learn/ Forth. But what company would invest in that? Even assuming a new toolchain for the GA144 based on modern ANS Forth rather than weird experimental (and dead) colorForth, you are talking about a great deal of investment for a very narrow use-case. It is certainly possible that this would be the right decision. But my point is that it would take an outstanding "killer application" to make it worth doing. I suspect the whole thing would be better off if a new toolset were made with a completely different language - even if that language were invented specifically. Drop Forth (or is that "Forth DROP" ?) and make a modern language at a higher level, with a strong emphasis on multi-processing, data passing and synchronisation (CSP-style, unless someone thinks of anything better), with optimising tools handling the distribution around the chip. Then at least someone using the chip could feel they are investing in the future, rather than something that views colour screens as a cool new invention. (I wonder if "Go" would be a good fit? I don't know much about Go, but I do know it has an emphasis on many small minimal overhead threads and CSP-style communication.) > >> XMOS takes a bit of changed ideas and some new ways of thinking to get >> the best from them. But the (virtual) cores are solid devices, >> programmed in decent modern languages (after some very frustrating >> limitations in their early days) with a good IDE and tools, and a large >> community of users well supported by the company. There are some things >> about the chips that I think are downright silly limitations, and I >> think a bit less "purism" would help, but they are a world apart from >> the GA144. > > Yes, too bad the XMOS is the best solution in only a tiny part of the market. XMOS is a viable company with a solid community and plenty of customers. It's small compared to other microcontroller designs - but it is a world ahead of GA144. > >> Still, there are devices from Efinix (I know almost nothing about the >> company) and Lattice for a dollar or so. Yes, these are fine-pitch BGA >> packages, but the range of companies that can handle these is much >> greater than it used to be (even if it is by outsourcing the board >> production). > > Lattice has some more "friendly" packages for their low end parts. As soon as I have a need I expect to be using one. Currently they don't do anything better (that I need) than the 10+ year old part I'm currently using. > > Lattice is always on my radar because they are the only company who seems to be taking the low end seriously. > Nice to know. Do you know anything about Efinix?
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-20 19:57 -0700 |
| Message-ID | <7439764e-f907-4c36-919d-f0e169042517@googlegroups.com> |
| In reply to | #29543 |
On Monday, April 20, 2020 at 11:44:53 AM UTC-4, David Brown wrote: > On 19/04/2020 23:47, Rick C wrote: > > > I agree that the GA144 finds very few sockets when the entire package > > is considered. But the problem is not because the multiprocessing is > > not an easy way to do multitasking. > I don't want to go through the whole post, because the thread is getting > long and time-consuming. (I'm reading all your posts - but practical > considerations are against my replying to everything.) I agree and I wasn't going to reply until I saw something about tools on a floppy disk, whaaat??? > I agree that multiprocessing is a viable technique, and not necessarily > harder than other ways of solving problems. However, I don't think it > is necessarily easier than multitasking on one (or a few) cores. I'm sure there are examples that are easier both ways. But in general using a processor for each process frees up the programming problem in many ways. I recall many years ago the US Navy wanted a common signal processor and so created the EMSP program (Enhanced Modular Signal Processor). Part of the program was a new language, ECOS (don't ask me what that stands for, ok I looked it up... "EMSP Common Operational Software Support Methodology"). Is there a rule about abbreviations in abbreviations? It was a data flow language and was intended to be programmed graphically. I think there are similar tools for signal processing and even general programming. Any of these tools could be used for designing tasks to be assigned to individual processors in a very simple manner. TI and ADI have simple signal processors that are programmed this way. It isn't multitasking as such, but the point is it could be and the tools make it very simple. > I agree that the hardware of this chip is interesting, and has some > smart and efficient ideas - and from a purely hardware perspective, it > could be a very good choice in a number of types of application. > > I believe there are two key issues with the GA144 that outweigh the > hardware itself or the learning and alternative thinking needed to make > use of a multi-processor design. > > One is the company - their size, their attitude, their documentation, > their support, etc. You've mentioned several of these yourself. That's not really what this discussion is about. It started as CPU cores on FPGAs and was diverted to XMOS which brought in the GA144. I don't care about pros and cons of the GA144 for any particular user or application. I was discussing the limitations of the XMOS with its very limited number of CPUs and it's high price. > The other is the software tools. I haven't tried them, but I've read > several of their application notes and information about them. Either > the company have done an amazingly bad job of showing them, or they are > the biggest pile of **** I've seen this century. And I have seen (and > used) some really bad tools over the years. The tools are very bad in the context of the amazingly complex tools in use today by the amazingly complex systems. > Even if both these points were fixed - they had a live and active > company that understood customers and their needs, and had realised that > most developers have access to a modern computer and don't need a > development environment that runs from a floppy disk, There! What are you talking about with a floppy disk??? I have/had the tools running on my PC (I don't think they were ported at the last laptop upgrade). I don't have a floppy. > there would still > be a huge obstacle to overcome - almost no developers use Forth. There is the mindset issue. I know people have so many reasons why they can't use Forth. Once in a larger company I had put in the budget money to buy a commercial Forth system for use in bringing up the hardware I was building. When time came to buy it, the program manager said no. No reason other than he didn't know what it was. I ended up letting the software guys worry about verifying the hardware. Fortunately they never found any real bugs. lol > Any > large enough embedded development department is going to have people > with FPGA experience. Finding new employees to build up FPGA competence > is not much harder than finding new experts in embedded software - and > there are plenty of consulting companies ready to help. But for Forth, > how many programmers are there? How many will not have retired in the > next 10 years? You can be a Forth programmer in a day, a not too bad Forth programmer in a week. I know, nobody believes that, but it's true. In other words, the only problem with training all your software people to use Forth is just getting them to forget all the stuff they already know. Much easier to teach your FPGA people. > Of course any programmer can /learn/ Forth. But what company would > invest in that? Even assuming a new toolchain for the GA144 based on > modern ANS Forth rather than weird experimental (and dead) colorForth, > you are talking about a great deal of investment for a very narrow use-case. > > It is certainly possible that this would be the right decision. But my > point is that it would take an outstanding "killer application" to make > it worth doing. So what is the point of all this? The discussion was about the concepts involved in programming with multiple processors. How did it turn into a slamfest on GA? > I suspect the whole thing would be better off if a new toolset were made > with a completely different language - even if that language were > invented specifically. Drop Forth (or is that "Forth DROP" ?) and make > a modern language at a higher level, with a strong emphasis on > multi-processing, data passing and synchronisation (CSP-style, unless > someone thinks of anything better), with optimising tools handling the > distribution around the chip. If you drop Forth as the programming language you lose a lot of what makes the GA144 easy to use. The native language of the chip is much like Forth. But that's ok. Most people already know too much to ever learn why Forth is useful. > Then at least someone using the chip could feel they are investing in > the future, rather than something that views colour screens as a cool > new invention. Again, what is that about??? Color is used in virtually every editor around. Why is it something to knock in the tools for the GA144? Are you aware that Chuck Moore developed colorForth in the 90's? So it's not new. He also wrote a CAD program called OKAD that allowed him to design digital devices from the ground up. The two evolved together. That's when the tools were on a floppy, because they didn't run under an OS, they took over the computer and booted Forth from disk. Part of the reason why he designed his own tools is because the existing tools told him a design would not work which he then built and used! So why is color in a tool suddenly something to make fun of? I think you are making fun of the marketing. Show me a company that doesn't have marketing worthy of being made fun of! > (I wonder if "Go" would be a good fit? I don't know much about Go, but > I do know it has an emphasis on many small minimal overhead threads and > CSP-style communication.) I think you don't like the language and tools because you are too accustomed to having tools do so much thinking for you. That's great if they do a good job of it. I've yet to find one that did for multiprocessing. With 144 cores manual task design is not a problem. > >> XMOS takes a bit of changed ideas and some new ways of thinking to get > >> the best from them. But the (virtual) cores are solid devices, > >> programmed in decent modern languages (after some very frustrating > >> limitations in their early days) with a good IDE and tools, and a large > >> community of users well supported by the company. There are some things > >> about the chips that I think are downright silly limitations, and I > >> think a bit less "purism" would help, but they are a world apart from > >> the GA144. > > > > Yes, too bad the XMOS is the best solution in only a tiny part of the market. > > XMOS is a viable company with a solid community and plenty of customers. > It's small compared to other microcontroller designs - but it is a > world ahead of GA144. I never said it wasn't a viable company. I said the chips are the best solution for only a tiny part of the market. Is that not true? I see revenues of 8 million pounds in 2018. That's pretty small for a chip company. A long way behind even Lattice, an also ran FPGA company. They can't be selling many chips with only 8 million revenue. > >> Still, there are devices from Efinix (I know almost nothing about the > >> company) and Lattice for a dollar or so. Yes, these are fine-pitch BGA > >> packages, but the range of companies that can handle these is much > >> greater than it used to be (even if it is by outsourcing the board > >> production). > > > > Lattice has some more "friendly" packages for their low end parts. As soon as I have a need I expect to be using one. Currently they don't do anything better (that I need) than the 10+ year old part I'm currently using. > > > > Lattice is always on my radar because they are the only company who seems to be taking the low end seriously. > > > > Nice to know. > > Do you know anything about Efinix? I've looked at them, I think I even exchanged some email with them. There are maybe four new FPGA companies suddenly (at least three in China, Anlogic, AGM and Gowin). I'm guessing some essential patents expired. Efinix is another one. I'm waiting for them to have product on the shelves someplace, preferably like Digikey. The only unique feature seems to be their "patented Quantum™ architecture" which appears to be the sort of thing where logic and routing are interchangeable which means you can't use as much logic as they claim because a lot of it has to be used for routing. Not sure. What interests you about them? I'm looking at Gowin pretty hard. They have some with a CPU, but their product line isn't filled out yet. Also some parts have pSRAM and/or DRAM die in the package. They are first introducing parts that customers are asking for of course. They aren't very good at indicating which parts are currently available, but they do have salesmen who will communicate with you. Many startups only want to talk to the big fish. -- 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-21 18:02 +0200 |
| Message-ID | <r7n5eq$oji$1@dont-email.me> |
| In reply to | #29558 |
On 21/04/2020 04:57, Rick C wrote: > On Monday, April 20, 2020 at 11:44:53 AM UTC-4, David Brown wrote: >> On 19/04/2020 23:47, Rick C wrote: >> Do you know anything about Efinix? > > I've looked at them, I think I even exchanged some email with them. There are maybe four new FPGA companies suddenly (at least three in China, Anlogic, AGM and Gowin). I'm guessing some essential patents expired. Efinix is another one. I'm waiting for them to have product on the shelves someplace, preferably like Digikey. > > The only unique feature seems to be their "patented Quantum™ architecture" which appears to be the sort of thing where logic and routing are interchangeable which means you can't use as much logic as they claim because a lot of it has to be used for routing. Not sure. > > What interests you about them? Nothing in particular - it's just in the discussions about FPGA's and costs, I looked at Digikey's FPGA offerings sorted by price, and one of their devices was the cheapest of all. I'd never heard of them. > > I'm looking at Gowin pretty hard. They have some with a CPU, but their product line isn't filled out yet. Also some parts have pSRAM and/or DRAM die in the package. They are first introducing parts that customers are asking for of course. They aren't very good at indicating which parts are currently available, but they do have salesmen who will communicate with you. Many startups only want to talk to the big fish. >
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-04-21 14:56 -0700 |
| Message-ID | <94f249f2-febd-45f9-a937-ea5a8f6ff3f7@googlegroups.com> |
| In reply to | #29570 |
On Tuesday, April 21, 2020 at 12:02:37 PM UTC-4, David Brown wrote: > On 21/04/2020 04:57, Rick C wrote: > > On Monday, April 20, 2020 at 11:44:53 AM UTC-4, David Brown wrote: > >> On 19/04/2020 23:47, Rick C wrote: > > >> Do you know anything about Efinix? > > > > I've looked at them, I think I even exchanged some email with them. There are maybe four new FPGA companies suddenly (at least three in China, Anlogic, AGM and Gowin). I'm guessing some essential patents expired. Efinix is another one. I'm waiting for them to have product on the shelves someplace, preferably like Digikey. > > > > The only unique feature seems to be their "patented Quantum™ architecture" which appears to be the sort of thing where logic and routing are interchangeable which means you can't use as much logic as they claim because a lot of it has to be used for routing. Not sure. > > > > What interests you about them? > > Nothing in particular - it's just in the discussions about FPGA's and > costs, I looked at Digikey's FPGA offerings sorted by price, and one of > their devices was the cheapest of all. I'd never heard of them. There's something odd about the pricing. The $1 part is a T4F49C2 at qty 5,000. The T4F81C2 is $4.50 at the same qty. The only difference is the package with 49 balls/33 I/Os vs. 81 balls/59 I/Os. Double the number of I/Os and get a 4x price increase with the same die??? My main concern with their parts is the talk of logic and routing being a tradeoff. So how many logic elements of the 3888 available are typically usable? Until I know that I can't even estimate design issues in my head. I guess the way to answer that question is to try a design in their tools. I have a design using over 80% of a 3,072 LUT4 device. I could try using that in the T4F part and see if it fits. It's a lot of files as I tried to make many smaller modules to get fine grain testing. Or maybe I'll construct a 1 file test case with some sort of generated logic in just a few lines. Trouble is the routing issue. The design needs to have a typical amount of routing since the purpose of this is to see how much logic is taken away to perform the routing. My 80%, 3k LUT design may end up needing the 8k Efinix or even the 13k part. Who knows? They also don't have packages I like. That's the FPGA story of my life. Gowin has some potential offering good packages, but I don't know when they will have the goldilocks combination available (package and features like a CPU). They are sold by Edge in the US who has a crappy web site. Digikey/Mouser are soooo much better. -- Rick C. ---+- Get 1,000 miles of free Supercharging ---+- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | Theo <theom+news@chiark.greenend.org.uk> |
|---|---|
| Date | 2020-04-17 16:34 +0100 |
| Message-ID | <wrB*GmNPx@news.chiark.greenend.org.uk> |
| In reply to | #29469 |
Paul Rubin <no.email@nospam.invalid> 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. I think part of the problem is the ARM licensing cost - if the license cost is (random number) 5% of the silicon sticker price that's fine when it's a $1 MCU, but when it's a $10000 FPGA that hurts. I understand all the Stratix 10 parts have the Cortex A53 on there but the licence fee is only paid when the ARM core is enabled. This explains why the SX versions of the FPGA are (or were initially) much harder to get hold of, because nobody wants to pay extra. RISC-V is likely to change this, because the licence costs can now be zero. However the additional question is what kind of core: there isn't a lot to be gained putting a 3-stage pipeline core in hard logic - it'll be small but the clock won't be very high, and the area is wasted for someone who doesn't need it. If you're interested in a high clock it gets more complex and starts dragging in caches etc - starts looking more like an application core. At which point you might as well pull in an MMU and have it run Linux, but then you need external memory, I/O and storage too. I think it would be hard for the synthesis toolchains to make good use of a CPU core, but there is value in having them there to be specially programmed, like SERDES or FPU blocks. Theo
[toc] | [prev] | [next] | [standalone]
Page 5 of 8 — ← Prev page 1 2 3 4 [5] 6 7 8 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web