FPGA TC driver board / Projects / Forums

Forums

4hv.org :: Forums :: Projects

« Previous topic | Next topic »

FPGA TC driver board

1 2 3 4 next

Move Thread

LAN_403

Wolfram

Wed Jun 20 2012, 05:19PM

Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971

Steve Ward's recent thread on his tesla gun started an interesting discussion on the idea of a universal FPGA-based DRSSTC driver board. Many people showed interest in participating, so I thought I'd start this thread to coordinate ideas around it. I've discussed the idea with Steve Conner in the past, so I have a few ideas, and some research gave me even more ideas. I'll try to sum up my thoughts around the project.

What it needs to have:

* A relatively powerful FPGA. The FPGA should have room for a reasonable amount of control logic, with lots of room for future ideas. The FPGA should also be widely available, not too expensive, and in a hobbyist-solderable package like TQFP. Developement tools should be available for cheap or free, and the same goes for programming hardware.

* Gate drive outputs. At least two individual GDT-driving outputs for phase shifted fullbridge operation or really big IGBTs. I think Steve Ward's UD-style complementary MOSFET fullbridge looks good.

* Inputs for feedback from the coil. Do we need phase lead hardware or do we do that in the FPGA? Do we need analog inputs?

* A fiberoptic input for control. This one is a bit trickier, simple bare-bones fiber TX/RX pairs like the HFBR-series are widely available, but somewhat expensive. SFP-style plugin modules for network switches can be had a lot cheaper, and since we have an FPGA on the board, interfacing with them is no problem at all. These also open up a lot of possibilities since they have a very high bandwidth. The inputs and outputs are LVDS-signals which should be directly compatible with the FPGA ports.

*Possibly a microcontroller to assist and possibly bootload the FPGA. Costs very little extra and opens up a lot of possibilities.

I looked at various different FPGAs, and I think the EP2C5T144 looks like a good candidate.

* Cheap and widely available, and it has a reasonable number of LUTs. It's in TQFP144, which means that it can be hand-soldered without too much trouble.

* "Core boards" based on this FPGA are widely available for around 25 dollars with free shipping on eBay. This should make initial prototyping easier.

* There is a free edition of the design software (Quartus II Web Edition). The official programming hardware is quite expensive, but copies are also dirt cheap on eBay, check out this one for example

for less than 10 dollars including shipping.

Do you think it's practical to do the design on a two-layer board? It would greatly reduce prototyping costs. The signals aren't awfully fast here so maybe we could get away with a two-layer one.

Does this sound reasonable?

Marko

Wed Jun 20 2012, 06:36PM

Registered Member #89 Joined: Thu Feb 09 2006, 02:40PM
Location: Zadar, Croatia
Posts: 3145

Hello,

I've already started the development of my own version of FPGA tesla coil and general power electronics controller. I have still not decided though, whether to make it a collaborative project or keep it super secret for a while more. You have pretty much pointed out the basic idea of it though.

Still I think it's ludicrous to use analog comparators, inductor phase lead networks and PWM generators (like Steve Ward did) for signal processing with all the FPGA firepower over there. It surely deserves a few channels of high speed ADC, and perhaps a good amount of DRAM you can capture waveforms with and store songs you want to play over audiomodulation.

Of course, several output gate drive channels are also a must.

I personally don't like Steve Ward's P-N mosfet gate driver hack. When I tried it with another type of mosfets, they blew up within seconds due to shoot through. Steve told me lowering the drive voltage would help (he uses 9V instead of 12-15) which I didn't try yet, but I'm still somewhat vary of this technique. It might be heavily dependent on the mosfets.

The controller for the start would be an AVR microcontroller whith display, keyboard, simple UART connection to fpga and a general purpose RS232 port. + perhaps an SD card slot as well.

Of course, it'll all be on single and two layer homemade PCB's. :)

On the other hand, I haven't found fpga's nearly as easy to source as you say. While I have a xilinx development board, getting xilinx FPGA's in croatia costs an arm and a leg. I'd greatly appreciate any ideas and help with that!

Marko

Steve Conner

Wed Jun 20 2012, 08:58PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

I'm heavily biased towards the Xilinx Spartan parts because I've been building stuff with them at work and I have the programming dongle.

I think there should be an analog input using a fastish ADC like the AD9280. Then you can easily implement the Prediktor as an IIR filter, just a digital simulation of the actual circuit. That's much harder if you only know the zero crossings and not the whole waveform.

Anders and I were kicking around the idea of the SFP modules, but I came up with an alternative that might be cheaper and less demanding of layout. I think it would be quite easy to make a decoder for the SPDIF digital audio format on the FPGA. The format allows for two channels, so one could be used as an interrupter bitstream or audio or ramp modulation data, and the other channel could be split into sub-channels like DMX, so you could adjust say 255 parameters on the driver.

I like this idea because it's faster than RS232, and you could drive it off a laptop with a digital audio output.

Any fiber hardware could be used. I've seen some high end CD players send SPDIF over the HFBR glass fibre transceivers.

You could also make a remote controller using a PIC, AVR, etc. and one of the SPDIF transmitter ICs like the CS8402.

Ben Solon

Wed Jun 20 2012, 10:42PM

Registered Member #3900 Joined: Thu May 19 2011, 08:28PM
Location:
Posts: 600

i'm interested. i know nothing about fpga though so could comeone point out exactly what i might need just to get started with fiddling with a xilinx spartan? what exactly do i need for this:

? and could this fpga even work for this application?

and i think it could be manageable using small traces and lots of vias...

joshua_

Thu Jun 21 2012, 02:19AM

Registered Member #61 Joined: Thu Feb 09 2006, 05:50AM
Location: Mountain View, CA
Posts: 43

Another vote for the Xilinx hardware. Even the older Spartan-3Es should be good enough for this application ... and if you go for a Spartan-3AN, then you get non-volatile goodness, so you don't have to worry about signals briefly going insane while you're programming the part.

I use and love the boards made by these guys for my personal FPGA work; they're inexpensive (especially the Nexys-2), and generally pretty well documented -- great for prototyping logic. The only two things to watch out for are 1) the host USB interface requires a closed-source blob, or some reverse engineering -- I've done the latter enough to load a bitstream on a Nexys-2, but if you want data over the parallel-port-like functionality, you still have to use their blob; and 2) some of the bigger boards are not supported by Xilinx's free "Webpack" programming tools. The XUPV5, in particular, requires a pricey version of Xilinx's tools; I believe that the Nexyses and the Atlys are all webpack-supported, though.

Using TOSLINK-like transmitters is a lot more possible with an FPGA, too. If you're talking between two FPGAs (or an FPGA and a CPLD on the other end), then you can encode things such that you are no longer being hit by the minimum frequency requirement, and hence you can use cheaper commodity TOSLINK stuff.

Given even a modestly sized FPGA, there should be no need for a uC on the board. A Spartan-3E with 500kgates has more than enough horsepower to stick a uC on it; to program the FPGA, just drop a SPI flash on the board. (For bonus points, route the SPI flash pins to the uC internal to the FPGA, which would mean that you could reprogram it without the need for an external programmer.)

Steve Conner

Thu Jun 21 2012, 06:45AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Yep, Marko and I both have those Digilent boards. I think if we used Xilinx, we would have to stick with Webpack.

Can you have a uC core in Webpack, or is that a paid feature? I know technically you can make your own out of HDL. I mean a ready-made one like the Picoblaze with an assembler and linker.

The way I see it, everything on the FPGA side could be done by state machines, and the uC belongs in the remote controller. That's why I like SPDIF for the line code, it is fast and real-time enough that the modulation can be sent over in raw format with a minimum of extra processing needed at the FPGA. It also gets rid of the minimum frequency issue as Joshua points out, since it is the line code that Toslink receivers are designed for.

Wolfram

Thu Jun 21 2012, 07:08AM

Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971

Marko wrote ...

I personally don't like Steve Ward's P-N mosfet gate driver hack. When I tried it with another type of mosfets, they blew up within seconds due to shoot through. Steve told me lowering the drive voltage would help (he uses 9V instead of 12-15) which I didn't try yet, but I'm still somewhat vary of this technique. It might be heavily dependent on the mosfets.

The controller for the start would be an AVR microcontroller whith display, keyboard, simple UART connection to fpga and a general purpose RS232 port. + perhaps an SD card slot as well.

Of course, it'll all be on single and two layer homemade PCB's. :)

I've only tried FDD8424s in the PN driver and I've had no trouble at all with it. Do you have any good suggestions on alternate drivers? UCCs are fine but a bit weak if the board is used to drive bricks. Maybe a fullbridge of n-channel FETs with high-side gate drivers could be used, it would add a lot of parts though.

Having boards professionally made is exceptionally cheap these days. 10 10x10cm double-sided boards with 6mil clearance and silkscreen on both sides costs less than 30 dollars including shipping.

On the other hand, I haven't found fpga's nearly as easy to source as you say. While I have a xilinx development board, getting xilinx FPGA's in croatia costs an arm and a leg. I'd greatly appreciate any ideas and help with that!

Digikey seem to have a good selection of FPGAs, and I think they do free shipping for orders over a certain size. Some FPGAs can be had cheaper on eBay, like the EP2C5T144 that I mentioned earlier, which can be had for 10 dollars with free shipping.

I like the idea of the AD9280, it seems to be pretty fast and cheap. Do we need more than one fast AD channel?

Making it TOSLINK compatible sounds like a good idea, I like the idea of it being possible to drive it directly from a common audio interface, that's one less thing to worry about. I can't say I like the TOSLINK hardware though, so I suggest we transmit it over multimode glass fiber.

The CS8402 seems to be hard to get, do you know of any alternatives?

I checked out some Xilinx parts, the XC6SLX4-2TQG144C looks nice. It's cheaper than older Spartans with a similar number of LEs. Or maybe the XC6SLX9-2TQG144C which has more resources. Do you know if they are suported by ISE Webpack?

I've still not given up the idea of Altera FPGAs though, the programmer is a quarter of the price of the Xilinx one, there are already footprints for them in Eagle and I already have a devboard. I must admit that the discovery of the Spartan 6 series changed my mind somewhat though.

I also read up on the Spartan-3AN series, they look nice, but only the 50kgate one is available in *QFP, the other ones are only available in BGA.

I'm starting to like the idea of using a softcore instead of an external microcontroller, as long as it doesn't mean that we need a much more expensive FPGA. Do you know the typical resource usage of a minimal microblaze/picoblaze core?

Can you have a uC core in Webpack, or is that a paid feature?

Steve Conner

Thu Jun 21 2012, 10:21AM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

Interesting!

I suppose one feature of this project would be that the "brains" would all be HDL, so you could theoretically put it on a FPGA from any vendor. I guess that was why the Department of Defense invented VHDL in the first place. Of course using Xilinx's IP cores would sink that idea.

The FPGA I use for my work projects is the XC3S100E-TQG144, with the XCF04S config PROM. It's available from Farnell for Â£10. I made an Eagle footprint for it.

I found the AD9280 inside a Cambridge Audio DAB tuner, it seems to hit about the right price/performance spot for a TC driver. I believe only one channel is required, but a second one would be nice. (say for instance you want secondary base feedback and primary current limiting, or you want to see the H-bridge output voltage, though isolation would be a real pig)

There are several SPDIF transmitter chips from Crystal and AKM. Crystal released several versions, I think they started with the CS8402 and ended with the CS8406. Higher end MCUs like the dsPIC may have a SPDIF transmitter built-in nowadays.

Reception is easy if you don't need to recover an ultra-low-jitter clock. You can just use a standard UART building block in the FPGA. SPDIF has error checking, which would have to be implemented to allow it to fail safe.

I like the idea of a bidirectional fibre link. Maybe the primary current waveforms could be sent back to the screen on the remote controller as a tuning aid. I would just use SPDIF in both directions. (Keeping with the laptop theme, rather than code a graphical display on your remote, you could use a soundcard oscilloscope program to display the data stream from the digital audio input)

Wolfram

Thu Jun 21 2012, 04:12PM

Registered Member #33 Joined: Sat Feb 04 2006, 01:31PM
Location: Norway
Posts: 971

I've just made an eagle library for the XC6SLX4 in TQFP144. Unfortunately I discovered a bit too late that libraries made with Eagle 6 are incompatible with older versions. If anyone has to use Eagle 5, I can make the library for Eagle 5 too, but it would be a bit of work so I'd like to avoid it if I could.

As far as I can see, the XC6SLX9 should be pin compatible, so we have the choice of using either one of these without doing any board changes. The former is around 11 dollars and has a similar number of logic elements as the XC3S200 and the latter costs around 16 dollars and is somewhere between an XC3S400 and an XC3S500 in terms of logic elements. This is a much newer series so they probably have some advantages to the older Spartan 3s in addition to being cheaper. They also have some built-in multiply-accumulate blocks which means that filters can be implemented with less resource usage.
]6slx4_test.zip[/file]

Steve Conner

Thu Jun 21 2012, 04:51PM

Registered Member #30 Joined: Fri Feb 03 2006, 10:52AM
Location: Glasgow, Scotland
Posts: 6706

The multiply-accumulate blocks would certainly help with our application. If you can get a FPGA that has them, in a TQFP, supported by Webpack, I'd say go for it.

At work we have a huge amount of stuff done in Eagle 5 and will be sticking with it until we save up the license fee for PADS.

Any thoughts on a microcontroller for the other end? STM32, ATMega or the like? I'm hoping for control by a laptop with some simple software, but I think many people would want a traditional remote control box with a LCD or VFD screen.

1 2 3 4 next

Moderator(s): Chris Russell, Noelle, Alex, Tesladownunder, Dave Marshall, Dave Billington, Bjørn, Steve Conner, Wolfram, Kizmo, Mads Barnkob