Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Maximum FPGA PWM Resolution

Status
Not open for further replies.

asdf44

Advanced Member level 4
Joined
Feb 15, 2014
Messages
1,000
Helped
355
Reputation
710
Reaction score
344
Trophy points
1,363
Activity points
9,716
Implementing a ~200Khz full bridge with FPGA control I'd like to maximize my output PWM resolution as much as possible. I have 16-bits in the feedback so while I won't be able to achieve that much output resolution I'll benefit from any additional output resolution I can get.


My initial plan is to have an architecture like this:
Error Amp -> PWM/State Machine -> Final PWM output engine

The point is that the middle stage, the PWM/State Machine running at ~32-128MHz will generate the overall output PWM while also perhaps adding some additional logic like variable dead time, fault handling etc. The middle stage really runs the show and the final stage, the point of this thread, will only be adding some additional bits of resolution on top of that.


This is my first idea where the middle stage PWM output routes through a high speed shift register. An additional 'delay' output from the middle stage determines how much extra delay gets added to the output before it reaches the pin.

The output engine here consists only of a shift register and an asynchronous mux which should be able to run near the limits of the fabric. The mux control lines will only change when the shift pipline is filled with all 0's or all 1's hence glitching here shouldn't cause a problem (helped by the extra flip-flop added at the beginning). A final flip-flop may also be added before the pin to minimize variations in routing delay (though with a small timing cost I assume).



So any thoughts or other suggestions on this implementation or suggestions for alternatives?
-What about adding a second layer of muxed flip-flops that are clocked at different phases (I.E. 0/180 or 0/90/180/270), for an extra 1 or 2 bits?
-Any other ideas I didn't think of, using serdes popped into my head though I don't actually have serdes on this part
-A counter implementation would work as well, and scale better, but I feel its extra complexity might minimize speed potential
 

Hi,

200kHz
16 bits resolution: =1:65536

means 200k x 65536 = 13GHz...very unlikely.

***
let´s say 100 MHz
100MHz / 200kHz = 500
500 is about 512 = 2^9 => 9 bits resolution.

Klaus

added:
For sure you may do some error spreading: a well filtered output with a sequency of the folowing PWM rates:
200, 200, 201, 200, 200, 200, 201, 200...

will average in 200.25 ... gaining two bits of resoution.
 

Understood I won't get to 16-bits but the more the better. Due to timing I think this will land between 200MHz and 500MHz (~10-11 bits) depending on how well I can optimize..which is what I want to address with this thread.

Spreading error as you suggest is another idea (and could be another layer), but regardless I only benefit from more 'native' resolution. And the oscillation you describe will, to an extent, already be the natural result of the higher feedback resolution.

Though as an aside I'm not sure whether a predictable pattern as you suggest or psudo-random dithering would be better for 'error spreading'. Given that I primarily have an AC output with a constantly changing output I feel dithering might be more suitable since it won't be sitting on a single count for any period of time.
 

Hi,

with a XILINX Spartan 6 we managed a 480MHz PWM clock frequency.
12 bit PWM.
A critical design. Next time I´d use a bit lower clock frequency.

Klaus
 
  • Like
Reactions: asdf44

    asdf44

    Points: 2
    Helpful Answer Positive Rating
And..how'd you do it?
 

Hi,

What do you mean?
480MHz counter, compare..

Klaus
 

Ok. And no hand layout or anything? I ask because as I said, I presumed that a counter implementation would have a slight timing penalty compared to the shift register implementation I showed which I chose because it has literally zero logic between flip flops and no start, reset or synchronization logic either.

Your example indicates that those things probably don't matter much since 480 is quite fast for a Spartan 6.
 

DDR outputs may be on the device if you don't have any SERDES. I would generally prefer a PISO-type approach. Parallel in - serial out. In the 50MHz domain, you can have a lookup table or other logic that determine the next 8+ fast-clock-cycle outputs. Using DDR outputs where available. This would get you up to the IO resolution and would have very well defined, easily met timings.

for example, if you have a ~100MHz clock with 512 cycles per output cycle, you could add the additional 7 bits of the accumulator here. If the upper 9 bits of the remaining high-time count is (or will be) non-zero then the output is all 1's. if the upper bits of the remaining high time is zero then a lookup table is used, or multiple compares. This generates perhaps 8 output bits which can be given to a 400MHz output clock which uses DDR outputs at 2 bits per 400MHz cycle. If you literally don't have DDR of any type, you would do 4 output bits. This design is easy to meet timing with because everything can be computed several cycles in advance -- bound only by the lowest supported pulse width.

You can also do similar things for non-power of two cases if you really want. It just takes more time to think about.

You can also do similar things with just the fast clock domain. Comparisons, addition/subtraction, and even accumulation can be pipelined due to the results of lsbs not depending on results of msbs.


--edit, actually, the high rate clock pipeline-accumulate, pipeline-compare is probably the least complex and most reliable version of the circuit. Higher power consumption but that should be negligable for such a small circuit.
 
Last edited:
  • Like
Reactions: asdf44

    asdf44

    Points: 2
    Helpful Answer Positive Rating
In my experience with analog PWM / DC-DC products
all of that resolution (anything beyond maybe 8 bits)
would be wasted once you expose the part to the
switching noise that the powertrain will lay on you.
Your current mode control jitter (if this is the end
game, digital power control) will make 12, 16 bits
irrelevant I expect due to the ringing and noise
getting into the feedback paths. Might want to
spend some thought on how the system will deal
with the garbage, and what's "good enough".
 
  • Like
Reactions: asdf44

    asdf44

    Points: 2
    Helpful Answer Positive Rating
Hi,
Ok. And no hand layout or anything?
Afaik without ...
As said: it is a critical design...often caused problems with timing..
Maybe we could improve the situation with manual layout.

In my experience with analog PWM / DC-DC products
all of that resolution (anything beyond maybe 8 bits)
would be wasted once you expose the part to the
This is not my experience.
We generate analog-style output signals, and even we have low voltage output signals and used a zoomed in scope view we see cleen signals. But we did no distortion measurement.

Additionally I assume class D audio amplifiers need way more than 8 bits PWM resolution to achieve low distortion low level signals.
Listening to quiet music could easily 40dB below max amplifier output signal level.

Klaus
 
  • Like
Reactions: asdf44

    asdf44

    Points: 2
    Helpful Answer Positive Rating
In my experience with analog PWM / DC-DC products all of that resolution (anything beyond maybe 8 bits) would be wasted once you expose the part to the switching noise that the powertrain will lay on you.
It really depends on the control topology. A number of application demands exact forward voltage control, they will suffer from insufficient PWM resolution particularly in static operation points.

There's a reason why some ARM chips provide high resolution PWM timers with 200 ps resolution. Depending on the number of PWM channels to implement, you can achieve sub-ns resolution by using PLLs and PLL phase shift features.
 

It really depends on the control topology. A number of application demands exact forward voltage control, they will suffer from insufficient PWM resolution particularly in static operation points.

There's a reason why some ARM chips provide high resolution PWM timers with 200 ps resolution. Depending on the number of PWM channels to implement, you can achieve sub-ns resolution by using PLLs and PLL phase shift features.

Well the phase shifted clock implentation I was picturing was to add multiple output flip-flops that are clocked at, say, 0/90/180/270 phase shift with a final mux to select which flip-flop drives the actual pin. It seems this scales well because the phase shifted clocks can be routed to many flip-flops (with some skew concerns of course). I will have 12 or 16 PWM outputs. Is that what you meant?
 

Yes, that's the best option for making many PWM outputs. If you need only few outputs, you can also use dynamic phase shift with FPGA families that support this feature.
 
  • Like
Reactions: asdf44

    asdf44

    Points: 2
    Helpful Answer Positive Rating
Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top