Current Server Time: 19:41 (Central Europe)

#apertus IRC Channel Logs

2015/03/03

Timezone: UTC


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