Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29520
| Newsgroups | comp.arch.embedded |
|---|---|
| Date | 2020-04-19 14:47 -0700 |
| References | (5 earlier) <878sivdl56.fsf@nightsong.com> <83042f0d-e68a-479d-bb67-d2d635ca60d4@googlegroups.com> <r7bnri$pf$1@dont-email.me> <bdee508d-74fd-44e4-a821-12834f31564f@googlegroups.com> <r7i6mc$8o1$1@dont-email.me> |
| Message-ID | <4429be4e-964c-47b3-9a55-252ebdc26544@googlegroups.com> (permalink) |
| Subject | Re: Custom CPU Designs |
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
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
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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