artvvb

Yeah, current PC RAM marketing is all over this. But since FPGA designs are very close to hardware, it's important to be more precise even with marketing materials, because I think the kind of people who buy these boards are tech savvy enough for the most part to know the difference between "marketing" MHz and real ones.

Hi @Cheeku
At least Vivado and likely Xilinx SDK or Vitis are required to use the board. Installation instructions and guides can be found in the Zybo Z7 resource center, here: https://digilent.com/reference/programmable-logic/zybo-z7/start#tutorials
Thanks,
Arthur

Figured it out, had to change the tcl script and constraint file and now it works as expected

We can't speak to everything yet, but here are a couple of pieces from the specs, and please let us know if you have more questions:
Sample memory is improved by about 2x over the AD2, max 32 KiS internal storage per channel in various instruments, and the Scope can use 64 KiS with a single channel. Buffers can still be traded around between instruments depending on the device configuration, so the actual size depends on the selected configuration. There's a 7-series Xilinx FPGA inside instead of a Spartan 6. The maximum sample rate can be increased to 125 MS/s from a default of 100. Connectivity is USB 2.0 over a USB-C® connector, so don't necessarily expect a drastic change in record mode maximum rates - it is still improved, I believe some folks internally have hit 10 MS/s on one channel to PC RAM with the scope. Voltage ranges are the same 5 V peak-to-peak low range and 50 V peak-to-peak high range as the AD2, selected in the app depending on the range setting of the channel. Thanks,
Arthur

The xiicps driver is the driver for the Zynq PS's hard IIC controller rather than the soft-core AXI IIC used inside the PmodTMP IP. Drivers for the PmodTMP should be included in the hardware platform project, including example code. You should be including the "PmodTMP.h" header. It would also be possible to reconfigure the Vivado project to map a hard PS IIC controller to Zynq EMIO and connect it to the relevant Pmod pins, in order to save FPGA resources and use the xiicps driver, but that would potentially be more work than trying to use what you've already got. In that scenario, you'd also potentially need to map the other Pmod pins to EMIO GPIO or an AXI GPIO, and rewrite software found in the PmodTMP drivers.
Thanks,
Arthur

I found my answer at:
https://digilent.com/reference/programmable-logic/documents/git
 

Hi @analog57
You can check the Vivado project out from cloned sources using the process described here: https://digilent.com/reference/programmable-logic/eclypse-z7/git#vivado_hw_repositories. The Vivado project sources are in the hw folder of the root repo that is cloned in the demo project setup instructions, like here: https://digilent.com/reference/programmable-logic/eclypse-z7/demos/zmod-scope.
The projects provided through GitHub only have a single Zmod Scope connected up in hardware.
Thanks,
Arthur

Hi @mahinay
Are you trying to package everything in that hierarchy into one IP? There would be a fair amount of difficulty in doing that, since that IP would also then be responsible for providing all drivers and everything else to the Vitis platform, for example.
If you are trying to package everything so that it is relatively easy to recreate a portion of a design in another Vivado project, I would recommend looking into the write_bd_tcl command with the -hier_blks argument. It will generate a script that can be used to recreate your blocks in another block design.
https://docs.xilinx.com/r/2020.2-English/ug835-vivado-tcl-commands/write_bd_tcl
Thanks,
Arthur

Hi @Francesco Crevatin,
Yes, you can decode buses to hex or ASCII, or several other formats, with just the base WaveForms application. Decoded values can also be used to trigger acquisitions.

This also works with protocols in the logic analyzer instrument, so that you can view decoded values alongside the samples:

Thanks,
Arthur

What, exactly are you referring to by USB data rate?

Are you trying to use the UART? The FTDI *H USB bridge device UARTs can support up to 12 Mbaud, though you will need to use the D2XX driver and API on the USB Host side. Most other USB bridge devices support up to 3 Mbaud. Windows COM devices go up to 921600 baud if you set the baud rate from Windows Device Manager. This is suitable for USB UART communication without any flow control. I've used Putty on Win10 to communicate to an Orangepi board at 1.5 Mbaud with no flow control. All of this information pertains to ascii data, not binary data.

If you want to pass data between your board and your PC you might find this tutorial interesting: https://forum.digilent.com/topic/24531-debugging-with-the-ftxxxx-mini-modules/

The short answer is that 921600 baud rate ( ~ 90K Bytes/s ) with no flow control for ascii text characters is pretty easy for a host TTY or COM device. Above that the answer gets complicated. I don't know of any USB bridge device that supports baud rates over 12 Mbaud. Note that FTDI devices that support high baud rates can do 8 Mbaud and 12 Mbaud but nothing in between without baud rate aliasing.

I think that it might be helpful if you provided some information about what you want to do.

Note: The Nexys Video and Genesys2 boards support DPTI mode for binary data communications at 30+ MB/s. Unfortunately, trying to add this capability to the Arty A7-100T uis difficult due to the limited IO pins.

Nevermind, I found a simple solution: I'm just passing in the device_handle as a parameter to the module, where I want to link it to the Analog Discovery 2.
 

The proposed fix for moving the Demo declaration to the C file worked for me in 2022.2. Please make sure that the Demo.verbose bit is set, and what error messages are you seeing?

(added the 2022.2 text as the only other change to ensure I was running the right project)
It's possible that an IP minor version change in the I2C controller could be affecting things, but the changes between rev 2.0 and 2.1 of AXI IIC appear to be pretty small.
To check possible differences, what revision of the board do you have (mine's a new rev F), and have you successfully run the demo in 2018.2?
Thanks,
Arthur
 

Hi @RAJAT99,
I was able to get the project set up in Vivado 2018.2 using the release files as described in the readme, without encountering errors, and managed to record audio from line in and play it back over hph out. What version of the tools are you using, and what are the specific errors you encountered?
Thanks,
Arthur

The oldest version of the Zedboard board files I can find on our Github specifies revision D.3: https://github.com/Digilent/vivado-boards/tree/9926feb0998c04eb82fdf30883f2ebbf20a2dfd8. These may still work for the Rev B, but I can't confirm.
Some of the older support materials for the Zedboard can also be found here: https://github.com/Digilent/Zedboard-old, can't tell which rev it targets, but the DMA demo in there also has Zynq settings.
Apologies to not be of more help,
Arthur

All QSPI lines except for clock are always user I/O pins, so your design can always use them, as for the clock, Xilinx provides a special primitive STARTUPE2 which allows user designs to output the clock for the QSPI flash, however specifically in the case of CMOD, they've connected another user I/O pin to the clock line such that your design can output clock through that pin directly (vs via STARTUPE2 primitive). All dual-purpose pins are completely in the user design's hands once configuration is over, FPGA itself will never interfere in any way.

No problem!
Referring to the ZC702 datasheet, particularly "User PMOD GPIO Headers" starting on page 49, it looks like you may need to wire the Pmod to the eight Pmod1_# and Pmod2_# pins using some additional cabling, as there isn't a full 2x6 connector with FPGA-connected IO.
Thanks,
Arthur

Hi to the community,
I have refreshed this design. Now with support for:
Digilent Inc. Arty S7-25 FPGA development board containing a small Xilinx Spartan-7 FPGA Digilent Inc. Arty A7-100 FPGA development board containing a large Xilinx Artix-7 FPGA Digilent Inc. Zybo Z7-20 APSoC development board containing a moderate Xilinx Zynq-7000 SoC There are four designs total. 3 IPI-BD designs plus a C program, one for each of the mentioned development boards. And 1 straight Verilog-HDL design that targets either of the Arty A7 and Arty S7 boards.
The examples are kept at beginner level and are based on textbook and datasheet study, as well as HDL and FPGA work experience.
The Pmod HYGRO is polled and then its readings displayed in human-readable text on the 16x2 LCD.
Read more at:
https://timothystotts.github.io/2023/04/30/refresh-of-the-fpga-iic-hygro-tester.html
Cheers.
Tim S.
 

Great post! It's always shocking just how simple a straightforward tcl build script is. It's subjectively so much easier to "just get in and start designing" when you don't need to fire up multiple heavy applications just to use a text editor, or go ten levels of UI deep to change some IP setting in a wizard.
Worth noting here that the write_bd_tcl command that is often used to automatically generate scripts to recreate block designs has some optional flags that allows you to ignore the version numbers of IP being included into a project. That doesn't get around the fact that IP changing versions between Vivado versions comes with the possibility that the ports and parameters don't match up, but at least the script can try to add it.
Also with regards to the IP integrator, the following shows up in every block design TCL script, and really underscores how valuable just going in and seeing what you can make happen in text editors, without the Vivado GUI, really is.
There are several similar posts that have been floating around, hwjedi and starware design's come to mind.

Boy did I sorely misunderstand the intent of the Xilinx code related to interrupt processing on the Uarts.  Here's what I learned through debugging (though I still see a few odd things with the debugger).  Again, I imagine most people figured this out on their own but just in case someone is reading in the future, maybe they find this useful.  Much of the code is similar or identical to what is in the example interrupt application, but I may have formatted it differently or made minor changes (to the interrupt mask, for example).
At the top of my file...
#define TEST_BUFFER_SIZE 12 static u8 DebugRecvBuffer[TEST_BUFFER_SIZE]; /* Buffer for Receiving Data */ The first code window below is my function that initializes the Uart. 
Note in step 4 the stuff to set the format that is commented out.  Those are the default settings anyway so they aren't needed, just there to show how to reset and to comment that the Uart needs to be disabled before changing the baud rate. Also note that mask that is being set which will interrupt on XUARTPS_IXR_RXFULL | XUARTPS_IXR_RXOVR (so when the receive FIFO is full or when the receive FIFO is above the interrupt threshold (which is set to 5 in the call to XUartPs_SetFifoThreshold)).  
Note in step 5 that the XUartPs_InterruptHandler mentioned is part if the XUartPs software - not the user ISR and it this line shouldn't be changed.  Some comments about that function (XUartPs_InterruptHandler) later.
Note in step 6 that this is where the user ISR is set (my ISR function is called UartISR).
Finally note in step 8 that the function XUartPs_Recv() is called.  Calling this function resets the XUartPs ReceiveBuffer items (RequestedBytes, RemainingBytes, and NextPtr).  This is important because the user ISR is only called when the ReceiveBuffer is full.
So with this init function, every time 5 bytes are received, the XUartPs_InterruptHandler is called by the processor.  And every time 12 bytes are received (TEST_BUFFER_SIZE), the user ISR is called (essentially by the XUartPs_InterruptHandler() function).
int InitUart(XScuGic *ptrGic, XUartPs *ptrUart, u16 UartDeviceId, u16 UartInterruptId) { int Status; u32 IntrMask; XUartPs_Config *ptrConfig; /* --------------------------------------------------------------------- * ------------ STEP 1: DEVICE LOOK-UP ------------ * -------------------------------------------------------------------- */ ptrConfig = XUartPs_LookupConfig(UartDeviceId); if (ptrConfig == NULL) {return XST_FAILURE;} /* --------------------------------------------------------------------- * ------------ STEP 2: DRIVER INITIALIZATION ------------ * -------------------------------------------------------------------- */ Status = XUartPs_CfgInitialize(ptrUart, ptrConfig, ptrConfig->BaseAddress); if (Status != XST_SUCCESS) {return XST_FAILURE;} /* --------------------------------------------------------------------- * ------------ STEP 3: SELF TEST ------------ * -------------------------------------------------------------------- */ Status = XUartPs_SelfTest(ptrUart); if (Status != XST_SUCCESS) {return XST_FAILURE;} /* --------------------------------------------------------------------- * ------------ STEP 4: PROJECT-SPECIFIC CONFIGURATION ------------ * -------------------------------------------------------------------- */ XUartPs_DisableUart(ptrUart); // UG5985 says to make sure the UART is disabled before writing to baud rate gen // XUartPsFormat psFormat; // psFormat.BaudRate = 115200; // psFormat.DataBits = XUARTPS_FORMAT_8_BITS; // psFormat.Parity = XUARTPS_MR_PARITY_NONE; // psFormat.StopBits = XUARTPS_MR_STOPMODE_1_BIT; // XUartPs_SetDataFormat(ptrUart, &psFormat); //IntrMask = XUARTPS_IXR_RXFULL | XUARTPS_IXR_RXEMPTY | XUARTPS_IXR_RXOVR; IntrMask = XUARTPS_IXR_RXFULL | XUARTPS_IXR_RXOVR; XUartPs_SetInterruptMask(ptrUart, IntrMask); XUartPs_SetOperMode(ptrUart, XUARTPS_OPER_MODE_NORMAL); XUartPs_SetFifoThreshold(ptrUart, 5); // After this value, the RXOVR interrupt will hit the XUartPs_InterruptHandler /* --------------------------------------------------------------------- * ------------ STEP 5: ADD TO INTERUPT SYSTEM ------------ * -------------------------------------------------------------------- */ Status = XScuGic_Connect(ptrGic, UartInterruptId, (Xil_ExceptionHandler)XUartPs_InterruptHandler, (void *)ptrUart); if (Status != XST_SUCCESS) {return Status;} /* --------------------------------------------------------------------- * ------------ STEP 6: SET A HANDLER TO BE CALLED(back) WHEN EVENT OCCURS ------------ * -------------------------------------------------------------------- */ XUartPs_SetHandler(ptrUart, (XUartPs_Handler)UartISR, (void *)ptrUart); /* --------------------------------------------------------------------- * ------------ STEP 7: ENABLE THE INTERRUPT ------------ * -------------------------------------------------------------------- */ XScuGic_Enable(ptrGic, UartInterruptId); /* --------------------------------------------------------------------- * ------------ STEP 8: ENABLE THE UART ------------ * -------------------------------------------------------------------- */ XUartPs_EnableUart(ptrUart); /* --------------------------------------------------------------------- * ------------ STEP 8: RESET RECEIVEBUFFER ITEMS ------------ * -------------------------------------------------------------------- */ // Reset the ptrUart.ReceiveBuffer items (RequestedBytes, RemainingBytes, and NextPtr) // This is needed to eventually allow the user ISR to be called. XUartPs_Recv(ptrUart, DebugRecvBuffer, TEST_BUFFER_SIZE); // After TEST_BUFFER_SIZE bytes are received, the user ISR will hit. return XST_SUCCESS; } Quick look at XUartPs_Recv()...  The main thing to note (at least to me) is that before calling the XUartPs_ReceiveBuffer() function, this function resets the RequestedBytes , RemainingBytes, and NextBytePtr values).  This is important because the user ISR is only called when the RemainingBytes counter reaches 0.
u32 XUartPs_Recv(XUartPs *InstancePtr, u8 *BufferPtr, u32 NumBytes) { u32 ReceivedCount; u32 ImrRegister; /* Assert validates the input arguments */ Xil_AssertNonvoid(InstancePtr != NULL); Xil_AssertNonvoid(BufferPtr != NULL); Xil_AssertNonvoid(InstancePtr->IsReady == XIL_COMPONENT_IS_READY); #if defined (XCLOCKING) Xil_ClockEnable(InstancePtr->Config.RefClk); #endif /* * Disable all the interrupts. * This stops a previous operation that may be interrupt driven */ ImrRegister = XUartPs_ReadReg(InstancePtr->Config.BaseAddress, XUARTPS_IMR_OFFSET); XUartPs_WriteReg(InstancePtr->Config.BaseAddress, XUARTPS_IDR_OFFSET, XUARTPS_IXR_MASK); /* Setup the buffer parameters */ InstancePtr->ReceiveBuffer.RequestedBytes = NumBytes; InstancePtr->ReceiveBuffer.RemainingBytes = NumBytes; InstancePtr->ReceiveBuffer.NextBytePtr = BufferPtr; /* Receive the data from the device */ ReceivedCount = XUartPs_ReceiveBuffer(InstancePtr); /* Restore the interrupt state */ XUartPs_WriteReg(InstancePtr->Config.BaseAddress, XUARTPS_IER_OFFSET, ImrRegister); return ReceivedCount; } The XUartPs_ReceiveBuffer() function isn't that interesting.  It really just fills the buffer from the Uart's FIFO (and it will call the user ISR if there is a frame error) so I didn't post it here (easy enough to look at yourself).
Similarly, the XUartPs_InterruptHandler() function isn't worth posting here - it's pretty straightforward and just looks at the interrupt that happened before calling one of several other functions depending on the interrupt type.  One of those functions I do show next though: ReceiveDataHandler().
Note that this function - besides getting any characters that are new since the interrupt happened with the call to XUartPs_ReceiveBuffer() - is responsible for calling the user ISR once the remaining bytes int he user's receive buffer (size TEST_BUFFER_SIZE in my case) reaches 0.  Also to note that no additional calls to the user ISR will happen unless the ReceiveBuffer items are reset with a new call to XUartPs_Recv().  The skeleton of my user ISR is shown at the end.
static void ReceiveDataHandler(XUartPs *InstancePtr) { /* * If there are bytes still to be received in the specified buffer * go ahead and receive them. Removing bytes from the RX FIFO will * clear the interrupt. */ if (InstancePtr->ReceiveBuffer.RemainingBytes != (u32)0) { (void)XUartPs_ReceiveBuffer(InstancePtr); } /* If the last byte of a message was received then call the application * handler, this code should not use an else from the previous check of * the number of bytes to receive because the call to receive the buffer * updates the bytes ramained */ if (InstancePtr->ReceiveBuffer.RemainingBytes == (u32)0) { InstancePtr->Handler(InstancePtr->CallBackRef, XUARTPS_EVENT_RECV_DATA, (InstancePtr->ReceiveBuffer.RequestedBytes - InstancePtr->ReceiveBuffer.RemainingBytes)); } } My user ISR skeleton.  Note the call at the end to XUartPs_Recv() to reset the ReceiveBuffer items so this ISR will eventually be called again.  Also note the //! lines which is the place something should be done with the info in the user ReceiveBuffer before we reset it.
void UartISR(void *CallBackRef, u32 Event, unsigned int EventData) { XUartPs *ptrSenderXUart = (XUartPs *) CallBackRef; // Send some relevant info about the event to the stdio xil_printf("ISR: Event: %i, EventData: %i, Remaining: %i, NextPtr: 0x%X\r\n", Event, EventData, ptrSenderXUart->ReceiveBuffer.RemainingBytes, &ptrSenderXUart->ReceiveBuffer.NextBytePtr); // Do something with the DebugRecvBuffer because we are about to reset it... //! //! //! // Reset the ReceiveBuffer items so this ISR will be called again XUartPs_Recv(ptrSenderXUart, DebugRecvBuffer, TEST_BUFFER_SIZE); } Now I haven't yet decided how best to use this info for the circumstance I mentioned with my 5 and 27 byte expected messages.  But I'm closer.  I hope someone else finds this useful.  It was useful for me to type, either way. :-)

That is exactly why I try to avoid writing constraints manually and instead prefer using GUI for that, as it greatly reduces chance of making silly mistakes like that one.

I integrated the VERA (Versatile Embedded Retro Adapter) core into BoxLambda: https://epsilon537.github.io/boxlambda/integrating-vera/

Hi Arthur, 
Sorry for late reply. Thank you for providing the link. The PMTK documentation helps a lot. The GPS performance improve a lot after reconfiguration.
Best Regard,
Jack Lu
 
For those who have similar problem, the PMTK can help improve the PmodGPS sensor, by enabled different mode. Also, you can use this to write the EPO file, to improve the oribt prediction. It would be a little  better than build-in EASY mode. It is important to remember to write the initial time and location. As far as the RTCM, I think it would be difficult to acquire any info to enable this function. According to my trace, the company, Gtop GPS division, has been sold to Sierra. But Sierra cannot provide any info for how to enable it. 
If you have the need to improve the accuracy, I would suggest to take a look at other GNSS module. Remember paying attention to the mode supported by the GNSS you selected. Some of them only support two system at same time. However, according to my experiment, smartphone build-in GNSS block mostly support 4 system simultaneously. Also, if your application is ASIC like me, I would suggest to use serial communication between the FPGA and GNSS modules. According to my experience, most GNSS modules at least support this interface.
Hope this will helps others.
 

I have been able to fix this issue by upgrading to vitis 2022.2, creating a new application project and importing my project's code. I flashed the sd card image generated during the debug build, PS program worked as expected.

Hello everyone! My name is David, and I am so excited to have found this forum and be a part of it. I am a huge fan of Digilient products and own, or have owned, the Basys 3, Nexys A7-50T, Nexys Video, Cora Z7 with 7010, Zybo Z7 with 7020, Cmod A7, Analog Discovery 2, and a plethora of PMODs including Keypad, Temp Sensor, Rotary Encoder, Accelerometer, OLED, and many more I cannot remember them all. 
I fell in love with digital design during college and learned the Verilog language and FPGA programming all on my own. I have had some successes and some failures, but I just keep going.

Thank you!! Clicking on Status->Install worked!