01:31 <mithro> Does anyone know of someone working on a FOSS DisplayPort core at all?

07:33 <mithro> rjo_: BTW How did you know / here about the HDMI2USB project?

14:42 <GitHub181> [ARTIQ] sbourdeauducq pushed 1 new commit to master: http://git.io/Z6qJRQ

14:42 <GitHub181> ARTIQ/master 11d8840 Sebastien Bourdeauducq: runtime: new serial protocol, support multiple entry points and log messages

14:49 <GitHub113> [ARTIQ] sbourdeauducq pushed 2 new commits to master: http://git.io/5-tvGQ

14:49 <GitHub113> ARTIQ/master 140b4eb Sebastien Bourdeauducq: devices/rtio_core: set OE, implement gate/count

14:49 <GitHub113> ARTIQ/master 8bf7b27 Sebastien Bourdeauducq: runtime: increase initial_time

15:04 <GitHub33> [ARTIQ] sbourdeauducq pushed 1 new commit to master: http://git.io/6Cfy3w

15:04 <GitHub33> ARTIQ/master 040fa0e Sebastien Bourdeauducq: runtime: blink LED at startup

15:06 <rjo> mithro: just browsing fpga projects on github.

15:06 <mithro> rjo: ahh, fair enough

15:07 <mithro> rjo: still a long way off reaching our goals, not enough time :P

15:08 <sb0_> mithro, it should be rather quick if you use misoc and the mixxeo hdmi sampler core

15:08 <mithro> sb0_: we have a working solution - with the HDMI capture, mixing, sending data up the USB, etc

15:09 <mithro> sb0_: but it code could be miles better

15:09 <mithro> sb0_: and we don't have very good tests

15:09 <sb0_> yeah, you used that hdmi xilinx appnote, right?

15:09 <sb0_> it looks like a contest winner for the most horrible verilog code indeed

15:10 <mithro> sb0_: we initially reused bunnie's code which I believe was based of the xapp

15:10 <mithro> sb0_: we also have a design and a couple of prototypes for the production board - but again needs more testing and stuff

15:11 <mithro> sb0_: also have lofty goals of getting a USB3.0 and DisplayPort cores going

15:11 <sb0_> https://github.com/timvideos/HDMI2USB/blob/master/hdl/hdmi/chnlbond.v#L79

15:12 <mithro> sb0_: yeah

15:12 <sb0_> when you see those delays it means the programmer does not understand delta-cycles

15:13 <sb0_> oh yeah, and this: https://github.com/timvideos/HDMI2USB/blob/master/hdl/hdmi/convert_30to15_fifo.v#L19

15:13 <mithro> sb0_: oh, I have a couple of small fixes for your HDMI core + SDRAM to fix some timing issue complaints

15:13 <sb0_> seriously

15:13 <ysionneau> what is even the point of those delays in the mind of the developer?

15:14 <sb0_> this is "assign wa_d = wa + 1", with the most crappy code possible, and possibly a bug

15:14 <sb0_> I laughed really hard when I found that in the appnote...

15:14 <mithro> sb0_: well, I

15:14 <mithro> bah

15:15 <sb0_> and it's followed by flip-flop instances. this horrible mess is actually just a counter...

15:15 <mithro> sb0_: well, if I can get your misoc working on our boards then maybe we can reuse some of your work

15:15 <sb0_> this appnote sucks and I wonder why you are not using misoc

15:16 <mithro> sb0_: we didn't know about misoc when we started

15:17 <mithro> sb0_: anyway, you know hindsight is 20-20 :P

15:23 <sb0_> DisplayPort is less hacky than HDMI... but you'll have to use the transceivers, which are worse than the serdes...

15:23 <mithro> sb0_: yeah

15:31 <sb0_> ysionneau, if in verilog you write always @(clk) y <= x; always @(clk) z <= y;

15:32 <sb0_> people who don't understand delta-cycles believe that there is a possibility that x goes directly to z in one clk cycle, if the second always block is executed after the first

15:32 <ysionneau> wow

15:32 <ysionneau> ok ...

15:33 <sb0_> writing instead "always @(clk) y <= #1 x; always @(clk) z <= #1 y;" removes that ambiguity

15:33 <ysionneau> when you understand it as an electronic circuit, then it's clear that x cannot go to z

15:33 <sb0_> the thing is, when you write "<=" the assignment is already delayed by one delta-cycle

15:33 <sb0_> and the verilog simulator runs all always blocks currently triggered in the current delta cycle before going to the next

15:34 <sb0_> so x->z is always 2 clk cycles, and the explicit delays are unneccessary (and generally harmful as a source of misunderstandings, messy vcd files, messy code, and bugs)

15:35 <ysionneau> ok thanks for the explanation

15:35 <sb0_> obviously, you can still get hired by xilinx if you don't understand delta cycles

15:35 <sb0_> which is a bit weird imo