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

Groups > comp.arch.embedded > #29500

Re: Custom CPU Designs

Show all headers | View raw

On 18/04/20 14:06, David Brown wrote:
> On 17/04/2020 18:49, Tom Gardner wrote:
>> On 17/04/20 17:15, David Brown wrote:
>>> On 17/04/2020 16:23, Tom Gardner wrote:
>>>> On 17/04/20 14:44, David Brown wrote:
>>>>> On 17/04/2020 11:49, Tom Gardner wrote:
>>>>>> On 17/04/20 09:02, David Brown wrote:
>>>
>>>>>> As you say, the XMOS /ecosystem/ is far more compelling,
>>>>>> partly because it has excellent /integration/ between the
>>>>>> hardware, the software and the toolchain. The latter two
>>>>>> are usually missing.
>>>>>
>>>>> Agreed.  And the XMOS folk have learned and improved.  With the first 
>>>>> chips, they proudly showed off that you could make a 100 MBit Ethernet 
>>>>> controller in software on an XMOS chip.  Then it was pointed out to them 
>>>>> that - impressive achievement though it was - it was basically useless 
>>>>> because you didn't have the resources left to use it for much, and hardware 
>>>>> Ethernet controllers were much cheaper.  So they brought out new XMOS chips 
>>>>> with hardware Ethernet controllers.  The same thing happened with USB.
>>>>
>>>> It looks like a USB controller needs ~8 cores, which isn't
>>>> a problem on a 16 core device :)
>>>>
>>>
>>> I've had another look, and I was mistaken - these devices only have the USB 
>>> and Ethernet PHYs, not the MACs, and thus require a lot of processor power, 
>>> pins, memory and other resources.  It doesn't need 8 cores, but the whole 
>>> thing just seems so inefficient.  No one is going to spend the extra cost for 
>>> an XMOS with a USB PHY, so why not put a hardware USB controller on the 
>>> chip?  The silicon costs would surely be minor, and it would save a lot of 
>>> development effort and release resources that are useful for other tasks.  
>>> The same goes for Ethernet. Just because you /can/ make these things in 
>>> software on the XMOS devices, does not make it a good idea.
>>
>> Oh I agree! However, being able to do it in software is a
>> good demonstration of the device's unique characteristics,
>> and that "you aren't in Kansas anymore"
>>
> 
> Indeed.
> 
> The real power comes from when you want to do something that is /not/ standard, 
> or at least not common.
> 
> Implementing a standard UART in a couple of XMOS cores is a pointless waste of 
> silicon.  Implementing a UART that uses Manchester encoding for the UART signals 
> so that you can use it on a balanced line without keeping track of which line is 
> which - /then/ you've got something that can be done just as easily on an XMOS 
> and is a big pain to do on a standard microcontroller.
> 
> Implementing an Ethernet MAC on an XMOS is pointless.  Implementing an EtherCAT 
> slave is not going to be much harder for the XMOS than a normal Ethernet MAC, 
> but is impossible on any microcontroller without specialised peripherals.

Agreed.



>>> Overall, the thing that bugs me about XMOS is that you can write very simple, 
>>> elegant tasks for the cores to do various tasks.  But when you do that, you 
>>> run out of cores almost immediately.  So you have to write your code in a way 
>>> that implements your own scheduler, losing a major part of the point of the 
>>> whole system.  Or you use the XMOS FreeRTOS port on one of the virtual cores 
>>> - in which case you could just switch to a Cortex-M microcontroller with 
>>> hardware USB, Ethernet, PWM, UART, etc. and a fraction of the price.
>>
>> I didn't know they had a FreeRTOS port, and it sounds
>> like having a dog and barking :) Sounds like it would
>> combine the disadvantages and negate the advantages!
>>
> 
> Some real-time stuff needs microsecond or sub-microsecond precision - XMOS lets 
> you do that in software on a core, while normally you'd do it in dedicated 
> peripherals on a microcontroller.  But a lot needs millisecond or sub-second 
> precision, and FreeRTOS is absolutely fine for that.  (As are other methods, 
> such as software timers.)
> 
>> Having said that, they did have a chip where one of the
>> processors was an ARM. Perhaps it was intended that the
>> ARM run FreeRTOS?
> 
> I haven't seen such a chip.  Do you have a link?  It could be an interesting 
> device.

Not offhand, and I don't think it is made anymore.

I pegged it as "seems nice at first glance, but
/two/ toolchains and what are the limitations on
the ARM?" -- and decided I didn't want to bother.



>>> If the XMOS devices and software had a way of neatly multi-tasking /within/ a 
>>> single virtual core, while keeping the same kind of inter-task communication 
>>> and other benefits, then they would have something I could see being very nice.
>>
>> There is a half-way house.
>>
>> If you adopt a certain coding style, the IDE will combine
>> several processes to run on a single processor.
>>
>> Basically it is equivalent to appending all the process'
>> "startup" code into a single block, and all the "forever
>> loop" code into a single block. The key bit is combining
>> all the process' select statements into as single select
>> statement.
>>
>> With that understanding, the coding style requirements
>> become obvious, not onerous, and they are checked by the
>> compiler.
> 
> I understand the principle, but you'd lose some of the modularity here. How well 
> does it work if you want to have your UART, your CAN, your PWM, etc., defined in 
> different files - and then you want to put them on the same core?  I guess it 
> will be possible.

Yup, see bottom of post, and for a different optimisation:
distributable functions.



>>>> To me a large part of the attraction is that you can
>>>> /predict/ the /worst/ case latency and jitter (and hence
>>>> throughput), in a way that is difficult in a standard MCU
>>>> and easy in an FPGA.
>>>
>>> For standard MCU's, you aim to do this by using hardware peripherals (timers, 
>>> PWM blocks, communication controllers, etc.) for the most timing-critical 
>>> stuff.  Then you don't need it in the software.
>>
>> Yebbut, the toolset won't analyse and predict worst case
>> performance. So you are back to "run it and hope we stumble
>> upon the worst case".
>>
> 
> The peripherals are independent, and specified in documentation.  If the PWM 
> timer block can do 16-bit precision at 120 MHz, then you know its limits - and 
> it doesn't matter how many UARTs you use or how fast you want your SPI bus to 
> run.  You don't need to analyse the timings - that was done when the chip was 
> designed.
> 
> You need to check the speeds of your high-level software that uses the modules, 
> but that applies to XMOS code too.
> 
>> Yes, that is sufficient in many cases, but it is /inelegant/,
>> dammit!
>>
> 
> There is always room for improvement and extra tools!

And that's recursive, iterative and fractal, and probably
another few woo-words as wwell :)


>>>> To that extent it allows FPGA-like performance with "traditional"
>>>> software development tools and methodologies. Plus a little
>>>> bit of "thinking parallel" that everybody will soon /have/ to
>>>> be doing :)
>>>
>>> It's a nice idea, and I'm sure XMOS has some good use-cases.  But I can't 
>>> help feeling they have something that is /almost/ a good system - with a bit 
>>> more, they could be very much more useful.
>>
>> There's no doubt it is niche.
>>
>> The world will go parallel. A major difficulty will be finding
>> people that can think that way. (Just look at how difficult
>> softies find it when they try to "program" VHDL/Verilog)
>>
>> We need all the tools and concepts we can muster; my fear
>> is that CSP is the best! :)
> 
> I'd like a good way to do CSP stuff in C or C++.  I've been looking at passing 
> std::variant types in message queues in FreeRTOS, but I'm not happy with the 
> results yet.  I think I'll have to make my own alternative to std::variant, to 
> make it more efficient for the task.

It always amazed me that Boehm had to write his paper
indicating that you couldn't write threads as a library.
I presume that is not longer the case.


> If I ever get time, I will dig out my old XMOS kit and see how the current tools 
> are looking.  If I can find a neat way to get your "half-way house" system 
> working, it will increase a good deal in its attractiveness for me.

 From my copy of The Programming Guide version F (there
may be a later variant).

That guide has the usual succinct and relevant examples
and pictures illustrating what is happening. If only
all documentation was as short and sweet.

*2.3 Creating tasks for flexible placement*

xC programs are built up from several tasks running in
parallel. These tasks can be of several different types
that can be used in different ways. The following [table]
shows the different types:

Normal tasks run on a logical core and run independently
to other tasks. The tasks have predictable running time
and can respond very efficiently to external events.

Combinable tasks can be combined to have several tasks
running on the same logical core. The core swaps context
based on cooperative multitasking between the tasks driven
by the compiler.

Distributable tasks can run over several cores, running
when required by the tasks connected to them. Using
these different tasks types you can maximize the resource
usage of the device depending on the form and timing
requirements of your tasks.

*2.3.1 Combinable functions*
If a tasks ends in an never-ending loop containing a
select statement, it represents a task that continually
reacts to events:
void task1 ( args ) {
  .. initialization ...
  while (1) {
   select {
    case ... :
     break ;
    case ... :
     break ;
    ...
   }
  }
}

If a function complies to this format then it can be marked
as combinable by adding the combinable attribute:
[[ combinable ]]

*2.3.2 Distributable functions*
Sometime tasks contain state and provide services to other tasks,
but do not need to react to any external events on their own.
These kinds of tasks only run any code when communicating with
other tasks. As such they do not need a core of their own but
can share the logical cores of the tasks they communicate with
(as shown in Figure 12).
More formally, a task can be marked as distributable if:
  - It satisfies the conditions to be combinable (i.e. ends
    in a never-ending loop containing a select)
  - The cases within that select only respond to interface
    transactions
...
A distributable task can be implemented very efficiently if
all the tasks it connects to are on the same tile. In this
case the compiler will not allocate it a logical core of
its own.

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