Got an application coming up for a high-efficiency, multikilowatt polyphase power supply that needs scarily fast responses to external requests. I'm thinking about maybe throwing a C2000 at the problem. It could really simplify keeping my phases in alignment and getting the feedforward through all the paths to match. TI sure makes it look easy, almost as if it's their job to do so. Anyone got any stories to share from that war? -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Digital Power Control
Started by ●September 21, 2015
Reply by ●September 21, 20152015-09-21
On 9/21/2015 2:49 PM, Rob Gaddi wrote:> Got an application coming up for a high-efficiency, multikilowatt > polyphase power supply that needs scarily fast responses to external > requests. I'm thinking about maybe throwing a C2000 at the problem. It > could really simplify keeping my phases in alignment and getting the > feedforward through all the paths to match. > > TI sure makes it look easy, almost as if it's their job to do so. Anyone > got any stories to share from that war?How complex are your calculations? I can see using a processor if the calculations are lengthy. But if the calcs are simple with a demand for speed, I think FPGA. Even if the calcs are not so simple, *I* would think FPGA most likely. Processors are great, but the inherently sequential nature creates problems, mainly when you need to be doing several things at one time and have to time share the processor. One of the things I like about FPGA work is that I can do nearly perfect simulation. I hardly ever have any difficult problems to debug in the hardware. I find software to be a bit harder to test well before heading to the bench. So would an HDL/FPGA design suit the requirements? -- Rick
Reply by ●September 21, 20152015-09-21
On 9/21/15 4:28 PM, rickman wrote:> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >> Got an application coming up for a high-efficiency, multikilowatt >> polyphase power supply that needs scarily fast responses to external >> requests. I'm thinking about maybe throwing a C2000 at the problem. It >> could really simplify keeping my phases in alignment and getting the >> feedforward through all the paths to match. >> >> TI sure makes it look easy, almost as if it's their job to do so. Anyone >> got any stories to share from that war? > > How complex are your calculations? I can see using a processor if the > calculations are lengthy. But if the calcs are simple with a demand for > speed, I think FPGA. Even if the calcs are not so simple, *I* would > think FPGA most likely. Processors are great, but the inherently > sequential nature creates problems, mainly when you need to be doing > several things at one time and have to time share the processor. > > One of the things I like about FPGA work is that I can do nearly perfect > simulation. I hardly ever have any difficult problems to debug in the > hardware. I find software to be a bit harder to test well before heading > to the bench. > > So would an HDL/FPGA design suit the requirements? >confession: i never ever designed an FPGA (but i once developed some note-processing algs that someone else put into the FPGA) and i have never been paid for anything regarding control of power. how "scarily fast" do you need to be? i wonder how a power-control app would need a faster sampling rate than audio and, if the calculation is complicated (with lotsa conditionals and math), i wonder how a DSP would not be adequate. and i doubt an arduino would suffice. it just seems to me that using a development system and a familiar programming language would be the easiest and most cost-effective way to do it. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●September 21, 20152015-09-21
On Mon, 21 Sep 2015 18:08:34 -0400, robert bristow-johnson wrote:> On 9/21/15 4:28 PM, rickman wrote: >> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>> Got an application coming up for a high-efficiency, multikilowatt >>> polyphase power supply that needs scarily fast responses to external >>> requests. I'm thinking about maybe throwing a C2000 at the problem. It >>> could really simplify keeping my phases in alignment and getting the >>> feedforward through all the paths to match. >>> >>> TI sure makes it look easy, almost as if it's their job to do so. >>> Anyone got any stories to share from that war? >> >> How complex are your calculations? I can see using a processor if the >> calculations are lengthy. But if the calcs are simple with a demand for >> speed, I think FPGA. Even if the calcs are not so simple, *I* would >> think FPGA most likely. Processors are great, but the inherently >> sequential nature creates problems, mainly when you need to be doing >> several things at one time and have to time share the processor. >> >> One of the things I like about FPGA work is that I can do nearly >> perfect simulation. I hardly ever have any difficult problems to debug >> in the hardware. I find software to be a bit harder to test well before >> heading to the bench. >> >> So would an HDL/FPGA design suit the requirements? >> >> > confession: i never ever designed an FPGA (but i once developed some > note-processing algs that someone else put into the FPGA) and i have > never been paid for anything regarding control of power. > > how "scarily fast" do you need to be? i wonder how a power-control app > would need a faster sampling rate than audio and, if the calculation is > complicated (with lotsa conditionals and math), i wonder how a DSP would > not be adequate. and i doubt an arduino would suffice. > > it just seems to me that using a development system and a familiar > programming language would be the easiest and most cost-effective way to > do it.Scary fast is 20 us 0 to fullscale, which means having to keep the inductances fairly low, which means having to get the switching frequency in the 1 MHz ballpark. It ain't RF, but by power supply standards it's a lift, and will put me north of 10A/us. I think the calculations should be borderline trivial; probably nothing more than a stupid PID on the PWM duty cycles along with some bounding logic to slam the duty to 0 or 100% when I need to slew hard without winding up any integrators. The C2000s came to mind because they've got 150ps high-resolution PWMs and some multi-Msps, low-latency ADCs built in. I've never tried programming them before; and I'm definitely more comfortable writing VHDL these days. But those fancy PWMs are really tempting; even if you run an FPGA core clock of 500 MHz and DDR the outputs you've STILL got only 1 part per thousand PWM control. Or you do it outboard with DACs and comparators and dedicated gating logic and the BOM explodes. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●September 21, 20152015-09-21
On 9/21/2015 6:08 PM, robert bristow-johnson wrote:> On 9/21/15 4:28 PM, rickman wrote: >> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>> Got an application coming up for a high-efficiency, multikilowatt >>> polyphase power supply that needs scarily fast responses to external >>> requests. I'm thinking about maybe throwing a C2000 at the problem. It >>> could really simplify keeping my phases in alignment and getting the >>> feedforward through all the paths to match. >>> >>> TI sure makes it look easy, almost as if it's their job to do so. Anyone >>> got any stories to share from that war? >> >> How complex are your calculations? I can see using a processor if the >> calculations are lengthy. But if the calcs are simple with a demand for >> speed, I think FPGA. Even if the calcs are not so simple, *I* would >> think FPGA most likely. Processors are great, but the inherently >> sequential nature creates problems, mainly when you need to be doing >> several things at one time and have to time share the processor. >> >> One of the things I like about FPGA work is that I can do nearly perfect >> simulation. I hardly ever have any difficult problems to debug in the >> hardware. I find software to be a bit harder to test well before heading >> to the bench. >> >> So would an HDL/FPGA design suit the requirements? >> > > confession: i never ever designed an FPGA (but i once developed some > note-processing algs that someone else put into the FPGA) and i have > never been paid for anything regarding control of power. > > how "scarily fast" do you need to be? i wonder how a power-control app > would need a faster sampling rate than audio and, if the calculation is > complicated (with lotsa conditionals and math), i wonder how a DSP would > not be adequate. and i doubt an arduino would suffice. > > it just seems to me that using a development system and a familiar > programming language would be the easiest and most cost-effective way to > do it.I have seen control apps where the calculation period was a significant factor in the stability of the loop. Rather than talk in terms of "arduino", "DSP" and "FPGA", I would want to see numbers. That is why I asked how complex the calculations are. When someone's requirements say, "scarily fast", I start thinking of getting rid of the inherent limitations of sequential instruction execution. Numbers would be a lot better though. "Easy" and "cost-effective" don't have much meaning until numbers can be attached. Reminds me of some data book where they listed "Damn Fast" buffers. "Easy" is certainly in the eye of the beholder. I already mentioned how I feel the debugging is easier with FPGAs. "Familiar" entirely depends on the user. -- Rick
Reply by ●September 21, 20152015-09-21
On 9/21/2015 6:38 PM, Rob Gaddi wrote:> On Mon, 21 Sep 2015 18:08:34 -0400, robert bristow-johnson wrote: > >> On 9/21/15 4:28 PM, rickman wrote: >>> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>>> Got an application coming up for a high-efficiency, multikilowatt >>>> polyphase power supply that needs scarily fast responses to external >>>> requests. I'm thinking about maybe throwing a C2000 at the problem. It >>>> could really simplify keeping my phases in alignment and getting the >>>> feedforward through all the paths to match. >>>> >>>> TI sure makes it look easy, almost as if it's their job to do so. >>>> Anyone got any stories to share from that war? >>> >>> How complex are your calculations? I can see using a processor if the >>> calculations are lengthy. But if the calcs are simple with a demand for >>> speed, I think FPGA. Even if the calcs are not so simple, *I* would >>> think FPGA most likely. Processors are great, but the inherently >>> sequential nature creates problems, mainly when you need to be doing >>> several things at one time and have to time share the processor. >>> >>> One of the things I like about FPGA work is that I can do nearly >>> perfect simulation. I hardly ever have any difficult problems to debug >>> in the hardware. I find software to be a bit harder to test well before >>> heading to the bench. >>> >>> So would an HDL/FPGA design suit the requirements? >>> >>> >> confession: i never ever designed an FPGA (but i once developed some >> note-processing algs that someone else put into the FPGA) and i have >> never been paid for anything regarding control of power. >> >> how "scarily fast" do you need to be? i wonder how a power-control app >> would need a faster sampling rate than audio and, if the calculation is >> complicated (with lotsa conditionals and math), i wonder how a DSP would >> not be adequate. and i doubt an arduino would suffice. >> >> it just seems to me that using a development system and a familiar >> programming language would be the easiest and most cost-effective way to >> do it. > > Scary fast is 20 us 0 to fullscale, which means having to keep the > inductances fairly low, which means having to get the switching frequency > in the 1 MHz ballpark. It ain't RF, but by power supply standards it's a > lift, and will put me north of 10A/us. > > I think the calculations should be borderline trivial; probably nothing > more than a stupid PID on the PWM duty cycles along with some bounding > logic to slam the duty to 0 or 100% when I need to slew hard without > winding up any integrators. > > The C2000s came to mind because they've got 150ps high-resolution PWMs > and some multi-Msps, low-latency ADCs built in. I've never tried > programming them before; and I'm definitely more comfortable writing VHDL > these days. But those fancy PWMs are really tempting; even if you run an > FPGA core clock of 500 MHz and DDR the outputs you've STILL got only 1 > part per thousand PWM control. Or you do it outboard with DACs and > comparators and dedicated gating logic and the BOM explodes.How do they do the PWM in the C2000s? I'm not really recommending it, but there is a *very* interesting chip with 144 - 700 MIPS peak rate processors, 5 ADCs, 5 - 9 bit DACs... and low power. But talk about "unfamiliarity", they are programmed natively in something similar to Forth. But it is a very interesting part and control is one of the potential apps where it may do well. I can't think of a way to get 150 ps resolution PWM. -- Rick
Reply by ●September 21, 20152015-09-21
On Mon, 21 Sep 2015 19:10:11 -0400, rickman wrote:> On 9/21/2015 6:38 PM, Rob Gaddi wrote: >> >> The C2000s came to mind because they've got 150ps high-resolution PWMs >> and some multi-Msps, low-latency ADCs built in. I've never tried >> programming them before; and I'm definitely more comfortable writing >> VHDL these days. But those fancy PWMs are really tempting; even if you >> run an FPGA core clock of 500 MHz and DDR the outputs you've STILL got >> only 1 part per thousand PWM control. Or you do it outboard with DACs >> and comparators and dedicated gating logic and the BOM explodes. > > How do they do the PWM in the C2000s? >It looks from http://www.ti.com/lit/ug/spru924f/spru924f.pdf like that edge resolution is independent of system clock rate, so I'm going to guess either a) an analog ramp, string DAC, and comparator; or more likely b) a tapped delay line Either way, it's probably got an exciting temperature coefficient, but I guess it doesn't matter; if you're using it you're using it in a closed- loop application where the stupid servos out.> I'm not really recommending it, but there is a *very* interesting chip > with 144 - 700 MIPS peak rate processors, 5 ADCs, 5 - 9 bit DACs... and > low power. But talk about "unfamiliarity", they are programmed natively > in something similar to Forth. But it is a very interesting part and > control is one of the potential apps where it may do well. I can't > think of a way to get 150 ps resolution PWM.Is that the GreenArrays chip you were playing with a while back? It still kinda feels like exotica in a way that buying from the megalith that is TI will keep my supply chain happy. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●September 21, 20152015-09-21
On Mon, 21 Sep 2015 19:10:11 -0400, rickman <gnuarm@gmail.com> wrote:>On 9/21/2015 6:38 PM, Rob Gaddi wrote: >> On Mon, 21 Sep 2015 18:08:34 -0400, robert bristow-johnson wrote: >> >>> On 9/21/15 4:28 PM, rickman wrote: >>>> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>>>> Got an application coming up for a high-efficiency, multikilowatt >>>>> polyphase power supply that needs scarily fast responses to external >>>>> requests. I'm thinking about maybe throwing a C2000 at the problem. It >>>>> could really simplify keeping my phases in alignment and getting the >>>>> feedforward through all the paths to match. >>>>> >>>>> TI sure makes it look easy, almost as if it's their job to do so. >>>>> Anyone got any stories to share from that war? >>>> >>>> How complex are your calculations? I can see using a processor if the >>>> calculations are lengthy. But if the calcs are simple with a demand for >>>> speed, I think FPGA. Even if the calcs are not so simple, *I* would >>>> think FPGA most likely. Processors are great, but the inherently >>>> sequential nature creates problems, mainly when you need to be doing >>>> several things at one time and have to time share the processor. >>>> >>>> One of the things I like about FPGA work is that I can do nearly >>>> perfect simulation. I hardly ever have any difficult problems to debug >>>> in the hardware. I find software to be a bit harder to test well before >>>> heading to the bench. >>>> >>>> So would an HDL/FPGA design suit the requirements? >>>> >>>> >>> confession: i never ever designed an FPGA (but i once developed some >>> note-processing algs that someone else put into the FPGA) and i have >>> never been paid for anything regarding control of power. >>> >>> how "scarily fast" do you need to be? i wonder how a power-control app >>> would need a faster sampling rate than audio and, if the calculation is >>> complicated (with lotsa conditionals and math), i wonder how a DSP would >>> not be adequate. and i doubt an arduino would suffice. >>> >>> it just seems to me that using a development system and a familiar >>> programming language would be the easiest and most cost-effective way to >>> do it. >> >> Scary fast is 20 us 0 to fullscale, which means having to keep the >> inductances fairly low, which means having to get the switching frequency >> in the 1 MHz ballpark. It ain't RF, but by power supply standards it's a >> lift, and will put me north of 10A/us. >> >> I think the calculations should be borderline trivial; probably nothing >> more than a stupid PID on the PWM duty cycles along with some bounding >> logic to slam the duty to 0 or 100% when I need to slew hard without >> winding up any integrators. >> >> The C2000s came to mind because they've got 150ps high-resolution PWMs >> and some multi-Msps, low-latency ADCs built in. I've never tried >> programming them before; and I'm definitely more comfortable writing VHDL >> these days. But those fancy PWMs are really tempting; even if you run an >> FPGA core clock of 500 MHz and DDR the outputs you've STILL got only 1 >> part per thousand PWM control. Or you do it outboard with DACs and >> comparators and dedicated gating logic and the BOM explodes. > >How do they do the PWM in the C2000s? > >I'm not really recommending it, but there is a *very* interesting chip >with 144 - 700 MIPS peak rate processors, 5 ADCs, 5 - 9 bit DACs... and >low power. But talk about "unfamiliarity", they are programmed natively >in something similar to Forth. But it is a very interesting part and >control is one of the potential apps where it may do well. I can't >think of a way to get 150 ps resolution PWM.High Resolution PWM is usually done by adding a series of delay taps and selecting I think, at least for one of the HRPWM endowed micros I am using works (ST) I would love to be able to use an FPGA but they are so fricking expensive compared to a microcontroroller. CPLDs are fast and cheap but not enough blocks and the typical FPGA that I see have more blocks than I need and therefore too expensive. Would love to find something in-between. boB
Reply by ●September 21, 20152015-09-21
On 9/21/2015 8:28 PM, Rob Gaddi wrote:> On Mon, 21 Sep 2015 19:10:11 -0400, rickman wrote: > >> On 9/21/2015 6:38 PM, Rob Gaddi wrote: >>> >>> The C2000s came to mind because they've got 150ps high-resolution PWMs >>> and some multi-Msps, low-latency ADCs built in. I've never tried >>> programming them before; and I'm definitely more comfortable writing >>> VHDL these days. But those fancy PWMs are really tempting; even if you >>> run an FPGA core clock of 500 MHz and DDR the outputs you've STILL got >>> only 1 part per thousand PWM control. Or you do it outboard with DACs >>> and comparators and dedicated gating logic and the BOM explodes. >> >> How do they do the PWM in the C2000s? >> > > It looks from http://www.ti.com/lit/ug/spru924f/spru924f.pdf like that > edge resolution is independent of system clock rate, so I'm going to > guess either > a) an analog ramp, string DAC, and comparator; or more likely > b) a tapped delay line > > Either way, it's probably got an exciting temperature coefficient, but I > guess it doesn't matter; if you're using it you're using it in a closed- > loop application where the stupid servos out.Yes, closed loops can do a lot to fix various issues. I expect there is a very interesting way to use the GA144 for this if enough thought is put into it. Just as someone figured out a simple way to make a crystal resonate by using NCO calculations to dither the startup pulse train, there is probably a good way to do something analogous for the PWM issue.>> I'm not really recommending it, but there is a *very* interesting chip >> with 144 - 700 MIPS peak rate processors, 5 ADCs, 5 - 9 bit DACs... and >> low power. But talk about "unfamiliarity", they are programmed natively >> in something similar to Forth. But it is a very interesting part and >> control is one of the potential apps where it may do well. I can't >> think of a way to get 150 ps resolution PWM. > > Is that the GreenArrays chip you were playing with a while back? It > still kinda feels like exotica in a way that buying from the megalith > that is TI will keep my supply chain happy.Yes, it has many concerns and supply is not the least. Their way to assure supply is if they decide to pack it in, you can do a lifetime buy or you can buy your own wafers. They have done two runs that they have publicly announced and both seem to be what would amount to pilot runs by the fab. Still, that's a lot of dice since they are so small, 21.3 mm^2 even in 180 nm technology. -- Rick
Reply by ●September 21, 20152015-09-21
On 9/21/2015 8:46 PM, boB wrote:> On Mon, 21 Sep 2015 19:10:11 -0400, rickman <gnuarm@gmail.com> wrote: > >> On 9/21/2015 6:38 PM, Rob Gaddi wrote: >>> On Mon, 21 Sep 2015 18:08:34 -0400, robert bristow-johnson wrote: >>> >>>> On 9/21/15 4:28 PM, rickman wrote: >>>>> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>>>>> Got an application coming up for a high-efficiency, multikilowatt >>>>>> polyphase power supply that needs scarily fast responses to external >>>>>> requests. I'm thinking about maybe throwing a C2000 at the problem. It >>>>>> could really simplify keeping my phases in alignment and getting the >>>>>> feedforward through all the paths to match. >>>>>> >>>>>> TI sure makes it look easy, almost as if it's their job to do so. >>>>>> Anyone got any stories to share from that war? >>>>> >>>>> How complex are your calculations? I can see using a processor if the >>>>> calculations are lengthy. But if the calcs are simple with a demand for >>>>> speed, I think FPGA. Even if the calcs are not so simple, *I* would >>>>> think FPGA most likely. Processors are great, but the inherently >>>>> sequential nature creates problems, mainly when you need to be doing >>>>> several things at one time and have to time share the processor. >>>>> >>>>> One of the things I like about FPGA work is that I can do nearly >>>>> perfect simulation. I hardly ever have any difficult problems to debug >>>>> in the hardware. I find software to be a bit harder to test well before >>>>> heading to the bench. >>>>> >>>>> So would an HDL/FPGA design suit the requirements? >>>>> >>>>> >>>> confession: i never ever designed an FPGA (but i once developed some >>>> note-processing algs that someone else put into the FPGA) and i have >>>> never been paid for anything regarding control of power. >>>> >>>> how "scarily fast" do you need to be? i wonder how a power-control app >>>> would need a faster sampling rate than audio and, if the calculation is >>>> complicated (with lotsa conditionals and math), i wonder how a DSP would >>>> not be adequate. and i doubt an arduino would suffice. >>>> >>>> it just seems to me that using a development system and a familiar >>>> programming language would be the easiest and most cost-effective way to >>>> do it. >>> >>> Scary fast is 20 us 0 to fullscale, which means having to keep the >>> inductances fairly low, which means having to get the switching frequency >>> in the 1 MHz ballpark. It ain't RF, but by power supply standards it's a >>> lift, and will put me north of 10A/us. >>> >>> I think the calculations should be borderline trivial; probably nothing >>> more than a stupid PID on the PWM duty cycles along with some bounding >>> logic to slam the duty to 0 or 100% when I need to slew hard without >>> winding up any integrators. >>> >>> The C2000s came to mind because they've got 150ps high-resolution PWMs >>> and some multi-Msps, low-latency ADCs built in. I've never tried >>> programming them before; and I'm definitely more comfortable writing VHDL >>> these days. But those fancy PWMs are really tempting; even if you run an >>> FPGA core clock of 500 MHz and DDR the outputs you've STILL got only 1 >>> part per thousand PWM control. Or you do it outboard with DACs and >>> comparators and dedicated gating logic and the BOM explodes. >> >> How do they do the PWM in the C2000s? >> >> I'm not really recommending it, but there is a *very* interesting chip >> with 144 - 700 MIPS peak rate processors, 5 ADCs, 5 - 9 bit DACs... and >> low power. But talk about "unfamiliarity", they are programmed natively >> in something similar to Forth. But it is a very interesting part and >> control is one of the potential apps where it may do well. I can't >> think of a way to get 150 ps resolution PWM. > > High Resolution PWM is usually done by adding a series of delay taps > and selecting I think, at least for one of the HRPWM endowed micros I > am using works (ST)I think Xilinx used a tapped delay line for part of their clock distribution circuits.> I would love to be able to use an FPGA but they are so fricking > expensive compared to a microcontroroller. CPLDs are fast and cheap > but not enough blocks and the typical FPGA that I see have more blocks > than I need and therefore too expensive. Would love to find something > in-between.FPGAs are pretty cheap at the low end. Xilinx has devices under $10 and Lattice has units under $4, maybe a lot less in real quantities. Partly it depends on how much space you need for your design. Lots of them have multipliers or DSP units. -- Rick