00:28 <cr1901_modern> mumptai: NextValue is the function you're looking for

02:41 <sb0> whitequark, can you develop a i2c core?

03:44 <cr1901_modern> sb0: I'd be willing to do that. Is it for misoc?

04:59 <sb0> cr1901_modern, yes; more precisely for programming the si5324

04:59 <sb0> on the transceiver demo.

04:59 <sb0> and it has to work next week.

07:26 <sb0> "1010101010101010101" seems to be the GTX output "fault" pattern when the input is stuck at zero

07:27 <sb0> the brute-force comma alignment method appears to work fine

07:30 <sb0> another advantage of this technique is it keeps resetting the GTX if the input data is not valid, which due to another Xilinx fuckup (RXCDRLOCK is not reliable and "reserved") is the only way of dealing with powering up a RX when the input data is not valid yet

07:32 <sb0> so it's 2-in-1

07:42 <whitequark> sb0: hmm

07:43 <whitequark> I've never really used migen before now, not sure how shallow the learning curve is

07:43 <whitequark> I could probably write it pretty quickly in Verilog

07:48 <sb0> ok, so it should be pretty quick in migen, too

07:48 <sb0> the only really new thing will be the CSR stuff

07:55 <whitequark> okay, I'll start looking at it around sunday or so

07:56 <whitequark> do you want me to bother with clock extension, or make it dumb and just drive SCK blindly?

07:58 <sb0> I don't think any chip we use right now requires clock extension

07:58 <sb0> nor do we care about performance, so we can just use the slowest clock that works

07:59 <sb0> *slower

08:01 <whitequark> ok, that should be quite easy indeed

08:31 <sb0> "The main contribution of 64b/66b is the observation that the deterministic runlength and transition density of 8b/10b are not always worth a 25% code overhead, and that solid robust systems could be designed using statistically bounded methods. At some point, the real risk of a nuclear war, meteoric impact, or power supply failure dominate the reliability of both 8b/10b and 64b/66b systems."

08:32 <sb0> whitequark, yes, i2c is easy, but frustrating when the chip at the other end acts up.

08:34 <sb0> also the easiest clock turns out to be 62.5MHz instead of 125MHz, as the transceiver have a minimum ratio of 20 - is that easy to input and output 62.5 MHz in the Si5324?

08:37 <whitequark> sure, just need to run the dspll tool

08:37 <whitequark> actually, probably can just adjust the divisor.

08:38 <sb0> the input will be 62.5 as well

09:33 <sb0> rjo, what do you think of TMDS?

09:36 <sb0> it's more elegant than IBM 8b10b, it has fewer commas but we really need only one. trying to understand the details of its running disparity control; since we'll typically encode multiple bytes per cycle, it's important that it is simple enough

09:40 <rjo> i have no experience with tmds. there are a bunch of things that we could use the other comma chars for, no?

09:40 <sb0> we can just use the same comma as synchronizer and packet delimiter. then the next byte can be the packet type

09:42 <rjo> the disparity (dc-coupled usually afaict) could be a bit worrying but i don't know really

09:42 <sb0> I don't actually understand how they came up with the equations for 5b/6b and 3b/4b, which are convoluted and look pretty random. did you find a good explanation for this?

09:42 <sb0> (talking about 8b/10b(

09:42 <rjo> yes. if we elevate everything to the packet layer then we only need one comma.

09:42 <sb0> TMDS is fundamentally a bunch or XORs to reduce the amount of transitions in non-comma characters

09:43 <sb0> that's easy enough to understand. but 8b10b...

09:44 <rjo> the original paper has a lot on that 5/6b 3/4b design. those two parts are similar and seemed to be somewhat fundamental in the sense that they already give you most of thee features and may be the smalles entities that achieve that. but it does seem a bit random.

09:44 <rjo> you don't need to understand it. but you said you already had implemented 8b10b in migen?

09:45 <rjo> logic-wise 8b10b is extremely small afaict.

09:46 <rjo> *the features ... *the smallest entities

09:49 <sb0> I had implemented TMDS. I thought that 8b10b was roughly the same, but there's this somewhat important difference between the strange equations and XORs

09:50 <rjo> yes. if you want i can give you my 8b10b in migen which felt like 90% done. equation based.

09:51 <sb0> let me fully understand the TMDS running disparity control. if it sounds plausible that a FPGA implementation can deal with the running disparity of multiple chars in one cycle at a reasonable clock rate (it is the case for 8b10b), I prefer TMDS

09:52 <sb0> TMDS is very straightforward to decode: https://github.com/m-labs/misoc/blob/master/misoc/cores/dvi_sampler/decoding.py

09:52 <sb0> no messy equations like 8b10b

09:55 <rjo> get over the equations! seems a bit artificial to employ the use of equations as an argument against something ;)

09:55 <rjo> http://paste.debian.net/784022/

09:56 <sb0> do you prefer remembering trigonometric identities, or computing with complex exponentials?

09:56 <sb0> bbl

09:57 <rjo> ;) you don't have to remember the 8b10b equations.

09:59 <rjo> anyway. 64b66b might actually be more aesthetic and albeit a bit more complicated.

11:54 <sb0> 64b66b doesn't have guaranteed disparity and requires many bits to be buffered

11:56 <rjo> the guaranteed disparity does not seem to matter in that case. but buffering does. i didn't know that.

12:03 <sb0> it doesn't matter from a practical standpoint, but it does from an aesthetic one

12:04 <sb0> from a practical standpoint, the 8b10b equations are also fine: the 5b6b encoder and decoder requires at most one LUT per bit in a modern FPGA

12:04 <sb0> and the LUT output is directly the value you want - it's one level of logic

12:05 <sb0> TMDS, well, you need to chain 7 XORs. that will take two levels of LUTs.

12:06 <sb0> plus the XOR/XNOR selection logic

12:44 <sb0> okay, TMDS has more complicated running disparity control, and it sounds more difficult to do many character per cycles using it

12:47 <sb0> because of the different running disparity control, its spectrum may reach into lower frequencies too

12:49 <sb0> (the maximum absolute value of the running disparity for TMDS is rather high)

12:49 <sb0> it's 1 for 8b/10b

12:49 <sb0> and 8 for TMDS

12:50 <sb0> at symbol boundaries

12:50 <sb0> I'm not even sure all SFP transceivers will handle that nicely

12:50 <sb0> so 8b10b it is then

12:51 <sb0> I'll probably not bother with the equations and just put a look-up table in the code

12:52 <sb0> that's what the FPGA hardware will end up doing anyway

12:58 <cr1901_modern1> sb0: "do you prefer remembering trigonometric identities, or computing with complex exponentials?" Do these ever go away once you get past first year of EE :P?

13:57 <GitHub163> [artiq] jordens created phaser (+1 new commit): https://git.io/vKM1t

13:57 <GitHub163> artiq/phaser d83046d Robert Jordens: gateware: copy phaser (df3825a)

14:11 <rjo> _florent_: i have moved my dsp code for the ad9154 into artiq/phaser i am using dummy data outputs currently. if you write your code, i would just put it in there as well.

14:13 <rjo> _florent_: how is the jesd204b stuff?

14:14 <rjo> cr1901_modern: is that misoc branch of yours "done" from your perspective?

14:15 <cr1901_modern> rjo: Need to push a few more commits/run the test suite one last time. Then yes it will be :). Please give me an hour

14:17 <cr1901_modern> rjo: Did you see the most recent commit? I was able to work your original test suite into something usable

14:27 <rjo> cr1901_modern: yes. it was also usable before.

14:29 <cr1901_modern> rjo: It was? As I imported it from artiq, it didn't run. And I recall that you said it "was an idea that didn't pan out"

14:29 <cr1901_modern> This wasn't a slight at your coding ability :P

14:29 <rjo> the stuff after the return was a sketch. the test suite before worked fine.

14:30 <cr1901_modern> Oh. Well I turned the sketch into a test suite successfully then :)*.

14:30 <rjo> cr1901_modern: you just need to be aware how much use that additional test suite will bring and how much bitrot it will see.

14:30 <rjo> ok. bbl

14:30 <cr1901_modern> rjo: Then I can get rid of it after I've verified the CSR core runs if you wish

14:31 <cr1901_modern> alright

14:31 <cr1901_modern> It just exercised all the features of the core