On Sunday, July 4, 2021 at 4:50:31 AM UTC-4, 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

Yes, and this is not appropriate for hardware design. If you can't calculate the timing, you can't validate the design or even make it work in most cases. So the loop is detected and an error/warning flag is thrown. The loop can be detected. The halting problem addresses the nature of code and input interactions. We don't care about input interactions. The loop can be detected physically and is flagged even if there is no input combination that would make it an infinite loop. For example a loop with two AND gates driven by the true and compliment of a single input signal. I don't know if the tools would understand that one or the other of the gates would prevent the loop. It just considers the fact there exists a combinational path..

There are reasons for the various methods and limitations of logic design. I recall when ​Level Sensitive Scan Design LSSD (the basis of JTAG scan chains) was being promoted as a way to make designs verifiable and testable. New ideas in the 1980s.

--

Rick C.

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

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.

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.

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

> 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

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

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

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.

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

--

Rick C.

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

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.

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

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.

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.

søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> 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.

it has a pll that can do several 100MHz

On Sunday, July 4, 2021 at 12:10:20 PM UTC-7, Ed Lee wrote:
> 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.

Page 7: https://www.latticesemi.com/view_document?document_id=50666

Low Frequency Oscillator – 10 kHz
High Frequency Oscillator – 48 MHz

On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:
> søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> > 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.
> it has a pll that can do several 100MHz

OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.

On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote:
> On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:
> > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> > > 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.
> > it has a pll that can do several 100MHz
> OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.

I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL.

Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz

Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18.

The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL.

Now, either learn something or go away. Stop being a Larkin.

--

Rick C.

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

On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote:
> > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:
> > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> > > > 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.
> > > it has a pll that can do several 100MHz
> > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.
> I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL.
>
> Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz
>
> Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18.
>
> The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL.

Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA.

On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote:
> On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote:
> > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:
> > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> > > > > 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.
> > > > it has a pll that can do several 100MHz
> > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.
> > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL.
> >
> > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz
> >
> > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18.
> >
> > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL.
> Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA.

Table 4.17. iCE40 Ultra External Switching Characteristics

Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking.

Try reading the data sheets and learn how it works.

Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices.

Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow?

This is always your problem. You can't let go of your mindset or even explain it enough to communicate.

--

Rick C.

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

On Sunday, July 4, 2021 at 1:05:11 PM UTC-7, gnuarm.del...@gmail.com wrote:
> On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote:
> > On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote:
> > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:
> > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> > > > > > 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.
> > > > > it has a pll that can do several 100MHz
> > > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.
> > > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL.
> > >
> > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz
> > >
> > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18.
> > >
> > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL.
> > Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA.
> Table 4.17. iCE40 Ultra External Switching Characteristics
>
> Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking.
>
> Try reading the data sheets and learn how it works.
>
> Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices.
>
> Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow?
>
> This is always your problem. You can't let go of your mindset or even explain it enough to communicate.

Your problem is just always making assumptions in your favour. It's very common to run micros at maximum speed to process the loop, then sleep (basically dropping to lowest speed) and wait for timer/interrupt.

The purposed app is 24V to 200V DC/DC, if i read previous posts correctly. The micro or fpga does not need to run constantly, especially if there is storage device (battery or cap) involved. All i am saying is that micro will have better power management than fpga.

On 03/07/2021 13.58, piglet wrote:
> On 02/07/2021 16:45, Klaus Vestergaard Kragelund wrote:
>> On 02/07/2021 07.33, Anthony William Sloman 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 have been a little absent from SED the last couple of months, got a
>> consulting gig in parallel with my day job
>>
>> Can you post a link to the Timo inverter?
>>
>> Cheers
>>
>> Klaus
> Look back a few weeks in SED for thread "Low noise high bias voltage
> ..." - basically a call for ideas on a low noise high voltage low power
> inverter.
>
> Bill Sloman is now exploring using very fast mcus to generate square
> wave drive for the current fed center tap push-pull converter he is
> fascinated with.
>
Thanks, I searched back and found it :-)

Very nice discussion, and also this thread which is technical instead of
all that OT.

In fact I am working on something vaguely similar. Also a micro driving
a converter. Right now it is hard-driven, but have been thinking about
using it in resonant mode

Resonant mode is a little difficult in that the loop gain is nonlinear.
Most resonant controllers use a charge transfer principle, to avoid this
non-liniarity. That is not simple to implement in a micro

On Sunday, July 4, 2021 at 3:51:42 PM UTC-7, Klaus Kragelund wrote:
> On 03/07/2021 13.58, piglet wrote:
> > On 02/07/2021 16:45, Klaus Vestergaard Kragelund wrote:
> >> On 02/07/2021 07.33, Anthony William Sloman 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 have been a little absent from SED the last couple of months, got a
> >> consulting gig in parallel with my day job
> >>
> >> Can you post a link to the Timo inverter?
> >>
> >> Cheers
> >>
> >> Klaus
> > Look back a few weeks in SED for thread "Low noise high bias voltage
> > ..." - basically a call for ideas on a low noise high voltage low power
> > inverter.
> >
> > Bill Sloman is now exploring using very fast mcus to generate square
> > wave drive for the current fed center tap push-pull converter he is
> > fascinated with.
> >
> Thanks, I searched back and found it :-)
>
> Very nice discussion, and also this thread which is technical instead of
> all that OT.
>
> In fact I am working on something vaguely similar. Also a micro driving
> a converter. Right now it is hard-driven, but have been thinking about
> using it in resonant mode
>
> Resonant mode is a little difficult in that the loop gain is nonlinear.
> Most resonant controllers use a charge traearnsfer principle, to avoid this
> non-liniarity. That is not simple to implement in a microies

I am also planning on same with inductor or transformer, driving with high frequency counter. Non-linear loop gain is not a problem, as long as the output is above the target, excess energy will be dumped into the super-caps or batteries. Power transfer efficiency is more important.

On Sunday, July 4, 2021 at 4:22:35 PM UTC-4, Ed Lee wrote:
> On Sunday, July 4, 2021 at 1:05:11 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > On Sunday, July 4, 2021 at 3:46:16 PM UTC-4, Ed Lee wrote:
> > > On Sunday, July 4, 2021 at 12:41:24 PM UTC-7, gnuarm.del...@gmail.com wrote:
> > > > On Sunday, July 4, 2021 at 3:29:35 PM UTC-4, Ed Lee wrote:
> > > > > On Sunday, July 4, 2021 at 12:16:38 PM UTC-7, lang...@fonz.dk wrote:
> > > > > > søndag den 4. juli 2021 kl. 21.10.20 UTC+2 skrev Ed Lee:
> > > > > > > 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.
> > > > > > it has a pll that can do several 100MHz
> > > > > OK, it can go to 180MHz. The question is whether this is set by the bit stream or run-time configuration. Namely, can it switch between 32KHz and 180MHz at run time.
> > > > I don't know what you think you've found that says 180 MHz, but they typically don't give you a toggle rate for FFs as it is a meaningless number in any real design and only used for marketing purposes. Here is the spec on the PLL.
> > > >
> > > > Table 4.18. sysCLOCK PLL TimingParameterDescriptionsConditionsMinMaxUnitfINInput ClockFrequency (REFERENCECLK, EXTFEEDBACK)—10 133MHzfOUTOutput Clock Frequency (PLLOUT)—16 275MHz
> > > >
> > > > Unfortunately that's how it copies from the PDF. If you want to see it clearly find table 4.18.
> > > >
> > > > The max logic speed depends on the logic in your circuit. A decent job of design will let a counter run at the full 275 MHz of the PLL.
> > > Page 34: Maximum global clock of 185MHz. Anyway, the critical issue is whether you can switch between low speed (32KHz) and high speed (185MHz) as in a micro. Micros have registers to write into, not FPGA.
> > Table 4.17. iCE40 Ultra External Switching Characteristics
> >
> > Did you see the word "external" there? That's the max rate on the I/O pin, not the internal clocking.
> >
> > Try reading the data sheets and learn how it works.
> >
> > Why do you want to switch the clock speed? Just run the parts that need 32 kHz from 32 kHz and run the fast parts from the fast clock. What's the point of running the fast parts from a slow clock? You are stuck in the hugely awkward mindset of MCUs which do things in a certain way because they don't have choices.
> >
> > Do you want to generate a 100 kHz waveform from a 32 kHz clock? I thought you wanted to run a slow timer so it would be low power and shut off the clock to the rest of the chip so it would not draw power. Do I have this wrong somehow?
> >
> > This is always your problem. You can't let go of your mindset or even explain it enough to communicate.
> Your problem is just always making assumptions in your favour. It's very common to run micros at maximum speed to process the loop, then sleep (basically dropping to lowest speed) and wait for timer/interrupt.

Which is exactly what an FPGA would do. You still have zero understanding of the problem and the solution.

> The purposed app is 24V to 200V DC/DC, if i read previous posts correctly.. The micro or fpga does not need to run constantly, especially if there is storage device (battery or cap) involved. All i am saying is that micro will have better power management than fpga.

Whatever. You don't know a damn thing about FPGAs, but you are hell bent on proving your assertion regardless of the facts. Since you know your conclusion you don't need to actually do anything to learn about FPGAs.

Enough said. Enjoy your ignorance.

--

Rick C.

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