• Content Count

  • Joined

  • Last visited

About tschesnok

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. As I continue to debug my TMDS input polarity issues into the DVI2RGB IP it seems that my output is CMY rather than screwed up RGB no matter what I do with the inputs. Source is a Raspberry Pi (I split the signal and it displays perfectly on a screen at the same time) Has anyone seen this. Unfortunately I have not heard from the author via DM. Otherwise picture if perfect.. so I could convert it to RGB via a custom IP... but that seems wrong :) (note Picture is not perfect.. it scrolls.. but DVI2RGB is putting out a solid v-sync at 60hz so I think it is unrelated to the above)
  2. For anyone following this - it looks like I resolved it and got DVI2RGB working with inverse TMDS signals: 1. You can't change a differential signal till AFTER IBUFDS. I tried.. no go. Vivado makes it very clear that positive is positive and negative is negative all the way into the IBUFDS. It has nothing to do with naming conventions.. it is hardware. The IBUFDS sits at the port of the chip PRIOR to FPGA fabric. 2. To get DVI2RGB working I had to break out separate versions of TMDS_Decoder and corresponding InputSERDES to get access to IBUFDS. I inverted the signal in the appropriat
  3. That would be nice.. but it does not seem so. Intel does it the right way.. You handle polarity and conversion the the pin level with the pin planner. No "code" in Verilog/VHLD deals with differential signals. It seems with Xilinx you do it in text from in code via I/OBUFDS. IBUFDS directly controls how the signal is used.. and unfortunately because it is code.. and not a pin setting.. it can be hidden inside other peoples designs / IP. That is the problem here.. and when I make a change I'm now triggering timing issues in viviado unrelated to code functionality. (i.e. code wor
  4. From what I gather, the only way to swap polarity on a differential pair is AFTER IBUFDS. (that seems to be confirmed all over the internet). In this particular case we have the code in the above FOR loop instantiating TMDS_Decoder 3x which in turn is instantiating inputSERDES 3x (not shown). inputSERDES contains the IBUFDS. So.. the only way to change polarity is to change inputSERDES for only one of the 3 data channels. This means that the three TMDS_Decoders can NOT be identical.. and can't be called in the FOR loop. When I write it as 3 code blocks Vivdo complains about timing
  5. From what I read, the hardware is fixed up until the IBUFDS. From there you can do what you want. P had to attache to IBUFDS p since it is a physical link. Please: I need some VHDL help in unrolling the for loop above. Specifically.. originally it creates 3 instances called DataDecoders[x].DecoderX where the small x is the instance number. How do I recreate that when unrolling it? If I simply rename the DecoderX as DecoderX_0 (_1, _2 etc) I get timing errors since the SERDES are no longer "associated".. I would be so grateful if you could write it out. (don't worry about
  6. Oh.. and since I have you.. how precisely would you unrole this for loop below: note: I will need to create a new file for TMDS_Decoder called "TMDS_Decoder_Inverse" which links to another changed file "SERDES_Decode_Inverse".. and then use these for iCh "2". - I mean I can't believe what an amazing pain it is to change pin polarity in an array of differential signals.. in a 3rd party IP. WTF :) -- Three data channel decoders DataDecoders: for iCh in 2 downto 0 generate DecoderX: entity work.TMDS_Decoder generic map ( kCtlTknCount => kMinTknCntFor
  7. Hi Zygot, Thanks for taking time to answer. Yes, the reason I'm swapping pins is because I traced them. I don't think you can just swap pins in the constraint file. (but If I'm wrong I would like to know since that would make life easy!) It is my experience (and understanding) that Vivado will complain when generating the bitstream when it finds a mismatch between pin polarity and IBUFDS. Of course now I'm thinking.. how does it know.. I'm guessing it understands the pin names assigned.. I don't think I can trick it.. but would love to hear suggestions. A
  8. I'm using a Digilent FMC-HDMI card on a Trenz FPGA board (Artix-7) and the FMC connector has a few inverted differential signals (All but TMDS Data2 are inverted) The DVI-to-RGB IP has no way to invert signals and I think there is no way to do it but to make changes in the IP code. I'm a Verilog guy at best.. and it is written in VHDL. I see a file called InputSERDES.vhd which seems to contain the IBUFDS: InputBuffer: IBUFDS generic map ( DIFF_TERM => FALSE, IOSTANDARD => "TMDS_33") port map ( I => sDataIn_p, IB
  9. Everything for the Arty z7 seems to be 2 years old and will not work with any of the last two major releases from Xilinx. (SDSoc, Petalinux..etc). Do I understand this correctly after wasting two days trying to get something to work?
  10. Was there any progress on this? I'm getting a warning and then errors building petalinux with 2017.4 using 2019.1 PetaSDK. I'm trying to avoid going back multiple years in the tool chain.. or something else is wrong? Related post of mine with screen dump:
  11. Total noob here trying to get Petalinux to build.. I followed all the steps.. got it all installed.. but get a warning of a version mismatch between the SDK tool and the BSP file (I think) Surly I can't be expected to install an old tool chain to use the Digilent BSP file. What are my next steps here? Can I build a new BSP? how? Is this even the issue? Here is the screen dump: [email protected]:~/PetaLinux$ petalinux-create -t project -n Testz7 -s ./Petalinux-Arty-Z7-20-2017.4-1.bsp INFO: Create project: Testz7 INFO: New project successfully created in /home/andrew/PetaLi