#apertus IRC Channel Logs

Hi BAndiT1983 ,would our daily/weekly updates reporting happen in the irc channel itself?

Congratulations to all of the GSOC participants!

If you don't mind..can everyone share their proposals.. because previously many students didn't share it publicly

Bertl_zZ: this wednesday. Next week if fine for me too.

morning folks!

felix_:, _florent__, apurvanandan[m], aSobhy|away: I would suggest we do a short discussion/brain storming today in the afternoon then (at least 4/5 seem to have time) and a longer one early next week

Bertl: that's fine for me

last year we did a weekly general team/gsoc IRC meeting (those were on Mondays IIRC) to give everyone a chance to present development progress, ask questions and see what the others are up to

Hi Bandit1983 : i am also free for discussion for T763 , please let us know when u will be free .

Dev__ ,yes I had a look there,If BAndiT1983 approves I would be using that only

Army institute of technology , pune. , yours??

Don't u have exams in next phase yash

Final year undergrad ,So I need to only do an internship

I do need to present my work at the college though

Work of your internship or gsoc , its a nice and rare rule btw

perfect, see you all in a little more than an hour then

_florent__ is currently working on the software side of a SATA solution (among other) suitable for the AXIOM plugin slots

yep

apurvanandan[m] will be working on the USB 3.0 plugin module during GSoC 2019

both GSoC projects are based on data transfer between the Xilinx Zynq and Lattice Mach XO2

if anybody wants to add anything here to the introduction, please go ahead ...

on the lowest level, there is a number of signalling standards which can be used to transfer (usually serial) data between two points

correct, but as we aim for low latency there, we also need high data rates (at least at times)

more details on those can be found here:

https://en.wikipedia.org/wiki/Current-mode_logic

T731 (packet protocol) has 1 and 2 differential pairs available for data transfer

both the SDI and SATA plugins get up to 12 pairs

this is for example done in HDMI where one of the four high speed serial connections is used to transmit a reference clock

with enough connections (differential pairs) available, the separate clock is probably a rather appealing solution but when the number of connections goes down an embeded clock signal becomes more and more interesting

usually PLLs are available in modern FPGAs (and they certainly are in Artix 7 and Mach XO2)

please do not hesitate to add information when you consider it relevant

hi all

Hi

no problem, that's the idea

yes, it has, connected to the FTDI

ok, and a doubt , You mean to get the PLL in phase with data stream?

and some tricks to sample data with unsynchronized clocks

yes, but delays only result in phase difference, not in differences in frequency

a constant phase offset is much easiert to correct than frequency drift

yep

Yes ofcourse

you will get some jitter and a (unknown) phase relation, but you will have the same average frequency

Yes, agreed

one reason to use encodings on the data is to keep a balance between '1's and '0's during any data transmission

for example if you want to regenerate a clock signal from the data, you would not be very successful if the data was all '0's or all '1's for a longer period of time

mainly to reduce EM interference, while still keeping a balance between the two states

and most encodings also have a number of unused or illegal states

(on the larger encoded word size)

sidenote here: 8b/10b encoding usually refers to the IBM encoding used in many places

while the TMDS (HDMI) encoding is also 8/10 but quite different :)

the TMDS encoder is a little more complicated, but we've also done implementations for HDMI so this is a good option as well

many other codes with different data and code lengths are out there and what is best suited for the projects stull needs to be decided

note that in all four cases, the data transfer cannot utilize hardware mechanisms to regenerate the clock from the data because the data transfer happens over 'normal' connections and not multi gigabit tranceivers featuring clock regeneration logic

also less overhead; if you need something dc offset free, the 64b/67b code is a better fit, but i don't think that this is needed here; iirc the differential pairs are all dc coupled

so how to test the BER of a connection?

https://en.wikipedia.org/wiki/Pseudorandom_number_generator

https://en.wikipedia.org/wiki/Bit_error_rate

(Fibonacci as well as Galois implementation)

https://en.wikipedia.org/wiki/Linear-feedback_shift_register

the only thing required to use those is some kind of 'reset' synchronization

Ok, got it

any difference needs to be further analyzed to determine the number of toggled bits

xor the recieved bits with the expected ones and count the ones

again a number of options are available here ...

https://en.wikipedia.org/wiki/Error_correction_code

okay, you have the room now for input, discussion, questions, etc

I had planned dividing the 48 bit rgb data into 6 8-bit pieces

And the encode all of them into 10-bit words

?

This means 6 Ghz of 10 bit data

No this is the max, just give me a second I am telling

okay, so it doesn't look like we have a lot of input at the moment, and there is still time to go into detail for the various tasks

Firstly, In the current code we read 64 bit words at 160 MHz from RAM, I think we will have to increase that?

in any case, there are (up to) four of those which can read data at the same time

Yeah that is what I was trying to figure out

the limiting factor on the USB 3.0 plugin is probably the FTDI or the MachXO2 deserialization

so, regarding next meeting, what about Monday or Tuesday (13.05 or 14.05) again in the afternoon?

Have a VISA appointment

so it would be fine for you then?

Am I wrong here?

I can't say whether I will be available at afternoon but probably will be at night ( ie around 6 pm CEST)

I am trying to calculate maximum output that 6 LVDS can achieve on Zynq

*8/10 isdue to encoding scheme

which is slightly out of spec for the Zynq IO Ports but seems to work reasonably fine

anything below 1GHz (800Mbit) per channel is in spec and should be great

Bertl: for theses serial link, are you going to develop everything from scratch or do you already have some code?

start at 6pm is fine

well, we have bits and pieces but I guess it will end up being a development from scratch based on various example code

That is what I said actually, 800 Mbit on one channel that means 100MBps per channel which is again 600MByte per sec

That pci_screamer no?

Bertl: ok so the code here https://github.com/enjoy-digital/liteiclink/tree/master/liteiclink/serwb is doing

the lower layer are probably what you want for 1 lane

Ok, thanks. Although I have trouble understanding Migen, but will try

apurvanandan[m]: this can be use to understand how to setup thing, but maybe Bertl wants the code in VHDL?

https://github.com/enjoy-digital/liteiclink/blob/master/liteiclink/serwb/s7serdes.py

https://github.com/enjoy-digital/liteiclink/blob/master/liteiclink/serwb/phy.py

the second one create a serial link and instanciate the 7-series serdes

theer is also an example design

Bertl , isn't the separate lane for clock the least efficient method in our case

hmm

that is 833MHz vs 1GHz on the data lanes as the same data rate

Bertl: for now it's 1 clock lane/1 data lanes, but the code could probably be easily modified to 1 clock lane/ n data lanes

if you manage to have an additional clock via the RFW, you are even better off

Ok, it will take time to decide. I got it.

so, next serial data meeting, Tuesday, May 14th, 18:00 CEST

Yes, so the task of this week is to go through all this reading content and report progress on Tuesday.

What is on monday?

next tuesday 18:00 cest works for me

Some video chat or what?

apurvanandan[m]: nah, always here on IRC, way easier :)

Nevermind

XD

Thanks :)

Dev_, Y_G, usually i'm available after 5PM (german time), at the moment it's 5:18PM

trello is also fine, as long as you can track all the small sub-tasks and don't lose overview

Okay Bandit1983 , trello is fine for me.

Till now i am able to understand the codebase of OC and also the general approach for T763.

From my side,I am able to understand the communication of WSServer and Daemon .

Currently I'm trying to figure out how to handle multiple requests by the daemon.

Y_G why do you focus on multiple requests so much? single requests are already enough to handle at the moment, as the structure has to be adjusted so it's flexible enough but still stable

Sure ,then I'll move my focus to understanding the communication better

there is not much to check about it, or do you have any trouble to find the endpoints?

ok

" as the structure has to be adjusted so it's flexible enough but still stable " ,what structure are we talking about here?

Sure :)

also other things have to be checked about it, later it would also include secured connection, e.g. SSL

Bertl_oO: felix_ : Just a minor input that is a bit on the side of the discussion of data transfer. Is synchronization from the output module. The SDI module felix is working on has reference inputs, which should probably be used to synchronize the sensor sampling. So somekind of method to send sync data in return is probably needed. But there might be some spare lines for that?

so either that one is used for sending sync information or some 'low speed' GPIO can be used for that

Let's just establish it as forward and return channels

Bertl, for my project you said 1 and 2 differential pairs, all of them are LVDS? and how they connected ?

I have a question about the hardware I'll use