#timvideos

can you test https://github.com/timvideos/HDMI2USB-firmware-...

Title: HDMI2USB-firmware-prebuilt/opsis_hdmi2usb-hdmi2usbsoc-opsis.bit at master · timvideos/HDMI2USB-firmware-prebuilt · GitHub (at github.com)

_florent_: I'm thinking so too

but that's strange it's working with pre-production board and not with production boards

_florent_: Using the other input https://goo.gl/photos/4stPm84zBXep6pfBA

_florent_: "WARNING:Par:468 - Your design did not meet timing. The following are some suggestions to assist you to meet timing in your design."

_florent_: TS_hdmi2usbsoc_crg_pll_5_

_florent_: this is on the firmware I'm using on the Atlys

Placer: Placement generated during map.

Routing: Completed - No errors found.

Timing: Completed - 4 errors found.

_florent_: however, the Opsis doesn't have any issues

_florent_: okay, I need to test your serial thing on an Opsis right?

yes

this way we will be able to run the same bitstreams

_florent_: Did you see I merged seaLne's "make download-prebuilt" ?

no

what is is doing?

_florent_: means you can download the travis built firmware

ah ok cool

_florent_: UART is working for me on git commit: 9ac8965527d26eb9f763080531cf7650f7cc7946

_florent_: shall we merge it?

yes

it's working here too

_florent_: great

so I'm going to merge it

_florent_, seaLne's download-prebuilt was how I tracked down the romboot failure to https://github.com/timvideos/HDMI2USB-misoc-fir...

Title: targets: Move common stuff in targets files to a common file. · timvideos/HDMI2USB-misoc-firmware@ca3f01c · GitHub (at github.com)

yes that's really a good idea to have that!

[13streaming-system] 15mithro closed pull request #110: Update for LCA2016, more bootstrap (06master...06master) 02https://git.io/vzSM9

_florent_: BTW If you have anything else which does rombooting, take a look at https://github.com/timvideos/HDMI2USB-misoc-fir...

Title: gateware/targets: Make firmware a real gateware object. · timvideos/HDMI2USB-misoc-firmware@254c281 · GitHub (at github.com)

_florent_: FYI, the Opsis production boards actually have a pin header on the SD card - so it is easy of other people to connect serial port there

good

ok except understanding the strange behaviour on the hdmi inputs, what are the plans now?

are you going to do some capture tests with the HV30?

(or maybe sleep too...)

_florent_: I have no plans at the moment except helping figure out the issues with the HDMI inputs

_florent_: btw, did you get shipping notification from Crowd Supply about the prod board?

yes

I got the notification, but the board are not already there

_florent_: how long ago?

let me check that

_florent_: would be interested to know if/when they might possibly turn up

6 days ago

any idea how long shipping might take? :P

I would guess minimum 7, maximum 14?

so likely to turn up Friday next week just when its no longer useful :P

but I don't understand why behaviour is not similare between pre-prod and prob boards

was is re-routed?

or are there some changes on hdmi input buffers?

_florent_: there should have only been minor changes to the HDMI (connecting the power supplies correctly)

my production opsis boards got to uk customs this morning

so _florent_ might not be long either

_florent_: shall I try and see if I can drop the Atlys frequency to 50MHz from the 75MHz?

yes if you want

back. Found a nice bug in my freq counter module that made it essentially wasted silicon. Let's see what happens now...

Okay, I now have something that works :D

_florent_: what are you looking into?

nothing for now, others things

_florent_: Is there anything you can do regarding the hdmi inputs?

since my hardware seems to be working fine that's a bit difficult

on your side, it would be interesting to do a bisect with prebuild bitstream and a configuration that is not working correctly now

_florent_: is there any extra debugging we can add to gateware/hdmi_in/chansync.py || gateware/hdmi_in/charsync.py which would give insight into where things are going wrong / it is loosing sync?

I'll look at that

mithro: I have a working frequency counter on my end. It's giving fairly accurate results, but something's a bit off

E.g. I'm feeding a 40MHz signal into one of the inputs. The frequency that's being read back is consistently 40040960 Hz

I mean, that's 0.1% error I think? But I would've expected 0% error

_florent_: question, why do the misoclib.soc.SoCs have a integrated_rom_size argument?

_florent_: is that for the bios?

yes for the bios

_florent_: should the firmware ROM be read only?

_florent_: (doesn't it make a difference?)

I think creating a ROM on FPGA is just using a block RAM and not connecting the write signals

_florent_: also, why does the Atlys have 1024 FIFOs but the Opsis only 512? - is that just an oversight?

IIRC it was needed because the Atlys have less DDR throughput

_florent_: that would increase the difficult in routing right?

maybe but that's not sure (maybe 1024 fits in a single bram, if so then there is no difference between 512 and 1024)

mithro: https://gist.github.com/cr1901/0ae23f42867c6703... First version of the patch. Try playing with this

Title: HDMI2USB Frequency Counter Patch · GitHub (at gist.github.com)

I'm curious to see if you get the same 0.1% error that I do on one of your boards...

cr1901_modern: send a pull request?

_florent_: dropping the frequency of the Atlys board seems to have made things worse....

mithro: Not sure if I should do that right now b/c: A. Idk if there's a bug or not, and B. The code that I added to minispartan6 is a debug target that probably shouldn't actually be used by anyone else right now

_florent_: Timing: Completed - 17 errors found.

Do you want me to send a pull request anyway and we'll fix bugs/remove the debug code later?

_florent_: I added something to the ci to re-enable the debug print from the input

ok

_florent_: http://paste.ubuntu.com/14679974/

Title: Ubuntu Pastebin (at paste.ubuntu.com)

_florent_: I'm not 100% sure how to read it - but it seems like the charsync is true but chansync doesn't appear to lock?

I assume the first 3 ph numbers are the phase adjustment of the rgb channels?

I would guess WER is some type of W??? Error Rate?

_florent_: this is what I'm seeing with the HV30 camera connected with my "good" cable -> http://paste.ubuntu.com/14680059/

Title: Ubuntu Pastebin (at paste.ubuntu.com)

_florent_: okay, it seems like the PLL is getting lock, even when no signal is getting through

it seems WER counts errors in the transitions, but I'm not well aware of the lower layers of HDMI

_florent_: http://paste.ubuntu.com/14680164/

Title: Ubuntu Pastebin (at paste.ubuntu.com)

_florent_: so, any ideas were we go from here?

ahh, WER == Word Error Rate

_florent_: is there any chance that the lm32 running at 50MHz is too slow at servicing the hdmi_in0_adjust_phase stuff?

sorry mithro, I'm doing some administrative stuff

first we should do a bisect to see if it was working before

(because I don't think we saw that before on the atlys)

it will maybe give use some indications

_florent_: you don't have an Atlys board any more, right?

GAH?! How can having *less* logic in your design cause *more* timing errors....

I have it... but not working...

ISE is sometimes a bit difficult to predict...

_florent_: I disabled the ethernet on the HDMI2USB target on the Atlys, I went from 2 timing errors to 12 :(

arf...

I probably need to got to sleep soon

it's 4am here...

yes probably

have a good night

Not yet, I'm trying another build

The Atlys firmware does only take 5 minutes to report those errors now though...

so, with the current gateware the PLL doesn't get lock on input0 on the Atlys board at all

I'd really like to fix https://github.com/timvideos/HDMI2USB-misoc-fir... and then turn timing errors back on....

Title: Fix CLOCK_DEDICATED_ROUTE disable on the HDMI outputs · Issue #191 · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com)

input1 is working fine

It's clear in the error message that the timing failure is on input0's PLL I believe?

the error is for the output no?

_florent_: oh you are correct - it is unrelated here to inputs

mithro: best thing to do first is probably to test old bitstreams

I'm pretty sure this was working before

we probably introduced something that cause this

_florent_: problem seems to exist all the way back too Fri Oct 9 18:28:35 2015 +1100

ok

_florent_: then I start running out of prebuilt firmware to download

so that's something that is quite old

but I don't remember having these kind of issues at that time

I do remember Ryan / Carl having issues with one of the inputs

and us discovering something having to be done with the jumpers

yes, you have the link?

I did a capture

CarlFK put it somewhere but I don't remember where exactly

Wasn't that the SCL/SDA issue?

yes I think

what are you trying by the way? a computer or the HV30?