Current Server Time: 13:01 (Central Europe)

#apertus IRC Channel Logs

2015/03/10

Timezone: UTC


00:03
MatthiasF
left the channel
00:25
aombk3
changed nick to: aombk
01:34
alesage
left the channel
01:50
fsteinel
left the channel
01:50
fsteinel_
joined the channel
03:23
dmj726
left the channel
03:36
dmj726
joined the channel
06:51
jucar
joined the channel
07:46
cbohnens|away
changed nick to: cbohnens
07:49
Bertl_zZ
changed nick to: Bertl
07:49
Bertl
morning folks!
07:55
cbohnens
good morning
08:18
jucar
left the channel
08:19
Francky
joined the channel
08:19
Francky
hi all
08:20
danieel
left the channel
08:27
MatthiasF
joined the channel
08:35
niemand
joined the channel
08:38
se6astian|away
changed nick to: se6astian
08:38
Bertl
morning se6astian!
08:46
se6astian
good morning
08:46
se6astian
we are in the studio already :)
08:47
Bertl
great!
08:55
Jin|away
changed nick to: Jin^eLD
08:58
danieel
joined the channel
09:08
jucar
joined the channel
09:59
fsteinel_
changed nick to: fsteinel
10:21
niemand
left the channel
10:49
niemand
joined the channel
10:57
niemand
left the channel
11:04
jucar
left the channel
11:05
jucar
joined the channel
11:47
fsteinel
left the channel
12:18
fadro
joined the channel
12:18
fadro
left the channel
12:18
fadro
joined the channel
12:19
fadro
hi all
12:20
Bertl
hey fadro!
12:24
fadro
So quite on the irc today...
12:25
fadro
well let's make some noise with a small tips to discuss with.....
12:26
Bertl
hehe, go ahead!
12:27
fadro
Well coming from the IF board there will have a bunch of LVDS lanes to provide max video throuput (something like 50 lanes or wathever). But the trouble is that, since these lanes are affected to the video, they obviously cannot be affected to extending IO, so my question is the following:
12:29
fadro
Why not to allow some scalability on the IF video bus (let's call like this). For example, let's dedicate 40 lanes to the video, but provide 10 lanes which can be affected either to the video lanes or IO extension depending on the need.
12:30
fadro
because i imagiune that not all peoples will need the max throuput, so many lanes can be affected somewhere else...
12:30
Bertl
well, we have 36 LVDS pairs and a bunch of GPIO interfaces (SPI, I2C) on the interface board
12:31
fadro
Most of the LVDS pairs you are pseaking about are coming from both ICE 40 right?
12:31
Bertl
so the GPIO already cover most of the sensor low speed interfaces, what would be the purpose of dedicating high speed LVDS for I/O there?
12:32
Bertl
no, all LVDS pairs on the interface board come directly from the zynq
12:32
se6astian
another team talk in the can!
12:32
se6astian
not the trashcan :)
12:32
fadro
OK, sorry for the IF board.....don't read it, yes from the zynq, OK
12:33
Bertl
se6astian: opening another can of worms? :)
12:40
se6astian
changed nick to: se6astian|away
12:51
fadro
ok, just check the design, and concerning the IF board, i was speaking with the next IF board revision, the one with the FPGA.
12:52
fadro
So the idea on this new IF revision board was to allow a max sensor throuput, and this should be done by maximazing the IF bus size
12:53
Bertl
correct
12:54
fadro
OK, but i can imagine that some users will be interested in have a max sensor throuput while others won't
12:54
Bertl
most likely
12:58
fadro
so my thinking was to say : let's leave a part from this IF bus (so from the IF fpga to the µZ fpga) scalable, ie, having the choice to route some lines to the IF board if needed otherwise, reroute them to an extension IO connector (maybe plugin or shield?) to provide higher IO to external applications)
13:00
Bertl
the low power FPGAs have not the throughput the zynq has, so routing zynq LVDS pairs through them would significantly reduce the throughput
13:00
Bertl
ignoring that for a moment, the question is why would somebody who doesn't want full sensor bandwidth, require more I/O bandwidth?
13:06
fadro
if i Well the idea was not to use the LP fpga but a dedicated mux to achieve such operation. And getting the full BW form the sensor is great, but with the current design i see not enought IO BW (on shields or plugins) to exploit such dataflow, for example, i see no ways to put on a custom plugin board things like 6G SDI, or a SATA3 msata ssd because of the IO bottleneck (6 LVDS))
13:07
Bertl
you have 12 in total for a double plugin module, but I agree, it might be an option to reroute the now µC "dedicated" 6 LVDS channels there as well
13:07
Bertl
making a total of 18 LVDS pairs, which should be enough
13:09
Bertl
but it is probably a little tricky to get those pairs to the other side of the board
13:12
fadro
you mean tricky because of the 4 layers pcb constraints?
13:12
Bertl
yes
13:14
fadro
Well, why not to put an small Artix on the Beta rather than 2 ICE40. OK it will need a bit more power, but it will provide more flexibility and throuput.
13:21
Bertl
also a routing problem
13:22
Bertl
i.e. we would need to have it in the middle somewhere
13:22
Bertl
but you're welcome to try a design
13:25
fadro
well just having a quick look, i see no "easy to solder" packages in the Artix family. I guess this is also a constraint to take into account? Boards should be handed soldered?
13:34
jucar
left the channel
13:39
Bertl
or at least reflow with the OSHpark constraints
13:39
Bertl
which unfortunately rules out most BGA packages
13:44
Bertl
but I was considering the MachXO2 instead of the iCE40 for the "medium speed" I/O routing
13:44
Bertl
which might be a little more powerful
13:47
Bertl
haven't got the time to do a comparison with pros/cons yet though
13:50
fadro
the MachX02 100 pins TQFP could be a nice candidate! But routability needed to be checked even with this one.
13:51
Francky
why do you limit the pcb ordering to OSHpark ?
13:51
Francky
which seems to have hard contraints
13:52
Bertl
because it allows folks all over the world to get cheap PCBs and make some modifications to the design
13:52
Bertl
they are reasonably good quality and are not produced under dubious conditions
13:55
Bertl
and the constraints are not that hard, if you consider that somebody should be able to assemble the boards at home or at a fab lab
13:56
Bertl
of course, as PCB designer, it is always better to have smaller features, more layers, etc :)
13:58
intracube_afk
changed nick to: intracube
14:09
Francky
ok
14:22
se6astian|away
changed nick to: se6astian
14:27
alesage
joined the channel
14:31
masplund|away
changed nick to: masplund
14:31
se6astian
hi masplund
14:33
masplund
changed nick to: masplund|away
14:34
masplund|away
changed nick to: masplund
14:41
se6astian
hi masplund
14:43
Bertl
accept it, he doesn't want to hi you :)
15:48
niemand
joined the channel
16:27
niemand
left the channel
16:35
masplund
changed nick to: masplund|away
17:10
Francky
bye
17:10
Francky
left the channel
17:14
Bertl
cya
17:19
fadro
There something unclear to me on certains power distribution branchs:
17:19
fadro
for example, W_VW power line start from power board to the PWR-NW connector, goes into the beta board where it goes to XWest connector where it arrive to the IF board Xwest connector, where it is looped back to the power board through NW connector to finally reach the same power board starting point!
17:20
danieel
left the channel
17:21
Bertl
yeah, that is kind of a legacy
17:22
Bertl
it is very likely that we will drop the Xwest connection once the power connector setup is verified
17:23
Bertl
for now, you can see it as two supply pathes for those power connections
17:23
Bertl
in an earlier version, we had the power supply handled via the X-WEST/EAST connectors
17:24
Bertl
but that was suboptimal, which is why we introduced the PWR-NW/SE connectors
17:24
Bertl
the W_VW and E_VE conenctions are a leftover
17:25
fadro
Yes, that's what i saw but didn't understand yet. So these 2 connectors pin will not be mounted at the end, right?
17:26
Bertl
actually it's six on each X connector
17:27
Bertl
and they will get freed up for other connections soon
17:47
aombk
is the beta "within schedule"?
17:47
danieel
joined the channel
17:49
Bertl
aombk: within what schedule? :)
17:50
slikdigit
joined the channel
17:50
slikdigit
left the channel
17:50
slikdigit
joined the channel
17:52
aombk
i see... so it will be delayed?:P
17:53
aombk
i remember eta april 2015
17:53
Bertl
yeah, so the schedule we advertized during crowd funding
17:54
Bertl
well, we might make it with the Early Beta
17:54
Bertl
(this will be part of the next update video)
17:55
Bertl
but I think you need to be very brave to get one of those, unless you're a developer
17:56
Bertl
so I would say, for the typical user, it is probably better to wait a month or two
17:56
aombk
i have no idea what early beta is. i will wait for the video
17:56
Bertl
yes, please do so, it will be out tomorrow or the day after I guess
18:02
fadro
Well, i imagine that PWR_SW is also a legacy since signals are routed down to the sensor board, but not used yet.
18:04
Bertl
the sensor board is designed to be rotation symmetrical
18:04
Bertl
i.e. the sensor board can be rotated 180° and plugged into the very same interface board
18:08
fadro
was it a request from folks? what the purpose of such option?
18:09
Bertl
to some degree, but the original reason for that was that we wanted to rotate the MicroZed to get the connectors out of the way
18:10
Bertl
together with the fact that the design was already very symmetrical
18:10
Bertl
we decided that we can easily make that a feature
18:12
niemand
joined the channel
18:26
niemand
left the channel
18:27
intracube
left the channel
18:28
g3gg0
joined the channel
18:51
Jin^eLD
changed nick to: Jin|away
19:14
intracube
joined the channel
19:34
cbohnens
changed nick to: cbohnens|away
19:36
niemand
joined the channel
19:44
intracube
left the channel
19:57
intracube
joined the channel
20:00
jucar
joined the channel
20:39
intracube
left the channel
20:57
intracube
joined the channel
21:01
Jin|away
changed nick to: Jin^eLD
21:20
intracube
left the channel
21:51
se6astian
time for bed
21:51
se6astian
good night
21:51
niemand
left the channel
22:07
se6astian
changed nick to: se6astian|away
22:08
jucar
left the channel
22:09
intracube
joined the channel
22:55
Jin^eLD
changed nick to: Jin|away
23:21
g3gg0
left the channel