Fast simple microcontroller

On Sunday, July 4, 2021 at 10:08:06 AM UTC-4, bill....@ieee.org wrote:
> On Sunday, July 4, 2021 at 11:07:08 PM UTC+10, gnuarm.del...@gmail.com wrote: 
> > On Saturday, July 3, 2021 at 10:34:16 PM UTC-4, bill....@ieee.org wrote: 
> > > 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: 
> > > > > > 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 
> > 
> > Hmmm... you seem to have reversed rolls. You just defined "simple" in terms of an MCU and then claim I am trying to push you into an MCU???!!! I'm telling you an FPGA is a more simple way to solve your problem by normal definitions of "simple".
> It's more parts - at least in the problem that I'm talking about.

Right, but "more parts" is not typically a matter of "simplicity" either unless the disparity gets to be huge.  But the reality is you don't know how many parts will be needed because you don't have anything remotely like a design.  A typical board design has some 10x or 20x times the part count as they do the IC count.  Is this where you go back to cost in place of "simple"? 


> > I don't know enough about your problem to solve it for you, but the info you've provided clearly in this thread shows an FPGA is a perfect tool for the job as many others have said.
> It would do part of the job perfectly, but a fast micro-controller would do rather more of it.
> > You shot that down by saying FPGAs are not "simple" enough and define "simple" as being the perfect MCU.
> What I was asking for was fast microcontroller - as fast as the Microchip dsPIC33EPxxxSP50X and simpler in not including the digital signal processing parts which I don't actually need. 
> 
> The subject line is "Fast simple microcontroller". I wasn't asking for a simple solution to a problem, but a simple example of a particular part

I also pointed you to some MCUs that you don't appear to have followed up on.  Someone else mentioned the PSOC devices as well.  Did you look at any of those?  You seem to be very focused on the dsPIC in spite of it being more complex because it has features you don't need.  I hate to tell you, but every MCU is going to have features you don't need.  

One thing that is common with less experienced designers is to try to optimize a design early in the process.  It would not be a bad idea to get an eval board with the dsPIC and prototype a design.  See if it really has potential or if there are issues you have missed. 


> > Yes, by that definition an FPGA will not be "simple" unless you design an MCU in the FPGA perhaps. I think sequentially executing processors have inherent limitations that make coding them complex as soon as you have more than one asynchronous tasks. This is a very simple problem to solve in an FPGA with much simpler timing constraints.
> Since whatever the problem you want to talk about doesn't have much to do with the problem that I am tackling, this isn't a useful observation.

Ok, so you don't want to discuss your approach.  Got it. 


> > > > > > 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. 
> > Oh, yes, and I'm trying to explain that an MCU may not be the best choice of tool to solve this problem. You said you wanted a "simple" solution and now have defined "simple" as being an MCU. Ok, I can't argue that point if that is your definition of what you want. Have at it. 
> > 
> > But I can make the point that such a definition of "simple" means you do not wish to consider other methods that may produce a better solution with less effort and less risk and remain within some given cost range. That's my idea of "simple" even if it's not yours. 
> > > > > > 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. 
> > Irrelevant. Now you understand why the DAC is needed in the FPGA solution if you don't want to add a low cost ADC chip. So you add a few resistors to the design and viola, you have an ADC that runs fast enough for your sampling requirement. So adding an ADC to an FPGA costs maybe $0.10. 
> > > > 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? 
> > Exactly. You don't. Just as you don't care that it is easy to add an ADC to an FPGA using resistors. 
> > > > > > 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'm just answering your questions. You did come here to ask questions, no? You didn't seem to understand that a DAC is required to make a successive approximation ADC, so I explained that to you. Now you seem to be getting defensive. If you don't want answers, why do you ask the questions?
> Of course I understand that, but the successive approximation A/D converter built into many micro-controllers does include that DAC, so I don't have to worry about i.

Of course, but you failed to understand that when I initially talked about it. 


> > > > > > 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 chnges 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 ±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. 
> > 
> > Ok, so you are just talking implementation details.
> You asked for an explanation.

Yes, thank you. 


> >You only need 10 us resolution. Fine.
> I want a roughly 10usec clock period. It's got to match the resonant frequency of a tank circuit to rather better than 1%, possibly 0.1% so I want a 10MHz c;\lock to get a resolution of 10nsec.
> > You can have an 11 bit counter in an FPGA. No problem. In most MCUs the counters are multiples of 8 bits, so no problem there either. 
> > 
> > > > 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. 
> > 
> > ??? I don't consider it to be anything other than simple to add the "bits" you seem to be talking about.
> Since when does adding extra components make a design simpler?

The overall approach can be simpler when using more parts if those parts are very simple to use.  That has been my point from the start, emulating multiple processors using a single processor can make programming complex.  In an FPGA each process runs on dedicated hardware (processor) making the design process very simple.  If you add an ADC chip or a few resistors, that doesn't make a design other than "simple" except by your definition of including an MCU. 


> > I haven't seen a clear explanation of the calculations you need to do and I have seen no description of the processing flow with timing.
> You could find them on the thread "Low noise, high bias voltage on picoAmp TIA's input, howto?". Not all that clearly spelled out because it is a pretty simple circuit. 

I'm going to pass on that.  Reading entire threads to get the info that could probably be indicated in a couple of paragraphs is not my responsibility.  


> >These are the complex matters in the design. Banging out a counter or even a UART in HDL is pretty simple no matter what. What "bits" do you see as being not simple? Or are you just going to hand wave "all of them"?
> They aren't complex matter in this design
> > Please keep in mind this is just a conversation. No one is attacking you. Batting around ideas. But if you reject ideas without consideration you are cutting off a branch of potential solutions. Perhaps the issue is that you are not comfortable with HDL coding?
> I've never used HDL coding. It's got to be more comfortable than the primitive schemes I have used. I do a text on the subject on my bookshelf, but that project evaporated before I'd read much of it. 

There's not much you need to learn other than to get familiar with the idea that HDLs (hardware description languages) describe hardware rather than get translated to sequentially executing instructions.  VHDL is a bit like ADA where you must explicitly convert between types and Verilog is a bit like C where it lets you shoot yourself in the foot.  Choose your poison, or maybe I should say, how's your aim? 

Whatever.  It's pretty clear you want to use the dsPIC.  Why not just go with it for a first pass.  Once you know more about the solution then you can pic the perfect device and maybe the semiconductor shortage will be over and your choices will be much wider? 

-- 

Rick C.

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

On 7/4/2021 6:14 AM, Martin Brown wrote:
>> 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.
> 
> Working out all possible paths for a given set of code is a relatively easily 
> solved problem. McCabes CCI complexity metric does exactly that. Every decision 
> point becomes a node and the code inbetween a line on a graph whose length can 
> be proportional to execution time.

But you can't put an execution time on those lines unless you know the
*data* values associated.  I.e., you can tell me that the time "around"
a loop of code; but you can't know how many times that loop will be
executed and, thus, the total time that it will take to GET PAST it.

> For most paths between decision points you can work out a minimum and maximum 
> number of machine cycles it is likely to take. Where it gets very tricky though 
> is when branch prediction and speculative execution is involved. Classical 
> gofaster code like loop unrolling can even go slower if it no longer fits 
> nicely into execution cache.
> 
> Even working out a minimal subset of CCI test vectors that will execute every 
> possible path at least once is still pretty simple to do. And also quite 
> worthwhile since the last bugs tend to reside in the least trodden paths (which 
> turn out to be in rare but vital critical error recovery).

Tools like KLEE can be used to help create test cases to exercise branches.
But, you still can't guarantee that every path WILL be traversed as that
implies there are no bugs in the code that prevent that from happening:

      if (x odd) {
          if (x even) {
              foo;
          } else {
              bar;
          }
      }

there's no set of inputs that will reach "foo".   So, any metric that provides
a time for that "foo" branch is meaningless -- we KNOW it will never happen.

> What *is* impossible is showing that a program will always terminate in finite 
> time for every possible set of inputs.

On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote:
> On Sunday, July 4, 2021 at 7:10:04 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > On Sunday, July 4, 2021 at 9:49:24 AM UTC-4, Ed Lee wrote: 
> > > On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > > > > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > > > > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > > > > > > > the FPGA design, with the CPU running whatever code to make a menu you 
> > > > > > > > would have put on a micro, (but with peripherals that do exactly 
> > > > > > > > whatever fast logic you need, unlike those on most microcontrollers), 
> > > > > > > > though there are much more efficient ways. 
> > > > > > > But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA. 
> > > > > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > > > > And with timer and interrupt to wakeup? Which one? 
> > > > There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current. 
> > > Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated. To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage. There is no ADCs or comparators, they will be external. Very soon, we are talking about board level design rather than single chip solution. 
> > This is not an MCU, you don't "reprogram" the clock. You have a 32 kHz clock driving the logic that runs at 32 kHz and you have a fast clock driving the logic that runs fast. You *can* multiplex clocks to logic, but it typically is not done that way as there is little purpose. So the fast clock is disabled in some way that matches your turn on time requirements and power consumption requirements just as with an MCU.
> So, FPGA is not same as micro in power management. STM32F4 can sleep in 100uA and run at full speed of 180MHz, or somewhere in between.

Sorry, I have no idea what you are trying to say.  FPGAs can run at any rate you clock them at given the data sheet restrictions.  They typically contain PLLs which can adjust clock rates.  What are you talking about exactly?  


> > > The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end. For that, you have to go with BGAs. Xilinx and Altera FPGAs are in millions of LUTs. 
> > Sorry, but just as you are never going to sleep an Intel megalith processor at 100 uA, you aren't going to sleep a megalith FPGA at 100 uA. I thought you were talking about smaller devices that can run with low power and sleep with very low power.
> We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter.

How many LUTs is that?  10, 1,000, 100,000?  

I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. 

I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. 

-- 

Rick C.

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

On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: 
> > On Sunday, July 4, 2021 at 7:10:04 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > On Sunday, July 4, 2021 at 9:49:24 AM UTC-4, Ed Lee wrote: 
> > > > On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > > > > > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > > > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > > > > > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > > > > > > > > the FPGA design, with the CPU running whatever code to make a menu you 
> > > > > > > > > would have put on a micro, (but with peripherals that do exactly 
> > > > > > > > > whatever fast logic you need, unlike those on most microcontrollers), 
> > > > > > > > > though there are much more efficient ways. 
> > > > > > > > But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA. 
> > > > > > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > > > > > And with timer and interrupt to wakeup? Which one? 
> > > > > There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current. 
> > > > Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated. To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage. There is no ADCs or comparators, they will be external. Very soon, we are talking about board level design rather than single chip solution. 
> > > This is not an MCU, you don't "reprogram" the clock. You have a 32 kHz clock driving the logic that runs at 32 kHz and you have a fast clock driving the logic that runs fast. You *can* multiplex clocks to logic, but it typically is not done that way as there is little purpose. So the fast clock is disabled in some way that matches your turn on time requirements and power consumption requirements just as with an MCU. 
> > So, FPGA is not same as micro in power management. STM32F4 can sleep in 100uA and run at full speed of 180MHz, or somewhere in between.
> Sorry, I have no idea what you are trying to say. FPGAs can run at any rate you clock them at given the data sheet restrictions. They typically contain PLLs which can adjust clock rates. What are you talking about exactly?

Self adjusting clock rate.  Micro can stop most clocks, except the timer, and sleep.

> > > > The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end. For that, you have to go with BGAs. Xilinx and Altera FPGAs are in millions of LUTs. 
> > > Sorry, but just as you are never going to sleep an Intel megalith processor at 100 uA, you aren't going to sleep a megalith FPGA at 100 uA. I thought you were talking about smaller devices that can run with low power and sleep with very low power. 
> > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter.
> How many LUTs is that? 10, 1,000, 100,000? 

An 8051 would need more than 7680.

> 
> I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. 
> 
> I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. 

Perhaps some, but not all features.  It would be tough to do 100KHz sampling loop and low long term power budget with FPGA.

On Monday, July 5, 2021 at 12:31:25 AM UTC+10, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 10:08:06 AM UTC-4, bill....@ieee.org wrote:
> > On Sunday, July 4, 2021 at 11:07:08 PM UTC+10, gnuarm.del...@gmail.com wrote: 
> > > On Saturday, July 3, 2021 at 10:34:16 PM UTC-4, bill....@ieee.org wrote: 
> > > > 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: 
> > > > > > > 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 
> > > 
> > > Hmmm... you seem to have reversed rolls. You just defined "simple" in terms of an MCU and then claim I am trying to push you into an MCU???!!! I'm telling you an FPGA is a more simple way to solve your problem by normal definitions of "simple".
> > It's more parts - at least in the problem that I'm talking about. 
> 
> Right, but "more parts" is not typically a matter of "simplicity" either unless the disparity gets to be huge. But the reality is you don't know how many parts will be needed because you don't have anything remotely like a design. A typical board design has some 10x or 20x times the part count as they do the IC count. Is this where you go back to cost in place of "simple"?
> > > I don't know enough about your problem to solve it for you, but the info you've provided clearly in this thread shows an FPGA is a perfect tool for the job as many others have said.
> > It would do part of the job perfectly, but a fast micro-controller would do rather more of it.
> > > You shot that down by saying FPGAs are not "simple" enough and define "simple" as being the perfect MCU.
> > What I was asking for was fast microcontroller - as fast as the Microchip dsPIC33EPxxxSP50X and simpler in not including the digital signal processing parts which I don't actually need. 
> > 
> > The subject line is "Fast simple microcontroller". I wasn't asking for a simple solution to a problem, but a simple example of a particular part 
> 
> I also pointed you to some MCUs that you don't appear to have followed up on. Someone else mentioned the PSOC devices as well. Did you look at any of those? You seem to be very focused on the dsPIC in spite of it being more complex because it has features you don't need. I hate to tell you, but every MCU is going to have features you don't need. 
> 
> One thing that is common with less experienced designers is to try to optimize a design early in the process. It would not be a bad idea to get an eval board with the dsPIC and prototype a design. See if it really has potential or if there are issues you have missed.
> > > Yes, by that definition an FPGA will not be "simple" unless you design an MCU in the FPGA perhaps. I think sequentially executing processors have inherent limitations that make coding them complex as soon as you have more than one asynchronous tasks. This is a very simple problem to solve in an FPGA with much simpler timing constraints.
> > Since whatever the problem you want to talk about doesn't have much to do with the problem that I am tackling, this isn't a useful observation. 
> 
> Ok, so you don't want to discuss your approach. Got it.
> > > > > > > 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. 
> > > Oh, yes, and I'm trying to explain that an MCU may not be the best choice of tool to solve this problem. You said you wanted a "simple" solution and now have defined "simple" as being an MCU. Ok, I can't argue that point if that is your definition of what you want. Have at it. 
> > > 
> > > But I can make the point that such a definition of "simple" means you do not wish to consider other methods that may produce a better solution with less effort and less risk and remain within some given cost range. That's my idea of "simple" even if it's not yours. 
> > > > > > > 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. 
> > > Irrelevant. Now you understand why the DAC is needed in the FPGA solution if you don't want to add a low cost ADC chip. So you add a few resistors to the design and viola, you have an ADC that runs fast enough for your sampling requirement. So adding an ADC to an FPGA costs maybe $0.10. 
> > > > > 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? 
> > > Exactly. You don't. Just as you don't care that it is easy to add an ADC to an FPGA using resistors. 
> > > > > > > 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'm just answering your questions. You did come here to ask questions, no? You didn't seem to understand that a DAC is required to make a successive approximation ADC, so I explained that to you. Now you seem to be getting defensive. If you don't want answers, why do you ask the questions? 
>
> > Of course I understand that, but the successive approximation A/D converter built into many micro-controllers does include that DAC, so I don't have to worry about i. 
> 
> Of course, but you failed to understand that when I initially talked about it.

Really? I'd already posted  " 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." which  you dismisseded as "irrelevant"

<snipped the rest. I posted a simple question, which you don't seem to able to answer, and  you want to keep telling me that I ought to use an FPGA, which strikes me as being distinctly unhelpful>

-- 
Bill Sloman, Sydney

On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote:
> On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: 
> > > On Sunday, July 4, 2021 at 7:10:04 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > On Sunday, July 4, 2021 at 9:49:24 AM UTC-4, Ed Lee wrote: 
> > > > > On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > > On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > > > > > > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > > > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > > > > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > > > > > > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > > > > > > > > > the FPGA design, with the CPU running whatever code to make a menu you 
> > > > > > > > > > would have put on a micro, (but with peripherals that do exactly 
> > > > > > > > > > whatever fast logic you need, unlike those on most microcontrollers), 
> > > > > > > > > > though there are much more efficient ways. 
> > > > > > > > > But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA. 
> > > > > > > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > > > > > > And with timer and interrupt to wakeup? Which one? 
> > > > > > There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current. 
> > > > > Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated. To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage. There is no ADCs or comparators, they will be external. Very soon, we are talking about board level design rather than single chip solution. 
> > > > This is not an MCU, you don't "reprogram" the clock. You have a 32 kHz clock driving the logic that runs at 32 kHz and you have a fast clock driving the logic that runs fast. You *can* multiplex clocks to logic, but it typically is not done that way as there is little purpose. So the fast clock is disabled in some way that matches your turn on time requirements and power consumption requirements just as with an MCU. 
> > > So, FPGA is not same as micro in power management. STM32F4 can sleep in 100uA and run at full speed of 180MHz, or somewhere in between. 
> > Sorry, I have no idea what you are trying to say. FPGAs can run at any rate you clock them at given the data sheet restrictions. They typically contain PLLs which can adjust clock rates. What are you talking about exactly?
> Self adjusting clock rate. Micro can stop most clocks, except the timer, and sleep.

This is why you are very hard to talk to.  Those are two independent things, self adjusting clock rate and stopping and starting clocks.   Not sure exactly what you mean by self-adjusting clock rates, but you probably mean that the clocks can be stopped.  FPGAs do that as well with total flexibility.  You construct your circuits to run from the clocks you choose.  So if the BLAH peripheral needs to be on the same clock as the CPU, do that.  If the BLORG and BLARF peripherals need to be on the same clock, do that.  Have it your way.  Shut them off when you want by what circuit is most suited for that. 


> > > > > The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end. For that, you have to go with BGAs. Xilinx and Altera FPGAs are in millions of LUTs. 
> > > > Sorry, but just as you are never going to sleep an Intel megalith processor at 100 uA, you aren't going to sleep a megalith FPGA at 100 uA. I thought you were talking about smaller devices that can run with low power and sleep with very low power. 
> > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. 
> > How many LUTs is that? 10, 1,000, 100,000?
> An 8051 would need more than 7680.
I don't think that is right, but if so, another CPU would be advised.  The sort of stack processors that are often used on FPGAs are as small as 500 LUTs.  But why use a processor if it's not required?  The point is everything I've heard about this does not require a processor at all. 


> > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. 
> > 
> > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily.
> Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA.

Again, you know nothing about it.  A 100 MHz timer is a very low power entity.  The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length.  Add a comparator and you get 2 FF equivalent at 100 MHz.  Not much current there.  Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). 

What else is going on in the design that would use much power?  

You should ask questions rather than making statements you don't know are right.  So far you have shown you know literally nothing about FPGAs in use in the real world.  

-- 

Rick C.

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

On Sunday, July 4, 2021 at 11:03:15 AM UTC-4, bill....@ieee.org wrote:
> 
> <snipped the rest. I posted a simple question, which you don't seem to able to answer, and you want to keep telling me that I ought to use an FPGA, which strikes me as being distinctly unhelpful> 

Dude!  Why don't you stop bickering about the petty little crap and try to pay attention to what people write rather than what little offenses you perceive?  I told you at least twice if not three times to look at the Cypress PSOC MCU parts.  I'm not going to do your leg work.  If you don't want to do any work on this, I'm not going to dig up the information for you. 

The PSOC devices have some amount of programmable digital and analog hardware with various processors.  You have said you want a 100 MHz clock to control the waveform outputs.  I have no idea what you need from the CPU itself.  If you can figure that out I suggest once more for you to take a look at the PSOC devices.  They may be just what you need.  Or the Greenpak parts too for that matter.  They don't have a CPU, but it's not clear if you need one or not. 

-- 

Rick C.

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

On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: 
> > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: 
> > > > On Sunday, July 4, 2021 at 7:10:04 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > On Sunday, July 4, 2021 at 9:49:24 AM UTC-4, Ed Lee wrote: 
> > > > > > On Saturday, July 3, 2021 at 5:37:45 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > > > On Saturday, July 3, 2021 at 8:19:39 PM UTC-4, Ed Lee wrote: 
> > > > > > > > On Saturday, July 3, 2021 at 5:17:50 PM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > > > > > On Saturday, July 3, 2021 at 11:04:33 AM UTC-4, Ed Lee wrote: 
> > > > > > > > > > On Saturday, July 3, 2021 at 6:30:21 AM UTC-7, Chris Jones wrote: 
> > > > > > > > > > > You could do it in an FPGA. Obviously you could put a CPU with UART in 
> > > > > > > > > > > the FPGA design, with the CPU running whatever code to make a menu you 
> > > > > > > > > > > would have put on a micro, (but with peripherals that do exactly 
> > > > > > > > > > > whatever fast logic you need, unlike those on most microcontrollers), 
> > > > > > > > > > > though there are much more efficient ways. 
> > > > > > > > > > But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA. 
> > > > > > > > > You need to learn about FPGAs before you post. That is simply not correct. There's more than one brand that has 100 uA or less sleep modes. 
> > > > > > > > And with timer and interrupt to wakeup? Which one? 
> > > > > > > There are some low idle current parts from the company that used to be Actel until they were bought by Microsemi who was bought by Microchip, Polar something I think. I never researched them much. The ones I know more about are the ICE40 parts from Lattice. There are some versions that have idle currents in the ~50 uA range. If you keep a fast clock running there will be additional current just like in an MCU. Run a slow clock for a timer and it will draw virtually no additional current. 
> > > > > > Yes, you can idle it at 50uA at 32KHz if the input and output are blocked and isolated. To wake it up and reprogram the clock at max of 48MHz, not sure if it can be done internally, or be reconfigured by an external storage. There is no ADCs or comparators, they will be external. Very soon, we are talking about board level design rather than single chip solution. 
> > > > > This is not an MCU, you don't "reprogram" the clock. You have a 32 kHz clock driving the logic that runs at 32 kHz and you have a fast clock driving the logic that runs fast. You *can* multiplex clocks to logic, but it typically is not done that way as there is little purpose. So the fast clock is disabled in some way that matches your turn on time requirements and power consumption requirements just as with an MCU. 
> > > > So, FPGA is not same as micro in power management. STM32F4 can sleep in 100uA and run at full speed of 180MHz, or somewhere in between. 
> > > Sorry, I have no idea what you are trying to say. FPGAs can run at any rate you clock them at given the data sheet restrictions. They typically contain PLLs which can adjust clock rates. What are you talking about exactly? 
> > Self adjusting clock rate. Micro can stop most clocks, except the timer, and sleep.
> This is why you are very hard to talk to. Those are two independent things, self adjusting clock rate and stopping and starting clocks. Not sure exactly what you mean by self-adjusting clock rates, but you probably mean that the clocks can be stopped. FPGAs do that as well with total flexibility. You construct your circuits to run from the clocks you choose. So if the BLAH peripheral needs to be on the same clock as the CPU, do that. If the BLORG and BLARF peripherals need to be on the same clock, do that. Have it your way. Shut them off when you want by what circuit is most suited for that.
> > > > > > The ICE40s are really very small, barely FPGA, topping out with 7680 LUTs at the high end. For that, you have to go with BGAs. Xilinx and Altera FPGAs are in millions of LUTs. 
> > > > > Sorry, but just as you are never going to sleep an Intel megalith processor at 100 uA, you aren't going to sleep a megalith FPGA at 100 uA. I thought you were talking about smaller devices that can run with low power and sleep with very low power. 
> > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. 
> > > How many LUTs is that? 10, 1,000, 100,000? 
> > An 8051 would need more than 7680.
> I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all.
> > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. 
> > > 
> > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. 
> > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA.
> Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). 

Perhaps you should read the datasheet also.  The ICE40 max out at 48MHz, it won't run at 100MHz.  And i never said it need 100MHz counter.  I only mention 100KHz sampling loop.  At 48MHz, we are talking about mA supply current, not uA.

On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote:
> On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: 
> > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: 
> > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. 
> > > > How many LUTs is that? 10, 1,000, 100,000? 
> > > An 8051 would need more than 7680. 
> > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. 
> > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. 
> > > > 
> > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. 
> > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. 
> > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count).
> Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA.

Sorry, you are reading the wrong data.  You might be looking at the configuration clock or something.  The internal logic runs at hundreds of MHz.  Go back and read some more. 

The 100 MHz comes from Bill.  It's his project after all. 

-- 

Rick C.

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

On Sunday, July 4, 2021 at 12:07:12 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 2:50:39 PM UTC-4, Ed Lee wrote: 
> > On Sunday, July 4, 2021 at 11:40:11 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > On Sunday, July 4, 2021 at 10:54:29 AM UTC-4, Ed Lee wrote: 
> > > > On Sunday, July 4, 2021 at 7:39:50 AM UTC-7, gnuarm.del...@gmail.com wrote: 
> > > > > On Sunday, July 4, 2021 at 10:24:24 AM UTC-4, Ed Lee wrote: 
> > > > > > We are talking about something that can fit in OP's app: 48V (or something, likely battery) to 220V inverter, and power budget matter. 
> > > > > How many LUTs is that? 10, 1,000, 100,000? 
> > > > An 8051 would need more than 7680. 
> > > I don't think that is right, but if so, another CPU would be advised. The sort of stack processors that are often used on FPGAs are as small as 500 LUTs. But why use a processor if it's not required? The point is everything I've heard about this does not require a processor at all. 
> > > > > I designed a circuit that decodes a B120 time code signal to a bit stream (as well as recreates it on the other end) then later added logic to add a digital input multiplexed with the time code as well as multiple sample rate, two channels of audio input and output with mulaw and A-law encoding/decoding and various test functions in a 3kLUT device with no multipliers. 
> > > > > 
> > > > > I've not heard a very complete description of the task (there are often many details left out of such a conversation) but it sounds to me like a 1kLUT device would do the job easily. 
> > > > Perhaps some, but not all features. It would be tough to do 100KHz sampling loop and low long term power budget with FPGA. 
> > > Again, you know nothing about it. A 100 MHz timer is a very low power entity. The power used by any counter is treated as one FF toggling at the clock rate since each FF toggles at half the rate of the next faster one, so clock rate * (1/2 + 1/4 + 1/8...) ~= 1 * clock rate no matter the length. Add a comparator and you get 2 FF equivalent at 100 MHz. Not much current there. Counters are best implemented as down counters using the carry chain for the terminal count down from a variable starting value instead of a comparator so back to 1 FF if that will work in this app (it means you make the decision about cycle length when you load the counter, rather than as it approaches the end of the count). 
> > Perhaps you should read the datasheet also. The ICE40 max out at 48MHz, it won't run at 100MHz. And i never said it need 100MHz counter. I only mention 100KHz sampling loop. At 48MHz, we are talking about mA supply current, not uA.
> Sorry, you are reading the wrong data. You might be looking at the configuration clock or something. The internal logic runs at hundreds of MHz. Go back and read some more. 

The ICE40 internal RC peak at 48MHz.  Stm32 internal RC peak at 180MHz.  If we are comparing single chip solution, we should be comparing internal RC.