who uses fpga's

[SilverSolder]

An FPGA P-machine would be an awesome thing! 

It would be smokin' fast!

UCSD Pascal was fast even on 6 MHz Z80s and an interpreter.  Imagine native P code at 100 MHz (or more).

I really like Wirth's book "Algorithms Plus Data Structures = Programs".  It is my favorite text on data structures and traversing.  I have implemented that P0 compiler from the last chapter several times.  I actually think I understand recursive descent compilers.

https://www.alibris.com/booksearch?mtype=B&keyword=niklaus+wirth

Our local community college has a Pascal course as one of the very first in the sequence of computer science.  I doubt that anybody is still using it but it remains my favorite language.  I haven't worked with Delphi but I know I would like it.  Today we can use Astrobe on ARMs and FPGAs.  Astrobe is a variant of Oberon which is an upgrade from Modula which is an upgrade from Pascal which is an upgrade from Algol.  Or something like that...

https://www.astrobe.com/

I would still like Algol.  In school I had to write a compiler for a tiny version of Algol using, of all things, Basic.  It was UGLY!  Had I thought through it, I would have written a very tiny version and then bootstrapped up to something workable.  Kind of like that P0 compiler.  It would be possible to use that to write the P4 compiler in some series of steps.

One of Delphi's claims to fame is that Object Pascal can be compiled in a single pass - you can compile almost as fast as the source code can be read off the drive!  It is truly amazing, almost like working with an interpreter...   

All of the different programming languages have stolen the best ideas from each other these days, pretty much.  So now it just boils down to what is supported and works well for you - rarely will you miss out on anything...

Native P-code would be crazy cool - imagine a P-code transputer, to parallelize the load...   something for a Sunday afternoon project? 

[rstofer]

All of the different programming languages have stolen the best ideas from each other these days, pretty much.  So now it just boils down to what is supported and works well for you - rarely will you miss out on anything...

Let's skip over Python's white space indentation rules.  I'm not found of the : operator either.  But, yes, it is a lot easier to write loops and conditionals with modern languages.  I never really like the 3 way IF branch of early incantations of FORTRAN.  For mathematics, it worked well.  For business programming it was a bit awkward.  And the lack of an ELSE target.  Well, we didn't have logical expressions anyway.

But only in the Algol .. Pascal .. Oberon branch do we have nested procedures and functions.  The first thing I missed when I changed to C was block structured code.  When parsing an expression, recursive descent and block structuring is a natural approach.  PL/I is also block structured.

Native P-code would be crazy cool - imagine a P-code transputer, to parallelize the load...   something for a Sunday afternoon project? 

I'm afraid I'm not that prolific...

[Capernicus]

Has anyone ever heard of Instruction Level Parallelism?

It actually is a serial code -> parallel code converter,  because it can run serial code in parallel, given a latency of the string length of the sequence.  You have to wait for it to get to the other side,  but when it comes out it can keep pumping outputs out every cycle, like a manufacturing assembly line

If u got the system to not skip a beat,    it means that one core actually counts as, as many cores as their is instructions in the series.
How about that for a space saver, but the issue is powering it,  every instruction has to run at the same time so it chews up watts like no other technique if it was ideal.

[james_s]

I'm just a GPU nut, I've doing it with direct compute ever since I was 21 doing direct x 6 win32 tutorials watching Martin Short on tv back in the olden days possibly 10 years after inner-space came out.  I loved that movie, it was absolute magic and the robot suit's were fricken amazing! and as I think back terrify the absolute shit out of me now if it ever became a reality. curse the singularity.

So the biggest mystery to me now is, now I'm old,40 sick still feel and look like an immature teenager and just about carked it in the head, what the hell are FPGA's and who uses them -and what do they use them for?

They seem to be a step up from GPU's in what I imagine about them, but thats only a fantasy because I never got the guts to work on them.
One thing that put me off was the cheap ones seem to only go to a megahert for some reason and that ruins the performance interest somewhat of what I thought they could do for me, so I put them off and just kept going with GPUs because they apparently hert quicker. and whats the difference between any type of physical parallelization, isnt it all equally as good as itself? 

But has anyone here got some real experience with them - is there any forums to go to get tips off guys that have been doing it for ages?

The only implementations I've scarcely heard about is people use them to emulate old computers perfectly,  but that is to me so uncreative and not even capitalizing on the power to do some original logic with them, at a modern performance,    as long as it fit on the FPGA, isnt it as good as an ASIC - its just with a little wasted space here and there - that seems more like what I'd like to do with it.

GPU's are what I know, and they are good for AI because you can do lots of brute forcing with them,  when it comes to FPGA's is the brute forcing ability higher than a GPU?

FPGAs and GPUs are two entirely different things, you're comparing apples to oranges. GPUs are high performance microprocessors optimized to perform specific types of tasks. FPGAs are a huge breadboard with an unlimited pile of logic chips that you can wire up any way you see fit.

I use FPGAs for recreating vintage computers, arcade games and other stuff, that is not really what they're intended for but they can do a good job of it. In a former job we used an FPGA as a crossbar switch to route the digital video and audio signals between the tuners, recorder and TV in a digital video recorder. They're also used in a lot of small volume specialized equipment where it is not cost effective to produce custom silicon.

[rstofer]

The idea of pipelining is used all the time in CPU design and, by implication, FPGA design.  Latency is higher but throughput is much higher.

Most RISC designs use a classic 5 stage pipeline:
https://en.wikipedia.org/wiki/Classic_RISC_pipeline

Of course, there are interlock issues to work through and pipeline stalls to handle but it is certainly possible and, in fact, quite common.

This book details ARM pipelining although the included code is for a non-pipelined processor:

https://www.amazon.com/gp/product/0128000562

It's a pretty good book and includes SystemVerilog and VHDL code.

The authors also have a book about MIPS architecture:

https://www.amazon.com/gp/product/0123944244

This book includes Verilog and VHDL code.

[dmills]

Ironically a MAJOR user of FPGAs is broadcast video.

Sure you could do 4k60 video effects on a GPU, but you are talking whole frames of latency to get the data in and back out, going line by line with only sufficient buffering to deal with the skew due to speed of light in the video cables lets you pull in multiple 12Gb/s SDI flows, do the gamma and colour space conversions, handle switching and keying, maybe do some DVE stuff and get the pixels back on the wire, with delays measured in terms of lines not frames, all this while NEVER dropping a frame or having to slow down because something was busy).

Getting a GPU to handle 20 bit 4:2:2 cleanly is MUCH harder then it at first appears, especially if trying to work with much less then a frame at a time (Yea, broadcast video is 10 bits per channel, non linear).

The a cpu (or even a whole field of them) you are telling preconfigured hardware what to DO, with an FPGA you tell a sea of gates (There is a reason FPGA folk call it a fabric) what to BE.

Where FPGAs really excel is in very highly pipelined doings, basically dataflow stuff where the ability to cascade a whole mess of DSP and logic and have it ALL execute on every clock is really quite powerful.

Where FPGAs are a pain in the arse is when there is 'sequence in time' sort of stuff, you basically have to build explicit state machines (In fact this is so much of a pain in the arse that both major vendors have small CPU models that you can build into your designs to deal with the stateful control stuff that is a pain in HDL).

GPUs also generally suck at IO, how are you going to get 16 12Gb/s links into a GPU, when they all have slightly different timing offsets (Oh, and you need to get some AES3 in and out as well, and handle a couple of shaft encoders, and output PTP V2 synchronous ST2110 on the low latency profile? Raw compute power is not the hard bit, moving data is.

[rstofer]

At least the entry level DSOs use FPGAs to make things happen including timing the GS/s A2D converters.  I'm not sure about the very high dollar scopes.  Their price may justify ASICs.

[james_s]

At least the entry level DSOs use FPGAs to make things happen including timing the GS/s A2D converters.  I'm not sure about the very high dollar scopes.  Their price may justify ASICs.

I haven't been inside a high dollar DSO although maybe Dave has taken a peak. I think it has more to do with sales volume than cost though. At a former job we had a HDMI analyzer that cost close to $100k and it had a big FPGA in it. It was one of the most expensive pieces of test equipment I've ever used but it's the sort of thing that has a global market of maybe a few hundred to a few thousand units.

[rstofer]

At least the entry level DSOs use FPGAs to make things happen including timing the GS/s A2D converters.  I'm not sure about the very high dollar scopes.  Their price may justify ASICs.

I haven't been inside a high dollar DSO although maybe Dave has taken a peak. I think it has more to do with sales volume than cost though. At a former job we had a HDMI analyzer that cost close to $100k and it had a big FPGA in it. It was one of the most expensive pieces of test equipment I've ever used but it's the sort of thing that has a global market of maybe a few hundred to a few thousand units.

Which would make you think that the Rigol DS1054Z would be ASIC based due to volume and any of the Keysight scopes would be FPGA based.  I don't think it works out that way.

I think the reason that most scopes are FPGA based is the ability to update the firmware.  Nothing as complex as a modern DSO is likely to ship day one with no bugs.  There is also the ability to add features on request (assuming they are workable).

[dietert1]

An FPGA may be a good method to improve time to market. You just wire all components to the FPGA and implement major parts of board layout inside the FPGA. And a modern FPGA includes multiple ARM cores, so you don't waste your time with large VHDL descriptions of embedded processors. A modern FPGA has other prebuilt components like RAM blocks, serial interfaces, PLL, ... Once you learn how to describe your system in VHDL, that's something very useful and universal.

I'm afraid a JETSON nano is a wonderful number crunching machine that won't perform well when trying to implement logic. Would you implement an ethernet node using one if its processors? Or does it include an FPGA to do that? GPU and FPGA are completely different concepts.

Regards, Dieter

[fourfathom]

An FPGA may be a good method to improve time to market. You just wire all components to the FPGA and implement major parts of board layout inside the FPGA. And a modern FPGA includes multiple ARM cores, so you don't waste your time with large VHDL descriptions of embedded processors. A modern FPGA has other prebuilt components like RAM blocks, serial interfaces, PLL, ... Once you learn how to describe your system in VHDL, that's something very useful and universal.

In my previous companies we would often jump-start the process by developing boards (plug-ins for multi-board communications systems) using FPGAs, designed in Verilog.  This gave hardware / software / marketing something to work with while we were fine-tuning the design.  We would then follow up with a full ASIC design for cost / power reduction and performance enhancements.  Other boards would require ASICs at the start, as the FPGAs couldn't provide required the speed and/or density.

[Siwastaja]

Who uses knives? You know they invented scissors, right? So cutting paper with a knife is stupid and obsolete. This scissor brand I happen to know is just ultimate for cutting paper. And cutting paper is everything that counts because I don't know anything else than how important cutting paper is.

What uses can you come up with for a knife? Who uses knives??

[james_s]

Which would make you think that the Rigol DS1054Z would be ASIC based due to volume and any of the Keysight scopes would be FPGA based.  I don't think it works out that way.

I think the reason that most scopes are FPGA based is the ability to update the firmware.  Nothing as complex as a modern DSO is likely to ship day one with no bugs.  There is also the ability to add features on request (assuming they are workable).

High market volume doesn't preclude the use of an FPGA, but low market volume usually does preclude the use of a custom ASIC. There's no one reason to go with one over the other, rather it's a decision based on numerous different factors. Oscilloscopes as a whole are low market volume compared to say consumer electronics. I'm only speculating but I would guess there are probably more of one specific model of iPad sold in a year than all oscilloscopes from all makes all put together.

[jmelson]

Where FPGAs are a pain in the arse is when there is 'sequence in time' sort of stuff, you basically have to build explicit state machines (In fact this is so much of a pain in the arse that both major vendors have small CPU models that you can build into your designs to deal with the stateful control stuff that is a pain in HDL).

Well, actually, state machines are not that big of a deal.  You have a "process" with statements like :
if (state=some_number) then
  state <= 21;
  signal <= '1';
end if;

and so on for each state.  While a CPU can only do one state machine at a time, you can have dozens of them in an FPGA, and link them all together in a top-level file.

Jon

[james_s]

Yeah state machines are part of just about every basic HDL lesson I've encountered, no big deal at all. The CPU soft cores are available for more complex tasks where it makes sense to have a general purpose microprocessor along with your custom logic.

[Capernicus]

Not that I know what im talking about,  but if I were using an fpga I wouldnt be using some provided ram array, I may as well be on a CPU and it would slow you down, Id be using purely registers connected directly to the gates, if I needed a state id set up a circular access memory of registers and drill it directly into the logic, and see how fast my framerate is.

performance performance performance, thats what I always imaged FPGA's were about.  GPUs just let me down these days, gtx3080 may be 4 times faster than my card but for what ive got in front of me I need more than that,  and it just costs so much.

If I can carve the logic down, keep the model as simple as possible maybe I can get away with something cheaper and runs faster at the task at hand.

Even tho you can optimize software as well, for the same result,  but maybe doing the hardware directly gets you more performance for your transistor count.

[dmills]

Oh state machines are routine, (And a CPU is a state machine!), but there are definite limits to how complex a state machine written as such can be and remain tractable.

Throwing a microblaze or such in the fabric gains you two things:
You can program the stupid thing in C, debug it with a debugger and generally treat some of the work as software dev.
Also, changes to the software side do not usually require P&R to be rerun, particularly with a mostly full part that can save literally hours of compute time.
High performance those little cores are not, but a lot of control (as opposed to data flow) stuff just does not need a high performance computer. 

The on chip block rams are in fact a KEY feature of an FPGA, these are usually relatively small memories (a few tens of kb typically), BUT there are potentially hundreds of them! This makes for fantastic memory bandwidth, and they get used for everything from filter coefficients, to fifos, to look up tables, to yes, program and data storage. They are explicitly designed to be useful for crossing clock domains and similar purposes.

Same with the 'DSP' cores, which are really some combination of adder/multiplier/accumulator, good typically (with some pipelining) to a few hundred MHz, but again you got a hundred or so on the chip, and they can be wired directly into the block rams for data or coefficients. 

A common mistake is to thing of writing an FPGA configuration as software, you can sort of do that, but software generally has an implicit notion of sequence, VHDL does not, it describes wiring, look up tables, and registers, if you need sequential, you have to describe the circuit to make things happen one after another, it is not built in.
 
Say, rather, IO, IO, IO is what FPGAs are really about, you can get some very nice performance as well, for problems that fit the model well, basically masses of data flow stuff that pipelines nicely, but the selling feature is hundreds of fast IO pins and a handful of scary fast transceivers.

[Siwastaja]

FPGA is an electronic component, not a trendsetter. You know if you need one.

Capacitors are not about "performance". Neither are FPGAs.

And you can't replace a capacitor with a CPU even though CPU processes approximately infinite times more data per second than a capacitor.

I don't know why but for some strange reason the term "FPGA" sometimes seems to sneak into the discussion of so-called laymen who have no idea what it is, but somehow they have got the wrong impression like it's some kind of new contender against CPUs or GPUs or whatever. This makes absolutely zero sense. Then they Google it and are more and more confused, commenting something utterly bizarre such as "it's not FPGA's year yet".

Meanwhile, we designers use FPGAs whenever needed like we always did.

[rstofer]

Not that I know what im talking about,  but if I were using an fpga I wouldnt be using some provided ram array, I may as well be on a CPU and it would slow you down, Id be using purely registers connected directly to the gates, if I needed a state id set up a circular access memory of registers and drill it directly into the logic, and see how fast my framerate is.

The Artix 7 -100T variant has 1188Kb of distributed RAM - basically flip-flops in the logic cells.  If we're building a 16 bit processor, this is about 74Kwords and more than enough for a 32K machine.  But this RAM is usually used for more important things like code conversion. 

The card reader uses Hollerith, the CPU uses Hollerith, the printer uses printer code, the keyboard is different yet and, of course, the bouncing ball typewriter uses rotate-tilt code.  But I want everything in ASCII at the edges!  I really can't change the internal codes without rewriting the OS and that's not going to happen.

BlockRAM is organized around 36Kb words which is really 32K bits plus 4 bits if I decide to implement some kind of ECC.  On the 100T, there are 135 of these blocks.  For my mythical 16 bit x 32K CPU, I need 16 of these blocks.  There is plenty left for a 25x80 video display.

https://www.xilinx.com/support/documentation/selection-guides/7-series-product-selection-guide.pdf

The modern FPGA has a LOT of memory and it's VERY fast.  I have yet to figure out how fast but it runs single-cycle at 100 MHz without a hiccup.  Of course, if you register the output then you add a cycle (or you have to think in terms of a pipeline).

https://www.xilinx.com/support/documentation/user_guides/ug473_7Series_Memory_Resources.pdf

The fact that all of this RAM, distributed or Block, can be initialized at startup is a very power feature.  The 1130 always used some kind of cold start program on the first card through the reader.  In my design, the cold start code is copied into memory from another chunk of initialized RAM at startup.  There is no separate operation, it just happens by magic.  Boot the processor and the first thing the CPU sees is the cold start code.

The idea of using some of the BlockRAM for microcode doesn't seem like a popular design approach AFAICT but it should work perfectly.  Maybe the microcode is 64 or 128 bits wide and perhaps 256 words deep.  This fits easily.

The memory resources of even a modest FPGA are pretty staggering.

[camila]

I have used them in a project? What's the query?

[james_s]

Not that I know what im talking about

You could just stop right there. It's clear that you don't know what you're talking about, you're just babbling complete nonsense and you don't seem to be paying any attention to what people are saying who are explaining what FPGAs are and what they're used for. You're just embarrassing yourself.

[Raj]

Apparently Razer's shitty deathstalker ultimate keyboard (cause it has the worst software support) has an FPGA inside of it. It also has 2 microcontrollers. (overkill? absolutely)

You haven't seen fpga cause they are too damn expensive to be in a consumer device.

I've also seen a lot of people use FPGA in Imaging application, be it driving displays or be a camera interface.

[james_s]

I've seen FPGAs in consumer devices before, one in particular that I recall was a LCD TV from around 2005, I didn't delve into it deeply enough to determine precisely what it was used for but I suspect it was routing the HDMI signals from the various inputs. You can spend a fortune on high end FPGAs but there are lots of inexpensive ones too.

[Capernicus]

I have used them in a project? What's the query?

What Id like to do is take an oldschool game, like pong or turbo snake, and then run as many instances as I can fit in parallel,  does this make sense at all to FPGA design?

I need to do that for an Ai application.

The implementation I saw of an FPGA was doing picture matching with k nearest neighbour (basic artificial intellignce), but there wasnt enough details for me to tell or learn much, but it did look like it was going pretty fast.

[james_s]

You could certainly do it, although I'm not sure how it could be useful to have a bunch of Pong games running in the same IC. Pong didn't even use a microprocessor, it was all implemented using counters and logic, discrete TTL ICs. FPGAs are quite good at recreating early games like this since they can't be emulated in the traditional sense, there is no microprocessor and no code to emulate. You can write a program that creates a very similar game, but it will not be exactly the same as the original. There's quite a good writeup analyzing the original Atari Pong circuit http://www.pong-story.com/LAWN_TENNIS.pdf

But back to my point, say you put a bunch of Pong circuits in parallel, once you have one working it's easy to instantiate as many copies as will fit in your FPGA, but then you have a bunch of vaguely NTSC-like composite video signals, what do you do with those? Once microprocessors started to displace the hardwired logic games most used the 6502 and 6800 micros to run the game logic, but generally the video generation circuitry remained similar to the pre-microprocessor games. The code would just manipulate variables in RAM, for example the object code in an address corresponding to a particular tile location on the background, or the position of a motion object. Without the video circuitry you're left with a typically sub-1MHz 6502 computer with just a few kB of RAM.