Todd-Kairos

Hi Arthur, Thanks for this information. I haven't been monitoring ZmodAWGController:sInitDoneDAC or sConfigError, but I'm typically waiting 1 sec between reset attempts so I don't think there is a problem of not waiting long enough. I may try to measure the reset behavior following your suggestion above, by adding a breakout board to an unused SYZYGY port and routing copies of interesting reset-related signals to pins I can monitor on an oscilloscope (it is difficult to monitor initial reset behavior on the ILA when booting from the SD card because it takes a while to start/trigger the ILA). I posted a copy of this project just now as it relates to a separate question if you want to take a look. Thanks. Todd

Hi Arthur, Sorry it took me so long to respond. I had a lot of trouble getting a Digilent Scope Zmod ADC 1410-40 module to work on the Brain SYZYGY Port C, so I connected the Digilent Zmod AWG 1411 to Port C instead, and used Ports A & D for my 2 Scope modules. This worked much better and I'm able to get them to operate (generating sinewaves on the AWG measuring them on the Scopes). However, there are still some very concerning warnings that I would like to address since these could cause problems or unreliability. Synthesis seems OK, but Implementation Route Design reports look problematic: particularly DRC - Route Design and Methodology - Route Design. Some specific items of concern: I defined pblocks for the hierarchy related to the AWG and each Scope module. It seems that these don't quite fit when placed, but I'm not sure how it still seems to work and does not report a critical error in this case. Here are the warnings from the DRC - Route Design report: UTLZ-3#1 Warning Resource utilization - PBlock:pblock_adc_hier_PortA DSPs over-utilized in Pblock pblock_adc_hier_PortA (This design requires more DSPs cells than are available in Pblock 'pblock_adc_hier_PortA'. This design requires 10 of such cell types but no compatible site is available in Pblock 'pblock_adc_hier_PortA'. Please consider increasing the span of Pblock 'pblock_adc_hier_PortA' or removing cells from it.) Related violations: <none> UTLZ-3#2 Warning Resource utilization - PBlock:pblock_adc_hier_PortD DSPs over-utilized in Pblock pblock_adc_hier_PortD (This design requires more DSPs cells than are available in Pblock 'pblock_adc_hier_PortD'. This design requires 10 of such cell types but no compatible site is available in Pblock 'pblock_adc_hier_PortD'. Please consider increasing the span of Pblock 'pblock_adc_hier_PortD' or removing cells from it.) Related violations: <none> UTLZ-3#3 Warning Resource utilization - PBlock:pblock_dac_hier_PortC DSPs over-utilized in Pblock pblock_dac_hier_PortC (This design requires more DSPs cells than are available in Pblock 'pblock_dac_hier_PortC'. This design requires 2 of such cell types but no compatible site is available in Pblock 'pblock_dac_hier_PortC'. Please consider increasing the span of Pblock 'pblock_dac_hier_PortC' or removing cells from it.) Related violations: <none> Methodology - Route Design report excerpts: Note that the clock constraints from the two instances of Zmod ADC appear to conflict with each other. How should this be handled to ensure that both take effect? Should I make 2 copies of this constraint with distinct clock names in one of my main project constraint files? TIMING-17#1 Critical Warning Non-clocked sequential cell The clock pin design_1_i/adc_hier_PortD/ZmodScopeController_D/U0/InstDataPath/GenerateIDDR[0].InstIDDR/C is not reached by a timing clock DPIR-1#1 Warning Asynchronous driver check DSP design_1_i/adc_hier_PortA/ZmodScopeController_A/U0/InstCh2ADC_Calibration/cCalibMult0 input pin design_1_i/adc_hier_PortA/ZmodScopeController_A/U0/InstCh2ADC_Calibration/cCalibMult0/A[10] is connected to registers with an asynchronous reset. This is preventing the possibility of merging these registers in to the DSP Block since the DSP block registers only possess synchronous reset capability. It is suggested to recode or change these registers to remove the reset or use a synchronous reset to get the best optimization for performance, power and area. TIMING-18#1 Warning Missing input or output delay An output delay is missing on ZmodAdcClkIn_n_D relative to the rising and/or falling clock edge(s) of ZmodAdcClkIn. XDCC-1#1 Warning Scoped Clock constraint overwritten with the same name A new clock constraint create_clock overrides a previous scoped clock constraint with the same name. It is not recommended to override a scoped (typically an IP) clock constraint and could result in unexpected behaviors. New: create_clock -period 40.000 -name ZmodDcoClk -waveform {0.000 20.000} [get_ports ZmodDcoClk_A] (Source: /home/todd/kairos/projects/laser/acquisition/syzygy/laser_daq/hdl/block_design/ip/design_1_ZmodScopeController_0_1/ConstrsZmodADC.xdc (Line: 6)) Previous: create_clock -period 40.000 -name ZmodDcoClk -waveform {0.000 20.000} [get_ports ZmodDcoClk_D] (Source: /home/todd/kairos/projects/laser/acquisition/syzygy/laser_daq/hdl/block_design/ip/design_1_ZmodScopeController_0_0/ConstrsZmodADC.xdc (Line: 6)) Related violations: <none> XDCC-1#2 Warning Scoped Clock constraint overwritten with the same name A new clock constraint create_generated_clock overrides a previous scoped clock constraint with the same name. It is not recommended to override a scoped (typically an IP) clock constraint and could result in unexpected behaviors. New: create_generated_clock -name ZmodAdcClkIn -source [get_pins InstADC_ClkODDR/C] -divide_by 1 -add -master_clock [get_clocks -of [get_ports -scoped_to_current_instance -prop_thru_buffers ADC_InClk]] [get_ports ZmodAdcClkIn_p_A] (Source: /home/todd/kairos/projects/laser/acquisition/syzygy/laser_daq/hdl/block_design/ip/design_1_ZmodScopeController_0_1/ConstrsZmodADC.xdc (Line: 1)) Previous: create_generated_clock -name ZmodAdcClkIn -source [get_pins InstADC_ClkODDR/C] -divide_by 1 -add -master_clock [get_clocks -of [get_ports -scoped_to_current_instance -prop_thru_buffers ADC_InClk]] [get_ports ZmodAdcClkIn_p_D] (Source: /home/todd/kairos/projects/laser/acquisition/syzygy/laser_daq/hdl/block_design/ip/design_1_ZmodScopeController_0_0/ConstrsZmodADC.xdc (Line: 1)) Related violations: <none> I have attached an archive of the complete project, plus the 2 report files referenced above. Thanks in advance for your help sorting out these issues! Todd laser_daq_digilent_forum_2023_09_29.zip design_1_wrapper_drc_routed.rpt design_1_wrapper_methodology_drc_routed.rpt

I'm trying to bring up a Zmod ADC 1410-40 on an Opal Kelly Brain-1 carrier. When Vivado tries to Run Implementation, it gives the following errors. [Place 30-126] Unroutable Placement! A BUFIO can only drive loads in the same IO bank. The following BUFIO clock loads are placed too far from the BUFIO to be routable. design_1_i/ZmodScopeController_0/U0/InstDataPath/InstDcoBufio (BUFIO.O) is provisionally placed by clockplacer on BUFIO_X1Y8 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[0].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y95 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[10].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y98 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[11].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y97 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[12].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y94 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[13].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y91 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[1].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y149 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[2].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y111 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[3].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y80 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[4].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y79 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[5].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y138 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[6].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y100 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[7].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y137 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[8].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y96 design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[9].InstIDDR (IDDR.C) is locked to ILOGIC_X1Y112 The above error could possibly be related to other connected instances. Following is a list of all the related clock rules and their respective instances. Clock Rule: rule_gclkio_mmcm_1load Status: PASS Rule Description: An IOB driving a single MMCM must both be in the same clock region if CLOCK_DEDICATED_ROUTE=BACKBONE is NOT set ZmodDcoClk_0_IBUF_inst (IBUF.O) is locked to IOB_X1Y74 design_1_i/ZmodScopeController_0/U0/InstDataPath/MMCME2_ADV_inst (MMCME2_ADV.CLKIN1) is provisionally placed by clockplacer on MMCME2_ADV_X1Y1 Clock Rule: rule_mmcm_bufg Status: PASS Rule Description: An MMCM driving a BUFG must be placed on the same half side (top/bottom) of the device design_1_i/ZmodScopeController_0/U0/InstDataPath/MMCME2_ADV_inst (MMCME2_ADV.CLKOUT1) is provisionally placed by clockplacer on MMCME2_ADV_X1Y1 design_1_i/ZmodScopeController_0/U0/InstDataPath/InstDcoBufg (BUFG.I) is provisionally placed by clockplacer on BUFGCTRL_X0Y31 Clock Rule: rule_mmcm_bufr_bufio Status: PASS Rule Description: An MMCM driving a BUFR/BUFIO must both be in the same clock region design_1_i/ZmodScopeController_0/U0/InstDataPath/MMCME2_ADV_inst (MMCME2_ADV.CLKFBOUT) is provisionally placed by clockplacer on MMCME2_ADV_X1Y1 design_1_i/ZmodScopeController_0/U0/InstDataPath/InstBufrFeedbackPLL (BUFR.I) is provisionally placed by clockplacer on BUFR_X1Y4 Clock Rule: rule_mmcm_bufr_bufio Status: FAIL Rule Description: An MMCM driving a BUFR/BUFIO must both be in the same clock region design_1_i/ZmodScopeController_0/U0/InstDataPath/MMCME2_ADV_inst (MMCME2_ADV.CLKOUT2) is provisionally placed by clockplacer on MMCME2_ADV_X1Y1 design_1_i/ZmodScopeController_0/U0/InstDataPath/InstDcoBufio (BUFIO.I) is provisionally placed by clockplacer on BUFIO_X1Y8 ERROR: The above is also an illegal clock rule Workaround: < set_property CLOCK_DEDICATED_ROUTE ANY_CMT_COLUMN [get_nets design_1_i/ZmodScopeController_0/U0/InstDataPath/DcoPLL_Clk2] > Clock Rule: rule_bufh_bufr_ramb Status: PASS Rule Description: Reginal buffers in the same clock region must drive a total number of brams less than the capacity of the region design_1_i/ZmodScopeController_0/U0/InstDataPath/InstBufrFeedbackPLL (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y4 Clock Rule: rule_bufr_mmcm Status: PASS Rule Description: A BUFR driving an MMCM must be placed within the same clock region design_1_i/ZmodScopeController_0/U0/InstDataPath/InstBufrFeedbackPLL (BUFR.O) is provisionally placed by clockplacer on BUFR_X1Y4 and design_1_i/ZmodScopeController_0/U0/InstDataPath/MMCME2_ADV_inst (MMCME2_ADV.CLKFBIN) is provisionally placed by clockplacer on MMCME2_ADV_X1Y1 I tried adding the suggested workaround to my constraint file, and then got this error (and 7 more like it): [Place 30-512] Clock region assignment has failed. Clock buffer 'design_1_i/ZmodScopeController_0/U0/InstDataPath/InstDcoBufio' (BUFIO) is placed at site BUFIO_X1Y8 in CLOCKREGION_X1Y2. Its loads need to be placed in the area enclosed by clock regions CLOCKREGION_X1Y2 and CLOCKREGION_X1Y2. One of its loads 'design_1_i/ZmodScopeController_0/U0/InstDataPath/GenerateIDDR[13].InstIDDR' (IDDR) is placed in site ILOGIC_X1Y91 in CLOCKREGION_X1Y1 which is outside the permissible area. The Zmod Scope Controller user guide says the following, but does not provide enough details for me to know what constraints to add. I'm generating all the clocks in the design from a single clock wizard, driven by FCLK_CLK3 at 200 MHz, configured with source=global buffer. I'm obviously not very knowledgable about clock routing issues yet, and would really appreciate some help with this. Thanks!

Hi Arthur, I tried to follow the tutorial link you sent to find a way to debug the ZmodAWGController:dZmodDAC_Data[13:0] outputs. From the Synthesis Debug view netlist, I can see nets dZmodDAC_Data_0(14) and dZmodDAC_Data_0_OBUF(14). I could not mark dZmodDAC_Data_0 as debug (option is grayed out), but I could and did mark dZmodDAC_Data_0_OBUF as debug. Synthesis works, but Implementation fails and I get error messages to the effect that ODDR loads should only be an output buffer or a port, but it is driving an invalid load. Any other ideas how to handle this? I suppose editing the ZmodAWGController to add a set of non ODDR outputs would work, but I'm not sure if I can just edit the VHDL files or if I would need to make changes using the IP packaging tools (I don't have experience using those yet). Thanks. Todd

Problem summary: I'm using a Zmod AWG 1411 with an Opal Kelly Brain-1 baseboard and experiencing problems with the reset logic on the Zmod AWG. Whenever I load the image via JTAG cable (Digilent JTAG-HS3), it always immediately gives clean sinusoidal outputs as expected. But often when the system boots off an SD card, it comes up in a state where the DAC outputs are scrambled with large discrete jumps instead of the expected sinusoidal outputs. If I manually generate a logical reset by pressing a user switch (more details in the next paragraph), it always recovers to clean sinusoidal outputs after a single reset - whether it was previously in a correct or incorrect state. Design info: My FPGA code uses a clock wizard with a 200 MHz input to generate 100 MHz (used for throughout my design and for ZmodAWGController:SysClk100 & DAC_InIO_Clk) and 100 MHz/90 (ZmodAWGController:DAC_Clk)) deg phase shifted output clocks - safe clock startup mode is currently off. I have separate Xilinx DDS IP modules driving each of the two DAC channel signals, and a Xilinx Processor System Reset module (includes a clock wizard lock signal input) to reset the DDS and Zmod control IP modules using the peripheral_aresetn output. My project is based off the Opal Kelly Brain "Hello World" example, and consists only of PL code - no PS code. The Zmod controller is the second generation version dated 3/8/2023 (commit #3819e788427d0f70f8d7948c38bcd97b26925157) from the Digilent repository. I mapped Brain user pushbutton #S2 to the auxiliary reset input of the Processor System Reset module. I wanted to rule out that there was any hardware side-effect of the button press (such as loading a power supply), so I wrote some simple logic to generate a reset signal when the switch is depressed and then released. Reset details: As far as I can tell, the DDS always resets correctly (outputs always look correct using the JTAG/ChipScope ILA). The Zmod controller is supposed to have an asynchronous active low reset that must be held low for >2 clock cycles, which should be satisfied by the Processor System Reset peripheral reset output. I don't know if the reset problems are coming from the Zmod controller FPGA module or from the underlying DAC chip. I've tried a variety of strategies to automatically generate a reset on startup that will act the same as manually pressing the reset button and ensure it always comes up in a correct state, but this has not been fully satisfactory. The most successful strategy so far (though it is highly unsatisfying to rely on an arbitrary empirically determined procedure like this) has been to wait a specified number of clocks after the clock wizard lock goes valid (e.g. 5 sec), then execute a number of periodic resets (e.g. 15x) every second. I trigger resets via a custom RTL module that connects to the Processor System Reset ext_reset_in input, and the peripheral_aresetn connects to the DDS aresetn and ZmodAWGController aRst_n inputs. When a reset takes effect properly, it causes a click sound due to the output enable relay on the AWG board. In some cases asserting a reset does not generate a click sound, so I may only hear 7 clicks out of the series of 15 attempts. Simpler ideas I tried like waiting a period a time and then only issuing 1 or 2 resets gave inconsistent performance. I want to make the system boot up deterministically so I have 100% confidence it will run correctly. It is hard for my FPGA code to tell if everything is OK, though it is easy to see visually from the scope output. I'm currently monitoring ZmodAWGController:sZmodDAC_EnOut and cDataAxisTvalid, and issuing another reset if either is deasserted. Questions: Why am I seeing different startup behavior when booting off the SD card compared to using the JTAG cable? Supposedly the ZmodAWGController just needs an asynchronous inverted reset for >= 2 cycles. Is there some other important phase that is important, for example, perhaps one should avoid reseting in the middle of Zmod internal SPI commands, etc.? I could potentially check when Output Enable is first asserted as way to synchronize to the internal state if necessary. Or can there be a discrepancy between the ZmodAWGController and the underlying DAC chip? Is there a way to steal a copy of the ZmodAWGController:dZmodDAC_Data[13:0] ODDR output signals without having to modify the ZmodAWGController code? If so, I could check for discontinuities in this data to recognize a bad state. Thanks very much for any insights! JColvin edit: confirmed the two google drive links are to .jpg images