Current Server Time: 18:26 (Central Europe)

#apertus IRC Channel Logs

2019/05/14

Timezone: UTC


01:45
johnathan
joined the channel
02:04
lexano
left the channel
02:09
lexano
joined the channel
02:14
aSobhy
changed nick to: aSobhy|away
02:22
futarisIRCcloud
joined the channel
02:28
Bertl_oO
off to bed now ... have a good one everyone!
02:28
Bertl_oO
changed nick to: Bertl_zZ
03:12
intrac
left the channel
03:12
intrac
joined the channel
06:00
BAndiT1983|away
changed nick to: BAndiT1983
06:47
BAndiT1983
changed nick to: BAndiT1983|away
06:57
johnathan
left the channel
07:18
johnathan
joined the channel
07:19
johnathan
left the channel
07:19
johnathan
joined the channel
08:08
Nira|away
changed nick to: Nira
09:27
se6astian|away
changed nick to: se6astian
09:37
Bertl_zZ
changed nick to: Bertl
09:37
Bertl
morning folks!
11:10
johnathan
left the channel
11:32
futarisIRCcloud
left the channel
13:11
johnathan
joined the channel
13:15
johnathan
left the channel
13:19
aSobhy|away
changed nick to: aSobhy
13:23
Spirit532
left the channel
13:23
Spirit532
joined the channel
13:27
Nira
changed nick to: Nira|away
15:03
se6astian
changed nick to: se6astian|away
15:11
se6astian|away
changed nick to: se6astian
15:29
Nira|away
changed nick to: Nira
15:46
BAndiT1983|away
changed nick to: BAndiT1983
16:55
se6astian
changed nick to: se6astian|away
16:58
Bertl
evening! everybody ready for the next discussion round with the topic "high speed FPGA communication"?
16:58
aSobhy
Yes
17:00
felix_
yep
17:00
apurvanandan[m]
yes
17:01
Bertl
so who want's to do a short recap what we concluded last time?
17:03
Bertl
please, not everbody at once! :)
17:04
apurvanandan[m]
We talked about how to send clock to the plugin modules, the encoding schemes , how to measure error rate and CRC and error reduction
17:07
Bertl
okay so in my experience, the 'simple' task of getting a simple serial link to work and measuring error rate is not trivial
17:07
Bertl
maybe somebody wants to share some experience with high speed serial links here?
17:08
Bertl
felix_, _florent__ maybe?
17:09
felix_
for source-synchronous links, the transmitter side is much easier to implement and get right than the receiver side
17:10
felix_
even when the clock and data have the right phase relation at the source, you'll get some additional delay for the clock through the clock distribution networks on the reveiver side and you'll need to compensate that
17:11
BAndiT1983
changed nick to: BAndiT1983|away
17:12
Bertl
a note here: do not fool yourself and think that you can get away with static delays in a high speed setup, even if the clocks are synchronized and the data has a known phase relation to the clock
17:12
johnathan
joined the channel
17:13
Bertl
at a certain data rate (probably anything above 200MHz) the jitter and clock variation is enough to mess up any static delays and ultimately increase the BER dramatically
17:13
felix_
having both sides of the system run on a clock that's derrived from the same oscillator also makes things much easier; beware though, that the while the phase offset doesn't change during runtime, it's not really predictable
17:14
johnathan
left the channel
17:14
johnathan
joined the channel
17:14
felix_
having clocks with the same nominal frequency, but form different sources have to be treated as asynchronous or you're in for some really hard to debug trouble
17:15
felix_
you also won't know which clock will be slightly faster; it's much easier when you know that one clock is always faster
17:16
felix_
but yeah, the clocking and adjusting the phases of the signals is what you'll likely spend most time on
17:17
felix_
when designing a fpga board it's also really important to have the clocks routed to clock-capable inputs and the data pairs routed to the same io bank, but since the hardware already exists, that shouldn't be a problem here
17:18
johnathan
left the channel
17:19
Bertl
so basically there are two 'goog' clocking setups and one 'not so trivial'
17:19
Bertl
1) the clock is generated by the source, the data is phase aligned, both clock and data are transmitted to the destination
17:20
Bertl
2) the clock is generated by the destination, sent to the source which regnerates it, aligns the data and sends it over
17:20
Bertl
3) both ends have a free running clock of 'about the same' frequency, data is aligned to the source clock, but sampled with the destination clock
17:21
felix_
i'd strongly advise against 3)
17:21
Bertl
the big advantage of 1) and 2) is that the amount of data per unit of time will always be the same on both ends
17:22
Bertl
if you go for case 3) you have to expect slightly more or less data on sender or receiver side and prepare for this case
17:22
Bertl
i.e. have stuffing bits/bytes you can drop or add when required
17:22
Bertl
so as felix_ already said, if possible, stay away from that
17:23
Bertl
now a fourth way to handle things is to regenerate the clock from the data received
17:24
Bertl
the problem with that usually is that you need special hardware or do some advanced trickery to keep the alignment with the data
17:24
Bertl
one way to actively synchronize a PLL to some data packets is by constant dynamic phase shifting based on the received data
17:25
Bertl
it should be noted here that this is not trivial either and if possible should be avoided
17:25
Bertl
aSobhy, apurvanandan[m]: any questions so far?
17:26
apurvanandan[m]
Bertl are you saying embedded clock method is very complicated?
17:28
Bertl
without dedicated hardware support it usually is
17:28
Bertl
for example the gigabit tranceivers available on some 7 Series FPGA can do clock recovery from the received data signal
17:29
apurvanandan[m]
Oh, I didn't knew this.
17:29
Bertl
there it is just a matter of either clocking your design from that recovered clock or doing a clock domain transition via FIFO
17:29
aSobhy
not yet
17:29
apurvanandan[m]
If clock is embedded in data only then why will need alignment with data.
17:30
apurvanandan[m]
?
17:30
Bertl
let's say you have a simple code with embedded clock
17:31
Bertl
e.g. manchester coding, 10 for '1' and 01 for '0'
17:31
Bertl
this is guaranteed to give you enough transitions to easily recover a clock
17:32
Bertl
now given that there is no hardware support for clock recovery, how do you approach sampling here?
17:33
Bertl
https://upload.wikimedia.org/wikipedia/commons/thumb/9/90/Manchester_encoding_both_conventions.svg/975px-Manchester_encoding_both_conventions.svg.png
17:35
apurvanandan[m]
Sorry I dont know about clock recovery in so much depths :(
17:36
Bertl
okay, so maybe read up on that then (till next time)
17:37
Bertl
basically you need to have a local clock and sample at a higher frequency to figure out where the transitions happen
17:37
apurvanandan[m]
Ok
17:37
Bertl
once you know that, you can adjust your local clock (either frequency or phase) to match the transitions
17:38
Bertl
but you are basically operating in the case 3) scenario
17:38
Bertl
which means that you have to handle all the ugly stuff of two free running clocks
17:38
apurvanandan[m]
ok, i understand
17:39
Bertl
now let's take a look at the second aspect of high speed serial, the verification
17:39
Bertl
i.e. how to check that your connection is reliable (and how to quantify the reliability)
17:39
Bertl
in short, how to estimate the BER
17:40
Bertl
one problem here which always comes up is "what test pattern/data should I use"
17:40
Bertl
?
17:41
Bertl
and we already talked about that last time, so what is a good approach here?
17:41
apurvanandan[m]
Use a PRNG
17:41
aSobhy
8b/10b
17:42
aSobhy
with psudo random number generator
17:42
Bertl
yes, you want to use a pseudo random generator to generate your test stream
17:43
Bertl
this is rather straight forward and you can get arbitrarily long random sequences with very simple designs (only a few gates)
17:43
Bertl
the 'magic' word here is LFSRs
17:44
Bertl
the tricky part in testing is to synchronize both sides so that they send and expect the same sequence
17:44
apurvanandan[m]
Resetting both side together
17:45
Bertl
the simplest approach here is to have a 'magic sequence' to reset the LFSRs
17:45
Bertl
unless you take special precautions, a typical LFSR doesn't reach all bit combinations during normal operation
17:46
Bertl
specifically the two basic designs (fibonaccy and galois) typically leave out all zero or all one states
17:47
apurvanandan[m]
Yes
17:47
Bertl
so you can use this specific data word to reset the receiver
17:48
Bertl
note that this presumes that you already established a connection, somehow trained the delays, and aligned the words on both sides
17:48
apurvanandan[m]
Will we need some feedback that module has been reset
17:48
apurvanandan[m]
?
17:48
apurvanandan[m]
Ok
17:48
Bertl
feedback to the sender?
17:48
apurvanandan[m]
Yes
17:49
Bertl
usually no, because when the feedback arrives at the sender, the data transfer is already in progress
17:49
apurvanandan[m]
Ok got it
17:49
Bertl
typically for testing is is sufficient to do accounting on both sides separately
17:50
apurvanandan[m]
yep
17:50
Bertl
caveat here: the clock domain where you read out the accounting data will usually be a different domain than the high speed serial transfer
17:51
Bertl
so you need to prepare for a clock domain crossing there to avoid problems
17:51
felix_
when using 8b/10b encoding you could also use some non-data symbol for synchronization. you still need to do the word aligning for this though
17:53
Bertl
note that most codes define so called 'comma symbols'
17:54
Bertl
those are specific symbol words within the encoding used to signal special conditions
17:54
felix_
yep, that's what i meant
17:54
Bertl
they often also use sequences which cannot be generated during 'normal' data transmissions
17:55
Bertl
okay, any input, comments, questions, etc?
17:56
apurvanandan[m]
I wanted to ask felix about 64b/66b encoding scheme
17:57
aSobhy
yeah I don't understand what the caveat rule means ?
17:57
felix_
it has less overhead than 8b/10b and it's based on shift registers
17:58
Bertl
aSobhy: let's say the serial clock runs at 500MHz and the data is transferred on each clock cycle (SDR)
17:58
Bertl
let's also assume that you collect 10 bits (8b/10b) encoding
17:58
Bertl
so you end up with one byte at 50MHz clock
17:59
aSobhy
ah okay got it
17:59
Bertl
you design then does BER accounting at this clock rate (two counters, total/fail)
18:00
Bertl
and this data needs to get out of the FPGA somehow :)
18:00
Bertl
let's say you report the current total/fail counters via SERIAL
18:00
Bertl
then you either have to make the serial clock related to your 50MHz data clock or you need to transfer the counter values to a different clock domain
18:01
Bertl
typically you will retrieve the data via JTAG or output it over UART or some other way
18:01
felix_
is afk for the next ~3h
18:01
Bertl
okay, thanks felix_!
18:01
Bertl
in any case, you need to transfer the data in a reliable way
18:02
felix_
oh and if you have questions, you can always ping me here; might take some time that i'll respond though
18:03
Bertl
okay, I guess we conclude the meeting for today with a few points to look into for next time, specifically:
18:03
Bertl
- encodings, why and how?
18:03
Bertl
- link training, bit and word alignment
18:04
Bertl
- dynamic delay adjustments (sender and/or receiver)
18:04
Bertl
try to dig through information online to get an idea how it works and how it can be done
18:05
Bertl
bonus points if you can explain the stuff next time and/or find new and useful information online :)
18:05
Bertl
next week, same time is fine?
18:06
apurvanandan[m]
Yes, most probably
18:06
aSobhy
can it be the same as Monday
18:06
Bertl
hmm, did we change the time for next monday?
18:07
Bertl
(otherwise it is the same anyway :)
18:07
aSobhy
an hour later
18:07
Dev_
joined the channel
18:08
Bertl
okay, so for me, 17:00 UTC is fine as well
18:08
aSobhy
because its the time of fasten
18:08
aSobhy
OK thanks Bertl :)
18:08
Bertl
apurvanandan[m]: any problems with that?
18:08
aSobhy
and for apurvanandan[m] ?
18:09
apurvanandan[m]
fine for me
18:10
aSobhy
^_^
18:10
Bertl
great! let me know if you have any questions in the meantime
18:11
Bertl
we will be busy over the weekend, but I'll try to answer those questions in a timely manner
18:12
Dev_
left the channel
18:12
aSobhy
ah you told that we run in the case 3
18:13
aSobhy
and for the ZYNQ & MachXO2 share the same clock
18:13
aSobhy
how can we separate it tp be two clocks ?
18:13
aSobhy
to*
18:14
Bertl
in the current design, the zynq has two clocks and a number of PLLs which can derive frequencies from that
18:15
Bertl
the MachXO2 has an internal oscillator as well and at least one PLL
18:15
apurvanandan[m]
Bertl can you share how you use openocd with your jtag
18:15
Bertl
there is a dedicated connection to a clock capable pin (Zynq to MachXO2) which can be used to create a phase synchronous clock in the MachXO2
18:17
Bertl
apurvanandan[m]: I'm currently using a digilent HS2 or HS3 jtag adapter (USB) with openocd
18:19
aSobhy
ok
18:20
Bertl
but uploading a configuration to the MachXO2 is not very complicated, so it doesn't depend on special jtag programmers
18:20
Bertl
can be done with a simple FTDI USB interface as well
18:21
Bertl
we will go through programming the MachXO2 in the Beta when we are back from the Maker Faire
18:24
apurvanandan[m]
Do you have some manual how to use it with opencd
18:25
Bertl
http://openocd.org/doc/html/Debug-Adapter-Hardware.html
18:25
Bertl
the HS1 is linked there, the HS2 has a similar config
18:28
apurvanandan[m]
Ok, will try for xup and tell you if face any problem
18:28
apurvanandan[m]
hs2 will be used for machXO2?
18:28
Bertl
try with something simple first, e.g. discovery
18:29
Bertl
i.e. connect it to your 'known good' device (the dev board)
18:29
Bertl
then use openocd with different configurations to get jtag chain discovery working
18:30
Bertl
one that works, you can switch to other jtag targets
18:31
aSobhy
apurvanandan[m]: what is opencd ?
18:32
Bertl
openocd
18:35
aSobhy
Its for debugging HW?
18:36
Bertl
yup
18:38
aSobhy
ok I find it
19:00
Dev_
joined the channel
19:13
Dev_
Hello BAndiT1983|away ,
19:14
Dev_
Sorry , Yesterday I had to left off in between.
19:14
Dev_
Let me continue where i left off...
19:15
Dev_
have you evaluated how this would be used by the application? : - I am using this approach (increase the slider position whenever playbutton is pressed and stop when pressed again) to visualize playing video. Right now I am just focusing on only this event.
19:16
Dev_
Also looked for MVP model
19:19
Dev_
as much as I could understand , the plabacksilder.ui will act as "View" part and all the logic of events will be implemented in Playbackslider class
19:20
Dev_
I would be great if u could explain the how modules will interact
19:22
Dev_
left the channel
19:22
BAndiT1983|away
changed nick to: BAndiT1983
19:23
Dev_
joined the channel
19:24
BAndiT1983
hi Dev_, i would expect to hear from you how it should interact, as it's a part of gsoc
19:24
BAndiT1983
my job is to guide you in the right direction
19:26
Dev_
okay, I will try to understand it
19:27
BAndiT1983
of course oyu can ask questions, if you need explanations, but the main tasks are ones to be solved by you
19:30
Dev_
what about the approach which i explained for playButton , Can u please provide feedback on that
19:30
Nira
changed nick to: Nira|away
19:30
Nira|away
changed nick to: Nira
19:31
BAndiT1983
have seen it, but still not sure how it will work, please explain a bit more in detail
19:34
Dev_
Yes, to visualize playing video: Each time we click the playbutton , it will pause or play the video. The slider will update its positon when the button is clicked.
19:35
BAndiT1983
who will update slider position and who will play the video?
19:36
Dev_
So whenever we have to keep track of change in state of playbutton, and update the slider value using ui->horizantal-slider->setValue();
19:36
BAndiT1983
playback slider will only provide events and maybe some methods to control it from outside, if required
19:37
BAndiT1983
but you still require some modules who will consume the events and also to play the video
19:37
BAndiT1983
e.g. to load a frame you need to use frame preprocessor, downscaler or debayerer and then the output, this is just an example of coarse pipeline
19:38
BAndiT1983
and when the frame is loaded, an event should be executed to notify other modules about it, also one which will update the slider position
19:40
Dev_
so its not he playbutton which call for event?
19:40
Dev_
The*
19:41
BAndiT1983
playbutton, or to be precise the playback slider, as it is a container for the player elements, will throw event, e.g. "play button toggled"
19:42
BAndiT1983
the event/signal could provide the variable which state was toggled, e.g. through enum PlaybackState::PAUSED
19:47
Dev_
left the channel
20:00
Dev_
joined the channel
20:07
Dev_
So we have to take account of modules of occore to interact with ui , which includes controlling of loading of frames through buttons on ui
20:07
Dev_
It looks typical now :( , don't have idea how it should be implemented
20:09
BAndiT1983
start by drawing flow diagram or sequence diagram or both and imagine how different actions, like clicking play button, would trigger events, which will be consumed by other modules etc.
20:09
BAndiT1983
to get started you can also start by googling "video player architecture"
20:09
Dev_
I will try to make a flowchart which includes occore as frames provider and intraction of events .
20:10
BAndiT1983
example -> https://i.stack.imgur.com/SPe5g.png
20:10
BAndiT1983
you have to make it more detailed as occore is rather general and contains a couplle of modules which are required
20:11
Dev_
As rought idea , clicking of play button will start loading of frame and pausing it will stop loading of frames ,
20:12
Dev_
Can I take it in this way ?
20:12
Dev_
In-between updating slider will take place
20:13
BAndiT1983
yes, sounds good, but also please don't forget that a play button, or any other in the slider playback is rather passive and only fires an event
20:13
BAndiT1983
updating slider happens not in the playback slider, it only provides a method to do it from other modules
20:14
Dev_
That event will be implemented and keep them as "presenter" part of MVP module
20:15
BAndiT1983
example sequence: playback button is clicked, event is fired on the event hub, frame provider is subscribed to it and starts to load next frames and send an event to the event hub, which video output consumes, frame provider also fires an event that frame is loaded (maybe same event is sufficient), then playback slider is updated by certain module
20:16
BAndiT1983
event hub is used, when events are supposed for broad crowd and not only for modules in near vicinity
20:16
BAndiT1983
the task is not simple at first, know it from OC development, as i've started to work on the project to improve my software dev skills for my job
20:17
BAndiT1983
but after short time you will get used to the software architecture ideas, they are not even used that pedantic in OC yet
20:18
Dev_
Yes , I will also try to learn asap
20:19
Dev_
I will provide you a flowchart for this when I will be able to get clear idea for this
20:20
BAndiT1983
if i haven'T mentioned some useful pages -> sourcemaking.com
20:20
BAndiT1983
try to start drawing and we can discuss it if you feel that you get stuck
20:22
Dev_
Yes , I will try to understand it more
20:22
Dev_
Thanks for the help
20:23
BAndiT1983
no problem
20:31
Dev_
left the channel
20:36
BAndiT1983
changed nick to: BAndiT1983|away
20:49
se6astian|away
changed nick to: se6astian
21:06
Nira
changed nick to: Nira|away
21:20
Nira|away
changed nick to: Nira
21:22
felix_
so next high speed serial link talk is next monday at 17:00 CEST, right?
21:22
Bertl
17:00 UTC
21:23
Bertl
i.e. 19:00 CEST
21:23
felix_
ok, that'll work for me
21:23
Bertl
great!
21:43
Bertl
off for now ... bbl
21:43
Bertl
changed nick to: Bertl_oO
22:01
se6astian
off to bed
22:01
se6astian
good night
22:01
se6astian
changed nick to: se6astian|away
00:25
Bertl_oO
off to bed now ... have a good one everyone!
00:25
Bertl_oO
changed nick to: Bertl_zZ
00:41
Nira
changed nick to: Nira|away