Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29515

Re: Custom CPU Designs

Show all headers | View raw

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).

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web