Author Topic: EEVblog #496 - What Is An FPGA?  (Read 81609 times)

0 Members and 2 Guests are viewing this topic.

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #496 - What Is An FPGA?
« Reply #25 on: July 20, 2013, 12:57:35 pm »
Maybe next time you can cover the difference with CPLD (although maybe you should have started with it :) )

I did contemplate starting the video working from GAL's/PAL's to CPLD, to FPGA's, but figured it would ultimately take too much time. I was right, because I waffled on for 37min on just FPGA's  ;D
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #496 - What Is An FPGA?
« Reply #26 on: July 20, 2013, 01:02:15 pm »
I do want to suggest you try setting your exposure to +1 stop, or press the backlight button if your camera has one, when the whiteboard dominates the frame. The white board comes across looking a bit too grey and you look a bit dark too. One stop compensation isn't really enough but 1.5 or 2 stops might be more than people will tolerate if the whiteboard actually looks white

I just hit the manual exposure button on the board and then walk into frame. The white balance could be slightly off maybe (I leave it set the same for the rest of my lab shooting), but the colour of the whiteboard looks ok to me on my main monitor, but it does depend upon the monitor I use. The whiteboard is not in an ideally lit location.
 

Offline mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13694
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #496 - What Is An FPGA?
« Reply #27 on: July 20, 2013, 01:14:21 pm »
Maybe next time you can cover the difference with CPLD (although maybe you should have started with it :) )

I did contemplate starting the video working from GAL's/PAL's to CPLD, to FPGA's, but figured it would ultimately take too much time. I was right, because I waffled on for 37min on just FPGA's  ;D
Not sure there's much point in this - the history and architectural detail isn't that important as HDL hides most of it - GALs are pretty much obsolete, and CPLDs can for most purposes just be thought of as much smaller, cheaper variants of FPGAs, with onboard config & core voltage regulators. 
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline daqq

  • Super Contributor
  • ***
  • Posts: 2301
  • Country: sk
    • My site
Re: EEVblog #496 - What Is An FPGA?
« Reply #28 on: July 20, 2013, 01:52:24 pm »
Dave: Good video, thanks, the next time someone asks me the question, I'll refer them to your video.
"technical life gives birth to monsters" was one of the quates i remembered.

fpga is an example of this monstruosity. why embeding, why making it faster ? how long do you think integrating, embeding until you reach to the final usable limit of the cosmos / universe / this space - temporal dimension and give up in front of infinity  ?

assholes from IBM thought ohhh.. let's make an atomic memory, each atom holding one bit - and then hires somebody to "produce" or "edit" videos like this guy going around on how science and technology will make the human life better.

beeing all relative -  faster and slower, bigger and smaller, discrete or integrated only means control over others is beeing passed from one group of people to another for a short period of time while they are dreaming about their accoumplishments in the field.

dave playing the violin in a certain group: new modern independent high tech cutting edge online job ...with a highly stage managed and controlled smile to fit the motto: "entusiastic and passionate"

ogh.. o by the way: we can't care less about how video editing takes place. it all sucks because of the above mentioned points.

that puts the fpga into perspective.. and you imagine: there are some tousands, maybe hundred of tousands of engineers going to a 8 hour job thinking how the fuck we will integrate the clock because their slave masters told them to do it, otherwise they will have theirs asses kicked out.

fuck electronics man.. it is all a fucking big sickness. since humans discovered semi-conductivity, the porn started.
Well... but... what? I mean... urm... where to start? Are you serious, or just, I don't know, hitting your head against the keyboard and looking what that does?
Believe it or not, pointy haired people do exist!
+++Divide By Cucumber Error. Please Reinstall Universe And Reboot +++
 

Offline c4757p

  • Super Contributor
  • ***
  • Posts: 7799
  • Country: us
  • adieu
Re: EEVblog #496 - What Is An FPGA?
« Reply #29 on: July 20, 2013, 01:58:55 pm »
fpga is an example of this monstruosity. why embeding, why making it faster ? how long do you think integrating, embeding until you reach to the final usable limit of the cosmos / universe / this space - temporal dimension and give up in front of infinity  ?

Any chance you're from Colorado or Washington?
No longer active here - try the IRC channel if you just can't be without me :)
 

Online xrunner

  • Super Contributor
  • ***
  • Posts: 7496
  • Country: us
  • hp>Agilent>Keysight>???
Re: EEVblog #496 - What Is An FPGA?
« Reply #30 on: July 20, 2013, 02:08:38 pm »
fuck electronics man.. it is all a fucking big sickness. since humans discovered semi-conductivity, the porn started.

I can't wait till we invent true A.I., so we can just tell the thing to make itself smarter by re-inventing itself over and better, and telling the resulting thing to do the same, lather - rinse - repeat, and sit back, finally having nothing of importance left for mankind to accomplish.
I told my friends I could teach them to be funny, but they all just laughed at me.
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: EEVblog #496 - What Is An FPGA?
« Reply #31 on: July 20, 2013, 02:15:51 pm »
I suspect that most engineers and most projects are not consumer projects and the cost of an FPGA is really not all that significant.  In fact, other than the work I'm doing now with my own business, I'd have to think hard if I EVER worked on a shrink wrapped consumer product, or even know anyone who has.  I believe the answer is no.  A friend of mine works for iRobot but he doesn't work on those cute little vacuum cleaners.

and here lies your problem, You suspect wrong. Market is all about optimization of cost. Altium bet on FPGAs taking over design, but FPGAs are expensive, and dedicated hardware will ALWAYS BE CHEAPER. Not to mention thanks to globalization its cheaper to hire 100 chinese/indian monkeys to code complete works of William Shakespeare than to pay living wage to 3 CS/EEs on staff.

There's a reason FPGA starts keep going up.  I can design one basic architecture with some basic IO on it, and then keep reusing that over and over and over and over again, just tweaking a bit here and there, adding a little here, removing a little there, etc etc.  You're stuck thinking about high volume production.  I'm starting to wonder if you understand how much engineering is done that DOESN'T target a high volume consumer market?

For the record, I'm not trying to be argumentative here.  There is just a huge amount of embedded engineering that is done where it doesn't matter one bit if a part cost $3 or $300.  It is completely and utterly dwarfed by a team of engineers, billing out at $100+ an hour, for 6 months.  Whatever gets you to the finish line soonest and with the greatest chance of success is by far the cheapest solution.
« Last Edit: July 20, 2013, 02:27:46 pm by John Coloccia »
 

Offline lgbeno

  • Frequent Contributor
  • **
  • Posts: 349
  • Country: 00
EEVblog #496 - What Is An FPGA?
« Reply #32 on: July 20, 2013, 02:52:07 pm »
I suspect that most engineers and most projects are not consumer projects and the cost of an FPGA is really not all that significant.  In fact, other than the work I'm doing now with my own business, I'd have to think hard if I EVER worked on a shrink wrapped consumer product, or even know anyone who has.  I believe the answer is no.  A friend of mine works for iRobot but he doesn't work on those cute little vacuum cleaners.

and here lies your problem, You suspect wrong. Market is all about optimization of cost. Altium bet on FPGAs taking over design, but FPGAs are expensive, and dedicated hardware will ALWAYS BE CHEAPER. Not to mention thanks to globalization its cheaper to hire 100 chinese/indian monkeys to code complete works of William Shakespeare than to pay living wage to 3 CS/EEs on staff.

This is almost entirely true, the only counter point that I would attempt to make is that as digital electronics move to deeper into submicron processes, a single piece of silicon needs to address bigger and bigger market with the same mask set due to the need to recover the costs associated with development.  Particularly eda software, design engineers and the actual mask set.  FPGAs are already flexible enough to span a very broad range of applications that may take a family of 10-20 processors to address.  With that said, I still agree it will either be a long time coming or wouldn't hit mainstream.

About programming model.  The value proposition of fpgas to hardware guys is very clear.  Trying to find a micro with 5 uarts, a can port, 50 io, ddr2 mem and hdmi video that fits your cost target might be impossible but quite trivial in an FPGA.

Most true software engineers who I've worked with dislike fpgas because they don't think in HDL, they think in sequential c code and would prefer to leverage reference code from an os or open source instead of hand crafting drivers for the custom HDL you just optimized for a specific application.  This is why software guys latch onto arm because it is a sophisticated, pre defined and tested ecosystem.  Saves ALOT of hardware vs software finger pointing.  With an FPGA you have to validate and test all of your own work, with a hard processor they have already done that (and published errata for what they missed)

With all of that said, I'm a hardware guy and love FPGAs...  Keep the videos coming!

 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #496 - What Is An FPGA?
« Reply #33 on: July 20, 2013, 03:24:25 pm »
Some pointers for people who want to start with FPGAs:
1. Simulators are extremely accurate in "post place and route" mode, enough to develop the entire project without programming a chip even once. So the only real reason to buy a board is to have that cool feeling when the first LED blinks on a real hardware.
2. There is an open-source simulator called iverilog (for Verilog only, obviously). It works on Win/MAC/Linux, really fast and easy to use. The benefit of using it on the initial stages is that it is possible to use your favorite IDE and not an IDE from the chip vendor, which are sort of slow and not all that great.

1) simulators are killjoy's... note more fun than seeing led's blink, especially when getting started.

2)the IDe of the vendor is orders of magnitude better than the kludged together 'roll your own environment'. for 2 reasons :
 reason 1 : it knows the EXACT behavior of the selected fpga timingwise. something that open-sauce stuff will never be able to do as that info is proprietary and vendor dependent
 reason 2 : the vendors ide works 'out of the box'. download, install ,run. draw a few gates, write some lines of hdl , click 1 button and done. when entering the complicated world of FPGA's there is no need to make it even more harder by having first build your environment.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #496 - What Is An FPGA?
« Reply #34 on: July 20, 2013, 03:29:12 pm »
"technical life gives birth to monsters" was one of the quates i remembered.

fpga is an example of this monstruosity. why embeding, why making it faster ? how long do you think integrating, embeding until you reach to the final usable limit of the cosmos / universe / this space - temporal dimension and give up in front of infinity  ?

assholes from IBM thought ohhh.. let's make an atomic memory, each atom holding one bit - and then hires somebody to "produce" or "edit" videos like this guy going around on how science and technology will make the human life better.

beeing all relative -  faster and slower, bigger and smaller, discrete or integrated only means control over others is beeing passed from one group of people to another for a short period of time while they are dreaming about their accoumplishments in the field.

dave playing the violin in a certain group: new modern independent high tech cutting edge online job ...with a highly stage managed and controlled smile to fit the motto: "entusiastic and passionate"

ogh.. o by the way: we can't care less about how video editing takes place. it all sucks because of the above mentioned points.

that puts the fpga into perspective.. and you imagine: there are some tousands, maybe hundred of tousands of engineers going to a 8 hour job thinking how the fuck we will integrate the clock because their slave masters told them to do it, otherwise they will have theirs asses kicked out.

fuck electronics man.. it is all a fucking big sickness. since humans discovered semi-conductivity, the porn started.

you need to lay off the strongly activated rosin-core flux... it's wreaking havoc above your nose...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #496 - What Is An FPGA?
« Reply #35 on: July 20, 2013, 03:30:15 pm »
Maybe next time you can cover the difference with CPLD (although maybe you should have started with it :) )

I did contemplate starting the video working from GAL's/PAL's to CPLD, to FPGA's, but figured it would ultimately take too much time. I was right, because I waffled on for 37min on just FPGA's  ;D

and you forgot to erase top left the config memory that sits in a cpld. where in fpga it is external ...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #496 - What Is An FPGA?
« Reply #36 on: July 20, 2013, 03:34:34 pm »
fuck electronics man.. it is all a fucking big sickness. since humans discovered semi-conductivity, the porn started.

I can't wait till we invent true A.I., so we can just tell the thing to make itself smarter by re-inventing itself over and better, and telling the resulting thing to do the same, lather - rinse - repeat, and sit back, finally having nothing of importance left for mankind to accomplish.

screwa AI. we need FPGA's with telepatic interfaces. here's why :
- simple pcb design all you need is power and ground ( or you could stick a solar cell on the back of the package. no routing needed.
- since they are telepatic they are all interconnected
- since they are telepatic : no compilers, simulators and other junk needed. i simply think ' i need a spi port here and a decoder that drives a led display with pwm dimming. as i am thinking the fpga reconfigures itself ( it's telepathic so it can do immediately what iam thinking about )

that's the future. and were almost 99% there. we got all the bits , it's just that damn telepatic interface ... i'll have to get back in my lab , let me grab my tinfoil hat with coathanger ( the hat collects my brainave and the coathanger emits them ) and see if i can pick em up with me DE0 board ...
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Online xrunner

  • Super Contributor
  • ***
  • Posts: 7496
  • Country: us
  • hp>Agilent>Keysight>???
Re: EEVblog #496 - What Is An FPGA?
« Reply #37 on: July 20, 2013, 03:38:19 pm »
screwa AI. we need FPGA's with telepatic interfaces ...

Ah yes - TPGAs (Telepathically Programmed Gate Arrays)  :)

Seriously, the video helped me understand this device immensely - thanks Dave.  :-+
I told my friends I could teach them to be funny, but they all just laughed at me.
 

Offline Winston

  • Regular Contributor
  • *
  • Posts: 121
  • Country: us
    • IC Die Photography
Re: EEVblog #496 - What Is An FPGA?
« Reply #38 on: July 20, 2013, 04:16:39 pm »
Fantastic video! Looking forward to more.  Idea for a geek t-shirt - a large graphic of a human brain with "FPGA" and/or "Field Programmable Gate Array" under it.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #496 - What Is An FPGA?
« Reply #39 on: July 20, 2013, 04:22:35 pm »
now, all the joking aside.

FPGA's have their place in medium volume applications where the design of full custom is too expensive , and the standard stuff available is simply too cumbersome as it would make the system physically large.
Another field is the area where not all criteria are known yet but design needs to start. Simply slap in an fpga and as the design evolves , adapt it. We'll deal with it later...

You will find fpga's in oscilloscopes from one-hung-lo ( because they don't have the money to go full-custom) to Agilent ( if there is an afterthought they can simply release a new config pattern and expand capabilities and lifetime of a product.

The idea of having soft-cores is indeed dwindling down. It is counterproductive and wastes gigantic amounts of cells in the fpga. The best solution is to take a standard microcontroller or microprocessor and pair it with an FPGA. Some fpga vendors are now offering fpga's with hard-cores ( cortex ) in em. That is the real future.

I have been using microcontroller/fpga combos for a long time. Instead of screwing around trying to get the cpu to do some very difficult , because timing related, task and jump through hoops i simply offload that to the fpga.
Doing this allows for fast and simple code on the cpu and fast and simple code in the fpga. A cpu has its strenghts and an fpga has its strengths. Combining the two is a win-win situation.

Now, on the development front : while fpgas are internally incredibly complex in terms of interconnect and partitioning , you are almost completely shielded from that by the development tools. Even for medium to large size designs you will never have to dig into manual constrianing , timing closure and other 'nasties'. I have designs running in FPGA , clocked at 200MHz. I didn't do a single timing analysis in the entire design. I didn't even simulate it. The fpga is fast enough to cope with this. my design is partitioned so that control signals govern the passing of information between blocks. The control signals are written in such a way that they are active at least one clocktick later than the data is steady. the only tricky bit where ismulation was needed was an arbitration system and the domain crossing. those things are difficult. but if you design fully syncronous logic in 99% of the cases it will work without having to fidget with the complex bits.

If you take a cheap fpga and i give you the task to do the following :

Make me a LED display driver for those 14 segment displays( starburst ) that can drive a 16 character display , multiplexed, with pwm dimming , character decoder and a spi interface this may sound overwhelming.
in reality the implementation is very simple and you can design block by block , try the block in a simulator , and then move to the next block.

spi interface :
lets assume we do a 16 bit transfer : first 8 bits hold '0000' followed by a 4 bit character address , next 8 bit hold the character code

0000_1001_0110_0101 as spi transfer would mean :
------    9      6     5     : character 9 is 0x65

here we go :

Code: [Select]

module spi(input MOSI,CLK,CE, output char[7:0], input address[3:0])

reg [7:0] char0,char1,char2,char3,char4,char5,char6,char7,char8,char9 ... // we need 17 here

always @(posedge CLK)
if (!CE) begin
    shifter[15:0] <= shifter{[14:0,MOSI};   // if CE is low : shift MOSI in to a shiftregister controlled by the CLK
end
else begin
    if case (shifter [11:8])
      4'b0000 : char0 <= shifter[7:0];
     4'b0001 : char1 <=shifter[7:0];
    ... do this for the 16 possible combinations
end

// look ma : i just made an SPI slave device that can take in a 16 bit command word, decode it and store the data in 16 registers...
// now how do we get the data out to process it internally ?
// well

always_comb begin
  case address[3:0]
    4'b0000 : char = char0;
   4'b0001 : char = char1;
 .. contine the decoder her for all 16 locations
end case
end
endmodule

there you go. a block in the fpga can now randomly access the stored characterloaded through SPI...

oh. wait dimming .. we had 4 empty bits right ? let use the first bit to switch between 'loading text' and setting options..
if i was breadboarding this with chips this would be an 'oh fuck' moment... but since this is an fpga... piece of cake:


Code: [Select]
module spi(input MOSI,CLK,CE, output char[7:0], input address[3:0], output reg brightness[7:0])  // add an 8 bit output for brightness

reg [7:0] char0,char1,char2,char3,char4,char5,char6,char7,char8,char9 ... char15;

always @(posedge CLK)
if (!CE) begin
    shifter[15:0] <= shifter{[14:0,MOSI};   // if CE is low : shift MOSI in to a shiftregister controlled by the CLK
end
else begin
    if shifter[15]  brightness <=shifter[7:0]; // if the bit is set : it's brightness
   else  // if not : its characters.
     case (shifter [11:8])
      4'b0000 : char0 <= shifter[7:0];
     4'b0001 : char1 <=shifter[7:0];
    ...
     4'b1111 : char1 <=shifter[7:0];
   end case
end

// look ma : i just made an SPI slave device that can take in a 16 bit command word, decode it and store the data in 16 registers...
// now how do we get the data out to process it internally ?
// well

always_comb begin
  case address[3:0]
    4'b0000 : char = char0;
   4'b0001 : char = char1;
 .. contine the decoder her for all 16 locations
end case
end
endmodule

now, purists are going to say : you could have made an array of chars , you could have done away with the if shifter[15] and simply made a biger case statement testing for the bit there like so:

case shifter[15:8]
8'b1000_0000 : brightness < ...
8'b0000_0000 : char0 < ...
...
8'b0000_1111 : char15 <...

in the end it all doesnt matter. yes you could write it more compact, cleaner but the end result will be EXACTLY the same. this is different form writing software. in software: the more lines of code you plonk down the more instructions you end up with and the more clockcyles the cpu will take to execute it.

in an FPGA this is NOT the case. Your brainfart gets translated in logic equations. These get expanded first , minimized and mapped in a lookup table. The end result is : 1 clocktick to do all that crap. Irrespective of how you wrote it, longwinded, elegantly, purist format, doesn't matter. The language statements all create boolean logic. if the source ended up with a very long equation , or a short one doesn't matter , after logic minimizing both will yield the same solution, simply because there is only 1 solution in the logic domain for a given problem.

so now we have access to the stored characters... how do we scan them..

well, a counter selecting one of them and sending it to the decoder and selecting the common line of one of the display.

Code: [Select]
module scanner( output reg address[3:0], output columns[15:0])

[code]
always @(posedge clk) begin
   address <=address +1;  // no need for other code. when we hit 1111 it will roll to 0000. basic nature of flipflop logic
end
always_comb begin  // make me some combinatorial crap here
columns[15:0] == 16'd1 << address; // make only 1 bit high , bit is determined by value of 'adress'
end

if i now to the address lines of this module to the address lines of my spi block , the spi block will spit out the recieved characters in sequential order. at the same time my outputs select one of the column drivers in the display.

all i need is a character decoder

Code: [Select]
module starburst (input char[7:0], output bitmap[13:0]
begin

always_comb case char[7:0]
  8'd65 : bitmap = 11_0000_1000_1010  // bitmap for letter 'A"
  8'd66 : bitmap = 11_1001_1001_1001 // bitmap for letter 'B'
.. and so on

 default : bitmap = 00_0000_0000_0000 // anything we didnt define : display nothing
end case
endmodule

connect the char bus together and you are done. this thing will scan the characters, decode the character into the appropriate LED bitmap , select the reight column and drive the leds'.

oh.. dimming... well i leave that up to you : simply throw in a counter that gets loaded with the dimming value and counts down. if the counter is larger than dimming value : pas the bitmap , if it is lower : force the bitmap to all 0. this is imply a small block between the output of the starburst module and the real led pins.

along the lines of

pwm = pwm+1
if (pwm > brightness)  bitmap_out = 0 else bitmap_out = bitmap...

so in a few lines , each in a very simple step i have created a fairly complex bit of logic. it reads an SPI datastream , decodes instructions and data, stores it , scans the stored information , decodes that into character bitmaps , pwm's the output and drives a 16 character 14 pixel led display...

that is a VERY complex thing if you were to try doing that with loose ttl or cmos chips.... the schematic alone is a nightmare. working out all the equations is a nightmare , soldering it is a nightmare.

plonk down an FPGA, think a bit what you need , partition it in simple chunks, write some simple code and leave the rest to the synthesizer. it will work out all the details.
do i need to do timing analysis for the bove ? hell no. That spi clock is 16Mhz. The FPGA laughs at that ...
the character decoder may be large and have some trouble , but, since the display is scanned at a much slower pace you wont even see it there. you could simply throw in another latch ar inject a deadtime between character transients to mask that off.

it ain't something to be scared of
« Last Edit: July 20, 2013, 04:30:13 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #496 - What Is An FPGA?
« Reply #40 on: July 20, 2013, 04:54:38 pm »
With all of that said, I'm a hardware guy and love FPGAs...  Keep the videos coming!
I'm a software guy and I love FPGAs too :) In VHDL you can even use variables, procedures, functions and loops. But you have to keep in mind that it needs A LOT of logic units, because a loop is kind of unrolled and synthesized in parallel, same for procedures and functions. You have to sequence it with state machines from time to time, when it gets to big or when the timing requirements are not met anymore because of too long logic chains. Hardware guys don't like my VHDL code :P
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline lgbeno

  • Frequent Contributor
  • **
  • Posts: 349
  • Country: 00
EEVblog #496 - What Is An FPGA?
« Reply #41 on: July 20, 2013, 05:47:32 pm »
With all of that said, I'm a hardware guy and love FPGAs...  Keep the videos coming!
I'm a software guy and I love FPGAs too :) In VHDL you can even use variables, procedures, functions and loops. But you have to keep in mind that it needs A LOT of logic units, because a loop is kind of unrolled and synthesized in parallel, same for procedures and functions. You have to sequence it with state machines from time to time, when it gets to big or when the timing requirements are not met anymore because of too long logic chains. Hardware guys don't like my VHDL code :P

Software guys who write HDL are the best!
 

Offline TheWelly888

  • Frequent Contributor
  • **
  • Posts: 344
  • Country: gb
Re: EEVblog #496 - What Is An FPGA?
« Reply #42 on: July 20, 2013, 06:06:00 pm »
Thanks Dave for the video. You have made the difference between FPGA and microcontrollers clear for me.

I noticed the thumbs up count climbed by 13 during my viewing  :-+
You can do anything with the right attitude and a hammer.
 

Offline Corporate666

  • Supporter
  • ****
  • Posts: 2008
  • Country: us
  • Remember, you are unique, just like everybody else
Re: EEVblog #496 - What Is An FPGA?
« Reply #43 on: July 20, 2013, 06:19:21 pm »
now, all the joking aside....


Free_Electron is such a huge resource to this site.  Loved reading the post, as always.
It's not always the most popular person who gets the job done.
 

Offline John Coloccia

  • Super Contributor
  • ***
  • Posts: 1208
  • Country: us
Re: EEVblog #496 - What Is An FPGA?
« Reply #44 on: July 20, 2013, 06:20:38 pm »

The idea of having soft-cores is indeed dwindling down. It is counterproductive and wastes gigantic amounts of cells in the fpga. The best solution is to take a standard microcontroller or microprocessor and pair it with an FPGA. Some fpga vendors are now offering fpga's with hard-cores ( cortex ) in em. That is the real future.

Either way.  I don't think the softcore is the essential feature.  Pairing SOME processor with an FPGA is the essential ingredient.

And as you so clearly show later on, you don't "program" the gates in an FPGA.  It would actually be better to think of it as combining certain patterns that you know will translate into specific gate configurations.  If you think of it as programming, you'll quickly get into trouble.  Specifying it in Verilog is far more convenient than drawing out some sort of schematic language, just because it's easier to actually see exactly what's going on when it starts getting larger and complex.  It's really best, though, to still think in terms of the basic building blocks that get created on the FPGA, and to simply know the common patterns off the top of your head.
 

Offline Winston

  • Regular Contributor
  • *
  • Posts: 121
  • Country: us
    • IC Die Photography
Re: EEVblog #496 - What Is An FPGA?
« Reply #45 on: July 20, 2013, 06:50:50 pm »
Nobody mention the spelling mistake at the top of the whiteboard!   >:D

It reminds me of the lift in the electronic engineering building at Leeds Uni, there's a big red button on the panel that says EMERERGENCY. Glancing at it, you know it is wrong somehow, but your brain won't say what's actually wrong.
A bug or a feature of our evolutionary programmed grey matter FPGAs?
 

Offline Winston

  • Regular Contributor
  • *
  • Posts: 121
  • Country: us
    • IC Die Photography
Re: EEVblog #496 - What Is An FPGA?
« Reply #46 on: July 20, 2013, 07:09:04 pm »
Maybe next time you can cover the difference with CPLD (although maybe you should have started with it :) )

I did contemplate starting the video working from GAL's/PAL's to CPLD, to FPGA's, but figured it would ultimately take too much time. I was right, because I waffled on for 37min on just FPGA's  ;D
I definitely wouldn't consider it waffling.  It was beautifully concise and well organized and I learned a great deal.  Please continue on the subject in any direction you feel to be most productive.
 

Offline tru

  • Regular Contributor
  • *
  • Posts: 107
  • Country: gb
Re: EEVblog #496 - What Is An FPGA?
« Reply #47 on: July 20, 2013, 07:37:37 pm »
Nice video Dave. Softcore CPU I think for a FPGA defeats the purpose of FPGA use.  What I understand (in real world terms) is that the FPGA is like a programmable DSP where you can process input signals with many operations all in parallel or due time before the signal changes, but a softcore CPU does things in sequence so one could (as many do) simply use an external ARM CPU with the FPGA.

There are cases where a microcontroller (MCU) or CPU just won't be able to do the job of the FPGA, that is without it being many times faster than the input signals.  A good example is the digital triggering detection in an oscilloscope of let's say for arguments sake at 100 Mega samples/s and that we don't want to miss any samples until a trigger occurred.  At 100MSPS the ADC is capturing each sample at 10ns.  Let's suppose we tried to use an ARM CPU and it executes instructions at 100MHz (suppose each instruction runs at 10ns), now, when the if conditional runs to check for a possible trigger it will be missing the next ADC sample of input!  Even worse if you have multiple if conditions to do, more samples are missed, before the ARM even has a chance to process the first input sample!
« Last Edit: July 21, 2013, 07:39:07 am by tru »
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #496 - What Is An FPGA?
« Reply #48 on: July 20, 2013, 07:47:59 pm »
now , to give you another example of what is possible and within reach of everybody. a friend of mine , possibly known to some of you. his name is foto_opa. he's the guy doing those insect pictures.

Retired electronics engineer, never really did anything with cpu's nor fpga during his lifetime. was kinda hesitant to roll into it. he had tried on his own but basically got nowhere. VHDL was too hard to figureout. so , on another forum i kinda pitched in and gave hime some simple examples. splitting a problem into little blocks , code them up. no overloading him with how to instatiate blocks , nor explaining how to do testbenches etc. that was for later ...

Toplevel : schematic. Yes, laugh all you want. going from raw to cooked is not instantaneous it takes time. Take little steps, use stuff that is familiar. It is great to have a toplevel schematic representation that shows you how blocks are connected. Doubleclick on a block and there is the code for it. You can make nice hierarchical designs that are navigated by schematic. Very easy to understand for anyone who has ever looked at an electronics circuit. You can even plonk in any part from a collection of premade TTL chips.

He bought the DE nano board and some others from terasic.

You should see his photography setup. The entire system has multiple lasers that pinpoint where the insect is, he uses linear ccd's to measure reflection of light and positioning within a frame , uses another module that calclates focusing , calculates light and exposure , drives a lcd display, reads buttons. All that stuff runs without a single cpu. It is pure hard logic going flat out.

to give you an idea : if the photodiodes detect reflected light from the lasers he has under a microsecond to perform the finding of the insect in the focus aperture, do the calculation , fire the shutter and the strobes.

The calculations done are immense. He is sampling linear ccd's, averaging them , performing peak detection , and much more. The number of instructions needed for that on a sequential processor are in the many thousands... not a problem you way..

well it is, especially if you tell that processor , you have 1 microsecond to execute this bunch of instructions... if your cpu neeeds to do 1000 instructions , and it needs 2 clockticks per instruction and it has 1 microsecond to execute them .. you need to clock it at 2 GHz ! or faster. and you havent even moved data yet ..

Throw that at the little PIC or AVR and this is what will happen :
it will jump out of its socket , scamper to the far corner of your circuit board , roll over on it's back , curl up it's tiny little legs and simply die...

the FPGA ? all that thing does is  go 'meh' ... you need to do averaging on 16 samples each 256 bits wide and perform a peak detect on them ? in 1 microsceond ? let's see. 16 samples is 1/16 of a microsecond each. Tree reducing from 256 to 1 takes 6 clocks (to find which cell has the highest value. so with 1/24 of a microsecond i can do this.. just clock me at 24 MHz and i will give you the peak of the averaged signal....

that is the power of parallel processing and massive amounts of custom hardware. things a cpu takes thousands of instructions the FPGA does in a few clockticks , simply becasue it parallelizes the problem. if your cpu has no hardware multiplier on board you are stuck with emulating this with a software routine. if your fpga has no hardware multiplier , and you need one , you build one and move on...
you can;t add something to a CPU that is not there ... in the FPGA ? not a problem. that's what the damn thing is for.

http://www.flickr.com/photos/fotoopa_hs/

this is the machine doing it :
http://www.flickr.com/photos/fotoopa_hs/sets/72157627714453063/

driven by a single cyclone FPGA.
« Last Edit: July 20, 2013, 07:51:17 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline marshallh

  • Supporter
  • ****
  • Posts: 1462
  • Country: us
    • retroactive
Re: EEVblog #496 - What Is An FPGA?
« Reply #49 on: July 20, 2013, 07:55:29 pm »
FPGAs are very handy when you need them.
They are really only suited for niche applications, but keep in mind there are a LOT of niches.

I would add some things:

1. Simulation - it's great if you are building a completely self contained module where you can directly constrain the inputs and outputs. Something like an internal DSP filter, framebuffer processor, etc. For interfacing with things like DDRx memory, external PHYs, glue logic, etc you are going to be forced to develop in tandem with the physical part. It's what I prefer anyway.

2. Internal constraints - Low-cost fpgas ($<200-300) have Fmax limitations usually around 130-150mhz. It gets very hard to clock logic faster than that. If you have a small functional unit you could spend time pipelining and optimizing by hand (and in the case of xilnx ISE, manually placing elements sometimes) and approach 200mhz. For something more complex like a 5stage pipelined MIPS core you would be lucky to break 60-70mhz. The process of hand tuning the code/constraints/routing until you achieve your desired clock speed in that unit is called "closing timing". You will either have gap/slack in propagation delay.

3. Understand the architecture of the FPGA you will be using, enough to know how your logic is getting mangled to fit in these elements. Recognize patterns in how the fitter is allocating resources. Then you can avoid writing constructs that cause excessive logic utilzation and kill your timing margin.

4. Read, read, read. I see questions from people using silicon they have obviously not read any datasheets about. You may have to read 1000-1500 pages of chapters in the FPGA handbooks to fully undesrtand what you are dealing with, especially if you are designing one into a PCB.

5. The mental "jump" of getting your brain to think in terms of synchronous, parallel hardware description takes time. I know people that took several years to fully grasp it. Some caught it in several months (those that were building glue logic with 74xx parts and GALs). It took me over a year to understand what it was all about.

6. CPUs and FPGAs - There are some problems that can ONLY be solved with a CPU. The converse is also true. The best design is one that has BOTH a cpu and fpga in it, with each doing what they are best at. This is also USUALLY the cheapest option. Embedding a softcore in your fpga is a good way to burn logic usage, necessitate a more expensive part, and still be inferior to dedicated silicon. The only advantage is when you want augmented instruction sets. For example, would you want to write verilog that parses a FAT32 filesystem? HELL no! It can be done, with tens of interlocking FSMs. It can also be done with a couple kilobytes of compiled C code almost painlessly. And samely, doing hashes, crcs and dumb transforms are blindingly fast in logic. Complete pipelined SHA hash coming out every 1 cycle? Possible. Not so in a CPU. Once you are exposed to enough algos/concepts you'll discern where to plop each one.

7. Xilinx vs Altera - let me say right out front that I greatly prefer Altera tools. Having used both vendors tools --
Altera: slightly more expensive/less bleeding edge silicon. Parts are better characterized, much fewer silicon bugs that need to be worked around. Quartus II design software is very well integrated, consistent, minimal foot-shooting. Free Signaltap logic analyzer you can embed.
Xilinx: slightly cheaper parts, may have faster I/O or special options. Silicon bugs are common, some are show stoppers (Virtex-5 PCIe hard IP is quite broken). For 6 series parts and below, ISE is required. ISE is a flaming pile of bug ridden crap, an amalgamation of separate software absorbed into the parent company over the past 10 years held together with duct tape. Even Xilinx reps admit it sucks. Bugs causing poor device fitting are common, early versions compiled on random seeds so you could fail timing one compile and pass the next. However for 7 series +, everything was retooled for the Vivado suite, which I hear is quite a step up, and supports more commonplace things (Like systemverilog, which ISE doesn't)

I would use Altera for protos/low volume, Xilinx for high volume where the one time cost of extra pain in ISE pays off among units sold.

Lattice makes FPGAs and low power CPLDs also. They bought SiliconBlue a few years ago which has tiny FPGAs that draw microamps current, and come in 0.4mm BGAs. Their upper end ECP3 line is pretty competent and well priced. Diamond design software uses external Synopsys compiler and is not as well integrated as Quartus.

Actel/Microsemi make radhard/flash based parts. The tools are on par with ISE, but the parts are very cheap. You also need to buy in volume.
Verilog tips
BGA soldering intro

11:37 <@ktemkin> c4757p: marshall has transcended communications media
11:37 <@ktemkin> He speaks protocols directly.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf