Current Server Time: 18:27 (Central Europe)

#apertus IRC Channel Logs

2015/03/03

Timezone: UTC


00:02
fsteinel_
joined the channel
00:05
fsteinel
left the channel
00:21
cbohnens
changed nick to: cbohnens|away
00:58
fsteinel
joined the channel
01:01
fsteinel_
left the channel
03:07
intracube
left the channel
05:34
Bertl_zZ
changed nick to: Bertl
05:34
Bertl
morning folks!
07:06
se6astian|away
changed nick to: se6astian
07:09
Bertl
morning se6astian!
07:14
se6astian
changed nick to: se6astian|away
07:50
se6astian|away
changed nick to: se6astian
07:55
Francky
joined the channel
07:55
Francky
hi all
07:59
Andrej741
left the channel
07:59
Andrej741
joined the channel
08:00
MatthiasF
joined the channel
08:03
Francky
does someone know what type of Zedboard is used for the APERTUS Alpha project ?
08:03
Francky
I try to compile vhdl for ZedBoard Zynq Evaluation and Development Kit (xc7z020clg484-1) but it seems there is not enought port...
08:16
Bertl
ZedBoard Revision C.1
08:16
Francky
it is the "classic" zedboard ?
08:17
Bertl
yes, with the XC7Z020-1CLG484CES,
08:17
Francky
hummmm ok thanks
08:18
Bertl
np
08:22
Francky
the place says that IO placement is infeasible. Number of unplaced terminals (1) is greater than number of available sites (0).
08:22
Francky
:(
08:32
Bertl
what code are you building?
08:33
Francky
cmv_hdmi2
08:33
Bertl
do you use the build commands in top.vhd?
08:33
Francky
i'm trying with command line and the build is very longer, for the moment it seems to works
08:33
Francky
previously, i had create a Vivado project and try to build in it
08:33
Francky
don't know why it is different
08:33
Bertl
don't do that :)
08:34
cbohnens|away
changed nick to: cbohnens
08:34
Francky
are you anti GUI ? :)
08:34
Bertl
there is a reason why we use a script for building and not the fancy GUI
08:35
Bertl
you can still invoke the GUI once it is built if you like to
08:35
Francky
I think building is done because I have a vivado prompt now
08:37
Francky
ok i have a .bit file so it is good, the problem came from GUI :(
08:37
Bertl
perfect
08:38
Francky
thank you :)
08:38
Bertl
you can type 'start_gui' to get your gui
08:38
Bertl
you're welcome!
08:38
Francky
the gui cannot use the tcl script to build the project ?
08:39
Bertl
no idea, I haven't tried
08:39
Bertl
in any case, the commandline build is much more reliable/reproduceable
08:40
Francky
yes i agree
08:40
Francky
maybe the "best" option is to use gui to edit code and comand line to build ?!
08:41
Bertl
if you like to, I'm perfectly fine with using my favorite editor to write/edit code :)
08:41
Francky
but I come from microcontroller and PC coding so I used to use GUI a lot !
08:41
Bertl
the gui is usefull for looking at schematics and visual maps of the FPGA layout
08:41
Bertl
it also has some uses for simulation and debugging of course
08:43
Francky
i saw that you will use a microzed board for beta camera
08:43
Bertl
correct
08:43
Francky
so you think the zynq 7010 is ok ?
08:43
Bertl
we will use the 7020 based MicroZed
08:44
Bertl
but the 7010 works as well, just less I/Os
08:44
Francky
ok
08:45
Francky
because i have a 7010 microzed and i hope i will use it to learn
08:47
Bertl
yes, it will work
08:47
Francky
can i ask you another question ?
08:47
Bertl
sure, go ahead
08:48
Francky
i saw in top.xdc file, you create pblock and you put some instance into it, then you place the pblock into the Zynq
08:48
Francky
is it because you don't want to let the placer do what it want to do ?
08:49
Bertl
yes, because the placer usually sucks :)
08:49
Francky
and if you don't do that, it will not work ?
08:49
Bertl
remove the pblocks and try to build it :)
08:49
Francky
ok :)
08:51
Francky
so you need to know exactly how is the zynd built to know where to place differents blocks ?!
08:51
Bertl
well, it helps
09:03
Francky
so to put the project onto my microzed, i need 1) to change pin affectation 2) to change pblock placement
09:05
Bertl
yes, where the pin assignment will be more work
09:05
Bertl
i.e. the pblocks will mostly work as is
09:06
Francky
i saw that 7010 has few slice that 7020, so some pblock you have placed cannot be placed on a 7010
09:07
Bertl
yes, that's why I said mostly :)
09:07
Francky
ok :))
09:08
Francky
i imagine that you donnot place the pblock anywhere in the fpga?!
09:08
Bertl
no but the grouping is more important than the placement itself
09:09
Bertl
except for some timing critical paths
09:12
Francky
the placement is also linked with the pin assignment ?
09:12
Francky
the block placement*
09:12
Bertl
usually, yes
09:13
niemand
joined the channel
09:20
Bertl
off for now ... bbl
09:20
Bertl
changed nick to: Bertl_oO
09:21
se6astian
changed nick to: se6astian|away
09:37
se6astian|away
changed nick to: se6astian
09:53
[1]Francky
joined the channel
09:53
Francky
left the channel
09:53
[1]Francky
changed nick to: Francky
09:54
Francky
just changing irc client
09:54
Francky
left the channel
09:55
Francky
joined the channel
09:55
Francky
left the channel
09:56
Francky
joined the channel
09:56
niemand
left the channel
09:57
se6astian
back now
09:59
se6astian
time for lunch
09:59
niemand
joined the channel
10:31
niemand
left the channel
11:00
se6astian
changed nick to: se6astian|away
11:01
se6astian|away
changed nick to: se6astian
11:28
niemand
joined the channel
12:10
se6astian
changed nick to: se6astian|away
12:28
se6astian|away
changed nick to: se6astian
12:43
Francky
back from lunch !
12:52
Bertl_oO
wb Francky!
12:56
Francky
oh I was waiting for your come back
12:57
Francky
because you saw me that the placer sucks, but it had placed the code into the 7010
12:57
Francky
whereas some slices was not good in the xdc file
12:58
Francky
when i look on the device in the gui it seems that it had placed the code anywhere but what are the conscequences ?
12:59
Bertl_oO
did you check the timing?
13:00
Francky
not at all
13:01
Bertl_oO
if the timing is fine, i.e. no setup/hold problems, then you're fine
13:02
Francky
is the timing checked by the builder ?
13:03
Bertl_oO
the script does a timing check, yes
13:03
Bertl_oO
report_timing -no_header -path_type summary -max_paths 1000 -slack_lesser_than 0 -setup
13:03
Bertl_oO
report_timing -no_header -path_type summary -max_paths 1000 -slack_lesser_than 0 -hold
13:03
Bertl_oO
those are the problematic ones, if you do not get a hit there, you're fine
13:04
Bertl_oO
(this happens in the script right before the bitstream is generated)
13:08
Francky
if there is problem, is the bitstream generated ?
13:08
Bertl_oO
yes
13:08
Francky
ok so i need to check the build messages
13:08
Bertl_oO
that is always a good thing to do :)
13:08
Bertl_oO
but you can also run those two commands _after_ everything finished
13:09
Bertl_oO
(and you will get the proper info)
13:09
Francky
ok
13:09
Francky
i thought that building stopped if an error occured
13:09
Francky
so i was happy to get a .bit file :)
13:10
Bertl_oO
sometimes the hold/setup violations are minor, and can be ignored for testing
13:10
Bertl_oO
so it doesn't always make sense to stop
13:11
Francky
ok
13:11
Francky
i saw a lot of timing violation in the report file
13:12
Francky
i will try to relocate pblock and group them
13:13
Francky
do you have any support (i mean a book or a datasheet) to know where are the slice and to search how you can place them ?
13:13
Francky
i think that the gui is not very usefull to do that
13:15
Francky
OH maybe i can delete the "resize" pblock to get them into the gui... i will try
13:46
se6astian
changed nick to: se6astian|away
13:55
intracube
joined the channel
14:30
Francky
finally i draw the pblock into the gui, not very usefull but not so bad
14:31
se6astian|away
changed nick to: se6astian
14:43
fadro
joined the channel
14:43
fadro
left the channel
14:43
fadro
joined the channel
14:44
fadro
Hi Bertl
14:45
fadro
Got some questions around the developement status around the Beta camera...
14:47
fadro
It seems to me that some boards are now available like power board, sensor board and io board right?
15:03
hozer
left the channel
15:08
se6astian
hi fadro
15:08
se6astian
yes we did share them through oshpark
15:09
se6astian
but we did not receive them yet for testing
15:09
se6astian
so we cant confirm they work yet
15:10
fadro_
joined the channel
15:10
fadro_
hi Sebastian
15:12
fadro
left the channel
15:12
fadro_
OK, from an 3d overview, i saw that there was a 4 boards stakup for the camera, the sensor holder, the sensor processing board, the beta board and the uZed board, is that scheme up to date ?
15:14
se6astian
the power board was added to the stack
15:15
se6astian
other than that its correct
15:16
fadro_
So this mean that the complete stackup is with 5 boards?
15:16
hozer
joined the channel
15:17
se6astian
correct
15:18
fadro_
I'm not clear with the role of the processing board (not the uzed) and the beta board... Can't all these functionalites be merged together on a single board ?
15:31
Bertl_oO
changed nick to: Bertl
15:31
Bertl
back now ...
15:32
Bertl
fadro_: originally we planned to use a single board design (i.e. one board with sensor) in addition to the MicroZed
15:33
Bertl
you probably know that design from the crowdfunding campaing
15:33
Bertl
*campaign
15:33
Bertl
but during said campaign, we got a lot of useful input and ideas how to make the design more modular and extensible
15:34
Bertl
modularity and flexibility comes with a price, and in case of the Beta, it is mostly PCB real estate
15:35
Bertl
but we also gained a lot of new features which would not have been possible with the old design
15:40
fadro_
Hi Bertl, yes I clearly undertand the modularity concept your speaking about and also understand (and approve) your idea of a unified interface to the sensor. The thing i'm not clear with is why is needed a 3 boards stackup (the power pcb, the sensor processing and the beta pcb) to achieve such functionalities?
15:43
Bertl
well, the sensor PCB (the top of the stack) has a wide interface with "lower" frequencies (typically sensors have up to 64 LVDS lanes at up to 600MHz)
15:43
Bertl
(at least the sensors we use)
15:44
Bertl
on the MicroZed side, we do not even have 64 LVDS lanes, and even if we had, we would not want to spend it all on the sensor interface
15:44
Bertl
(we also want to do some output, etc :)
15:45
Bertl
so one solution is to use only 32 or even 16 LVDS lanes from the sensor, which would reduce the bandwidth and thus the framerate respectively
15:45
Bertl
the other solution is to add an intermediate board (in my nomenclature the "interface" board)
15:46
Bertl
which basically works as a data pre-processing unit, managing and combining data from the sensor and transferring it to the FPGA over a reasonable number of LVDS channels
15:53
fadro_
Yes, I agree with your points above and clearly understand (and know) the needs to low down the nber of LVDS lanes. But my remaining question still why is a 3 stack pcb is needed? From what i understand, an interface board + IO board should be sufficient.
15:57
Bertl
so, there is the sensor board (top of the stack)
15:57
Bertl
the interface board (the one doing the LVDS reduction)
15:58
Bertl
then we have the actual beta board, which contains almost everything we don't have on the MicroZed
15:58
Bertl
and for space reasons (we don't want to get the board too crowded) we recently added the "power board"
15:58
Bertl
which takes care of all the power management and power related sequencing as well as instrumentation
15:59
Bertl
this allows for a few new features we didn't even plan for in the beginning
16:00
Bertl
for example, having adjustable (programmable) and verified voltages for the various sensors, including monitoring and additional protection for the sensor
16:02
fadro_
OK clear, and what are the features embedded on the beta board?
16:03
Bertl
the beta board itself has the planned sensors, e.g. the 9/10DOF
16:03
Bertl
it also contains the PIC32 microcontroller
16:04
Bertl
and it does some GPIO management/distribution to the plug-in modules
16:04
Bertl
and of course the electrcal interface to the MicroZed as well as the "interface" board
16:07
Francky
what will be the aim of the PIC32 ?
16:07
fadro_
I imagine that the PIC32 manages the 10DOF sensor, gather the electrical information from the power pcb and provide an interface (trough a simple comm channel like uart, ..) to the fpga ?
16:11
Bertl
we plan to allow the PIC32 to controll everything GPIO and Power wise
16:11
Bertl
so the PIC32 can actually power down the sensor and FPGA
16:11
Bertl
allowing for an extremely low power shutdown/standby
16:12
Bertl
and yes, the PIC32 also has a good conenction to the FPGA and thus the ARM cores to exchange data, like the DOF or Power measurements
16:14
se6astian
just to get an idea, what would the power consumption of the pic32 be (when everything else is powered down)?
16:15
se6astian
plus how long would a power up recovery when the pic32 initiaties a wake up take roughly?
16:15
se6astian
adding this to the next team talk as topic :)
16:16
Bertl
the power consumption can be way below a single LED
16:19
Bertl
to put that in numbers:
16:21
Bertl
the maximum expected current for the PIC is 90mA, while a low speed processing is about 5mA and a sleep mode would go down to µA
16:23
fadro_
The picture becomes clearer now. however, I'm not completly catching the strategy to split beta functionalities + power functionalities on 2 separate PCB since the beta pcb surface seems to be quite large. Maybe you want to keep a 4 layers pcb maximum?
16:25
fadro_
And I imagine that the 3 HDMI connectors you are planning for the 1st release will be attached to the beta board?
16:25
Bertl
yes, this is one of the reasons here
16:26
Bertl
we want folks to be able to easily adapt and recreate the Beta
16:26
Bertl
that is the main reason we use OSHpark for the PCBs for example
16:26
Bertl
and we kind of artificially limit ourselves to parts which can be easily bought and assembled
16:27
Bertl
the HDMI connectors will be on a plugin module
16:27
Bertl
which connects via the two PCIe x1 connectors to the beta board
16:30
se6astian
so in summary when recording long term timelapse with the Beta the pic32 can at regular (programmed intervals) wake the camera up, snap a picture and put it back to sleep with extremely energy efficient operations for a longer timeframe, great topic for the team talk :)
16:31
Bertl
yes, for example
16:34
se6astian
perfect
16:37
Francky
do you need any help for the pic developpement (hard and soft) ?
16:37
Francky
or maybe you have a lot of experts in the apertus team :)
16:41
Bertl
there are many areas we can use help, including the PIC side
16:42
Bertl
so if you want to work on that, there is surely room
16:42
Francky
i would be pleased to help you and to give you some of my time
16:43
Francky
i have some skills about pic32
16:43
Francky
left the channel
16:43
Francky
joined the channel
16:44
Francky
left the channel
16:44
Francky
joined the channel
16:44
fadro_
And how the µzed FPGA feed the HDMI pl*ugin board? Through the PCIe lanes?
16:45
Francky
left the channel
16:45
intracube
left the channel
16:45
Francky
joined the channel
16:46
Francky
sorry i was disconnected
16:46
Francky
so i don't see if you answer me
16:46
Francky
Bertl i need to qui irc, i propose you to speak about the help i can give for APERTUS tomorrow
16:46
Francky
quit*
16:47
Bertl
there are real time IRC logs :)
16:47
niemand
left the channel
16:47
Francky
oh real time ! i didn't know ;)
16:47
Bertl
http://irc.apertus.org/index.php?day=03&month=03&year=2015
16:48
Francky
i saw, i thougt it wasn't real time !
16:48
Francky
it is great
16:48
Francky
see you tomorrow
16:48
Francky
bye
16:49
Francky
left the channel
16:49
Bertl
cya!
16:50
Bertl
fadro_: yes, the PCIe conenctors provide up to 12 LVDS pairs and a bunch of GPIO lanes to the plug-in board
16:50
Bertl
(or actually boards, as you can have two separate boards or one board using both slots)
16:56
fadro_
But in the case of a plugin board with 3 HDMI, you need to address 3 HDMI drivers (and around 20 active signals per driver). Is there sufficient IO to drive 3 HDMI drivers?
16:59
Bertl
yes, we need 3x4 = 12 high speed lanes for 3xHDMI
17:00
Bertl
and only a few GPIO signals for I2C, CEC and HP/HEAC
17:01
fadro_
Oh, so you drive the HDMI directly through FPGA pins. You are not using an external driver such as ADV7511 or else..
17:02
Bertl
correct
17:04
danieel
left the channel
17:06
fadro_
And concerning the sensor throughput are all the LVDS lines connected to the IF board? And is the bandwidth between IF board and µzed sufficient to support the maximum CMV12k throughput? (which is around 300 fps if i remember well)
17:07
intracube
joined the channel
17:13
fadro_
And thanks to all the interfaces the LVDS lanes will cross we really need to think about SI (also because the layout is 4 layers only, so microstrip lines only)
17:13
fadro_
µzed----[connector]----power IF board----[connector]----IF board----[connector]----plugin board----[hdmi connector] --> HDMI cable
17:15
Bertl
all the sensor lanes go to the interface board
17:15
Bertl
and the bandwidth between interface and FPGA is sufficient for the 300FPS @ 10bit
17:15
fadro_
perfect!
17:19
fadro_
Is there a place where all schematics and layout (power board, IF board, beta board) are reposited?
17:20
fadro_
oups, error previously:
17:21
fadro_
µzed----[connector]----power IF board----[connector]----Beta board----[connector]----plugin board----[hdmi connector] --> HDMI cable
17:21
danieel
joined the channel
17:22
cbohnens
I am looking through the sensor datasheet right now, I guess they recently updated the specification to support 600mbps lvds? Because on the website they advertise sometimes 600, sometimes 300....
17:34
Bertl
yes, in the v2 version of the sensor
17:34
Bertl
it was planned in v1, but they didn't get it working
17:35
cbohnens
yeah, found the relevant section in the change record
17:35
Bertl
open channel is fine, but expect many additions questions and ideas :)
17:35
Bertl
(note that this channel is open as well, just not logged/advertized)
17:37
Bertl
s/this/the other/
17:41
fadro_
Bertl, is there an accessible place where lastest beta design sources are stored?
17:41
Bertl
you can get the PCB designs here: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/
17:42
Bertl
and the mechanical designs are on github, se6astian has the details
17:43
Bertl
let me know if a pdf is not up-to-date, it sometimes happens as we haven't automated this yet (but it is on my todo)
17:43
fadro_
ok , i have already been there but it was not clear how boards stack together. Now it is...
17:44
fadro_
and just to finalize for today, how do you feel with signal integrity because of multi-board stacking and 4 layers PCB?
17:46
Bertl
well, we try to keep it clean and well grounded, so it is all more like coplanar waveguide for the high speed connections and well shielded connectors
17:46
Bertl
but of course, SI is something you always have to worry about, luckily we are not in the really high speed arena yet
17:47
Bertl
(i.e. everything is below 2GHz)
17:49
Bertl
so I'm quite optimistic there :)
17:52
Bertl
but input and detailed analysis is always welcome!
17:55
fadro_
yes, i will take a look on the source files and give you some feedback. I have done several high speed designs, so i'm quite used to it....but never with a 4 layers pcb...
17:55
fadro_
when do you plan to assemble your 1st complete prototype?
17:55
Bertl
yeah, I know, it's a challenge :)
17:56
fadro_
That's what is exciting...challenges...
17:56
Bertl
we are expecting the next batch of PCBs in a week or so, and we should be able to build a functional prototype with that
17:56
Bertl
it won't have the final boards, but it should work
17:57
Bertl
(and allow for some bandwidth testing :)
17:58
fadro_
perfect....In all case you have done a great job. I know that spending time on open projects when you already have a full time job is complicated.... But you just do it....
17:58
fadro_
you rock men !!!
17:58
fadro_
see U later
17:58
fadro_
+++
17:58
Bertl
thanks! cya!
17:59
fadro_
left the channel
18:03
niemand
joined the channel
18:10
aombk2
joined the channel
18:13
cbohnens
I'm off for the day, see you tomorrow with hopefully new ideas and more likely, additional questions :)
18:13
cbohnens
changed nick to: cbohnens|away
18:13
aombk
left the channel
19:02
baldand_
left the channel
19:17
lab-bot
BAndiT1983 created T300: Add basic plug-in architecture. http://lab.apertus.org/T300
19:18
baldand
joined the channel
19:18
lab-bot
BAndiT1983 created T301: Add layout switching. http://lab.apertus.org/T301
19:22
lab-bot
BAndiT1983 created T302: Implement interface for GLSL plug-ins. http://lab.apertus.org/T302
19:23
lab-bot
BAndiT1983 created T303: Implement interface for OpenCL plug-ins. http://lab.apertus.org/T303
19:23
lab-bot
BAndiT1983 created T304: Implement "Vulkan" backend. http://lab.apertus.org/T304
19:24
lab-bot
BAndiT1983 created T305: Add support for MOX file format. http://lab.apertus.org/T305
20:12
lab-bot
sebastian committed rBH4d1388c34c9e: added latest datasheets (authored by sebastian).
20:48
Bertl
off for a nap ... bbl
20:48
Bertl
changed nick to: Bertl_zZ
21:01
se6astian
me too
21:01
se6astian
gnight
21:01
se6astian
changed nick to: se6astian|away
21:05
niemand
left the channel
21:26
dmj726
joined the channel
21:57
niemand
joined the channel
22:17
niemand
left the channel