Tim S.

Members
  • Content Count

    24
  • Joined

  • Last visited

Everything posted by Tim S.

  1. Hi @vttay03, @jpeyron, I may have a solution to this problem for you. I am working with a Arty A7-100T; and I am designing material that mostly does not make use of a Microblaze / AXI setup. From a different tutorial, I learned that this board should be configured to operate the boot-up at 33 MHz instead of the default of 3 MHz. Also, the configuration modes should be both JTAG and Master-SPI-x4 selected for the bitstream configuration. By default, a new project in Vivado 2019.1 with the Arty-A7-100 boad selects only configuration of JTAG and no configuration is selected for Flash memory. These options can be found under Open Implemented Design | Tools | Edit Device Properties... Note that I've noticed that the Arty A7-100T may have a power-on failure where the board only operates correctly if PROG_B is pressed once after adding power by plugging-in USB-A port. Tim S.
  2. Thanks, @JColvin, I have a few additional questions. The schematic shows IC1 as part N25Q512A836SF40G . I was unable to find this exact part on DigiKey, though there are similar part numbers. Also, the reference manual lists an older and smaller flash part, the N25Q256A. Can you clarify? The part is now populated with the larger and newer part due to sourcing supply and demand? Also, the part number or serial on the IC is: 7JD1 7ZAI5 RW243 with logo ISA . Can you clarify if this is a generic N25Q256 or N25Q512 ? Tim
  3. Hi. I work with FPGAs and other embedded systems for a living. I am going through self-directed learning on the Zybo-Z7 and the Arty-A7, with FPGA design textbooks. The Analog Discovery 2 has been a great help with this; and I have authored a few custom Pmod drivers direct in the FPGA logic that do not require a processor system with AXI. One project I authored as a fun experiment for the Arty-A7 was to drive both text on the Pmod OLEDrgb and a PWM mix duty cycle on the 4 discrete RGB LEDs with custom 24-bit RGB color mixing values to compare PWM scaling of the discrete RGB against the 16-bit color of the Pmod OLEDrgb. I have achieved numerous color blends on the discrete RGB LEDs. Tim
  4. I purchased a Pmod SF3. The Reference Manual and the anti-static packaging document Pins 7, 8, as No Connect. The Schematic documents Pin 7 as No Connect and Pin 8 as Flash Chip Reset signal. Can someone clarify the discrepancy? Tim
  5. I am using the PMOD CLS to develop a custom CLS driver via the SPI interface. The PMOD CLS data sheet did not define the protocol, so I used the Analog Discovery 2 to watch the SPI traffic of the Digilent PMOD CLS driver in a Microblaze architecture on a Arty A7-100T board. The FPGA signals are SS, MOSI, MISO, SCK. For my design, MISO is an input that is optimized away for lack of logic connection. The SS, SCK, and MOSI are operated the same as the C api calls from the PMOD CLS BSP driver. With the Digilent driver, I can control the two lines of text to display any text. With my own driver, I believe the only issue is that their are several nanosecond duration spikes on the SS signal during a data transfer. This interferes with the escaped commands ESC]digit;digitdigitCMD as well as the text data. The spikes appear random: SS is held low and for nanoseconds the SS may rise to a value of '1'. Note that I am driving the PMOD CLS via JB of the Arty A7-100T. The jack JB is a high-performance port. I am running the SCK at 625 kHz. Has anyone seen spikes like this before on the SS and found a solution? Thanks.
  6. Hi @jpeyron, Regarding your question on the KYPD: with the clock wizard set as discussed, the MIG UI clock is 86 MHz. If I use the KYPD driver as-is, the GPIO will poll at a frequency based on the CPU clock of the Microblaze. This caused some keys to not be read, or to be read as multiple keys pressed. Only about 1/2 of the keys would detect properly. To solve this, I added a micro sleep call to allow the GPIO of the KYPD columns to settle before polling the rows. With this modification, all of the keys detect correctly using the demo code. u16 KYPD_getKeyStates(PmodKYPD *InstancePtr) { u32 rows, cols; u16 keystate; u16 shift[4] = {0, 0, 0, 0}; // Test each column combination, this will help to detect when multiple keys // in the same row are pressed. for (cols = 0; cols < 16; cols++) { KYPD_setCols(InstancePtr, cols); usleep(5); rows = KYPD_getRows(InstancePtr); // Group bits from each individual row shift[0] = (shift[0] << 1) | (rows & 0x1); shift[1] = (shift[1] << 1) | (rows & 0x2) >> 1; shift[2] = (shift[2] << 1) | (rows & 0x4) >> 2; shift[3] = (shift[3] << 1) | (rows & 0x8) >> 3; } // Translate shift patterns for each row into button presses. keystate = 0; keystate |= KYPD_lookupShiftPattern(shift[0]); keystate |= KYPD_lookupShiftPattern(shift[1]) << 4; keystate |= KYPD_lookupShiftPattern(shift[2]) << 8; keystate |= KYPD_lookupShiftPattern(shift[3]) << 12; return keystate; } Thanks, Tim
  7. Just to make sure my explanation is thorough. The above has a typo. It should read: Linux has a case-sensitive file system whereas Windows has a case-insensitive file system.
  8. Hi @jpeyron, The following solved the missing xspi. 1. Rename pmodOLEDrgb to PmodOLEDrgb under Vivado-library . 2. Add the PmodOLEDrgb IP to the block design. 3. Open the IP in IP Packager. 4. Under File Groups, rename the path driver/pmodOLEDrgb for the xspi to have capital 'P' for Pmod instead of lowercase, for each file. 4. Retarget the IP submodules to Arty A7 100. 5. Regenerate the IP module in the IP packager editor. 6. Close the subproject that opened for PmodOLEDrgb. 7. Remove the IP from the block design. 8. Delete the hardware description from project and file system in the SDK. 9 Re-add the PmodOLEDrgb to the block design, and then Regenerate top design bitstream. 10 Export hardware with bitstream to SDK. 11. Open in SDK from Vivado menu. Best, Tim
  9. Hi @jpeyron, I have a successful design with KYPD and OLEDrgb. The only bug is the ABCD column of the keypad indicates multiple key press and the correct key, at the same time. Thank you for your assistance. Best regards, Tim
  10. Hi @jpeyron, I discovered why the xspi sources are missing. Linux has a case-sensitive file system whereas Windows has a case-sensitive file system. The packaging of the PmodOLEDrgb has mixed folder name alphabet-case of the first character 'p' in the folders PmodOLEDrgb. This causes silent errors on Linux whereas I presume there would be no error on Windows. Best, Tim
  11. Hi @jpeyron, I previously copied the Vivado board files under 2019.1/data/boards/board_files for both the /opt/Xilinx/Vivado/ and /opt/Xilinx/SDK/ directories on Linux. I have had problems with the Vivado_Init.tcl approach where Vivado was inconsistent in finding the additional boards. See this Digilent tutorial. I modified the mig,prj to use the correct 100T (as opposed to 35T) part. Also, the PMOD IP from vivado-library was originally targeted to the classic Arty board. To solve this, I opened the two PMOD in IP Packager and retargeted the IP submodules to Arty A7 100. I noticed that the OLEDRGB PMOD contained the xspi sources in the IP packaging. The system.hdf says as shown in the screenshot. It has the FPGA part selected without the board, as you noticed. With the OLEDrgb removed from the project and only kypd preset, the Microblaze project does execute over JTAG as expected. After adding OLEDrgb, the xspi sources are missing, so the project cannot compile. What option did you select to export the Vivado hardware to the SDK? I use File | Export | Hardware , and I include the bitstream. I select Local to Project. My clocking wizard configuration is the same as your screenshots. Tim
  12. Hi @jpeyron, I switched to the Arty A7-100T. I have imported the latest master git branch of the Digilent vivado-library for use in Vivado 2019.1 . The same missing files compilation error exists. See a screenshot below. Regards, Tim
  13. I am trying to design a PL block design and SDK application to exercise the Pmod KYPD and Pmod OLEDrgb together with Vivado 2019.1 . I downloaded the Vivado-library git release for Vivado 2019.1 . In the SDK, I notice that driver PmodOLEDrgb.h is missing source files xspi.h and xspi_l.h . Where do these sources come from? Tim S.
  14. Hi @jpeyron, The base-linux project provides a complex and highly configurable IP Core for the MIPI RX as part of the Board Design. The core is not included under repo/ of the design. It cannot be customized without a license. And it cannot be synthesized without a license. The name of the MIPI RX also differs from the simpler model of the PCam 5 demo. The demo provides MIPI_CSI_2_RX_0 which is an instance of "MIPI CSI-2 Receiver v1.1". The linux base utilizes an absent mipi_csi2_rx_subsystem_0 which is an instance of "MIPI CSI-2 Rx Subsystem v1.0" containing unlicensed core "MIPI CSI-2 Rx Controller v3.0" (Product Guide 232?). Regards, Tim
  15. Specifically, I am using the WebPACK without the SDSoC voucher.
  16. Hi @jpeyron, I am also using Vivado 2017.4 with SDK and support for Zynq-7000 family only. Tim
  17. The exact error message is "Unlicensed Upgrade IP. Check IP license". The needs purchase link indicates minimum version of Vivado as 2017.10 .
  18. Hi @jpeyron, I am unable to upgrade the IP core. Vivado indicates a need to purchase the IP core. Is this IP core not free with WebPACK? Would the SDSoC license voucher provide access to this core? Best regards, Tim
  19. I downloaded Zybo Z7-20 base linux project from git and ran the create_project.tcl script. On the system.bd, there are IP that require a license and are not gratis license. Specifically, the /mipi_csi2_rx_subsystem_0 requires an IP Core license for its sub-component bd_0ac3_rx_0 which.is MIPI CSI-2 Rx Controller. How can I proceed from here for generating a working Zybo Z7-20 linux demo? Thanks. Tim
  20. Tim S.

    Zybo Z7-20 audio interrupt

    Hi @jpeyron, I have examined some of the d_axi_i2s_audio Digilent IP Core sources. It appears that the control of the fifo_4 and fifo_32 fifo instances might be dependent on the AXI4 Stream and AXI4 Lite all running on the same clock. I had attempted to run the AXI4 Lite at 50 MHz and the AXI4 Stream run at a matching-phase 100 MHz. Best I can tell from the STATUS register is that the FIFOs fill with data and then are not dequeued. If I utilize a second M_GP (M_GP1) on the Zynq 7 Processing System and execute it at 100 MHz instead of 50 MHz; and interconnect the Audio DMA cores all at the same 100 MHz; then the audio I2S functions according to the Audio DMA example. Best regards, Tim
  21. I have merged the Pcam5C and DMA projects to gain an understanding of the IP Integrator and Xilinx SDK. I am not receiving an interrupt on s2mm_introut of axi_dma_0 of the sound DMA part of the example. In main.cc, I have merged-in the demo.c main procedure. irpt_ctl.registerHandler(XPAR_FABRIC_AXI_GPIO_0_IP2INTC_IRPT_INTR, reinterpret_cast<typename ScuGicInterruptController::Handler>(&fnUserIOIsr), &sUserIO); irpt_ctl.registerHandler(XPAR_FABRIC_AXI_IIC_0_IIC2INTC_IRPT_INTR, reinterpret_cast<typename ScuGicInterruptController::Handler>(&XIic_InterruptHandler), &sIic); irpt_ctl.registerHandler(XPAR_FABRIC_AXI_DMA_0_MM2S_INTROUT_INTR, reinterpret_cast<typename ScuGicInterruptController::Handler>(&fnMM2SInterruptHandler), &sAxiDma); irpt_ctl.registerHandler(XPAR_FABRIC_AXI_DMA_0_S2MM_INTROUT_INTR, reinterpret_cast<typename ScuGicInterruptController::Handler>(&fnS2MMInterruptHandler), &sAxiDma); irpt_ctl.enableInterrupts(); To use the same ScuGicInterruptController.h already provided by the Pcam5C, I have added a call to XScuGic_SetPriorityTriggerType(). template <typename ...Arg> Errc registerHandler(uint32_t irpt_id, Handler handler, Arg&& ...args) { XStatus Status; Status = XScuGic_Connect(&drv_inst_, irpt_id, (Xil_InterruptHandler) handler, std::forward<Arg>(args)...); if (Status != XST_SUCCESS) { return XST_FAILURE; } //Enable the interrupts for the IIC device. this->enableInterrupt(irpt_id); // XScuGic_Enable(&drv_inst_, irpt_id); return XST_SUCCESS; } Errc disableInterrupt(uint32_t irpt_id) { XScuGic_Disable(&drv_inst_, irpt_id); return XST_SUCCESS; } Errc enableInterrupt(uint32_t irpt_id) { XScuGic_SetPriorityTriggerType(&drv_inst_, irpt_id, 0x00, 0b11); XScuGic_Enable(&drv_inst_, irpt_id); return XST_SUCCESS; } I receive an interrupt that writes to Demo.fDmaMM2SEvent, but no interrupt that writes to Demo.fDmaS2MMEvent. Thus the recording never completes; but playback does complete without a recording. I need to understand how to display the Zynq 7 Processing System ARM-9 interrupt registers and Xilinx AXI DMA status/control registers in the SDK Debug Perspective. I also need to understand the necessity of XScuGic_SetPriorityTriggerType for adding edge/level with priority configuration, of peripheral IRQs. Where can I find relevant documentation besides AXI DMA IP product guide?
  22. @jge64: I have built the pcam example with Vivado 2016.4 and Vivado 2018.2 . With 2016.4 I observed an error with processing with RGB color space turned on. With 2018.2 I observed a refresh rate error at 15 fps. I do not know if @jpeyron is accurate that the timing closure error is benign.
  23. Hi @jpeyron, I followed the Digilent on-line documentation for the project and the demo is working on my board. Thank you for confirming in advance that the timing issue on the "special" IO Delay Buffer instances can be ignored. I will go ahead and read the relevant Xilinx App Note on the special IO Delay Buffer configuration for my own edification. Best, Tim
  24. The current ZIP-file release of the Zybo Z7-20 pcam-5c demo does not achieve timing closure with Xilinx Vivado 2016.4 . The constraint from ZyboZ7_A.xdc: create_clock -period 2.976 -name dphy_hs_clock_p -waveform {0.000 1.488} [get_ports dphy_hs_clock_clk_p] does not achieve timing closure for two signal paths in system_i/MIPI_D_PHY_RX_0, both related to DDLY A B Name Path 62 Slack -3.303ns Source dphy_data_hs_n[0] (input port clocked by dphy_hs_clock_p {rise@0.000ns fall@1.488ns period=2.976ns}) Destination system_i/MIPI_D_PHY_RX_0/U0/DataLaneGen[0].DPHY_LaneSFEN_X/HSDeserializerX/Deserializer/DDLY (falling edge-triggered cell ISERDESE2 clocked by dphy_hs_clock_p {rise@0.000ns fall@1.488ns period=2.976ns}) Path Group dphy_hs_clock_p Path Type Setup (Max at Fast Process Corner) Requirement 1.488ns (dphy_hs_clock_p fall@1.488ns - dphy_hs_clock_p rise@0.000ns) Data Path Delay 1.822ns (logic 1.822ns (100.000%) route 0.000ns (0.000%)) Logic Levels 2 (IBUFDS=1 IDELAYE2=1) Input Delay 4.250ns Clock Path Skew 1.372ns Clock Uncertainty 0.035ns I would like to request information as to how I may solve timing closure for the MIPI_D_PHY_RX. This is an unmodified project.