Custom CPU Designs

On Monday, April 20, 2020 at 4:58:57 PM UTC+1, David Brown wrote:
> On 19/04/2020 20:52, 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/
> > 
> 
> Has anyone here tried SpinalHDL ?  I had a look at it, and it seems very 
> appealing.

Haven't tried it, but did follow the link and looked at the code.

I thought it was interesting in that registers are explicit rather than using a rising_edge(clk) if statement.

I followed some of the links on https://github.com/riscv/riscv-cores-list and found Chisel to be similar to SpinalHDL.

I did a quick compare of UART TX code for Spinal and Chisel from here
https://spinalhdl.github.io/SpinalDoc/spinal/examples/uart/ and here
https://github.com/nyuichi/chisel-uart/blob/master/src/main/scala/Uart.scala.

Overall I didn't see anything compelling compared to VHDL, in that admittedly very limited quick look :)

The Spinal website says one of it's advantages is "Reduce code size - By a high
factor, especially for wiring. This enables you to have a better overview of
your code base, increase your productivity and create fewer headaches.".
That looks to be a false statement (I didn't look at the wiring). Maybe there
is something in the other stated advantages but I only looked at the above.

On 21/04/20 02:12, Rick C wrote:
> On Monday, April 20, 2020 at 10:32:31 AM UTC-4, David Brown wrote:
>> 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.?

An unprogrammed processor (or FPGA) is merely sand. That's why
the tools are /vital/.

Most hardware designers grossly underestimate the difficulty
of producing application software and tools. The traditional
refrain is "it is only software".

That's why the XMOS hardware/software combination is so
important and different. But you have decided not to be
interested in finding that out; your loss.


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

I normally end up pushing the technology I use. All
technologies have pinch points.


> But those designs are far beyond anything a CPU is capable of.

Only in some respects. In others CPUs far outstrip hardware.

The last time I heard of a hardware "database" was in the
early 80s, with ICL's DAP machine. It sunk without a trace.

On Monday, April 20, 2020 at 8:23:30 PM UTC-4, Clifford Heath wrote:
> 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

Interesting.  I don't see any mention of the Power architecture in James Brakefield's soft IP charts linked early in this thread.  I wonder what a low end implementation might be like for an FPGA?  

I would be worried this would be lost in the large interest in RISC-V which seems to have a pretty good head of steam at this point.  How many open architectures do we need?  Isn't MIPS open at this point? 

I still like the MISC concept.  I'm not one for complicated tools for software.  But then I don't typically code complex apps.  My software is a complement to the hardware and is often rather simple by many measures even if it is a bit intense. 

I want to get back to my stack/register ISA design at some point.  I've looked at the potential for it being an efficient instruction set (which it is), but I haven't explored the implementation issues for the hardware fully yet.  

-- 

  Rick C.

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

On 21/04/2020 02:36, Rick C wrote:
> 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:
>>>> 

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

EtherCAT has been increasingly popular in industrial automation (the 
world of Programmable Logic Controllers, Profibus, Frequency Converters, 
etc.).  It's the stuff that runs factories, and programmed and set up by 
automation engineers that are a kind of cross between electricians and 
software developers.  Characteristics of electronics in this field are 
that they are often quite expensive, but designed to fit together and 
"just work" even when made by different companies.  Most of the stuff is 
made by relatively few large companies, rather than small companies. 
Implementing many of the protocols involved are quite horrible - badly 
specified (with large fees to be paid before you can even see the 
documents), overly complex, and typically require complicated XML-based 
"descriptors" that make USB descriptors look simple.  But while that 
stuff makes them unpleasant to implement, it makes them very easy to use 
for the people actually making the automation setups.

EtherCAT is also quite complicated, but a lot of it is handled by 
dedicated slave controller chips and software stacks that are available.

I believe you are right that if it takes off in the automotive world, 
we'll see more microcontrollers that support them.  Certainly there is 
more normal Ethernet in the car world.  Normal Ethernet has big 
advantages of flexibility, familiarity and existing software and 
hardware.  EtherCAT is unfamiliar to most people, and is suitable for 
different types of network - it's good for very predictable timing (you 
can get 0.1 microsecond synchronisation between nodes), deterministic 
transfers and low latency, but throughput is lower and transfer of large 
amounts of data is awkward.

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

There are lots of Ethernet cores available for FPGAs.  Some are free, 
some cost, some are very efficient, some less so, some flexible, some 
more dedicated.  The ubiquity of Ethernet means cores are cheap and well 
supported.

There are very few EtherCAT cores available.  They are expensive, and 
quite specialised - just like microcontrollers with EtherCAT, and 
external stand-alone peripherals.  And if they take off in cars, then we 
can expect that situation to change.

> 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?

My point was that XMOS could have made something /different/.  Something 
that is known well enough for people to see the point even if they 
hadn't thought of using EtherCAT themselves (there is a Wikipedia entry, 
and plenty of Youtube videos on EtherCAT), but not so standard that 
everyone and their cat has support.  (XMOS /have/ done that with the 
audio stuff.)

> 
> 
>>> 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?
> 

It is a type of MAC, but not a normal Ethernet MAC.  The physical side 
(the PHY) is the same.  But where an Ethernet MAC reads incoming packets 
in and stores them in ram somewhere, and collects outgoing packets from 
ram and sends them out, an EtherCAT MAC reads and writes bits of the 
packet while passing it on towards the next 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.
> 

I said I haven't needed them, except for one project a fair number of 
years ago.  It is even longer since I have needed an FPGA (though a 
number of our customers have FPGA boards).

On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote:
> On 21/04/2020 02:36, Rick C wrote:
> > 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:
> >>>> 
> 
> >> 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.
> > 
> 
> EtherCAT has been increasingly popular in industrial automation (the 
> world of Programmable Logic Controllers, Profibus, Frequency Converters, 
> etc.).  

You say "increasingly popular" but if it were being used in higher volumes MCUs with EtherCAT interfaces would be available.  MCU makers aren't stupid and love to have any advantage over the competition they can find. 

So "popular" has to be something other than unit volume. 


> It's the stuff that runs factories, and programmed and set up by 
> automation engineers that are a kind of cross between electricians and 
> software developers.  Characteristics of electronics in this field are 
> that they are often quite expensive, but designed to fit together and 
> "just work" even when made by different companies.  Most of the stuff is 
> made by relatively few large companies, rather than small companies. 
> Implementing many of the protocols involved are quite horrible - badly 
> specified (with large fees to be paid before you can even see the 
> documents), overly complex, and typically require complicated XML-based 
> "descriptors" that make USB descriptors look simple.  But while that 
> stuff makes them unpleasant to implement, it makes them very easy to use 
> for the people actually making the automation setups.
> 
> EtherCAT is also quite complicated, but a lot of it is handled by 
> dedicated slave controller chips and software stacks that are available.

So what sort of price premium are these peripheral chips adding to the BoM? 


> I believe you are right that if it takes off in the automotive world, 
> we'll see more microcontrollers that support them.  Certainly there is 
> more normal Ethernet in the car world.  Normal Ethernet has big 
> advantages of flexibility, familiarity and existing software and 
> hardware.  EtherCAT is unfamiliar to most people, and is suitable for 
> different types of network - it's good for very predictable timing (you 
> can get 0.1 microsecond synchronisation between nodes), deterministic 
> transfers and low latency, but throughput is lower and transfer of large 
> amounts of data is awkward.
> 
> > 
> >> 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.
> > 
> 
> There are lots of Ethernet cores available for FPGAs.  Some are free, 
> some cost, some are very efficient, some less so, some flexible, some 
> more dedicated.  The ubiquity of Ethernet means cores are cheap and well 
> supported.
> 
> There are very few EtherCAT cores available.  They are expensive, and 
> quite specialised - just like microcontrollers with EtherCAT, and 
> external stand-alone peripherals.  And if they take off in cars, then we 
> can expect that situation to change.
> 
> > 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?
> 
> My point was that XMOS could have made something /different/.  Something 
> that is known well enough for people to see the point even if they 
> hadn't thought of using EtherCAT themselves (there is a Wikipedia entry, 
> and plenty of Youtube videos on EtherCAT), but not so standard that 
> everyone and their cat has support.  (XMOS /have/ done that with the 
> audio stuff.)

You are suggesting that EtherCAT could be the "killer app" for XMOS?  I don't know.  But as with virtually every other type of peripheral, once the demand increases it will be part of everything from 8051s to high end ARMs.  


> >>> 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?
> > 
> 
> It is a type of MAC, but not a normal Ethernet MAC.  The physical side 
> (the PHY) is the same.  But where an Ethernet MAC reads incoming packets 
> in and stores them in ram somewhere, and collects outgoing packets from 
> ram and sends them out, an EtherCAT MAC reads and writes bits of the 
> packet while passing it on towards the next node.

Ok, sounds like there is a lot more to it.  I guess I'll have to read up about it at some point. 

I'm happy to work on an EtherCAT design for an FPGA.  I'm not really in the business of selling IP but it's a possibility.  Maybe program it into an Ice40 chip and sell it as a product.  They have non-volatile, one time programmable config memory.  So they can work as preprogrammed devices.  


> >>> 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.
> > 
> 
> I said I haven't needed them, except for one project a fair number of 
> years ago.  It is even longer since I have needed an FPGA (though a 
> number of our customers have FPGA boards).

I've realized for a number of years FPGAs are underutilized.  It's largely a matter of unfamiliarity or misconceptions.  I still run into people who think they have to be high power consumption devices.  They can be small, power efficient and high performance all in a single chip.  Development difficulty is overstated a lot too.  I find them much easier to work with than MCUs.  

That's why I feel the XMOS has a limited niche between MCUs and FPGAs.  They really aren't general purpose because they are pricey.  An FPGA can be cheaper in many situations.  But FPGAs aren't great for a full TCP/IP stack, etc.  So different horses for different courses.  

-- 

  Rick C.

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

David Brown <david.brown@hesbynett.no> wrote:
> On 17/04/2020 17:34, Theo wrote:
> > I think part of the problem is the ARM licensing cost - if the license cost
> > is (random number) 5% of the silicon sticker price that's fine when it's a
> > $1 MCU, but when it's a $10000 FPGA that hurts.  
> 
> I'm not sure that's valid.  First, do you know that the ARM licensing 
> costs work that way?

I have no insight into the licensing contracts (which are likely very
confidential), but what I understand is that all Stratix 10 parts have an
ARM but relatively few have it enabled.  Additionally I understand the
licence cost is only paid for parts where it is enabled.  From that I
surmise that the licence cost is significant; if the cost was minimal then
why have a separate SKU without the ARM?

One other possibility is that a separate SKU allows the ARM to be faulty
and the part still saleable, but it seems that ballpark 80-90% of the
eval boards I see are offering parts without ARMs.  Which suggests there's a
strong motivation not to use it.

> (And whatever the numbers, RISC-V changes things significantly.)

I'm not sure RISC-V is to the level of maturity for baking a Cortex A53
equivalent into a critical product.

Theo

On 21/04/2020 15:15, Rick C wrote:
> On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote:
>> On 21/04/2020 02:36, Rick C wrote:
>>> 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:
>>>>>>
>>
>>>> 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.
>>>
>>
>> EtherCAT has been increasingly popular in industrial automation (the
>> world of Programmable Logic Controllers, Profibus, Frequency Converters,
>> etc.).
> 
> You say "increasingly popular" but if it were being used in higher volumes MCUs with EtherCAT interfaces would be available.  MCU makers aren't stupid and love to have any advantage over the competition they can find.
> 
> So "popular" has to be something other than unit volume.

I wrote "increasingly popular", because it is becoming increasingly 
popular.  That means both that more and more people are using EtherCAT 
devices, more and more EtherCAT devices are being installed, more and 
more EtherCAT devices are being developed, more and more EtherCAT MCUs, 
standand-alone peripherals, and FPGA cores have become available in 
recent years.

In the big picture of MCU sales, EtherCAT usage is tiny.  /Really/ tiny. 
  Less tiny than five years ago, but still tiny.  Making an EtherCAT 
peripheral in a MCU is not an insignificant investment for an MCU 
company - it would be a very big investment.  They won't do that until 
they foresee a sizeable market - far greater than the automation market. 
  Until then, it will be left to the few who are heavily involved in 
this sort of thing, such as Infineon (Siemens has always been a big 
player in the automation world).

> 
> 
>> It's the stuff that runs factories, and programmed and set up by
>> automation engineers that are a kind of cross between electricians and
>> software developers.  Characteristics of electronics in this field are
>> that they are often quite expensive, but designed to fit together and
>> "just work" even when made by different companies.  Most of the stuff is
>> made by relatively few large companies, rather than small companies.
>> Implementing many of the protocols involved are quite horrible - badly
>> specified (with large fees to be paid before you can even see the
>> documents), overly complex, and typically require complicated XML-based
>> "descriptors" that make USB descriptors look simple.  But while that
>> stuff makes them unpleasant to implement, it makes them very easy to use
>> for the people actually making the automation setups.
>>
>> EtherCAT is also quite complicated, but a lot of it is handled by
>> dedicated slave controller chips and software stacks that are available.
> 
> So what sort of price premium are these peripheral chips adding to the BoM?
> 

I don't deal with prices at that level, but Digikey puts them at about $10.

>>
>> My point was that XMOS could have made something /different/.  Something
>> that is known well enough for people to see the point even if they
>> hadn't thought of using EtherCAT themselves (there is a Wikipedia entry,
>> and plenty of Youtube videos on EtherCAT), but not so standard that
>> everyone and their cat has support.  (XMOS /have/ done that with the
>> audio stuff.)
> 
> You are suggesting that EtherCAT could be the "killer app" for XMOS?  I don't know.  But as with virtually every other type of peripheral, once the demand increases it will be part of everything from 8051s to high end ARMs.
> 

No, I have /not/ been suggesting EtherCAT would be a killer app for 
XMOS.  You seem to have combined various posts, adding 2 plus 3 to get 17.

I said it would be a good example of the kind of thing you could do with 
an XMOS that you could not easily do with a standard MCU.  Of course 
/some/ people might buy an XMOS because they want EtherCAT.  But demo 
applications and examples are primarily marketing - it's about showing 
how great the chip and tools are at doing one thing, so that customers 
will use the device for their own strange needs.  Far more people would 
use a standard Ethernet core than an EtherCAT core, but the EtherCAT 
core would be a better advertisement for the chip and toolset.

>>>
>>
>> It is a type of MAC, but not a normal Ethernet MAC.  The physical side
>> (the PHY) is the same.  But where an Ethernet MAC reads incoming packets
>> in and stores them in ram somewhere, and collects outgoing packets from
>> ram and sends them out, an EtherCAT MAC reads and writes bits of the
>> packet while passing it on towards the next node.
> 
> Ok, sounds like there is a lot more to it.  I guess I'll have to read up about it at some point.
> 
> I'm happy to work on an EtherCAT design for an FPGA.  I'm not really in the business of selling IP but it's a possibility.  Maybe program it into an Ice40 chip and sell it as a product.  They have non-volatile, one time programmable config memory.  So they can work as preprogrammed devices.
> 

I have no doubt that you have the ability to make an EtherCAT core in an 
FPGA.  But I have absolutely no idea whether it would be a good economic 
investment for you to do so.  And while you will probably find it 
interesting to read a little about it, I would not think making an 
EtherCAT core is the kind of project you might do for fun.

>> I said I haven't needed them, except for one project a fair number of
>> years ago.  It is even longer since I have needed an FPGA (though a
>> number of our customers have FPGA boards).
> 
> I've realized for a number of years FPGAs are underutilized.  It's largely a matter of unfamiliarity or misconceptions.  I still run into people who think they have to be high power consumption devices.  They can be small, power efficient and high performance all in a single chip.  Development difficulty is overstated a lot too.  I find them much easier to work with than MCUs.
> 

Habit and familiarity is the key.  Very few people find them easier to 
work with than MCUs, even though /you/ do.

> That's why I feel the XMOS has a limited niche between MCUs and FPGAs.  They really aren't general purpose because they are pricey.  An FPGA can be cheaper in many situations.  But FPGAs aren't great for a full TCP/IP stack, etc.  So different horses for different courses.
> 

On that last sentiment, I hope we can all agree!

On Tuesday, April 21, 2020 at 10:20:41 AM UTC-4, Theo wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> > On 17/04/2020 17:34, Theo wrote:
> > > I think part of the problem is the ARM licensing cost - if the license cost
> > > is (random number) 5% of the silicon sticker price that's fine when it's a
> > > $1 MCU, but when it's a $10000 FPGA that hurts.  
> > 
> > I'm not sure that's valid.  First, do you know that the ARM licensing 
> > costs work that way?
> 
> I have no insight into the licensing contracts (which are likely very
> confidential), but what I understand is that all Stratix 10 parts have an
> ARM but relatively few have it enabled.  Additionally I understand the
> licence cost is only paid for parts where it is enabled.  From that I
> surmise that the licence cost is significant; if the cost was minimal then
> why have a separate SKU without the ARM?

They do the same thing with the FPGA itself.  It is not inexpensive to spin the masks for FPGAs at the bleeding edge of semiconductor fabrication technology.  So they sell parts with more or less of the part enabled or even just tested (testing cost in an FPGA is not inexpensive).  So you buy an FPGA with 50,000 LUTs or you buy one with 25,000 LUTs and it's the same part.  The 50,000 part has the entire chip tested, the 25,000 LUT part only tests the section with 25,000 LUTs you will be using.  They will get the price even lower if you are buying a large quantity and you give them your design, so they only test the parts of the chip your design uses!  

So don't test the CPU and don't pay the license fee.  Save some on the license and save more on not testing the CPU and various supporting logic. 


> One other possibility is that a separate SKU allows the ARM to be faulty
> and the part still saleable, but it seems that ballpark 80-90% of the
> eval boards I see are offering parts without ARMs.  Which suggests there's a
> strong motivation not to use it.

I'm told if a chip fails a test, it is tossed.  The savings comes from not testing a section to begin with.  Testing equipment is not cheap and FPGAs take a lot of time on the beast. 


> > (And whatever the numbers, RISC-V changes things significantly.)
> 
> I'm not sure RISC-V is to the level of maturity for baking a Cortex A53
> equivalent into a critical product.

Not sure what you are trying to say, but Microsemi is coming out with a RISC-V FPGA device family this year. 

-- 

  Rick C.

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

On 21/04/20 16:25, David Brown wrote:
> On 21/04/2020 15:15, Rick C wrote:
>> On Tuesday, April 21, 2020 at 8:02:18 AM UTC-4, David Brown wrote:

>> You are suggesting that EtherCAT could be the "killer app" for XMOS?  I don't 
>> know.  But as with virtually every other type of peripheral, once the demand 
>> increases it will be part of everything from 8051s to high end ARMs.
>>
> 
> No, I have /not/ been suggesting EtherCAT would be a killer app for XMOS.  You 
> seem to have combined various posts, adding 2 plus 3 to get 17.

Yes. Rick's assertion caused my eyebrows to go up as well!


>> I've realized for a number of years FPGAs are underutilized.  It's largely a 
>> matter of unfamiliarity or misconceptions.  I still run into people who think 
>> they have to be high power consumption devices.  They can be small, power 
>> efficient and high performance all in a single chip.  Development difficulty 
>> is overstated a lot too.  I find them much easier to work with than MCUs.
>>
> 
> Habit and familiarity is the key.  Very few people find them easier to work with 
> than MCUs, even though /you/ do.

Precisely.

Not many people have designed everything from analogue
electronics, vanilla digital electronics, FPGA and
similar, hard realtime mission critical programs,
soft realtime telecom systems, and CRUD applications.

I've done all of those (and more) and know their
relative strengths and weaknesses.

Far too many people have only done one or two of those,
and then use hammers to insert screws.


>> That's why I feel the XMOS has a limited niche between MCUs and FPGAs.  They 
>> really aren't general purpose because they are pricey.  An FPGA can be cheaper 
>> in many situations.  But FPGAs aren't great for a full TCP/IP stack, etc.  So 
>> different horses for different courses.
>>
> 
> On that last sentiment, I hope we can all agree!

I certainly can :)

On 21/04/2020 03:27, Rick C wrote:
> 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.

Livelock is when bits of a system are running fine, but the overall 
system is not making progress.  Often it is temporary and resolves 
itself (unlike deadlock).

A hardware example might be if you have a crossbar for multiple bus 
masters to access a single slave device.  You need some way of deciding 
which master gets access when both want it simultaneously.  Perhaps you 
decide that master A is more important, and always gets priority.  Then 
if master A hogs the bus, master B never gets a chance - livelock.

Often these kinds of things are straightforward to avoid as long as you 
think about what can happen.  That applies to software and hardware.

> 
> I don't even know of an example of deadlock in hardware design.

The simplest way to get a deadlock is to have two shared resources, and 
two processes (hardware modules, software tasks, whatever) that need 
both the resources, but acquire them in different orders.  But you don't 
usually get such simple cases, as they are so obvious.

> 
> So clearly these are not such important issues in hardware design.

If your designs don't involve much in the way of shared resources, 
you're not going see them.  (The same applies in software.)  It is also 
perfectly possible that the way you design your systems, they naturally 
don't occur - or that you think of them as bugs, hangs, blocks or stops 
rather than as "deadlocks".  (The same applies in software.)  It is also 
possible, though of course /highly/ unlikely, that your systems /do/ 
have the risk of deadlocks and they just haven't happened yet.  (The 
same applies in software.)

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

You can have shared resources in hardware too.

It is perhaps fair to say that the way you design hardware makes shared 
resources stand out a bit more - you have explicit sharing with 
cross-switches, multiplexors, etc.  And that might mean that 
deadlock-free solutions are mostly so obvious that you don't see them as 
a potential problem.  I discussed previously about thinking the 
"hardware way" for shared data in software development - that also makes 
it very easy to avoid deadlock.

> 
>> 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?

Yes.  But it means task A - the high priority task - can't be completed 
as fast as you had wanted.

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

I program mostly in C and Python.  It's hard to pick two software 
languages that are further apart - so I understand what you mean here.