Current Server Time: 22:43 (Central Europe)

#apertus IRC Channel Logs

2015/03/06

Timezone: UTC


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