Where To Start

[PapaMike]

Totally new to all this. 73 year old grandpa, retired engineer, returning to grad school, microelectronics concentration. Lots of technology catch-up to do. So, starting with VHDL. I must self-teach VHDL and need my first FPGA. Can someone help me understand these 3 possible choices for someone in my position: (1) Basys MX3 PIC32MX, (2) Nexys A7-100T, (3) Zybo Z7. Don't want to buy anything too complex, but I have to get the basics with ability to grow. Many questions about compatibility, accessories, programming... Can you help me get started?

[xc6lx45]

Very quick answer: If you want to learn FPGA, pick some entry level board and stop looking for shiny bits you could buy. That's the level ground before the learning curve even starts, don't waste any time there.

If you're disciplined, a few LEDs and switches will keep you busy for months or even years.

Just asking, have you considered Verilog? And BTW, "PIC" sounds like microcontroller, not FPGA.

[zygot]

Well to start the conversation I have a few comments.

First off gramps, I'm not that far behind you age-wise. I'm an electronics hardware Engineer forced into doing software engineering for a spell before software engineering was a thing, and have spent the last 20 years or so doing mostly FPGA logic design and board level development.

• I agree with the advice that  @xc6lx45 has just provided. Your two main options are the Intel universe or the Xilinx universe. I suggest sticking with the Xilinx universe for beginners. I also recommend ( I hate recommending things...) finding a cheap board from Digilent for the following reasons:
  • The Arty boards have a JTAG header and their proprietary Digilent JTAG interfaces work seamlessly with Vivado tools.
  • This web site offers some pretty good support where it's relatively easy to get questions answered
• Don't start with a ZYNQ based board as it just makes learning the basics more complex. Unfortunately, all new Digilent boards are ZYNQ based.
• Don't try and start with choosing a board that you can "grow into". Wait until you have the skills and desire to do a project requiring specific interfaces and then spend your money on a board that supports your needs. A few LEDs, buttons, switches and PMOD connectors will suffice until then. A basic Arty A7 board can keep you busy for a few years. Don't get fooled into thinking that you can't do very difficult and interesting things on a basic FPGA platform. Just ask @D@n.
• DO install Vivado and use the Document Navigator heavily. You need to understand the fundamentals of not only the devices but the tools that you will be spending a lot of time with. There's a lot of reading and preparatory work involved in doing FPGA development.
• I mostly do straight VHDL coding. I'm not a seasoned Verilog guy. I developed as a VHDL developer because that's what was required. I would probably suggest Verilog to new beginners based on a number of factors. I don't like the board flow using vendor IP from Intel or Xilinx. If you were a software engineer learning an HDL for synthesis might be challenging. There are some basic concepts that you need to master for FPGA development. Think if it as text based logic design.
• Learning how to do logic design on you own using an HDL is hard as I alluded to above. A big problem is that there aren't any good books about writing simulation testbench code and simulation is a fundamental part of the design process. This is a pretty good place ( the FPGA forum that is ) to get (usually) helpful advice and tips on figuring this all out.
• Start slowly and carefully using basic HDL constructs such as if..then..else, or concurrent, or assign statements until you've mastered them. Then add more of the syntax as your skills develop. There are some very subtle and important things to learn about HDL for synthesis as opposed to HDL for simulation. Before the FPGA vendors and the IEEE latched onto Verilog and VHDL as a design source flow these were simulation languages. Treating them as any other language will trip you up. This isn't software design.

I can't think of a better way to keep that brain of yours burning off calories than picking up a complex challenge like FPGA development. Even on a corporate level there are many that try and few that flourish doing it.

 

[PapaMike]

Some very good responses - informative, to the point, and helpful. What a pleasure to come across a forum like this. I think I see a starting point given your feedback. BTW - not new to software. I programmed on my first IBM 1620 in 1964 and PDP-11 in 1965. Hardware language is new, but not that difficult to understand with my background. Looking forward to more interaction as I expect to get lost in the weeds quickly. I picked up a book, "Digital Design", by Peter Ashenden. Only finished Chapter 2, so far, but for me a good book to learn VHDL.

[D@n]

@PapaMike,

Welcome to the forums, and welcome to digital design!

As @zygot mentioned, I have done a lot with an Arty board.  I also have the Nexys Video, and I'd recommend it for anyone interested in video.  I also share @zygot's criticisms of the SOC (Zynq) chips.  The tools just aren't really there to support them yet IMHO.  1) They require that you interact with your design components using a very complicated bus, one so complicated that both Xilinx and Intel messed up their demos.  (As of 2019.2, the automatically generated demos are still broken too.)  2) These chips very much depend upon on-board software/hardware integration.  Sure, I can understand why this might be a good thing--you can do more faster/better/cheaper if you can put the CPU on the same hardware as your logic.  It gives you an awesome high bandwidth link between the programming logic and the CPU.  It's also a very difficult link to debug.  Indeed, most of the help requests I've examined are from individuals trying to figure out how to debug a design where all the key details are under the hood.  Worse, as I just mentioned, 3) Xilinx's board design methodology tends to hide the bugs within your design in places where they become much harder to find, identify, and fix.

I've also slowly been building a blog based upon the premise that hardware debugging is hard, and very different from software debugging.  From what I've discovered, there are a lot of teaching materials out there that will teach you how to design hardware in VHDL or Verilog, but very few teaching materials that will teach you how to find or fix the bugs in your design.  I've therefore tried my hand at writing a tutorial that will go over not just design, but two basic debugging techniques as well: formal methods and simulation, while walking the student through a series of basic designs.  So far, the tutorial has been well received enough that I'm now working on a second tutorial on how to deal with designs that interact with some kind of bus.  Most of that tutorial has been focused on the Wishbone bus so far, but there is a lesson on AXI-lite and I expect more to come.

As for your PDP work, do you know that there are some PDP simulators on OpenCores?  Last I remembered, they'd been using the Artix-7 to emulate them.

There's also a very lively FPGA gaming community that's been resurrecting the ancient hardware game consoles.  I just haven't (yet) had the opportunity to get involved in that world--even though it sounds like a lot of fun.  I'd love to introduce my kids to Donkey Kong, Centepede, Crazy Climber, Moon Lander, and so much more ...

You should be aware there are other forums out there.  I really like Digilent's forums for beginners, but Xilinx has a forum as well.  The questions there tend to be more complex than those here, and the response rate seems to be much lower as well.  There's also an FPGA Reddit that may be worth looking into, and even an ##fpga channel on Freenode's IRC server that's fun to pay attention to.  There's often very good live discussions there, and plenty of people asking for and receiving help there real-time.  (Not always, sometimes you might have to wait 24hrs for a response ...)  There's also a lot of active development into building open source tools for synthesizing, placing and routing, and loading designs, so that's something you may wish to pay attention to as well.  I have yet to use those methods on Xilinx devices, but so far they've worked pretty well for me on Lattice devices.

Either way, welcome to the forums, and I look forward to hearing good things about how your design methodologies are going.

Dan

[zygot]

I still have Asheden's first release of that book handy as a reference for when I forget rarely used syntax. Even the latest version is probably not  up to date with the current version of VHDL supported by the tools. By the way an early puzzle to solve is determining exactly what parts of VHDL are supported by your versions of the Vivado synthesis tool. Finding this information used to be easier....  good hunting! For now it's not something to worry about. There are probably better texts dealing specifically with synthesis but I don't have any recommendations. For simulation you will use all sorts of statements not suitable for synthesis.

Early on the important thing is to get basic concepts down. Later, you can look through available code. One thing that is in common between FPGA development and standard software design are basic stylistic and procedural best practices. This is where learning from others code examples might engender bad habits. Again, you'll figure this out once you feet are on fima terra. 

PDP-11... wow, talk about unfriendly user interfaces. Not bad enough to induce PTSD but I'd rather not think about it. Not everything about the 'good old days' was good. But it sure did fulfill a purpose in its time.

Xilinx Series7 devices are quite nifty in most ways compared to earlier generations. An Artix 35T device is a lot more capable than many of the devices I've to used in the 'real world' for quite complicated products.

Oh, I did intend to say the for a software wired brain a few of the key things to get straight are the differences of the concepts of time, delay and concurrency between the two disciplines. Yes both have to deal with them but the differences might be subtle but vital to you progress. A programmable logic device,m whether an actual 'sea of gates' or LUT based is a blank page. Traditional 'software' deals with fixed architecture machine code even though it might be non-deterministic like the CPU in your PC. 

[D@n]

1 minute ago, zygot said:

Not everything about the 'good old days' was good.

 ? ? 

2 minutes ago, zygot said:

Xilinx Series7 devices are quite nifty in most ways compared to earlier generations. An Artix 35T device is a lot more capable than many of the devices I've to used in the 'real world' for quite complicated products.

An Artix-7 35T device has an amazing amount of logic on it as long as you 1) don't fill it up with the DDR3 memory controller, 2) a MicroBlaze CPU, and 3) an AXI interconnect, to the point where there's nothing left to play with.  Logic bloat is a real thing, and many of the example demonstration designs suffer from it.  While I used the DDR3 memory controller in the designs I have that require a DDR3 interface, it does require a sizable amount of the programming logic on the device in order to implement.  (20-30%% perhaps?  I don't have the number in front of me)

Dan

[zygot]

39 minutes ago, D@n said:

An Artix-7 35T device has an amazing amount of logic on it as long as you

This is a nice way to express my frustration with the way the the FPGA vendors hand their customers lots of rope to hang themselves with.

Please bear with me for a short, somewhat jaded, story.

I've done a lot of commercial and defense related FPGA designs. Only one used a soft-processor. This was for a start-up in which the end product was really an experimental machine. It became clear early on the way the the hardware, at least early on, was to be used would involve lots of short experiments with as little tur-n-around time as possible between them. Clearly, compiling a C program and downloading it to the hardware was going to be a few orders of magnitude less time than redesigning, simulating, debugging, and rebuilding configuration files using straight VHDL. My colleagues were using schematic capture but their FPGA designs weren't subject to radical changes. I decided to take a chance on the very first official release of the NIOS processor and its required 'board design' flow. NIOS started as an unofficial self-directed off hours project by one of Altera's Field Application Engineers (Anyone ever hear of those any more?) Eventually, the Altera marketing grasped the significance  what such a tool could be, and that didn't have anything to do with helping customers create better designs. First of all FPGA vendors have always been aware of how difficult designing and debugging with their devices are. A programmable core could hide most of the complexity and replace it with a drag and drop GUI design flow.Even today this hasn't changed. A soft-core processor and vendor IP had a lot more potential for profit margin. You could present an easy path to using their devices without actually having to learn logic design. Better yet your soft-processor and vendor IP would be incompatible with any competitors' core and IP. This locks most of your customers to your devices over time and prevents shopping around for the most cost effective device. You could provide your IP for free in an encrypted form ( see your friendly vendor provided free Ethernet IP ) or require a license fee to use it. Even better, your general purpose IP would guarantee to use up most of the resources of a small device and force customers into up-sizing to  a much more expensive one. And it would be their choice to go along with this! Wow, who could resist. Hence, MicroBaze, and for a brief period of time PicoBlaze. Eventually ARM convinced the vendors that embedding a much higher performance hard-core processor into their devices would be a great adjunct to the soft-core processor biz.  Of course the cost would be extremely flexible, logic resource hogging, and totally un-neccessarly complex AXI and AMBA bus IP. Life's grand, if your not the customer.  Of course there's no , non-profit motivated reason why an ARM hard-core processor can't have a very specific, very high performance simple bus connecting it to the programmable logic. But where would be the profit in that?

 

[zygot]

53 minutes ago, D@n said:

While I used the DDR3 memory controller in the designs I have that require a DDR3 interface, it does require a sizable amount of the programming logic on the device in order to implement. 

Here's an area where the old Spartan 6 family shines. I has a hard external memory controller block(s) greatly reducing the logic resource requirements to implement a DDR interface. This is why my good ol' ATLYS board still gets to do useful work on a regular basis. Most Cyclone V devices have hard external memory controllers available too. Of course your FPGA board vendor has to use the pins that allow their use. Obviously,  this 'frivolous' feature on those families didn't impose sizable cost burdens on producing those devices. So why can't the Artix family have those. I guess that you have to ask the vendor Marketing people.

[PapaMike]

Any thoughts on simulators? I started by downloading the student edition of ModelSim PE. Yeah, it's free and I know you get what you pay for. But I'm out here alone starting from scratch with a limited budget. ModelSim at least allows me to see what my VHD code looks like and start working on basic syntax and structure. At some point, however, I will need to know if my code actually does what it's supposed to do. I must admit, @D@n's post on debugging scared the ... out of me. But onward...

[D@n]

@PapaMike,

There's a whole world of open source support out there, to include simulators.

If you really want to stick with VHDL, you might want to look into ghdl.

Beware, though, there's a lot of bugs that won't manifest in simulation at all!  You can read about some of the ones I've missed here or even here again.  For these reasons, I've switched to using formal verification for most of my (initial) bench testing needs.  There are free formal verification tools out there, but the open source VHDL support is still pretty new.  I use Verilog, and I've loved it.  Oh, and if you use Verilog, you can get access to the fastest simulator on the market.  (Just don't tell @zygot I'm recommending a cycle-based simulator.)

Here's my favorite list of (mostly) open source tools that might help get you off the ground.

Dan

 

[zygot]

1 hour ago, PapaMike said:

Any thoughts on simulators?

Vivado simulator is fine. You can get a free copy of ModelSim with the free version of Quartus. ModelSim needs compatible libraries so yo9u aren't going to simulate Artix block ram with an Intel versio of ModelSim. I use both as I design for devices from many FPGA vendors. The ISE version of ISIM is better in that it lets you view the contents of simulated memory. For some reason Vivado never got around to supporting that. I recommend that you start with Vivado simulator. Don't let Vivado trick you into thinking that it can simulate your toplevel RTL entity and hierarchical code. You need to create a testbench which will be your simulation toplevel file, Vivado simulator knows about Xilinx macros, resources and IP so it should be your first choice. The best practice method is to write hierarchical code and a testbench for each entity. Don't try and put too much functionality into one module or source file. Same idea as in writing software. You might have to fight with Vivado doing this because it wants to figure out the heirarchy for itself and gets confused if your toplevel has syntax errors. I also has a hard time with a lot of testbenches in one project. In this regard ModelSim is more sensible.

Dan and I don't see eye to eye on the topic of simulation. In general diversity of opinion is a good thing but I will tell you that I've nver worked anywhere as an employee ro contractor that used his methodology. He also is a Verilog guy. Verilog is actually better at doing simulation and if you want to simulate a lot of Xilinx IP, especially MIG external memory controller IP, you need to be using Verilog. Period.

Not sure what exactly what is causing anxiety about simulation. Both of us would agree that it's a key part of design. I have some simple designs in the Digilent Project Vaultr with some very simple testbench code that you can load into Vivado and see working right away. Start here: https://forum.digilentinc.com/topic/4348-a-uart-based-debugger-tool/

There are others. I haven;t posted my best testbench work but the simple examples are a good start. You will see all kinds of VHDL statement that can't be synthesized... and that;s fine. VHDL is a simulation language co-opted for synthesis.

1 hour ago, D@n said:

Beware, though, there's a lot of bugs that won't manifest in simulation at all! 

Well, I'd qualify that. Vivado simulator has been known to just provide nonsensical results in response to some types of errors. By nonsensical I mean that you can change the soruce, re-compile the simulation and still get previous results. Vivado simulator will also let you know if you are violating a rule for using IP or hard resources, assuming that you bother to read the messages. A problem with Vivado simulator is that it compiles executable code in order to speed the simulation. This has some nasty side-effects on occasion. If Vivado simulator starts telling me things that I know aren't true then I just close it down and restart it. This usually results in a compi8le failure and a path forward. Xilinx isn't a shining example of good software development prowess. This is how it's usually done in industry unless the company has the money to spend on  Simplicity or other tools.

If you're curious, Dan is the smart one and I'm the one who's been doing this for a living for a few decades at a lot of companies in a lot of markets. But Dan is a quick study, so he'll get it right at some point in the near future.

The hardest part of simulation is figuring out what need to be simulated... oh, and testbench code is code so it need to be debugged too when it get complex.

 

 

[zygot]

1 hour ago, D@n said:

Oh, and if you use Verilog, you can get access to the fastest simulator on the market.

Yeah, and jumping out of the 10th story window to get to the street is way faster than taking the stairs but you get to live longer the slow way. Cycle based simulators have their place. I'd say 4th or 5th if the normal tools are taking too long and wasting hard disk space... but then you could re-write your testbench and still not have to go there. I've never seen an actual company that used FPGA devices for a living use a cycle-based simulator for FPGA verification.

Formal verification methods are an adjunct to the verification process not a replacement.

As I keep telling Dan, if you become an expert with the normal simulation flow and still feel that there must be a better way then fine, God be with you. If the only tool that you know is one that isn't within the bounds of industry standard practice then perhaps you should expand your experience. 

The truth is that regardless of what poison you pick verification is difficult to do well and is a bit if an art form. That's my story and I'm sticking to it.

My advice is: use Verilog, forget about the fastest simulator on the market until the correct simulator tools aren;t cutting it for the odd project.

[PapaMike]

Would love to get @zygot and @D@n in the same room for a simulator face-off! ?

[zygot]

17 minutes ago, PapaMike said:

Would love to get @zygot and @D@n in the same room for a simulator face-off!

Yikes!

Actually there are way more things that we agree on than not. You've been around the block a few times, so to speak. So, you know that when faced with conflicting advice on a topic you know to mark that as one deserving particularly careful study and effort. At the end of the day you have to live with and adapt to you own choices. It's never a bad idea to be open to putting aside cherished beliefs when evidence suggests exploring a different viewpoint. 

It's unfortunate that there isn't a lot of useful information available in texts or published material dealing with this topic.  I'd suggest that if there's one thing that technical companies want to protect even more that their design intellectual property might be their verification and production methodologies. Sometimes the little secrets that separate success from failure aren't in the design documentation or sources.

One good source of ideas and usually good HDL code examples is in the form  of Application notes and supporting project sources. Sometimes these contain examples of testbench code for study. Don't be afraid to use any vendors reference material. A really good testbench for a complex interface really does start looking like software, at least in terms of construction and style.

[D@n]

@PapaMike,

@zygot has just reminded me that there's less space in between our views than you might imagine.  I actually have a mental note left over from our last discussion that I want to sit down with him and learn some more on this issue, so I really need to wait for that conversation.  Perhaps once this virus passes we'll have a chance to share a glass at some table again.

Either way, we're both grumpy old men who are just completely tickled pink that someone's willing to listen to us.

13 hours ago, zygot said:

The truth is that regardless of what poison you pick verification is difficult to do well and is a bit if an art form. That's my story and I'm sticking to it.

"Verification is difficult to do well" is something I'm reminded of every time I end up chasing a design bug in hardware.  It happens more often than I want to admit, although I've found that for some strange reason folks like listening to my stories of all the bugs I've ended up finding after the fact.  Perhaps we should just chalk it up to the fact that kids all like to hear good "war" stories from those who've gone before them.

Dan

[zygot]

3 minutes ago, D@n said:

Either way, we're both grumpy old men who are just completely tickled pink that someone's willing to listen to us.

Either way, we're both grumpy old men who are just completely tickled pink that someone's willing to listen to us.

[PapaMike]

Just a final word. It's been less than 3 weeks since I joined this forum and asked my first question. I am writing to complement both D@n and zygot for their excellent responses and advice. I purchased the arty-a7-35 and have already completed several very simple applications. Could not have gotten here this quickly without your help. Thanks a million.

[zygot]

Enjoy the ride! There's plenty of open roads to explore out there in FPGA development land, and I usually find the journey as rewarding as making the destination.

[ForgottenDan]

Well I just wanted to say that @zygot's links and feedbacks were very helpful for a newbie like me. Thanks

[zygot]

@ForgottenDan, thanks for the encouragement. Everyone who posts answers to questions on the forums wants to be helpful. Sometimes we fail to understand the issues. Sometimes we provide answers that aren't all that helpful. Sometimes we provide answers that we think are helpful but isn't what the questioner thinks is helpful. It's nice to know that every so often our answers are well received. There's no point at which anyone can say, " Well I conquered FPGA development, there's nothing left to learn and there's no room for improvement".

I always try to provide answers to posts with the expectation that lots of people other than the person asking the questions, and at different stages of learning, are reading them. Your comment reinforces this idea.