Custom CPU Designs

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

On Sunday, April 19, 2020 at 5:15:20 PM UTC-4, Tom Gardner wrote:
> On 19/04/20 21:37, Rick C wrote:
> > On Sunday, April 19, 2020 at 5:11:22 AM UTC-4, Tom Gardner wrote:
> >> On 18/04/20 22:53, Rick C wrote:
> >>> On Saturday, April 18, 2020 at 1:07:00 PM UTC-4, Tom Gardner wrote:
> >>>> On 18/04/20 16:51, Theo wrote:
> >>>>> David Brown <david.brown@hesbynett.no> 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.
> >>>>>> 
> >>>>>> 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.
> >>>>> 
> >>>>> The Cypress PSoC has an interesting take on this.  You can specify
> >>>>> (with the GUI) that you want a component.  If you specify a simple
> >>>>> component (let's say I2C slave) there's a hard IP for that.  But if
> >>>>> you specify something that's more complicated (say I2C master and
> >>>>> slave on the same pins) it builds it with the existing IP plus some
> >>>>> of its FPGA-like logic. Takes more resources but allows you to do
> >>>>> many more things than they put in as hard cores.
> >>>>> 
> >>>>> Unfortunately they don't provide a vast quantity of cells for that
> >>>>> logic, so it's fine if you want to add just a few unusual bits to the
> >>>>> regular microcontroller, but not a big system.  (PSoC also has the
> >>>>> programmable analogue stuff, which presumably constrains the process
> >>>>> they can use)
> >>>>> 
> >>>>> It would be quite interesting to combine that with the XMOS approach
> >>>>> - more fluid boundaries between hardware and software.
> >>>>> 
> >>>>> I'm a bit surprised XMOS don't provide 'soft realtime' virtual cores
> >>>>> - lock down the cores running a task that absolutely needs to be 
> >>>>> bounded-latency, and then multitask the remaining tasks across the
> >>>>> other cores.  If that was provided as an integrated service then it
> >>>>> wouldn't need messing about running a scheduler.
> >>>> 
> >>>> What scheduler?
> >>>> 
> >>>> To a very useful approximation the an RTOS's functions are encoded in 
> >>>> hardware.
> >>>> 
> >>>> The "select" statement is like a "switch" statement, except that the
> >>>> core sleeps until one of the "case" conditions becomes true. In effect
> >>>> the case conditions are events. Events can be inputs arriving, outputs
> >>>> completing, timeouts, etc.
> >>> 
> >>> Isn't that what interrupts are about?  Many processors have a "halt and
> >>> wait for interrupt" instruction.
> >> 
> >> Hardware on its own is trivial and has been done many times over the
> >> decades.
> >> 
> >> XMOS have integrated the hardware with the software with the conceptual
> >> tools, and have provided excellent development tools.
> >> 
> >> That has not been achieved elsewhere.
> > 
> > Not sure what your point is.  XMOS doesn't have programmable hardware, so
> > it's not clear what you are referring to "integrating".  The only company
> > I've seen integrate the hardware and software is Cypress and that is fairly
> > crude.
> 
> I'm not going to /poorly/ regurgitate XMOS information for you.
> 
> Start with
> https://www.xmos.com/download/xCORE-Architecture-Flyer(1.3).pdf
> and then you will be able to ask more useful questions.

I think this conversation has come to an end.  You made a claim that does not fit with what I know about the XMOS.  If that claim is in the documentation, just provide a reference.  I'm not going to wade through a bunch of docs to research YOUR claim. 

"XMOS have integrated the hardware with the software with the conceptual tools"

Either support that, or don't bother making it. 


> > What exactly is special or unique about XMOS other than the fact they have N
> > processors with a shared memory on a single chip?  The point is if this is
> > not the Goldilocks combination for you, the XMOS is not so great a chip.
> 
> Sigh, IT ISN'T JUST THE PROCESSOR HARDWARE. Got the point?
> See the architecture flyer, and then add
> https://www.xmos.com/software/tools/

Then WHAT IS IT?  See, you aren't the only one who can shout.  Either discuss, or don't discuss.  I'm not here to do your research. 


> >>>> N.B. as far as a core is concerned, receiving input from a pin is the
> >>>> same as receiving a message from another task/core. Ditto output to a
> >>>> pin and sending a message to another task/core. Everything is via the
> >>>> "port" abstraction, and that extends down into the hardware and i/o
> >>>> system.
> >>> 
> >>> That sounds a lot like the Transputer.
> >> 
> >> Exactly.
> >> 
> >> And xC is a modern successor to Occam, with CSP a core abstraction.
> >> 
> >> Some of the original Transputer team are in XMOS.
> >> 
> >> 
> >> 
> >> 
> >>>> For a short intro to the hardware, software, and concepts see the 
> >>>> architecture flyer.
> >>>> https://www.xmos.com/file/xcore-architecture-flyer/
> >>>> 
> >>>> FFI see the XMOS programming guide, which is beautifully written,
> >>>> succinct, and clear. https://www.xmos.com/file/xmos-programming-guide/
> >>>> 
> >>>> I wish all documentation was as good!
> >>>> 
> >>>> 
> >>>>> After all, there must be applications with a lot of 
> >>>>> do-this-once-a-second tasks, that would be wasted using a whole core?
> >>>>> Do they have a scheduler where you can tell a task to sleep until a 
> >>>>> particular time?
> >>>> 
> >>>> See "combinable tasks" in my post in response to David Brown's post.
> >>>> 
> >>>> 
> >>>>> Or is FreeRTOS intended for that?  In which case you presumably have
> >>>>> to write the code in a different way compared to the hard-tasks?
> >>>> 
> >>>> I really don't see the point of FreeRTOS running inside an xCORE chip.
> >>>> To be over simplistic, RTOSs are designed to schedule multiple  tasks
> >>>> on a single processor and to connect i/o with tasks (typically via
> >>>> interrupts).
> >>>> 
> >>>> All that is done in hardware in the xCORE ecosystem.
> >>> 
> >>> That's true of most processors, no?  An I/O event happens and an
> >>> interrupt invokes a task called an interrupt handler.
> >>> 
> >>> The tricky part is dealing with the real time requirements of handling
> >>> the I/O events.  Which task must be done first, which tasks can be
> >>> interrupted to deal with other tasks, what resources are required to
> >>> process an event, etc. This is what makes real time multitasking
> >>> difficult.
> >> 
> >> Those problems mostly disappear with sufficient independent cores.
> > 
> > Hmmm...  the keyword there is "sufficient".  That was when I mentioned 144
> > and the cycle began.
> 
> Those cores can be regarded as merely "LUTs on steroids" :)

YES!  That's what I try to tell people and they often don't get it.  I don't think of the GA144 as a multiprocessor.  It's a FPPA, Field Programmable Processor Array.  


> >> What remains is the logical dependencies which can result in livelock or
> >> deadlock. No implementation technology can solve those, since they are
> >> inherent in either the problem or the architectural solution.
> > 
> > Indeed.  However these problems go away once you decompose your problem for
> > independent processors such as in an FPGA.  I can't remember ever having to
> > even consider a deadlock other than the most simple of issues when designing
> > in an FPGA.
> 
> If you have two independent FSMs sending events to each other,
> then you can get livelock and deadlock.

Not if they are designed correctly. 


> Whether the FSMs are implemented in hardware, software, wetware,
> is irrelevant.

Absolutely.  Bad design is not dependent on the implementation technology. 


> Proving such systems of FSM are deadlock-free is an active
> research topic (and probably always will be).

You must work with pretty large FSMs to worry about such things.


> > Multitasking on a single processor (or even on several) can open up a design
> > to very complex interactions which have subtle failure modes.
> Yup. As I said, the implementation technology is irrelevant.

What technology?  If you are talking about single vs. multiprocessor I don't agree which should be pretty clear by now. 

-- 

  Rick C.

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

On 19/04/20 23:02, Rick C wrote:
> On Sunday, April 19, 2020 at 5:15:20 PM UTC-4, Tom Gardner wrote:
>> On 19/04/20 21:37, Rick C wrote:
>>> Not sure what your point is.  XMOS doesn't have programmable hardware,
>>> so it's not clear what you are referring to "integrating".  The only
>>> company I've seen integrate the hardware and software is Cypress and that
>>> is fairly crude.
>> 
>> I'm not going to /poorly/ regurgitate XMOS information for you.
>> 
>> Start with https://www.xmos.com/download/xCORE-Architecture-Flyer(1.3).pdf 
>> and then you will be able to ask more useful questions.
> 
> I think this conversation has come to an end.  You made a claim that does not
> fit with what I know about the XMOS.  If that claim is in the documentation,
> just provide a reference.  I'm not going to wade through a bunch of docs to
> research YOUR claim.

That doc is all of 4 pages long.

I'm not going to do your research for you.


> "XMOS have integrated the hardware with the software with the conceptual
> tools"
> 
> Either support that, or don't bother making it.

XMOS have supported it, as indicated.

If you can't be bothered to read a 4 page document, you
aren't interested in learning.



>>> What exactly is special or unique about XMOS other than the fact they
>>> have N processors with a shared memory on a single chip?  The point is if
>>> this is not the Goldilocks combination for you, the XMOS is not so great
>>> a chip.
>> 
>> Sigh, IT ISN'T JUST THE PROCESSOR HARDWARE. Got the point? See the
>> architecture flyer, and then add https://www.xmos.com/software/tools/
> 
> Then WHAT IS IT?  See, you aren't the only one who can shout.  Either
> discuss, or don't discuss.  I'm not here to do your research.

I don't need to research this.

You do need to read a 4 page document and think about
its contents. I can't do that for you.



>>>>>> N.B. as far as a core is concerned, receiving input from a pin is
>>>>>> the same as receiving a message from another task/core. Ditto
>>>>>> output to a pin and sending a message to another task/core.
>>>>>> Everything is via the "port" abstraction, and that extends down
>>>>>> into the hardware and i/o system.
>>>>> 
>>>>> That sounds a lot like the Transputer.
>>>> 
>>>> Exactly.
>>>> 
>>>> And xC is a modern successor to Occam, with CSP a core abstraction.
>>>> 
>>>> Some of the original Transputer team are in XMOS.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>>> For a short intro to the hardware, software, and concepts see the 
>>>>>> architecture flyer. 
>>>>>> https://www.xmos.com/file/xcore-architecture-flyer/
>>>>>> 
>>>>>> FFI see the XMOS programming guide, which is beautifully written, 
>>>>>> succinct, and clear.
>>>>>> https://www.xmos.com/file/xmos-programming-guide/
>>>>>> 
>>>>>> I wish all documentation was as good!
>>>>>> 
>>>>>> 
>>>>>>> After all, there must be applications with a lot of 
>>>>>>> do-this-once-a-second tasks, that would be wasted using a whole
>>>>>>> core? Do they have a scheduler where you can tell a task to sleep
>>>>>>> until a particular time?
>>>>>> 
>>>>>> See "combinable tasks" in my post in response to David Brown's
>>>>>> post.
>>>>>> 
>>>>>> 
>>>>>>> Or is FreeRTOS intended for that?  In which case you presumably
>>>>>>> have to write the code in a different way compared to the
>>>>>>> hard-tasks?
>>>>>> 
>>>>>> I really don't see the point of FreeRTOS running inside an xCORE
>>>>>> chip. To be over simplistic, RTOSs are designed to schedule
>>>>>> multiple  tasks on a single processor and to connect i/o with tasks
>>>>>> (typically via interrupts).
>>>>>> 
>>>>>> All that is done in hardware in the xCORE ecosystem.
>>>>> 
>>>>> That's true of most processors, no?  An I/O event happens and an 
>>>>> interrupt invokes a task called an interrupt handler.
>>>>> 
>>>>> The tricky part is dealing with the real time requirements of
>>>>> handling the I/O events.  Which task must be done first, which tasks
>>>>> can be interrupted to deal with other tasks, what resources are
>>>>> required to process an event, etc. This is what makes real time
>>>>> multitasking difficult.
>>>> 
>>>> Those problems mostly disappear with sufficient independent cores.
>>> 
>>> Hmmm...  the keyword there is "sufficient".  That was when I mentioned
>>> 144 and the cycle began.
>> 
>> Those cores can be regarded as merely "LUTs on steroids" :)
> 
> YES!  That's what I try to tell people and they often don't get it.  I don't
> think of the GA144 as a multiprocessor.  It's a FPPA, Field Programmable
> Processor Array.

A LUT is a long way from being a core.

Very few people want to work at the level of individual LUTs.

Those that do would probably use one of the original MACH
or CPLD devices - very sensibly in my view.



>>>> What remains is the logical dependencies which can result in livelock
>>>> or deadlock. No implementation technology can solve those, since they
>>>> are inherent in either the problem or the architectural solution.
>>> 
>>> Indeed.  However these problems go away once you decompose your problem
>>> for independent processors such as in an FPGA.  I can't remember ever
>>> having to even consider a deadlock other than the most simple of issues
>>> when designing in an FPGA.
>> 
>> If you have two independent FSMs sending events to each other, then you can
>> get livelock and deadlock.
> 
> Not if they are designed correctly.

Well, duh.

Now /prove/ the design is correct - t'ain't easy.

I've dealt with FSMs where different components have been
developed by different companies over decades. That's
standard in the telecom world. It has also occurred in some
LANs.

Good luck with some idealistic small-system design concepts
those circumstances!


>> Whether the FSMs are implemented in hardware, software, wetware, is
>> irrelevant.
> 
> Absolutely.  Bad design is not dependent on the implementation technology.

Not necessarily bad; real-world pragmatism is sufficient.


>> Proving such systems of FSM are deadlock-free is an active research topic
>> (and probably always will be).
> 
> You must work with pretty large FSMs to worry about such things.

I have done, yes.

So have many other people.

It is in the nature of telecom systems.

There are many things in this world that you haven't
experienced, but that doesn't mean they don't exist.
(Example: European cities, how the infrastructure is
built, and the impracticality of each dwelling having
its own EV charging point.)


>>> Multitasking on a single processor (or even on several) can open up a
>>> design to very complex interactions which have subtle failure modes.
>> Yup. As I said, the implementation technology is irrelevant.
> 
> What technology?  If you are talking about single vs. multiprocessor I don't
> agree which should be pretty clear by now.

Any  technology.

On 19/04/20 22:47, Rick C wrote:
> One application the company talks about is for a hearing aid.  It used new
> theories of how we hear to improve hearing for people what traditional
> "filtered" amplifiers don't work.

If true, that marks them as being completely unrealistic.

The chances of some softies coming up with novel valid
hearing aid algorithms without having previous experience
is effectively zero.

Even if they had, the chances of getting one of their chips
into an ear canal are effectively zero.

Tom Gardner <spamjunk@blueyonder.co.uk> writes:
> The chances of some softies coming up with novel valid hearing aid
> algorithms without having previous experience is effectively zero.

I don't think they developed the algorithms themselves.  IIRC the method
was developed by some medical types who do that sort of thing.  It used
a bunch of filter banks simultaneously, and the claim was that the GA144
or its 28-core predecessor could do this using less electrical power
than conventional MCU's or DSP's, at least at the time.  I don't know if
the approach ever went anywhere.  I don't think it purported to fit
inside the ear canal.  It may have been a behind-the-ear type of hearing
aid, or even a pocket device.

On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote:
> On 19/04/20 22:47, Rick C wrote:
> > One application the company talks about is for a hearing aid.  It used new
> > theories of how we hear to improve hearing for people what traditional
> > "filtered" amplifiers don't work.
> 
> If true, that marks them as being completely unrealistic.
> 
> The chances of some softies coming up with novel valid
> hearing aid algorithms without having previous experience
> is effectively zero.
> 
> Even if they had, the chances of getting one of their chips
> into an ear canal are effectively zero.

There you go, proving my point of mindset, over and over. 

No, I don't care enough about the XMOS to read more of their marketing docs.  If you have a point to make, either make it or not.  I don't care.  

-- 

  Rick C.

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

On 20/04/20 04:32, Rick C wrote:
> On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote:
>> On 19/04/20 22:47, Rick C wrote:
>>> One application the company talks about is for a hearing aid.  It used
>>> new theories of how we hear to improve hearing for people what
>>> traditional "filtered" amplifiers don't work.
>> 
>> If true, that marks them as being completely unrealistic.
>> 
>> The chances of some softies coming up with novel valid hearing aid
>> algorithms without having previous experience is effectively zero.
>> 
>> Even if they had, the chances of getting one of their chips into an ear
>> canal are effectively zero.
> 
> There you go, proving my point of mindset, over and over.

What are you on about?

That point has nothing whatsoever to do with XMOS!


> No, I don't care enough about the XMOS to read more of their marketing docs.
> If you have a point to make, either make it or not.  I don't care.

So why did you write elsewhere?...

On 19/04/20 23:02, Rick C wrote:> I think this conversation has come to an end. 
You made a claim that does not
 > fit with what I know about the XMOS.  If that claim is in the documentation,
 > just provide a reference.  I'm not going to wade through a bunch of docs to
 > research YOUR claim.

I provided a reference to a 4 page information dense
document. Your refusal to read a  indicates that /you/
are the one with the mindset that you are not prepared
to change!

Yes, I and others have read the GAL document, thought
about how to use it, and chosen not to.

On Monday, April 20, 2020 at 2:46:34 AM UTC-4, Tom Gardner wrote:
> On 20/04/20 04:32, Rick C wrote:
> > On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote:
> >> On 19/04/20 22:47, Rick C wrote:
> >>> One application the company talks about is for a hearing aid.  It used
> >>> new theories of how we hear to improve hearing for people what
> >>> traditional "filtered" amplifiers don't work.
> >> 
> >> If true, that marks them as being completely unrealistic.
> >> 
> >> The chances of some softies coming up with novel valid hearing aid
> >> algorithms without having previous experience is effectively zero.
> >> 
> >> Even if they had, the chances of getting one of their chips into an ear
> >> canal are effectively zero.
> > 
> > There you go, proving my point of mindset, over and over.
> 
> What are you on about?
> 
> That point has nothing whatsoever to do with XMOS!

You are uniquely obsessed with XMOS.  The quoted conversation is about the GA144.  Why are you bringing XMOS into it???  

You are making assertions about a design team that you know nothing about being unable to be innovative in a useful way on a product you know nothing about.  

Then you talk about not being able to put a chip in an ear canal as if that was the only way to use a hearing aid.  

What is going on with you?  Is the Corona-confinement getting to you? 


> > No, I don't care enough about the XMOS to read more of their marketing docs.
> > If you have a point to make, either make it or not.  I don't care.
> 
> So why did you write elsewhere?...
> 
> On 19/04/20 23:02, Rick C wrote:> I think this conversation has come to an end. 
> You made a claim that does not
>  > fit with what I know about the XMOS.  If that claim is in the documentation,
>  > just provide a reference.  I'm not going to wade through a bunch of docs to
>  > research YOUR claim.
> 
> I provided a reference to a 4 page information dense
> document. Your refusal to read a  indicates that /you/
> are the one with the mindset that you are not prepared
> to change!
> 
> Yes, I and others have read the GAL document, thought
> about how to use it, and chosen not to.

No, I'm not going to read four pages of "information dense document" to figure out what you are trying to say when I don't even know what to look for.  "IT ISN'T JUST THE PROCESSOR HARDWARE" is way to vague for me to go digging to support.  Actually you said I should review "the architecture flyer" then add https://www.xmos.com/software/tools/.  Sounds like a lot of digging to figure out what I am even supposed to be looking for.  Either say it or don't.  If you have nothing to say about your claim, I don't care.  

Actually, let's call this dead.  You have gotten far too hostile over a simple matter.  So much that your posts aren't even fully coherent.  

Signing off. 

-- 

  Rick C.

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

On 20/04/20 08:33, Rick C wrote:
> On Monday, April 20, 2020 at 2:46:34 AM UTC-4, Tom Gardner wrote:
>> On 20/04/20 04:32, Rick C wrote:
>>> On Sunday, April 19, 2020 at 9:11:30 PM UTC-4, Tom Gardner wrote:
>>>> On 19/04/20 22:47, Rick C wrote:
>>>>> One application the company talks about is for a hearing aid.  It
>>>>> used new theories of how we hear to improve hearing for people what 
>>>>> traditional "filtered" amplifiers don't work.
>>>> 
>>>> If true, that marks them as being completely unrealistic.
>>>> 
>>>> The chances of some softies coming up with novel valid hearing aid 
>>>> algorithms without having previous experience is effectively zero.
>>>> 
>>>> Even if they had, the chances of getting one of their chips into an
>>>> ear canal are effectively zero.
>>> 
>>> There you go, proving my point of mindset, over and over.
>> 
>> What are you on about?
>> 
>> That point has nothing whatsoever to do with XMOS!
> 
> You are uniquely obsessed with XMOS.  The quoted conversation is about the
> GA144.  Why are you bringing XMOS into it???

The same reason you bang on about the GA144 and Forth: they
are different to the usual run-of-the-mill processors.

Besides, you don't own the thread and several other
processors have been mentioned.



> You are making assertions about a design team that you know nothing about
> being unable to be innovative in a useful way on a product you know nothing
> about.

Learn to read and comprehend: which bit of "if true..." did
you not understand?



> Then you talk about not being able to put a chip in an ear canal as if that
> was the only way to use a hearing aid.

As someone that wears a BTE hearing aid and will soon
be eligible for a cochlea implant, I know how little
most people understand about hearing aids - and the
key points to force them to think about the practicalities.



>>> No, I don't care enough about the XMOS to read more of their marketing
>>> docs. If you have a point to make, either make it or not.  I don't care.
>> 
>> So why did you write elsewhere?...
>> 
>> On 19/04/20 23:02, Rick C wrote:> I think this conversation has come to an
>> end. You made a claim that does not
>>> fit with what I know about the XMOS.  If that claim is in the
>>> documentation, just provide a reference.  I'm not going to wade through a
>>> bunch of docs to research YOUR claim.
>> 
>> I provided a reference to a 4 page information dense document. Your refusal
>> to read a  indicates that /you/ are the one with the mindset that you are
>> not prepared to change!
>> 
>> Yes, I and others have read the GAL document, thought about how to use it,
>> and chosen not to.
> 
> No, I'm not going to read four pages of "information dense document" to
> figure out what you are trying to say when I don't even know what to look
> for.  "IT ISN'T JUST THE PROCESSOR HARDWARE" is way to vague for me to go
> digging to support.  Actually you said I should review "the architecture
> flyer" then add https://www.xmos.com/software/tools/.  Sounds like a lot of
> digging to figure out what I am even supposed to be looking for.  Either say
> it or don't.  If you have nothing to say about your claim, I don't care.

There would be no point saying anything since you have
clearly and explicitly stated you won't listen and can't
be bothered to do your own research.

That is ironic coming from someone that complains that
other people have fixed mindsets!

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