| *** tpb has joined #timvideos | 00:00 | |
| *** CarlFK has quit IRC | 00:45 | |
| *** CarlFK has joined #timvideos | 01:08 | |
| *** ChanServ sets mode: +v CarlFK | 01:08 | |
| CarlFK | if I run 2 instances of melt that write to the same output file.... what happens ? | 01:30 |
|---|---|---|
| CarlFK | one is 90% done, one is 92% done | 01:31 |
| CarlFK | I am guessing I should kill the one that started first | 01:31 |
| CarlFK | I am guessing I should have killed them both and started over | 01:50 |
| mithro | ysionneau: ping me when you get up | 01:51 |
| *** springermac has quit IRC | 02:19 | |
| *** springermac has joined #timvideos | 02:20 | |
| *** Kripton has quit IRC | 02:26 | |
| *** miselin has quit IRC | 02:26 | |
| *** miselin has joined #timvideos | 02:27 | |
| *** Kripton has joined #timvideos | 02:27 | |
| *** Niharikaway is now known as Niharika | 03:02 | |
| *** CarlFK has quit IRC | 04:09 | |
| *** CarlFK has joined #timvideos | 04:24 | |
| *** ChanServ sets mode: +v CarlFK | 04:24 | |
| *** Bertl_oO is now known as Bertl_zZ | 04:56 | |
| *** sb0_ has joined #timvideos | 06:14 | |
| *** travis-ci has joined #timvideos | 06:37 | |
| travis-ci | [timvideos/HDMI2USB-misoc-firmware/pipstrello#295] (3648d3d): The build passed. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/91334132) | 06:37 |
| *** travis-ci has left #timvideos | 06:37 | |
| *** se6astian|away is now known as se6astian | 08:03 | |
| *** CarlFK has quit IRC | 08:14 | |
| *** sb0_ has quit IRC | 09:20 | |
| *** Bertl_zZ is now known as Bertl | 09:53 | |
| ysionneau | mithro: pong | 10:17 |
| mithro | ysionneau: how are things going? I see you pushed some changes for the crc stuff on the HDMI input? | 10:17 |
| mithro | ysionneau: which was kind of strange, I thought you'd work on the HDMI output stuff first as you have access to a device which has output capabilities? | 10:18 |
| ysionneau | I took a bit of time to read the hdmi in/out gateware code + how it articulates with the lm32 software | 10:19 |
| ysionneau | yes maybe it was not the smartest idea, but that's what came in mind to be easier for a start | 10:19 |
| ysionneau | with the drawback that I could not test it myself | 10:20 |
| mithro | ysionneau: I actually think the HDMI output stuff is simpler too? | 10:21 |
| ysionneau | for the hdmi out I have, the only source is the pattern source | 10:22 |
| ysionneau | which is generated by the lm32 IIUC | 10:22 |
| ysionneau | I didn't understand clearly where I would put a CRC computation then | 10:22 |
| mithro | ysionneau: If I understand correctly, the lm32 generates a pattern into a frame buffer in the DDR | 10:23 |
| ysionneau | yes | 10:23 |
| mithro | ysionneau: first step would be to calculate the CRC on the pattern frame buffer | 10:23 |
| ysionneau | who would check this CRC then? | 10:24 |
| *** travis-ci has joined #timvideos | 10:24 | |
| travis-ci | [timvideos/HDMI2USB-misoc-firmware/master#297] (1a34258): The build has errored. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/91993749) | 10:24 |
| *** travis-ci has left #timvideos | 10:24 | |
| mithro | ysionneau: then as the HDMI output DMA's the frame buffer out it should also calculate the CRC on the pixels | 10:24 |
| mithro | ysionneau: after the full frame has been output, you check that the CRC matches the one you calculated when generating it | 10:25 |
| ysionneau | hmmm | 10:26 |
| ysionneau | you mean I check the CRC when the 1st stage of the hdmi_out "pipeline" is reading the data from DDR? | 10:26 |
| mithro | ysionneau: yes, it checks that the frame hasn't been corrupted / changed in memory since it was written (and also that nothing goes wrong in the output stuff) | 10:29 |
| ysionneau | ok now it's more clear for the checking crc rght after reading the frame from DDR | 10:29 |
| ysionneau | but the "and also that nothing goes wrong in the output stuff" is not clear to me | 10:29 |
| mithro | ysionneau: the same pixels that are getting sent out should be the pixels used for the CRC | 10:30 |
| ysionneau | yes but pixels sent out are transformed, and encoded etc, so I'm not sure I can check the CRC anymore | 10:30 |
| ysionneau | the different hdmi_out stages are applying transformations to this pixel stream | 10:31 |
| ysionneau | maybe you have in mind connecting HDMI_out to an HDMI_in port? (but I don't have the hdmi in port) | 10:32 |
| mithro | ysionneau: yes, you need to do the CRC before the transform (although we could calculate the CRC on the transformed content too) | 10:32 |
| ysionneau | before the transform, to me, means "right after reading from DDR" | 10:32 |
| mithro | ysionneau: I don't know if there is any buffering between the DDR and the output | 10:33 |
| ysionneau | I mean, the hdmi_out module is reading from ddr (and buffering, sure) by burst of lasmim.dw (data width) width | 10:34 |
| ysionneau | so I can get those burst and compute the CRC on them | 10:34 |
| ysionneau | this I understand | 10:34 |
| mithro | ysionneau: yes, so you want to put it as late as possible | 10:34 |
| mithro | IE the pixels are they are forwarded into the color space conversion stuff | 10:35 |
| mithro | Eventually the idea is to have a self test mode, where you connect a laptop to input 1, then a HDMI cable from output 1 to input 2 - then you put a image with a known CRC on the laptop screen and check that you get the same value at each stage | 10:36 |
| ysionneau | then I think computing CRC when hdmi_in dma into DDR, and checking when hdmi_out reads from DDR , and comparing from lm32, both, with a known one, would do the job | 10:39 |
| ysionneau | the more crc you have, indeed, the more precise you have an idea about *where* the problem is | 10:39 |
| ysionneau | I agree about that | 10:39 |
| ysionneau | maybe I'm wrong about where I would place those CRC generation/check | 10:41 |
| ysionneau | let's ask _florent_ when he's around where he would put them | 10:41 |
| ysionneau | to me it seems the best place, and I don't think putting (for the case of the hdmi out) the crc further would catch bugs, since we would anyway put it at a stage where no serious transformation has been done | 10:42 |
| ysionneau | so there could be no change, so no crc change | 10:42 |
| mithro | ysionneau: the problems I'm trying to identify at the moment are | 10:46 |
| mithro | * Issues with writing / reading the values from the memory | 10:47 |
| mithro | * Issues with pixel alignment | 10:47 |
| mithro | ysionneau: eventually want a full self-test mode | 10:48 |
| mithro | ysionneau: see some of the issues in https://github.com/timvideos/HDMI2USB-misoc-firmware/issues/134 | 10:48 |
| ysionneau | ok I see | 10:48 |
| mithro | ysionneau: for example, we could start with a completely black frame, then a completely white frame, then a checkerboard, then some more test patterns | 10:48 |
| ysionneau | I don't know much about those things, but maybe some debugging on the v/hsync signals? | 10:49 |
| ysionneau | you think it could be a "pixel integrity issue"? | 10:49 |
| mithro | ysionneau: yes - I've asked cr1901_modern to take a look at getting some strong debugging around the v/hsync signals | 10:49 |
| ysionneau | the sun picture it really looks (like you said) like an alignment issue | 10:50 |
| ysionneau | since the same "dashes" are seen from the black to white transition, and in the yellow to white (sun) transition | 10:50 |
| mithro | ysionneau: the random white/black dashes in the image could be read/write errors | 10:51 |
| mithro | ysionneau: did I ever show you https://warmcat.com/hardware%20design/hdmi/fpga/2015/10/23/hdmi-capture-and-analysis-fpga-project-4.html ? | 10:51 |
| tpb | Title: HDMI Capture and Analysis FPGA Project 4 warmcat.com (at warmcat.com) | 10:51 |
| mithro | ysionneau: I want to get the same stats he is generating in that json dump | 10:52 |
| *** travis-ci has joined #timvideos | 10:52 | |
| travis-ci | [timvideos/HDMI2USB-misoc-firmware/master#297] (1a34258): The build passed. (https://travis-ci.org/timvideos/HDMI2USB-misoc-firmware/builds/91993749) | 10:52 |
| *** travis-ci has left #timvideos | 10:52 | |
| mithro | ysionneau: picture too -> https://warmcat.com/hdmi-fpga-stats.png | 10:52 |
| ysionneau | ah yes I had a look at those pages, really interesting! | 10:52 |
| mithro | ysionneau: btw it might be worth you purchasing a miniSpartan6+ with a LX25 | 10:53 |
| ysionneau | oh, input and output, awesome | 10:54 |
| ysionneau | very good idea | 10:54 |
| ysionneau | I'm ordering right now | 10:54 |
| ysionneau | LX25 is small though, but I've seen someone is porting the hdmi2usb to it | 10:55 |
| ysionneau | I'll have to go prepare lunch, but next target for me is to implement the crc for hdmi out, and compare with the known crc of the pattern | 11:04 |
| ysionneau | to see if my gateware crc integration stuff is OK | 11:04 |
| ysionneau | 11:50 <@mithro> ysionneau: btw it might be worth you purchasing a miniSpartan6+ with a LX25 < ordered! | 11:04 |
| mithro | ysionneau: great | 11:05 |
| mithro | ysionneau: yeah, I'm pretty sure the input+output stuff will fix, unsure about the JPEG encoder | 11:06 |
| ysionneau | do you have other pictures of issues, with for instance wrong pixels in the middle of some colour? | 11:11 |
| ysionneau | or something like that? | 11:11 |
| ysionneau | *afk lunch* | 11:12 |
| *** se6astian is now known as se6astian|away | 12:03 | |
| * ysionneau is back | 12:23 | |
| _florent_ | ysionneau: I agree with mithro, just put CRC after the DMA and compute (with software) the CRC of the pattern | 12:36 |
| _florent_ | ysionneau: as we discuss, the only thing you have to take care is that the data from lasmim are not necessary 32bits (use print(lasmim.dw) to know it) | 12:37 |
| ysionneau | yep that's a very good point | 12:37 |
| ysionneau | I need to pay attention to that | 12:37 |
| ysionneau | thanks for pointing that out | 12:37 |
| _florent_ | ysionneau: but code should be generic and lamim.dw is different on Atlys and Opsis | 12:37 |
| _florent_ | IIRC correctly it's 64bits for Atlys and 128bits for Opsis | 12:38 |
| ysionneau | but the CRC module is adapting itself to the bus data width, isn't it? | 12:41 |
| ysionneau | there's a data_width input parameter :o | 12:41 |
| _florent_ | it's adapting, but for data_width < 32 | 12:43 |
| ysionneau | ouch, ok | 12:43 |
| _florent_ | for data_width > 32 that's not implemented | 12:43 |
| ysionneau | 13:33 < _florent_> ysionneau: I agree with mithro, just put CRC after the DMA < right after the lasmi.Reader()? | 12:45 |
| _florent_ | in fact the best place to put it is here: | 12:47 |
| _florent_ | https://github.com/timvideos/HDMI2USB-misoc-firmware/blob/master/gateware/hdmi_out/phy.py#L211 | 12:47 |
| tpb | Title: HDMI2USB-misoc-firmware/phy.py at master · timvideos/HDMI2USB-misoc-firmware · GitHub (at github.com) | 12:47 |
| _florent_ | and use the input signal of the chroma_upsampler | 12:47 |
| _florent_ | data_width will be 16bits for the CRC | 12:47 |
| _florent_ | input signal/input signals | 12:47 |
| _florent_ | that's the datas from the DDR that have been downconverted to 16bits (y, cb_cr) | 12:48 |
| _florent_ | this way, no need to modify CRC module | 12:49 |
| ysionneau | hmm ok, and that will procude the same CRC as the non-downconverted framebuffer? | 12:49 |
| ysionneau | produce* | 12:49 |
| _florent_ | yes, data are the same :) | 12:51 |
| ysionneau | ok, thanks! that's what I was afraid of | 12:52 |
| ysionneau | oh, another thing, what's the best approach here, do like your "inserter" which appends the CRC at the end of the stream. The CRC would then be located at the end of the framebuffer, in DDR. Or write the CRC in some CSR? | 12:53 |
| ysionneau | hummm I guess that's a question for the hdmi_in, not for the out | 12:54 |
| ysionneau | for the out I guess it's mandatory to be in CSR | 12:54 |
| _florent_ | I see two options: | 12:56 |
| _florent_ | - use CRCInserter (hdmi_in) and the CRCChecker (hdmi_out) | 12:57 |
| _florent_ | with that CRC will be written to memory | 12:57 |
| ysionneau | yep | 12:57 |
| _florent_ | and checked by the gateware when read from memory | 12:57 |
| _florent_ | but then you have to program the DMA with 4 additional bytes | 12:57 |
| ysionneau | yes, have an artificially "longer" framebuffer | 12:58 |
| _florent_ | - use software CRC Engine and CSR and manage check in software | 12:58 |
| ysionneau | ok, I tend to think the latter offers more flexibility, you can then have more "software probes" to read the csr and compare them | 12:58 |
| _florent_ | but what will be more difficult here is to synchronize CRC values to be checked | 12:58 |
| _florent_ | maybe first solution is easier in fact | 12:59 |
| ysionneau | hmmm | 12:59 |
| ysionneau | ok | 12:59 |
| _florent_ | and only consist of inserting CRCInserter/CRCChecker in the stream | 12:59 |
| ysionneau | yes I see | 12:59 |
| ysionneau | ok, I guess I'll do that then | 12:59 |
| _florent_ | but I'm just suggesting, see with mithro if that's what he needs | 12:59 |
| ysionneau | allright | 13:00 |
| ysionneau | thanks for the big help! Sorry for the bother, but I wanted to ask you since you are the one who wrote the gateware | 13:00 |
| mithro | I think either option could work | 13:02 |
| mithro | Either way we are going to end up with a C structure describing a frame | 13:03 |
| ysionneau | yes | 13:04 |
| ysionneau | with framebuffer and crc field | 13:04 |
| ysionneau | and maybe other informations in the future | 13:05 |
| mithro | ysionneau: yeah, we should also store size/width plus format | 13:06 |
| *** rohitksingh has joined #timvideos | 14:12 | |
| *** CarlFK has joined #timvideos | 14:19 | |
| *** ChanServ sets mode: +v CarlFK | 14:19 | |
| *** _florent_ has quit IRC | 14:49 | |
| *** Bertl is now known as Bertl_zZ | 14:58 | |
| *** _florent_ has joined #timvideos | 15:09 | |
| *** rohitksingh has quit IRC | 16:14 | |
| *** rohitksingh has joined #timvideos | 16:30 | |
| *** rohitksingh has quit IRC | 16:44 | |
| *** _florent_ has quit IRC | 18:10 | |
| *** _florent_ has joined #timvideos | 18:19 | |
| *** Bertl_zZ is now known as Bertl | 19:18 | |
| *** se6astian|away is now known as se6astian | 19:34 | |
| *** se6astian is now known as se6astian|away | 19:51 | |
| *** se6astian|away is now known as se6astian | 19:54 | |
| *** se6astian is now known as se6astian|away | 20:04 | |
| *** se6astian|away is now known as se6astian | 20:06 | |
| *** se6astian is now known as se6astian|away | 20:32 | |
| *** se6astian|away is now known as se6astian | 20:38 | |
| *** se6astian is now known as se6astian|away | 21:03 | |
| *** se6astian|away is now known as se6astian | 22:13 | |
| *** se6astian is now known as se6astian|away | 22:14 | |
| *** CarlFK has quit IRC | 23:16 | |
Generated by irclog2html.py 2.13.1 by Marius Gedminas - find it at mg.pov.lt!
