- Welcome to Trenz Electronic GmbH Support Forum.
Recent posts
#11
Trenz Electronic FPGA Modules / Re: SDCARD Images download for...
Last post by eddydw - October 30, 2025, 09:29:32 PMThanks for the answers John.
That answers all my questions.
Best regards
Eddy
That answers all my questions.
Best regards
Eddy
#12
Trenz Electronic FPGA Modules / Re: Does TE0720 Ethernet work ...
Last post by viktornikolov - October 28, 2025, 07:23:01 PMNetworking works in Vitis 2025.1 in a FreeRTOS app!
TL;DR: Vitis 2025.1 forced me to enable the lwip220_lwip_dhcp_does_acd_check option, but it doesn't work with my MikroTik switches (not even in Vitis Classic 2024.2). After I disabled this option, the FreeRTOS lwIP TCP Perf Client worked perfectly. I achieved an average transfer speed of 566 Mbits/sec.
I made the project export publicly available here.
When you use any of the lwIP examples in Vitis 2025.1, it throws an error unless you set certain lwIP parameters to the values specified in the error message.
The thing is that the default values of lwIP parameters are chosen to save memory but are not optimal for performance. Vitis 2025.1 requires you to increase several parameter values to achieve high TCP Perf Client performance.
For some reason, AMD also decided to insist on enabling the parameter lwip220_lwip_dhcp_does_acd_check, which has nothing to do with performance.
In theory, with this parameter enabled, the lwIP stack should send an ARP probe to verify that the IP address it received via DHCP is not in use by another device on the network. I don't know how it's actually implemented in the code.
However, on my MikroTik switches (I tried two different ones), it doesn't work, and the lwIP prints a misleading error message "ERROR: DHCP request timed out".
(I tried an old TP-Link router, and the dhcp_does_acd_check works OK with it.)
I don't know what's wrong with my MirkoTik switch. I can use arping normally, so an ARP probe is not prohibited.
So, I must enable the lwip220_lwip_dhcp_does_acd_check so that Vitis 2025.1 will generate an lwIP example, and then I must disable it so that the example works with my MikroTik switch. 🙂
I still have no luck with a standalone app using the RAW lwIP API in Vitis 2025.1. It simply freezes after the Ethernet speed auto negotiation, even after I disabled the dhcp_does_acd_check option.
TL;DR: Vitis 2025.1 forced me to enable the lwip220_lwip_dhcp_does_acd_check option, but it doesn't work with my MikroTik switches (not even in Vitis Classic 2024.2). After I disabled this option, the FreeRTOS lwIP TCP Perf Client worked perfectly. I achieved an average transfer speed of 566 Mbits/sec.
I made the project export publicly available here.
When you use any of the lwIP examples in Vitis 2025.1, it throws an error unless you set certain lwIP parameters to the values specified in the error message.
The thing is that the default values of lwIP parameters are chosen to save memory but are not optimal for performance. Vitis 2025.1 requires you to increase several parameter values to achieve high TCP Perf Client performance.
For some reason, AMD also decided to insist on enabling the parameter lwip220_lwip_dhcp_does_acd_check, which has nothing to do with performance.
In theory, with this parameter enabled, the lwIP stack should send an ARP probe to verify that the IP address it received via DHCP is not in use by another device on the network. I don't know how it's actually implemented in the code.
However, on my MikroTik switches (I tried two different ones), it doesn't work, and the lwIP prints a misleading error message "ERROR: DHCP request timed out".
(I tried an old TP-Link router, and the dhcp_does_acd_check works OK with it.)
I don't know what's wrong with my MirkoTik switch. I can use arping normally, so an ARP probe is not prohibited.
So, I must enable the lwip220_lwip_dhcp_does_acd_check so that Vitis 2025.1 will generate an lwIP example, and then I must disable it so that the example works with my MikroTik switch. 🙂
I still have no luck with a standalone app using the RAW lwIP API in Vitis 2025.1. It simply freezes after the Ethernet speed auto negotiation, even after I disabled the dhcp_does_acd_check option.
#13
MAX1000 community projects / Re: Playing ZX Spectrum in HDM...
Last post by Subcritical - October 28, 2025, 01:54:32 PMoriginal dominic-meads
dvi sinals I - señales dvi I- DVI-Signale I
dvi sinals II - señales dvi II- DVI-Signale II
[Español]
Vamos a adaptar el hdmi de la placa ATLAS o un conector generico hdmi de 8 pines para crear la cara sonriente de "VGA image driver (make a face) on an Intel FPGA"
El código original esta en la siguiente dirección:
https://github.com/dominic-meads/Quartus-Projects/tree/main/VGA_face
Es un ejercicio muy sencillo pero muy util para ver como dibujar en cada cuador de la imagen o "frame" rectángulos.
Para ello se definen coordenadas y desigualdades.
Sólo hay que cambiar la correspondencia de los pines asociados al HDMI y el reloj principal los hacemos paso a paso desde quartus y su pin planner.
El error se ha producido porque primero hay que cambiar de chip al chip usado en la supercpld max1000.
Los pines que hay que cambiar en las restricciones son:
## HDMI Direct ATLAS_V002_MAX1000
set_location_assignment PIN_H5 -to # CLK-
set_location_assignment PIN_K10 -to # CLK+ # canal del reloj dvi/hdmi
set_location_assignment PIN_H13 -to # 0- # Negativo difierencial canal azul
set_location_assignment PIN_J13 -to # 0+ # Positivo canal azul
set_location_assignment PIN_K11 -to # 1-
set_location_assignment PIN_K12 -to # 1+ # canla verde
set_location_assignment PIN_J12 -to # 2-
set_location_assignment PIN_L12 -to # 2+ # canal rojo
##clocks ATLAS_V002_MAX1000
set_location_assignment PIN_H6 -to CLK_12MHZ
El envoltorio HDMI es el más simple que he usado y hay que poner a cero las señales negativas.
Es un DVI en realidad y muy sencillo.
Poniendo los pines a 0:
assign TMDS_D0_N=1'b0;
assign TMDS_D1_N=1'b0;
assign TMDS_D2_N=1'b0;
assign TMDS_CLK_N=1'b0;
Cometimos el error de identificar incorrectamente el chip de la max1000, he puesto la misma familia pero de 2kles, ahora corrigo el error.
La serie max 10 es más moderna que la serie cyclone 10 Lp, sin cambiar las IPS propietarias de intel/altera vamos a ver si sintetiza el diseño para max1000.
Este ejercicio es realmente interesante para saber posicionar elementos en pantalla a través de HDMI/DVI.
[English]
We are going to adapt the HDMI from the ATLAS board or a generic 8-pin HDMI connector to create the smiling face of the "VGA image driver (make a face) on an Intel FPGA."
The original code is located at the following address:
https://github.com/dominic-meads/Quartus-Projects/tree/main/VGA_face
It is a very simple exercise but very useful for seeing how to draw rectangles in each square of the image or "frame."
Coordinates and inequalities are defined for this purpose.
You only need to change the mapping of the pins associated with HDMI, and we will set up the main clock step by step from Quartus and its Pin Planner.
The error occurred because you first need to switch from the chip to the chip used in the SuperCPLD MAX1000.
The pins that need to be changed in the constraints are:
## HDMI Direct ATLAS_V002_MAX1000
set_location_assignment PIN_H5 -to # CLK-
set_location_assignment PIN_K10 -to # CLK+ # clock channel
set_location_assignment PIN_H13 -to # 0-
set_location_assignment PIN_J13 -to # 0+ # blue channel
set_location_assignment PIN_K11 -to # 1-
set_location_assignment PIN_K12 -to # 1+ # green channel
set_location_assignment PIN_J12 -to # 2-
set_location_assignment PIN_L12 -to # 2+ # red channel
##clocks ATLAS_V002_MAX1000set_location_assignment PIN_H6 -to CLK_12MHZ
The HDMI wrapper is the simplest I have used, and the negative signals need to be set to zero.
It is actually a DVI and very simple.Setting the pins to 0:
assign TMDS_D0_N=1'b0;
assign TMDS_D1_N=1'b0;
assign TMDS_D2_N=1'b0;
assign TMDS_CLK_N=1'b0;
We made the mistake of incorrectly identifying the chip of the max1000; I put the same family but with 2kles, now I am correcting the error.
The max 10 series is more modern than the cyclone 10 LP series. Without changing Intel/Altera's proprietary IPs, let's see if the design synthesizes for max1000.
This exercise is really interesting to know how to position elements on the screen via HDMI/DVI.
[Deutsch]
Wir werden den HDMI-Anschluss der ATLAS-Platine oder einen generischen 8-Pin-HDMI-Stecker anpassen, um das lächelnde Gesicht von ,,VGA-Bildtreiber (ein Gesicht machen) auf einem Intel FPGA" zu erstellen.
Der Originalcode befindet sich unter folgender Adresse:
https://github.com/dominic-meads/Quartus-Projects/tree/main/VGA_face.
Es ist eine sehr einfache, aber sehr nützliche Übung, um zu sehen, wie man Rechtecke in jedem Feld des Bildes oder ,,Frames" zeichnet. Dazu werden Koordinaten und Ungleichungen definiert.
Es müssen nur die Zuordnungen der mit HDMI verbundenen Pins geändert werden, und die Hauptuhr wird Schritt für Schritt über Quartus und seinen Pin Planner eingerichtet.
Der Fehler trat auf, weil man zuerst vom Chip zum verwendeten Chip auf der SuperCPLD MAX1000 wechseln muss. Die Pins, die in den Einschränkungen geändert werden müssen, sind:
## HDMI Direct ATLAS_V002_MAX1000
set_location_assignment PIN_H5 -to # CLK-
set_location_assignment PIN_K10 -to # CLK+ # positiver Kanal der Taktdifferenz des DVI-Signals
set_location_assignment PIN_H13 -to # 0-
set_location_assignment PIN_J13 -to # 0+ # blauer Differenzialkanal
set_location_assignment PIN_K11 -to # 1-
set_location_assignment PIN_K12 -to # 1+ # positiver grün differenzieller Kanal
set_location_assignment PIN_J12 -to # 2-
set_location_assignment PIN_L12 -to # 2+ # roter Differenzialkanal
##clocks ATLAS_V002_MAX1000set_location_assignment PIN_H6 -to CLK_12MHZ
Die HDMI-Hülle ist die einfachste, die ich je benutzt habe, und die negativen Signale müssen auf Null gesetzt werden. Es ist eigentlich ein DVI und sehr einfach. Die Pins auf 0 setzen:
assign TMDS_D0_N=1'b0;
assign TMDS_D1_N=1'b0;
assign TMDS_D2_N=1'b0;
assign TMDS_CLK_N=1'b0;
Wir haben den Fehler gemacht, den Chip des Max1000 falsch zu identifizieren.
Ich habe dieselbe Familie, aber von 2kles, verwendet, jetzt korrigiere ich den Fehler.
Die Max 10-Serie ist moderner als die Cyclone 10 LP-Serie. Ohne die proprietären IPs von Intel/Altera zu ändern, werden wir sehen, ob das Design für Max1000 synthetisiert werden kann.
Diese Übung ist wirklich interessant, um zu lernen, wie man Elemente auf dem Bildschirm über HDMI/DVI positioniert.
CaraSONRIENTE - Limpia - max1000.zip
#14
Trenz Electronic FPGA Modules / Re: TE0720-04-62I33MA QSPI pro...
Last post by JH - October 28, 2025, 08:35:51 AMHi,
load Uboot with over JTAG with xsct console,this should be:
br
John
load Uboot with over JTAG with xsct console,this should be:
Code Select
connect
targets -set -filter {name =~ "Cortex-A9 #0"}
rst
dow fsbl.elf
con
# Wait until DDR init done, then stop CPU and load U-Boot:
stop
dow u-boot.elf
con
On Uboot load your boot.bin with tftp and write to the qspi flah. this should be somthing like this:Code Select
setenv serverip 192.168.1.1
setenv ipaddr 192.168.1.10
tftpboot 0x1000000 BOOT.BIN && \
sf probe 0 0 0 && \
sf erase 0x0 +${filesize} && \
sf write 0x1000000 0x0 ${filesize}
br
John
#15
Trenz Electronic FPGA Modules / Re: TE0745-03-81C31-A board sc...
Last post by JH - October 28, 2025, 08:26:56 AMDear Zhou,
schematics of the modules are available on the download area of our modules.
https://www.trenz-electronic.de/Downloads/?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0745/REV03/Documents
We offer also altium project of our carrier, which you can use as startpoint for your own design:
https://www.trenz-electronic.de/Downloads/?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/5.2x7.6_Carriers/TEB0745/REV02/HW_Design
br
John
schematics of the modules are available on the download area of our modules.
https://www.trenz-electronic.de/Downloads/?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/TE0745/REV03/Documents
We offer also altium project of our carrier, which you can use as startpoint for your own design:
https://www.trenz-electronic.de/Downloads/?path=Trenz_Electronic/Modules_and_Module_Carriers/5.2x7.6/5.2x7.6_Carriers/TEB0745/REV02/HW_Design
br
John
#16
Trenz Electronic FPGA Modules / TE0745-03-81C31-A board schema...
Last post by zhouxltx - October 27, 2025, 01:23:41 PMHi Expert:
Can you send schematic design file of this board? We will design daughter card for this board.
Regards
Brian Zhou
Can you send schematic design file of this board? We will design daughter card for this board.
Regards
Brian Zhou
#17
Trenz Electronic FPGA Modules / Re: TE0720-04-62I33MA QSPI pro...
Last post by michalk - October 27, 2025, 01:20:46 PMHi,
Could you please point me to more information on how to use ethernet for programming? The board fortunately is ethernet connected. Will it be possible to use this method with baremetal application and blank QSPI or after some error that makes qspi content unbootable? Dedicated firmware for programming is an option - the process may be complicated, reliability is a priority.
Unfortunately the MODE pin is hardwired do VCC and pgood is used in its primary function (I have to admit I missed the possibility to use this pin to force JTAG-only mode when making a base board design a while back).
On the other hand even routing to jumpers would not help much since the final product is assembled into sealed chassis. I might be able to salvage a single pin on the service connetor so if I understand correctly it would work if I could short pgood and mode, add weak pull-up and an option to short to gnd via service connector. This should set 1/1 on normal operation (QSPI Boot) and 0/0 with programming adapter connected to service connector (JTAG Boot). This change could probably be manually wired even on existing boards.
best regards,
Michal
Could you please point me to more information on how to use ethernet for programming? The board fortunately is ethernet connected. Will it be possible to use this method with baremetal application and blank QSPI or after some error that makes qspi content unbootable? Dedicated firmware for programming is an option - the process may be complicated, reliability is a priority.
Unfortunately the MODE pin is hardwired do VCC and pgood is used in its primary function (I have to admit I missed the possibility to use this pin to force JTAG-only mode when making a base board design a while back).
On the other hand even routing to jumpers would not help much since the final product is assembled into sealed chassis. I might be able to salvage a single pin on the service connetor so if I understand correctly it would work if I could short pgood and mode, add weak pull-up and an option to short to gnd via service connector. This should set 1/1 on normal operation (QSPI Boot) and 0/0 with programming adapter connected to service connector (JTAG Boot). This change could probably be manually wired even on existing boards.
best regards,
Michal
#18
Trenz Electronic FPGA Modules / Re: TE0720-04-62I33MA QSPI pro...
Last post by JH - October 27, 2025, 09:34:32 AMHi,
without changing boot mode to JTAG only, I think it's hard.
I think it's not possible to control MODE and PGOOD Pin on your carrier or? With newer CPLD Firmware it's possible to switch to JTAG only than.
Is Ethernet is available on your final product? Than it's maybe possible to start maybe uboot from xsct console temporary to load your final design from network and write it into the flash.
br
John
without changing boot mode to JTAG only, I think it's hard.
I think it's not possible to control MODE and PGOOD Pin on your carrier or? With newer CPLD Firmware it's possible to switch to JTAG only than.
Is Ethernet is available on your final product? Than it's maybe possible to start maybe uboot from xsct console temporary to load your final design from network and write it into the flash.
br
John
#19
Trenz Electronic FPGA Modules / Does TE0720 Ethernet work in V...
Last post by viktornikolov - October 26, 2025, 05:14:44 PMHi!
Has anybody managed to get Ethernet networking on TE0720 working in Vitis 2025.1?
My TE0720-04-62I33MA with carrier board TE0705 works like a charm with apps built in Vitis Classic 2024.2. I successfully ran Xilinx lwIP iperf TCP Client examples (standalone and RTOS).
However, when I try the same in Vitis 2025.1, the network connection is not established.
The lwIP iperf server's console output shows that Ethernet speed autonegotiation succeeded, but no connection is established.
The standalone version of the iperf server just hangs. The RTOS version says that the DHCP request timed out.
I have three different Digilent Zynq-7000 boards, and none of them worked in Vitis 2025.1 either (they do work with Vitis 2024.2).
Nevertheless, I find it hard to believe that Vitis 2025.1 is that bad.
Am I doing something wrong?
Has anybody managed to get Ethernet networking on TE0720 working in Vitis 2025.1?
My TE0720-04-62I33MA with carrier board TE0705 works like a charm with apps built in Vitis Classic 2024.2. I successfully ran Xilinx lwIP iperf TCP Client examples (standalone and RTOS).
However, when I try the same in Vitis 2025.1, the network connection is not established.
The lwIP iperf server's console output shows that Ethernet speed autonegotiation succeeded, but no connection is established.
The standalone version of the iperf server just hangs. The RTOS version says that the DHCP request timed out.
I have three different Digilent Zynq-7000 boards, and none of them worked in Vitis 2025.1 either (they do work with Vitis 2024.2).
Nevertheless, I find it hard to believe that Vitis 2025.1 is that bad.
Am I doing something wrong?
#20
Trenz Electronic FPGA Modules / Petalinux won't boot on TE0720
Last post by AlexSan - October 24, 2025, 03:25:23 PMHello. I succesfully booted petalinux on one of my soms and then i tried to do it on a couple of other of my devices.
--I formatted the sd to contain 2 partitions (boot/fatfs root/ext4) and flashed image.ub,boot.bin and boot.scr on boot and rootfs.ext4 on root using the dd command.
--i set the dip switches on my carrier board to sd boot mode and plugged in the device.
Got no output on my serial console whatsoever.
I then tried to program the qspi memory and jtag boot, but again i got a "download successful" message but no output. I tried the sd card on my first som and it booted just fine.
Note: I didn't change anything. I tried to flash the image on a second sd card as is. I changed carrier boards to make sure that none of them were faulty. But again only one out of the three of them booted successfuly meaning that i probably haven't done some configurations.
Any advice would be very useful
--I formatted the sd to contain 2 partitions (boot/fatfs root/ext4) and flashed image.ub,boot.bin and boot.scr on boot and rootfs.ext4 on root using the dd command.
--i set the dip switches on my carrier board to sd boot mode and plugged in the device.
Got no output on my serial console whatsoever.
I then tried to program the qspi memory and jtag boot, but again i got a "download successful" message but no output. I tried the sd card on my first som and it booted just fine.
Note: I didn't change anything. I tried to flash the image on a second sd card as is. I changed carrier boards to make sure that none of them were faulty. But again only one out of the three of them booted successfuly meaning that i probably haven't done some configurations.
Any advice would be very useful