How to get up the learning curve efficiently (Zedboard, Arty, etc)

[DougM]

Hello,

I have not much FPGA experience, but a decent amount of microcontroller, board design, math, and silicon design in my background (I'm a physicist by training). 

How can I most efficiently get to the point where I can become competent with the Vivado/Vitus flow? Thanks in advance for any pointers.

I often have found (from other learning experiences) that a good way for me to proceed is to understand the basic concepts, implement/follow an example, and then grow from there with reference documentation to support new functions/features and help with the understanding and fixing of bugs.

I'm finding this unusually difficult with the Xilinx/AMD infrastructure, even though I've bought both a Zedboard and an Arty A7, and spent quite a bit of time on the endeavor. I have successfully implemented some designs (microblaze, small code examples, etc) but I am often running into frustration where I sometime am questioning whether the tools are at fault. Here's what I have found.

1. Examples, though appreciated, do not generally have much explanation of the "why" something is done, and how one might be expected to know that this particular IP block might benefit from this particular tweak, for example. 

2. The infrastructure is large, and tends to change. Examples and explanations become stale and broken rather quickly it seems. For example, the UI in Vitis 2023 is completely different. Maybe it's "better" by some metric, but it brings another significant barrier/overhead to a learning process. 

3. So far, I don't find the Documentation Navigator to be very helpful and a lot of the documentation is quite "Microsofty".  "to Spiffle a Splurge, select Spliffle->Splurge". Okaaay, but an explanation like that doesn't add much value.
For example, I just looked at "Zync-7000 SoC: Embedded Design Tutorial" which has the subheading "A Hands-On Guide to Effective System Design". Sounds good! It turns out to just be a one-pager saying that the tutorial is available on GitHub, and then gives a broken link...

 

 

So, I guess, I'm looking for a good book or set of explanatory articles, or even videos I suppose. I don't really want to go to formal training because, at this stage, it's hard to justify the time and I feel I ought to be able to make better progress on my own. 

As they say "Build a man a fire, and he'll be warm for an evening. Set a man on fire, and he'll be warm for the rest of his life".  I want to get to the point where I can debug my own problems more effectively.

Thanks

Doug

[asmi]

Your first order of business would be to become familiar with devices themselves. These FPGAs are at least an order of magnitude more complex than even the most advanced MCUs, and so the tooling is neccessarily complex too. So if you want to master these things, you'd better get ready for a lot of reading. First of all you will need to internalize that you don't "program" FPGA - but you design hardware. The HDL "code" you write is not "executed" (because there is nothing in FPGA which can execute anything), but it's used to describe hardware - so your HDL turns into real logic and real registers actually connected with a real wires inside the chip (if you open implemented design, you can actually see all of that). Then you can read about CLB (configurable logic block) in UG474, then some other blocks which are inside the chip - like block RAM (UG473), clocking resources (UG472), DSP tiles (UG479) and I/O buffers and logic (UG471). All these are the basic "bricks" with which you will build your designs. It's unlikely that you are going to remember all these guides after first reading, so keep them handy as you will be referring to them very often. There is also a configuration - which actually configures the FPGA to whatever is in your design, this is covered in UG470.

All of the above covers the "tools" you have at your disposal (I've intentionally omitted some more advanced blocks like PCIE, MGTs, XADC as they are are not used in all designs, while pretty much everything I mentioned above is going to be used in every design), but then there is another side to it - namely the "what" of designs. Meaning what exactly are you trying to achieve with your design. Here comes protocols, buses, interfaces - most of it is not specific to FPGAs, but these are things which you are going to be implementing using the tools I mentioned above.

As for pre-created IPs, they all perform a certain function, once you understand what exact function they perform and how (this is often covered in "Product Guide" for that IP), it will be easier to understand what configuration parameters do and why they are there.

[zygot]

Question" "How can I most efficiently get to the point where I can become competent with the Vivado/Vitus flow? "
Statement: "I want to get to the point where I can debug my own problems more effectively. "

Doug, I expect that you are looking for a variety of viewpoints regarding the two quotes extracted from your post.

Personally, I view Vitis FPGA development that contains either a hard ARM block or a soft-processor block as a different exercise than an all HDL design flow. A design that consists of 90% vendor IP connected in a GUI block connection format is also different than an all HDL design flow. So, I think that a useful response to your post depends on how you want to use the AMD/Xilinx tools, or the Altera/Intel tools, or any programmable logic vendor tools for that matter.

The above statement tells me that you are already an advanced student in FPGA development because you realize something that a lot of people don't; If you can't debug or understand the work product of your labors, then you aren't in a very good place.

The design flow preferred by FPGA vendors is is the Vivado board design, or the Quartus Platform Designer, where one connects vendor specific IP blocks together and lets the tool manage most of the work flow. This doesn't seem to me to be a good way to develop the kinds of experience and skills where one can develop competency in creating unconstrained logic that one understands and can debug efficiently.

Even if you become proficient at the HDL design flow, using no or minimal vendor IP, you still need to develop more sophisticated development/debug skills as the complexity of your designs grows. This is easier to do with the HDL design flow, but requires a lot more work. I've been doing programmable logic design for 40 years so I've created a lot of custom debugging IP and approaches to fit a lot of use cases.

But, your question isn't specifically about FPGA design flows... I'm reading it as more to do with the tools themselves.

The bad news is that the tools are constantly changing, and becoming more complicated, and buggier. If it's not the user interface of the hardware or software tools, then it's the syntax for constraints.. or some other aspect that makes life hard. If you you have old projects created in older tool versions they are broken in newer toll versions. If you are learning FPGA development and trying to follow example designs, or tutorials from earlier tool versions, then it's confusing because the IP or the tools have changed.

I use both Intel and AMD tools and devices using the HDL design flow and the least amount of vendor IP that I can get away with. In theory, implementing a design using nothing but VHDL or Verilog text sources on any device from any vendor should be easy, if not trivial. In practice this isn't even usually true for porting a design from one device to another device from the same vendor, or for the same device using different versions of the same vendors tools. That's just the way that it is.

Unfortunately, modern FPGA devices are complicated and there are a lot of restrictions in how the basic structural elements and resources of the FPGA can be used. Often you can ignore the subtle rules or limitations with simple designs, but have to deal with them in more complicated designs. Edited November 4, 2023 by zygot

[DougM]

On 11/3/2023 at 8:06 PM, zygot said:

But, your question isn't specifically about FPGA design flows... I'm reading it as more to do with the tools themselves.

The bad news is that the tools are constantly changing, and becoming more complicated, and buggier. If it's not the user interface of the hardware or software tools, then it's the syntax for constraints.. or some other aspect that makes life hard. If you you have old projects created in older tool versions they are broken in newer toll versions. If you are learning FPGA development and trying to follow example designs, or tutorials from earlier tool versions, then it's confusing because the IP or the tools have changed.
 

Thank you for the thoughtful reply. 

Indeed, you are correct, and my need for learning/practice/examples is predominantly around the tools. And, the source of my frustration is the tools... 

So, here's an example. I have implemented a simple hardware design (with IP blocks) and a simple C program running on the PS on my Zedboard and talking to Putty. (not much more than a Hello World. So far, so good.
Then I get "clever", and try to do some benchmarking of a simple FFT in software before then (more ambitiously) seeing if I could implement the FFT in the PL. Sounds like a fun Saturday night project (yes, I'm of a certain age....).

So, I drop in some C code for a simple FFT, #include math.h because I have a sqrt and some trig functions and, it won't build because of an undefined reference to sqrt. Okaay, I think, I'll make sure the math library is linked properly. Then the next few hours vanish in failing to figure out how to do that!! Good grief, it's discouraging... I have the usual skills of document reading and googling, but even the differences in minor revs of Vitus seem to be significant. (2022.2, in case you happen to know that answer to this).

Regards
Doug

[zygot]

Doug: "Then I get "clever", and try to do some benchmarking of a simple FFT in software before then (more ambitiously) seeing if I could implement the FFT in the PL. Sounds like a fun Saturday night project (yes, I'm of a certain age....). So, I drop in some C code for a simple FFT, #include math.h because I have a sqrt"

So, part of my reply to your post concerned the topic of "design flow". This is important because some design flows are more dependent on tools versions and support than others.

The design flow that is least dependent on a specific tool or device vendor is the HDL flow using no vendor IP. It's also the hardest to learn and requires the most work. Then, there's the IPI board schematic or Platform Designer method where most if not all "coding" is connecting vendor or user IP blocks. This can be useful for experimentation or prototyping but is ultimately very limiting to the user. And... vendor IP is here today, and gone tomorrow.. or is changed.

If you are "dropping" some C code to implement an FFT in the PL, this suggest that you are using the HLS version of the tools. Sounds promising, if you are new to programmable logic. Notably, HLS is a different tool than Vivado. I did experiment with it many years ago but soon dropped it as more of a curiosity than a serious design flow.

Ever since programmable logic left the PAL concept for LUT based implementation, the vendors have tried to make using their devices **appear** to be easier to use that they actually are. The NIOS was the first step, because it made an FPGA look like a micro-processor in terms of functionality, and everyone knows software development. But vendors aren't the only ones to do this. There have been many attempts, by third parties, to circumvent all of the FPGA vendor tool complexity. Notable are frameworks like LiteX and Migen. But many years ago a number of people created C-Verilog tools that would implement designs in BRAM. These efforts can have impressive "showcase" demo projects as selling points. But, do they make for a robust, general purpose design flow? I think not.

Since you have micro-controller design experience, you know that vendor tools are not quite the same as other tools designed for any target. You have to read the documentation, to see if the tool supports your requirements; that is if the documentation bothers to mention the topics of interest to you.

Personally, I view the HDL design flow as the only viable long term and robust way to do programmable logic. Even then I have to read the vendor support for VHDL, Verilog or System Verilog as it applies to synthesis and simulation. If you are doing any logic synthesis, then you also need to read the documentation for the architecture of the devices that you are using to understand its limitations and "personality". SOP..

The fact is... FPGA devices are very complex, and are designed to allow implementing almost unconstrained behavioral concepts. This is unlike a micro with a fixed architecture and set of machine codes. Within a small subset of design possibilities, HLS, IPI, or even MIgen have a place and might be useful for some purpose. They certainly have the potential to shorten design time and complexity for some endeavors. What they don't do is replace the most basic programmable logic design flow for demanding projects, or help the user debug problems, or help the designer conceptualize how an implementation works to the extent that is required.

For FPGA development and design your choices are:
A) the long, arduous, hard way
B) the (sometimes) quick, easy way

If all you want to do is tweak a demo project, or prototype a concept, then perhaps choice B is OK. Maybe. Your post suggest that, even as an intellectual exercise of investigation into FPGA design flows, choice B hasn't been quite the experience that the advertising has suggested that you should expect.

Many people have no interest in learning the details of programmable logic deign. They just want to abstract away the complexity of the devices and tools and do something useful. Intel and AMD have taken notice and have OpenCL type initiatives that work with really expensive boards and devices using PCIe in a PC. But, in the end these are just more levels of complicated scripts, tools, and supporting code, much of it proprietary and not available to the user, and subject to change at the whim of the vendor. Edited November 6, 2023 by zygot

[DougM]

12 hours ago, zygot said:

If you are "dropping" some C code to implement an FFT in the PL, this suggest that you are using the HLS version of the tools. Sounds promising, if you are new to programmable logic. Notably, HLS is a different tool than Vivado. I did experiment with it many years ago but soon dropped it as more of a curiosity than a serious design flow.

For FPGA development and design your choices are:
A) the long, arduous, hard way
B) the (sometimes) quick, easy way

 

Actually, I was still at the stage of simply running the C on the PS. Not yet trying to implement the algorithm in hardware. So, I was especially irritated/discouraged that something that shouldn't be too hard to achieve was such a headache.

My thinking was that I should be able to learn enough with option B (the easy way) to gauge the viability of a project and whether then I, or a "real" hardware engineer would take it on. In that event I was anticipating that option A would be required, at least to some extent. For example, measuring the speed of some processing without yet worrying about I/O, or even much verification of the results, seemed to perhaps be a plausible option B task. (Maybe it isn't...)

How practical it really is to use some amount of customized "drag-n-drop" of IP blocks is very interesting. For example, as I'm sure you know, in software the FFT is a classic algorithm, and there are well known routines that people *should* be using rather than rolling their own. Especially if they want to take advantage of some hardware properties of their machine. Why reinvent the wheel and just rediscover the pitfalls that were sorted out decades ago?  I would hope that, at least some, level of "drop-in" IP can be used without too many problems. Maybe this is unrealistic.  

Thanks for the discussion. I think I have some awareness of the size and complexity of the task of becoming actually competent within a family of FPGAs. But my goal is more modest for now and, I agree, it has been more difficult/annoying than advertised...

Doug

 

[zygot]

Doug: "My thinking was that I should be able to learn enough with option B (the easy way) to gauge the viability of a project and whether then I, or a "real" hardware engineer would take it on. In that event I was anticipating that option A would be required"

Nothing wrong with that plan. A lot of important work gets done "playing around", especially when it's done with a purpose.

Doug: " Why reinvent the wheel and just rediscover the pitfalls that were sorted out decades ago?"

You'll get no argument from me, at least on a philosophical level. In terms of cost, I've found that most of the time I can create my own IP that accomplishes the same functionality as vendor IP and with much lower resource usage. Plus I understand how it works. Sometimes resource usage isn't terribly important. In commercial practice it always is. Vendor IP just isn't available to implement the kinds of projects that I do. Implementing functionality in logic is very different than doing so in software, where compiled machine code can sit around in memory somewhere and be used in different contexts at run time.

As far as software goes. ZYNQ devices or even soft-processor-in-logic approaches can use the basic tool "OS" or some version of Linux. ( this is a simplification for discussion purposes ) For a ZYNQ platform, running Linux, you could use any third party ARM library to do an FFT. There are a myriad of hurdles however for such an approach.
- Running Linux on a Zedboard requires development on a Linux host PC and involves a LOT more work
- There aren't many FPGA boards that are well suited for supporting a large OS, plus user code
- ARM performance in an FPGA is much lower than, say, an RPi 4
- ARM implementations in FPGA devices aren't equivalent to, say a Broadcom uC in a RPi for which there is third party support for software development

FPGA vendors aren't going to promote the short-comings, limitations, exceptions, problems, etc. that comes with using their devices and tools. They know how hard FPGA development is. So, the only way to figure this out is to do what you've been doing; play around with a unique-enough application and see what happens.

One alternative development approach is, if you have a lot of money, the MATLAB framework. I think that you'll find this to be as problematic... just more expensive. Again, more levels of code that may make development easier.. or perhaps not. That's why companies have technical employees with specialized training and experience. Edited November 7, 2023 by zygot

[DougM]

Right, so "playing around with a purpose" has proven to be much less productive than I had hoped, hence the need to reset my expectations and get much more competent with the tools and documentation before that approach can be informative. 

For the application I'm interested in, I really don't think I want to be running Linux on the board. The real application needs to be fairly light on BOM cost and engineering support. I've used Matlab for decades and, briefly, pondered whether to use that infrastructure to help. In the end, though, I prefer to have as few layers of infrastructure involved as practical, for the reasons you allude to. 

I "feel" that a bare metal application (targeting Zync and so I'm playing with Zedboard) with some PL acceleration ought to be do-able for my application of interest. I'm trying to turn a feeling into informed opinion in my spare time.  Of course, I wouldn't be doing this if I wasn't also interested in learning more about the technology. 

So, with all that said, I'm still on the lookout for good learning materials, but since it's mostly the tools I'm struggling with, one might think AMD would provide them. So far, I've not been very happy. Do you know of a book or article that talks about Vitis/vivado from a conceptual standpoint, but still goes into some detail? 

cheers
Doug

Edited November 7, 2023 by DougM

[zygot]

Doug: "Do you know of a book or article that talks about Vitis/vivado from a conceptual standpoint, but still goes into some detail? "

Well, Vivado installs Document Navigator. It's the best way to find relevant datasheets, device and Ip documentation, application notes, tutorials etc. that are **hopefully** in sync with the version of the tools installed. There's a lot of documentation. FPGA vendors haven't been very good at keeping up with it. The tools are complex. I mean, Vivado 2022.2 uses about 140 GB of hard disk space once installed... and that is for a reduced device support options at install time.

There's always the Xilinx Wiki. Again, a lot of tool specific information and rarely content that you can implement without difficulty; but it is a learnng experience.

Tool version incompatibility has always been a huge problem for Altera and Xilinx. Even the vendors can't keep up with the changes. Recent versions of Vivado have been happy to write constraints for me, only for the tools to reject what the tool has just added to my constraint files because of syntax. It's a problem.

Once in a while I run into, in the internet, a cogent, well written write-up of how the author implemented a project in the tool version that I'm using that's informative and useful. Once in a while... So there's always hope and luck. I make sure to write down that author's name and save the url.

Currently, the former Altera and former Xilinx are owned by companies with no interest in programmable logic other than perhaps making their consumer CPU products "functionality as a paid service". I doubt that either company writes code for their tools in-house. In my experience, new tool versions bring new bugs, annoyances, and disappointment far more reliably than improvements. That, and having old project broken, and node-locked device licenses is why I rarely install new tool versions anymore. So one way to reduce the pain is to use a tool version that was released when the device that you are using was a hot new thing... if you can for your OS.

In one way, things have improved. Instead of quarterly updates and new device families every couple of years we now get one or two tool releases and many years between new families. I guess that one could view that as an improvement.... Edited November 7, 2023 by zygot

[DougM]

zygot: Currently, the former Altera and former Xilinx are owned by companies with no interest in programmable logic other than perhaps making their consumer CPU products "functionality as a paid service". I doubt that either company writes code for their tools in-house. In my experience, new tool versions bring new bugs, annoyances, and disappointment far more reliably than improvements. That, and having old project broken, and node-locked device licenses is why I rarely install new tool versions anymore. So one way to reduce the pain is to use a tool version that was released when the device that you are using was a hot new thing... if you can for your OS.
 

Well, that's depressing.... But, sadly, I see no evidence to suggest you're wrong.

Doug

 

[zygot]

Well, I don't want to be overly pessimistic. One possible ray of hope is that Intel has recently announced plans to spin off it Altera division.. though who knows what that will mean to product designers needing commodity level programmable logic.

Because FPGA devices have gotten so complex, and the tools so bloated and complicated and subject to constant change, it's just not realistic to expect to read a couple of articles or tutorials and create/develop/implement unique logic designs that are terribly useful, in a couple of weeks or months of part time effort Yes, you can replicate an IPI demo project that turns a concept into mainly a processor software effort... if you use the same tool version ( and with Quartus, perhaps the same host OS ). But then what do you do when you need significant changes in functionality?

Xilinx and Altera, for decades, had 90% of the programmable market. For the most part their tools have been designed mostly to exclude customers from switching vendors rather than provide real productivity for designers. In the 40 plus years of programmable logic, the best design flow is still the HDL flow, if you want as much control over your designs as possible. And, yet in all that time, no one has created a language or design framework that's complete. You can describe your concept to the synthesis tools but you can't provide constraints, implement vendor agnostic, device agnostic design elements that uses the various resources consistently. I think that the reason is that the major vendors don't want to design devices that meet standards or a common framework.. a concept that has defined electronics packaging and functionality for the past 50 years.

Even still, if you eliminate as much complexity a possible, that is use only the best version of the tools for your device, use one vendor to start, and put in the time to learn the basics ( HDL design, HDL simulation/verification ), exclude hard and soft processor based designs, there's plenty of opportunity ( for now ) to do some exciting FPGA projects. Edited November 9, 2023 by zygot