What's Stopping You Building Your Next Project with an FPGA? (Please, Don't Blame the Cost!)

I don't think price should be an issue; I think that the motivation to start using FPGAs comes from the desire to build a project that cannot perform on microcontrollers and need fast data processing.  Maybe a design challenge on let's say high speed video processing or similar would motivate people to try FPGA implementations.

Cosmin

ntewinkel

Sorry I missed the response.

Looks like I'll still need two more 7805's for the 2 inputs, right?

No I think you only need the single one to power it.

do you have a much more clever way of doing that?

I would diode OR the lights (with the capacitor) to provide the power for the Digispark, or a small battery.

You can use a transistor or opto to provide the input detection that drives the input on the digispark.

Since they are LED's on the trailer you could use a PNP transistor.

Mark

Ah! I didn't think of using transistors for inputs. So then it's the 12v switching the 5v instead of the other way around when powering LEDs or such. That makes much more sense.

And I guess the 7808 in between is just to take the bullet in case of a voltage spike on the dirty-automotive-power ?

Oh and the small battery - also a way to clean up the power? Or to keep the power on?

I was thinking of using a capacitor (maybe of the super variety), to keep power on for an intermediate amount of time - that way if there's any startup lag, subsequent use will be quicker.

Not sure if that would make any real-life difference though, now that I think of it - it's the reaction time on the first lighting of brake lights that counts!

But maybe if a battery or cap keeps it powered long enough for the down-time for city traffic, that might be useful.

That's another interesting project in itself - can we store enough power during the start of a journey, to last for the next 5 or 10 minutes? The start of a journey usually involves holding the brakes while starting and putting the car in gear, and then a fair bit of brake use while leaving the driveway.

But first things first, though not necessarily in that order

Thanks,

-Nico

ps, mcb1

ntewinkel

I guess the 7808 in between is just to take the bullet in case of a voltage spike on the dirty-automotive-power ?

The specs for the Digispark regulator say 35v, but yes it was "just in case".

Battery or Capacitor would work.

You have LED's so they are almost instant, and the startup lag is very little. (worth an experiment)

You're likely to be be braking earlier than normal which gives more time for anyone following, and the indicator only cycle is going to be a little shorter.

All bets are off in a full emergency so even 250mS is not really going to be the final deciding factor IMO.

Mark

>All bets are off in a full emergency

Right. In that case we buy a new trailer

A bit late to the party but I'd have to say that I've not had many projects actually need the capabilities of an FPGA. Even when they do, having to think differently and either do schematic capture or VHDL/Verilog programming takes a bit of practice after being of the "procedural" mindset for microcontrollers and the likes.

But I think the biggest annoyance from when I was tinkering with FPGAs was the toolchain. Xilinx ISE Webpack was a mighty large download that consumed close to half of my boot SSD, ran slowly, took a decent amount of time to synthesize and build a bitstream and wasn't very beginner friendly when it came down to the subtleties of FPGA designs. For example, warnings about maximum clock rates on a net, or clock-skew warnings, errors about clock sources coming in from less than desirable pins (due to the design of the prototyping board) which, while useful, don't exactly give us that much insight into how one might work around the limitations of a particular FPGA product. It was great that it was free, but I just wished it could be a little more friendly, lean and optimized. Some of the nice features like a graphic simulation (if I recall correctly) have been removed in later versions which was a shame. The limitations of Webpack were not the best either - as some Digilent prototype boards can accommodate designs which are on the borderline of what is allowed (e.g. if trying to integrate a soft-core from free HDL sources) - and WebTalk being not-disableable in later versions means Xilinx basically gets metadata about every generated design (which I don't like).

- Gough

What's stopping my design? The cost.

Sure, Dev boards are getting to real good prices [I have an Arty-S7 sitting on my desk] - that's not all the cost.  There's also time costs, space costs - and prototype costs.

My latest ideas tend to involve RF in some form (from satellite weather decoding to general SDR) and getting high frequency signals digitized is NOT a trivial task. Some of the PMOD connectors on the S7 are "high speed" - but how high is high?

I have to design / make / order custom PCB's for high speed ADC's then populate them, plug them in, and THEN I get to determine if my design is flawed, or the Dev board just can't handle the speed I'm clocking in data.

The S7 claims internal clocking over 450MHz. Can the Dev board handle a 400MHz ADC / DAC?  300MHz? 200?  150? 120?

Can I really afford to keep making PCB's to test a design, even assuming I can get the actual chips as free (or cheap) samples? That's... daunting.

Not sure what the answer is. Higher speed connectors, with specified speed ratings, would sure help. As to the format- coax? optic fibre? JESD204? The only thing I know for sure is the "Arduino" connector isn't enough when you want serious speed - and serious speed is the principle reason for changing from a microcontroller design in the first place.

I think you are more blocked by the cost of deployment of a high speed ADC than of the FPGA.

You don't say how fast you want the ADC to sample so I can't make very specific comments but I think that you'll have all the same problems and worse trying to interface a fast (250MHz+) ADC to a micro, or to anything.

The next step up of dev boards (from the Arty level) will have some high speed connectors, for example you can buy a Lattice ECP5 VERSA dev board for £250 and it has one full duplex 3.2GHz serdes channel on SMA connectors which would get you 8 bits at 400MHz, or 12 at 250MHz.

You'll need to make a board for the ADC.

MK

Yes, I'm blocked by the price of deploying a high speed ADC / DAC.

I'm also blocked, in this instance, by just "not knowing" how fast I can push data through the S7.   If I knew the limit of the interface, I could select a device accordingly.

As it stands, I'll have to use the 2 "high speed" PMOD connectors, along with a TI ADS4125 (12-bit, 125Msps, DDR LVDS output) and just hope for the best.

The whole point of an FPGA, for me, is to work with DSP.

Reducing a data stream to the point where it can be handled by a microcontroller (microBlaze, ARM cortex-M) or CPU (via USB 2 high speed connection).

I had a quick look and I think you may get away with the interface to the ADS4125 via two high speed PMOD connectors. You have 8 LVDS pairs on the Arty and you will need 7 of them to connect to the ADC. It will be much simpler to design the interface if you use single ended non LVDS mode although you are pushing it a little speedwise - 125 MHz is a little fast for the rather basic connectors used for PMODs but it might well work. It may well be possible to design your ADC board to work in either mode.

I'll be very interested to hear how you get on.

MK