On Mon, 21 Sep 2015 17:46:26 -0700, 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 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. > > boBIf they haven't changed in the ten years since I've looked at them, TI does it with tapped delay lines. -- www.wescottdesign.com
Digital Power Control
Started by ●September 21, 2015
Reply by ●September 22, 20152015-09-22
Reply by ●September 22, 20152015-09-22
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?>> 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? -- www.wescottdesign.com
Reply by ●September 22, 20152015-09-22
On Mon, 21 Sep 2015 18:50:04 -0400, rickman wrote:> On 9/21/2015 6:08 PM, robert bristow-johnson wrote: >> On 9/21/15 4:28 PM, rickman wrote: >>> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>>> Got an application coming up for a high-efficiency, multikilowatt >>>> polyphase power supply that needs scarily fast responses to external >>>> requests. I'm thinking about maybe throwing a C2000 at the problem. >>>> It could really simplify keeping my phases in alignment and getting >>>> the feedforward through all the paths to match. >>>> >>>> TI sure makes it look easy, almost as if it's their job to do so. >>>> Anyone got any stories to share from that war? >>> >>> How complex are your calculations? I can see using a processor if the >>> calculations are lengthy. But if the calcs are simple with a demand >>> for speed, I think FPGA. Even if the calcs are not so simple, *I* >>> would think FPGA most likely. Processors are great, but the inherently >>> sequential nature creates problems, mainly when you need to be doing >>> several things at one time and have to time share the processor. >>> >>> One of the things I like about FPGA work is that I can do nearly >>> perfect simulation. I hardly ever have any difficult problems to debug >>> in the hardware. I find software to be a bit harder to test well >>> before heading to the bench. >>> >>> So would an HDL/FPGA design suit the requirements? >>> >>> >> confession: i never ever designed an FPGA (but i once developed some >> note-processing algs that someone else put into the FPGA) and i have >> never been paid for anything regarding control of power. >> >> how "scarily fast" do you need to be? i wonder how a power-control app >> would need a faster sampling rate than audio and, if the calculation is >> complicated (with lotsa conditionals and math), i wonder how a DSP >> would not be adequate. and i doubt an arduino would suffice. >> >> it just seems to me that using a development system and a familiar >> programming language would be the easiest and most cost-effective way >> to do it. > > I have seen control apps where the calculation period was a significant > factor in the stability of the loop. Rather than talk in terms of > "arduino", "DSP" and "FPGA", I would want to see numbers. That is why I > asked how complex the calculations are. When someone's requirements > say, "scarily fast", I start thinking of getting rid of the inherent > limitations of sequential instruction execution. Numbers would be a lot > better though. "Easy" and "cost-effective" don't have much meaning > until numbers can be attached. > > Reminds me of some data book where they listed "Damn Fast" buffers. > > "Easy" is certainly in the eye of the beholder. I already mentioned how > I feel the debugging is easier with FPGAs. "Familiar" entirely depends > on the user.One of the nice features of the TI parts that Rob is talking about is that they have the ADC, processor core, and PWM drives all in one package. I'm not sure about this, but I'd be at least mildly surprised if there aren't versions that have some comparators built in, too. Particularly if there's comparators in there, you're comparing at least three packages (four, if you need an external memory for the program) for the FPGA solution vs. one for the processor. For all that, however, if you really want to iterate the control loop at 1MHz the processor isn't going to be doing much else. (It's too bad no one makes a motor control FPGA, with ADCs and comparators on one edge of the chip, and a honkin' big FPGA on the rest. I suppose the processes just don't mix well enough -- but if it can be done with a processor, why not an FPGA? Too much ground bounce?) -- www.wescottdesign.com
Reply by ●September 22, 20152015-09-22
Tim Wescott <tim@seemywebsite.com> writes:> [...] > For all that, however, if you really want to iterate the control loop at > 1MHz the processor isn't going to be doing much else.Some of the TI 2xxx devices have a CLA (control law accelerator) that is perfect for doing these sorts of computations. -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●September 22, 20152015-09-22
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?>>> 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. 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. -- Rick
Reply by ●September 22, 20152015-09-22
On 9/21/2015 11:27 PM, Tim Wescott wrote:> On Mon, 21 Sep 2015 18:50:04 -0400, rickman wrote: > >> On 9/21/2015 6:08 PM, robert bristow-johnson wrote: >>> On 9/21/15 4:28 PM, rickman wrote: >>>> On 9/21/2015 2:49 PM, Rob Gaddi wrote: >>>>> Got an application coming up for a high-efficiency, multikilowatt >>>>> polyphase power supply that needs scarily fast responses to external >>>>> requests. I'm thinking about maybe throwing a C2000 at the problem. >>>>> It could really simplify keeping my phases in alignment and getting >>>>> the feedforward through all the paths to match. >>>>> >>>>> TI sure makes it look easy, almost as if it's their job to do so. >>>>> Anyone got any stories to share from that war? >>>> >>>> How complex are your calculations? I can see using a processor if the >>>> calculations are lengthy. But if the calcs are simple with a demand >>>> for speed, I think FPGA. Even if the calcs are not so simple, *I* >>>> would think FPGA most likely. Processors are great, but the inherently >>>> sequential nature creates problems, mainly when you need to be doing >>>> several things at one time and have to time share the processor. >>>> >>>> One of the things I like about FPGA work is that I can do nearly >>>> perfect simulation. I hardly ever have any difficult problems to debug >>>> in the hardware. I find software to be a bit harder to test well >>>> before heading to the bench. >>>> >>>> So would an HDL/FPGA design suit the requirements? >>>> >>>> >>> confession: i never ever designed an FPGA (but i once developed some >>> note-processing algs that someone else put into the FPGA) and i have >>> never been paid for anything regarding control of power. >>> >>> how "scarily fast" do you need to be? i wonder how a power-control app >>> would need a faster sampling rate than audio and, if the calculation is >>> complicated (with lotsa conditionals and math), i wonder how a DSP >>> would not be adequate. and i doubt an arduino would suffice. >>> >>> it just seems to me that using a development system and a familiar >>> programming language would be the easiest and most cost-effective way >>> to do it. >> >> I have seen control apps where the calculation period was a significant >> factor in the stability of the loop. Rather than talk in terms of >> "arduino", "DSP" and "FPGA", I would want to see numbers. That is why I >> asked how complex the calculations are. When someone's requirements >> say, "scarily fast", I start thinking of getting rid of the inherent >> limitations of sequential instruction execution. Numbers would be a lot >> better though. "Easy" and "cost-effective" don't have much meaning >> until numbers can be attached. >> >> Reminds me of some data book where they listed "Damn Fast" buffers. >> >> "Easy" is certainly in the eye of the beholder. I already mentioned how >> I feel the debugging is easier with FPGAs. "Familiar" entirely depends >> on the user. > > One of the nice features of the TI parts that Rob is talking about is > that they have the ADC, processor core, and PWM drives all in one > package. I'm not sure about this, but I'd be at least mildly surprised > if there aren't versions that have some comparators built in, too. > > Particularly if there's comparators in there, you're comparing at least > three packages (four, if you need an external memory for the program) for > the FPGA solution vs. one for the processor. > > For all that, however, if you really want to iterate the control loop at > 1MHz the processor isn't going to be doing much else. > > (It's too bad no one makes a motor control FPGA, with ADCs and > comparators on one edge of the chip, and a honkin' big FPGA on the rest. > I suppose the processes just don't mix well enough -- but if it can be > done with a processor, why not an FPGA? Too much ground bounce?)I don't recall comparators, but Microsemi has FPGAs with everything else you need including an ARM processor. I forget the name of the FPGA company Microsemi bought. Cypress has a PSOC line with programmable analog and digital logic. I wouldn't call the Cypress stuff "FPGA", but you can configure counters and such. I think they can even be programmed in Verilog. Why would you need a "honkin' big" FPGA? These days "big" in FPGAs is not measured in K's of gates, but K's of LUTs, like 10's or 100's of kLUTs. Those are parts that you could implement a bank of ARM CM4s in. 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. -- Rick
Reply by ●September 22, 20152015-09-22
On 9/22/2015 7:33 AM, rickman wrote:> I don't recall comparators, but Microsemi has FPGAs with everything > else you need including an ARM processor. I forget the name of the > FPGA company Microsemi bought.Actel Bob.
Reply by ●September 22, 20152015-09-22
On 9/22/2015 11:36 AM, Rob Doyle wrote:> On 9/22/2015 7:33 AM, rickman wrote: >> I don't recall comparators, but Microsemi has FPGAs with everything >> else you need including an ARM processor. I forget the name of the >> FPGA company Microsemi bought. > > ActelTY -- Rick
Reply by ●September 22, 20152015-09-22
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. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
Reply by ●September 22, 20152015-09-22
On Mon, 21 Sep 2015 22:15:12 -0500, Tim Wescott wrote:> On Mon, 21 Sep 2015 22:55:19 -0400, rickman wrote: > >> On 9/21/2015 8:46 PM, boB wrote: >>> 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? >I don't know about the distribution circuit; but I know for the longest time Xilinx was putting delay-locked loops instead of true PLLs into their chips. It lead to some exciting bimodal jitter in the generated frequency under some circumstances. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
