Den onsdag den 23. september 2015 kl. 21.16.36 UTC+2 skrev rickman:> On 9/23/2015 2:50 PM, Tim Wescott wrote: > > On Wed, 23 Sep 2015 14:18:15 -0400, rickman wrote: > > > >> On 9/23/2015 1:42 PM, Tim Wescott wrote: > >>> On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote: > >>> > >>>> 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. > >>> > >>> No, saving area is only useful if it makes the chip less expensive or > >>> (assuming I care) consume less power. If 10 peripherals, together, are > >>> smaller and less expensive than the generic fabric I need to implement > >>> the one I actually use, then I don't give a crap about the unused 9 -- > >>> I'll just chortle happily every time I review the BOM. > >> > >> What does the BOM have to do with it? None of this will add any parts > >> or is at all likely to require a larger part. If this was the guiding > >> principle to adding hard IP, there would be a lot more hard IP on a lot > >> more FPGAs. > > > > Man, if I said "what does the BOM have to do with it" to a customer for > > whom I was designing a board, I would only have myself to blame if they > > hung up on me and expunged me from their files. > > > > BOM "has to do with it" because BOM cost matters. It just does. > > > >>> If I'm trying to minimize power consumption and the one peripheral I > >>> use takes 1/3 the power (I'm just inventing numbers in my head here, > >>> BTW) that I'd need to implement it in the fabric, then I may be willing > >>> to pay _more_ for the chip, even. > >>> > >>> So, I disagree. > >> > >> Trouble is all your numbers are made up and it assumes that all designs > >> using that FPGA will use *any* of the added hard IP. > > > > Well, yes, my numbers are made up, for illustrative purposes. I'm > > assuming that -- being an engineer -- you know how to get the gist of > > what I'm saying without getting hung up on the specific numbers. > > > > My point is made even if not all designs using an FPGA use any of the > > added IP. If Xilinx can make one chip with added hard IP for cheaper > > than it can make two chips, one with the added IP and one without, and if > > it passes that savings on to its customers, then the people who use the > > chips without ever turning on the hard IP benefit from having a chip to > > use in the first place. > > > > Since you don't want me to use made-up numbers, I'll just use > > inequalities. If X > Y > Z represent three dollar amounts, would you > > Xilinx sold chip x (with hard IP that you don't have to use) and chip y > > (without), at costs X and Y, or would you rather Xilinx sold only chip x > > at cost Z, or would you rather pay a premium for chip y so that you can > > use it without offending your sensibilities? > > Actually this is not the comparison. If chip Y is cheaper than chip X > and also cheaper than chip Z, then offer the SPI, I2C, etc as soft IP > and be done with it. Quit making stuff up! >that's not what he wrote, x cost X, y cost Y, but if y wasn't build x could be sold for Z only one chip need to be designed, everyone saves money and those who doesn't need the extra stuff can ignore it -Lasse
Digital Power Control
Started by ●September 21, 2015
Reply by ●September 23, 20152015-09-23
Reply by ●September 23, 20152015-09-23
robert bristow-johnson <rbj@audioimagination.com> writes:> On 9/23/15 5:40 PM, Tim Wescott wrote: >> On Wed, 23 Sep 2015 14:28:52 -0700, gyansorova wrote: >> >>> On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? >>>> >>>> -- >>>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email >>>> address domain is currently out of order. See above to fix. >>> >>> I think you need FPGAs. You will always have nano seconds latency since >>> your code executes serially. >> >> Rob mentions elsewhere that he's looking at a 1MHz sampling rate > > can someone explain why or what the device is that draws power from > some DSP-controlled power source (say PWM or PDM, which seems to me to > be about the same as sigma-delta) that needs a sample rate of 1MHz? > >> and a 20us ramp from zero to full-on. > > > i fail to see why that ramp needs to be sampled 20 times from zero to rails. > > i admit that i am outa my element, but i'm having trouble visualizing > this. what power controller needs such a spec? what's it powering? > > is it step response envelope delay?Hey Robert, Blind leading the blind but here goes... It's a feedback control system. If the desired step response is 20 microseconds, you need to be sampling the output a good bit faster and running that through your feedback loop. There's also the issue of latency - you always want to minimize latency in order to improve stability - and increasing the sample rate, even if you don't need the bandwidth, is a way to reduce latency in a sampled control system. If you're like me, the barrage of terms is also confusing. To help with that, you can look at the reference guide I was referring to in another post, the TI SPRUG77B on their "high-resolution pulse width modulator" in the Delfino series (TMS320x2834x). Figure 1 there shows a nice, basic picture of the PWM signal and it's parameters. T_{PWM} there is what has been called here in various posts as the "sample rate" and "switching frequency." The T_{SYSCLK} is the parameter Rob was referring to when he mentioned 150ps. Rob, Tim, Rick, whoever, correct me if I got something wrong here. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●September 23, 20152015-09-23
Randy Yates <yates@digitalsignallabs.com> writes:> robert bristow-johnson <rbj@audioimagination.com> writes: > >> On 9/23/15 5:40 PM, Tim Wescott wrote: >>> On Wed, 23 Sep 2015 14:28:52 -0700, gyansorova wrote: >>> >>>> On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? >>>>> >>>>> -- >>>>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email >>>>> address domain is currently out of order. See above to fix. >>>> >>>> I think you need FPGAs. You will always have nano seconds latency since >>>> your code executes serially. >>> >>> Rob mentions elsewhere that he's looking at a 1MHz sampling rate >> >> can someone explain why or what the device is that draws power from >> some DSP-controlled power source (say PWM or PDM, which seems to me to >> be about the same as sigma-delta) that needs a sample rate of 1MHz? >> >>> and a 20us ramp from zero to full-on. >> >> >> i fail to see why that ramp needs to be sampled 20 times from zero to rails. >> >> i admit that i am outa my element, but i'm having trouble visualizing >> this. what power controller needs such a spec? what's it powering? >> >> is it step response envelope delay? > > Hey Robert, > > Blind leading the blind but here goes... > > It's a feedback control system. If the desired step response is 20 > microseconds, you need to be sampling the output a good bit faster and > running that through your feedback loop. There's also the issue of > latency - you always want to minimize latency in order to improve > stability - and increasing the sample rate, even if you don't need the > bandwidth, is a way to reduce latency in a sampled control system. > > If you're like me, the barrage of terms is also confusing. To help with > that, you can look at the reference guide I was referring to in another > post, the TI SPRUG77B on their "high-resolution pulse width modulator" > in the Delfino series (TMS320x2834x). Figure 1 there shows a nice, basic > picture of the PWM signal and it's parameters. > > T_{PWM} there is what has been called here in various posts as the > "sample rate" and "switching frequency." The T_{SYSCLK} is the parameter > Rob was referring to when he mentioned 150ps. > > Rob, Tim, Rick, whoever, correct me if I got something wrong here....continued... http://www.ti.com.cn/general/cn/docs/lit/getliterature.tsp?baseLiteratureNumber=sprug77&fileType=pdf You can see from the "PWM resolution (bits)" there that the number of bits increases as T_{SYSCLK} decreases (higher frequency) and T_{PWM} increases (lower frequency). Thus you have the classic engineering tradeoff: given a fixed T_{SYSCLK} you want to increase T_{PWM} to improve the number of bits, but you want to decrease T_{PWM} to increase the sample rate. Or viewed another way, you have to have a low T_{SYSCLK} if you simultaneously want a high sample rate and more bits. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●September 23, 20152015-09-23
Rob Gaddi <rgaddi@technologyhighland.invalid> writes:> 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?PS: Rob, are you considering using GaN devices? Aren't they known (basically) for their low on-resistance and high switching rates? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●September 23, 20152015-09-23
On 9/23/15 8:09 PM, Randy Yates wrote:> Randy Yates<yates@digitalsignallabs.com> writes: > >> robert bristow-johnson<rbj@audioimagination.com> writes: >> >>> On 9/23/15 5:40 PM, Tim Wescott wrote: >>>> On Wed, 23 Sep 2015 14:28:52 -0700, gyansorova wrote: >>>> >>>>> On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? >>>>>> >>>>>> -- >>>>>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email >>>>>> address domain is currently out of order. See above to fix. >>>>> >>>>> I think you need FPGAs. You will always have nano seconds latency since >>>>> your code executes serially. >>>> >>>> Rob mentions elsewhere that he's looking at a 1MHz sampling rate >>> >>> can someone explain why or what the device is that draws power from >>> some DSP-controlled power source (say PWM or PDM, which seems to me to >>> be about the same as sigma-delta) that needs a sample rate of 1MHz? >>> >>>> and a 20us ramp from zero to full-on. >>> >>> >>> i fail to see why that ramp needs to be sampled 20 times from zero to rails. >>> >>> i admit that i am outa my element, but i'm having trouble visualizing >>> this. what power controller needs such a spec? what's it powering? >>> >>> is it step response envelope delay? >> >> Hey Robert, >> >> Blind leading the blind but here goes... >> >> It's a feedback control system. If the desired step response is 20 >> microseconds, you need to be sampling the output a good bit faster and >> running that through your feedback loop. There's also the issue of >> latency - you always want to minimize latency in order to improve >> stability - and increasing the sample rate, even if you don't need the >> bandwidth, is a way to reduce latency in a sampled control system. >> >> If you're like me, the barrage of terms is also confusing. To help with >> that, you can look at the reference guide I was referring to in another >> post, the TI SPRUG77B on their "high-resolution pulse width modulator" >> in the Delfino series (TMS320x2834x). Figure 1 there shows a nice, basic >> picture of the PWM signal and it's parameters. >> >> T_{PWM} there is what has been called here in various posts as the >> "sample rate" and "switching frequency." The T_{SYSCLK} is the parameter >> Rob was referring to when he mentioned 150ps. >> >> Rob, Tim, Rick, whoever, correct me if I got something wrong here. > > ...continued... > > http://www.ti.com.cn/general/cn/docs/lit/getliterature.tsp?baseLiteratureNumber=sprug77&fileType=pdf > > You can see from the "PWM resolution (bits)" there that the number of > bits increases as T_{SYSCLK} decreases (higher frequency) and T_{PWM} > increases (lower frequency). > > Thus you have the classic engineering tradeoff: given a fixed T_{SYSCLK} > you want to increase T_{PWM} to improve the number of bits, but you want > to decrease T_{PWM} to increase the sample rate. Or viewed another > way, you have to have a low T_{SYSCLK} if you simultaneously want > a high sample rate and more bits.thanks, Randy. i understand the naive resolution issue regarding log2(T_{PWM}/T_{SYSCLK}). i still don't understand why you would need the fire-breathing speed of an FPGA to do the time_on and time_off calculation to get decent resolution (without ripple below some given frequency). looks like this device is meant to do something. you can do simple high-resolution PWM by toggling between N*T_{SYSCLK} and (N+1)*T_{SYSCLK} using fraction saving. if the intended duty cycle is (N+f)/M where M*T_{SYSCLK} is the whole period of the waveform and the fractional part is 0 <= f < 1, you just toggle the "on time" to be N*T_{SYSCLK} for the fraction of the time that is 1-f and (N+1)*T_{SYSCLK} for the fraction that is f. and you can do even better. you get the DC value that you want and you can spread out the spectrum of what you don't want even better with pulse-density modulation, which i think sigma-delta does nicely. and i can understand fast response times for something like a tiny-little servo motor that's controlling a delicate little mechanical arm, and i can understand fast response times for something like a radiator (like a heat or light emitter that's gotta be controlled). but i can't understand why a cheap little 10 MHz PIC or something can't handle the job. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●September 23, 20152015-09-23
On 9/23/2015 7:22 PM, lasselangwadtchristensen@gmail.com wrote:> Den onsdag den 23. september 2015 kl. 21.16.36 UTC+2 skrev rickman: >> On 9/23/2015 2:50 PM, Tim Wescott wrote: >>> On Wed, 23 Sep 2015 14:18:15 -0400, rickman wrote: >>> >>>> On 9/23/2015 1:42 PM, Tim Wescott wrote: >>>>> On Tue, 22 Sep 2015 13:56:57 -0400, rickman wrote: >>>>> >>>>>> 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. >>>>> >>>>> No, saving area is only useful if it makes the chip less expensive or >>>>> (assuming I care) consume less power. If 10 peripherals, together, are >>>>> smaller and less expensive than the generic fabric I need to implement >>>>> the one I actually use, then I don't give a crap about the unused 9 -- >>>>> I'll just chortle happily every time I review the BOM. >>>> >>>> What does the BOM have to do with it? None of this will add any parts >>>> or is at all likely to require a larger part. If this was the guiding >>>> principle to adding hard IP, there would be a lot more hard IP on a lot >>>> more FPGAs. >>> >>> Man, if I said "what does the BOM have to do with it" to a customer for >>> whom I was designing a board, I would only have myself to blame if they >>> hung up on me and expunged me from their files. >>> >>> BOM "has to do with it" because BOM cost matters. It just does. >>> >>>>> If I'm trying to minimize power consumption and the one peripheral I >>>>> use takes 1/3 the power (I'm just inventing numbers in my head here, >>>>> BTW) that I'd need to implement it in the fabric, then I may be willing >>>>> to pay _more_ for the chip, even. >>>>> >>>>> So, I disagree. >>>> >>>> Trouble is all your numbers are made up and it assumes that all designs >>>> using that FPGA will use *any* of the added hard IP. >>> >>> Well, yes, my numbers are made up, for illustrative purposes. I'm >>> assuming that -- being an engineer -- you know how to get the gist of >>> what I'm saying without getting hung up on the specific numbers. >>> >>> My point is made even if not all designs using an FPGA use any of the >>> added IP. If Xilinx can make one chip with added hard IP for cheaper >>> than it can make two chips, one with the added IP and one without, and if >>> it passes that savings on to its customers, then the people who use the >>> chips without ever turning on the hard IP benefit from having a chip to >>> use in the first place. >>> >>> Since you don't want me to use made-up numbers, I'll just use >>> inequalities. If X > Y > Z represent three dollar amounts, would you >>> Xilinx sold chip x (with hard IP that you don't have to use) and chip y >>> (without), at costs X and Y, or would you rather Xilinx sold only chip x >>> at cost Z, or would you rather pay a premium for chip y so that you can >>> use it without offending your sensibilities? >> >> Actually this is not the comparison. If chip Y is cheaper than chip X >> and also cheaper than chip Z, then offer the SPI, I2C, etc as soft IP >> and be done with it. Quit making stuff up! >> > > that's not what he wrote, > > x cost X, y cost Y, but if y wasn't build x could be sold for Z > > only one chip need to be designed, everyone saves money and those who > doesn't need the extra stuff can ignore itThat's my point. His example doesn't include the case of just building Y and no X or Z. X has the extra hard logic and Y can be built for less than any of the above. -- Rick
Reply by ●September 23, 20152015-09-23
robert bristow-johnson <rbj@audioimagination.com> writes:> i understand the naive resolution issue regarding > log2(T_{PWM}/T_{SYSCLK}). i still don't understand why you would need > the fire-breathing speed of an FPGA to do the time_on and time_off > calculation to get decent resolution (without ripple below some given > frequency).Well I don't think an FPGA is going to get you any better. The microstep technology gives you the equivalent of a 1/60ps clock!> but i can't understand why a cheap little 10 MHz PIC or something > can't handle the job.How are you going to get a T_{SYSCLOCK} of this short with a bit-banging loop on a 10 MHz processor?!? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●September 24, 20152015-09-24
Randy Yates <yates@digitalsignallabs.com> writes:> Randy Yates <yates@digitalsignallabs.com> writes: > >> robert bristow-johnson <rbj@audioimagination.com> writes: >> >>> On 9/23/15 5:40 PM, Tim Wescott wrote: >>>> On Wed, 23 Sep 2015 14:28:52 -0700, gyansorova wrote: >>>> >>>>> On Tuesday, September 22, 2015 at 6:51:30 AM UTC+12, 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? >>>>>> >>>>>> -- >>>>>> Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email >>>>>> address domain is currently out of order. See above to fix. >>>>> >>>>> I think you need FPGAs. You will always have nano seconds latency since >>>>> your code executes serially. >>>> >>>> Rob mentions elsewhere that he's looking at a 1MHz sampling rate >>> >>> can someone explain why or what the device is that draws power from >>> some DSP-controlled power source (say PWM or PDM, which seems to me to >>> be about the same as sigma-delta) that needs a sample rate of 1MHz? >>> >>>> and a 20us ramp from zero to full-on. >>> >>> >>> i fail to see why that ramp needs to be sampled 20 times from zero to rails. >>> >>> i admit that i am outa my element, but i'm having trouble visualizing >>> this. what power controller needs such a spec? what's it powering? >>> >>> is it step response envelope delay? >> >> Hey Robert, >> >> Blind leading the blind but here goes... >> >> It's a feedback control system. If the desired step response is 20 >> microseconds, you need to be sampling the output a good bit faster and >> running that through your feedback loop. There's also the issue of >> latency - you always want to minimize latency in order to improve >> stability - and increasing the sample rate, even if you don't need the >> bandwidth, is a way to reduce latency in a sampled control system. >> >> If you're like me, the barrage of terms is also confusing. To help with >> that, you can look at the reference guide I was referring to in another >> post, the TI SPRUG77B on their "high-resolution pulse width modulator" >> in the Delfino series (TMS320x2834x). Figure 1 there shows a nice, basic >> picture of the PWM signal and it's parameters. >> >> T_{PWM} there is what has been called here in various posts as the >> "sample rate" and "switching frequency." The T_{SYSCLK} is the parameter >> Rob was referring to when he mentioned 150ps. >> >> Rob, Tim, Rick, whoever, correct me if I got something wrong here. > > ...continued... > > http://www.ti.com.cn/general/cn/docs/lit/getliterature.tsp?baseLiteratureNumber=sprug77&fileType=pdf > > You can see from the "PWM resolution (bits)" there that the number of > bits increases as T_{SYSCLK} decreases (higher frequency) and T_{PWM} > increases (lower frequency). > > Thus you have the classic engineering tradeoff: given a fixed T_{SYSCLK} > you want to increase T_{PWM} to improve the number of bits, but you want > to decrease T_{PWM} to increase the sample rate. Or viewed another > way, you have to have a low T_{SYSCLK} if you simultaneously want > a high sample rate and more bits.Q: Does the sample rate of the ADC (providing the feedback for the closed loop) have to be the same as the switching frequency (T_{PWM})? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●September 24, 20152015-09-24
> > > > Thus you have the classic engineering tradeoff: given a fixed T_{SYSCLK} > > you want to increase T_{PWM} to improve the number of bits, but you want > > to decrease T_{PWM} to increase the sample rate. Or viewed another > > way, you have to have a low T_{SYSCLK} if you simultaneously want > > a high sample rate and more bits. >Why would you even want to use a true digital feedback loop? Why not a tight analog feedback loop and you can hang ADCs and DACs on it to monitor and control it if you wish. Use a DAC to set the setpoint and an ADC to monitor the output. Trim the setpoint from time to time as needed. Even change the loop gain and BW if you wanted to go nuts. Mark
Reply by ●September 24, 20152015-09-24
On Thu, 24 Sep 2015 06:14:30 -0700, makolber wrote:>> > Thus you have the classic engineering tradeoff: given a fixed >> > T_{SYSCLK} >> > you want to increase T_{PWM} to improve the number of bits, but you >> > want to decrease T_{PWM} to increase the sample rate. Or viewed >> > another way, you have to have a low T_{SYSCLK} if you simultaneously >> > want a high sample rate and more bits. >> > Why would you even want to use a true digital feedback loop? > > Why not a tight analog feedback loop and you can hang ADCs and DACs on > it to monitor and control it if you wish. Use a DAC to set the setpoint > and an ADC to monitor the output. Trim the setpoint from time to time > as needed. Even change the loop gain and BW if you wanted to go nuts. > > MarkBecause given the power and ripple requirements, the idea had been to run 6 or 8 phases on the switcher and take advantage of some cancellation. But given the fact that I need to be able to switch it on and off with low latency, some feedforward is called for in addition to all the feedback loops. You're at a lot of parts there with an analog loop, and if you're going to run that all polyphase you need to be concerned with how well each individual phases's loop matches. Do it all digitally and at least each phase can have an identical transient response. Also a digital loop allows the handling of the big transients non- linearly. Slam all the FETs on at 100% duty cycle and you become slew rate limited; dI/dt = V/L. With an analog loop that's going to want to wind up the integrator. Can you fix that too? Sure. Yet more parts. Whereas with a digital loop, knowing the voltage and inductor values, you can run it open loop until say 80% of the slew is covered and precharge the integrator to whatever will give you a nice settling time. Probably not going to do it that way; in fact the entire project has changed topologies pretty radically since we started kicking it around. But the digital loop is only a semi-crazy idea given that the Piccolos are pretty much designed to do exactly that. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
