JColvin

Thank you. For some unknown reason after update/upgrading the ubuntu and rebooting it worked.

Hi @0xbadcaffe,
Yes, that is entirely possible to do; simply just have the Rx assigned on one particular Pmod pin and the Tx on a different pin. An external wire like a breadboard jumper wire would be needed to make the electrical connection the two pins of course, but whether the Rx and Tx are part of the same UART core or not (or same board) doesn't matter.
So long as the setups are expecting the same baud rate and word length and the logic is in place to handle when data comes in at unexpected times (presuming you aren't using clear-to-send, etc, signals) it'll work. The harder portion is any extra application material to correctly process the data at more than one byte at a time (option 1 or option 2 style) to enable different types of functionality.
Thanks,
JColvin

Hi @0xbadcaffe,
The Pmod RS232 and Pmod RS485 can be used with the Arty S7 without any special crossover cables. This is because FPGAs can have their internal logic be "assigned" to any compatible IO pin (unlike microcontrollers or microprocessors where their UART or SPI cores are hardwired to only particular pins; the PIC32 microcontrollers that Digilent used to sell had a change in the architecture where the hardwired locations of the Rx and Tx pins changed).
Otherwise you could use the UART VHDL implementation that is used as part of the Arty S7 GPIO demo, https://digilent.com/reference/programmable-logic/arty-s7/demos/gpio; the UART_TXD port that is defined in the "top" file (in this case GPIO_Demo.vhd) is set to the corresponding RX port on the USB-UART interface in the .xdc file. This could easily be "assigned" to a different pin on one of the Pmod ports instead.
Let me know if you have any questions.
Thanks,
JColvin

Hi @0xbadcaffe,
Digilent does not have a demo using the both the Pmod RS232 and the Pmod RS485 (a singular design that seamlessly supports both devices would not be super straightforward either as the Rx and Tx pins on the two Pmods are on different pin locations on the 6-pin header).
I have made an external UART loopback on Digilent boards that takes serial terminal data from the host computer, sends the UART data out one of the Pmod port pins, receives that UART data via a breadboard jumper wire to a different Pmod port pin, and then sends the received data back to the serial terminal on a host computer. The general process of how to set this up in Vivado block design is described here:
The corresponding Vitis code that facilitates the described communication would be similar to this:
To be clear, this does not implement any of the control signals used in the Pmod RS232 and Pmod RS485, though otherwise are communicated with via standard UART.
Let me know if you have any questions.
Thanks,
JColvin

Welcome to the Forum!

Hi @Anthocyanina,
I'm not certain why this might be; I just attempted to redownload WaveForms on both Chrome and Firefox on my Windows 10 machine and was able to successfully download both the formal release and the 3.19.27 beta in about 10 seconds each (~6.0 MB/s download based on what the Firefox on-going downloads told me).
I know that there was recently a browser cookie update to some of the Digilent websites and that some parts of the website would run very slow or not at all if you blocked different cookies, but my understanding was that issue got resolved a couple of weeks ago. But even if this was the issue, I don't know why it would only affect your Windows system but not the Linux system. I will ask some my coworkers to see if this can be replicated.
Thanks,
JColvin

you can do it like this with a math channel

I can certainly put that in as customer feedback, though with the SD cards current location, I fear it would entail an entire PCB spin to put the SD card on the side with regards to rerouting. Maybe it could simply be rotated with minimal PCB routing rework though (I'm not a hardware engineer, so my perspective is limited on this front).
I don't know the story of why the SD card is in the middle of the board, but I would like to to think that the decision wasn't made lightly, considering that every other Digilent board (including multiple made by the same lead engineer on the Genesys ZU boards).
But at the same time, I also just noticed that the SD card housing has the open and lock instructions with arrows directly etched onto it... Regardless, it's at least clear to me that it is not a well received design choice, so I will do my best to help make sure it is not the housing of choice in the future.
Thanks,
JColvin

@attila Thank you! I had not noticed that menu, is there a setting to tell it how much time to keep in the display? or does it infinitely accumulate the points and display them? thanks again, it works quite nicely :)

Hi @CBI,
I checked with Niță Eduard and learned that they still intend to look into your question and help debug it, but they did not have time to do this week, though they are hoping to get some time next week.
Thanks,
JColvin

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

Hi @drkome,
I'm a little confused; I'm not certain what PL2303 is (hardware that you attached to the board? something else?), but based on the output from Adept the board is successfully configured (as you noted). Did LD12 (the "Done" LED next to PGOOD) light up after Adept reported that it successfully programmed the board?
Based on what you described, and because jumper JP5 (just below the "Z7" portion on the silkscreen name) is set to QSPI, I believe what you saw was that the program that was loaded into the QSPI flash was instead superseded by the bitstream program that was loaded instead. If you power cycled the board, whatever program was in flash should "reload" onto the board.
Thanks,
JColvin

Hi @drkome,
As zygot mentioned, the Zybo Z7 is not intended to be powered through the Pmod host port as shown in your picture with the orange and blue/purple colored wires. The correct way to provide power to the device is through either with a micro B USB cable on J12 or with a 5 V external power supply through the barrel jack connector on J17, as that is the only way the the power can be properly provided at the correct voltage levels to all parts of the system board. The fact that you have the DONE LED turned on when powering the Zybo Z7 through a Pmod host port is very concerning, please disconnect those wires starting with the blue/purple one.
What I would do to check for functionality of the board is:
-slide the power switch on the Zybo Z7 to the off position, disconnect your Zybo Z7 from the computer and other devices, close out both Vivado and Adept
-With the Zybo Z7 still disconnected, ensure that the jumper JP6 (near the power switch) is set to USB, and also set jumper JP5 to JTAG
-Connect the Zybo Z7 to the host computer with a micro B USB cable and turn on the Zybo Z7. LD13 (PGOOD) should light up with a red color (nothing else will happen on the board).
-Open up Adept and load the bitstream that I have attached to this message. This should cause LD12 (DONE) to light up with a green color and cause LD6 to start flashing with a magenta color, as well as each of the switches SW0 through SW3 to turn on the LEDs directly above them. This design tests the functionality of Bank 34 and Bank 35 on the Zybo Z7 to see if either one has been damaged (since Pmod Host port JE has IO pins routed to both of those banks).
-Regardless of if the LEDs or switches appear to be working turn off the Zybo Z7 and then turn it back on again.
-Close Adept and then open up an existing design or a brand new blank design in Vivado. Open up the Hardware Manager in Vivado and load the same bitstream to the Zynq chip (xc7z010).
From your screenshots, Vivado seemingly detects the board somewhat, or at least finds the serial number associated with the device, but not the downstream Zynq chip. I am uncertain as to what the root problem might be in this instance, but let's worry about this test first.
Thanks,
JColvin
SW-LED-ZyboZ7-10.bit

HI @engrpetero,
Kvass is correct. Here is a post describing the process in a bit more detail (for a non-zynq board but the general process is the same):
And this post has some basic Vitis code that does external UART loopback (PC -> board -> external loopback to board -> PC) for a different Zynq based board
Thanks,
JColvin

This issue has since been fixed in the Digilent board files in version 1.1 of the Zedboard board files, which can be found in the vivado-boards repo on Github: https://github.com/Digilent/vivado-boards
Thanks,
Arthur

Hi @SB1,
Your use case is acceptable.
You can view a courtesy copy of the WaveForms License Agreement here: https://digilent.com/reference/software/waveforms/waveforms-3/start#additional_resources, as well as a longer thread discussing a nearly identical use case as to what you described here:
Please let me know if you have any questions.
Thanks,
JColvin

https://forum.digilent.com/topic/8908-waveforms-beta-download/
WaveForms 3.19.18 brings for Eclypse Z7 Zmods the following:
- deep capture for Scope (Zmod Scope and Digitizer) 256Mi and Logic Analyzer 128Mi samples, all up to 125MHz
- IIR filter channels performed in the device
- the Wavegen channels can be controlled from the Scope interface and digital outputs captured
- the Scope inputs (raw ADC, averaged or filtered) can be output to the Wavegen channels, as signal or as amplitude, frequency, phase modulation or summing
- DIO 14/15 can be used as trigger IOs
Limitations:
- when more than 4 capture channels are enabled the max sampling rate is 62.5MHz
- the IIR filter is optimized for high speed with lower resolution and due to this in certain conditions it can saturate, like with narrow band or high sample rate/frequency ratio
The QSPI firmware is updated automatically, for SD card boot mode and initial QSPI programming see the Help tab/ Eclypse Z7
 
AWG1 -> Scope1 -> Scope3 (Scope1 IIR)
AWG2 -> Scope2 -> Scope4 (Scope2 IIR)

 
AWG1 -> Scope1 -> Scope3 (Scope1 IIR) -> AWG2 -> Scope2
AWG1 -> Scope5 output
AWG2 -> Scope6 output

No mystery here: you selected a bistream file created  for a ZYNQ device and your board is not a ZYNQ device. If you started off with a demo for your board and selected the correct device your bitstream would be correct. There's very little likelihood of getting past synthesis, implementation or bitgen targeting the wrong device as pin assignments would not match.
Where are you finding these?
If you look in the Vivado Project Settings, what device is listed?

Hi @Josef Čada,
I'm not certain what you mean by change the values on the ADC through NI VISA. You are correct though that this particular demo I found on the internet simply only has LabVIEW receiving the data being generated on the serial port by the Zybo board; LabVIEW does not do any communication or control of the device.
The ADC on both Xilinx FPGA boards and SoC boards is configured in hardware before the application starts running on the boards. I suppose it would be possible to configure on the onboard XADC to have all channels enabled and then create your own custom C application that listens for data input on the serial port that would then read from whatever channel you choose to request from in LabVIEW, maybe via a button press that sends a "2" indicating channel 2 which would then be processed by the application? Something similar is done for the Zybo Z7 HDMI demo with a switch case statement waiting for different characters to be received in the UART FIFO (demo project is detailed here: https://digilent.com/reference/programmable-logic/zybo-z7/demos/hdmi, with the specific code that does what I'm attempting to describe in the DemoRun() function on line 182 on the Digilent Github here: https://github.com/Digilent/Zybo-Z7-SW/blob/5d3c1cf06f8215cbeae1081a7ce06ac5f3d97807/src/Zybo-Z7-10-HDMI/src/video_demo.c).
Thanks,
JColvin

Hi @Josef Čada,
I do not believe there is any way to directly connect the Zybo Z7 to LabVIEW, or at least I am not aware of any option.
In principle, it should be possible to set some serial communication up with NI VISA or something like that...actually it should be possible based on this tutorial I found here: https://www.instructables.com/Digilent-ZYBO-based-oscilloscope-with-LabVIEW/, where they did exactly that.
Thanks,
JColvin

The A7-35T is probably a bit small for video applications, even low resolution VGA ones, but you can do simple display things with the Basys3, as this tutorial points out: https://forum.digilent.com/topic/19910-basys3-game-tutorials-beeinvaders/

A problem with small devices like the A7-35T is that Vivado IP and MicroBlaze will use up a lot of its resources if you have to use that design flow. For an all HDL design you can fit a lot of functionality into even the smallest A7 device if it doesn't use external DDR3 memory.

Someone with a very tight budget has to be very careful before spending money. These days boards don't necessarily come with all the stuff that you need to use them; like USB 2.0 cables, power supplies, etc. Also, because of global chip shortages process for even old board have gone up 50-100% over what they sold for when originally released.

I'd recommend that you take an inventory everything that you will need to actually enjoy the fruits of your labor and add up the costs. It might be cheaper to spend more money on something that provides most of it than starting off with a minimal expenditure and buying add-ons as you go. For any kind of game experience you not only need a video output, and cable that's compatible with a monitor that you have handy, you need some way for the user to interact with your application. Do you expect to have audio? Do you need joystick inputs? Make a list and add it all up.

Lastly, and perhaps more importantly, how are you going to proceed with your project goals? Do you want to learn FPGA development, or are you more interested in bootstrapping projects that you've found on the web? If it's the latter, then buying a platform for which project code has been written for might make more sense.

Be careful of making an investment in something that may not allow you to get to your end goal, or will be a lot more expensive getting there by the time that you've purchased all of the extra stuff that's needed... only to find that you have a platform with very limited potential. Most cheap FPGA boards are designed to sell you more stuff. If it's a trap, avoid it, if it gets you to your goal within your budget, then do your homework and go for it if it makes sense. Even some cheaper Intel FPGA boards have PMOD connectors these days. Be cautioned that Intel has restricted the free version of Quartus to Cyclone 10LP and earlier and that some of it's free IP, like DDR interfaces, are broken or very hard to use.

Cheaper Xilinx FPGA boards might not be the best choice, in terms of value for cost. The Cyclone V Start Kit is available for about double what it originally costs, but comes with a lot more features than a really cheap A35T board. I'm not recommending that as an option, just as an example of something different that's currently available from distributors. Unfortunately, this is not a good time to dive into cheap FPGA board development on a very tight budget.

Hi @hrathod,
I have sent you a PM.
Thanks,
JColvin

You have a few misconceptions going on here.

The create_clk and create_generated_clock tcl commands are for timing constraints, not generating physical clocks in a design.

In programmable logic, clocks are different than other signals in an HDL design. FPGA resources and routing resources for clocks are separate from other signal in a design. Most PFGA devices don't have on-board clock resources. So, a clock begins life in a clock module that is external to the FPGA and is connected by a clock-capable ( for Xilinx ) pin. From there it can be used to clock the user internal design logic or can go to an MMCM or PLL, which in turn can generate multiple output clocks that can be used in a design. This is how you should create a clock. You can use Verilog, System Verilog, or VHDL to instantiate a primitive or use the vendor IP; it's up to you. Until you know what you are doing, I'd suggest using the Clocking Wizard.

While you can create a clocked signal using a counter or divider, or whatever suits your fancy to create a logic signal that you may want to use as a clock for the purpose of clocking other logic this is a very very bad idea. Don't do it. The correct way to create a custom clock with a specific frequency is to use an MMCM or PLL. That's what they are there for.

Going back to your original tcl commands. Let's say that your FPGA has an external clock module that puts out a 100 MHz clock on a pin assigned the name sysclk. In your constraints file you can create a timing constraint that tells the tools some basic information about sysclk using the create_clock command. At a minimum the tools need to know period and duty cycle as your create_clock command does. Now, if you instantiate a PLL and run sysclk into the PLL and have the PLL create a 10 MHz clk_out that you name clk10, you can also use the create_generated_clock to create a new timing constraint for clk_10. If you use the Clocking Wizard, it will also create it's own timing constraints file in addition to yours with pertinent information. In recent version of Vivado, this can cause issues, or at least a warning that you are over-writing a timing constraint.

In order for the synthesis and routing tools to properly create an implementation and place it, it need basic timing information for the clocks that create signals in a deign.

Its possible to create a VIvado project and generate a bitstream using tcl but, except for constraints, an HDL is better for describing your design to the tools.

Hi @ajeetsinha2003,
I have sent you a PM.
Thanks,
JColvin

Hi @PDonnelly,
I have not heard anything about that variant of the JTAG SMT2 being discontinued.
I'm not involved in that aspect of the business, but I believe the -B is indicating baked, or at least the MSL 3 option.
You should be able to learn more (including the important 'can I still order this' ) by contacting our Sales department here: https://digilent.com/shop/sales-and-order-support/.
Thanks,
JColvin