Current Server Time: 23:32 (Central Europe)

#apertus IRC Channel Logs

2015/03/10

Timezone: UTC


23:03
MatthiasF
left the channel
23:25
aombk3
changed nick to: aombk
00:34
alesage
left the channel
00:50
fsteinel
left the channel
00:50
fsteinel_
joined the channel
02:23
dmj726
left the channel
02:36
dmj726
joined the channel
05:51
jucar
joined the channel
06:46
cbohnens|away
changed nick to: cbohnens
06:49
Bertl_zZ
changed nick to: Bertl
06:49
Bertl
morning folks!
06:55
cbohnens
good morning
07:18
jucar
left the channel
07:19
Francky
joined the channel
07:19
Francky
hi all
07:20
danieel
left the channel
07:27
MatthiasF
joined the channel
07:35
niemand
joined the channel
07:38
se6astian|away
changed nick to: se6astian
07:38
Bertl
morning se6astian!
07:46
se6astian
good morning
07:46
se6astian
we are in the studio already :)
07:47
Bertl
great!
07:55
Jin|away
changed nick to: Jin^eLD
07:58
danieel
joined the channel
08:08
jucar
joined the channel
08:59
fsteinel_
changed nick to: fsteinel
09:21
niemand
left the channel
09:49
niemand
joined the channel
09:57
niemand
left the channel
10:04
jucar
left the channel
10:05
jucar
joined the channel
10:47
fsteinel
left the channel
11:18
fadro
joined the channel
11:18
fadro
left the channel
11:18
fadro
joined the channel
11:19
fadro
hi all
11:20
Bertl
hey fadro!
11:24
fadro
So quite on the irc today...
11:25
fadro
well let's make some noise with a small tips to discuss with.....
11:26
Bertl
hehe, go ahead!
11: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:
11: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.
11:30
fadro
because i imagiune that not all peoples will need the max throuput, so many lanes can be affected somewhere else...
11:30
Bertl
well, we have 36 LVDS pairs and a bunch of GPIO interfaces (SPI, I2C) on the interface board
11:31
fadro
Most of the LVDS pairs you are pseaking about are coming from both ICE 40 right?
11: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?
11:32
Bertl
no, all LVDS pairs on the interface board come directly from the zynq
11:32
se6astian
another team talk in the can!
11:32
se6astian
not the trashcan :)
11:32
fadro
OK, sorry for the IF board.....don't read it, yes from the zynq, OK
11:33
Bertl
se6astian: opening another can of worms? :)
11:40
se6astian
changed nick to: se6astian|away
11: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.
11: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
11:53
Bertl
correct
11:54
fadro
OK, but i can imagine that some users will be interested in have a max sensor throuput while others won't
11:54
Bertl
most likely
11: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)
12: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
12: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?
12: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))
12: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
12:07
Bertl
making a total of 18 LVDS pairs, which should be enough
12:09
Bertl
but it is probably a little tricky to get those pairs to the other side of the board
12:12
fadro
you mean tricky because of the 4 layers pcb constraints?
12:12
Bertl
yes
12: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.
12:21
Bertl
also a routing problem
12:22
Bertl
i.e. we would need to have it in the middle somewhere
12:22
Bertl
but you're welcome to try a design
12: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?
12:34
jucar
left the channel
12:39
Bertl
or at least reflow with the OSHpark constraints
12:39
Bertl
which unfortunately rules out most BGA packages
12:44
Bertl
but I was considering the MachXO2 instead of the iCE40 for the "medium speed" I/O routing
12:44
Bertl
which might be a little more powerful
12:47
Bertl
haven't got the time to do a comparison with pros/cons yet though
12:50
fadro
the MachX02 100 pins TQFP could be a nice candidate! But routability needed to be checked even with this one.
12:51
Francky
why do you limit the pcb ordering to OSHpark ?
12:51
Francky
which seems to have hard contraints
12:52
Bertl
because it allows folks all over the world to get cheap PCBs and make some modifications to the design
12:52
Bertl
they are reasonably good quality and are not produced under dubious conditions
12: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
12:56
Bertl
of course, as PCB designer, it is always better to have smaller features, more layers, etc :)
12:58
intracube_afk
changed nick to: intracube
13:09
Francky
ok
13:22
se6astian|away
changed nick to: se6astian
13:27
alesage
joined the channel
13:31
masplund|away
changed nick to: masplund
13:31
se6astian
hi masplund
13:33
masplund
changed nick to: masplund|away
13:34
masplund|away
changed nick to: masplund
13:41
se6astian
hi masplund
13:43
Bertl
accept it, he doesn't want to hi you :)
14:48
niemand
joined the channel
15:27
niemand
left the channel
15:35
masplund
changed nick to: masplund|away
16:10
Francky
bye
16:10
Francky
left the channel
16:14
Bertl
cya
16:19
fadro
There something unclear to me on certains power distribution branchs:
16: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!
16:20
danieel
left the channel
16:21
Bertl
yeah, that is kind of a legacy
16:22
Bertl
it is very likely that we will drop the Xwest connection once the power connector setup is verified
16:23
Bertl
for now, you can see it as two supply pathes for those power connections
16:23
Bertl
in an earlier version, we had the power supply handled via the X-WEST/EAST connectors
16:24
Bertl
but that was suboptimal, which is why we introduced the PWR-NW/SE connectors
16:24
Bertl
the W_VW and E_VE conenctions are a leftover
16: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?
16:26
Bertl
actually it's six on each X connector
16:27
Bertl
and they will get freed up for other connections soon
16:47
aombk
is the beta "within schedule"?
16:47
danieel
joined the channel
16:49
Bertl
aombk: within what schedule? :)
16:50
slikdigit
joined the channel
16:50
slikdigit
left the channel
16:50
slikdigit
joined the channel
16:52
aombk
i see... so it will be delayed?:P
16:53
aombk
i remember eta april 2015
16:53
Bertl
yeah, so the schedule we advertized during crowd funding
16:54
Bertl
well, we might make it with the Early Beta
16:54
Bertl
(this will be part of the next update video)
16:55
Bertl
but I think you need to be very brave to get one of those, unless you're a developer
16:56
Bertl
so I would say, for the typical user, it is probably better to wait a month or two
16:56
aombk
i have no idea what early beta is. i will wait for the video
16:56
Bertl
yes, please do so, it will be out tomorrow or the day after I guess
17: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.
17:04
Bertl
the sensor board is designed to be rotation symmetrical
17:04
Bertl
i.e. the sensor board can be rotated 180° and plugged into the very same interface board
17:08
fadro
was it a request from folks? what the purpose of such option?
17: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
17:10
Bertl
together with the fact that the design was already very symmetrical
17:10
Bertl
we decided that we can easily make that a feature
17:12
niemand
joined the channel
17:26
niemand
left the channel
17:27
intracube
left the channel
17:28
g3gg0
joined the channel
17:51
Jin^eLD
changed nick to: Jin|away
18:14
intracube
joined the channel
18:34
cbohnens
changed nick to: cbohnens|away
18:36
niemand
joined the channel
18:44
intracube
left the channel
18:57
intracube
joined the channel
19:00
jucar
joined the channel
19:39
intracube
left the channel
19:57
intracube
joined the channel
20:01
Jin|away
changed nick to: Jin^eLD
20:20
intracube
left the channel
20:51
se6astian
time for bed
20:51
se6astian
good night
20:51
niemand
left the channel
21:07
se6astian
changed nick to: se6astian|away
21:08
jucar
left the channel
21:09
intracube
joined the channel
21:55
Jin^eLD
changed nick to: Jin|away
22:21
g3gg0
left the channel