connoisseur_de_mimi

thanks for the explaination! seeing how different FPGAs of different vendors are, I am not surprised. But I did not expect things to be this dire that was necessary to enable clock cascading. its not possible to enable just clk_out_0, clk_out_5 and clk_out_7. to enable clk_out_n, all clk_out_[0..n-1] must be enabled. I was able to fix the timing violation by replacing sample_clk with a binary counter. my system clock is an integer multiple of the sample clock, so this change was dead simple. implementation now meets timing.

Hi @zygot, I agree, I didn't know that async resets should be released synchronously, for example. I learned some things ^^ This is not an error. clk_out 5 is cascaded with clk_out7 to get down do 1 MHz (note the option is named after MMCM Port, not Clock Wizard Port). primary clock is 100 MHz, so 100 * 48 / 5 = 960 MHz, div by 96 = 10 MHz, div by 10 = 1 MHz for clk_out5. I don't know why this is not displayed correctly. Can you elaborate more on that or provide resources? This is what I am trying to do with if (!trigger & trigger_last) begin I'll try moving this out of the module and see if it fixes the issue

did a little more digging. I'm not sure if this is a red herring. I have another module that is very similar to the one shown above, but this module does not cause a hold time violation. Schematic view in the implementation shows that the non-violating module is synthesized to a LUT followed by a register, where the violating module (DAC80501_ch1) is synthesized to a register only: (update and trigger are synonymous in this case) the code that synthesizes to a register only: always @ (posedge clk) begin if (!rst_n) begin //... end else begin case (state) STATE_IDLE: begin if (!update & update_last) begin din_q <= {8'h08, din}; update_q <= 1'b0; state <= STATE_WAIT_TRANSMISSION; end //... end end update_last <= update; ref_pwdwn_edge <= {ref_pwdwn_edge[0], ref_pwdwn}; ready_dac_edge <= {ready_dac_edge[0], ready_dac}; end the code that synthesizes to a LUT followed by a register: always @ (posedge clk) begin if (!rst) begin //... end else begin case (state) STATE_IDLE: begin if (!trigger & trigger_last) begin //falling edge on trigger convst_q <= 1'b0; state <= STATE_WAIT_IRQ; end //... endcase irq_last <= irq; trigger_last <= trigger; ready_last <= ready; end end

Hi @artvvb, I have the same issue with synchronous reset, I actually introduced the async reset to try to fix the issue. Thanks for the links, I have gone back to synchronous resets. The clock interaction report shows the clocks are safely timed (according to https://docs.xilinx.com/r/2022.2-English/ug945-vivado-using-constraints-tutorial/Step-6-Clock-Interaction-Report ) The schematic is pretty straigt forward. This is one of the failing nets sample_clk is passed to various places in the schematic. the only failing nets are those where sample_clk is connected to the D input of a register (like the circled ones below) the design works in hardware (eclypse-z7 with custom pods), but I have yet to confirm that no sampling jitter is introduced by this (I can live with the register being updated one clock cycle later as long as it is consistent).

Hi, I've created a verilog module for a SPI peripheral that is fed 2 clocks, both generated by the same xilinx clocking wizard block. The main clock is a 80MHz clock which feeds the internal logic and determines SPI clk. A secondary clock of 1 MHz is used as a sample clock (that is, triggering an action of the SPI peripheral). in the screenshot below the names are sys_clk and sample_clk, respectively the module: module DAC80501 ( input clk, input update, input rst_n, //... ); reg update_last = 1'b1; always @ (posedge clk or negedge rst_n) begin if (!rst_n) begin //... end else begin case (state) STATE_IDLE: begin if (!update & update_last) begin //... end end //... endcase update_last <= update; end end DAC80501SPI DAC (din_q, update_dac, clk, ready_dac, sclk, mosi, cs); endmodule this results in a hold time violation which I can't figure out how to fix:

awesome, thank you :) I can use the .stp for my design.

I want to create a custom Zmod Faceplate for my Eclypse Z7 Enclosure. Is a mechanical drawing available that I can use as a starting point?

I dug a little deeper using the dpmutil library. SyzygyReadDNAHeader() called in dpmutilFEnum() reads 0xFF only from EEPROM. I2C communication appears to work correctly, at least the I2C HAL does not return any errors, which should also mean the firmware is running correctly. I have read out the EEPROM with avrdude, it matches the file created by syzygy-tools.py. Lots of dead ends. What solved this issue in the end was patching the syzygy-tools.py script to work with my programmer and using it to flash the Pod MCUs 😩 Vio is now set as defined in the dna json.

I was able to read the Syzygy Port Info containing the fsStatus Byte struct { unsigned fPresent:1; unsigned fDW:1; unsigned f5v0InLimit:1; unsigned f3v3InLimit:1; unsigned fVioInLimit:1; unsigned rsv1:1; unsigned rsv2:1; unsigned fAllowVioEnable:1; }; BYTE fsStatus; having the value 0x1d, everything seems to be in order except the fAllowVioEnable bit, which is 0. I also tried to change the Vio min / max settings (all within the voltage range given on the Eclypse-Z7 reference page) but no change.

looking good, thanks :)

I'm using an Eclypse-Z7 board and would like to read out Syzygy Pod information. I know the decutil tool exists, but my project is bare metal (C++). Is there a library / example code for this? (I'm mainly interested in the manufacturer_name and product_name fields of the Syzygy DNA and power rails).

I've created a custom Syzygy pod for internal use with an Eclypse-Z7. It is based on the Syzygy PCB Templates project and has an Attiny44 on board. It does not use the VIO voltage but needs the FPGA to use 3.3 V logic levels to communicate. I have checked out the Syzygy Tools and created my own DNA definition, based on what I've seen in other definitions: { "max_5v_load": 200, "max_3v3_load": 200, "max_vio_load": 200, "is_lvds": false, "is_doublewide": false, "is_txr4": false, "vio": [ { "min": 330, "max": 330 }, { "min": 0, "max": 0 }, { "min": 0, "max": 0 }, { "min": 0, "max": 0 } ], "manufacturer_name": "AWESOME INC.", "product_name": "SZG-CHARLIE", "product_model": "SZG-CHARLIE", "product_version": "" } I then used the syzygy-tools.py script to create a .hex file from that definition and flashed this hex file to EEPROM, avr-dna-fw-main.hex to flash and set the fuses to the values found in the python script Uefuse:w:0xFE:m -Uhfuse:w:0xDD:m -Ulfuse:w:0xE2:m Flashing was successful (using myAVR ProgTool, the script does not support my mySmartUSB light), but the VIO voltage regulators are not enabled - the LEDs stay off (LD2 and LD3). Does anyone see what I may have done wrong?

Thanks @artvvb, it worked! I also added the Pullup constraint, as suggested (its not needed as my I2C devices have pullups built in, but it should make debugging easier). my constraints are now

I want the PS to be able to communicate with I2C sensors via the PMOD interfaces, while other pins of the PMOD are in use by the PL. I added the AXI IIC IP to my design and use a Utility Buffer IP (set up as IOBUFDS) to implement the I2C Open Drain interface: The Package Pins are constrained: set_property -dict { PACKAGE_PIN D15 IOSTANDARD LVCMOS33 } [get_ports { i2c_scl_ch1 }]; #IO_L1N_T0_AD0N Sch=ja3_fpga set_property -dict { PACKAGE_PIN E16 IOSTANDARD LVCMOS33 } [get_ports { i2c_sda_ch1 }]; #IO_L1P_T0_AD0P Sch=ja4_fpga [...] set_property -dict { PACKAGE_PIN D17 IOSTANDARD LVCMOS33 } [get_ports { i2c_scl_ch2 }]; #IO_L5N_T0_AD9N Sch=jb3_fpga set_property -dict { PACKAGE_PIN E18 IOSTANDARD LVCMOS33 } [get_ports { i2c_sda_ch2 }]; #IO_L5P_T0_AD9P Sch=jb4_fpga During Implementation, the following errors and critical warnings are generated: If I set the I/O standard via Implementation -> Schematic -> I/O Ports to LVCMOS33, the constraints file is updated t set_property IOSTANDARD LVCMOS33 [get_ports i2c_ch1_sda] set_property IOSTANDARD LVCMOS33 [get_ports {i2c_ch1_scl[0]}] set_property IOSTANDARD LVCMOS33 [get_ports {i2c_ch2_scl[0]}] set_property IOSTANDARD LVCMOS33 [get_ports i2c_ch2_sda] I cannot, however, set the Package Pins for the I2C ports to the Package Pins listed above - the Pins are not in the List, Vivado shows an "invalid placement site" error: I selected the I2C PMOD pins according to the PMOD Spec. How can I fix this error? Is this related to the utility buffer output being differential?

I changed your project to better reflect my design, it is working correctly, except the issue with transmissions longer than 25000 words (buffer size = 100000 u32's). If I double the buffer size the issue appears with transmissions longer than 50k words. I don't quite understand why tough, the buffer is much longer than the amount of data transferred. I can't attach the .zip file (too big) so here's a google drive link https://drive.google.com/file/d/1hyeEnv1iQgdiS3OBkP5wZk4dJ5RZjMwE/view?usp=share_link I'm still trying to figure out what's different between this project and the one I'm working on. Using an ILA I can see the that the DMA is in fact writing data to the AXI bus, incrementing the AWADDR field as it goes, sending 256 elements per burst: