Fast simple microcontroller

On Sunday, July 4, 2021 at 10:13:42 AM UTC+10, gnuarm.del...@gmail.com wrote:
> On Saturday, July 3, 2021 at 9:46:38 AM UTC-4, bill....@ieee.org wrote: 
> > On Saturday, July 3, 2021 at 11:00:29 PM UTC+10, gnuarm.del...@gmail.com wrote: 
> > > On Friday, July 2, 2021 at 10:35:11 PM UTC-4, bill....@ieee.org wrote: 
> > > > On Saturday, July 3, 2021 at 11:28:33 AM UTC+10, gnuarm.del...@gmail.com wrote: 
> > > > > On Friday, July 2, 2021 at 1:33:59 AM UTC-4, bill....@ieee.org wrote: 
> > > > > > I've been thinking about Timo's inverter, and it looks as if a micro-controller that offered a 100MHz clock rate would be fast enough to do a decent job of switching the Siliconix Si3440DV DMOSFet that I fancy. 
> > > > > > 
> > > > > > I've found a PIC part that's fast enough, and pretty cheap, but it is designed for digital signal processing, which makes it more complicated than necessary. A nice, dumb but quick 8051 would be good enough. 
> > > > > > 
> > > > > > Somebody is apparently offers a 600MHz part, but I want something cheap and simple - if fairly fast (but not that fast). Browsing element-14 threw up a few candidates, but I didn't find their search engine all that helpful. 
> > > > > > 
> > > > > > Has anybody got a favourite part? 
> > > > > 
> > > > > An FPGA can be used to implement an 8051 or any other MCU architecture you wish at 100 MHz without much trouble. Then you can tailor the peripherals as you choose. Gowin has parts for $3 or less with internal Flash. > 
> > > > And the Microchip dsPIC33EPxxxSP50X will do the job for for $3, and throws in a PPL that will multiply up a 7MHz clock to 100MHz as well as an A/D converter that I can use. 
> > > > 
> > > > The aim is to get a single chip processor that is cheaper and simpler of the shelf. 
> > > 
> > > Single chip is not synonymous with simple. 
>
> > Obviously not. Back when I was working with electron beam microfabricators, the floor plan of a single layer of single chip could be as complex as the street map of New York. Minimum features sizes have gone down quite a bit since then. 
>
> > > "Cheap" is relative and you haven't really looked at the total price. For example you seem to think supplying a 7 MHz clock and using a PLL to the MCU is somehow cheaper than the same process with an FPGA. The clock is not an expensive part by any means. 
>
> > Actually the Microchip dsPIC33EPxxxSP50X does seem to have an internal RC oscillator, which would probably be good enough for what I need to do. The circuit has to drive the resonant tank at (or just below) it's resonant frequency and the control loop could also cope with drift in the internal oscillator frequency. 
> > > Likewise, a one input ADC is not an expensive part either. 
> > Clearly. 
> > > So you are not looking for cheap as much as "cheapest possible". 
>
> > I'm actually looking for "simple" and it looks as if the Microchip part would cost about as much as the Si3440DV MOSFet switches, which is cheap enough.
>
> The trouble is this has become a bit of the X/Y problem. You ask for X when you are really trying to do Y. "Simple" has no definition, so you can't really expect to get good advice.

"Simple" - in this context - was a fast fast micro-controller that wasn't designed to do signal processing. I didn't want to pay for options I didn't, or cope with the power consumed by signal processing hardware that I didn't want to use. You figured that it was the kind of problem that needs a micro-controller rather than thinking about the problem I am trying to solve

<snip>

> > > So it would appear you asked for "simple" but really want minimum price. 

What I explicitly asked for was a fast single chip processor that wasn't weighed down with digital signal processing hardware. You don't seem to have taken that on board.
 
> > > Sigma-delta converters are often the choice for FPGAs, but successive approximation is easily done as well. The hard part is the DAC output you need. 
>
> > I don't need a DAC at all. All the micro-controller would do would change the period of the square wave-drive to keep it at (or just below) the resonant frequency of the tank circuit
> I guess you aren't following the ideas. To implement a successive approximation ADC you need a DAC.

If the successive approximation converter it is buried inside the micro-controller, I get the DAC with micro-controller. If I remember rightly, Siemens did one where the DAC part was a bunch of capacitors (capacitance defined by the lithography) so no 0.1% resistors at all.

> You set the msb to the DAC and if the comparator indicates the DAC output is greater than the ADC input, you back off that bit and set the next lesser bit. lather, rinse, repeat. With an adequately fast DAC you can get MHz sample rates. This is what they are most likely using in the MCUs at 500 kSPS and 12 bits.

Perhaps. Why would I care how they did it?

> > > You can get 0.1% resistors for an R-2R ladder without too high a price. It's not clear if that would be adequate or not. The I/O supplies on each bank of FPGA I/Os are separate, so noise from the FPGA internals is minimal. 
> >
> > I do know about 0.1% resistors. I've specified lots of them. This isn't an application that seems to need them.
>
> Yeah, as I said, you aren't following the concepts.

Not the concept that you have decided that I ought to be worrying about.

> > > I seem to recall a 100 MHz 8051 created some years ago with the same idea as the propeller that peripherals can be implemented in software. Anyone remember that? 
> >
> > A 100MHz 8051 would do exactly what I need. At one point I spent a couple of weeks learning about 8051 assembler - it's a pretty rudimentary processor, but does everything I'd need .
> > > There's also the various Cypress PSOC lines with an emphasis on low cost by trading off fixed peripherals for programmable analog and logic. The processor may not run at 100 MHz, but if you can off load some of the heavy lifting to the programmable portions maybe the lower clock rate is good enough. 
> >
> > The idea is is to get two roughly 100kHz square waves. With a 100MHz clock, that's a 10-bit counter. Since there is +/17% tolerance on that 100kHz resonant frequency, you might need 11-bits to cope with the worst case. You then have tweak that "100kHz" to fit the tank circuit you've got, and keep tweaking it track the actual resonant frequency as it cahnges withb load and room temperature. It's not rocket science.
>
> Yes, I'm sure it's not, but what you describe does not explain how you get from &plusmn;17% to 11 bits of resolution on a 100 kHz output counter. If you want to explain enough for others to understand, fine. If not, that's fine too. 

100kHz is a 10usec clock period. To divide a 100MHz clock down to 100kHz you need to count  1000 edges - not quite 2^10 (1024). If  I needed 17% slower clock (83kHz) I'd need to count 1170 edges (more than 1024) so I'd need a 11-bit counter which could get up to 2048.
 
> But as I have said very clearly, this is all a slam dunk in an FPGA unless there are parts to the design you aren't explaining. That's what I think of when someone asks for "simple", something that is easy and straight forward to implement. 

If I've got to add bits to a FPGA that I'd get built into the microcontroller, life becomes less simple. You don't seem to have grasped this.

-- 
Bill Sloman, Sydney

On Sunday, July 4, 2021 at 10:39:54 AM UTC+10, gnuarm.del...@gmail.com wrote:
> On Saturday, July 3, 2021 at 8:35:49 PM UTC-4, Clifford Heath wrote: 
> > On 4/7/21 5:55 am, Tom Gardner wrote: 
> > > You still can, for the 32-core 4000MIPS xCORE processors. 
> > > 
> > > In fact the IDE will tell you the exact max timings from 
> > > here to there in you, for /all/ of the code paths in between. 
> > What you just said implies that they have solved the halting problem. 
> > 
> > Which makes it clear that you are more enthusiastic than factual. 
> > 
> > It still sounds like they have a nice feature there, even if it cannot 
> > do what you say.
> What you just said shows you don't understand the halting problem. Can you state it in a few words? Maybe that will help you understand why your claim is not correct. 

The halting problem - as discussed by Turing in 1936 - is that you can't work out whether an arbitrary computer program will ever halt. It may get stuck in an endless loop.

The claim that the IDE "will tell you the exact max timings from  here to there in you, for /all/ of the code paths in between" does imply that you can work out all the possible paths, which does seem to be over-optimistic.

-- 
Bill Sloman, Sydney

On Saturday, July 3, 2021 at 5:21:21 AM UTC+10, Fred Bloggs wrote:
> On Friday, July 2, 2021 at 1:33:59 AM UTC-4, bill....@ieee.org wrote: 
> > I've been thinking about Timo's inverter, and it looks as if a micro-controller that offered a 100MHz clock rate would be fast enough to do a decent job of switching the Siliconix Si3440DV DMOSFet that I fancy. 
> > 
> > I've found a PIC part that's fast enough, and pretty cheap, but it is designed for digital signal processing, which makes it more complicated than necessary. A nice, dumb but quick 8051 would be good enough. 
> > 
> > Somebody is apparently offers a 600MHz part, but I want something cheap and simple - if fairly fast (but not that fast). Browsing element-14 threw up a few candidates, but I didn't find their search engine all that helpful. 
> > 
> > Has anybody got a favourite part?
>
> Who would know what Timo's inverter is? 

Anybody who had looked at the the thread "Low noise, high bias voltage on picoAmp TIA's input, howto?" which started on the 21st May, and has had 66 posts and 480 views.

> 100 MHz is difficult to work with in any case. 

Not if it is confined inside a micro-controller.

I've been looking at the Microchip dsPIC33EP parts, and they seem to offer a 7.4MHz internal oscillator, an internal VCO which can get up to 120MHz, and a "divide by n" option which can let you lock the divided output of the VCO to the 7.4MHz internal clock. So I'd have a choice of 96.2MHz or 103.6 MHz. The internal oscillator can be tweaked up or down by up to about 0.5% in steps of about 0.03%.

There a PWM outputs that could let me divide this down to 83kHz to 117kHz range that I'd need. It all seems to be doable inside the micro-controller.

I have worked with an 800MHz system clock, and I do know the problems that this entails (and how to solve them), but here the problems are safely buried inside the bought-in part.

-- 
Bill Sloman, Sydney

On 7/3/2021 5:35 PM, Clifford Heath wrote:
> On 4/7/21 5:55 am, Tom Gardner wrote:
>> You still can, for the 32-core 4000MIPS xCORE processors.
>>
>> In fact the IDE will tell you the exact max timings from
>> here to there in you, for /all/ of the code paths in between.
> 
> What you just said implies that they have solved the halting problem.
> 
> Which makes it clear that you are more enthusiastic than factual.

I suspect the claim is that it will evaluate the costs of
all paths between two points *known* to be reachable -- and without
concern for the actual values/conditions that must be satisfied
for a path to be traversed.  (i.e., at any conditional, it will
evaluate "let's assume this is true; then let's assume false"
without synthesizing the actual conditions required for those
results)

E.g., it is possible that there is NO path between two points,
even if the code does "halt" (e.g., dead code).

OTOH, if the developer can rely on his own knowledge of how
the code works, then being able to automate this tabulation
would be a win (if you are counting cycles, then there is
obviously a reason for doing so!)

[I recall such a code snippet from a product that had to push
*bits* into a CVSD at a constant rate.  The hardware designers
(in their ignorance of the software costs) had opted to skimp
a bit and force the software to serialize the bit stream from
the BYTE stream where it would be sourced.  So, this *tight* loop
had to shift bits out AND ensure the time between bits was
constant, even as the code had to retrieve NEXT BYTES to do so.]

> It still sounds like they have a nice feature there, even if it cannot do what 
> you say.

Likely the same sort of technology used for automatic test coverage
generation.  In those cases, the tool would actually synthesize the
data to force each branch to be exercised (and, detect branches that
couldn't be reached due to the conditions imposed upstream).

I'd question how realistic the assessment would be in light of unknown states
of cache, memory/peripheral access times, etc.  It seems any such tool would
need to know A LOT about the implementation (or, for the implementation to be
very homogeneous)

On 04/07/21 01:35, Clifford Heath wrote:
> On 4/7/21 5:55 am, Tom Gardner wrote:
>> You still can, for the 32-core 4000MIPS xCORE processors.
>>
>> In fact the IDE will tell you the exact max timings from
>> here to there in you, for /all/ of the code paths in between.
> 
> What you just said implies that they have solved the halting problem.
> 
> Which makes it clear that you are more enthusiastic than factual.
> 
> It still sounds like they have a nice feature there, even if it cannot do what 
> you say.
> 
> CH

Unfortunately no magic is involved :(

The devices are not general purpose but are aimed
at the technically interesting and commercially
important cases of hard realtime embedded processors.

You can download the IDE (Windows, Linux) and see what
it can do, including allowing you to define performance
without any hardware. Try that with other processors!

Don't trust me, see
https://www.xmos.ai/download/xTIMEcomposer-User-Guide-14(14.x).pdf
which includes...


Under some conditions the timing analyzer is unable to
prove timing without additional information. Examples
of common conditions include:
  * The route contains an I/O instruction that can pause for an unknown length of
time.
  * The route contains a loop with a data-dependent exit condition.
  * A path fails to meet timing, but the path is only executed as a result of an 
error condition and is not therefore timing critical.

In these cases you can provide the timing analyzer
additional information about the execution of your
program. Armed with this additional information,
the analyzer may then be able to prove that a route’s
timing requirement is met. Information you can provide
includes:
...

On 04/07/21 08:17, Don Y wrote:
> On 7/3/2021 5:35 PM, Clifford Heath wrote:
>> On 4/7/21 5:55 am, Tom Gardner wrote:
>>> You still can, for the 32-core 4000MIPS xCORE processors.
>>>
>>> In fact the IDE will tell you the exact max timings from
>>> here to there in you, for /all/ of the code paths in between.
>>
>> What you just said implies that they have solved the halting problem.
>>
>> Which makes it clear that you are more enthusiastic than factual.
> 
> I suspect the claim is that it will evaluate the costs of
> all paths between two points *known* to be reachable -- and without
> concern for the actual values/conditions that must be satisfied
> for a path to be traversed.  (i.e., at any conditional, it will
> evaluate "let's assume this is true; then let's assume false"
> without synthesizing the actual conditions required for those
> results)
> 
> E.g., it is possible that there is NO path between two points,
> even if the code does "halt" (e.g., dead code).
> 
> OTOH, if the developer can rely on his own knowledge of how
> the code works, then being able to automate this tabulation
> would be a win (if you are counting cycles, then there is
> obviously a reason for doing so!)
> 
> [I recall such a code snippet from a product that had to push
> *bits* into a CVSD at a constant rate.  The hardware designers
> (in their ignorance of the software costs) had opted to skimp
> a bit and force the software to serialize the bit stream from
> the BYTE stream where it would be sourced.  So, this *tight* loop
> had to shift bits out AND ensure the time between bits was
> constant, even as the code had to retrieve NEXT BYTES to do so.]
> 
>> It still sounds like they have a nice feature there, even if it cannot do what 
>> you say.
> 
> Likely the same sort of technology used for automatic test coverage
> generation.  In those cases, the tool would actually synthesize the
> data to force each branch to be exercised (and, detect branches that
> couldn't be reached due to the conditions imposed upstream).
> 
> I'd question how realistic the assessment would be in light of unknown states
> of cache, memory/peripheral access times, etc.  It seems any such tool would
> need to know A LOT about the implementation (or, for the implementation to be
> very homogeneous)

Caches and interrupts make the problem impossible!

The xCORE devices don't have caches and don't need
interrupts: you simply dedicate one (of many) core to
an i/o port.

No, they are not general purpose: they target *hard*
realtime embedded applications.

It is easy to guarantee the low-level hard timings
in a chip which is simultaneously:
  - communicating with a PC via USB (or ethernet)
  - doing front panel i/o
  - sucking/blowing bits through an i/o port

On 4/7/21 10:39 am, Rick C wrote:
> On Saturday, July 3, 2021 at 8:35:49 PM UTC-4, Clifford Heath wrote:
>> On 4/7/21 5:55 am, Tom Gardner wrote:
>>> You still can, for the 32-core 4000MIPS xCORE processors.
>>>
>>> In fact the IDE will tell you the exact max timings from
>>> here to there in you, for /all/ of the code paths in between.
>> What you just said implies that they have solved the halting problem.
>>
>> Which makes it clear that you are more enthusiastic than factual.
>>
>> It still sounds like they have a nice feature there, even if it cannot
>> do what you say.
> 
> What you just said shows you don't understand the halting problem.  Can you state it in a few words?  Maybe that will help you understand why your claim is not correct.
> 

If you know how to compute the upper limit of execution time of some 
arbitrary bit of code, you know how to solve the halting problem. It's 
the same problem.

On 4/7/21 6:06 pm, Tom Gardner wrote:
> On 04/07/21 01:35, Clifford Heath wrote:
>> What you just said implies that they have solved the halting problem.
> Under some conditions the timing analyzer is unable to
> prove timing without additional information. Examples
> of common conditions include:
>   * The route contains a loop with a data-dependent exit condition.


^^^^^ This is the halting problem

CH

On 04/07/21 09:50, Clifford Heath wrote:
> On 4/7/21 6:06 pm, Tom Gardner wrote:
>> On 04/07/21 01:35, Clifford Heath wrote:
>>> What you just said implies that they have solved the halting problem.
>> Under some conditions the timing analyzer is unable to
>> prove timing without additional information. Examples
>> of common conditions include:
>>   * The route contains a loop with a data-dependent exit condition.
> 
> 
> ^^^^^ This is the halting problem
> 
> CH

Yup :)

Nonetheless, in the targeted application domain,
the IDE (or command line tools) give useful results
that you can't get for other processors.

On 7/4/2021 1:13 AM, Tom Gardner wrote:
> On 04/07/21 08:17, Don Y wrote:
>> On 7/3/2021 5:35 PM, Clifford Heath wrote:
>>> On 4/7/21 5:55 am, Tom Gardner wrote:
>>>> You still can, for the 32-core 4000MIPS xCORE processors.
>>>>
>>>> In fact the IDE will tell you the exact max timings from
>>>> here to there in you, for /all/ of the code paths in between.
>>>
>>> What you just said implies that they have solved the halting problem.
>>>
>>> Which makes it clear that you are more enthusiastic than factual.
>>
>> I suspect the claim is that it will evaluate the costs of
>> all paths between two points *known* to be reachable -- and without
>> concern for the actual values/conditions that must be satisfied
>> for a path to be traversed.  (i.e., at any conditional, it will
>> evaluate "let's assume this is true; then let's assume false"
>> without synthesizing the actual conditions required for those
>> results)
>>
>> E.g., it is possible that there is NO path between two points,
>> even if the code does "halt" (e.g., dead code).
>>
>> OTOH, if the developer can rely on his own knowledge of how
>> the code works, then being able to automate this tabulation
>> would be a win (if you are counting cycles, then there is
>> obviously a reason for doing so!)
>>
>> [I recall such a code snippet from a product that had to push
>> *bits* into a CVSD at a constant rate.  The hardware designers
>> (in their ignorance of the software costs) had opted to skimp
>> a bit and force the software to serialize the bit stream from
>> the BYTE stream where it would be sourced.  So, this *tight* loop
>> had to shift bits out AND ensure the time between bits was
>> constant, even as the code had to retrieve NEXT BYTES to do so.]
>>
>>> It still sounds like they have a nice feature there, even if it cannot do 
>>> what you say.
>>
>> Likely the same sort of technology used for automatic test coverage
>> generation.  In those cases, the tool would actually synthesize the
>> data to force each branch to be exercised (and, detect branches that
>> couldn't be reached due to the conditions imposed upstream).
>>
>> I'd question how realistic the assessment would be in light of unknown states
>> of cache, memory/peripheral access times, etc.  It seems any such tool would
>> need to know A LOT about the implementation (or, for the implementation to be
>> very homogeneous)
> 
> Caches and interrupts make the problem impossible!

...*if* you can't specify the current state of the cache (or
the likelihood of an ISR).  But, where that is important to
the solution, you often *can* (because you drive these things
to known states)

> The xCORE devices don't have caches and don't need
> interrupts: you simply dedicate one (of many) core to
> an i/o port.
> 
> No, they are not general purpose: they target *hard*
> realtime embedded applications.

But HRT is boring.  The majority of RT problems are soft.
And, there, the challenge is deciding which schedule
will yield the "best value".

With HRT, it works -- or it doesn't.  It's why practitioners want
to push so many problems into the HRT domain than are strictly
necessary:  "I *need* X, Y and Z..." instead of "If I had to
prioritize the values of these subtasks, they would be..."

Extra credit if you can sort out the subtasks that *won't*
complete on-time and elide them from your workload BEFORE
wasting resources on them (those resources likely allowing
other subtasks to complete that wouldn't, otherwise)!

Tying SPC into an RT problem gives you even more ways of
"optimizing" your solution without overprovisioning.

[Why aren't there *5* backup computers on the Hubble?
Clearly, what they "settled for" was not enough...]

> It is easy to guarantee the low-level hard timings
> in a chip which is simultaneously:
>   - communicating with a PC via USB (or ethernet)
>   - doing front panel i/o
>   - sucking/blowing bits through an i/o port