- Welcome to Trenz Electronic GmbH Support Forum.
Recent posts
#1
UltraScale / TE0820 Power Up Issues with RE...
Last post by jan.blaesi - June 05, 2026, 04:07:11 PMHi,
we are experiencing some issues with REV04 TE0820 modules.
After a brownout, or occasionally on initial startup, the module sometimes gets stuck, not booting anymore.
The red LED on the long side of the module stays lit up, the boot mode LED blinks as usual.
Doing a longer power cycle (~10 seconds), the module boots up just fine.
Our REV05 modules never show this kind of behaviour, it is just the REV04 ones.
The EN1, RESIN and NOSEQ lines are controlled by a microcontroller, but I did not find any way to get the module out of this state.
Do you have any idea what we could be doing wrong?
Best regards
we are experiencing some issues with REV04 TE0820 modules.
After a brownout, or occasionally on initial startup, the module sometimes gets stuck, not booting anymore.
The red LED on the long side of the module stays lit up, the boot mode LED blinks as usual.
Doing a longer power cycle (~10 seconds), the module boots up just fine.
Our REV05 modules never show this kind of behaviour, it is just the REV04 ones.
The EN1, RESIN and NOSEQ lines are controlled by a microcontroller, but I did not find any way to get the module out of this state.
Do you have any idea what we could be doing wrong?
Best regards
#2
Trenz Electronic FPGA Modules / Open-source 1024-point FFT acc...
Last post by ka_ru - June 04, 2026, 09:32:16 AMI built a complete, fully open-source FFT engine around the Trenz ICEZero (TE0876-03-A) — the iCE40HX4K + 4 Mbit SRAM Raspberry Pi HAT. It does a 1024-point complex FFT (16-bit Q1.15, block-floating-point output), talks to the Pi over SPI (up to 14 MHz, streaming BULK_READ), and uses the on-board SRAM as a double-buffer on both input and output so compute, readout and the next upload overlap → ~500 FFT/s, ~0.2 W. The whole flow is 100% Yosys + nextpnr + icestorm (no vendor tools), it programs straight from the Pi's GPIO (no external programmer, ~2.3 s), and uses only ~34% of the HX4K.
Verified on real hardware against NumPy: DC/ramp/sine correlate 1.000000, an 18–34 kHz chirp 0.999987 (spectrum below). Code, docs and the SPI protocol spec: 👉 https://github.com/ipmgroup/fftd — thanks to Trenz for a genuinely hackable little board, questions and PRs welcome!
(attach: chirp_fft_comparison.png — FPGA vs NumPy spectrum of the 18–34 kHz chirp)
Verified on real hardware against NumPy: DC/ramp/sine correlate 1.000000, an 18–34 kHz chirp 0.999987 (spectrum below). Code, docs and the SPI protocol spec: 👉 https://github.com/ipmgroup/fftd — thanks to Trenz for a genuinely hackable little board, questions and PRs welcome!
(attach: chirp_fft_comparison.png — FPGA vs NumPy spectrum of the 18–34 kHz chirp)
#3
Trenz Electronic FPGA Modules / Re: Limited interoperability o...
Last post by FvM - June 01, 2026, 01:38:59 PMHello Antti, thanks for confirming the issue. I wonder if anybody tried to run the modules at 1.3V IO voltage?
#4
UltraScale / TE0813 + TEBF0818 - PCIe Link ...
Last post by woonjung - June 01, 2026, 11:00:45 AMHello,
I am experiencing a PCIe Link Up failure when connecting an M.2 Key-E WiFi module (SX-PCEBE-M2, Qualcomm QCC2076 chipset) to the TE0813 + TEBF0818 board via an M.2 Key-E to PCIe x16 slot adapter card.
=== Environment ===
- Module: Trenz TE0813 (Zynq UltraScale+ ZU3EG) + TEBF0818
- PCIe Controller: Xilinx NWL PCIe (PS-PCIe)
- OS: PetaLinux 2023.2 (Linux Kernel 6.1.30-xilinx)
- Connection: M.2 Key-E WiFi module via PCIe x16 slot adapter card
=== Verified OK ===
- 3.3V power supply: Normal
- PERST0_L (Pin 52): 1.8V confirmed
- REFCLK 100MHz: Normal output confirmed
- TX/RX signal direction: Correct
- W_DISABLE pins: Normal
- Reserved pins: All Open (NC)
=== Symptom ===
dmesg output:
nwl-pcie fd0e0000.pcie: Link is DOWN
PS_LINKUP Register (0xFD480238):
BIT(1) PHY_RDY_LINKUP = 1 → PHY is UP
BIT(0) PCIE_PHY_LINKUP = 0 → PCIe Link Training NOT completed
BIT(0) remains 0 even after waiting 2+ seconds
=== Key Observation ===
- WNFQ-268AXI module (Qualcomm WCN6856 chipset) works fine in the exact same environment
- SX-PCEAX module (older Qualcomm-based) also fails with identical symptoms on the same board
- This suggests a compatibility issue between the Xilinx NWL PCIe controller and Qualcomm-based WiFi modules in general
=== What I have tried ===
- Added wait loop in nwl_wait_for_link() → No effect
- Forced PEWAKE to GND → No effect
- Forced PCIe Gen1 speed → No effect
- PCIe controller reset via 0xFD1A0100 → No effect
- CMA size increased to 512MB → No effect
=== Question ===
Has anyone successfully used a Qualcomm-based M.2 WiFi module with TE0813 + TEBF0818 and the NWL PCIe controller?
Is there any known configuration, FSBL setting, or kernel patch required to make PCIe Link Training work with Qualcomm chipsets on the NWL PCIe controller?
Any advice would be greatly appreciated.
Thank you.
I am experiencing a PCIe Link Up failure when connecting an M.2 Key-E WiFi module (SX-PCEBE-M2, Qualcomm QCC2076 chipset) to the TE0813 + TEBF0818 board via an M.2 Key-E to PCIe x16 slot adapter card.
=== Environment ===
- Module: Trenz TE0813 (Zynq UltraScale+ ZU3EG) + TEBF0818
- PCIe Controller: Xilinx NWL PCIe (PS-PCIe)
- OS: PetaLinux 2023.2 (Linux Kernel 6.1.30-xilinx)
- Connection: M.2 Key-E WiFi module via PCIe x16 slot adapter card
=== Verified OK ===
- 3.3V power supply: Normal
- PERST0_L (Pin 52): 1.8V confirmed
- REFCLK 100MHz: Normal output confirmed
- TX/RX signal direction: Correct
- W_DISABLE pins: Normal
- Reserved pins: All Open (NC)
=== Symptom ===
dmesg output:
nwl-pcie fd0e0000.pcie: Link is DOWN
PS_LINKUP Register (0xFD480238):
BIT(1) PHY_RDY_LINKUP = 1 → PHY is UP
BIT(0) PCIE_PHY_LINKUP = 0 → PCIe Link Training NOT completed
BIT(0) remains 0 even after waiting 2+ seconds
=== Key Observation ===
- WNFQ-268AXI module (Qualcomm WCN6856 chipset) works fine in the exact same environment
- SX-PCEAX module (older Qualcomm-based) also fails with identical symptoms on the same board
- This suggests a compatibility issue between the Xilinx NWL PCIe controller and Qualcomm-based WiFi modules in general
=== What I have tried ===
- Added wait loop in nwl_wait_for_link() → No effect
- Forced PEWAKE to GND → No effect
- Forced PCIe Gen1 speed → No effect
- PCIe controller reset via 0xFD1A0100 → No effect
- CMA size increased to 512MB → No effect
=== Question ===
Has anyone successfully used a Qualcomm-based M.2 WiFi module with TE0813 + TEBF0818 and the NWL PCIe controller?
Is there any known configuration, FSBL setting, or kernel patch required to make PCIe Link Training work with Qualcomm chipsets on the NWL PCIe controller?
Any advice would be greatly appreciated.
Thank you.
#5
Trenz Electronic FPGA Modules / Re: Limited interoperability o...
Last post by Antti Lukats - May 27, 2026, 08:16:20 AMyes the operation is only possible for MIPI and HDMI boards. The 1.3V is not so good but Agilex has no other options
#6
Trenz Electronic FPGA Modules / Re: TE0701 Rev7 Release Date
Last post by mch - May 26, 2026, 10:32:16 AMHello Tobias,
Could you please contact our sales department? Our sales department email address is:
sales@trenz-electronic.de
Best regards,
Mohsen Chamanbaz
Could you please contact our sales department? Our sales department email address is:
sales@trenz-electronic.de
Best regards,
Mohsen Chamanbaz
#7
Trenz Electronic FPGA Modules / Limited interoperability of CR...
Last post by FvM - May 23, 2026, 12:03:56 PMHello,
I recently ordered CR00200-01 (1 Gbps Ethernet) and CR00049-01 eMMC CRUVI modules, considering to use them for test setups with AXE5000 Agilex 5 Eval Board.
Looking into possible implementation details, I notice now that these modules can be most likely not used with Agilex FPGA Boards due to incompatible Vadj range. Agilex 3 and 5 have a maximal VCC_HSSI of 1.3 V while Marvell 88E1512 PHY on CR00200 and eMMC on CR00049 require at least 1.8 V IO supply.
I might be that operation at unspecified lower VDDO respectively VCCQ is possible, I didn't yet test.
What I would expect however is a hint in module product information about minimal required Vadj.
Any experience with operation of CRUVI modules beyond 1.8 V Vadj?
Regards
Frank
I recently ordered CR00200-01 (1 Gbps Ethernet) and CR00049-01 eMMC CRUVI modules, considering to use them for test setups with AXE5000 Agilex 5 Eval Board.
Looking into possible implementation details, I notice now that these modules can be most likely not used with Agilex FPGA Boards due to incompatible Vadj range. Agilex 3 and 5 have a maximal VCC_HSSI of 1.3 V while Marvell 88E1512 PHY on CR00200 and eMMC on CR00049 require at least 1.8 V IO supply.
I might be that operation at unspecified lower VDDO respectively VCCQ is possible, I didn't yet test.
What I would expect however is a hint in module product information about minimal required Vadj.
Any experience with operation of CRUVI modules beyond 1.8 V Vadj?
Regards
Frank
#8
Trenz Electronic FPGA Modules / TE0701 Rev7 Release Date
Last post by TobiasWinkler - May 22, 2026, 04:01:46 PMI'd like to purchase the TE0701 with a HPC FMC connector.
Is there already a release date for the seventh revision?
Best regards
Tobias
Is there already a release date for the seventh revision?
Best regards
Tobias
#9
Trenz Electronic FPGA Modules / Re: TE0726 TRM V.3 - MIO48 - M...
Last post by MA - May 22, 2026, 07:09:33 AMHi,
The TE0726-03R is an assembly variant without Ethernet, USB and HDMI. The schematics and assembly documentation for your specific assembly variant can be found under the following link.
However, based on the DDR size, I assume that you may not be able to use the HDMI interface in the same way as on the standard variant (128 MB instead of 512 MB DDR).
Best regards
The TE0726-03R is an assembly variant without Ethernet, USB and HDMI. The schematics and assembly documentation for your specific assembly variant can be found under the following link.
However, based on the DDR size, I assume that you may not be able to use the HDMI interface in the same way as on the standard variant (128 MB instead of 512 MB DDR).
Best regards
#10
Trenz Electronic FPGA Modules / Re: TE0726 TRM V.3 - MIO48 - M...
Last post by qwaserdf - May 21, 2026, 06:03:15 PMHello,
It was only out of curiosity, since I realized that regardless of which MIO port I select for the UART1 communication, or even if I use the EMIO one, this is configured correctly. That feels a bit strange to me.
Besides that, there is something else I would like to ask about this board, if you don't mind. Please let me know if I should open a new topic for this question.
The version I bought of the ZynqBerry only has the J1 connector, and it also lacks many of the other resistors (purchased years ago from DigiKey: https://www.digikey.at/en/products/detail/trenz-electronic-gmbh/TE0726-03R/6141394).
I would like to know whether mounting the HDMI connector and the adjacent EMI filters would be enough to enable HDMI functionality, or if any other indispensable components are also missing.
Best regards.
It was only out of curiosity, since I realized that regardless of which MIO port I select for the UART1 communication, or even if I use the EMIO one, this is configured correctly. That feels a bit strange to me.
Besides that, there is something else I would like to ask about this board, if you don't mind. Please let me know if I should open a new topic for this question.
The version I bought of the ZynqBerry only has the J1 connector, and it also lacks many of the other resistors (purchased years ago from DigiKey: https://www.digikey.at/en/products/detail/trenz-electronic-gmbh/TE0726-03R/6141394).
I would like to know whether mounting the HDMI connector and the adjacent EMI filters would be enough to enable HDMI functionality, or if any other indispensable components are also missing.
Best regards.