Vivado: OSERDES_DataRateTqTriWidth: Unexpected programming GEN_HDMI_CLK/U_SER_S with TRISTATE_WIDTH. DATA_RATE_TQ set DDR expects TRISTATE_WIDTH to be set 4
Closed this issue · 5 comments
Hi Adam (@amb5l),
it's been a while - 1 year I guess :-) I trust you are well.
I know that you already have the Tyto2 project - but since we (MEGA65, MiSTer2MEGA65 framework) are still using your "old" code from this version, I thought it might be sensible to open the issue here.
Please have a look at these warnings:
Looking at your source code here and here and not really understanding what actually happens in detail: Might it be better to use tristate_width => 4 in the DDR context instead of 1 ?
Hi again! All well thanks...
I have seen this warning before, and ignored it because the serialiser output is never tristated (I guess this is why it's a warning, not an error). I just tried building the hdmi_tpg design (for the nexys_video target) using Vivado 2022.2 and it built OK, but showed the same DRC during the write_bitstream process.
Let's see what's going on.
MAIN/GEN_HDMI_DATA[*].HDMI_DATA/U_SER_M are all instances of the oserdese2 primitive from the vcomponents package of the unisim library. I have the tristate_width generic set to 1, and the error complains that it should be 4, as you suggest.
Refer to UG471. The TRISTATE_WIDTH attribute of the OSERDESE2 primitive is discussed on page 166:
The TRISTATE_WIDTH attribute defines the parallel 3-state input width of the 3-state control parallel-to-serial converter. The possible values for this attribute depend on the DATA_RATE_TQ attribute. When DATA_RATE_TQ is set to SDR or BUF, the TRISTATE_WIDTH attribute can only be set to 1. When DATA_RATE_TQ is set to DDR, the possible values for the TRISTATE_WIDTH attribute are 1 and 4.
TRISTATE_WIDTH cannot be set to widths larger than 4. When a DATA_WIDTH is larger than four, set the TRISTATE_WIDTH to 1.
See also Table 3-8:
There it is. I have DATA_WIDTH set to 10, that's why I chose to set TRISTATE_WIDTH to 4. But I (wrongly) set DATA_RATE_TQ to "DDR". So my preferred fix is to change DATA_RATE_TQ to "SDR". I've tested this change and the warning disappears.
See this Xilinx support forum post for a similar situation.
I will push a commit with this fix shortly. Please can you confirm that this works for you?
Hi @amb5l WOW - This was not only a super fast answer, you also took the time to share a lot of background information. Thank you so much. Highly appreciated. I can confirm that using your latest commit
(a) The warning is gone
(b) The system still works (i.e. produces the expected images on my HDMI screen)
I am closing the issue.
But just in case you can spare the time, here is a bit of context (why I opened the issue at all) and questions:
Context: We still have about 5% of users where HDMI does not work properly: No sound or no image or other problems. We ignored it so far. HDMI seems to be a messy standard. I recently switched from Vivado 2019.2 to Vivado 2022.2. I saw the above-mentioned warning.
Questions:
- Do you think the new version (that uses Single Data Rate instead of Double Data Rate) is more compatible?
- Is there any "danger" that the new version might be less compatible than the old one?
(I am asking, because I feel the pressure of many hundreds of users and I am always quite conservatively applying changes - particularly those that I do not fully understand ;-) )
Glad the commit helped!
I see no chance that the change will affect compatibility either way. Tristating the serialiser output is not something we do, so there's no way this change could have an effect.
I am interested in the edge cases. Maybe we should build an hdmi_tpg version for your hardware platforms so that we can do some further testing. What hardware are you running on?
@amb5l Sounds great! Thank you for offering your help. Yes: If we were able to build a hdmi_tpg version that allows further testing, I could distribute it to the people with "edge case monitors". Some of the monitor and HDMI grabbers etc. are listed here: MJoergen/C64MEGA65#4
So the hardware is the MEGA65, it uses a Xilinx XC7A200T-2FBG484C. The components list is attached below. And here is the PCB schematics as PDF so that you can see how the FPGA is connected to the HDMI out: TE0765-03.pdf
An XDC file for the system is here:
https://github.com/MJoergen/C64MEGA65/blob/master/MEGA65/C64MEGA65-R3.xdc
Since your code seems to need a key press to switch to the next video mode - here is a component that does that (return_out is low active and goes to zero if one presses the Return key on the MEGA65):
https://github.com/MJoergen/HyperRAM/blob/main/src/Example_Design/MEGA65/keyboard.vhd
If it would not be too much effort for you, then I would highly appreciate if you could build a bitstream to test.
P.S. Would you like to continue this conversation in Skype or in the MEGA65 Discord (invitation link for you https://discord.gg/8jXREhAS) or do you prefer a new issue inside Tyto 1 or 2?
CONNECTORS:
JB1 : Debug Adaptor (UART/JTAG)
J1 : VGA
J2 : SDCard (Internal)
J3 : Joystick B
J4 : HDMI
J5 : Keyboard JTAG
J6 : CBM Disk IEC
J7 : Joystick A
J8 : Cartridge Expansion
J9 : Headphones
J10 : Ethernet
J11 : Power Input
J12 : Keyboard JTAG
J13 : Floppy Disk Power
J14 : Floppy Disk Data
J15 : SDCard (External)
J16 : Floppy Disk Power
J17 : Max10 JTAG
J18 : Grove I2C
J19 : Speaker Right
J20 : Max10 JTAG enable ??
J21 : Max10 Debug GPIO
J22 : Speaker Left
CHIPS:
U1 : XC7A200T-2FBG484C : Main FPGA
U2 : SN74LVCH16T245DGV : Bus Transceiver (Cartridge)
U3 : ADV7125BCPZ170 : Video DAC (VGA)
U4 : KSZ8081RNDCA : Ethernet PHY
U5 : S25FL256SAGBHI20 : Flash (32MB)
U6 : NC7SZ126P5X : Buffer (JB_AX)
U7 : SN74LVCH16T245DGV : Bus Transceiver (Floppy Drive)
U8 : SN74LVCH16T245DGV : Bus Transceiver (Cartridge)
U9 : SN74LVCH16T245DGV : Bus Transceiver (Cartridge)
U10 : TPD12S016PWR : HDMI PHY
U11 : EN6347QI : Voltage Regulator
U12 : 171050601 : Voltage Regulator
U13 : EP53A7HQI : Voltage Regulator
U14 : 171050601 : Voltage Regulator
U15 : NC7SZ126P5X : Buffer (F_SER_CLK_O)
U16 : NC7SZ126P5X : Buffer (F_SER_DATA_O)
U17 : SiT8008BI-73-XXS : Oscillator (100 MHz)
U18 : NC7SZ126P5X : Buffer (VGA_HSync)
U19 : NC7SZ126P5X : Buffer (VGA_VSync)
U20 : NC7SZ126P5X : Buffer (F_SER_CLK_I)
U21 : NC7SZ126P5X : Buffer (F_SER_DATA_I)
U22 : NC7SZ126P5X : Buffer (JA_RIGHT)
U23 : NC7SZ126P5X : Buffer (JA_LEFT)
U24 : NC7SZ126P5X : Buffer (JA_DOWN)
U25 : NC7SZ126P5X : Buffer (JA_FIRE)
U26 : NC7SZ126P5X : Buffer (JA_UP)
U27 : NC7SZ126P5X : Buffer (F_SER_SRQ_O)
U28 : NC7SZ126P5X : Buffer (F_SER_SRQ_I)
U29 : IS66WVH8M8BLL : HyperRAM (8MB)
U30 : NC7SZ126P5X : Buffer (C64_EXROM)
U31 : NC7SZ126P5X : Buffer (C64_GAME)
U32 : 10M08SAU169C8G : Max10
U33 : MP5010BDQ-LF-Z : Voltage Regulator
U34 : LTC4365ITS8#TRMPBF : Voltage Regulator
U35 : AP2196SG-13 : Voltage Regulator
U36 : 24AA025E48T-I/OT : I2C addr: 0x50 : 2Kb EEPROM
U37 : SSM2518CPZ-R7 : I2C addr: 0x34 : Audio Power Amplifier
U38 : ISL12020MIRZ : I2C addr: 0x6F (RTC) & 0x57 (SRAM)
U39 : 24LC128-I/ST : I2C addr: 0x54 : 128Kb EEPROM
U40 : NC7SZ126P5X : Buffer (JB_AY)
U41 : NC7SZ126P5X : Buffer (JA_AX)
U42 : NC7SZ126P5X : Buffer (JA_AY)
OK let's add the MEGA65 as a supported platform to my new repo. See this issue.