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

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

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

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

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

Hi JColvin, Well, while it was all fresh in my mind I tried to replicate my example using Vivado/Vitis 2021.2. I gave up after it became clear that the hardware manager in that version is unusably slow with the Arty. This appears to be a bug in the HW manager, as evidenced by a google search. I did not have the enthusiasm/time/real need to spend time on trying to figure out a work-around, or to install yet another version of Vivado. Thx, Doug

All is now working as expected. I, eventually, found how to properly configure SPIx4 at 50MHz and the board configures very quickly. For my next adventure, I may try to see if I can do the same thing with Vivado/Vitis 2022. I believe the SPI library is handled differently. Any pointers? Thx, Doug

Hi JColvin, Yes, I think your conjecture is correct. It's only Vivado that must be closed for the board to boot, so I suppose something in the hardware manager system is talking to the board. Now, I'm going to try to get the board to configure and load the application more quickly. It takes about 7 seconds to configure, which seems excessively slow. I think I may have the SPI bus width wrong because when I try to create an MCS file the system complains that the bit file is configured for SPIx1 not x4. This is odd, because the block design is clearly x4. Somewhere, something is goofed up. I think my brain must have different defaults than the designers of the user interface... I'm finding it quite hard to track things down! thanks, doug

And so, finally, it seems the board will boot without help if I apply power without it being plugged into the PC that's running Vivado/Vitis... doug

Well, I've got this working (mostly). I found the following guides quite helpful. https://shadowcode.io/microblaze-srec-spi-bootloader-hardware/ https://shadowcode.io/vitis-srec-spi-bootloader-software/ I still don't have the system booting without help on power-up. I have to press the "prog button" but the configuration and app are loading and running correctly. That's the next thing to track down. cheers doug

Hi Richm It's an Arty A7 board I'm using (hidden in the original post's title :) ), so I'd be implementing a Microblaze to get a processor. I do have the processor working, and I can get the FPGA configuration to load from flash when the board powers up, so I feel I'm close. JColvin's suggestion is also Vivado->Vitis->Vivado but, so far, I haven't got that working. I have experience of programming a board (Kintex 7) set up by another engineer, using an older version of the tools. In that system he creates two .mcs files, one for the FPGA configuration which includes a Microblaze, and one for the Microblaze app. I think the first .mcs file contains the bootloader that knows where to find the Microblaze app in the flash. I'll have to track him down and have him explain it to me. His explanation of how that goes together might be informative. Thx, Doug

Hi JColvin, Thanks for the reply. I *think* I understand how it's supposed to work, but so far I've not got the tools to make it happen... I've got to the point where I believe the hardware configuration loads from the flash, as proven by the LEDs lighting up in a pattern I set up in the hardware design. But, the Microblaze app doesn't run. I'll read the Forum thread you're suggesting. Thanks. In general, though, if Xilinx is not really being very keen to support applications like this, maybe I should be looking at other approaches, such as Zynq. I'd rather stay on the main "thoroughfare" rather than explore the back streets... Doug

Anyone??

Hello, I've got myself in a bit of a tangle in my attempts to get a configuration and microblaze app to load from SPI flash on power up. I'm new to Vivado, so there's a bit of a learning curve, for sure. I would love to find a step-by-step guide that not only explains *what* to do, but *why*. Though, at this point, I'd be happy to start with the direct what-to-do. Right now, I have a configuration and simple microblaze program that I can program from Vitis, and all is well. I'm struggling with adding a bootloader application. I'm getting errors with the bootloader overflowing the amount of memory available, even though I've increased the Microblaze's local memory to 32K. But, really, I'm in a bit of a tangle with platforms, applications, systems etc etc. At this point, I'd really like to scrape everything off and make a nice tidy fresh start... Any pointers are appreciated. I have found some guides, but they're mostly pre-Vitis and I may be making some mistake in translation. I'm using Vitis 2020.1. Regards Doug