JColvin

Hi @johndah,
I don't know all of the answers to your questions (hopefully @attila will be able to provide some additional insight to the power related questions) but here are the answers that I do know:
- The USB A port is connected to a hub (Microchip USB2513B); I do not know the details on connecting a powered dongle to the ADS
- You may safely remove the screws from the breadboard canvas without issue.
Thanks,
JColvin

My occupation is embedded software development especially for micro-controllers, preferably the ARM Cortex-M type. I was annoyed by two things, first the mess on my desk, boards, programmers, wires, power supplies, measurement devices and so on. Second the fact that working from multiple places, the office, home, a client was very problematic since the development equipment was hard to move.....
I decided to integrate it all........ and this is the result:

A metal portable frame where the development boards are attached using magnetic feet.
On the top left connections to a Digilent Digital Discovery,
Next to it two USB ports,
To the right of that three power outlets for 5V, 12V and 24V
And finally a trigger output for my ADP3450 which I can connect to one of the pins of the Digital Discovery
On the right a connection for a J-Link programmer
and a connector for a second logic analyzer, a LogicPort which I like for its flexible trigger capabilities

And this is how the bottom looks:

Everything is here. Most important, in the top left corner the Digital Discovery, more about this later.
There is a 7 port USB Hub, a UART Dongle, a power supply, a DC-DC converter for powering the USB hub, the LogicPort and the J-Link.
And this is what I did with the Digital Discovery:
First designed a PCB:

Next dismantled the Digital Discovery and using pin headers soldered it to the PCB

And finally mounted it in the development frame

 
The feet of the frame are magnetic and I can just click it in a Pelicase for transportation. 
Just wanted to share this with you all
 
 

Hi @dyne21,
I am looking to see if I can get this working, though I personally have always had issue getting the SREC SPI Bootloader ever working as advertised, whether I follow Digilent's or Xilinx's instructions on it.
I've instead successfully used this approach for storing SDK/Vitis projects in flash:
Thanks,
JColvin

Hi @Sundance_Chris,
I have sent you a PM with some instructions.
Thanks,
JColvin

Hi @CHONG,
I got some answers to your questions:
Output driver configuration -- push-pull drivers
source termination value -- No source termination
Trace length between the output driver and SMT connector:
Signal length [mm] TMSC 8.869848481 TDOC 24.731727984 TDIC 12.526955262 TCKC 5.510660172 current strength -- the signals are 24 mA drivers
rise and fall time -- we do not have this characterized
Thanks,
JColvin

Hi @HAZIQ,
You will want an updated version of Digilent's board files to get an updated version; there is a guide on how to do this here: https://digilent.com/reference/programmable-logic/guides/installing-vivado-and-vitis#install_digilent_s_board_files. During board creation, you will want to select the Nexys A7 rather than the Nexys 4 DDR; this is because the Nexys 4 DDR was rebranded to the Nexys A7; it is otherwise the same board.
You will want the SD card if you want to use the demo material that we have for the Pmod WiFi (which sets up a http server whose html contents are defined on the SD card).
The Pmod WiFi does have TCP echo server and clients (as well as UDP versions) though I have not personally attempted these with a pair of WiFI modules, but they would be one way that you can facilitate communication between two boards, or set up a situation where one Pmod WiFi hosts an HTTP server and puts some board data on the server and then another board connects to that same IP and reads data from that hosted site.
In terms of the other questions you had on other threads:
You do not need to worry about the warnings about the Pmod IP being built for a different board.
Thanks,
JColvin

HI @kannan.sasikumar,
There are a couple of options you can do. 
One is to implement a UART module in HDL, such as this one, https://www.nandland.com/vhdl/modules/module-uart-serial-port-rs232.html; the .xdc in Vivado would need to have the UART data leaving the FPGA to the host computer assigned to D4 (UART_RXD_OUT) and UART data going into the FPGA from the host computer assigned to C4 (UART_TXD_IN), as per the schematic bank pins on page 7: https://digilent.com/reference/_media/programmable-logic/nexys-a7/nexys-a7-d3-sch.pdf.
The second option if you are wanting to use a Microblaze/SDK/Vitis flow with IP blocks, you can use the AXI UARTlite IP with Microblaze (Digilent has some instructions on how this might be done here: https://digilent.com/reference/programmable-logic/guides/getting-started-with-ipi) and then using Xilinx's AXI UartLite examples (https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842359/AXI+UART+Lite+standalone+driver#AXIUARTLitestandalonedriver-LinkstoExamples) to receive data that you type on a serial terminal on your computer.
Thanks,
JColvin

Hi @kannan.sasikumar,
If you want to yes, but most applications don't need to use the CTS and RTS signals anymore since modern hardware's timing is good enough (and they aren't sending signals over super long distances).
Thanks,
JColvin

Hello @Mahdi Moradmand,
If you click on the two clock pin traces that are named on the 'axi_ethernet_0_dma' IP block and trace them back to their original sources, you will see that the s_axi_lite_aclk is coming from the ui_clk output on the Memory Interface Generator (which was added when the DDR3 was first added) and is set at 225 MHz.
Whereas the m_axi_sg_aclk gets it's source from output 1 of the clocking wizard that got added during one of the Block Automations, and is set at 200 MHz, which is slower than the s_axi_lite_aclk.
To resolve this, I would restart the project but in step 5.6 where you are running connection automation, rather than just clicking "OK" after selecting all of them, I would instead select the S_AXI_LITE option under axi_ethernet_0_dma and change it's "Clock source for Slave interface" option from Auto to "/axi_ethernet_0_refclk_clk_out1 (200 MHz)" and the on the second time you run Connection Automation, change the Auto option for the M_AXI_SG for the Clock source for the Master interface to match the "/axi_ethernet_0_refclk_clk_out1 (200 MHz)".
I haven't gotten to go through and test to see if this resolves all of the timing errors (since I don't think this will fix the clk_out2 reference clock mismatch, you may need to replace the clocking wizard with a new one to see if that helps or if the problem is elsewhere) and continue to debug the design.
Thanks,
JColvin
 

Hi @dyne21,
Yes, if you are selecting the board name during the initial Vivado project creations, then you should have the board files already.
Thanks,
JColvin

Hi @dyne21,
Digilent does not have any experience with getting PetaLinux set up for a MicroBlaze processor, so we won't of a lot of help in this regard. You're probably already aware of them, but there are a couple of links that may be helpful to you here and here.
Otherwise, based on the board_part error, it sounds like you'll need to install the board file for the Nexys A7 50T, which you can get from our GitHub here. If this does not resolve the issue, you'll probably want to try building each PetaLinux component individually to find out which portion is failing, as per this Xilinx support thread.
Thanks,
JColvin

Hi @John J,
I am in the process of downloading 2021.2 (garsh these downloads get bigger every year) and will let you know what I experience. From your very detailed description, you seem to have done every step correctly so I don't have anything to directly recommend to try differently at the moment.
Thanks,
JColvin

Hi @Eder,
You can find some guides for the Cora Z7 on it's Resource Center here: https://digilent.com/reference/programmable-logic/cora-z7/start. In terms of interrupts and other non-Digilent focused communication libraries, Xilinx has a number of libraries including examples listed here: https://github.com/Xilinx/embeddedsw/tree/master/XilinxProcessorIPLib/drivers.
Thanks,
JColvin

Hi @Enthusiastic,
I don't know why the 2019.1 materials are not readily linked anywhere, but I was able to find some of them through github by looking at their tags, https://github.com/Digilent/Genesys-ZU-HW/tags and https://github.com/Digilent/Genesys-ZU-OS/tags, it didn't look like there was any tags for the software page though.
Thanks,
JColvin

Hi @rehsd,
It sounds like you got it working, but if you haven't seen it already you should take a look at this well done project by xc6lx45 on the Cmod A7:
Thanks,
JColvin

Hi @AaronD,
I checked with our web and sales team and received confirmation that the banner advertisement on the main store landing page (which you paraphrased in your quote) only applies specifically to the Analog Discovery 2 SKU/part number; it does not apply to the Pro Bundle (or other bundles). 
Thanks,
JColvin

@HomaGOD,
Let's see ... when I built with the keypad, I used the COLumns as FPGA outputs, and the ROWs and FPGA inputs.  Here's how I went about reading it:
First, output zeros on all of the COLumns.  This is the normal state of the keypad.  You'll sit here until something happens. If any of the ROWs, treated as inputs, produce a value other than VCC, then a button has been pressed. You can then output VCC on two of the COLumns.  If the ROW inputs don't change, then these two columns were not responsible for the button--repeat with the other two outputs Once you've narrowed down which two of the COLumns is responsible for the button press, you can set VCC out on three of the columns--the two unused (i.e. unpressed) ones, and the one that has been pressed. Your goal is to find the one COLumn, which when set to zero, leaves the ROW at zero--because the key is pressed.  That column plus the row then gives you the key you need. Beware of bouncing!  Once the key is pressed, you will have to wait for it to settle before reading it.  Looking back over my notes, I waited for 100,000 ticks after registering the ROWs weren't all VCC before I went and tried to figure out which COLumn was responsible.
Also, this isn't the only way to handle the PMod keypad.  I remember doing this in college (decades ago ...) and reversing the directions of the pins in the process.  In this case, the pull ups can help you to know which way to go.  For example, the COLumns have no pull ups on them--so they work better as outputs than as inputs.
Dan

Hi @rehsd,
It sounds like you got it working, but if you haven't seen it already you should take a look at this well done project by xc6lx45 on the Cmod A7:
Thanks,
JColvin

Hi @rehsd,
The main caveat I was going to mention was that the Pmod LVLSHFT does not work in a bi-directional fashion, but clearly you are already well aware of this limitation.
That being said, I think what you are proposing will work, or at least for what it's worth I would personally wire it up as you proposed (ensuring grounds between all the systems are connected of course) and presume that everything was going to work as advertised.
There is of course some delay associated with the translating of voltages, but this is in the single digit nanosecond range, as mentioned in Switching Characteristics section Table 7.8 of the SN47LVC1T45 datasheet (link).
Thanks,
JColvin

Think that you need AXI busses or complicated logic design to use the PL in your fancy ZYNQ device? Well, this demo proves that you don't. Find out how to read and write registers in your PL logic design just by reading and writing a few registers in the PS register set.
By routing an unused PS UART to the PL via EMIO you can have a full-duplex data path as well as 6 additional input or output signals. What could be easier?
EmioUartDemo_R1.zip

Hi @tnkumar,
That is correct. There are some considerations that you will have to take into account though.
The first, and most critical in my opinion, is logic resources on the FPGA; each Pmod takes some amount of the LUTs and other available logic resources on the FPGA. This can get further compounded if you use the Digilent made IPs which use different AXI peripherals to be able to communicate with the host processor (usually Microblaze on an Arty S7-50). I would highly recommend that you check that the designs you are intending to create are able to successfully fit and run on an Arty S7-50 by generating the bitstreams and if you are using a processor, the Vitis/SDK applications in advance before you buy a wide range of Pmods + the Pmod Shield, if only to save the hassle of returning products you aren't able to use.
The second is that most of Pmod ports on the Pmod Shield have 200 Ohm series resistors. In conjunction with the 200 Ohm series resistors that are also present on the Arduino styled header I/O pins on the Arty S7/A7/etc themselves, this can lead to some unexpected behavior on different modules i.e. slower speed, lower I/O voltage, etc, all potentially leading to the attached Pmod not working. I know I have experienced this first hand with different Pmods.
The third is power consideration. Most Pmods don't need a lot of power, but it's also non-zero amount. The DA9062 should be able to supply 2 amps worth of current on the 3.3 V rail, but Pmods are not the only things in the system that use that 3.3 V line.
My personal opinion, stemming from the second point and the fact that the Pmod Shield is no longer being sold/manufactured, is that if you are not considered about the overall look of the system, you may want to consider just individually wiring additional Pmods to the existing female header on the Arty S7, as that is all the Pmod Shield effectively does. This would also help facilitate using different features of communications like SPI where a number of the same communication lines can be shared between different Pmods, reducing the number of overall I/O used on the FPGA itself. You'd have to get the logic appropriately working to switch between the different modules at that point, but it's an aspect to consider when you have a lot of different modules on one system.
Thanks,
JColvin

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
 

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

Hi @rehsd,
Yes, in general you should be able to use multiple of the same Pmod as all Microblaze would really see is that there is more than one AXI Quad SPI IP (in the case the Pmod OLEDrgb). The two IPs would need to have different names, but the names can be changed directly in the block design.
As a caveat, I haven't attempted this with the Pmod OLEDrgb in particular, but you would be able to add the extra IP in Vivado and see the bitstream still successfully generates (and if the SDK/Vitis still successfully builds the project) as much of the debugging work can be done prior to actually purchasing anything.
Thanks,
JColvin