FPGA Design...

[JR.]

OK, now I follow. A friend of mine did something like that back in the '80s. I looked into it for a specific application (a tracking filter for a old BBD delay line) where the filter cut off would vary with the clock frequency and delay time, so it could be optimized for all delay times. I never pursued this and I don't recall the ultimate gotchas. We used simple CMOS transfer gates (CD4016/4066) as the switching element back then.

OK, I am more familiar with PIC micro's and they sell standard parts with up to 8x 16b PWM modules so this seems like a possible path.

Now to get 16b resolution at a super audible rate you need a >1GHz clock which isn't going to happen in cheap micro, but you can probably get 10b or so range.

JR

[Crusty]

I guess you would still call it PWM, but really all I need is a presettable pulse width output; no capture/compare capabilities, where I would think most of the processing overhead would be. That's why I was thinking array logic as opposed to a micro.

[JR.]

Unless I don't follow, it is exactly a PWM. The R is increased by the ratio of off time and on time.

If you wish to vary the R, you can hold the period of the PWM constant and vary the up/down threshold, or hold the up or down constant and vary the period. If trying to get 8 PWM out of a single micro, they will use a common period, since every time-base requires a dedicated 16b counter and comparator.

JR

[Andy Peters]

I guess you would still call it PWM, but really all I need is a presettable pulse width output; no capture/compare capabilities, where I would think most of the processing overhead would be. That's why I was thinking array logic as opposed to a micro.

In an FPGA, the simple way of doing this is to have a counter, clocked at some highish frequency, and two registers: one is the period, and the other is the on-time pulse width. The counter rolls over at the first, and a comparator tests the counter against the second and gives the PWM output directly. The clock frequency of course sets the granularity of the whole thing. The higher the clock frequency, the wider your counter needs to be to get low-frequency output. This could rapidly eat up flops in a CPLD.

If you hard-code (perhaps using a VHDL generic) the period register, which sets the width of the counter, then you can save some logic.

You still need some way of loading the pulse width register, and I suspect that's where you'll spend most of your design time. Front panel control?

If your design is such that all of your PWMs use the same period, then you can use the same counter for all. You just need one pulse width register and one comparator per PWM output. A few PWMs should fit into a reasonable CPLD, but you might end up running out of flip-flops, so a small FPGA could be a better option. And the smallest FPGA will have more flip-flops than you can use!

-a

[Crusty]

Yep, it's PWM. I was trying to say that it's a simple application of it - no analog input or feedback to contend with, such as class 'D' or SMPS sort of apps. Just need steady pulse trains ...

Another question for you - since I'm using it in a high-Z circuit (passive filter), is charge injection going to be a major problem? Maybe even make this a dead end ?

Andy, thanks for the perspective with the parts. No shame in using more than one CPLD if I have to. I'm sure to contact you if I get further along with this...

Thanks all,

Paul

[mediatechnology]

Another question for you - since I'm using it in a high-Z circuit (passive filter), is charge injection going to be a major problem? Maybe even make this a dead end ?

I think it would be an issue. That's why I suggested the H11M1 OptoFET which has 0 charge injection.

[Crusty]

True Wayne, but it's on/off time is 5u seconds. Or are you suggesting it as a variable resistor?

[mediatechnology]

Hmm... For some reason I recalled it to be faster than that.

[Crusty]

Since the charge injection is going to occur at a frequency equal to the timebase, wouldn't it be removed by the following low-pass filter stage anyway?

[mediatechnology]

Since the charge injection is going to occur at a frequency equal to the timebase, wouldn't it be removed by the following low-pass filter stage anyway?

It would seem to since it's far out-of-band. Would the charge injection also introduce in-band errors? It seems time to revisit an old SIliconix databook...