amb5l / tyto_project

The Tyto Project
GNU Lesser General Public License v3.0
7 stars 0 forks source link

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 #6

Closed sy2002 closed 1 year ago

sy2002 commented 1 year ago

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:

grafik

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 ?

amb5l commented 1 year ago

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 TRISTATEWIDTH 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: ug471_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?

sy2002 commented 1 year ago

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:

(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 ;-) )

amb5l commented 1 year ago

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?

sy2002 commented 1 year ago

@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: https://github.com/MJoergen/C64MEGA65/issues/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)
amb5l commented 1 year ago

OK let's add the MEGA65 as a supported platform to my new repo. See this issue.