Reply by Rick C August 2, 20212021-08-02
On Monday, August 2, 2021 at 2:11:34 PM UTC-4, Piotr Wyderski wrote:
> Rick C wrote: > > > Something is not right with your comparison. In one case you are starting with an analog signal and digitizing it in the other you are starting with a digital signal and turning it into analog (analogizing it?). Either the starting signal is analog or the starting signal is digital... > Digital gives you fancy control algorithm, analog gives you low latency. > If you need to react fast to the instant value of the current waveform, > the price of a sufficiently fast ADC can exceed the cost of the FPGA it > feeds, not to mention its output stream is often serial (crossing the > isolation boundary with fewer wires is one reason), which adds to the > delay. Moving the boundary conditions checking to the analog domain can > result in a cheaper and more reliable product. But I am referring to the > front-end, the control is provided by the FPGA in both cases. > > In other words, relying on the ADC data implies relying on the events > long gone, whereas reconfiguring the DAC for the next cycle is preparing > for a future event with minimal delay. Closing this gap is certainly > possible, but requires $$$.
You did not address a single issue I raised. Please read my post again and consider what I was talking about. -- Rick C. -+--+ Get 1,000 miles of free Supercharging -+--+ Tesla referral code - https://ts.la/richard11209
Reply by Piotr Wyderski August 2, 20212021-08-02
Rick C wrote:

> "Heroic pipelining"??? If you design ignoring speed, you will get a slow design in any FPGA.
https://www.latticesemi.com/-/media/LatticeSemi/Documents/DataSheets/iCE/FPGA-DS-02008-1-9-iCE40-UltraPlus-Family-Data-Sheet.ashx?document_id=51968 This FPGA is slow, to begin with. Have a look at the register-to-register performance, section 4.19.2. A 16-bit adder is specified to run at 100MHz and a 16:1 mux at 110MHz. And you want to crank it at 180MHz while doying something non-trivial. > Pipelining is not particularly difficult when designing logic. If you want to go 63% faster than a 16:1 mux can go according to the vendor, who is not interested in downplaying the performance of the chip, nothing is straightforward.
> Then again, maybe you are right about the performance of the iCE40 line.
I'm just quoting the datasheet. This FPGA is slow, but cheap and rich with features and has loads of RAM for the price. Best regards, Piotr
Reply by Piotr Wyderski August 2, 20212021-08-02
Rick C wrote:

> Something is not right with your comparison. In one case you are starting with an analog signal and digitizing it in the other you are starting with a digital signal and turning it into analog (analogizing it?). Either the starting signal is analog or the starting signal is digital...
Digital gives you fancy control algorithm, analog gives you low latency. If you need to react fast to the instant value of the current waveform, the price of a sufficiently fast ADC can exceed the cost of the FPGA it feeds, not to mention its output stream is often serial (crossing the isolation boundary with fewer wires is one reason), which adds to the delay. Moving the boundary conditions checking to the analog domain can result in a cheaper and more reliable product. But I am referring to the front-end, the control is provided by the FPGA in both cases. In other words, relying on the ADC data implies relying on the events long gone, whereas reconfiguring the DAC for the next cycle is preparing for a future event with minimal delay. Closing this gap is certainly possible, but requires $$$. Best regards, Piotr
Reply by Rick C August 2, 20212021-08-02
On Sunday, August 1, 2021 at 7:50:41 PM UTC-4, Don Y wrote:
> On 8/1/2021 3:42 PM, Dimiter_Popoff wrote: > > Of course they are fine. The first time I designed one for such > > purposes was back in 1993... in this: http://tgi-sci.com/tgi/fr64.gif . > > A HC11 was dedicated to monitor all the convertors (+5, +/-15, +/-24, > > I may be forgetting some) and shut them off on over/undervoltage within > > a ms or so, it also did the pwm to charge/maintain the battery, > > connected to a ps2 keyboard (so the main CPU - a "mighty" 68340 - would > > access it through it via spi) .... etc. etc. Ah yes, it stored > > a lot of board unique trim values in its eeprom. > > If designed correctly - with reset conditions etc. in mind - MCU-s > > are a real blessing for power supply usage, have been for decades. > How is it any different than letting a processor control a > delicate mechanism (that could be expensive to replace, recalibrate, > etc.)? > > At it's heart, it's just "electronics" sequenced in a KNOWN manner. > You just need to be sure that "known manner" has been designed > robustly.
I have actually seen data sheets that tell you to design "carefully", whatever that means. Is there an ISO spec for "carefully"? Designing "robustly" is the same sort of vague statement. It means whatever the speaker intends to to mean. -- Rick C. -+--- Get 1,000 miles of free Supercharging -+--- Tesla referral code - https://ts.la/richard11209
Reply by Rick C August 2, 20212021-08-02
On Sunday, August 1, 2021 at 3:37:40 PM UTC-4, Piotr Wyderski wrote:
> Don Y wrote: > > > There are MCUs that address those needs. The advantage of an MCU is that > > it is considerably easier to get it to do *other* things, as well. > The other things is precisely what will eventually lead you astray. > Power control is no joke, don't mess with it with an MCU, at least if > you don't plan to roast some marshmallows.
I've had this discussion with power control designers and they much prefer a processor. Sometimes a simple MCU is fast enough other times they want a DSP. Few of them use FPGAs or will even consider the possibility of using one. They typically want to shave the dollar or two extra the FPGA would cost coupled with an external ADC. -- Rick C. --+++ Get 1,000 miles of free Supercharging --+++ Tesla referral code - https://ts.la/richard11209
Reply by Rick C August 2, 20212021-08-02
On Sunday, August 1, 2021 at 12:48:33 PM UTC-4, Piotr Wyderski wrote:
> jla...@highlandsniptechnology.com wrote: > > > Analog comparators are cheap and don't need code! > The need for code I took for granted, don't know Bill's requirements. > But you are sort of right, an analog comparator driven by a DAC turns > out to be a way cheaper and much faster option than an ADC followed by > fully digital processing. Hybrid approaches work best.
Something is not right with your comparison. In one case you are starting with an analog signal and digitizing it in the other you are starting with a digital signal and turning it into analog (analogizing it?). Either the starting signal is analog or the starting signal is digital... -- Rick C. --++- Get 1,000 miles of free Supercharging --++- Tesla referral code - https://ts.la/richard11209
Reply by Rick C August 2, 20212021-08-02
On Sunday, August 1, 2021 at 11:17:16 AM UTC-4, Piotr Wyderski wrote:
> Rick C wrote: > > > If you are using USB you can run that at 48 MHz all the time. The rest of the chip can run at 180 MHz all the time. Where's the issue? > Anything useful running on an ICE40 at 180MHz? Boy, I would like to see > that. My experience shows it is a decent small FPGA for the 50-100MHz > range, but hardly more without heroic pipelining.
"Heroic pipelining"??? If you design ignoring speed, you will get a slow design in any FPGA. Pipelining is not particularly difficult when designing logic. I don't know the details of this design, but it sounds fairly simple to me. Then again, maybe you are right about the performance of the iCE40 line. The DSP sections which can run pipelined are only rated for 50 MHz if not pipelined. Not sure how that number should even be considered since it would require registers on the input and output to measure a clock rate. Are they the internal registers to the DSP section or fabric registers? This is a goofy spec to publish without information on what it means. -- Rick C. --+-+ Get 1,000 miles of free Supercharging --+-+ Tesla referral code - https://ts.la/richard11209
Reply by Jan Panteltje August 2, 20212021-08-02
On a sunny day (Sun, 1 Aug 2021 21:37:22 +0200) it happened Piotr Wyderski
<bombald@protonmail.com> wrote in <se6t5u$jltd$1@portraits.wsisiz.edu.pl>:

>Don Y wrote: > >> There are MCUs that address those needs.&nbsp; The advantage of an MCU is that >> it is considerably easier to get it to do *other* things, as well. > >The other things is precisely what will eventually lead you astray. >Power control is no joke, don't mess with it with an MCU, at least if >you don't plan to roast some marshmallows. > > Best regards, Piotr
Oh I dunno, my (own designed) lab supply has been running for > 15 years on a PIC Point is many micro controllers have build in hardware, that PIC has a PWM generator, (to drive the switcher) and hardware comparators working directly on that PWM generator (for current and voltage control). Have not put it to sleep at uA level, but you could. The 'software' part drives the LCD display, the PIC has a build in multi channel ADC that reads voltage and current settings from potmeters on front, the software via RS232 can set timers (for battery charging).
Reply by Anthony William Sloman August 2, 20212021-08-02
On Monday, August 2, 2021 at 2:50:18 AM UTC+10, jla...@highlandsniptechnology.com wrote:
> On Sun, 1 Aug 2021 09:34:07 -0700 (PDT), Fred Bloggs <bloggs.fred...@gmail.com> wrote: > >On Sunday, August 1, 2021 at 12:30:12 PM UTC-4, jla...@highlandsniptechnology.com wrote: > >> On Sun, 1 Aug 2021 17:07:45 +0200, Piotr Wyderski <bom...@protonmail.com> wrote: > >> >Ed Lee wrote:
<snip>
> >Stupid thread started by Sloman hallucinating about something he can't build in a million years. And all this in response to that mediocre moron Habib posing as an engineer again.
Fred Bloggs is seriously confused. The thread involved - "Low noise, high bias voltage on picoAmp TIA's input, howto?" was started by Timo, not me.
> Sloman hasn't designed anything in decades.
The thread "Low noise, high bias voltage on picoAmp TIA's input, howto?" did provoke me me into designing yet another version of the Baxandall Class-D oscillator. John Larkin wasn't interested, so he didn't notice.
>The only thing he creates now and silly droning insults.
I don't flatter John Larkin as fulsomely as he thinks he deserves and he process that as "silly droning insults". He finds the suggestion that he isn't quite as wonderful as he likes to think he is very painful, and he lashes out at the source of the pain. Trimming his inflated self-image down to man-size might work better. He' s no Paul Bunyan.
> Being retired is mostly a choice, and that makes some people happy, > but being a bitter old git sounds boring. It doesn't take much space > or money to have a workbench and play with electronics.
Being retired isn't my choice. I do keep on applying for jobs, though I'm well aware that I'm much too old to be likely get one. LTSpice does let me play with electronics. I've got a couple of projects that I could turn into working hardware if there was any prospect that I could find a customer who would want to use them
> I recently did a class-D power amp for my alternator simulator. People wanted to make that digital, but the PWM loop just took a few analog parts, and that was easy to Spice first.
He has given up posting his Spice simulations here. I remember one that was set up to run for 2msec. When I ran it there was something odd going on at 2msec, and I ran it for 10msec and found a problem that needed fixing and was easy to fix. John has been less specific in his boasting since then. -- Bill Sloman, Sydney
Reply by Don Y August 1, 20212021-08-01
On 8/1/2021 3:42 PM, Dimiter_Popoff wrote:
> Of course they are fine. The first time I designed one for such > purposes was back in 1993... in this: http://tgi-sci.com/tgi/fr64.gif . > A HC11 was dedicated to monitor all the convertors (+5, +/-15, +/-24, > I may be forgetting some) and shut them off on over/undervoltage within > a ms or so, it also did the pwm to charge/maintain the battery, > connected to a ps2 keyboard (so the main CPU - a "mighty" 68340 - would > access it through it via spi) .... etc. etc. Ah yes, it stored > a lot of board unique trim values in its eeprom. > If designed correctly - with reset conditions etc. in mind - MCU-s > are a real blessing for power supply usage, have been for decades.
How is it any different than letting a processor control a delicate mechanism (that could be expensive to replace, recalibrate, etc.)? At it's heart, it's just "electronics" sequenced in a KNOWN manner. You just need to be sure that "known manner" has been designed robustly. Or, that you are willing to tolerate some number of faults/failures in the name of some sort of economy. Why do power supplies fail? Isn't that an old, established technology??