Digital Power Control

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