tnkumar

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.
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.
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.

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

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... 

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 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.

Hi @rehsd,
This is correct. All of the instances in the Pmod Shield documentation that refer to JA, JB, etc., are referring to the Pmod Shield Pmod host ports themselves, not whatever host FPGA/microcontroller it might be placed on top of has in terms of Pmod ports (as an example, an Arduino board has no Pmod Host ports).
The way the Pmod shield makes the connections to the host system is through the pins on the underside of the board to connect to the female IO headers on the host system.
The bit about the SPI, UART, and I2C Pmods on the shield are only relevant for the Digilent microcontrollers since microcontrollers are hardwired to a particular protocol 'engine' on the processor. FPGAs do not have this limitation with pins connected to their fabric as you can configure the FPGA to create a protocol bus of whatever variety you like (limited by speeds, I/O standards, and termination of course, but that's not an issue for SPI, I2C, UART, and GPIO Pmods).
To configure those Pmod ports for something like the Arty A7 35T, you would do something like this in the .xdc (after you add the Pmod IP/Hierarchy and make the Pmod_out connection external, which you can then name to something else) for Pmod JA on the Pmod Shield:
#set_property -dict { PACKAGE_PIN U11 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin1_io }]; #Arty A7 Arduino header pin 26, Shield JA1 #set_property -dict { PACKAGE_PIN V16 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin2_io }]; #Arty A7 Arduino header pin 27, Shield JA2 #set_property -dict { PACKAGE_PIN M13 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin3_io }]; #Arty A7 Arduino header pin 28, Shield JA3 #set_property -dict { PACKAGE_PIN R10 IOSTANDARD LVCMOS33 } [get_ports { Pmod_out_pin4_io }]; #Arty A7 Arduino header pin 29, Shield JA4 Let me know if you have any questions.
Not on the weekends when the Digilent staff is not working. 
Thanks,
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

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.

Hi - I am Kumar. I just got my Arty S7-50 board today. I have an interest in robotics. I am looking to learn FPGA programming and considering using Verilog to start with. I also got a PMOD ENC. I hope I can learn by engaging in the forums

@rehsd - Good to know that you got your PMOD OLEDrgb to work. Today, I also got my PMOD OLEDrgb working. It is good to know that it is possible to add 2 PMOD OLEDrgbs to the same FPGA board, if needed
 

@thinkthinkthink, thanks again for your helpful suggestions. I was able to resolve the issue. I had to delete the design wrapper and recreate it. Everything is working great now!

@thinkthinkthink and @JColvin have been helpful with questions I have been posting.

I was able to get video output working! ? After moving data sections to DDR via the linker script, my build with 640x480 worked.

Xilinx Replaced the long-lived SDK, starting with Vivado 2019.2, with Vitis. You can download and use Vitis and Vivado for free from Xiinx, though not all devices are supported for free. Vitis includes most of the old software development tools, but Vivado still creates the HW bitstream.