Custom CPU Designs

David Brown <david.brown@hesbynett.no> writes:
> Your posts in this thread have renewed my interest in XMOS.  If XMOS
> run a pyramid scheme for evangelism, you have definitely earned
> yourself a few more brownie points.

Do you know about the Parallax Propeller and the newer Propeller 2?  It
is another one of those "hub and cog" designs where there are a bunch of
peripheral processors connected to a central one.  You can use the
peripheral processors to drive individual i/o pins, like with the GA144
and apparently like with XMOS.  There is an on-chip crossbar or
something of that sort, that allow you to connect the internal
processors to external pins any way you want.

On 20/04/20 22:32, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> Your posts in this thread have renewed my interest in XMOS.  If XMOS
>> run a pyramid scheme for evangelism, you have definitely earned
>> yourself a few more brownie points.
> 
> Do you know about the Parallax Propeller and the newer Propeller 2?  It
> is another one of those "hub and cog" designs where there are a bunch of
> peripheral processors connected to a central one.  You can use the
> peripheral processors to drive individual i/o pins, like with the GA144
> and apparently like with XMOS.  There is an on-chip crossbar or
> something of that sort, that allow you to connect the internal
> processors to external pins any way you want.

I remember looking at it in the past, and thinking it looked
like a few "boring" cores bolted together. There have been
many such devices over the decades. The programming languages
and tools are bog-standard, and aren't built with hardware
parallelism as a core feature.

The attraction (to me) of the XMOS devices was that the
hardware and software and tools were designed to be highly
parallel, and to interwork smoothly, cleanly and without
"random" barriers between them.

Parallel hardware is easy. Changing the software and
mindset away from single thread sequential program
execution has been harder than desirable.

On Monday, April 20, 2020 at 8:59:36 AM UTC-4, Clifford Heath wrote:
> On 20/4/20 4:52 am, Przemek Klosowski wrote:
> > On Thu, 16 Apr 2020 17:13:41 -0700, 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.
> > 
> > Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB
> > and LLVM have Risc-V backends already for a while), and the simple
> > versions take very few gates.
> > https://github.com/SpinalHDL/VexRiscv
> > https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/
> > 
> 
> There's a lot of push in the direction of the Power architecture. What 
> does that look like in FPGA?
> 
> CH

Do you mean the Power PC?  That was the hard IP used in the very old and possibly obsolete Virtex II Pro devices.  

Why do they have to use such goofy names like "Pro" or "Polarfire".  Do they really think that sells even one frigging chip?  I would be so much more inclined to dig through their information if they just had decent names that give you some idea of the technical details including the heritage.  

-- 

  Rick C.

  +--- Get 1,000 miles of free Supercharging
  +--- Tesla referral code - https://ts.la/richard11209

On 21/4/20 10:01 am, Rick C wrote:
> On Monday, April 20, 2020 at 8:59:36 AM UTC-4, Clifford Heath wrote:
>> On 20/4/20 4:52 am, Przemek Klosowski wrote:
>>> On Thu, 16 Apr 2020 17:13:41 -0700, 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.
>>>
>>> Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB
>>> and LLVM have Risc-V backends already for a while), and the simple
>>> versions take very few gates.
>>> https://github.com/SpinalHDL/VexRiscv
>>> https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/
>>>
>>
>> There's a lot of push in the direction of the Power architecture. What
>> does that look like in FPGA?
>>
>> CH
> 
> Do you mean the Power PC?  That was the hard IP used in the very old and possibly obsolete Virtex II Pro devices.
> 
> Why do they have to use such goofy names like "Pro" or "Polarfire".  Do they really think that sells even one frigging chip?  I would be so much more inclined to dig through their information if they just had decent names that give you some idea of the technical details including the heritage.

Hah! I hear you. :)

Yes, I mean PowerPC, specifically OpenPoWER:
<https://en.wikipedia.org/wiki/OpenPOWER_Foundation>

A friend is a fan. Me, I haven't read much about it.

CH

On Monday, April 20, 2020 at 7:01:52 PM UTC-5, Rick C wrote:
> On Monday, April 20, 2020 at 8:59:36 AM UTC-4, Clifford Heath wrote:
> > On 20/4/20 4:52 am, Przemek Klosowski wrote:
> > > On Thu, 16 Apr 2020 17:13:41 -0700, 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.
> > > 
> > > Maybe Risc-V will catch on. The design is FOSS, as is the toolchain (GDB
> > > and LLVM have Risc-V backends already for a while), and the simple
> > > versions take very few gates.
> > > https://github.com/SpinalHDL/VexRiscv
> > > https://hackaday.com/2019/11/19/emulating-risc-v-on-an-fpga/
> > > 
> > 
> > There's a lot of push in the direction of the Power architecture. What 
> > does that look like in FPGA?
> > 
> > CH
> 
> Do you mean the Power PC?  That was the hard IP used in the very old and possibly obsolete Virtex II Pro devices.  
> 
> Why do they have to use such goofy names like "Pro" or "Polarfire".  Do they really think that sells even one frigging chip?  I would be so much more inclined to dig through their information if they just had decent names that give you some idea of the technical details including the heritage.  
> 
> -- 
> 
>   Rick C.
> 
>   +--- Get 1,000 miles of free Supercharging
>   +--- Tesla referral code - https://ts.la/richard11209

|>Do you mean the Power PC?  That was the hard IP used in the very old and
|> possibly obsolete Virtex II Pro devices. 

Also on Virtex-4 (90nm) and Virtex-5 (65nm & six input LUTs)

|>goofy names like "Pro" or "Polarfire"

in an industry full of hyperbola why exclude a niche player:
"28nm non-volatile process yields very low static power"

On Monday, April 20, 2020 at 9:58:09 AM UTC-4, David Brown wrote:
> On 18/04/2020 21:38, Rick C wrote:
> > On Saturday, April 18, 2020 at 9:06:57 AM UTC-4, David Brown wrote:
> >> 
> >> 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.
> > 
> > I take your point even if I don't agree with your example.
> > 
> > I don't follow your comment about "which line is which".  Manchester
> > encoding uses the polarity of transitions for the data being
> > transmitted.  To set up for the correct polarity data transition
> > there are extra transitions which should be ignored.  To properly
> > decode the data requires having the correct polarity of the signal at
> > the input.  Swap lines and you get wrong data.
> 
> Sorry, it is /differential/ Manchester encoding that is polarity 
> independent.  But as you say, it is the principle of the point that 
> matters, rather than the details.

Ok, got it. 


> > It's not hard to receive Manchester encoded data on a typical MCU.
> > They virtually all have transition based interrupts on I/O pins.
> > Enable the interrupts and on each transition grab a timer value.  It
> > would even be easy to have it auto-baud rate detect as the values
> > should have two primary modes.  Why do you say this is a hard thing
> > to do???
> > 
> 
> Of course it can all be done in software on an MCU, using timers and 
> interrupts.  But the more timing-critical things you do in pure 
> software, the harder it gets to keep everything in specification in the 
> worst case.  The way the XMOS is built up with its IO ports connected to 
> timers and buffers, it's easy to make such features with extremely low 
> jitter - even if you have many of them at high speed.  And more 
> importantly, the way the software tools are designed it can check that 
> your code is within your specifications for this kind of thing.

That's interesting.  


> >> 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.
> > 
> > That is exactly the point of the MCU market, the huge variety of
> > combinations of hard peripherals available these days.  Nearly every
> > maker of MCUs will have an almost perfect match for your needs.
> 
> I need an MCU with 4 EtherCAT slave channels.  There are exactly 0 on 
> the market.  There are only two or three in total - from all 
> manufacturers together - with even /one/ EtherCAT slave.

Yes, because EtherCAT is not widely used at the moment.  I had never heard of it.  When I read about it I see some car makers are looking at adopting it.  Once that happens there will be MCUs supporting the interface.  Until then it is a niche market.  Am I wrong?  I don't see any indication there is much out there either in the supply or demand side. 


> If there were an XMOS EtherCAT slave peripheral, perhaps I could have 
> used one of their devices.  (There are FPGA EtherCAT cores available, 
> but the price of the cores, the price of the required FPGAs, and other 
> complications rule that out.)

Huh?  I'm not familiar with the details of EtherCAT.  Is this a rather complex protocol on a level with Ethernet?  

I haven't looked at core prices for FPGAs.  Is an Ethernet MAC expensive?  Is this something you can't design yourself?  Get me an adequate specification and I will give you a price estimate for a four channel EtherCAT interface in an FPGA.  

I'm not really sure of your point.  You are talking about a limitation of a new interface which is not supported in the market.  How does this have anything to do with any of the technologies involved? 


> > Peripherals may use some real estate on a chip, but the lion's share
> > is simply the memory.  These days MCU chips are more memory chips
> > with built in CPUs and peripherals than CPU chips.
> 
> I agree entirely, for "standard" peripherals.  But some peripherals are 
> too unusual to turn up on MCUs.  (There is, of course, not clear 
> definition of what a "standard peripheral" might be.)

That was exactly the reason I initially used an FPGA on the board I'm currently selling.  The customer had a custom control interface that was just enough different that an SPI could not be used and too fast to bit bang it.  The FPGA turned out to be fortunate because they came back later with other requirements that would also have been hard in a reasonable MCU. 

A GA144 would have been a good choice but not available at the time. 


> > So your point of adding an external Ethernet MAC to MCUs is a red
> > herring.
> > 
> > I just noticed you said "EtherCAT" which I was not aware of.  Seems
> > this is some other protocol than Ethernet.  
> 
> Ah, that explains things.
> 
> Roughly speaking, an EtherCAT slave takes Ethernet packets as they come 
> in, reads and writes to them as they go past, and sends the packets on 
> towards the next slave on the bus with the least possible delay (they do 
> not wait for the packet to be fully received).  The master side can run 
> on a normal Ethernet MAC, but the slave side requires special hardware.

So is this then a superset of the Ethernet MAC or a separate interface that then requires an Ethernet MAC for this same node? 


> > Ok, maybe that will be
> > just as easy on either type of MCU since it is a relatively niche
> > application.  Once the market grows you can be assured MCUs will be
> > commonly available with EtherCAT in hard peripherals.
> > 
> 
> EtherCAT has been around for a long time - it is not new.  But it is 
> quite niche.

New, not new.  Not relevant.  Newly received by a larger audience.  


> >> You need to check the speeds of your high-level software that uses
> >> the modules, but that applies to XMOS code too.
> > 
> > This is an area where FPGAs excel.  Timing is relatively easy to
> > verify and the details of coordinating the various processes is
> > trivial.
> > 
> 
> Yes, especially for the fine details.  But it gets harder again if there 
> can be a varying number of clock cycles in events.  You do have the big 
> advantage with FPGAs that timing of different parts is usually 
> independent, unlike on MCUs.
> 
> > It's an area where MCUs can be very difficult to analyze.
> > 
> 
> Absolutely.
> 
> You could say that XMOS devices and tools are a middle ground here.

Yes, I have mentioned before that XMOS sits in a small area where conventional CPUS are difficult, but the problem is still simple enough to run on the XMOS.  Outside of MCUs it isn't far to get to the point where only FPGAs will do the job easily. 

At least that's my experience.  I don't see XMOS taking many design wins from FPGAs or MCUs. 

You seem to be saying they haven't worked very often for you. 

-- 

  Rick C.

  +--+ Get 1,000 miles of free Supercharging
  +--+ Tesla referral code - https://ts.la/richard11209

On Monday, April 20, 2020 at 10:32:31 AM UTC-4, David Brown wrote:
> On 18/04/2020 23:21, Rick C wrote:
> > On Saturday, April 18, 2020 at 10:57:55 AM UTC-4, David Brown wrote:
> >> On 17/04/2020 19:48, Rick C wrote:
> >>> On Friday, April 17, 2020 at 12:15:37 PM UTC-4, 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.
> >>>> 
> >>>> 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.
> >>> 
> >>> Too bad the XMOS doesn't have more CPUs, like maybe 144 of them?
> >>> 
> >> 
> >> 144 cpus is far more than would be useful in practice - as long as
> >> you have cores that can do useful work in a flexible way (like XMOS
> >> cores). When you have very limited cores that can barely do
> >> anything themselves, you need lots of them.
> > 
> > The point of the XMOS concept is to not have to do multitasking on a
> > single core.  As soon as your task number exceeds the number of cores
> > you have to do multitasking on a single core.  No one ever complains
> > about having too many resources.
> 
> Agreed.  That is why I have been pleased to hear Tom's description of 
> how you can deal with multitasking within a core on XMOS, for when you 
> have more tasks than cores.
> 
> > 
> > The design process for many small CPUs is not the same as a few
> > larger CPUs.  
> 
> Agreed.
> 
> > But the point is it can be simpler, more like designing
> > hardware.
> 
> Disagreed.  Well, sort-of disagreed.
> 
> /Some/ things can be easier on small and simple cpus - other things are 
> harder.  But when a cpu is small enough and limited enough, almost 
> everything gets harder.
> 
> And no, hardware design is /not/ simpler.  It is /different/.

I very much disagree there... for most design work.  When you are designing something very complex it can be hard to do in hardware or software.  Those are the minority of designs, at least in my experience.  

I designed a test fixture in an FPGA that included a text based comms to control all the testing capabilities. 3,000 LUT device and still not full.  Could have been done in an MCU, but it would have been hard to meet all the speed requirements of synthesizing data, driving data out, receiving data, verifying data.  No, I was happy to use an FPGA for that.  Simulation was much easier with the FPGA too.  I am probably a bit behind on knowing the tools available, but how would you verify timing of the code to make all this work in any CPU in any language? 

I stand by my statement of hardware design being easier... with the qualification of not trying to do things that are inherently hard to do in hardware, like a TCP/IP stack. 


> > Atmel had an FPGA with a simple logic element equivalent to a 3 input
> > LUT and FF (done with a small number of gates rather than the larger
> > LUT structure).  It had relatively little routing, connecting logic
> > elements to adjacent logic elements almost as the only routing.  The
> > theory was the simplicity of the logic elements meant you could have
> > a lot more of them for a given amount of real estate/$$$ so you could
> > afford to use them for routing.  In practice they never kept up with
> > state of the art process technology, so this didn't pan out.  But
> > that is the concept of the many small cores.  You don't have to focus
> > on being highly efficient with your CPU resources since you have so
> > many.
> 
> You equate "having more of resource X than you need" with "it's easy". 
> That simply isn't the case.

That's not what I said.  I was addressing the comms issue in the GA144.  The Atmel device was similar, mostly comms to neighbors and using not so valuable resources for comms. i.e. different mindset. 


> It doesn't matter how many cpus you have if they can't do what you need 
> - or if it takes a ridiculous effort to make them do what you need.

The example designs by the GA group have been to illustrate that this is not a barrier.  People find the device hard to use because it requires a different manner of decomposing a design.  No, you can't implement a complex function in a single F18A CPU.  But you can't implement a complex function in a single code routine either.  At least everyone tells you not to in order to make it maintainable. 

If code can be modularized, it can be broken into separately executed units for the GA144.  Not rocket science, just different from what you are used to. 


> Ten thousand mice weigh less than a horse - they will eat less, provide 
> redundancy, and have a much higher combined strength.  Which do you 
> think is better for pulling a cart?

I use a truck.  Every application has an appropriate tool. 


> >> (Arguably that's what you have on an FPGA - lots of tiny bits that
> >> do very little on their own.  But the key difference is the tools -
> >> FPGA's would be a lot less popular if you had to code each LU
> >> individually, do placement manually by numbering them, and write a
> >> routing file by hand.)
> > 
> > Huh?  Why can't any of that be automated in the many CPU chip?
> 
> That's a very good question.  And if it /were/ automated for the GA144, 
> maybe it would be a much more useful chip.

You mean it would be a more useful development tool.  The GA144 would be no different. 

The problems with the GA144 don't come from a lack of automatic partitioning in the tools.  Many of them come from the limits of designers to think.  The guys in SED who design analog circuits do amazing things with the devices they use.  They would be right at home with partitioning a design across multiple small processors.  

That's the big advantage of a single, big, fast CPU, it makes the problem about having enough speed and then managing all the complexities of multitasking on a single processor, a problem that has been solved in the general case.  It's just the implementation details that can be difficult. 


> > Certainly the issue is not so important with only 144 processors, but
> > the same size chip would have many thousands of processors in a more
> > modern technology.  I think the GA144 is 180 nm.  Bring that down to
> > 15 nm and you have 15,000 nodes on a chip just 5 mm square!!!  That
> > will require better tools for sure.
> 
> Tools are critical.

With 15,000 CPUs, absolutely. 


> I think the biggest failing of the GA144 is the tools.  With a 
> completely different philosophy of toolset, maybe the device would 
> become a realistic and exciting new architecture.

I don't agree because the present state of the GA144 is such that there is no real problem with coding in the Forth provided and the partitioning problems are not so great with just 144 CPUs.  The problem is the blank slate issue really.  A new designer sits down to think of how to do a design in the chip and he has to figure it all out from ground zero.  The first few designs require multiple iterations I'm sure.  There aren't going to be automated tools for this chip.  We'll see if they have something new out the door before the doors close... not that it takes much to keep them open. 


> > Some of your use of language is interesting.  "lots of tiny bits that
> > do very little on their own".  That sounds like the way people write
> > software.  They decompose a large, complex design into lots of tiny
> > routines that individually do little on their own.  How can you
> > manage all that complexity???  Yes, I think the Zeno paradox must
> > apply so that no large program can ever be finished.  That certainly
> > happens sometimes.
> 
> In normal (serial, or multi-threaded) software, the programming language 
> you use lets you combine the bits.  It checks at least some aspects of 
> how they fit together, it lets you use the different bits from where you 
> want, it lets you split them up or combine them, write big bits and 
> small bits.  The same applies to FPGA design with Verilog, VHDL, or 
> higher level languages.

I never have trouble with partitioning designs.  It's the testing that is awkward.  In Forth I can test any function I want as soon as it is written.  In HDL I have to write a test bench for every module.  Tons of extra work. 


> The GA144 - judging from the application notes and examples - requires 
> you to figure out the tiniest details and split things up manually.  It 
> is a level of micromanagement beyond what is needed for assembly 
> programming.

Yes, but I'm not sure what you mean by "tiniest details".  Most programs just aren't that hard to write.  It's assembly code and a very simple one at that.  What were you thinking about when you looked at it?  


> It's the tools.

If you want it to be the tools for you, then it's the tools.  

For the people who designed the chip, they never felt the need for the tools to do the things you are describing.  I don't know much about parallel programming languages (other than HDL) but for the most part don't they require you to decide how to partition the design and set up tasks, etc.? 

While FPGA tools will do much of the work for you, they make a lot of really crappy decisions when it comes to placement.  They are only useful because there is a plethora of routing resources and most people don't care about optimization... until they do.  Then FPGAs can be a bit of a PITA.  But those designs are far beyond anything a CPU is capable of. 

-- 

  Rick C.

  +-+- Get 1,000 miles of free Supercharging
  +-+- Tesla referral code - https://ts.la/richard11209

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

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

On 4/21/20 5:32 AM, Paul Rubin wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> Your posts in this thread have renewed my interest in XMOS.  If XMOS
>> run a pyramid scheme for evangelism, you have definitely earned
>> yourself a few more brownie points.
> 
> Do you know about the Parallax Propeller and the newer Propeller 2?  It
> is another one of those "hub and cog" designs where there are a bunch of
> peripheral processors connected to a central one.  You can use the
> peripheral processors to drive individual i/o pins, like with the GA144
> and apparently like with XMOS.  There is an on-chip crossbar or
> something of that sort, that allow you to connect the internal
> processors to external pins any way you want.
> 
I used the Propellor I in several projects. I like this approach where 
every core run totally independent and undisturbed from all others. This 
gives total predictability. You write e.g. one module that runs on one 
core to implement a time critical peripheral and start the some program 
on several other cores without any worry that your timing gets messed up.
As David asked for something serial with unusual format, I implemented 
ARINC-429 (Avionics bus). This is 32 bit pi-phase serial 100kbit/s. Each 
input or output runs one one core. One more core implements the 
interface to the host. That's 4 rx/3 tx much cheaper than using standard 
chips.
Similar ARINC-708 (12 bit, manchester bi-phase, 1 Mbit/s) used for 
weather radar.

-- 
Reinhardt