Current Server Time: 04:46 (Central Europe)

#apertus IRC Channel Logs

2019/05/14

Timezone: UTC


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