Author Topic: EEVblog #635 - FPGA's Vs Microcontrollers  (Read 26910 times)

0 Members and 1 Guest are viewing this topic.

Offline xygor

  • Regular Contributor
  • *
  • Posts: 227
  • Country: us
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #25 on: July 01, 2014, 05:09:28 pm »
Does anyone remember or have used 'jbits'?
http://www.xilinx.com/prs_rls/end_markets/03108jbits.htm

It was withdrawn.  It looks like it would have allowed one to write one's own synthesis and P&R software.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #26 on: July 01, 2014, 05:37:35 pm »
There is Altera OpenCL
http://www.altera.com/products/software/opencl/opencl-index.html

For now it's aimed to Stratix V and up so a dev board will probably cost north of $5K

but it's a step in the right direction.
 

Offline BytesGuy

  • Regular Contributor
  • *
  • Posts: 50
  • Country: gb
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #27 on: July 01, 2014, 08:10:15 pm »
Lattice XO2 devices mop up a lot of this messy stuff - internal core voltage regulator, flash and even an oscillator, albeit with only 5% accuracy.

..and does anyone use platform flash these days now that SPI flash is so cheap?
You can in most cases program it through the FPGA, avoiding the need to have seperate connections to the programmer.

I really don't understand why FPGAs don't include at least an MCU style osc that you can connect a crystal to.

Would you recommend one of those XO2 breakout boards as a cheap way to get into FPGAs?

I don't really fancy forking out £100+ on an FPGA board because I probably won't use it enough!

I do like the fact the breakout board gives you access to virtually every pin so you are not bound to use peripherals that are pre built on the board.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #28 on: July 01, 2014, 08:35:19 pm »
Lattice XO2 devices mop up a lot of this messy stuff - internal core voltage regulator, flash and even an oscillator, albeit with only 5% accuracy.

..and does anyone use platform flash these days now that SPI flash is so cheap?
You can in most cases program it through the FPGA, avoiding the need to have seperate connections to the programmer.

I really don't understand why FPGAs don't include at least an MCU style osc that you can connect a crystal to.

Would you recommend one of those XO2 breakout boards as a cheap way to get into FPGAs?

I don't really fancy forking out £100+ on an FPGA board because I probably won't use it enough!

I do like the fact the breakout board gives you access to virtually every pin so you are not bound to use peripherals that are pre built on the board.
Yes, definitely
http://uk.mouser.com/ProductDetail/Lattice/LCMXO2-7000HE-B-EVN/?qs=sGAEpiMZZMurtJ7VwBTl0fuXvMOPgNe8hSHI90CFJ0k%3d
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline BytesGuy

  • Regular Contributor
  • *
  • Posts: 50
  • Country: gb
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #29 on: July 01, 2014, 09:39:42 pm »
Lattice XO2 devices mop up a lot of this messy stuff - internal core voltage regulator, flash and even an oscillator, albeit with only 5% accuracy.

..and does anyone use platform flash these days now that SPI flash is so cheap?
You can in most cases program it through the FPGA, avoiding the need to have seperate connections to the programmer.

I really don't understand why FPGAs don't include at least an MCU style osc that you can connect a crystal to.

Would you recommend one of those XO2 breakout boards as a cheap way to get into FPGAs?

I don't really fancy forking out £100+ on an FPGA board because I probably won't use it enough!

I do like the fact the breakout board gives you access to virtually every pin so you are not bound to use peripherals that are pre built on the board.
Yes, definitely
http://uk.mouser.com/ProductDetail/Lattice/LCMXO2-7000HE-B-EVN/?qs=sGAEpiMZZMurtJ7VwBTl0fuXvMOPgNe8hSHI90CFJ0k%3d

Thanks Mike :-+

£17 is a really good price. Shame the delivery is £12 though, know of any other places that may be cheaper?
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #30 on: July 01, 2014, 09:43:43 pm »
Would you recommend one of those XO2 breakout boards as a cheap way to get into FPGAs?

Any FPGA board will get you into FPGAs quicker than not having a board at all. But if you think about it for a while, does having a breakout board as your first dev board make sense?

To make use of FPGAs you are going to spend a while 'fiddling' with the technology. To do anything moderately complex will take a lot of study to develop the skills to make it work. It is worth it, as once over the hump in the learning curve almost anything is then possible.

So when you buy your first FPGA board, don't think "goodie! this is the board that I am going to use to build a SDR platform or 100 MHz 32-bit CPU on it!". That is like an electronics novice thinking that they will be designing a superhet receiver and a 100W stereo amp and PSU as their first project. If you head down this road then odds are that the FPGA board will sit on the bench, and then languish the cupboard unused.

I strongly suggest that you think "I am a beginner student at the start of a long journey to learn how to design state of the art digital electronics. I need something on which I can play with and practice on and develop my skills before I shoot for the moon". Think how long it took you to get familar with analogue electronics - it is going to take a few hundred hours. How much did you spend on that journey for parts and tools?

Here's a video from somebody who is starting out, and taking the low road and just purchased what is almost a bare FPGA board - http://t.co/EYY82JedM6 -  how much more productive would he be over the next few weeks if he had spend an extra $40 on the pre-built board with the LEDs, switches, connectors, ADCs and so on? (http://papilio.cc/index.php?n=Papilio.LogicStartMegaWing).

Rather than slugging it out for a few months with a naked breakout board, soldering leds and wires, wouldn't you rather spend time working with a Digilent Nexys3? (http://www.digilentinc.com/Products/Detail.cfm?Prod=NEXYS3) It may seem like a lot, but some people pay more than that for a multimeter...

If you can't spend more than $100, just get something like a Papilio One 250k and a LogicStart (~$75 for both). That is less than a good soldering iron - but will give you equivilent to a quarter of a million gates to play with, and you won't need that soldering iron. If you out-grow it can then dedicate the Papilio one to a project, and get a Papilio Pro as your new development board.

But in general the *second* board you buy will be the breakout board you use in your first projects - your first FPGA board is what you will design that project on.
« Last Edit: July 01, 2014, 09:54:02 pm by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Online mikeselectricstuff

  • Super Contributor
  • ***
  • Posts: 13748
  • Country: gb
    • Mike's Electric Stuff
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #31 on: July 01, 2014, 09:53:27 pm »
Lattice XO2 devices mop up a lot of this messy stuff - internal core voltage regulator, flash and even an oscillator, albeit with only 5% accuracy.

..and does anyone use platform flash these days now that SPI flash is so cheap?
You can in most cases program it through the FPGA, avoiding the need to have seperate connections to the programmer.

I really don't understand why FPGAs don't include at least an MCU style osc that you can connect a crystal to.

Would you recommend one of those XO2 breakout boards as a cheap way to get into FPGAs?

I don't really fancy forking out £100+ on an FPGA board because I probably won't use it enough!

I do like the fact the breakout board gives you access to virtually every pin so you are not bound to use peripherals that are pre built on the board.
Yes, definitely
http://uk.mouser.com/ProductDetail/Lattice/LCMXO2-7000HE-B-EVN/?qs=sGAEpiMZZMurtJ7VwBTl0fuXvMOPgNe8hSHI90CFJ0k%3d

Thanks Mike :-+

£17 is a really good price. Shame the delivery is £12 though, know of any other places that may be cheaper?
Free shipping if you can get the order up to £50.
Youtube channel:Taking wierd stuff apart. Very apart.
Mike's Electric Stuff: High voltage, vintage electronics etc.
Day Job: Mostly LEDs
 

Offline Rigby

  • Super Contributor
  • ***
  • Posts: 1476
  • Country: us
  • Learning, very new at this. Righteous Asshole, too
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #32 on: July 01, 2014, 11:47:02 pm »


I remember discussing with a friend a while ago; wondering when someone was going to make the "Arduino of FPGAs" that is easy to build with and program with. 
Probably never, as you will always have to use the vendors place & route tools. You could make a nice front-end that called these & package it all up, but even if done really well it would still have a significant compile time.
This is where CPLD may be better, but probably too limiting.
Yeah, that front end thing worked out well for altium ;)

That doesn't make it a necessarily bad idea.

A well done front end and a little bit of end-user knowledge will go a long way.  From what I've seen of the Xilinx and Altera tools there is a great deal of improvement to be done.

It would be nice if there was some UI paradigm that grew the UI complexity as your understanding of the tools grew.  Something beyond the "basic" vs. "advanced" setting commonly seen.
 

Offline Zad

  • Super Contributor
  • ***
  • Posts: 1013
  • Country: gb
    • Digital Wizardry, Analogue Alchemy, Software Sorcery
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #33 on: July 02, 2014, 12:05:56 am »
I think the problem with software is exactly the same problem that Altium had - trying to be all things to everyone. The user interfaces all seem to look like something from the OS/2 era. I remember in the early 90s when I first got Borland C++ developer for windows, and it had an editor which allowed you to put as many icons, sub-windows and scrolly widgets as you wanted onto a nice "big" 800x600 window. They don't seem to have progressed much beyond this point.

I would say that it is a lack of competition which has stifled development of the UI, but CAD offerings as diverse as Eagle, LTSpice, Kicad etc all seem to suffer from the same failings.

Offline Russ.Dill@gmail.com

  • Contributor
  • Posts: 19
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #34 on: July 02, 2014, 01:55:37 am »
Yes, with a microcontroller, you never ever have to think even a moment about configuration memory. Its awesome, but I think that Dave makes the situation with FPGAs more intimidating than it needs to be.

A simple SPI flash is all you need. Its very low pin count and doesn't need a connection to the JTAG chain. The SPI flash can be programmed indirectly by the FPGA through JTAG, which is supported by the tools. The number of pages dedicated to supporting external SPI flash and indirect programming is pretty small. But again, as he warns "young players", there are many things you can get wrong and if you do, it can be absolutely maddening to debug.

And as another poster has pointed out, the configuration clock is available after configuration, but the frequency is not very precise.

(/me rolfs at the "Dave Jones" edition in the demo video)
 

Offline AlfBaz

  • Super Contributor
  • ***
  • Posts: 2184
  • Country: au
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #35 on: July 02, 2014, 02:18:30 am »
That doesn't make it a necessarily bad idea.

A well done front end and a little bit of end-user knowledge will go a long way.  From what I've seen of the Xilinx and Altera tools there is a great deal of improvement to be done.

It would be nice if there was some UI paradigm that grew the UI complexity as your understanding of the tools grew.  Something beyond the "basic" vs. "advanced" setting commonly seen.
I have to admit that I got into fpga's using altium's front end. It really was a blessing as it initially hid some of the more esoteric nuances of programming fpga's

As the level of complexity in my construct's grew I found I was resorting to the underlying synthesizer more and more until I eventually did everything in ISE
 

Offline nixfu

  • Supporter
  • ****
  • Posts: 346
  • Country: us
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #36 on: July 02, 2014, 03:10:39 am »
As a "micro-guy".  I just have not yet gotten what you do with an FPGA. 

I dont mean applications like DSP, ADA, etc.  but as a dev, what are you doing?   do you break what you want to do down into individual logic gates?   or do you mostly end up putting together/using pre-built special purpose cores?

i am an experienced developer with many platforms and languages but the FPGA seems even removed from using an assembler, yet I just cant wrap my head around the concept.



 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #37 on: July 02, 2014, 03:41:47 am »
As a "micro-guy".  I just have not yet gotten what you do with an FPGA. 

I dont mean applications like DSP, ADA, etc.  but as a dev, what are you doing?   do you break what you want to do down into individual logic gates?   or do you mostly end up putting together/using pre-built special purpose cores?

i am an experienced developer with many platforms and languages but the FPGA seems even removed from using an assembler, yet I just cant wrap my head around the concept.

Yes, all of the above.

You can do 'structural' designs where you wire pre-defined components together - much like a building a system's schematic. This is what I think most people with an electronics engineers background think that FPGAs are for - replacing lots of little chips.

You can do data-flow designs, where you set up a data stream that enters the FPGA, does stuff, and then exits the FPGA. (e.g. audio processing) - very much like a hardware based UNIX "filter" program. This is very DSP friendly - and this is what most computer S/W people think FPGAs are for.

You can do sequencing style designs (called Finite State Machines or FSM in the local jargon), where you build a state machine that does something special. This is what most embedded engineers think FPGAs are for -  bitbashing high speed I/O and adding custom MCU peripherals and so on.

You can also be designing a very advanced state machine, which looks much like a CPU. This is what Computer Scientists think FPGAs are for - playing with computer architectures.

High-end H/W suppliers think of FPGAs as a low cost / rapid development replacement for ASICs, when volume and/or performance requirements are relatively low.

And then ASIC developers think FPGAs are a way to validate the logic behind their designs before they get put into real silicon.

You usually end up doing a whole lot of things at once (except of course the last two!).

So maybe a CMOS camera system has a small CPU that controls the camera's I2C interface a data stream to receive the pixels from the camera and process them. They can then be put into a frame memory using a pre-designed memory controller block. After that it could then be displayed using a video controller, which is just PWM system which seqences accessing memory and squirts the pixels out to the DAC.

Some bits you will build at the gate level, other bits you build at the block level. Usually the closer you are to the input pins on the FPGA the closer to gate level you need to work, or perhaps you are trying to make the most of an internal DSP block where using tricky features can make huge performance gains.

Much like using software libraries, doing things with high-value pre-defined blocks usually costs real money, as you need to license them from the original developers.
« Last Edit: July 02, 2014, 03:43:21 am by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37740
  • Country: au
    • EEVblog
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #38 on: July 02, 2014, 03:53:52 am »
I think FPGA's are a bridge too far for hobbieists, they usually are extremely large and expensive and used for prototyping large circuits such as video circuits and such.
Nice for companies and pro's but not for amateurs.

The problem is that there are relatively few applications that can't be done (even if inelegantly) with a microcontroller these days.
So learning a entirely new way to conceptualise problems and "code" them is a very steep curve. Let alone the complex tools and setup required to get them working properly as well.
So it's a huge step to get into what is ultimately a niche application area.
Almost everyone remotely technical is familiar with traditional sequential processor based programing, so something like the Arduino or other micro solution is a snap to understand and pickup and use. But FPGA's aren't even close to that I'm afraid.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37740
  • Country: au
    • EEVblog
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #39 on: July 02, 2014, 03:57:32 am »
Do NOT compare FPGA and microcontrollers. They are totally different beasts. Yes, you can plonk a softcore in the larger ones but those are only used to do stuff that is too complex to synthesize into hard logic. Apart from some very niche applications no sane system designers cams the entire logic + cpu in an FPGA. they are too expensive for that.

And that is why Altium betting the entire company that this would be the future of electronics failed so miserably  :-DD
 

Offline darrell

  • Regular Contributor
  • *
  • Posts: 51
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #40 on: July 02, 2014, 04:04:57 am »
On Xilinx parts, the configuration clock is available after configuration. I have used it to get the real clock initialized.

Which one(s)?  CCLK is supposed to go tristate shortly after configuration from an FPGA in master mode.  For slave mode, I am not sure what CCLK from a Xilinx configuration PROM does, but I think that stops too.

Spartan 3E, 3A, 6 and 7 Series, at least. The pin does go tristate, but there is a primitive called STARTUPE2 (Kintex 7, may be some other variation on STARTUP for others) that provided the internal CCLK oscillator as an output.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #41 on: July 02, 2014, 05:39:19 am »
The funny thing is that the world is concurrent and everything we do is also concurrent. We are taught being sequential because it does have advantages but with the prevalence of multicore computing we are going to need to shift to more functional programming paradigms. Note that a lot of new functional languages are being developed and on the last 10 years old functional programming languages have gained a boost (like Haskell and Erlang)..

Here is a two part interview with Joe Armstrong (father of Erlang) 30 minutes each on his thoughts about concurrency.
http://channel9.msdn.com/blogs/charles/jaoo-2007-joe-armstrong-on-erlang-oo-concurrency-shared-state-and-the-future-part-1
Edit: this 2nd part goes more into FPGAs.
http://channel9.msdn.com/blogs/charles/jaoo-2007-joe-armstrong-on-erlang-oo-concurrency-shared-state-and-the-future-part-2

Btw an ATM exchange made by Ericsson running Erlang (the AXD301) supposedly achieved a reliability of nine nines (31.5 milliseconds/year downtime)

In these interviews he touches on the concept of Erlang running on FPGAs and some already to this.

Like this group uses them for correlating data from several remote radio telescopes with different packet formats to work as one in real time. One board with 8 FPGAs can process 16 Gbits/second in real time, and they claim the code was so easy to write that they were able to convince management to green light them.


Maybe there is not going to be a programming paradigm shift but I rather be ready so I can hit the ground running.
« Last Edit: July 02, 2014, 06:55:34 am by miguelvp »
 

Offline Kjelt

  • Super Contributor
  • ***
  • Posts: 6460
  • Country: nl
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #42 on: July 02, 2014, 08:00:48 am »
As a "micro-guy".  I just have not yet gotten what you do with an FPGA. 
Let me give it a try from another perspective a bit black/white but just to make it clear (for the example I do not include softcores in FPGAs because then you have another hybrid and the discussion would be less clear):

A microcontroller is a circuit that was designed to be flexible, dynamic, to be able to do almost anything depending on how you program it and able to change quickly with different programs, user scripts as you like. It was designed to be re-configured (running its code) on the fly.
The counterside to this ultraflexibility is that it is pretty slow, think of cycles in us (microseconds).

A FPGA is a fixed circuit that after being programmed performs (a multiple of) a single core functions, less flexibility but is able to do this task ultrafast, think of throughput of 5 to 10 ns (nanoseconds).

So to give you an example when you need a FPGA and can not use a microcontroller:
- continuously extract and output the audio stream from an incoming digital HDMI stream of 5Gbps.
 

Offline hamster_nz

  • Super Contributor
  • ***
  • Posts: 2803
  • Country: nz
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #43 on: July 02, 2014, 08:50:21 am »
Which one(s)?  CCLK is supposed to go tristate shortly after configuration from an FPGA in master mode.  For slave mode, I am not sure what CCLK from a Xilinx configuration PROM does, but I think that stops too.

Spartan 3E, 3A, 6 and 7 Series, at least. The pin does go tristate, but there is a primitive called STARTUPE2 (Kintex 7, may be some other variation on STARTUP for others) that provided the internal CCLK oscillator as an output.

Well, I just had to try it:

Code: [Select]
STARTUP_SPARTAN6_inst : STARTUP_SPARTAN6
   port map (
      CFGCLK    => open,       -- 1-bit output: Configuration logic main clock output.
      CFGMCLK   => test_signal,
      EOS       => open,         -- 1-bit output: Active high output signal indicates the End Of Configuration.
      CLK       => '0',          -- 1-bit input: User startup-clock input
      GSR       => '0',          -- 1-bit input: Global Set/Reset input (GSR cannot be used for the port name)
      GTS       => '0',          -- 1-bit input: Global 3-state input (GTS cannot be used for the port name)
      KEYCLEARB => '0'           -- 1-bit input: Clear AES Decrypter Key input from Battery-Backed RAM (BBRAM)
   );

I routed test signal into my frequency counter project's input (rather than using an external pin) and this is what I got:

Code: [Select]
...
053,153,413
053,154,512
053,155,198
053,152,184
053,152,781
053,150,509
053,150,583
053,151,034
053,151,486
053,148,068
053,148,444
053,146,664
053,145,952
053,146,836
053,143,573
053,142,675
053,145,679
...

The frequency looks to be temperature sensitive - the dip in the attached graph is when I warmed the FPGA with my thumb. It is about 5 minutes worth of samples
« Last Edit: July 02, 2014, 09:00:11 am by hamster_nz »
Gaze not into the abyss, lest you become recognized as an abyss domain expert, and they expect you keep gazing into the damn thing.
 

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8517
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #44 on: July 02, 2014, 02:17:42 pm »
Here is how i use FPGA's :

I have a machine that can play a digital pattern. This machine is stupid. It can only play the pattern from a begin point , to an end point and then go to an intermediate point and keep looping.
Lets say ot starts at line one, runs to line 1000 and then goes to line 500. It now endlessly runs from 500 to 1000 after which it jumps to 500 and so on.

I want to give this thing more intelligence. The machine itself cannot be altered. It is huge (a whole room full of 19 inch racks).
So i do the following : i create a 'compiler' for a software language that can create flat paaterns (loops etc need to be unrolled). I use one of the pattern bits as a clock bit, the rest is used as command/data.

I feed the pattern to an fpga. In there i create a bunch of logic that can decode these commands and take action. One such command is : test current and see of it is in side two boundaries.
The boundaries were set once in the non-looping part. When the command is requested a bunch of a/d comverters need to be read and checked against a min and max value.
These a/d converters hang off SPI buses.

Commands arrive at a rate of 1MHz. There are 32 ad converters that need sampling and comparison.

Let's try this with a cpu shall we ? First of all SPI has a limited bandwidth. The A/D converters can't be clocked much faster than 30MHz ... The SPI frame is 14 bit , looking at the pattern we need one clocktick to make cs low, then 14 clockticks to get the data and another tick to make cs high. 16 clockticks. So, if i want to be able to get the data from 1 convertor i need to be able to do this in 1/16 of a microsecond (remember new commands arrive every 1 microsecond without stopping ! So i need to be able to do this, guaranteed, in the given timeframe)

Using a cpu clocked at a hundred MHz i could do this no problem. For one channel. But there are 32 that need doing ... Even 4 or 8 channels become problematic for a cpu ...
So i created the spi interface in the fpga. The fpga spits out a cs and a clock to the a/d convertors. The data lines of the A/D are being fed back in parallel. So 32 serial streams are entering, each on a pin of the fpga. I get 32 readings synchronized in time back. 32 shifters in the fpga trap this and 32 hi/lo comparators against 64 registers (each a/d channel can have different hi and lo setpoints.) test this captured data in 1/320 of a microsecond (my fpga master clock is 320MHz). If an out of bounds is detected i kick of an interrupt to an external cpu. The cpu has access to the captured data stored as a chunk of ram. The cpu is unaware that the comtents of this ram are altered by hardware. The whole operation happens much faster than the cpu can even execute one instruction.

In short FPGA's are used to solve time critical, parallel problems in hardware. Doing things where a cpu would fail because it doesn't have enough time to do it. You create hard logic.

Practical examples : HD video playback. Many of the early plasma and lcd tv's were based in altera fpga's. Before the mass market custom chips were available this was the only way to play 1920x1080 .. Cpu's were too slow and the asics werent there yet. So we shove it in an fpga.

Another examp,e : take a look at foto_opa website. He makes pictures of insects in flight.
He uses an fpga to control two crossbeam lasers, focuse detection, shitterspeed calculation , flash delay calibration etc.  his system is self configuring. It takes a trial shot, establishes flash and shutter delay , and it is ready. If an insect flies through the crossbeam the fpga know, within 1 microsecond, what to fire and when to fire. A task impossible, even on the fastest cpu simply because the i/o is too slow and there are too many things to do that are time critical. A cpu needs to do a whole sequence of instructions , an fpga does it all in 1 clockcycle.
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline curiousbob

  • Newbie
  • Posts: 9
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #45 on: July 04, 2014, 03:40:18 pm »
For those knowledgeable in FPGA design:

When looking at a particular module/entity or even a larger design consisting of multiple modules/entities are you able to look at the rtl and quickly understand how it works and what is happening or do you find it necessary
to spend time dissecting it and perhaps simulating it in order to understand it and possibly customize it for your own needs?
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #46 on: July 04, 2014, 05:30:28 pm »
For those knowledgeable in FPGA design:

When looking at a particular module/entity or even a larger design consisting of multiple modules/entities are you able to look at the rtl and quickly understand how it works and what is happening or do you find it necessary
to spend time dissecting it and perhaps simulating it in order to understand it and possibly customize it for your own needs?

Will be the same as in C or C++, how many times do you resort to look at the generated assembly language and do you understand the assembly language generated without looking at the C function or C++ method?

With the added understanding on how an assembly op code actually works and what register flags are touched.

As far as the HDL code same thing, it all depends how it's written a monolithic module with nonsense variable names, poorly structured and undocumented will be as hard to understand as their counterparts in C or C++.

I only been using FPGAs for 6 months an change on my spare time so I have to lookup things every now and then because they have not become second nature just yet. But I have no problem understanding what a piece of VHDL or Verilog that others wrote. Even large projects since most tend to be very modular.
 

Offline hikariuk

  • Supporter
  • ****
  • Posts: 206
  • Country: gb
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #47 on: July 04, 2014, 11:04:38 pm »
For those knowledgeable in FPGA design:

When looking at a particular module/entity or even a larger design consisting of multiple modules/entities are you able to look at the rtl and quickly understand how it works and what is happening or do you find it necessary
to spend time dissecting it and perhaps simulating it in order to understand it and possibly customize it for your own needs?

Will be the same as in C or C++, how many times do you resort to look at the generated assembly language and do you understand the assembly language generated without looking at the C function or C++ method?

About the only time you look at assembly nowadays, ime, is when you need to get really greasy in a debugging session.  Or you really want to tweak the output of the compiler.

I suspect the vast majority of developers never look at assembly anymore.
I write software.  I'd far rather be doing something else.
 

Offline miguelvp

  • Super Contributor
  • ***
  • Posts: 5550
  • Country: us
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #48 on: July 05, 2014, 04:34:51 am »
Will be the same as in C or C++, how many times do you resort to look at the generated assembly language and do you understand the assembly language generated without looking at the C function or C++ method?

About the only time you look at assembly nowadays, ime, is when you need to get really greasy in a debugging session.  Or you really want to tweak the output of the compiler.

I suspect the vast majority of developers never look at assembly anymore.
And that was my point, no one needs to work at the RTL level.
 

Offline curiousbob

  • Newbie
  • Posts: 9
Re: EEVblog #635 - FPGA's Vs Microcontrollers
« Reply #49 on: July 05, 2014, 03:11:33 pm »
Writing code at the RTL (Register Transfer Level) level using an HDL langauge is the most common way to design... at least that's the impression I have.

With C/C++ you have a sequential order of execution and can follow a program as it executes in a certain order.

With FGPAs there is no "order" of execution. Everything runs in parallel. The order of written code has no bearing on order of execution.
This to me is what makes undertanding a module/entity more difficult than a C function. When a module/entity comes with written documentation, it is a lot easier to understand whereas a C/C++ function can be more easily understood with the embedded comments.
« Last Edit: July 05, 2014, 03:43:52 pm by curiousbob »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf