- Welcome to Trenz Electronic GmbH Support Forum.
Recent posts
#91
Open source hardware / ZynqBerry open-source Atari ST...
Last post by zerkman - November 13, 2024, 11:22:27 AMHello,
In case there are retro-computing enthusiasts out here, I just wanted you to know that I recently ported my open-source (GPLv3) zeST Atari ST FPGA implementation project to the ZynqBerry board.
More info here: https://zest.sector1.fr/posts/release_20241108/
In case there are retro-computing enthusiasts out here, I just wanted you to know that I recently ported my open-source (GPLv3) zeST Atari ST FPGA implementation project to the ZynqBerry board.
More info here: https://zest.sector1.fr/posts/release_20241108/
#92
Trenz Electronic FPGA Modules / Re: TEM0009 module
Last post by JH - November 12, 2024, 09:05:31 AMHi,
STEP is available on our Download area:
https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/JTAG_Programmer/TEM0009/REV02/HW_Design
br
John
STEP is available on our Download area:
https://shop.trenz-electronic.de/en/Download/?path=Trenz_Electronic/JTAG_Programmer/TEM0009/REV02/HW_Design
br
John
#93
Open source hardware / Re: TE0726-04 ZynqBerry + zhdm...
Last post by zerkman - November 09, 2024, 07:21:46 PMIt seems p and n physical pins can not be swapped in pin assignment or fpga logic since it's a physical constraint. Thus the p output of an OBUFDS can only be routed to a p output pin, and the n output must be routed to a n output pin. This means the only way to "invert back" the differential pair is to invert the OBUFDS input. But since it is connected to a OSERDES output, there is no routable way to place a LUT in between so I had to invert the OSERDES input.
I have updated the zhdmi code so the user can set up a INVERTED_TX generic bitfield that specifies which of the TMDS channels are inverted so the generated logic inverts the channel data again. See the ZynqBerry toplevel design of the zhdmi demo.
I have updated the zhdmi code so the user can set up a INVERTED_TX generic bitfield that specifies which of the TMDS channels are inverted so the generated logic inverts the channel data again. See the ZynqBerry toplevel design of the zhdmi demo.
#94
Trenz Electronic FPGA Modules / TE0712_03
Last post by batte72 - November 07, 2024, 06:52:36 PMI have a big problem I search to insert sysytem ILA in my design , the ila have a clock 150MHz from clock wizard but I program th device tis is reply:
INFO: [Labtools 27-1434] Device xc7a100t (JTAG device index = 0) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device. To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).
WARNING: [Labtools 27-3413] Dropping logic core with cellname:'design_2_i/system_ila_0/U0/ila_lib' at location 'uuid_4B3CE664E2765957B9AAF87F9382A547' from probes file, since it cannot be found on the programmed device.
INFO: [Labtools 27-1434] Device xc7a100t (JTAG device index = 0) is programmed with a design that has no supported debug core(s) in it.
WARNING: [Labtools 27-3361] The debug hub core was not detected.
Resolution:
1. Make sure the clock connected to the debug hub (dbg_hub) core is a free running clock and is active.
2. Make sure the BSCAN_SWITCH_USER_MASK device property in Vivado Hardware Manager reflects the user scan chain setting in the design and refresh the device. To determine the user scan chain setting in the design, open the implemented design and use 'get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub]'.
For more details on setting the scan chain property, consult the Vivado Debug and Programming User Guide (UG908).
WARNING: [Labtools 27-3413] Dropping logic core with cellname:'design_2_i/system_ila_0/U0/ila_lib' at location 'uuid_4B3CE664E2765957B9AAF87F9382A547' from probes file, since it cannot be found on the programmed device.
#95
Trenz Electronic FPGA Modules / TEM0009 module
Last post by aptobtainable - November 07, 2024, 04:57:02 AMCan you please provide a .stp file for the TEM0009 module?
#96
Open source hardware / Re: TE0726-04 ZynqBerry + zhdm...
Last post by zerkman - November 06, 2024, 12:34:50 AMI rewrote the HDMI constraints as follows, specifying all n and p pins.
From the schematic I also noticed the clock p and n pins are swapped, but I'm leaving the original order for now.
I only swapped the d_p[ 0 ] and d_n[ 0 ] as instructed.
Now, Vivado produces this error on write_bitstream:
Please note that I also previously got the same error when trying to swap the n and p in the top level design. Similarly I got errors when trying to invert (NOT operator) the output values of d_p[ 0 ] and d_n[ 0 ].
I could set the SEVERITY to Warning as explained in the error message, but I assume my problem is not about unspecified pin locations (they are set correctly in the xdc) so I would not want to do something dangerous.
As explained above the clock p and n bits also seem to be swapped; if I swap the R7/R8 pin assignments in the xdc, this results in 4 port assigment issues (the previous ones plus the clock p and n ports) instead of 2.
From the schematic I also noticed the clock p and n pins are swapped, but I'm leaving the original order for now.
I only swapped the d_p[ 0 ] and d_n[ 0 ] as instructed.
Code Select
# HDMI
set_property IOSTANDARD TMDS_33 [get_ports {hdmi_tx_clk_p hdmi_tx_clk_n}]
set_property PACKAGE_PIN R7 [get_ports hdmi_tx_clk_p]
set_property PACKAGE_PIN R8 [get_ports hdmi_tx_clk_n]
set_property IOSTANDARD TMDS_33 [get_ports {hdmi_tx_d_p[*] hdmi_tx_d_n[*]}]
set_property PACKAGE_PIN P9 [get_ports {hdmi_tx_d_p[0]}]
set_property PACKAGE_PIN P8 [get_ports {hdmi_tx_d_n[0]}]
set_property PACKAGE_PIN P10 [get_ports {hdmi_tx_d_p[1]}]
set_property PACKAGE_PIN R10 [get_ports {hdmi_tx_d_n[1]}]
set_property PACKAGE_PIN P11 [get_ports {hdmi_tx_d_p[2]}]
set_property PACKAGE_PIN R11 [get_ports {hdmi_tx_d_n[2]}]
Now, Vivado produces this error on write_bitstream:
QuoteERROR: [DRC UCIO-1] Unconstrained Logical Port: 2 out of 43 logical ports have no user assigned specific location constraint (LOC). This may cause I/O contention or incompatibility with the board power or connectivity affecting performance, signal integrity or in extreme cases cause damage to the device or the components to which it is connected. To correct this violation, specify all pin locations. This design will fail to generate a bitstream unless all logical ports have a user specified site LOC constraint defined. To allow bitstream creation with unspecified pin locations (not recommended), use this command: set_property SEVERITY {Warning} [get_drc_checks UCIO-1]. NOTE: When using the Vivado Runs infrastructure (e.g. launch_runs Tcl command), add this command to a .tcl file and add that file as a pre-hook for write_bitstream step for the implementation run. Problem ports: hdmi_tx_d_p[0], and hdmi_tx_d_n[0].
Please note that I also previously got the same error when trying to swap the n and p in the top level design. Similarly I got errors when trying to invert (NOT operator) the output values of d_p[ 0 ] and d_n[ 0 ].
I could set the SEVERITY to Warning as explained in the error message, but I assume my problem is not about unspecified pin locations (they are set correctly in the xdc) so I would not want to do something dangerous.
As explained above the clock p and n bits also seem to be swapped; if I swap the R7/R8 pin assignments in the xdc, this results in 4 port assigment issues (the previous ones plus the clock p and n ports) instead of 2.
#97
Trenz Electronic FPGA Modules / Re: TE0701-06 Assembly Diagram...
Last post by M.Tserabei - November 05, 2024, 03:18:27 PMHi, we updated assembly diagram. Best regards, Maksim Tserabei
#98
Open source hardware / Re: TE0726-04 ZynqBerry + zhdm...
Last post by RC - November 04, 2024, 02:30:04 PMHi,
The Swap is for the optimal PCB routing. Otherwise,the routing would be complicated. Could you modify the XDC file and manually assign all the pins(n and p)? It might be a simpler workaround.
The Swap is for the optimal PCB routing. Otherwise,the routing would be complicated. Could you modify the XDC file and manually assign all the pins(n and p)? It might be a simpler workaround.
#99
Trenz Electronic FPGA Modules / Re: Detecting wrong speed grad...
Last post by neels - October 31, 2024, 06:57:34 PMThanks Mohsen, I have sent a request to the support email address regarding the CPLD source code.
regards,
Neels
regards,
Neels
#100
UltraScale / TEB0818+TE00813 custom hardwar...
Last post by marcelobraga - October 31, 2024, 01:00:14 PMI'm following the AMD guide for developping a device driver for a custom axi IP: https://docs.amd.com/r/en-US/ug1165-zynq-embedded-design-tutorial/Creating-Custom-IP-and-Device-Drivers-for-Linux as well as the one for deploying a custom Petalinux image for the Trenz board.
However I'm having problems during petalinux-build command, it seems it only builds when my Vivado block design has the same ZynqMP configuration as in the Trenz StarterKit or TestBoard examples. Whenever I try to to create a hardware platform in VIvado from scratch, without all the configs for the ZynqMP, my petalinux-build fail.
Is this how it is supposed to happen? I can provide any log files if necessary
However I'm having problems during petalinux-build command, it seems it only builds when my Vivado block design has the same ZynqMP configuration as in the Trenz StarterKit or TestBoard examples. Whenever I try to to create a hardware platform in VIvado from scratch, without all the configs for the ZynqMP, my petalinux-build fail.
Is this how it is supposed to happen? I can provide any log files if necessary