Zynq - When does it become useful?

[tnkumar]

I currently have an Arty S7-50 board and have started learning FPGAs about a month ago.

When I browse for FPGA tutorials, I come across Zynq quite often.

When is it useful to have a Zynq board to learn FPGAs? or is it good enought to continue with Arty S7-50?

 

 

[zygot]

My opinion is that for someone just starting out learning about FPGA development should start with a board just like yours. FPGA devices with an embedded hard ARM complex just adds to the complexity... and there's plenty of complexity for a beginner in programmable logic to master.

A very small percentage of my projects involve a processor in the FPGA, whether a soft-processor like MicroBlaze or a hard processor like ARM. At some point you need to be able to create you own IP and designs that are FPGA vendor agnostic. And even if you are targeting a ZYNQ ir the like, you will need to have good logic design experience. Trust me, the Arty can keep you busy for a very long time honing those skills.

I think that a lot of people ( especially those who work for ARM Holdings ) see the ZYNQ as a microprocessor with some FPGA logic attached. I see it as an FPGA with an attached, relatively high performance microprocessor. A lot of my projects are just that... one or more FPGA devices that communicate with a PC or SBC via PCIe or USB 3.0. This can usually provide more processing horsepower and flexibility than an ARM based FPGA. Software development is easier as well. My ZYNQ projects usually require two software projects; one for ARM and one for a PC. If you are building a small embedded system then ZYNQ is a pretty nice way to go.

Put off the ZYNQ platform until you have mastered logic design verification and debugging. When you need to use an ARM-base device you will be in a much better place to do so effectively.

[JColvin]

I concur with what zygot said. If you are wanting to be using an embedded system on a board that doesn't communicate with a host PC and use some of the various turnkey offerings, then a Zynq based board will work.

Zynq is used often in tutorials since things like the various drivers for different peripherals that are used by the processing system are already conveniently designed for you, which can speed up development work when you are just wanting to prototype or get some sort of design done and you don't want to make/have the existing material already. The caveat with this of course is that your modification and fine tuning options will be limited. Like zygot mentioned though, it won't excuse you from not knowing how to do logic design.

If you are wanting a microprocessor as just a little computer to do some processing and you don't plan to do a lot/any of development, you'd probably be better off looking at something like a Raspberry Pi, if only for the wallet friendlier price point.

Thanks,
JColvin

[zygot]

I should add that one thing that you can't do with an Arty A7 is experiment with advanced IO features. A board like the Nexys Video solves that but is expensive unless you are ready to take on design challenges requiring some degree of FPGA development expertise. There are cheaper boards to do this. My feeling is that one should make FPGA board purchases based on the requirements of the project that you want to execute. But for a beginner, I'd say that you the Arty A7 is plenty capable of allowing users to learn the tools and basic logic design.

[tnkumar]

16 hours ago, zygot said:

My opinion is that for someone just starting out learning about FPGA development should start with a board just like yours. FPGA devices with an embedded hard ARM complex just adds to the complexity... and there's plenty of complexity for a beginner in programmable logic to master.

A very small percentage of my projects involve a processor in the FPGA, whether a soft-processor like MicroBlaze or a hard processor like ARM. At some point you need to be able to create you own IP and designs that are FPGA vendor agnostic. And even if you are targeting a ZYNQ ir the like, you will need to have good logic design experience. Trust me, the Arty can keep you busy for a very long time honing those skills.

I think that a lot of people ( especially those who work for ARM Holdings ) see the ZYNQ as a microprocessor with some FPGA logic attached. I see it as an FPGA with an attached, relatively high performance microprocessor. A lot of my projects are just that... one or more FPGA devices that communicate with a PC or SBC via PCIe or USB 3.0. This can usually provide more processing horsepower and flexibility than an ARM based FPGA. Software development is easier as well. My ZYNQ projects usually require two software projects; one for ARM and one for a PC. If you are building a small embedded system then ZYNQ is a pretty nice way to go.

Put off the ZYNQ platform until you have mastered logic design verification and debugging. When you need to use an ARM-base device you will be in a much better place to do so effectively.

Thanks @zygot for your perspective. Very helpful

[asmi]

I can think of two scenarios when using Zynq is justified: 

1. When you want/need to run Linux. This usually happens when you need to use complicated driver/software stacks like USB, Ethernet or PCI Express and want decent performance while doing that (if performance is not important, you can run Linux on Microblaze as well). This also has some benefits in a sense that you can develop and debug your userspace software on a desktop Linux system, which of course is much easier and more efficient than doing it directly on a target board, especially if that application need to have a rich graphical interface.

2. When you need to have some sort of processing on a CPU which exceeds what Microblaze can do. Zynq CPUs can be ran in the bare metal mode too, and they can provide quite a bit of computing horsepower.

Edited December 15, 2021 by asmi

[zygot]

There really aren't a lot of things that you can't implement in logic without a processor that you can implement with one; provided that you have the development skills. There are clear advantages to building products with no processor software. There are occasions when a processor embedded in your logic makes sense. In my experience that hasn't been very often.

[jb9631]

I'm from the school of thought that uses microcontrollers, since they're cheap, low power, simple to program, simple to debug. We, perhaps unfairly, avoid FPGAs whenever we can, despite having had some practice with HDLs (I remember starting out with Spartan 3). When we cannot, it means we're dealing with a data stream or data processing too fast or too accurate for good old PICs or ARMs. For the workflow we're taught (literally, this stigma against FPGAs comes from school, or more accurately, university, where the entire staff agrees with this sentiment), it makes sense to only use the smallest/cheapest FPGA/PLD we can get away with, then deal with the rest of the application in the microcontroller as per usual. That's the opposite end of the spectrum for you. :)

For what it's worth, I've worked with Zynq in the form or the RedPitaya. The Linux functionality is nice, but in my opinion prohibitively expensive, and unnecessary unless you _really_ need Linux. A soft core or an additional microcontroller chip are much less expensive, and sufficient for most projects, in my opinion. I suppose the benefits and ease of integration might outweigh that cost (though it is of course difficult to transfer this price increase to the end user).

[zygot]

I have a Red Pitaya. It's a interesting platform but I use it only as an instrument... on occasion. I really don't do a lot of ZYNQ designs, though a good portion involve a PC or SBC.

The ivory tower isn't the only place where FOPL ( Fear of Programmable Logic ) exists. I've run across many a company that tried, and failed at using FPGA devices for product design, development and production, It's basically a failure to adapt and abandon old habits.

I started my Engineering career before FPGAs, before PLDs, before the first PAL. Yeah, the first company that I worked for had the mighty MC6800 1 MHz processor, but most of the design I did was strictly LSI/MSI board logic using hand drawn schematics and manual analysis. It's quite impressive what you can do with crude building blocks. Of course there were limits... there still are even with the best of the most expensive components.

I've had to adapt to stay alive, but sadly,  many companies and teaching institutions have managed to avoid that... and are stuck in the past. I'm the first one to admit that FPGA logic design ain't easy.... but I've also done enough low level software development to know that software design is plenty hard to do well too.

Yeah, my perspective is not typical. Perhaps, that's a good thing. I bear no grudge against those with a different perspective. Sometimes what works well based on historical biases is sufficient... sometime is isn't and you have to migrate to a new paradigm. It certainly can't hurt to be somewhat knowledgeable about all available technology. It does take a commitment in time and money to invest in adapting to the unfamiliar.

BTW I remember when programmable logic was in the state where the mindset that you describe was almost universally correct. There's still a place for it pf course, but I suspect that it applies to a smaller range of endeavors. There are certainly wrong ways to do things, sub-optimal ways, and optimal ways. Each is driven by a number of factors.

"Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats." -- Howard Aiken

Edited December 15, 2021 by zygot

[asmi]

4 hours ago, zygot said:

There really aren't a lot of things that you can't implement in logic without a processor that you can implement with one; provided that you have the development skills. 

Well, try implementing a USB 2.0 Host controller with support for anything under the sun from keyboards and mice to USB flash drives and video cameras using only logic. You will likely spend a lifetime doing that, and you probably won't be able to fit it even inside very large FPGA. While going for a software solution is going to be heaps and bounds more efficient.

Same goes for other major software stacks - like PCI Express Root Complex for example. It also will need a separate logic to handle any kind of device you might want to plug in. While with Zynq-015 and Linux all it takes is to tick right checkboxes in the kernel configuration. That's how I was able to prototype a system with support for USB 3.0 thumb drives and 2.5G Ethernet all on the same board.

So while I agree that using in everywhere is not a good idea, there are many-many projects where it's indispensable.

[asmi]

4 hours ago, jb9631 said:

I'm from the school of thought that uses microcontrollers, since they're cheap, low power, simple to program, simple to debug. We, perhaps unfairly, avoid FPGAs whenever we can, despite having had some practice with HDLs (I remember starting out with Spartan 3). When we cannot, it means we're dealing with a data stream or data processing too fast or too accurate for good old PICs or ARMs. For the workflow we're taught (literally, this stigma against FPGAs comes from school, or more accurately, university, where the entire staff agrees with this sentiment), it makes sense to only use the smallest/cheapest FPGA/PLD we can get away with, then deal with the rest of the application in the microcontroller as per usual. That's the opposite end of the spectrum for you. :)

That only gets you so far. What if you need a high-bandwidth link between your CPU and a FPGA? Or if you want your FPGA design to be able to DMA into and from CPU memory, or have CPU access the memory connected to FPGA? In all those cases Zynq will be a superior choice. One chip is always better than two - smaller (==cheaper) PCB, less power consumption, easier to route and assemble. Then lower Zynqs have another subtle advantage is that they come with 32 bit 1066 MT/s DDR3 memory controller, while regular Artix/Spartan FPGAs can only go up to 800 MT/s (Artix-7 speed grade 3 can go to 1066, but it's very expensive and hard to source even in better times than what we currently live in). Interestingly, for 030 and above the situation is reverse - PL is capable of going as high as 1866 MT/s, while hard memory controller can still only do 1066.

Also, Zynqs are often used to create accelerators, when you profile your code on a Zynq and then replace the most time-consuming functions with their hardware implementations. You can even use Vitis HLS for that, eliminating a need for any HDL coding.

Does it mean that they are a silver bullet for all designs? Of course not, in fact the vast majority of my designs (both commercial and personal) were just fine without it. But I wouldn't dismiss it right off as well - sometimes they are the best solution. At the end of the day, they are just another tool in our toolbox, so it's good to learn it in case you need it some day.

Edited December 16, 2021 by asmi

[zygot]

21 minutes ago, asmi said:

So while I agree that using in everywhere is not a good idea, there are many-many projects where it's indispensable.

You're not going to get a counter argument from me. There's only one universal rule that covers all electronic development: There are no rules that dictate all electronic design and development.

[zygot]

45 minutes ago, asmi said:

That only gets you so far. What if you need a high-bandwidth link between your CPU and a FPGA? Or if you want your FPGA design to be able to DMA into and from CPU memory, or have CPU access the memory connected to FPGA? In all those cases Zynq will be a superior choice.

I find that point interesting as it is the reason why I've been spending time on alternatives to ARM based FPGA devices. Currently my preference is an ODYSSEY-X86J4105 connected to a non-ARM base FPGA board via 4 lane PCIe. Even an old Cyclone V can DMA data into the ODYSSEY memory at about 2 GB/s. I don't have to struggle with Arm specific libraries and tools for software application development. No doubt that an UltraScale+ device might be capable of similar data rates, but not so much as to overcome other considerations. ZYNQ might be superior for some applications but not all.

 

45 minutes ago, asmi said:

One chip is always better than two - smaller (==cheaper) PCB, less power consumption, easier to route and assemble.

Not sold on that idea.

45 minutes ago, asmi said:

Zynqs are often used to create accelerators, when you profile your code on a Zynq and then replace the most time-consuming functions with their hardware implementations. You can even use Vitis HLS for that, eliminating a need for any HDL coding.

I have no real experience with HLS so I can't state an opinion. Do you have a real use case that showcases the HDL free FPGA application flow that you can share? I still remember when FPGA vendors tried using C as an alternative to the HDL flow. Seems like a curiosity more than a robust development flow to me.

As for FPGA based accelerators, it's quite apparent that both Intel and Xiinx has put a lot of effort into exploiting that market niche, in the form of PCIe cards for PCs. Isn't this what Vitis is all about? It's kind of like my ODYSSEY/FPGA board setup, but for people with a much higher budget.

But your conclusion to that post isn't something that I'd want to argue against. Every project has its own needs and prioritized specifications to meet and countless other considerations like component availability, alternate component sources etc. Usually, there is more than one way to do a adequate job completing it. These days, if I buy a product that the manufacturer did an adequate job designing and building I'm feeling pretty lucky... unless the product turns out to be a permanent sales platform in disguise... like the car i'm driving. Time is often the over-riding specification. I'm sure that there have been projects that took long enough to be obsolete from the project kick-off to when a product was ready to manufacture in quantity.

Anyway, as interesting as this discussion is, it's left the orbit of the original post... sorry for that tnkumar..

Edited December 16, 2021 by zygot

[asmi]

4 hours ago, zygot said:

I find that point interesting as it is the reason why I've been spending time on alternatives to ARM based FPGA devices. Currently my preference is an ODYSSEY-X86J4105 connected to a non-ARM base FPGA board via 4 lane PCIe. Even an old Cyclone V can DMA data into the ODYSSEY memory at about 2 GB/s. I don't have to struggle with Arm specific libraries and tools for software application development. No doubt that an UltraScale+ device might be capable of similar data rates, but not so much as to overcome other considerations. ZYNQ might be superior for some applications but not all.

PCI Express has insane latency compared to AXI HP bus available for Zynq. It also requires, well, actual PCI Express host, while Zynq solution is self-contained on a single chip. Zynq DDR3 controller peaks at a bit over 4GB/s, which is enough for a lot of applications. If your design need more, you can add another memory controller in PL, but I suspect that fabric speed will become a limiting factor somewhere in that area. You can step up to Zynq-030, which sports faster Kintex fabric and can implement 933 MHz DDR3 controller, which will give you all the bandwidth you'll ever need, and you can set up your design such that ARM CPUs will have access to part (or all) of that memory as well as that of the hardIP side - the limiting factor here is address space, but this can be side-stepped by banking.

4 hours ago, zygot said:

Not sold on that idea.

Seriously? External board with PCIE and a PCIE card with FPGA is cheaper/better/easier than just a single chip?

4 hours ago, zygot said:

I have no real experience with HLS so I can't state an opinion. Do you have a real use case that showcases the HDL free FPGA application flow that you can share? I still remember when FPGA vendors tried using C as an alternative to the HDL flow. Seems like a curiosity more than a robust development flow to me.

I don't have any commercial experience with it myself, but some of my customers did some designs on a board I built for them, so my experience is only anecdotal. That said, these customers were super-happy with results, with the main advantage being time to market, so there is definitely a place for it. Again, yet another tool in our toolbox to learn about so that we can use it when a need arises.

4 hours ago, zygot said:

As for FPGA based accelerators, it's quite apparent that both Intel and Xiinx has put a lot of effort into exploiting that market niche, in the form of PCIe cards for PCs. Isn't this what Vitis is all about? It's kind of like my ODYSSEY/FPGA board setup, but for people with a much higher budget.

That is one possible use case, but Vitis HLS basically produces IP blocks that can be connected to any other logic in Vivado, you can use them even with pure FPGAs like Artix. HLS is great for stuff like advanced math, FFT, image processing via OpenCV, as Xilinx includes a library of these functions ready to be used in your C/C++ code, allowing for extremely fast iterations - as you can debug your code as a regular C/C++ application, with compilation being pretty much instant, and only move to hardware once you've ensured that your code works properly - and even here you can use the very same C/C++ testbench you used to debug your code, to run a co-simulation to verify that generated core still works properly.

If you are interested and have some time, I recommend you to watch the following YT playlist: https://www.youtube.com/playlist?list=PLo7bVbJhQ6qzK6ELKCm8H_WEzzcr5YXHC They are one of the best video tutorials I've seen on this subject, even if they are a bit dated.

Edited December 16, 2021 by asmi

[tnkumar]

2 hours ago, asmi said:

PCI Express has insane latency compared to AXI HP bus available for Zynq. It also requires, well, actual PCI Express host, while Zynq solution is self-contained on a single chip. Zynq DDR3 controller peaks at a bit over 4GB/s, which is enough for a lot of applications. If your design need more, you can add another memory controller in PL, but I suspect that fabric speed will become a limiting factor somewhere in that area. You can step up to Zynq-030, which sports faster Kintex fabric and can implement 933 MHz DDR3 controller, which will give you all the bandwidth you'll ever need, and you can set up your design such that ARM CPUs will have access to part (or all) of that memory as well as that of the hardIP side - the limiting factor here is address space, but this can be side-stepped by banking.

Seriously? External board with PCIE and a PCIE card with FPGA is cheaper/better/easier than just a single chip?

I don't have any commercial experience with it myself, but some of my customers did some designs on a board I built for them, so my experience is only anecdotal. That said, these customers were super-happy with results, with the main advantage being time to market, so there is definitely a place for it. Again, yet another tool in our toolbox to learn about so that we can use it when a need arises.

That is one possible use case, but Vitis basically produces IP blocks that can be connected to any other logic in Vivado, you can use them even with pure FPGAs like Artix. HLS is great for stuff like advanced math, FFT, image processing via OpenCV, as Xilinx includes a library of these functions ready to be used in your C/C++ code, allowing for extremely fast iterations - as you can debug your code as a regular C/C++ application, with compilation being pretty much instant, and only move to hardware once you've ensured that your code works properly - and even here you can use the very same C/C++ testbench you used to debug your code, to run a co-simulation to verify that generated core still works properly.

If you are interested and have some time, I recommend you to watch the following YT playlist: https://www.youtube.com/playlist?list=PLo7bVbJhQ6qzK6ELKCm8H_WEzzcr5YXHC They are one of the best video tutorials I've seen on this subject, even if they are a bit dated.

Thanks @asmifor sharing the link to YT HLS video tutorials. I had also come across (~8 mins video)

 that very nicely explained the beneift of HLS in some scenarios.

@zygot - It is ok for threads to diverge from the original question ?. I learnt a lot reading the discussions with @asmi and you
I have been working with FPGAs for about 4 weeks and these discussions are very beneficial for me.

Edited December 16, 2021 by tnkumar

[tnkumar]

9 hours ago, asmi said:

you can run Linux on Microblaze as well).

@asmi - Can you point to tutorials that show how Linux can run on MicroBlaze? Would this be possible on Arty S7-50? The tutorials I came across using Vivado / Vitis 20.1 point to the use of MicroBlaze with c/c++

[asmi]

48 minutes ago, tnkumar said:

@asmi - Can you point to tutorials that show how Linux can run on MicroBlaze? Would this be possible on Arty S7-50? The tutorials I came across using Vivado / Vitis 20.1 point to the use of MicroBlaze with c/c++

There are some specific requirements for your MB design in order to run Linux - MB itself has to be configured to run Linux (there is a preset in MB's customization dialog), you need to have at least 32 MBytes of memory (Arty-S7 has more, so that's fine), you need to have a timer, a UART port (so that you can talk to it), and a QSPI interface for storing Linux image (I think this is optional, though it wouldn't hurt for sure), and an interrupt controller. Pretty much all Xilinx-provided IPs have a driver for Linux. You will also need access to Linux installation (virtual machine will work too), as all Petalinux stuff only works in Lunux.

I don't know of any guide specific to Arty-S7, not do I have an actual board to write one, but it's not very complicated. You can go through this guide: https://numato.com/kb/mimas-a7-microblaze-and-linux-how-to-run-linux-on-mimas-a7-fpga-development-board/ to get an idea of what's involved.

Unfortunately information is kind of scattered all over the place, here are requirements for MB system taken from UG1144:

Quote

MicroBlaze processors (AXI)
The following is a list of requirements for a MicroBlaze™ hardware project to boot Linux:
• IP core check list:
○ External memory controller with at least 32 MB of memory (required)
○ Dual channel timer with interrupt connected (required)
○ UART with interrupt connected for serial console (required)
○ Non-volatile memory such as Linear Flash or SPI Flash (required)
○ Ethernet with interrupt connected (optional, but required for network access)
• MicroBlaze processor configuration:
○ MicroBlaze processors with MMU support by selecting either Linux with MMU or low-end
Linux with MMU configuration template in the MicroBlaze configuration wizard.
Note: Do not disable any instruction set related options that are enabled by the template, unless you
understand the implications of such a change.
○ MicroBlaze processor initial boot loader fs-boot needs minimum 4 KB of block RAM for
parallel flash and 8 KB for SPI flash when the system boots from non-volatile memory.

One bummer is that Arty-S7 doesn't have Ethernet, so you can't use what I think is the biggest advantage of running Linux - which is networking. But you can still make it work, I've done it for Spartan-7 on an open-source board I designed for those who would like to get a jump start on designing their own boards. The device was Spartan-7 S50, which is what you have on Arty, so it's got more than enough logic resources to make it happen.

[tnkumar]

8 hours ago, asmi said:

There are some specific requirements for your MB design in order to run Linux - MB itself has to be configured to run Linux (there is a preset in MB's customization dialog), you need to have at least 32 MBytes of memory (Arty-S7 has more, so that's fine), you need to have a timer, a UART port (so that you can talk to it), and a QSPI interface for storing Linux image (I think this is optional, though it wouldn't hurt for sure), and an interrupt controller. Pretty much all Xilinx-provided IPs have a driver for Linux. You will also need access to Linux installation (virtual machine will work too), as all Petalinux stuff only works in Lunux.

I don't know of any guide specific to Arty-S7, not do I have an actual board to write one, but it's not very complicated. You can go through this guide: https://numato.com/kb/mimas-a7-microblaze-and-linux-how-to-run-linux-on-mimas-a7-fpga-development-board/ to get an idea of what's involved.

Unfortunately information is kind of scattered all over the place, here are requirements for MB system taken from UG1144:

One bummer is that Arty-S7 doesn't have Ethernet, so you can't use what I think is the biggest advantage of running Linux - which is networking. But you can still make it work, I've done it for Spartan-7 on an open-source board I designed for those who would like to get a jump start on designing their own boards. The device was Spartan-7 S50, which is what you have on Arty, so it's got more than enough logic resources to make it happen.

Thanks @asmi for all the pointers. It is heartening to know that Linux may be possible. Regarding Ethernet, possibly this https://digilent.com/shop/pmod-nic100-network-interface-controller/ PMOD can be used with the ArtyS7-50?

Edited December 16, 2021 by tnkumar

[zygot]

What's possible might not be all that useful. Of course, just about any endeavor can (should?) be a learning opportunity.

I suggest that if you want to run explore Linux running on an FPGA, ARM or soft-processor core,  you familiarize yourself with tools like Yocto and the like for building minimalist versions of an OS. Make sure that the whole application and OS runs in available volatile memory and avoids corrupting corrupting the non-volatile memory from where it is loaded from. The Red Pitaya is a good guide. If you are an expert building modern Linux kernels and writing drivers then it's a great alternative to an RTOS or Xiinx standalone.

Develop some expertise in logic design, verification, and debugging techniques before adding software to the mix. Before you try winning a triathlon, it's a good idea to learn how to swim and ride a bike... 

[asmi]

1 hour ago, tnkumar said:

Thanks @asmi for all the pointers. It is heartening to know that Linux may be possible. Regarding Ethernet, possibly this https://digilent.com/shop/pmod-nic100-network-interface-controller/ PMOD can be used with the ArtyS7-50?

I don't know for sure, you need to check if there is a driver for that chip in Petalinux.

[asmi]

1 hour ago, zygot said:

I suggest that if you want to run explore Linux running on an FPGA, ARM or soft-processor core,  you familiarize yourself with tools like Yocto and the like for building minimalist versions of an OS.

It's not something I'm really proud of, but I know next to nothing about Yocto and yet I was able to build Linux images for both Zynq and Microblaze just fine. So while it no doubt will be helpful to know about these things, this is not a strict requirement.

1 hour ago, zygot said:

Make sure that the whole application and OS runs in available volatile memory and avoids corrupting corrupting the non-volatile memory from where it is loaded from.

You can boot Linux via JTAG without ever touching any of non-volatile memory. This is how I do it during design, because it's faster than programming flash every time I want to change something.

1 hour ago, zygot said:

Develop some expertise in logic design, verification, and debugging techniques before adding software to the mix. Before you try winning a triathlon, it's a good idea to learn how to swim and ride a bike... 

That I fully agree with. Playing with Petalinux can be fun, but it's a deep rabbit hole in it's own right. It's better to get to grips with the actual FPGA side first.

[zygot]

18 hours ago, asmi said:

PCI Express has insane latency compared to AXI HP bus available for Zynq. It also requires, well, actual PCI Express host, while Zynq solution is self-contained on a single chip. Zynq DDR3 controller peaks at a bit over 4GB/s, which is enough for a lot of applications. If your design need more, you can add another memory controller in PL, but I suspect that fabric speed will become a limiting factor somewhere in that area. You can step up to Zynq-030, which sports faster Kintex fabric and can implement 933 MHz DDR3 controller, which will give you all the bandwidth you'll ever need, and you can set up your design such that ARM CPUs will have access to part (or all) of that memory as well as that of the hardIP side - the limiting factor here is address space, but this can be side-stepped by banking.

 

18 hours ago, asmi said:

Seriously? External board with PCIE and a PCIE card with FPGA is cheaper/better/easier than just a single chip?

PCIe has latency. DDR has latency. USB 3.0 has latency. For blasting huge quantities of data as fast as possible they are all great. For a few random bytes ? Not so much. ZYNQ has it's own limitations as you've pointed out.

You can cherry pick devices and speed grades to support an argument but that doesn't always turn out to have practical benefits. The Kintex-160T has always been  supported for free by Xilinx tools. How many affordable FPGA boards using that device do you know of? The last time I checked the price with a distributor of that device in the slowest speed grade was more than the cost of a Genesys2 and had a leas time of about a year. How many cheap Z7030 or Z7045 boards does Digilent sell? 

The ODESSEY/FPGA board combination isn't necessarily the cheapest path to achieving the goals that I use it for. But better and easier? Yeah, I think so.

My FPGA designs are all HDL and no AXI/AMBA busses. They connect to a more powerful and complete computing entity that isn't tied to an ARM. No 4 GB addressing limit that even the ZU7EV has. More memory. More flexibility than a ZYNQ board. I have access to more legacy tools and software and can use a supported OS and keep it up to date easier. More IO options. Etc, etc. My software designs aren't restricted to the ARM toolchain. I have a far larger choice of applications to use in this setup. Would I want to try and sell it as a system when a lesser ZYNQ board would make more sense? Of course not. Cheaper than my ZCU106? Yes, by quite a margin. More useful than my ZCU106? Yes or no. Would I rather develop some of my applications on the ODESSEY/FPGA than the ZCU106 ? Absolutely. Can the overall development for applications on such hack be easier and faster than if I were try to do it on the ZCU106? Absolutely. Can I use Intel or Xilinx FPGAs on this system? Yes, even UltraScale+ with 1.5 HPC FMC connectors ( that's what's currently connected to the one ODESSEY ). Can I upgrade the processing power or FPGA capabilities of a SBC/FPGA setup? Yup. Can I do that with my Zedboard? Nope.

Single chip (based boards) are fine and certainly are better suited for some applications; but not for all. The ARM processors in the ZU7EV are roughly equivalent to the Raspberry Pi 4 but as a microcomputer less full featured than the Broadcom device that the RPI4 is based on. Is Xilinx selling me cheap ARM processors? I don't think that they are. You see any Raspbery Pi UltraScale board for under $100? Speaking of RPI4, for some applications it and a cheap FPGA board make for a fine ZYNQ alternative. And that's one point to make. It's just an alternative when it makes sense. So, what's better? A ZYNQ board with fixed processing power or a multi-board setup with flexibility? I think that the answer is that it all depends on what you intend to do with it. Does every application have the same data transfer rate requirements? No. Do I care about the DMA data rate from PL to PS memory of the Z7030? Only if I were designing a custom board for an application that required it  because i am unaware of any cheap boards using that device that I'd want to buy for development. Are there applications that I'd rather spend development effort on the ZCU106 using Xilinx tools? Perhaps. But right now my ZCU106 PL can communicate with 4 ARM cores with 4 GB of memory and 4 X86-64 cores with 8 GB of memory so I'm a pretty happy camper. And if I need to put the ZCU106 to other uses, I can still marry the ODESSEY to a number of Intel or Xilinx based FPGA devices. Can a ZYNQ based board to that? Perhaps. How many ZYNQ boards with PL connected DDR can you think of? Well, the ZCU106 for a whole lot of coin does... can't think of any cheap boards that do.

My point here isn't to further the argument, just to point out that the analysis is more complex than ardent advocates of any one point of view might want to acknowledge. For the record, I see this interchange of ideas as referencing hardware that you can buy, not related to any custom board that you might be able to build... if you can get components. Those are two very different discussions. I'm talking about things that I can buy, not things that perhaps someone can design that I might not be able to afford.

 

Edited December 16, 2021 by zygot

[tnkumar]

Thanks @zygot and @asmi for additional perspectives.

I had the following takeaways

-try and create a minimlist kernel, possibly with a driver for a PMOD Ethernet interface

- you can have Petalinux in non volatile memory

Not that I intend to immediately try these, but that these are possibilities.

[zygot]

Gee, those were your takeaways? Sigh...

You've used the Red Pitaya so you have an idea how one custom Linux build runs on a dual core 600 MHz ARM processor. Don't expect those results with Microblaze. As nifty as that instrument is, it still lacks features that one might expect for the money.

As for the PMODNIC100, this is a strictly low ( 10BASE-T) speed Ethernet solution. I've done 12 Mbaud USB UART interfaces with DE0 Nano and CMODs. The ENC424J600 is an odd bird among Ethernet solutions and the PMOD SPI interface is the slowest possible way to get data into and out of it. Make sure you are comfortable with the support that Digilent supplies for that device as far as software drivers and logic connections go. I'd be pretty surprised if you will find Linux drivers ( what kernel version are you intending to use? ) for that PMOD. But, I'm used to surprises.

Be aware that ( as of Vitis 2020.2 ) Petalinux still hasn't been integrated into Vitis and requires a separate and not easy install. You can only use Linux hosts of a certain distribution and version, much like Vivado, but with cross-compiler tools it's even more important to follow the rules.

I'm not one to stand in the way of anyone pursuing their obsession but considering how this discussion has turned from your initial post to the most recent on I'm hoping that you aren't distracted by subject material that really is peripherally related to logic design and development. If you want to do custom Linux programming then the RPI4 is cheaper and faster.

Programmable logic is pretty cool and very complicated. Programmable logic paired with a computer is even cooler and a whole lot more complicated if you want to do more than have Vivado wire up a limited set of IP for you to play with. Everyone has their own path to follow, so well wishes to you as you choose yours.

Edited December 17, 2021 by zygot

[asmi]

7 hours ago, zygot said:

For the record, I see this interchange of ideas as referencing hardware that you can buy, not related to any custom board that you might be able to build

Well here is your problem. To unlock full potential of these devices, you need to be willing to design custom boards as each application is unique. At least that explains why you prefer those Frankensteins cobbled-together solutions instead of nice and efficient single-chip ones. 

[tnkumar]

9 hours ago, zygot said:

Gee, those were your takeaways? Sigh...

You've used the Red Pitaya so you have an idea how one custom Linux build runs on a dual core 600 MHz ARM processor. Don't expect those results with Microblaze. As nifty as that instrument is, it still lacks features that one might expect for the money.

As for the PMODNIC100, this is a strictly low ( 10BASE-T) speed Ethernet solution. I've done 12 Mbaud USB UART interfaces with DE0 Nano and CMODs. The ENC424J600 is an odd bird among Ethernet solutions and the PMOD SPI interface is the slowest possible way to get data into and out of it. Make sure you are comfortable with the support that Digilent supplies for that device as far as software drivers and logic connections go. I'd be pretty surprised if you will find Linux drivers ( what kernel version are you intending to use? ) for that PMOD. But, I'm used to surprises.

Be aware that ( as of Vitis 2020.2 ) Petalinux still hasn't been integrated into Vitis and requires a separate and not easy install. You can only use Linux hosts of a certain distribution and version, much like Vivado, but with cross-compiler tools it's even more important to follow the rules.

I'm not one to stand in the way of anyone pursuing their obsession but considering how this discussion has turned from your initial post to the most recent on I'm hoping that you aren't distracted by subject material that really is peripherally related to logic design and development. If you want to do custom Linux programming then the RPI4 is cheaper and faster.

Programmable logic is pretty cool and very complicated. Programmable logic paired with a computer is even cooler and a whole lot more complicated if you want to do more than have Vivado wire up a limited set of IP for you to play with. Everyone has their own path to follow, so well wishes to you as you choose yours.

Thanks @zygotfor listing implications of going down this path. I think I will leave PetaLinux out of my pursuits for now.