I want to apologize for the awful excesses to which you were exposed about which you were objecting on this blog. I was the first person to make a comment on getting started with FPGAs because it was a topic I was looking into myself, and I have certainly "done my share of embedded development" and specifically NOT using FPGAs (at least not at the current level of development) so I thought my "perspective" might possibly be useful in the discussion. It turned out that no one who was currently working at the state of the art in this field wanted to "waste their time with newbies and rookies" so they wouldn't even THINK of exchanging casual thoughts about the subject lest they reveal precious secrets about the internal workings of the "priesthood" to which they belong. You have to understand that in their world only the "blessed" are the ones to whom the arcane and mystical secrets of the inner workings of Vivado are revealed, and it is only the lesser of us mortals who are condemned to scratch out a subsistence existence with pathetic remnants of the art like ISE (whatever either of those are, I really couldn't care less). I would however point out about these "wizards" that I strongly feel that if the relationship in the following article by Martin Rowe is correct, they must certainly be working for free:
In deference to these folks and their expertise, to the extent it's possible I'll delete my previous posts on this subject, so in my absence we can see just how modest and unassuming these folks truly are. I apologize for thinking one of the "unanointed" like myself was worthy of commenting on this topic, so please accept my humble apologies for kicking off this blog. The calumny and viciousness you've observed would certainly not have occurred had it not been for my actions in the first place.
To be honest I find Vivado very easy to use, but then planahead / ISE is too.
The writing I have been doing over on Xcell Daily has focused more on the software side at the momenr so interupts, timers, watchdogs etc which is SDK based but it is important for people to understand how this all works and is intergrated trogether.
I have just emailed you something which I hope you will find useful
I have been writing on how to use the Zynq using the Planahead flow over on the now sadly defunct All Programmable Planet, this series of blogs will be reposted on EE Times starting this week I hope. They cover everything from getting it creating the project to adding peripherals, creating your own perihperal and adding a RTOS. I have also written a similar series for the Xilinx Xcell Journal starting with the January 2013 issue.
There is also a series of blogs over on Xcell daily blog that has focused upon using the Vivado flow. This again starts at project creation, adding perihperals, but has then looked at things like the interrupt structre, clocks and timers, bootloaders etc.
hi anon, as a fellow FPGA design engineer who just happen to pass by, I have to say, why are you wasting your time arguing with obvious amateur hobbyist. I'd stop after realizing he was complaining about JTAG and listing Atmel as FPGA vendor (what is this, the 1990s??).
FYI I worked for Xilinx, now works for a telecom equipment vendor as a FPGA engineeer. I know "a little bit" about FPGA.
Gentlemen (I assume you are all male, due to the high testosterone level vibes :)
I am new to electronics as a serious hobby, and would appreciate it if, when things get stormy, post-wise, you would take the acrimony offline. I have neither the time nor the inclination to wade through 'my ego is bigger than your ego' posts.
Good comments, Alvie, but I'm wondering about your subject line: "FPGAs are a commodity". According to Wikitionary, commodities are:
6. (marketing) Undifferentiated goods characterized by a low profit margin, as distinguished from branded products.
FPGA families each have their own strengths and quirks, making it hard to switch between vendors. The vendor tools are quite different, each with their own steep learning curves, which is another barrier for switching FPGA families. I don't know about the profit margins, but I suspect they're quite a bit higher than commodity MCUs.
In addition, FPGA design is still IMO regarded as a "black art", and many engineering organizations don't have in-house FPGA design capability. One one sense this is good for FPGA consulants, but it does mean that FPGAs are not designed in as often as they might be, which is bad for FPGA consultants. I sure hope they distribute magic wands and wizard hats at the upcoming EE Live! (formerly ESC) "FPGA boot camp".
I really hope you all had a new years day, things got a bit out of control last year - nothing a nice bottle nof champagne would not fix.
Now, back to the original post topic.
I do software for a living. Embedded software, usually even BSP and other weird stuff most programmers never heard about. Many things to consider, like multicore, multi depth caches, odd MMU/MPU systems, CPU/Coprocessor bugs, bad documentation, really odd accelerators, so on. Tough most of the time, but that is our job - to hide all of the HW peculiarities to higher level enginneers and programmers, so they can focus on what they do best: implement their algorithms.
And this is exactly where FPGA enters the show. Independently of implementing a softcore CPU on FPGA, or just have the FPGA implement accelerators (in a sense) and use external CPU, they do present an advantage over other, hardwired, architectures:
1) they are field reprogramable, so you can update them easily
2) they are relatively cheap
3) the design is faster than a CPU for specialized designs
4) they can be (some) partially reprogramable, and in runtime, which allows for efficient hw
aceleration of different tasks
5) they are cool (not thermally cool, unfortunately :) )
If you read this closely, you can see that there is no definite answer to FPGA usage. All depends on your requirements, and your need of hw design update.
I personally love them, but only advice their usage in specific scenarios.
I cannot say the same as hobby! I love them, and halfway my second CPU/SoC design. Why? Because i can, and because I enjoy doing so.
Side note for someone that said porting GNU tools is rather easy: do not believe them.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...