Forums

Digital Power Control

Started by Rob Gaddi September 21, 2015
On Tue, 22 Sep 2015 17:07:42 +0000, Rob Gaddi wrote:

> On Tue, 22 Sep 2015 10:33:20 -0400, rickman wrote: > >> To date, the two large FPGA companies are sticking to the path that got >> them where they are, catering to the large comms companies needs which >> is bigger, faster FPGAs. There is a lot more margin at the high end >> than at the low end. Motor control would definitely be the low end. >> Someone has already complained about FPGA prices in this thread. >> >> There is nothing stopping FPGAs from being built like MCUs with all >> manner of accessories built in. But the big guys aren't going to do >> it. >> The new market for FPGAs is in very high volume handheld devices. >> The >> new push is to low end FPGAs in very small packages and price will be a >> major issue. So far there aren't many pushing in that direction. The >> processes are still digital. But once they broach this market more >> they will be more inclined to break out of their mold and explore more >> innovative areas like motor control with analog subsystems. > > Actually, both X and A have SoC offerings now that integrate ARM Cortex > A9s with a mess of peripherals alongside the fabric. > > I'm actually really surprised at the balance they struck; they both > decided to put a LOT of hard IP in. Gb Ethneret MAC, DRAM controller, > all that stuff makes sense to me to harden. But they're also putting > SPI, I2C, counter/timers, all the sort of stuff that seems like it would > be just as easily implemented on the fabric. Beats me what the logic > was.
You can implement stuff in much less space (and probably power) if it's hard-coded rather than implemented in the FPGA fabric -- that's why there's a processor core in there and not just available IP. The logic extends to peripherals: if it's something that's used a lot, then it's worthwhile putting in. I suspect that the area difference is 10:1, which would mean (roughly) that if you put in 10 different peripherals and each customer used one and let the other 9 lie idle, that you'd break even on area and come out ahead on power consumption. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Tue, 22 Sep 2015 10:21:35 -0400, rickman wrote:

> On 9/21/2015 11:15 PM, Tim Wescott wrote: >> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote: >> >>> 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. >> >> But could they be used to get the necessary clock resolution? > > A PLL might be able to do that. Adjusting the ratio of the two dividers > would provide a high resolution clock rate. > > I don't think a delay line is used to adjust the clock frequency for the > PWM. I expect the leading edge of the PWM is controlled from the clock > directly and the trailing edge is controlled by the delayed clock. Is > this wrong? I can see where temperature drift would be a significant > factor in making a delay line circuit work correctly. The number of > steps per clock cycle would change widely. When lengthening the pulse > width, at what point are the steps zeroed and the clock count > incremented instead?
For there to be any point to extending the PWM resolution, you'd need to be able to do it on a cycle-by-cycle basis. If you're using a PLL, it'd have to come into it's new lock pretty damned fast.
> >>>> 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. >> >> With or without the high-resolution PWM? > > There is no special hardware called "high resolution DWM". A PLL is > standard on most parts and could be used to provide good resolution to a > PWM by adjusting the clock rate.
Fine. With or without the necessary hardware to implement a PWM controller with less than one clock cycle resolution.
> I wonder if dithering in the PWM itself would be acceptable. The OP > seems concerned about rail to rail steps in a short time, but this might > not mean the high resolution is critical if it is obtained by dithering > a lower resolution. That makes things much easier. The response time > required seems to be 20 uS. I don't see a lot of other numbers in the > requirements so it is hard to tell exactly what will work here. Driving > the PWM with an NCO will give tons of resolution if the associated > jitter is acceptable.
I was going to raise this one myself -- that's for Rob to think about, and maybe answer. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On 9/22/2015 1:46 PM, Tim Wescott wrote:
> On Tue, 22 Sep 2015 17:07:42 +0000, Rob Gaddi wrote: > >> On Tue, 22 Sep 2015 10:33:20 -0400, rickman wrote: >> >>> To date, the two large FPGA companies are sticking to the path that got >>> them where they are, catering to the large comms companies needs which >>> is bigger, faster FPGAs. There is a lot more margin at the high end >>> than at the low end. Motor control would definitely be the low end. >>> Someone has already complained about FPGA prices in this thread. >>> >>> There is nothing stopping FPGAs from being built like MCUs with all >>> manner of accessories built in. But the big guys aren't going to do >>> it. >>> The new market for FPGAs is in very high volume handheld devices. >>> The >>> new push is to low end FPGAs in very small packages and price will be a >>> major issue. So far there aren't many pushing in that direction. The >>> processes are still digital. But once they broach this market more >>> they will be more inclined to break out of their mold and explore more >>> innovative areas like motor control with analog subsystems. >> >> Actually, both X and A have SoC offerings now that integrate ARM Cortex >> A9s with a mess of peripherals alongside the fabric. >> >> I'm actually really surprised at the balance they struck; they both >> decided to put a LOT of hard IP in. Gb Ethneret MAC, DRAM controller, >> all that stuff makes sense to me to harden. But they're also putting >> SPI, I2C, counter/timers, all the sort of stuff that seems like it would >> be just as easily implemented on the fabric. Beats me what the logic >> was. > > You can implement stuff in much less space (and probably power) if it's > hard-coded rather than implemented in the FPGA fabric -- that's why > there's a processor core in there and not just available IP. The logic > extends to peripherals: if it's something that's used a lot, then it's > worthwhile putting in. I suspect that the area difference is 10:1, which > would mean (roughly) that if you put in 10 different peripherals and each > customer used one and let the other 9 lie idle, that you'd break even on > area and come out ahead on power consumption.
Saving area is only useful if you *use* the IP. Adding a CPU pays a large dividend and would be a selection criterion for buying that chip. Adding an SPI interface would pay relatively little compared to a soft IP module and very unlikely to be a factor in selecting that FPGA. The other reason to use hard IP is if the performance improvement is significant. I'm not certain, but Gb Ethernet might be hard to do in soft IP. I2C not so much. All of that is aside from the issues being discussed elsewhere in this thread. A pair of ARM A9s and Ethernet interface are not needed for a motor controller while the analog peripherals are. -- Rick
On 9/22/2015 1:49 PM, Tim Wescott wrote:
> On Tue, 22 Sep 2015 10:21:35 -0400, rickman wrote: > >> On 9/21/2015 11:15 PM, Tim Wescott wrote: >>> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote: >>> >>>> 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. >>> >>> But could they be used to get the necessary clock resolution? >> >> A PLL might be able to do that. Adjusting the ratio of the two dividers >> would provide a high resolution clock rate. >> >> I don't think a delay line is used to adjust the clock frequency for the >> PWM. I expect the leading edge of the PWM is controlled from the clock >> directly and the trailing edge is controlled by the delayed clock. Is >> this wrong? I can see where temperature drift would be a significant >> factor in making a delay line circuit work correctly. The number of >> steps per clock cycle would change widely. When lengthening the pulse >> width, at what point are the steps zeroed and the clock count >> incremented instead? > > For there to be any point to extending the PWM resolution, you'd need to > be able to do it on a cycle-by-cycle basis. If you're using a PLL, it'd > have to come into it's new lock pretty damned fast.
I think that's not what the OP asked for. The two numbers he provided were 1 MHz PWM rate and 20 uS rail to rail changes. Maybe you can extract more useful info from that than I can. I'm not a motor controller designer. I see it analogous to the spec on a DAC. An input change has a significant change very quickly, but the full settling time would be longer to the specified resolution. Besides, what I am describing above is not a PLL at all. The idea is to use a conventional PWM with a fixed clock to set a pulse width and a delay line tap to fine tune only the trailing edge of the pulse. So generate a pulse with the PWM and OR it with a version passing through the tapped delay line. Immediate adjustment capability and high resolution although the fine adjustment is now subject to temperature influences. A friend designed a similar circuit for the USNO to generate a 1 pps signal and provide a time of day display for their latest and greatest atomic clock. It had a 10 &micro;s delay line with 1024 taps to let the 1 pps be synced to the master 1 pps signal. I forget the details of how it worked actually. That was more than a couple of years ago.
>>>>> 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. >>> >>> With or without the high-resolution PWM? >> >> There is no special hardware called "high resolution DWM". A PLL is >> standard on most parts and could be used to provide good resolution to a >> PWM by adjusting the clock rate. > > Fine. With or without the necessary hardware to implement a PWM > controller with less than one clock cycle resolution.
A PLL would work by adjusting the clock to suit the PWM so the term "less than one clock cycle resolution" would be a bit hard to interpret. It might be problematic if you needed wide, fast swings. I'm sure you can tell me more about that than I can tell you, or perhaps others here would know more. I think it would not be hard to implement a tapped delay line even in FPGA fabric. It may require specific placement control and detailed knowledge of the internal organization of the part, but I'm pretty sure it can be done. This level of FPGA usage is not common and often discouraged. It is the equivalent of assembly language programming or taking advantage of "tricks" in a higher level language which could be hard to port to other processors or tools. It would be reliable and repeatable within the same device and could easily be verified by the standard tools such as timing verification or post routing simulation.
>> I wonder if dithering in the PWM itself would be acceptable. The OP >> seems concerned about rail to rail steps in a short time, but this might >> not mean the high resolution is critical if it is obtained by dithering >> a lower resolution. That makes things much easier. The response time >> required seems to be 20 uS. I don't see a lot of other numbers in the >> requirements so it is hard to tell exactly what will work here. Driving >> the PWM with an NCO will give tons of resolution if the associated >> jitter is acceptable. > > I was going to raise this one myself -- that's for Rob to think about, > and maybe answer.
I await with bated breath. :) -- Rick
On Tue, 22 Sep 2015 14:38:17 -0400, rickman wrote:

> On 9/22/2015 1:49 PM, Tim Wescott wrote: >> On Tue, 22 Sep 2015 10:21:35 -0400, rickman wrote: >> >>> On 9/21/2015 11:15 PM, Tim Wescott wrote: >>>> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote: >>>> >>>>> 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. >>>> >>>> But could they be used to get the necessary clock resolution? >>> >>> A PLL might be able to do that. Adjusting the ratio of the two >>> dividers would provide a high resolution clock rate. >>> >>> I don't think a delay line is used to adjust the clock frequency for >>> the PWM. I expect the leading edge of the PWM is controlled from the >>> clock directly and the trailing edge is controlled by the delayed >>> clock. Is this wrong? I can see where temperature drift would be a >>> significant factor in making a delay line circuit work correctly. The >>> number of steps per clock cycle would change widely. When lengthening >>> the pulse width, at what point are the steps zeroed and the clock >>> count incremented instead? >> >> For there to be any point to extending the PWM resolution, you'd need >> to be able to do it on a cycle-by-cycle basis. If you're using a PLL, >> it'd have to come into it's new lock pretty damned fast. > > I think that's not what the OP asked for. The two numbers he provided > were 1 MHz PWM rate and 20 uS rail to rail changes. Maybe you can > extract more useful info from that than I can. I'm not a motor > controller designer. I see it analogous to the spec on a DAC. An input > change has a significant change very quickly, but the full settling time > would be longer to the specified resolution.
The rule of thumb for control systems is that you want to have at least ten clocks within the settling time of the loop after it has come out of nonlinear operation. 20us is 20 clock ticks at 1MHz, so even if the loop doesn't go nonlinear in the first place you're not out of line to ask for a 1MHz sample clock. If you did use a PLL (and you did mention using a PLL) then it would need to be fast enough to not contribute much phase shift at 1MHz.
> Besides, what I am describing above is not a PLL at all. The idea is to > use a conventional PWM with a fixed clock to set a pulse width and a > delay line tap to fine tune only the trailing edge of the pulse. So > generate a pulse with the PWM and OR it with a version passing through > the tapped delay line. Immediate adjustment capability and high > resolution although the fine adjustment is now subject to temperature > influences. > > A friend designed a similar circuit for the USNO to generate a 1 pps > signal and provide a time of day display for their latest and greatest > atomic clock. It had a 10 &micro;s delay line with 1024 taps to let the 1 pps > be synced to the master 1 pps signal. I forget the details of how it > worked actually. That was more than a couple of years ago. > > >>>>>> 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. >>>> >>>> With or without the high-resolution PWM? >>> >>> There is no special hardware called "high resolution DWM". A PLL is >>> standard on most parts and could be used to provide good resolution to >>> a PWM by adjusting the clock rate. >> >> Fine. With or without the necessary hardware to implement a PWM >> controller with less than one clock cycle resolution. > > A PLL would work by adjusting the clock to suit the PWM so the term > "less than one clock cycle resolution" would be a bit hard to interpret. > It might be problematic if you needed wide, fast swings. I'm sure you > can tell me more about that than I can tell you, or perhaps others here > would know more. > > I think it would not be hard to implement a tapped delay line even in > FPGA fabric. It may require specific placement control and detailed > knowledge of the internal organization of the part, but I'm pretty sure > it can be done. This level of FPGA usage is not common and often > discouraged. It is the equivalent of assembly language programming or > taking advantage of "tricks" in a higher level language which could be > hard to port to other processors or tools. It would be reliable and > repeatable within the same device and could easily be verified by the > standard tools such as timing verification or post routing simulation.
I would be more inclined to say it's like using assembly language to access some undocumented feature of the processor, even. I'd be suspicious as hell if someone presented the idea of using the FPGA fabric for this purpose. However, I could see it working if you had some sort of continual calibration -- perhaps a chain of gates down which you launch a clock pulse, with each gate's output latched each clock. Then you could read how far down the chain the pulse gets and use that to deduce the speed at that moment and adjust your PWM trim to match. This is starting to sound like we're designing either a lab queen, or a system that can only ever be used by one person. Keeping in mind that I'm not an FPGA guy, I wonder if you couldn't extend a counter by having two sections with two clocks: one is a traditional counter with a magnitude comparator to generate the "main" PWM, and the other is just a string of D flip-flops that (I believe) can be clocked at a faster rate because there's only one gate of delay between sections. OTOH, I suppose that an aggressively pipelined counter could be made that would do essentially the same thing.
>>> I wonder if dithering in the PWM itself would be acceptable. The OP >>> seems concerned about rail to rail steps in a short time, but this >>> might not mean the high resolution is critical if it is obtained by >>> dithering a lower resolution. That makes things much easier. The >>> response time required seems to be 20 uS. I don't see a lot of other >>> numbers in the requirements so it is hard to tell exactly what will >>> work here. Driving the PWM with an NCO will give tons of resolution >>> if the associated jitter is acceptable. >> >> I was going to raise this one myself -- that's for Rob to think about, >> and maybe answer. > > I await with bated breath. :)
Me, too. And -- thank you for spelling "bated" correctly. I've been inundated with a lot of "baited breaths" and "mute points" and other such spell- checkerisms lately. Reading the Ones that Got It Right is an ongoing relief. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Tue, 22 Sep 2015 14:18:47 -0500, Tim Wescott wrote:

> On Tue, 22 Sep 2015 14:38:17 -0400, rickman wrote: > >> I think it would not be hard to implement a tapped delay line even in >> FPGA fabric. It may require specific placement control and detailed >> knowledge of the internal organization of the part, but I'm pretty sure >> it can be done. This level of FPGA usage is not common and often >> discouraged. It is the equivalent of assembly language programming or >> taking advantage of "tricks" in a higher level language which could be >> hard to port to other processors or tools. It would be reliable and >> repeatable within the same device and could easily be verified by the >> standard tools such as timing verification or post routing simulation. > > I would be more inclined to say it's like using assembly language to > access some undocumented feature of the processor, even. > > I'd be suspicious as hell if someone presented the idea of using the > FPGA fabric for this purpose. However, I could see it working if you > had some sort of continual calibration -- perhaps a chain of gates down > which you launch a clock pulse, with each gate's output latched each > clock. Then you could read how far down the chain the pulse gets and > use that to deduce the speed at that moment and adjust your PWM trim to > match. >
Can and has been done (though not by me) pretty much exactly that way. The way I've seen it done was to build a parallel delay chain, and servo VCC to keep the end to end delay constant.
> This is starting to sound like we're designing either a lab queen, or a > system that can only ever be used by one person. >
And there's the rub. When I'm doing my FPGA guy thing, that's the sort of desperation play that I'd need an incredibly compelling reason to run. Manually constraining place and route at that level is a huge pain and requires a ton of manual verification to make sure you've gotten it right. The timing constraint tools aren't set up to do that sort of thing, so it's compile, check, repeat until you've got it. And of course, since the tools don't want you doing that, they fight you every step of the way while the vendor support people say "Well then don't do that." Meanwhile, some of those TI chips I'm eyeballing are under $10 overpaying Digikey for 50 piece quantities. No rolling my own PLD trickery, ADCs already onboard and plenty of horsepower to handle both my control loop and an idiot UART interface off to the side.
> Keeping in mind that I'm not an FPGA guy, I wonder if you couldn't > extend a counter by having two sections with two clocks: one is a > traditional counter with a magnitude comparator to generate the "main" > PWM, and the other is just a string of D flip-flops that (I believe) can > be clocked at a faster rate because there's only one gate of delay > between sections. > > OTOH, I suppose that an aggressively pipelined counter could be made > that would do essentially the same thing. >
Yeah, but trying to run the entire counter at that rate will get your chip very hot very fast. I've done that first trick before; it's pretty easy so long as you maintain an integer frequency ratio between your slow and fast clock.
>>>> I wonder if dithering in the PWM itself would be acceptable. The OP >>>> seems concerned about rail to rail steps in a short time, but this >>>> might not mean the high resolution is critical if it is obtained by >>>> dithering a lower resolution. That makes things much easier. The >>>> response time required seems to be 20 uS. I don't see a lot of other >>>> numbers in the requirements so it is hard to tell exactly what will >>>> work here. Driving the PWM with an NCO will give tons of resolution >>>> if the associated jitter is acceptable. >>>
It'd translate into additional ripple in the supply; I'm already up against the wall on that front without wasting any margin.
>>> I was going to raise this one myself -- that's for Rob to think about, >>> and maybe answer. >> >> I await with bated breath. :) > > Me, too. > > And -- thank you for spelling "bated" correctly. I've been inundated > with a lot of "baited breaths" and "mute points" and other such spell- > checkerisms lately. Reading the Ones that Got It Right is an ongoing > relief.
Well I'm just glad I was here to take the bate. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
On 9/22/2015 3:18 PM, Tim Wescott wrote:
> On Tue, 22 Sep 2015 14:38:17 -0400, rickman wrote: > >> On 9/22/2015 1:49 PM, Tim Wescott wrote: >>> On Tue, 22 Sep 2015 10:21:35 -0400, rickman wrote: >>> >>>> On 9/21/2015 11:15 PM, Tim Wescott wrote: >>>>> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote: >>>>> >>>>>> 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. >>>>> >>>>> But could they be used to get the necessary clock resolution? >>>> >>>> A PLL might be able to do that. Adjusting the ratio of the two >>>> dividers would provide a high resolution clock rate. >>>> >>>> I don't think a delay line is used to adjust the clock frequency for >>>> the PWM. I expect the leading edge of the PWM is controlled from the >>>> clock directly and the trailing edge is controlled by the delayed >>>> clock. Is this wrong? I can see where temperature drift would be a >>>> significant factor in making a delay line circuit work correctly. The >>>> number of steps per clock cycle would change widely. When lengthening >>>> the pulse width, at what point are the steps zeroed and the clock >>>> count incremented instead? >>> >>> For there to be any point to extending the PWM resolution, you'd need >>> to be able to do it on a cycle-by-cycle basis. If you're using a PLL, >>> it'd have to come into it's new lock pretty damned fast. >> >> I think that's not what the OP asked for. The two numbers he provided >> were 1 MHz PWM rate and 20 uS rail to rail changes. Maybe you can >> extract more useful info from that than I can. I'm not a motor >> controller designer. I see it analogous to the spec on a DAC. An input >> change has a significant change very quickly, but the full settling time >> would be longer to the specified resolution. > > The rule of thumb for control systems is that you want to have at least > ten clocks within the settling time of the loop after it has come out of > nonlinear operation. 20us is 20 clock ticks at 1MHz, so even if the loop > doesn't go nonlinear in the first place you're not out of line to ask for > a 1MHz sample clock. > > If you did use a PLL (and you did mention using a PLL) then it would need > to be fast enough to not contribute much phase shift at 1MHz.
On a PLL that is just a matter of the low pass filter. The design issue is making it stable.
>> Besides, what I am describing above is not a PLL at all. The idea is to >> use a conventional PWM with a fixed clock to set a pulse width and a >> delay line tap to fine tune only the trailing edge of the pulse. So >> generate a pulse with the PWM and OR it with a version passing through >> the tapped delay line. Immediate adjustment capability and high >> resolution although the fine adjustment is now subject to temperature >> influences. >> >> A friend designed a similar circuit for the USNO to generate a 1 pps >> signal and provide a time of day display for their latest and greatest >> atomic clock. It had a 10 &micro;s delay line with 1024 taps to let the 1 pps >> be synced to the master 1 pps signal. I forget the details of how it >> worked actually. That was more than a couple of years ago. >> >> >>>>>>> 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. >>>>> >>>>> With or without the high-resolution PWM? >>>> >>>> There is no special hardware called "high resolution DWM". A PLL is >>>> standard on most parts and could be used to provide good resolution to >>>> a PWM by adjusting the clock rate. >>> >>> Fine. With or without the necessary hardware to implement a PWM >>> controller with less than one clock cycle resolution. >> >> A PLL would work by adjusting the clock to suit the PWM so the term >> "less than one clock cycle resolution" would be a bit hard to interpret. >> It might be problematic if you needed wide, fast swings. I'm sure you >> can tell me more about that than I can tell you, or perhaps others here >> would know more. >> >> I think it would not be hard to implement a tapped delay line even in >> FPGA fabric. It may require specific placement control and detailed >> knowledge of the internal organization of the part, but I'm pretty sure >> it can be done. This level of FPGA usage is not common and often >> discouraged. It is the equivalent of assembly language programming or >> taking advantage of "tricks" in a higher level language which could be >> hard to port to other processors or tools. It would be reliable and >> repeatable within the same device and could easily be verified by the >> standard tools such as timing verification or post routing simulation. > > I would be more inclined to say it's like using assembly language to > access some undocumented feature of the processor, even.
Not very valid. The structure and timing of all the components have to be set in stone or *any* design will not continue to work. So these are not features that can change appreciably, nor are the truly undocumented. The chip editor shows all the structure and the timing analyzer has all the timing info.
> I'd be suspicious as hell if someone presented the idea of using the FPGA > fabric for this purpose. However, I could see it working if you had some > sort of continual calibration -- perhaps a chain of gates down which you > launch a clock pulse, with each gate's output latched each clock. Then > you could read how far down the chain the pulse gets and use that to > deduce the speed at that moment and adjust your PWM trim to match.
Your suspicions are not relevant to how well an FPGA design works. What is important is how well it actually works. Yes, some calibration would help and should be fairly simple to implement. Two chains in parallel, one for calibration and the other for signal delay should work. The physically closer they are, the better matched they will be, but process variation across the chip should be very small and voltage/temperature variation should also be unimportant for anything but a large chip.
> This is starting to sound like we're designing either a lab queen, or a > system that can only ever be used by one person.
That is not a founded statement. I think just the opposite, it has more potential as further explored.
> Keeping in mind that I'm not an FPGA guy, I wonder if you couldn't extend > a counter by having two sections with two clocks: one is a traditional > counter with a magnitude comparator to generate the "main" PWM, and the > other is just a string of D flip-flops that (I believe) can be clocked at > a faster rate because there's only one gate of delay between sections.
The limitation in the clock rate is not really because of logic. As someone mentioned 500 MHz is an approximate upper limit for nearly any logic in an FPGA other than perhaps a SERDES which brings up another approach. But there is nothing to say the output couldn't be a combination of coarse and fine PWMs where each one runs from the same clock, but the fine PWM is given a low weight by an analog summer. Sort of a combination of PWM and DAC. That should give as much resolution as you can get from the analog circuit. The SERDES can get GHz pulse rates using the internal PLL of the SERDES. It is fed words of data which would be all '1's until the trailing pulse edge which would be a string of '1's and '0's depending on where you want the edge located. This should get you down to the 100's of ps range.
> OTOH, I suppose that an aggressively pipelined counter could be made that > would do essentially the same thing.
Counters don't typically need to be pipelined as they are already highly optimized in FPGAs. They only need pipelining if they are very long. But I don't work at 500 MHz often, so no promises.
>>>> I wonder if dithering in the PWM itself would be acceptable. The OP >>>> seems concerned about rail to rail steps in a short time, but this >>>> might not mean the high resolution is critical if it is obtained by >>>> dithering a lower resolution. That makes things much easier. The >>>> response time required seems to be 20 uS. I don't see a lot of other >>>> numbers in the requirements so it is hard to tell exactly what will >>>> work here. Driving the PWM with an NCO will give tons of resolution >>>> if the associated jitter is acceptable. >>> >>> I was going to raise this one myself -- that's for Rob to think about, >>> and maybe answer. >> >> I await with bated breath. :) > > Me, too. > > And -- thank you for spelling "bated" correctly. I've been inundated > with a lot of "baited breaths" and "mute points" and other such spell- > checkerisms lately. Reading the Ones that Got It Right is an ongoing > relief.
I knew how to spell it correctly, but looked up the meaning to make sure I was using the right word. "Bated" is not one I use every day, lol. BTW, I thought it was "moop" point! lol Seinfeld I believe. Or maybe that was the "Moops" rather than the "Moors". -- Rick
On 9/22/2015 4:04 PM, Rob Gaddi wrote:
> On Tue, 22 Sep 2015 14:18:47 -0500, Tim Wescott wrote: > >> On Tue, 22 Sep 2015 14:38:17 -0400, rickman wrote: >> >>> I think it would not be hard to implement a tapped delay line even in >>> FPGA fabric. It may require specific placement control and detailed >>> knowledge of the internal organization of the part, but I'm pretty sure >>> it can be done. This level of FPGA usage is not common and often >>> discouraged. It is the equivalent of assembly language programming or >>> taking advantage of "tricks" in a higher level language which could be >>> hard to port to other processors or tools. It would be reliable and >>> repeatable within the same device and could easily be verified by the >>> standard tools such as timing verification or post routing simulation. >> >> I would be more inclined to say it's like using assembly language to >> access some undocumented feature of the processor, even. >> >> I'd be suspicious as hell if someone presented the idea of using the >> FPGA fabric for this purpose. However, I could see it working if you >> had some sort of continual calibration -- perhaps a chain of gates down >> which you launch a clock pulse, with each gate's output latched each >> clock. Then you could read how far down the chain the pulse gets and >> use that to deduce the speed at that moment and adjust your PWM trim to >> match. >> > > Can and has been done (though not by me) pretty much exactly that way. > The way I've seen it done was to build a parallel delay chain, and servo > VCC to keep the end to end delay constant. > >> This is starting to sound like we're designing either a lab queen, or a >> system that can only ever be used by one person. >> > > And there's the rub. When I'm doing my FPGA guy thing, that's the sort > of desperation play that I'd need an incredibly compelling reason to > run. Manually constraining place and route at that level is a huge pain > and requires a ton of manual verification to make sure you've gotten it > right. The timing constraint tools aren't set up to do that sort of > thing, so it's compile, check, repeat until you've got it. And of > course, since the tools don't want you doing that, they fight you every > step of the way while the vendor support people say "Well then don't do > that."
I'm not sure what you mean. The tools don't care one hoot if you manually constrain placement. They all still work fine. The routing would need to be laid out manually and would take a bit of time. But once that is done the first time it can be turned into a macro for subsequent runs of the same design.
> Meanwhile, some of those TI chips I'm eyeballing are under $10 overpaying > Digikey for 50 piece quantities. No rolling my own PLD trickery, ADCs > already onboard and plenty of horsepower to handle both my control loop > and an idiot UART interface off to the side.
I thought you said you were concerned about the processor performance? I know I don't like to do timing related things in a processor that has to do more than one thing. Not that it won't work, but there are often issues with timing when everything is sequential.
>> Keeping in mind that I'm not an FPGA guy, I wonder if you couldn't >> extend a counter by having two sections with two clocks: one is a >> traditional counter with a magnitude comparator to generate the "main" >> PWM, and the other is just a string of D flip-flops that (I believe) can >> be clocked at a faster rate because there's only one gate of delay >> between sections. >> >> OTOH, I suppose that an aggressively pipelined counter could be made >> that would do essentially the same thing. >> > > Yeah, but trying to run the entire counter at that rate will get your > chip very hot very fast. I've done that first trick before; it's pretty > easy so long as you maintain an integer frequency ratio between your slow > and fast clock.
Like I've said, I don't often run 500 MHz (or ever), but I've also never seen a simple FPGA design use any more power than an MCU. Any one counter will use microscopic power levels. If you have a bank of 50 of them all running at 500 MHz, that might be a different matter.
>>>>> I wonder if dithering in the PWM itself would be acceptable. The OP >>>>> seems concerned about rail to rail steps in a short time, but this >>>>> might not mean the high resolution is critical if it is obtained by >>>>> dithering a lower resolution. That makes things much easier. The >>>>> response time required seems to be 20 uS. I don't see a lot of other >>>>> numbers in the requirements so it is hard to tell exactly what will >>>>> work here. Driving the PWM with an NCO will give tons of resolution >>>>> if the associated jitter is acceptable. >>>> > > It'd translate into additional ripple in the supply; I'm already up > against the wall on that front without wasting any margin.
So what of the dual PWM, high/low resolution approach? But if you are happy with a DSP, there's no point in pursuing this really. Some are more comfortable dealing with timing issues of sequential software. I'm more comfortable with the relatively simple issues of designing with FPGAs. -- Rick
On Tue, 22 Sep 2015 17:42:33 -0400, rickman wrote:

> On 9/22/2015 3:18 PM, Tim Wescott wrote: >> On Tue, 22 Sep 2015 14:38:17 -0400, rickman wrote: >> >>> On 9/22/2015 1:49 PM, Tim Wescott wrote: >>>> On Tue, 22 Sep 2015 10:21:35 -0400, rickman wrote: >>>> >>>>> On 9/21/2015 11:15 PM, Tim Wescott wrote: >>>>>> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote: >>>>>> >>>>>>> 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. >>>>>> >>>>>> But could they be used to get the necessary clock resolution? >>>>> >>>>> A PLL might be able to do that. Adjusting the ratio of the two >>>>> dividers would provide a high resolution clock rate. >>>>> >>>>> I don't think a delay line is used to adjust the clock frequency for >>>>> the PWM. I expect the leading edge of the PWM is controlled from >>>>> the clock directly and the trailing edge is controlled by the >>>>> delayed clock. Is this wrong? I can see where temperature drift >>>>> would be a significant factor in making a delay line circuit work >>>>> correctly. The number of steps per clock cycle would change widely. >>>>> When lengthening the pulse width, at what point are the steps >>>>> zeroed and the clock count incremented instead? >>>> >>>> For there to be any point to extending the PWM resolution, you'd need >>>> to be able to do it on a cycle-by-cycle basis. If you're using a >>>> PLL, >>>> it'd have to come into it's new lock pretty damned fast. >>> >>> I think that's not what the OP asked for. The two numbers he provided >>> were 1 MHz PWM rate and 20 uS rail to rail changes. Maybe you can >>> extract more useful info from that than I can. I'm not a motor >>> controller designer. I see it analogous to the spec on a DAC. An >>> input change has a significant change very quickly, but the full >>> settling time would be longer to the specified resolution. >> >> The rule of thumb for control systems is that you want to have at least >> ten clocks within the settling time of the loop after it has come out >> of nonlinear operation. 20us is 20 clock ticks at 1MHz, so even if the >> loop doesn't go nonlinear in the first place you're not out of line to >> ask for a 1MHz sample clock. >> >> If you did use a PLL (and you did mention using a PLL) then it would >> need to be fast enough to not contribute much phase shift at 1MHz. > > On a PLL that is just a matter of the low pass filter. The design issue > is making it stable. > > >>> Besides, what I am describing above is not a PLL at all. The idea is >>> to use a conventional PWM with a fixed clock to set a pulse width and >>> a delay line tap to fine tune only the trailing edge of the pulse. So >>> generate a pulse with the PWM and OR it with a version passing through >>> the tapped delay line. Immediate adjustment capability and high >>> resolution although the fine adjustment is now subject to temperature >>> influences. >>> >>> A friend designed a similar circuit for the USNO to generate a 1 pps >>> signal and provide a time of day display for their latest and greatest >>> atomic clock. It had a 10 &micro;s delay line with 1024 taps to let the 1 >>> pps be synced to the master 1 pps signal. I forget the details of how >>> it worked actually. That was more than a couple of years ago. >>> >>> >>>>>>>> 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. >>>>>> >>>>>> With or without the high-resolution PWM? >>>>> >>>>> There is no special hardware called "high resolution DWM". A PLL is >>>>> standard on most parts and could be used to provide good resolution >>>>> to a PWM by adjusting the clock rate. >>>> >>>> Fine. With or without the necessary hardware to implement a PWM >>>> controller with less than one clock cycle resolution. >>> >>> A PLL would work by adjusting the clock to suit the PWM so the term >>> "less than one clock cycle resolution" would be a bit hard to >>> interpret. >>> It might be problematic if you needed wide, fast swings. I'm sure >>> you >>> can tell me more about that than I can tell you, or perhaps others >>> here would know more. >>> >>> I think it would not be hard to implement a tapped delay line even in >>> FPGA fabric. It may require specific placement control and detailed >>> knowledge of the internal organization of the part, but I'm pretty >>> sure it can be done. This level of FPGA usage is not common and often >>> discouraged. It is the equivalent of assembly language programming or >>> taking advantage of "tricks" in a higher level language which could be >>> hard to port to other processors or tools. It would be reliable and >>> repeatable within the same device and could easily be verified by the >>> standard tools such as timing verification or post routing simulation. >> >> I would be more inclined to say it's like using assembly language to >> access some undocumented feature of the processor, even. > > Not very valid. The structure and timing of all the components have to > be set in stone or *any* design will not continue to work. So these are > not features that can change appreciably, nor are the truly > undocumented. The chip editor shows all the structure and the timing > analyzer has all the timing info. > > >> I'd be suspicious as hell if someone presented the idea of using the >> FPGA fabric for this purpose. However, I could see it working if you >> had some sort of continual calibration -- perhaps a chain of gates down >> which you launch a clock pulse, with each gate's output latched each >> clock. Then you could read how far down the chain the pulse gets and >> use that to deduce the speed at that moment and adjust your PWM trim to >> match. > > Your suspicions are not relevant to how well an FPGA design works. What > is important is how well it actually works. Yes, some calibration would > help and should be fairly simple to implement. Two chains in parallel, > one for calibration and the other for signal delay should work. The > physically closer they are, the better matched they will be, but process > variation across the chip should be very small and voltage/temperature > variation should also be unimportant for anything but a large chip. > > >> This is starting to sound like we're designing either a lab queen, or a >> system that can only ever be used by one person. > > That is not a founded statement. I think just the opposite, it has more > potential as further explored. > > >> Keeping in mind that I'm not an FPGA guy, I wonder if you couldn't >> extend a counter by having two sections with two clocks: one is a >> traditional counter with a magnitude comparator to generate the "main" >> PWM, and the other is just a string of D flip-flops that (I believe) >> can be clocked at a faster rate because there's only one gate of delay >> between sections. > > The limitation in the clock rate is not really because of logic. As > someone mentioned 500 MHz is an approximate upper limit for nearly any > logic in an FPGA other than perhaps a SERDES which brings up another > approach. But there is nothing to say the output couldn't be a > combination of coarse and fine PWMs where each one runs from the same > clock, but the fine PWM is given a low weight by an analog summer. Sort > of a combination of PWM and DAC. That should give as much resolution as > you can get from the analog circuit.
I'm not sure what you think is being done, here, but in this sort of control circuit the PWM pin is connected to a gate driver which is connected to a transistor gate. The only analog that's happening is steering many amps at many volts -- "low level" is not to be found on that side of the design. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Tim Wescott <seemywebsite@myfooter.really> writes:
> [...] > This is starting to sound like we're designing either a lab queen, or a > system that can only ever be used by one person.
What's a "lab queen?" -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com