Current Server Time: 19:37 (Central Europe)

#apertus IRC Channel Logs

2015/03/06

Timezone: UTC


00:31
MatthiasF
left the channel
01:22
Jin^eLD
changed nick to: Jin|away
01:35
lab-bot
left the channel
01:35
lab-bot
joined the channel
01:40
aombk
ok so. beta needs a super8 mode
01:40
intracube
aombk: crop factor?
01:41
aombk
no. recording some minutes of different videos to a single file
01:42
aombk
like a reel
01:43
intracube
aombk: how would that be better than just recording individual clips?
01:44
intracube
and unless the plans have changed, the Beta won't record itself
01:45
aombk
it will not be better necessarily.[yes it wont record (but i think it will record compressed video after a while)]
01:47
aombk
but a friend found a super8 reel shot by his grandfather and we watched it and it was random 5-10 sec clips and it was very very good
01:47
aombk
instand art
01:49
intracube
aombk: could easily write a script to generate short compilations of clips once the data is transferred to computer
01:50
aombk
come on. you know thats not the same
01:55
intracube
yeah
01:55
intracube
you think enough people would like that as a feature?
01:56
fsteinel_
joined the channel
01:59
fsteinel
left the channel
02:00
aombk
i am not part of the department that thinks of what enough people would like. i know i would like that feature
02:01
intracube
fair enough :)
02:04
intracube
and some video formats can be joined together easily by concatenating the data
02:05
intracube
in that case it could be trivial to design into the recording device
02:48
fsteinel_
changed nick to: fsteinel
05:47
lab-bot
left the channel
05:47
lab-bot
joined the channel
07:36
cbohnens|away
changed nick to: cbohnens
07:44
Bertl_zZ
changed nick to: Bertl
07:44
Bertl
morning folks!
07:54
MatthiasF
joined the channel
08:02
Bertl
morning MatthiasF!
08:06
se6astian|away
changed nick to: se6astian
08:06
Bertl
morning se6astian!
08:06
se6astian
good morning
08:25
[1]Francky
joined the channel
08:29
cbohnens
good morning
08:31
[1]Francky
hi !
08:39
Bertl
hey [1]Francky! how's going?
08:40
[1]Francky
i cannot set my nickname to "Francky"
08:40
[1]Francky
i'm good ans you ?
08:40
[1]Francky
and*
08:41
Bertl
you might consider registering the nick with nickserv
08:41
Bertl
you can then reclaim it when necessary
08:42
[1]Francky
it is currious that thiere is no "Francky" in the user list but when i try to get it the server says that this nickname is already in use...
08:42
[1]Francky
thant doesn't matter
08:43
[1]Francky
i am sorry not to have a lot of time for woring and speaking about pic today
08:43
[1]Francky
maybe some times but not all the day
08:44
Bertl
no problem, I have a lot of other stuff to do as well
08:45
[1]Francky
just to finish about pic shield interface ... :)
08:45
[1]Francky
what do you think about this :
08:46
[1]Francky
- 1 PMP port dedicated to zynq communication (high speed and large bandwith) -> 16 bits data + 14 bit addr + 2 bits control (=32Ko adressed)
08:46
[1]Francky
for the first connector
08:47
[1]Francky
- 1 I2C connected to slow devices (power boards and others), 1 SPI + N CS + 3 power pin (VCC, VCCana, 1.8V), 2 GND
08:47
[1]Francky
for the second connector
08:47
[1]Francky
N as to be choosen
08:47
[1]Francky
has*
09:16
[1]Francky
left the channel
09:22
niemand
joined the channel
09:28
Andrej741
joined the channel
09:29
Jin|away
changed nick to: Jin^eLD
09:51
MatthiasF
Bertl: Morning
10:05
niemand
left the channel
10:20
Micka
joined the channel
10:21
Micka
left the channel
10:21
fadro
left the channel
10:45
Francky|busy
joined the channel
10:46
Francky|busy
Is the interface proposed good?
10:47
Bertl
we need to check regarding pins and board space
10:48
Francky|busy
But you found the idea interesting?
10:48
Francky|busy
The pmp bus can be adapt to pin and board place if needed
10:48
Bertl
the PMP makes perfect sense, although I'm not sure we have the pins
10:49
Bertl
the I2C (for power board) is required anyway and makes perfect sense
10:49
Bertl
I'm not sure about the SPI though, I have some ideas we should discuss when you have some time
10:50
Francky|busy
I have some time
10:52
Bertl
one problem with many SPI + CS is the routing in the current design
10:53
Bertl
i.e. we cannot easily route too many CS into the middle or to the other side of the board for example
10:53
Bertl
so one option would be to keep the sensors on one side (which is suboptimal)
10:54
Bertl
the other option would be to use some kind of SPI multiplexer in the middle
10:54
Bertl
or, we drop the SPI idea and use I2C with all sensors on the same bus
10:54
Francky|busy
Wait a minute : what is the need about spi/sensors?
10:54
Francky|busy
If we need only 2 sensors, one in each side
10:55
Francky|busy
Let's put 2 spi bus, 1 in each side
10:56
Bertl
please elaborate
10:56
Francky|busy
The MAIN idea of spi bus is to have high speed devices connected on it
10:57
Bertl
correct, like the IMU(s)
10:57
Francky|busy
In my mind, 10dof and accelerometers need this speed
10:57
Bertl
agreed
10:57
Francky|busy
If we need other devices, we will be able to put them on i2c bus
10:58
Bertl
yes
10:58
Francky|busy
ie : if a hacker want to add device, he will use i2c
10:58
Francky|busy
We have the best of the 2 worlds : speed of spi for main device, ability to add devices with i2c
10:59
Bertl
yes, I agree, that's the plan
11:00
Francky|busy
Or if the hacker want to have high speed device, he can put it directly on the micro shield
11:00
Bertl
okay, good point
11:01
Francky|busy
So you can choose to have 1 spi and 2 CS (10dof + accelero) or directly 2 spi
11:02
Bertl
well, yeah, but for example, the connection to the center of the board is currently limited to 3 wires
11:02
Bertl
we might be able to squeeze in two more though
11:03
Francky|busy
But cannot you put 1 spi on top side and one on bottom?
11:04
Bertl
the top side is blocked by the connector
11:04
[1]Francky
joined the channel
11:04
Bertl
the first inner layer is required for shielding
11:05
Francky|busy
left the channel
11:05
Bertl
the second inner layer is currently used for supplying power
11:05
Bertl
and the bottom layer has the 3 wires (which are already very close to the bottom high speed routing)
11:06
[1]Francky
ok i am looking at the sch
11:07
Bertl
but we got similar 3 wires from the other side
11:07
[1]Francky
i imagien you cannot rout the last bottom high speed line nearer each with the others ?
11:07
Bertl
not really a good idea
11:10
[1]Francky
so, has it is made, we could have only the 10DOF on the spi bus
11:10
[1]Francky
as*
11:11
Bertl
yes, unless we find some kind of simple multiplexor to put on the bus
11:13
[1]Francky
it could be a spi gpio expender, wich could control the CS of sensors ?!
11:14
[1]Francky
but we need a CS for it
11:14
Bertl
something like that
11:14
[1]Francky
so 1 more wire
11:15
[1]Francky
it is too bad to add a chip to save 1 wire don't you find ?
11:16
Bertl
yes, I'm looking for better options
11:18
[1]Francky
the 2 sensors are needed ?
11:19
Bertl
maybe, maybe not
11:20
[1]Francky
and why not put one of them on the pic shield ?
11:20
[1]Francky
and une se beta board to implement the more important one ?
11:20
Bertl
might be an option
11:21
Bertl
I have to check a few tings first
11:42
Bertl
I think the most flexible and still easily doable solution would be to put one of those iCE40 together with eeprom and I2C GPIO (for programming) into the middle area and use the left connection for the I2C and then utilize the right wires to distribute the data via the right side FPGA
11:43
Bertl
I just checked, we have enough space in the middle to do that and still add a bunch of sensors, which could be I2C or SPI based
11:43
Bertl
as long as the total I/O count doesn't exceed 15 pins
11:47
[1]Francky
i think i don't understand all your idea
11:48
[1]Francky
so in the midlle, we put a ice40, linked with zynq by lvds
11:48
[1]Francky
and some sensors
11:48
[1]Francky
linked with who ?
11:49
[1]Francky
linked with pic by spi
11:49
[1]Francky
dans ice40 will make the CS by I2C
11:49
[1]Francky
right ?
11:49
[1]Francky
and*
11:50
Bertl
middle small iCE40 linked with right side big iCE40
11:50
Bertl
(via 3 wires)
11:51
Bertl
this way we can move the data through the right side iCE40 into the PIC
11:51
Bertl
or alternatively, as it also connects to the zynq
11:51
Bertl
directly into to zynq/to the arm cores
11:51
Bertl
we also can multiplex the datastreem to accomodate a number of sensors in the middle
11:52
Bertl
even with different speeds and/or connections (I2C or SPI)
11:54
[1]Francky
so pic will speak with big iCE40 in spi, big iCE40 speak with small iCE40 in lvds, and small iCE40 will speak with the sensor in spi ?
11:56
Bertl
yep, something like this
11:57
[1]Francky
if you are not afraid that this kind of architecture can add a lot of problem of debugging/communication/synchro between all of the chip, why not
11:58
Bertl
well, of course it adds some complexity, but it solves the routing problem once and for all
11:58
[1]Francky
in fact the limiting things on the board is the space availaible to route wire between middle to right area
11:59
Bertl
I'll see if I can put the entire iCE40 bundle on the bottom of the PCB, in which case the top could still provide space for a solder-on board for testing
12:00
Bertl
so that we can try different sensor combinations without rerouting
12:06
[1]Francky
so you would pu a interface board between beta board and pic board to implement big iCE40
12:06
[1]Francky
?
12:09
Bertl
no, I'm talking about the center
12:09
Bertl
it is currently a solder-on place
12:14
[1]Francky
yes but for the right side, you will reroute the beta board ?
12:17
Bertl
yes
12:17
Bertl
we can still test the new concept with the existing board though
12:17
[1]Francky
with proto board
12:18
Bertl
or by designing the pic board for the final connections and adding an intermediate board
12:19
Bertl
we have all the relevant connections on the headers
12:30
[1]Francky
so the big iCE40 will be a PMP multiplexer, a SPI multiplexer and an I2C multiplexer for the microcontroleur board right ?
12:34
Bertl
yes, but all those functions are pretty independant
12:34
Bertl
(one of the advantages of FPGAs :)
12:35
[1]Francky
yes this (fpga) world seems to be wonderfull :)
12:36
Bertl
it has some problems, especially in the availability of suitable devices and proper documentation :)
12:36
[1]Francky
the aim is that the microcontroller don't see the fpga and speak to sensors on spi and i2c as they were directly connected to it right ?
12:36
Bertl
either that or we feed a combined stream (i.e. "virtual" device) to the microcontroller
12:37
[1]Francky
the disavatage of virtual device is the complexity of the fpga code
12:37
[1]Francky
no ,
12:37
[1]Francky
?
12:37
Bertl
we can decide that later based on testing and when we have a good idea what we want to do
12:37
[1]Francky
yes, only interfaces nned to be clear right now
12:38
Bertl
not necessarily, it really depends on the sensors, but yes, the "direct" mapping with "virtual" CS is probably the simplest approach for a start
12:38
Bertl
i.e. both FPGAs work as serializer/deserializer chain
12:39
[1]Francky
oh i have a general question about fpga
12:39
Bertl
shoot
12:40
[1]Francky
who speag about the iCE40, which seems to be a great device, but how do you "fell" the power of this or this other fpga ? by the number of logicl cells ? a frequency ?
12:41
[1]Francky
you*
12:41
[1]Francky
the start of my sentence is "you speak"
12:43
Bertl
you mean, how do I decide which FPGA to use?
12:43
Bertl
or how I compare different FPGAs feature wise?
12:46
[1]Francky
how do you decide that this fpga can be good for this use ?
12:48
Bertl
ah, yeah, well, that's always a tricky question
12:48
Bertl
first, there is electrical specifications/requirements
12:48
[1]Francky
indeed
12:48
Bertl
you need two voltages, e.g. 1.8V and 3.3V, then you have to pick one which has at least two I/O banks with different voltages
12:49
Bertl
then you need to figure out if it has enough "power" which might be frequency, throughput or just macrocells
12:49
Bertl
finally the footprint, availability and price
12:49
Bertl
other tricky aspects are programming, software, hardened peripherials, etc
12:50
Bertl
it is always good if devices come in different peformance/macrocell ranges
12:51
Bertl
so you can pick the larger one and later reduce the price by downgrading the device
12:51
[1]Francky
"enought power" is little bit hard to imagine when you don't have any experience with it
12:53
Bertl
yes, I agree, that requires either testing or some experience
12:53
[1]Francky
ok thanks
12:53
[1]Francky
i hope i will be able to make my own test plateform with beta boards
12:54
Bertl
I think you will have a lot of different devices to play with on the Beta :)
12:57
[1]Francky
starting with small iCE40 to hudge ZYNQ
12:57
Bertl
precisely
13:03
Bertl
I'm off for now ... bbl
13:03
Bertl
changed nick to: Bertl_oO
13:46
niemand
joined the channel
13:54
niemand
left the channel
15:00
cbohnens
changed nick to: cbohnens|away
15:52
niemand
joined the channel
16:03
se6astian
time to leave the office
16:03
se6astian
changed nick to: se6astian|away
16:29
niemand
left the channel
16:32
[1]Francky
off for today
16:32
[1]Francky
bye
16:32
[1]Francky
left the channel
16:54
Francky|busy
joined the channel
16:55
Francky|busy
left the channel
17:12
niemand
joined the channel
17:47
Jin^eLD
changed nick to: Jin|away
19:10
aombk2
joined the channel
19:13
aombk
left the channel
19:15
Bertl_oO
changed nick to: Bertl
19:15
Bertl
back now ...
20:16
niemand
left the channel
20:21
fadro
joined the channel
20:22
fadro
Hi Bertl, still there ??
20:24
Bertl
yup
20:27
niemand
joined the channel
20:35
fadro
Just to discuss about Zynq perfs with the LVDS lanes in the HR banks (this discussion is related to the IF board, and the ways to reduce lanes nber between the IF board and the µZ)
20:35
fadro
since HR banks will be the only available on the µZ...
20:37
g3gg0
joined the channel
20:37
Bertl
okay?
20:37
fadro
and from what i can see in datasheet, the max perf throuput with OSERDES is 950Mb/s in ddr mode for -1 SG
20:38
fadro
but in a last discussion you speak about 1200 Mb/s possibility right?
20:39
Bertl
the 950 is the "well defined" and "guaranteed over the full range" value
20:39
fadro
I'm trying to find it in the bunch of spec, but i can't.
20:41
Bertl
it's not that they zynq or the software keeps you from going beyond that limit
20:41
Bertl
actually xilinx says that the limits do not even apply if you are working e.g. in a reduced temperature range
20:42
Bertl
(just to give an example)
20:48
fadro
OK, so you mean you should go beyong the guaranted value?
20:49
Bertl
we will check how far we can go and we will probably do that on every camera individually
20:50
Bertl
it isn't too hard to have some checksumming and maybe even forward error correction on the data (we need some kind of crc anyway)
20:50
Bertl
which in turn will give a BER
20:51
Bertl
so if the data transfer at the current rate is not reliable, we can switch down a gear
20:53
fadro
OK. but when you design your system, you want to guaranty a minimal bandwidth, and to do so youonly rely on the guaranted specifications. Afterward, if your system can go beyong, that's even better.
20:54
Bertl
even with the 950Mb/s we are probably fine
20:54
Bertl
there is a lot of idle communication with the sensor
20:56
fadro
And you think that it should be possible to shrink the nber of lvds between the sensor and the µZ by half thanks to the IF board?
20:57
Bertl
well, the cmv12k has 64+3 channels
20:57
fadro
agreed
20:57
Bertl
two channels are "just" clock channels
20:58
Bertl
the third channel is the control channel
20:58
Bertl
data is "only" on 64 channels at most
20:58
Bertl
let's assume we need 2 lvds pairs for clock and control between zynq and interface board
20:59
Bertl
still leaves us with 34 "data" channels at 950Mb/s
21:00
Bertl
mean we have 85% of the absolute maximum throughput from the sensor covered
21:01
Bertl
(not considering idle data)
21:03
Bertl
in case we figure out that it doesn't work as expected, we could still change the current 36 lvds pairs to 40 pairs (by sacrificing a little flexibility with the spi ports)
21:04
Bertl
which would then cover 95%
21:04
Bertl
but I don't think that we will a) really hit that limit nor b) really need that throughput
21:08
fadro
Yes, agree with the fact that even if we get the full sensor throughput, we have no huge pipe to store or broadcast it anymore! This was more about to feel the limit of the system,
21:08
Bertl
another theoretical option (no idea if that works or not) would be to switch to a memory like interface
21:09
Bertl
and synchonously send the data on 34*2 channels at up to what? 800MHz
21:09
Bertl
but I'd rather avoid that mess and the involved training :)
21:12
Bertl
I think what might be important is to allow for fast memory access on the interface board, so that it has some kind of frame buffer to do summing or averaging on the sensor data when transmitting at full bandwidth
21:13
Bertl
this might actually become one of the most challenging parts of the design
21:13
fadro
In fact, since there will be no huge broadcast pipe (maxi will maybe 6Gps with picoZ on a 6G SDI link), nor storage pipe, it would make sense to reduce the size of the "bus lanes" between the IF board and the µZ. It will free LVDS lanes for others stuff...
21:15
Bertl
while this is correct, I think the current number is a good choice, we still have 12 lanes on the high speed side and 6 lanes on the GPIO side
21:16
Bertl
actually 13 on the high speed side :)
21:16
fadro
the 12 lanes you are speaking about are the 2x6lanes going to North and South PCIe connectors right??
21:16
Bertl
yep
21:16
fadro
Oh bytheway I saw an issue on the PCB power board....
21:17
Bertl
ah? let's hear
21:17
fadro
Sorry I don't all the tools here so i'll speak by memory only!
21:18
fadro
Well this issue is not critical, but it will prevent you from doing the current monitoring on the supplies rails for both shield pcb otions...
21:18
fadro
You'll need a cutter...! Here is what i remind:
21:19
intracube
left the channel
21:20
fadro
On the power rail called _NW1 & 2 which supplies the East & West shield, there is an unwanted track who act as a short circuit before the ferrite bead to the outer pin of the sensing resistor.
21:21
fadro
And since the 4 sensing layout are strictly identical, they have the same issue...
21:22
fadro
What i don't understand is how it is possible that the RDC missed that!
21:22
Bertl
hehe, that is intentional
21:22
Bertl
if you look closer, you'll see that I made two very small rectangles which do not have a stop mask
21:22
intracube
joined the channel
21:23
Bertl
I want to test what effect it has when the LDO feedback comes from after the sensing resistor
21:24
Bertl
as we get 3 boards from OSHpark anyway, I plan to build two versions for testing
21:24
Bertl
and in each version, I simply cut the respective feedback line
21:24
fadro
you cut on the small stop mask?
21:25
Bertl
on the small area where there is no solder mask, yes
21:25
Bertl
if you look at the board, on the right side of the NW1 and right above R61 for example are the cut points
21:27
Bertl
and yes, DRC complains about it loudly unless you approve it
21:27
fadro
OK. so my mistake! Everything goes right.
21:27
Bertl
nah, it's good that you found it, it might have been some oversight
21:28
Bertl
after all, I didn't document it as feature
21:30
fadro
I still working on the detailed architecture and dataflow diagram. It allow me to discover many details I have missed on the 1st readout. Once done I will submit it to you for validation/verif
21:31
Bertl
first I had two places for resistors (with only one populated) but that got too crowded just for a test
21:31
fadro
I think it's important to have a claer mind of the overall system before diving into technocal aspects...
21:32
Bertl
sounds good
21:32
Bertl
looking forward to it!
21:37
fadro
Other question : What do you think about switching the stacking order of the power pcb and the beta pcb??
21:38
fadro
I see 2 advantages:
21:38
fadro
1-power pcb will be more centric, which will reduce the overall ground loops
21:40
fadro
2- if a versin with the picoZ MGT is planned, the MGT connectors (like SDI, coaxpress, ...) must be immediatly underneath... So to keep a general coherency between all the stacking version, it should be good to swap?
21:41
Bertl
well, we have two "big" power rails, one supplies the MicroZed, and the other everything else
21:41
Bertl
so looking at it this way, the power board is right in the center
21:42
Bertl
another reason for the existing stackup is that we need some space for the plugin modules
21:42
Bertl
otherwise they end up sticking out of the back of the camera
21:43
Bertl
for the PicoZed, we have to add an adapter board anyway to break out the MGTs
21:43
fadro
you mean actually the power pcb is right centric in the stackup??
21:44
Bertl
it is from the power perspective, yes
21:44
Bertl
we have one big 5V rail going directly into the MicroZed
21:44
Bertl
and another 5V rail which supplies (through regulators) the BetaBoard
21:45
Bertl
one goes down through the connectors, and the other up
21:46
Bertl
switching beta board and power board would result in more power connections going down to supply beta board and MicroZed
21:46
Bertl
I'm not saying it couldn't be done, but it would be a little trickier I guess
21:47
Bertl
and we would immediately lose 5+1.6mm from the plugin module space
21:47
Bertl
well, actually only 5mm :)
21:47
Bertl
or? no, 6.6mm
21:48
Bertl
what bugs me more is that I do not have a smart solution for the PicoZed MGT interface yet, but I think we will find a solution there as well
21:50
fadro
anyway tha power connections you are speaking about alreay exists and their number won't change by swapping power and beta. But what is right, is that you have to carry the "heavy 5V" for the µZ through the beta in this case...
21:53
fadro
The thing i find dangerous in the actual power distribution is to remote the supplies of the sensor on the power pcb (since the sensor is user interchangeable, otherwise, why not)
21:54
Bertl
my first design had all the sensor specific power supplies on the sensor board
21:55
Bertl
but two reasons led me to the current design, whether it is a good or bad one :)
21:55
Bertl
first, almost all sensors specify a voltage range not single voltages
21:56
Bertl
and sensor manufacturers also encourage to play with those voltages
21:56
Bertl
and secondly, power regulation uses up a lot of space and inevitably creates heat, which we do not want to have on the sensor board
21:59
fadro
understand your point of view.
22:02
fadro
So that's it for me today. I'll digest all that informations!! Thanks. bye
22:02
Bertl
regarding swapping beta and power board ... if you find the time, try it
22:02
Bertl
you'll see that it complicates things quite a lot
22:03
Bertl
thanks for the feedback! very appreciated!
22:04
fadro
left the channel
22:16
Bertl
off to bed now ... have a good one everyone!
22:16
Bertl
changed nick to: Bertl_zZ
22:44
niemand
left the channel
23:42
Rebelj12a
joined the channel
23:42
Rebelj12a
Ah boy its been too long
23:44
Rebelj12a
Hows progress?
23:56
MatthiasF
left the channel