Current Server Time: 18:51 (Central Europe)

#apertus IRC Channel Logs

2019/06/04

Timezone: UTC


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