Upload configuration to Art A7 from Raspberry Pi 4

[ZiomoGorofil]

Hi all, 

I have to develop a PCB tester system, where Raspberry Pi 4 uses Arty A7 100 to measure certain voltages, drive some pins, etc. The problem is that some of the I/O of the Arty should perform different functions and be different directions depending of the PCB my system is testing. The two possible options I see is: 

- make majority of pins bidirectional, have one configuration on Arty (booting from the flash), and depending on the signals sent by Raspberry (via some protocol, SPI, I2C, UART) decide which I/O port to use and how. 

- have different configurations stored on raspberry and configure arty a7 depending on the module I'm testing. This is an option that I wanted to ask about.  

Is it possible to store configurations in form of bitstreams (generated on windows, vivado) and depending on module configure fpga by sending them via JTAG? (As I understand ARTY A7 can only be configured via JTAG or from Flash on the board). If so do I have to write my own protocol, and how can I know the structure of frame sent do ARTY via JTAG?

Or do I have to install vivado on raspberry linux to be able to configure it via raspberry? And if so is there a way to configure it programmatically by some sort of a script

 

Thanks, 

Ziomo 

[zygot]

It turns out that there's a version of Digilent's ADEPT2 utilities available for an ARM host like the RPI4.

You can also use the BSCAN interface to configure a Xilinx FPGA board using your own custom software application. Look over this project:https://forum.digilent.com/topic/17096-busbridge3-high-speed-ftdifpga-interface/

The latter option might prove to be more useful and easier to maintain in the end. The busbridge tutorial uses C# unfortunately, but the main idea is worth pursuing.

I'd recommend putting a lot of thought into how you expect your project will evolve and design a robust scheme before getting too far down the road. You don't want to spend a lot of time developing a scheme that works for a few iterations and then discover that you need to re-think your basic concept later. Edited December 5, 2023 by zygot

[D@n]

5 hours ago, ZiomoGorofil said:

Is it possible to store configurations in form of bitstreams (generated on windows, vivado) and depending on module configure fpga by sending them via JTAG? (As I understand ARTY A7 can only be configured via JTAG or from Flash on the board). If so do I have to write my own protocol, and how can I know the structure of frame sent do ARTY via JTAG?

Or do I have to install vivado on raspberry linux to be able to configure it via raspberry? And if so is there a way to configure it programmatically by some sort of a script

Yes, it is possible to store bitstreams on an RPi and then configure an FPGA from there via JTAG.  My 10Gb Ethernet switch project does exactly that.  We use the openFPGALoader tool to do the loading.

openFPGALoader -c digilent --ftdi-channel 0 toplevel.bit

There is no reason or need to install Vivado on a Raspberry PI.

Dan

[zygot]

Dan: "There is no reason or need to install Vivado on a Raspberry PI. "

NO one is going to install Vivado or even the Lab Tools edition that just includes the Hardware Manager functionality on a Raspberry Pi host.

[D@n]

17 hours ago, zygot said:

NO one is going to install Vivado or even the Lab Tools edition that just includes the Hardware Manager functionality on a Raspberry Pi host.

I've seen crazier things before--like the AF sergeant who instructed me to install a piece of PC/Windows software on a Sparc machine.  Much like I expected, it didn't work.  In this case, I'll wait for the forum request for help to arrive from the individual trying to install Vivado on an RPi before making such a declaration.  😄

Dan

[zygot]

Dan: "I'll wait for the forum request for help to arrive from the individual trying to install Vivado on an RPi before making such a declaration"

One doesn't NEED to try and milk a bull without knowing how it's going to work out ( unless it's an order from the sarge...)** I've had enough experience to know that software built for an x86 processor isn't going to run on an ARM processor even if you manage to find some virtualization software that runs on an RPi4. Now... if anyone wants to prove me wrong, then I'd be more than happy to be proven wrong.

** OK, I can see a couple of endings here ( none of which gets me milk for my cereal:
(1) really angry bull and lot's of pain
(2) a really large animal who wants to be my BFF

Trying to run Vivado on an RPi? That's just plain crazy talk... Edited December 6, 2023 by zygot

[BMiller]

17 hours ago, zygot said:

Trying to run Vivado on an RPi? That's just plain crazy talk...

It would be very nice, though, if the (TcL-only?) version of Vivado ran on the Zybo. And if it ran there, it would run on any ARM including macs! I understand that would require AMD/Xilinx to port it, but I don't think it's a crazy idea. The world is moving away from x86... and more advanced apps would rather not have to lug around (in, say, a robot) an energy-sucking x86 co-processor with their Zynq just to (re)configure a bitstream for DFX (or rely on cloud processing when typically in an RF-denied environment for that matter).

[D@n]

You are not going to get Vivado on an RPi.  There's no money in it.

You are more likely to get some other design tool, such as an open source Yosys+NetPNR or some such, to run on an RPi.  I know folks who have run the two on RPi to date, just not for Xilinx chips (yet).  I know because ... I've had to debug some of it.  (Welcome to open source, you get what you work for.)  While I doubt it yet works for Xilinx, you are more than welcome to roll up your sleeves and get to work at it.

Dan

[zygot]

BMiller: " It would be very nice, though, if the (TcL-only?) version of Vivado ran on the Zybo"

I remember, not all that long ago, reading a dismissive comment by Linus Torvalds about the ARM ecosystem. Never will be a viable platform for Linux.. in so many words. Boy was he wrong; I knew it when he said it, and this was before Apple transitioned from x86 to ARM.

I happen to like the RPI4 ( and if one every gets delivered to me an RPi5.. been waiting for over 2 months now ). But really, it just isn't designed to run something like Vivado. It's not just the ARM cores, or the limited memory, but also mass storage for an OS and user files. A SDcard just won't cut it. Forget about ARM code portability. There are alternatives to the RPi4, like the OrangePi with a M.2 SSD capabilities. Still, wouldn't want to install VIvado on that. Both of these ARM based controllers are much faster than a Z70xxx FPGA by a wide margin; even faster than an Ultrascale ZYNQ... I've done them all. The big problem is that once you try doing something interesting on these platforms you start running into bottlenecks. Like poor USB 3.0 data bandwidth. Like DMA bottlenecks. Even if you are only using CLI mode all of this congeals into system design headaches.

Personally, I prefer a cheap X86 Celeron based SBC like a X86J4125V2. Not that much more expensive, once you assemble all of the required hardware. It does have a 4-lane PCIe M2. port for connecting an FPGA board with PCIe, and a separate M.2 suitable for a SATA SSD, or if you like rotating storage a SATA port that can be directly connected to an SSD or HD. It's also in the same power dissipation tier as the RPI4-Rpi5. I have installed ( older versions of ) Vivado on that platform so that I can do everything that I need remotely. It's all about picking the right tool for the right job.

Fortunately, as I pointed out in my first post to this thread, you can configure a Xilinx FPGA board from an RPI4 using the ARM version of the Adept tools. Edited December 7, 2023 by zygot

[zygot]

BMiller,

There is no "tiny" version of either Vivado or the Lab Tools.

With Vivado, you don't need to ever bring up the Vivado GUI if you like writing TCL scripts to all project activities up to and including building a bitstream. You don't even need the GUI to configure a device. If you need to use the Vivado debug IP, like an ILA, then you need a GUI interface.

For professional work, TCL scripting is the only way to go. For short educational projects the GUI is generally quicker. I imagine that once you've created some TCL boilerplate one might want to avoid the Vivado GUI altogether. Unfortunately, given the bugs that always seem to be included in every Vivado release, I don't think that I'd want to do many designs without being able to open the GUI implementation deign views. If your organization has a few hundred FPGA engineers, all specialized to do one part of the development process, then you'd never use the GUI. If your organization has 1 employee, then adding layers of development might not be too efficient. Edited December 7, 2023 by zygot

[BMiller]

3 hours ago, zygot said:

If you need to use the Vivado debug IP, like an ILA, then you need a GUI interface.

Yes, I agree. I wasn't trying to diss the GUI use case, only that with just the scripts a lot of interesting stuff can be done by an autonomous system (which is my end-point use case) or essentially using the lab tools and remote (in my case, tethered) development. But looking ahead, how much longer will x86 be around? It's the IBM 360 in the age of VAX.

[zygot]

BMiller: "But looking ahead, how much longer will x86 be around? It's the IBM 360 in the age of VAX. "

Hmmm... I remember when the PowerPC was going to kill of the x86 architecture. Today there are adults that have never heard of a PowerPC, yet, like a bad cold, new x86 CPUs and a slew of captive supporting products are being released by two companies every year. Sigh!

ARM will one day be forgotten, as will us all. All hail progress, mystifyingly slow as it sometimes is.

I'm not sure that a analogy comparing a "big iron" mainframe like the IBM360 to something like a VAX holds up well once you start thinking about it. But I get your point. Edited December 8, 2023 by zygot

[D@n]

1 hour ago, zygot said:

I remember when the PowerPC was going to kill of the x86 architecture.

Yes, I remember that day well.  I remember taking a computer architecture course in graduate school and much of what we studied was the power PC.

My how things change.

[BMiller]

1 hour ago, zygot said:

I remember when the PowerPC was going to kill of the x86 architecture.

Hey I still have a G5 Mac... not that I use it for much anymore. I still think it's a better architecture than x86, but well, the Lisp Machines were better than anything else at their time too (early to late 80s) and possibly even today if they were commercially viable. Market and scaling kept piston engines from being replaced by the Wankel as well. (I miss my Rx7 too in case you want to detect a trend here.)

The Apple commercials for PowerPC were kind of hilarious though. I still remember the tanks defending the G4.

But if AMD really wants to insist on the superiority of x86 for hard problems, why isn't there yet a version of Zynq with x86 cores? I think we all know the answer to that.

@D@n might have the right idea: build open source tools. At least for smaller FPGAs the fancy algorithms needed to address the fundamental NP-Hard problems of route and place aren't as critical.

Sadly, I can only work on a few (one?) research problems at a time. I'll just spec smaller and more power dense batteries (utilizing fusion or maybe zero point energy) to make everything "practical" once it's tossed over the wall for commercialization. 😁