Tim S.

  • Content Count

  • Joined

  • Last visited

Everything posted by Tim S.

  1. 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
  2. Specifically, I am using the WebPACK without the SDSoC voucher.
  3. Hi @jpeyron, I am also using Vivado 2017.4 with SDK and support for Zynq-7000 family only. Tim
  4. The exact error message is "Unlicensed Upgrade IP. Check IP license". The needs purchase link indicates minimum version of Vivado as 2017.10 .
  5. 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
  6. 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
  7. 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
  8. 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?
  9. @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.
  10. 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
  11. 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.