Current Server Time: 21:14 (Central Europe)

#apertus IRC Channel Logs

2019/06/04

Timezone: UTC


00:01
RexOrCine
Partial?
00:02
Bertl
yes, please leave it on
00:02
RexOrCine
Of course.
00:02
RexOrCine
changed nick to: RexOrCine|away
00:03
Davelister
joined the channel
00:03
Davelister
changed nick to: Guest80690
00:07
Guest80690
left the channel
00:12
apurvanandan[m]
Hey Bertl, It worked, we are able to program the RFW with our own code :D
00:12
apurvanandan[m]
in the remote beta
00:12
apurvanandan[m]
We toggled a pin also
00:12
Bertl
excellent!
00:13
apurvanandan[m]
Now will prepare for presentation :)
00:14
apurvanandan[m]
It will be through chats only no?
00:14
apurvanandan[m]
I mean IRC chat.
00:15
Bertl
yes, but you can provide (PDF?) slides as well if you like
00:16
apurvanandan[m]
Yeah, I will make slides. 15 min long presentation will be fine?
00:17
Bertl
sure, expect some question from folks who don't know the FTDI
00:17
apurvanandan[m]
Okk
01:53
futarisIRCcloud
left the channel
02:01
Davelister
joined the channel
02:01
Davelister
changed nick to: Guest8997
02:07
Guest8997
left the channel
02:57
Bertl
off to bed now ... have a good one everyone!
02:57
Bertl
changed nick to: Bertl_zZ
03:47
futarisIRCcloud
joined the channel
04:03
Davelister
joined the channel
04:03
Davelister
changed nick to: Guest43392
04:07
Guest43392
left the channel
05:08
Davelister
joined the channel
05:08
Davelister
changed nick to: Guest11552
05:22
BAndiT1983|away
changed nick to: BAndiT1983
05:23
BAndiT1983
changed nick to: BAndiT1983|away
06:16
Guest11552
left the channel
06:43
LordVan
left the channel
06:57
futarisIRCcloud
left the channel
07:12
Davelister
joined the channel
07:12
se6astian|away
changed nick to: se6astian
07:12
Davelister
changed nick to: Guest91195
07:16
Guest91195
left the channel
07:45
se6astian
changed nick to: se6astian|away
07:54
se6astian|away
changed nick to: se6astian
07:54
se6astian
left the channel
07:54
se6astian|away
joined the channel
07:55
se6astian|away
changed nick to: se6astian
07:55
se6astian
left the channel
07:55
BAndiT1983|away
left the channel
07:55
RexOrCine|away
left the channel
07:55
Nira|away
left the channel
07:55
philippej
left the channel
08:13
Davelister
joined the channel
08:13
Davelister
changed nick to: Guest91704
08:19
Guest91704
left the channel
09:21
Bertl_zZ
changed nick to: Bertl
09:21
Bertl
morning folks!
10:15
Davelister
joined the channel
10:15
Davelister
changed nick to: Guest4843
10:19
Guest4843
left the channel
10:24
ItsMeLenny
joined the channel
12:16
Davelister
joined the channel
12:16
Davelister
changed nick to: Guest84733
12:20
Guest84733
left the channel
13:58
ItsMeLenny
left the channel
14:16
Davelister
joined the channel
14:17
Davelister
changed nick to: Guest30471
14:21
Guest30471
left the channel
14:57
Bertl
off for now ... bbl
14:58
Bertl
changed nick to: Bertl_oO
15:31
Dev
joined the channel
15:31
Dev
changed nick to: Guest52884
15:32
dev__
joined the channel
15:38
dev__
Hello Bandit1983, After doing changes as you have suggested, I could able to load frames of MLV
15:38
dev__
https://github.com/kakashi-Of-Saringan/opencine/commit/78c6c8ebde8ae724310b6da443be124f34530559
15:39
dev__
There were some unwanted memory allocations in OCImage.cpp
15:39
dev__
What are the next steps regrading playback , optimization or bringing sliders into processing test
15:42
Guest52884
left the channel
15:42
dev__
left the channel
16:14
Davelister
joined the channel
16:14
Davelister
changed nick to: Guest61027
16:19
Guest61027
left the channel
16:42
Bertl_oO
changed nick to: Bertl
16:42
Bertl
back now ...
17:01
Bertl
apurvanandan[m]: how are you?
17:02
apurvanandan[m]
Hi Bertl,
17:02
apurvanandan[m]
I am fine
17:03
Bertl
ready?
17:03
apurvanandan[m]
Presentation is almost ready, just changing a slide a bit
17:03
Bertl
okay
17:03
apurvanandan[m]
But didn't get the time to rehearse what I have to speak
17:05
Bertl
happens sometimes :)
17:06
apurvanandan[m]
https://docs.google.com/presentation/d/14qhVNg21O4JjeTLjCuC_IdNfXwxFWjM-F1kAMySoTxU/edit?usp=sharing
17:06
apurvanandan[m]
Here it is
17:07
Bertl
okay then, let's hear about the FT601Q then
17:10
apurvanandan[m]
Hi everybody, This is my presentation summarizing the documentation of FT601Q FTDI chip. This was my last weeks task.
17:10
apurvanandan[m]
Next Slide please
17:11
Bertl
you probably better use slide page numbers :)
17:11
apurvanandan[m]
ok
17:13
apurvanandan[m]
On slide 2. The presentation is about the fllowing aspects of ft601q. Lets move on them one by one.
17:15
apurvanandan[m]
Slide 3. The first point FT601Q is a high performance FTDI USB 3.0 to 32-bit wide parallel FIFO interface bridge chip with up to 5Gbps of bandwidth.
17:17
apurvanandan[m]
What it means is this chip acts like a bridge between the USB 3.0 protocol and a chip/fpga that can send data through 32 bit wide FIFOs.
17:18
Bertl
at up to 5Gbit/s?
17:20
apurvanandan[m]
Sorry for the mistake, 5Gbps is the speed of USB 3.0 protocol
17:20
apurvanandan[m]
Not this chip.
17:20
apurvanandan[m]
The max speed we can attain with this chip is 3.2Gbits/s
17:21
Bertl
okay
17:22
apurvanandan[m]
So if we use this chip , we don't need to worry about the USB 3.0 protocol, hence it simplies the task.
17:22
apurvanandan[m]
On slide 4
17:23
RexOrCine|away
joined the channel
17:23
philippej|away
joined the channel
17:23
philippej|away
changed nick to: philippej
17:23
se6astian|away
joined the channel
17:23
Nira|away
joined the channel
17:23
BAndiT1983|away
joined the channel
17:23
se6astian|away
changed nick to: se6astian
17:23
BAndiT1983|away
changed nick to: BAndiT1983
17:25
Bertl
yes? on slide 4?
17:25
apurvanandan[m]
So this is the functional description, meaning we have these subunits inside the ft601q. Most of them are somewhat electrical side of the chip. The main thing here is the FIFO protocol management unit and the USB3.0 controller. Explained on next slide.
17:27
apurvanandan[m]
On slide 5
17:28
apurvanandan[m]
So , as it says. USB 3.0 protocol controller is responsible for the USB 3.0 interfacing of ft601q with connected pc.
17:29
Bertl
k
17:31
apurvanandan[m]
The ft601q has certain number of channels and buffer allocated to the channels. The management of this buffer and 32bit fifo interface is done by the fifo management uni
17:31
apurvanandan[m]
the second and third point
17:32
Bertl
can this be changed?
17:32
apurvanandan[m]
So lets move to slide 6
17:32
apurvanandan[m]
The ft601q offers various configuration, some main configs are discussed.
17:33
apurvanandan[m]
This chip offers the ft245 and ft 600 mode.
17:33
apurvanandan[m]
ft245 mode is for greater compatability with usb 2.0
17:34
apurvanandan[m]
FT245 mode only offers single channel bidirectional data transer
17:34
Bertl
but at USB 3 speeds?
17:34
apurvanandan[m]
While ft600 mode is what this is chip is designed for, ie 4 bidirectional channel data transfer
17:36
apurvanandan[m]
I searched this thing, Most probably it works with USB 3.0 also, similar to FT600 in single channel in out mode
17:38
apurvanandan[m]
So ft601q also offers selection of the number of channels we want to use
17:39
apurvanandan[m]
Depending on that it distributes the buffer available in the chips ie 8KB
17:39
apurvanandan[m]
The table describing the distribution is given
17:39
apurvanandan[m]
On slide 7
17:40
Bertl
that slide says 'Underrun handline'
17:40
Bertl
*handling
17:40
apurvanandan[m]
Two features of this chip which are again configurable
17:41
apurvanandan[m]
YesBertl
17:41
Bertl
just stating so folks know where we are
17:41
apurvanandan[m]
Ok
17:41
apurvanandan[m]
As it states, underrun is the condition when master stops sending the data to the fifo
17:42
apurvanandan[m]
In this condition, the session underrun is handled by sending the data in the fifo to the usb 3.0 host
17:43
Bertl
what's the master here and what is the host?
17:43
apurvanandan[m]
Master is the FIFO bus master ie the fpga
17:43
apurvanandan[m]
Host is the usb 3.0 pc
17:44
Bertl
okay, so that is something done _outside_ the FT601
17:45
apurvanandan[m]
So when this setting is turned off, then the session doesn't stops on the lack of data, and it waits untill the fifo is full again.
17:46
apurvanandan[m]
Then there are the notification pipes, they are just a feedback of the amount of data from the master to the connected pc. I don't find them that useful but it is a config so it is here.
17:46
apurvanandan[m]
Slide 8
17:47
apurvanandan[m]
The main thing
17:48
apurvanandan[m]
Fifo bus master is the circuit/state machine we wish to design on the fpga for feeding the data to the ft601q
17:49
apurvanandan[m]
Firstly,all the *_N are active low
17:49
apurvanandan[m]
RXF_N is the data receive acknowledge signal to the master
17:50
apurvanandan[m]
TXE_N is a optional signal, states that the master fifo idle status is valid or not
17:51
apurvanandan[m]
BUF_FUL and BUF_EMP are full /empty indicator of the fifo
17:51
apurvanandan[m]
i is counter for the 4 channels
17:52
apurvanandan[m]
And the state diagram is then self explanatory ?Bertl
17:53
Bertl
well, maybe :)
17:53
Bertl
anyway, let's move on, we can get back to that later
17:53
apurvanandan[m]
On slide 9
17:55
apurvanandan[m]
The ftdi manufacturers are good people, they have already provided us with a generic fifo bus master for spartan 6 fpga in Verilog.
17:55
apurvanandan[m]
With each configuration available
17:56
apurvanandan[m]
So I pushed the code on github with a short description of each module in the readme file
17:56
apurvanandan[m]
You can have a look at that later
17:56
Bertl
okay
17:56
apurvanandan[m]
On slide 10
18:00
apurvanandan[m]
So on the software side we have the proprietary d3xx driver (upgrade from d2XX for usb 2.0). It provides the APIs for handling the ftdi chips. Several software are available using this driver for testing the data streaming from ftdi chip
18:00
apurvanandan[m]
On slide 11
18:03
apurvanandan[m]
First 4 points we have talked on. The last point mentions how the data bus is used for signalling the fifo status to the master in the idle state.
18:04
apurvanandan[m]
And also for commanding the slave ie ft601q using the BE and DATA[7:0]
18:04
apurvanandan[m]
The truth table is given at bottom , you can have a look at that
18:04
apurvanandan[m]
On slide 12
18:05
Bertl
does that mean we need to do 'idle' cycles to know when the FIFOs get full/empty?
18:10
apurvanandan[m]
I think , when the master makes the bus idle it asserts 1s and then the fifo status is checked by data bus. But I will confirm that later
18:11
Bertl
okay
18:11
apurvanandan[m]
As we are dealing with large amounts of data , we need to maximise the performance of ft601q as per our needs
18:12
apurvanandan[m]
FIFO read efficiency is closely related to USB 3.0 output efficiency
18:13
apurvanandan[m]
The formula for efficiency is given with each timing variable marked in the bottom diagram.
18:15
Davelister
joined the channel
18:15
Davelister
changed nick to: Guest32078
18:15
apurvanandan[m]
So if we see, efficiency is (output time)/(total time needed). As we invested idle+ command+ bus turn+ data output time for the data output time, we get this formula.
18:16
Bertl
why is multi channel data rate higher than single channel?
18:19
apurvanandan[m]
Bertl: If we use strategies like one mentioned in third point, we are managing the data better, so we get better data rates. It should be one point actually.
18:19
Guest32078
left the channel
18:19
apurvanandan[m]
On slide 13
18:20
Bertl
well, to me it looks like we have overhead for switching between the channels
18:21
apurvanandan[m]
Bertl:Maybe ( I can't comment without trying)
18:21
Bertl
so I would assume that I can supply a single channel with almost 400MB/s (limited by the clock rate)
18:22
Bertl
but when I have four channels, I will need to add more command phases
18:22
Bertl
which will actually steal some data cycles
18:23
Bertl
(just from looking at the timing diagram on page 12)
18:24
apurvanandan[m]
Looks like when we already are using 4 channels then it may be benficial. But a single channel with perform better ( see on slide 13).
18:24
apurvanandan[m]
This point was mentioned in the documentation : If the FIFO master wants to get the max data throughput, the design should consider having a bigger FIFO size and also reduce the idle cycles between FIFO bus data transactions.
18:24
Bertl
on slide 13, the unlabeled axis at the bottom is the idle cycles per second?
18:26
apurvanandan[m]
yesBertl
18:28
apurvanandan[m]
They haven't written the unit anywhere on the documentation
18:28
apurvanandan[m]
On slide 14 , I have gien the references which helped me in makinng this presentation
18:28
apurvanandan[m]
On slide 15 : THANK YOU :)
18:29
Bertl
okay, thanks for the 15min presentation!
18:29
Bertl
:)
18:29
Bertl
I'm still a little confused by slide 13 though
18:30
apurvanandan[m]
I was unprepared, otherwise it would have been concise
18:30
Bertl
because assuming we are operating at full speed, we'll have about 100 million cycles per second
18:31
Bertl
now 120 or 320 idle cycles there should not matter at all
18:31
Bertl
i.e. they are just noise, but the diagram suggest a quite dramatic effect on the datarate
18:31
Bertl
at 120 [whatever] we already have lost 10% of our total bandwidth
18:32
Bertl
and at 320 [whatever] we are down to 75% as it seems
18:34
Bertl
aSobhy: you around?
18:34
aSobhy
yes I'm here :)
18:34
apurvanandan[m]
I am checking just a sec
18:35
Bertl
aSobhy: how did you like the presentation?
18:35
apurvanandan[m]
Bertl: You can go through page 5 of the 6th reference link in slide 14
18:37
aSobhy
actually I was concentrating at first but then lost
18:38
Bertl
fair enough, want to do a presentation next week?
18:39
apurvanandan[m]
Actually no
18:40
aSobhy
for what topic
18:40
Bertl
how about JTAG?
18:40
aSobhy
for what topic ?
18:40
apurvanandan[m]
I feel it is wastage of time making the ppt, when I can go thorugh more documentations, or write code.
18:40
apurvanandan[m]
The time of meeting is also wasted
18:41
Bertl
well, the idea was to go through all that stuff and give a short overview for everybody else so that they get the essential stuff without going through all the stuff
18:42
se6astian
its very interesting to follow from my perspective at least
18:42
Bertl
didn't say that there is any need to prepare slides, although they have probably illustrated the topic somewhat
18:42
Bertl
also didn't expect it to last one and a half hour :)
18:43
Bertl
but despite all those issues, we now have some interesting aspects to talk about
18:43
aSobhy
ok Bertl JTAG next week :)
18:43
Bertl
great! looking forward to it!
18:43
apurvanandan[m]
I would like you speaking and we listening.
18:44
Bertl
I guess you get that a lot in class, no? :)
18:44
BAndiT1983
apurvanandan[m], i think gsoc work a bit different and students have to propose
18:44
BAndiT1983
*works
18:45
Bertl
so back to the interesting aspects ...
18:45
apurvanandan[m]
Yes
18:45
Bertl
I think the timing diagram makes it obvious that we want to avoid everything but data cycles to maximize throughput
18:46
Bertl
so, any bus turn around, any idle cycles and any commands will reduce the amount of data and thus the bandwidth
18:47
Bertl
an interesting aspect is that we can do bidirectional stuff on USB 3.0 with only the bus turn around (and maybe a command?) cycle
18:48
Bertl
having two or four channels thus seems like a waste of bandwidth (unless there is something we are missing right now)
18:48
Bertl
I'm also not sure what the difference between the FT245 and FT601 mode is when operating with one channel
18:50
Bertl
I'm also not sure why the 'bandwidth demonstration' only achieves 360 MByte/s throughput
18:51
Bertl
let's assume we can transfer 4k in one go
18:51
Bertl
that means we might have to send a new command or do an idle cycle after 4096 cycles
18:51
Bertl
let's say we need 4 cycles for this, which is about 0.1% of the total bandwidth
18:52
Bertl
why would we lose another 10% ?
18:53
Bertl
maybe _florent__ has some input on this, but not sure he is around
18:56
Bertl
the unknown unit in the graph seems to be 'idle cycles per 4k data'
18:57
Bertl
which brings the question, why would there be 120-320 idle cycles each 4k data package?
18:58
Bertl
given that the USB 3.0 bus can do 5Gbit/s and we only can input or output data with 3.2Gbit/s (because of the 100MHz/32bit interface)
18:59
Bertl
anyway, we won't solve that right now (by contemplation) we need to do some test there
19:00
Bertl
speaking of, could you both describe the tests you did on the remote Beta yesterday?
19:00
apurvanandan
joined the channel
19:02
apurvanandan
left the channel
19:04
apurvanandan[m]
Yes sorry for delay
19:05
apurvanandan[m]
It was just preliminary test.
19:06
Bertl
well, I guess you managed to design, build, convert, upload and test code on one of the MachXO2s :)
19:07
Bertl
so an important step IMHO ...
19:07
aSobhy
yes the RFW that we were on it yesterday
19:08
Bertl
so short description, what did the test do, how was it verified
19:08
Bertl
is the code somewhere online?
19:09
aSobhy
I'll push it on git
19:10
aSobhy
it was togling a bit(we choose the CLK) and we checked it with eye as we type pic_gpio multiple of time and see it toggling
19:10
apurvanandan[m]
I made two bit files , with code equivalent to PB22B = PCIE_SDA in one and PB22B= ~PCIE_SDA in other and when I uploaded the bits on the RFW we saw the PB22B changing state with the two the bit files
19:11
Bertl
okay
19:12
apurvanandan[m]
So basically this ensured everything works
19:12
Bertl
of course! :)
19:12
Bertl
so what's the next step?
19:12
apurvanandan[m]
Now we need to dig a little more, and get this thing from emio of zynq
19:12
aSobhy
link training ?
19:12
apurvanandan[m]
and also on RFE
19:13
Bertl
(btw, you might want to document the build and upload step somewhere)
19:13
apurvanandan[m]
Ohh yes, I forgot, will do tomorrow
19:14
Bertl
okay, great! looking forward to 'link training' in the next few days :)
19:15
apurvanandan[m]
I will start working on the ft601 controller also.
19:16
apurvanandan[m]
And yeah the USB 3.0 plugin module is reaching me on June 10
19:16
Bertl
good, check with _florent__ when he's around, might have some tips ready
19:17
apurvanandan[m]
I am lagging from timeline :(
19:18
apurvanandan[m]
Will try to cover up
19:18
aSobhy
and also the doccumentation of the MachXO2 to see OPT
19:19
Bertl
okay, next meeting next week same time?
19:19
aSobhy
yeah fine with me :)
19:19
Bertl
we also should probably do a session on the weekend with the remote Beta
19:20
apurvanandan[m]
se6astian: Just to inform, USB 3.0 module is arriving on June 10 :)
19:20
se6astian
great, so you did get the notification, excellent
19:20
apurvanandan[m]
<Bertl "we also should probably do a ses"> Yes, it would be great
19:24
Bertl
okay then, anything else, feel free to contact me/us anytime
19:25
apurvanandan[m]
Am I not required to do presentation next week ?
19:25
aSobhy
can I ask If I'll recive some kits soon ?
19:28
Bertl
as explained, at the moment, there is little point in sending you hardware as it doesn't give you any benefit over the remote hardware we can service and extend
19:32
apurvanandan[m]
<Bertl "as explained, at the moment, the"> Bertl: Am I required to give presentation next week?
19:32
Bertl
nope
19:32
apurvanandan[m]
Ok Thanks! Good night!
19:33
Bertl
have a good one
19:44
BAndiT1983
changed nick to: BAndiT1983|away
19:45
aSobhy
I thought that my address I sent to se6astian will sent somthing
19:49
Bertl
you will certainly get something sooner or later, no worries
19:49
Bertl
but do you see any advantage in having e.g. the partial Beta at your place? anything you could do better or differently?
19:53
Davelister
joined the channel
19:54
Davelister
changed nick to: Guest79707
19:58
Guest79707
left the channel
20:00
Davelist1r
joined the channel
20:05
BAndiT1983|away
changed nick to: BAndiT1983
20:05
aSobhy
Its the same boxes I'll interface also I know. but I'm afraid to had trouples in the futuer( I didn't know what are they)
20:06
aSobhy
troubles*
20:12
BAndiT1983
hi dev_, which parts are missing at the moment to get a playback working?
20:12
BAndiT1983
it's not my task to tell you every step, in fact it's your task to provide me with information how you will proceed to solve the main goal of the gsoc task, please refer to your proposal
20:23
Bertl
aSobhy: no worries, once we see that it makes sense that you have the hardware in hands, we'll simply send it over
20:24
Bertl
just at the moment it is easier for us to maintain it and if something goes terribly wrong, replace it :)
20:37
aSobhy
ok Berl no problem
21:01
Davelist1r
left the channel
21:19
BAndiT1983
changed nick to: BAndiT1983|away
22:28
se6astian
changed nick to: se6astian|away
22:55
Bertl
off to bed now ... have a good one everyone!
22:55
Bertl
changed nick to: Bertl_zZ
22:57
Davelister
joined the channel
22:57
Davelister
changed nick to: Guest3198
23:04
Guest3198
left the channel
23:36
futarisIRCcloud
joined the channel