Current Server Time: 07:34 (Central Europe)

#apertus IRC Channel Logs

2015/03/05

Timezone: UTC


23:37
MatthiasF
left the channel
00:26
fsteinel
joined the channel
00:56
Jin^eLD
changed nick to: Jin|away
00:57
fsteinel_
joined the channel
01:00
fsteinel
left the channel
01:00
fsteinel_
changed nick to: fsteinel
01:14
ItsMeLenny
joined the channel
02:15
intracube
changed nick to: intracube_afk
02:30
jucar
left the channel
04:45
ItsMeLenny
left the channel
04:46
ItsMeLenny
joined the channel
05:31
Bertl_zZ
changed nick to: Bertl
05:31
Bertl
morning folks!
05:37
ItsMeLenny
morning Bertl!
07:06
Francky
joined the channel
07:15
Francky
hey Bertl
07:15
Francky
you saw me yesterday that signal are 1.
07:15
Francky
1.8V on connectors on the pic board
07:15
Francky
so a converter is needed
07:16
Francky
do you have any converter references that you have already used ?
07:50
Bertl
yes, for the LVDS (i.e. signals coming from the Zynq) the other signals are 3.3V
07:52
Bertl
for I2C we have been using the GTL2002 and similar, for unidirectional signals the 74LVC125 or 74AVC4T245 seems to do a good job
07:53
Bertl
or 74AVC4T774 as alternative
08:00
Francky
and have you already select which signal will be the jtag signals or it doesn't matter because you will choose in the vhdl code ?
08:01
Francky
i mean jtag of pic
08:01
Francky
on the hdr ne connector
08:01
MatthiasF
joined the channel
08:03
Francky
lvds signals are JX* signals on hdr connectors right ?
08:03
Bertl
assuming that the PIC will not be reprogrammed that often, we could use the GPIO pins, i.e. 4/5 of the HDR-SE pins connecting to U7
08:04
Bertl
or alternatively, 4/5 of the medium speed pins from HDR-NE going to U6
08:04
Bertl
yes, the "right side" of HDR-SE and HDR-NE is from the Zynq
08:08
Francky
in my mind jtag needs 4 signals ?!
08:08
Bertl
yeah, we might need the reset as well
08:08
Francky
oh 4/5 in your sentence mean "4/5 pins" and not "the pins 4 and 5"
08:09
Bertl
yep
08:09
Francky
ok
08:09
cbohnens|away
changed nick to: cbohnens
08:13
Francky
for I2C/SPI signals, they are 1.8V level too ?
08:13
Bertl
we'll probably go for 3.3V there
08:14
Francky
so no need of GTL2002
08:14
Bertl
unless you want to connect an I2C port to the Zynq, no
08:15
Bertl
the main difference is bidirectional vs unidirectional
08:16
Francky
in fact with your 3 point connector for communication bus, we cannot use a spi because spi use 1 CS per slave, so it will be I2C
08:17
Francky
ok so we'll use gtl2002 for zynq lvds signal to be able to use them in bidirectionnal right ?
08:17
Bertl
it can still be SPI, if we either have only one slave or designate 1-3 of the SPI-W for CS
08:31
Francky
to implement gtl2002, we need the 1.8V power supply of the zynq, so do we use on of MP-SE pin to get this voltage ?
08:35
Bertl
maybe let's use the MP-NE power for the 1.8V rail
08:36
Francky
but on the pic32 there is not core voltage and io voltage, there is just power voltage and analog voltage, which are set to the same voltage on microchip reference design, so maybe we don't need these two power rails on MP SE ?
08:37
Bertl
it might be a good idea to keep digital and analog separate for noise reasons
08:38
Francky
so this is the power board which will make filtering right ?
08:38
Bertl
correct
08:38
Francky
and for 1.8V, we remove a GND signal on the MP NE connector ?
08:38
Bertl
just take the middle pin
08:39
Bertl
it is connected to the JX1-7
08:39
Francky
ok
08:39
Bertl
which is currently not connected on the power board, but easy to patch to 1.8V
08:45
Jin|away
changed nick to: Jin^eLD
08:45
fadro
joined the channel
08:54
se6astian|away
changed nick to: se6astian
08:56
fadro
Hi all
08:58
fadro
Bertl, i spend some time yesterday on the HW source files. I imagine that things will evoluate in the future but i would like to share some points about the modularity
09:00
fadro
Concerning the sensor board, it should be a good thing if all the voltage rails related to the sensor would be generated on the sensor board itself, meaning that only a general supply voltage (5v for example) is coming into the sensor board.
09:02
fadro
This allow to have no hardware change (expect the sensor board of course) when pluging different sensors (and reprograming the IF fpga of course).
09:04
se6astian
changed nick to: se6astian|away
09:15
Bertl
yes, and no
09:15
Bertl
there are two problems with this approach
09:16
Bertl
first, all programmable voltage control as well as the instrumentation to measure power consumption would have to be placed on the sensor board as well
09:16
se6astian|away
changed nick to: se6astian
09:16
Bertl
and secondly, we would get all the heat produced by regulation, instrumentation, etc on the sensor board
09:17
Bertl
those two points led to the decision to move the actual power supply out of the sensor board and just leave the verification to the board
09:19
se6astian
good day
09:20
Bertl
for what? hopefully not to die :)
09:24
fadro
ok, but instrumentation do not produce heat and the most heating part for the suply is the 1.8V rail, but it can be drawn with a clean dc/dc since it supply digital logic. Most heat generated from this board will be from the sensor itself. And in all case, i that you already have a heat dissipation strategy for this part.
09:25
se6astian
for a lot of things... :)
09:27
Bertl
fadro: note that we don't require a hardware change (except for the sensor board) in the current setup either
09:28
Bertl
(because the power board can accomodate the different voltages)
09:30
fadro
for now the cmv1200 requires 3.3V x3, 3V and 1.8V., but baybe tomorrow you want to add one with 1.5V, 2.5v and 3.3V with different constaints on the noise level and the ripple. You have enough flexibily and outputs on the power board to handle such cases
09:32
fadro
I saw the power board, but i a little bit lost because there are many power rails, but i think that a goot part of them are reserved for future use.right?
09:32
Bertl
for the voltage ranges definitely, noise we try to keep as low as possible anyway, but special additional filtering can still happen on the sensor board
09:32
Bertl
the current power board is a test board to get something working quickly
09:32
Bertl
the final power board will feature a central power management system which can be fully programmed
09:35
fadro
OK, on the power board you put only LDO type. This provide of course low noise and also good noise rejection (plus the ferrite you add at the end of each ldo rail), but produce a lot of heat and have a bad electrical efficiency. Do you plan to use dc/dc on the final power board?
09:36
Bertl
yes
09:37
Bertl
we are currently considering two designs (which will be tested soon) one which uses a simple capacitive solution with a single mosfet and a second which utilizes an inductor together with two (push/pull) type mosfets
09:38
Bertl
depending on the results we might go for one or the other or a mix of both
09:40
fadro
ok, good. if you need hands on such part i can help.. I quite used to play with dc/dc in video devices (and of course knows how noise impact sensors and video...)
09:40
fadro
And you also plan to let different voltage rails for the plugins boards, or only a generic rails, and then each module board will generate it's own voltage rails
09:42
Bertl
that hasn't been decided yet, we know we want the eight voltages (two for the interface and six for the sensor board) to be under programmatic control
09:42
Bertl
but it might make sense to have the two/four voltages for plugin modules flexible as well
09:46
fadro
well, from my point of view, it would be better to simply supply the plugin connectors (the x2 PCIe in fact) with a generic supply rail (5V). Since plugin boards are open to the community, it's complicated to imagine what people would need, how much power will be desired
09:47
fadro
by supplying several rails, you complicate the initial power board design and you are not sure to handle the plugin needs...
09:47
Bertl
we could also do both, i.e. supply some programmatically controlled power to each module and a general 5V rail, which then allows you to simplify designs even further
09:50
fadro
yes compromise can be done, but you add strong contraints on the power board itself by adding several rails (so cost, heat, pcb space, ...), and since you add more and more programmable power rails, you also add many risks to make an error when programming one of the many rails which can lead to a risk of burning some items...
09:51
Bertl
the current design prevents this by direct feedback, of course, it's not 100% but close
09:52
Bertl
but I agree, for now it is probably better to keep it simple
09:55
fadro
Yes. since this camera has the vocation to be hacked by anyone (included hobbists), it would be better to keep it simple in the measure where it doesn't kill the overall performance.
09:55
fadro
I think that hackers will know better that can be anticipated what they should need...
09:57
surami
joined the channel
09:57
surami
hi
09:57
Bertl
wb surami!
09:59
surami
i would like to know things about the low light capabilities of the Beta, especially shooting timelapses
09:59
surami
i mean milkyway shots etc.
10:00
surami
is the sensor capable for this things too?
10:00
fadro
and concerning the interface board (IF board), for now it's a "simple passtrough board". But i imagine that it will rapidly grow with some intelligence and with an hi fpga io pin count. But how do you plan to reduce the number of LVDS incoming from the sensor? The original sensor LVDS are 300Mbps with 64 lanes, so i suppose that you will provide an unified interface with 32 LVDS lanes with 600Mbps??
10:01
Bertl
actually it is already 600MHz on the v2 of the sensor, but yes, we plan to 'pack' the datastream on the interface board
10:01
se6astian
surami: you can check out some benchmark results of the sensor by the Magic lantern guys: http://www.magiclantern.fm/forum/index.php?topic=11787.msg129672#msg129672
10:01
Bertl
fadro: or alternatively pre process it in the interface FPGA
10:02
Bertl
surami: for astronomy purposes you probably want excellent cooling and you definitely need the equippment to track your object
10:02
Bertl
but the sensor itself can do very long exposures
10:03
ItsMeLenny
left the channel
10:05
fadro
ok, 600M on the v2...i don't get it! but i don't get the way you want to pack datastream to reduce the BW.... and even if you do pre-processing on the 1st stage fpga, the bw limitation has the same issues...
10:06
Bertl
first, we can change the interface in various ways, higher datarate, memory like single ended interface, etc
10:06
Bertl
secondly, we can avoid transferring idle data
10:07
Bertl
and finally, if we implement soft exposure for example, it could be completely done in the interface board without need to transfer all the data to the zynq
10:07
Bertl
so yeah, it's not likely that we will do full bandwidth right now, but there are certainly options for the future
10:11
fadro
of course the goal is not to have the fuul BW at 1st powerup, but what is not easy is that all cases should be think about it early in the process of architecture design, otherwise, it will require huge efforts to modify the existing, and also drawkbacks of HW imcompatibilities and costs for redesign.
10:11
se6astian
changed nick to: se6astian|away
10:13
Bertl
btw, any comments on the existing design, routing, choice of parts, etc?
10:13
fadro
And concerning your 1st point above, on your new IF fpga you will have the bank you want (speaking about HP banks, cause you speak about higher data rate), but on the µZ side, you only have HR banks and i see the bottleneck on this side...
10:15
fadro
Comments concerning the existing design are more related to the modularity architecture the the electrical design itself
10:16
fadro
routing, some question, yes : how do you manage the 100ohm differential lines impedances?? OSHpark gives you the parameters of the stackup to allow such controlled impedance?
10:17
Bertl
we know the 4 layer stackup and the dielectric constant of the substrate (FR408)
10:18
fadro
concerning choice of parts, not especially... There are many good but differents ways to achieve a functionnality, and i think that's a little bit early in the design process to discuss such.
10:18
Bertl
we are not yet in the really critical range (> 2GHz) that we need board controlled impedance, but we did some tests and it looks good
10:19
fadro
ok, and you know the type of copper foils they use (ED i suppose)?? and also theFR4 fiber weave spacement??(important for the differential lines)?
10:19
Bertl
the existing 100R differential/50R single setup is the result of EM simulation
10:21
Bertl
at the prepreg width (6.7mil) the fiber weave is not relly relevant for data rates up to 1.5GHz (which is our current limit)
10:21
Bertl
s/width/thickness/
10:21
Bertl
(at least as far as I know :)
10:22
fadro
OK. I agree with you that since we are under the Ghz, we can relax... but carefull design must stay...they are many connectors to cross, and signal corruption can raise fast...
10:22
Bertl
yes, agreed
10:22
fadro
OK, you use a field solver to got the tracks width and spacement??
10:23
Bertl
yes
10:23
fadro
Polar, Hyperlinx, or maybe an online one?
10:25
fadro
In any cases, on the boards you design, the rules of thumbs (crosstalk sepration, reference plane, spacement between differential lines, well grounded connectors IF) are respected so this is a good point.
10:27
Bertl
we've mostly used ATLC but also investigated openEMS and MMTL
10:28
Bertl
there are online field solvers?
10:29
fadro
The only thing i'm not sure (because i've never experienced it before ) is more about the 4 layers stackup. Not because of the 4 layers itself (since 2 layers are sufficient to define a Ghz microstrip line), but because of the materials quality used by 4 layers pcb manufacturers...I would suspect poor ED copper foils (whch can lead to big insertion losses depending on the quality even for signal under Ghz (because of skin effect)) , an
10:30
fadro
poor FR4 quality leads to big variation of the DK (or Er) and can add enough sken in diff pair to cause many errors on the receptor side....
10:31
Bertl
http://support.oshpark.com/helpdesk/attachments/4001917116
10:31
fadro
by poor FR4 quality, i'm speaking about the fiber weave with large spacement which lead to high variation in the Er
10:31
surami
@se6astian: thanks for the link, @Bertl: ok, i understand
10:31
Andrej741
left the channel
10:32
fadro
ooh, very good, give me a few seconds....
10:38
fadro
Well, that's a good surprise...They use a good FR4 product....In general, when I see ISOLA products, i'm quite confident.... So very good point!
10:39
Bertl
excellent then!
10:40
Bertl
so far, we have been very satisfied with the PCBs in almost all regards
10:41
fadro
I saw a strange thing in the axiom_beta_interface_dummy_v09.sch file. There are double connection (like short circuit) on the Xnorth & Xsouth connectors, but the PCB side is OK. It seems that the sch and pcb file are not related but pcb connection looks good.
10:42
Bertl
page and coordinates?
10:43
Bertl
or are you referring to the "broken" ellipses around the pairs?
10:44
fadro
well, page 2, all the connections on the Xnorth and X south...And i'm speaking about the electrical connection....
10:44
fadro
But it looks like a drop error that has been saved... I get it from the server of course..
10:45
Bertl
hmm, okay, let me update the files, just to make sure
10:46
jucar
joined the channel
10:47
Bertl
okay, please redownload and check if you see the same effect
10:49
fadro
OK, this time the *.sch file is correct!
10:49
fadro
just to be back on a previous [12:06] point...
10:49
fadro
And concerning your 1st point above, on your new IF fpga you will have the bank you want (speaking about HP banks, cause you speak about higher data rate), but on the µZ side, you only have HR banks and i see the bottleneck on this side...
10:50
Bertl
well, with the de/serializers in the zynq, the HR banks can still do 1.2-1.6GHz
10:51
Bertl
we have 36 pairs from the interface board to the zynq
10:51
Bertl
and we have a total of 80 pairs to the sensor board
10:53
Bertl
so it should be enough to handle the sensors we have for now
10:58
fadro
OK. Initially, you plan plan to use the µZ. Is this a definitive choice, or the use of a board such as PicoZ can be imagined??
10:59
Bertl
we already plan to support the PicoZed as well
10:59
Bertl
(and the Parallella, for those interested in image processing)
11:00
niemand
joined the channel
11:00
intracube_afk
changed nick to: intracube
11:00
fadro
goood...I like this idea...from my point of view Picozed offers more scalability, more LVDS lanes, and we can also open an incredible field with the 4 MGT...(7015/7030 version...)
11:01
Bertl
yes, the only problem is the minimalistic nature of the PicoZed
11:01
Bertl
i.e. no console, no ethernet, no USB, etc
11:01
Bertl
but I agree, the MGTs are very interesting
11:02
fadro
Ah, that right, you have to do your own connector IF, BUT, we have your powerfull plugin architecture, so I see no problems :))
11:03
se6astian|away
changed nick to: se6astian
11:03
Bertl
yeah, the most likely solution for the PicoZed will be to add another PCB which handles the MGTs and the missing interfaces
11:05
fadro
Yes, but once again, extreme care should be taken with connectors interface especially if we play with GTP/GTX signals....
11:06
fadro
And to handle this, even if it is future (as short as possible...) the modularity architecture has to be well choosen...
11:06
Bertl
that's the reason why this PCB would address the MGTs directly
11:06
fadro
to let highspeed signal in the best integrity as possible...
11:09
fadro
And since µZ and PicoZ connectors are definitively not compatible, how do you plan to handle the future devlopement? 1 power board version for the µZ and 1 PW bard version for the PicoZ??
11:11
Bertl
interestingly they are compatible
11:11
Bertl
i.e. the two connectors shared between MicroZed and PicoZed are identical
11:12
Bertl
all new connections are done through the third connector
11:17
fadro
Oh, I didn't care about this, so it's surprising and very interesting yet...Compatibility have been well stutied...
11:17
fadro
But in any cases there should be 2 versions of the PW pcb since if you use the PicoZed, you want to take advantate of the 3rd connector...
11:18
fadro
*advantage
11:19
Bertl
that's why I said another PCB :)
11:23
jucar
left the channel
11:23
fadro
So, what are your plan for versionning of the BETA camera?? All the boards would exists, and the final user will choose in these options to build its own camera depending on its need and budget??
11:24
Bertl
yes, that's the most likely scenario
11:24
Bertl
where of course certain boards would be a bad choice, because they have been superceeded by newer ones
11:30
jucar
joined the channel
11:35
fadro
What do you mean by superceeded?
11:40
Bertl
for example the v0.12 of the cmv12k sensor board would be a bad choice, given that the v0.13 has same functionality and a better design
11:48
fadro
OK, obviously. But in any cases I imagine that end users will wait for your green fire to begin buying some HW parts. Only hackers will find interest in the current HW version.
11:48
Bertl
yes, we hope and think so
11:50
fadro
Do you have a kind of dead line for a 1st BETA release? I mean did you give some delivery date when doing crowfunding capaign?
11:50
Bertl
we had some estimates but nothing fixed at the campaign
11:50
fadro
And what was the estimation ?
11:51
Bertl
we are good in time but due to the changes we incorporated, we will not make our (originally) planned goal
11:52
fadro
OK, so what are the changes and what is the reported estimated date??
11:53
Bertl
the first batch was planned to ship in April, but back then, the AXIOM Beta consisted of a single board including the sensor
11:54
Bertl
now we have really modular sensor boards, the interface board to allow for full bandwidth and the PCIe plugin modules
11:54
Bertl
(before those were simple shields on the front of the camera)
11:55
fadro
OK, so you add the modular architecture from your initials plan... And of course, yes, it requires more design time and more validation....for sure...
11:56
Bertl
we will have early betas next month, so bold folks can probably still get a beta in april :)
11:56
fadro
:)
11:56
Bertl
but I expect the majority will want to wait (even if they backed for the 1st batch) till we have a more mature design :)
11:57
fadro
Yes, i agree
11:57
se6astian
changed nick to: se6astian|away
11:59
fadro
But concerning the HW development, you are the only one involved in the design process?? I mean HW, FPGA, Arch linux?? Cause I see only you name on sch, pcb, hdl file...??
11:59
niemand
left the channel
12:04
Bertl
I'm doing most of the work on the electronics and software at the moment, but that will hopefully change in the near future
12:05
Bertl
for example Francky is currently working on the PIC32 "shield"
12:17
fadro
Is there any existing documents for describing the overall modular architecture? What are the inputs, the options, and also things like dataflows, supply trees, ..
12:18
Bertl
not yet, it is mostly in our minds, but there will be documentation soon
12:23
fadro
I'm sure that's it's clear in your mind, but it's always good to write some blackboxes and arrows to have a overall design step back and checks if everything fits together...
12:26
fadro
Maybe i can do this exercice of writting such diagrams. I think that it will also ease our communication (1 graph is often better than hundreds irc lines!!)
12:27
Francky
it would had help me yesterday :)
12:27
Francky
have*
12:29
fadro
Are you new comer to this project?
12:31
Francky
yes
12:32
Francky
and i had to extract lot of information from the head of Bertl :D
12:33
Francky
in fact i'm interested in zynq device, and i ask lots of questions to Bertl, and in our discussion he tells me that the project needs a PIC board, so i propose my help
12:33
Francky
and as you see my english is not very good
12:38
Bertl
fadro: any help is truly appreciated
12:39
Bertl
Francky: don't worry, it is more than sufficient to communicate :)
12:40
se6astian|away
changed nick to: se6astian
12:40
se6astian
changed nick to: se6astian|away
12:41
Francky
i have difficulty with conjugation
12:42
Francky
because i'm french and we don't use conjugation very weel in french language
12:42
Francky
but i agree i undestand what you tell, and we undestand almost i said :)
12:48
fadro
Francky : You are French? I love this country!!! Vive la France ... Maybe cause that's my native one!!
12:49
fadro
Bertl : I want to invest myself in Axiom project... I've taken so many from open source, that I decide now to give back...
12:49
Francky
yep. Where are you now ?
12:50
fadro
But since i'm more HW than SW, i choose an open source pjct which fits my job...
12:50
fadro
Euuhhh, in France...
12:51
Francky
i undestood that you have leave France, don't know why...
12:51
Francky
for me i'm more SW than HW :)
12:52
Francky
but i like both
12:52
fadro
by SW you mean firmware & RTOS or heavier OS like linux, ... I also like both...
12:54
fadro
Bertl : For doing such king of graph, documention,... do you have prefered application and prefered way to share online doc???
12:56
Bertl
well, I did this one: https://images.indiegogo.com/file_attachments/846669/files/20140910012757-BETA_interface.jpg with tikz
12:56
Francky
fadro> my main skills are in low level firmware (BSP), but i work on high level languages too, and on embedded linux (applications dev)
12:57
Bertl
something TeX based is probably easiest to adjust to changes and also can be easily incorporated into other documents
12:57
niemand
joined the channel
13:00
fadro
yes, agree, and how do you usually share your drafts doc for team discussion??
13:00
Bertl
many documents are either just uploaded or shared via google docs
13:01
Bertl
but we have the wiki as well for documentation
13:01
fadro
ok, good let's take goole doc as document repository... You have an open account on google doc??
13:02
Bertl
please check with se6astian when he comes back, I'm not really into google doc
13:02
fadro
OK, i will...
13:02
Bertl
(mostly because they prevent "sane" copy/paste on Linux :)
13:03
fadro
:) i see...
13:08
danieel
left the channel
13:13
danieel
joined the channel
13:18
niemand
left the channel
13:33
Francky
Bertl> do you have any time to take a look to my schematics ?
13:36
niemand
joined the channel
13:40
Bertl
sure, url?
13:43
Francky
https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.pdf
13:44
Francky
i've put spi, jtag, isp, then all IO from zynq and beta board fpga, then led on free pins
13:46
Bertl
the schematic around the pic looks a little crowded :)
13:47
Bertl
i.e. it is hard to read
13:47
Francky
yes but all pins are connectes, unless usb pins that are dedicated for usb
13:47
Bertl
and it seems to have my copyright :)
13:48
Francky
yes i have copied your schematics style
13:48
Francky
to be homogeneous
13:49
Bertl
so what is the idea how the zynq and the pic communicate?
13:49
Francky
oh a question about Eagle : how do you do to make labels with small text size and decoration aroud ?
13:49
Bertl
it is a style option for the label, you can select it in the tool bar or change it later
13:50
Bertl
the text size can be changed via the size attribute
13:53
Francky
ok i will search
13:54
Francky
for communication, there is a mappable UART RX TX on RF0 and RF1, connected to JX2
13:54
Bertl
PMP would be an option, but that requires at least PMD0-PMD7
13:54
Bertl
plus the involved control signals and some address lines
13:55
Francky
it faster, but more expensive about gpio
13:55
Francky
is*
13:55
Bertl
how much space do you have left on the board?
13:55
Francky
do we need high speed communication ?
13:55
Bertl
it might make sense for the IMU data later
13:56
Bertl
so if possible, we should keep that option open
13:56
Francky
https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.png
13:57
Bertl
so it's already rather crowded
13:57
Francky
it depends on what you want to add :)
13:59
Bertl
well, we could add some FPGA/CPLD to make better use of the zynq connection(s)
13:59
Bertl
but I think that is not an option here, too little space left
13:59
Francky
to use the lvds lines ?
13:59
Bertl
yeah
14:01
Francky
so do you have another good idea for the bus between zynq and pic ?
14:02
Bertl
you're the pic expert :)
14:02
Francky
pic datasheet says that baud rate on UART could be to 25Mbps
14:03
Francky
it depends on the real need, and you have more information in mind that me
14:03
Francky
than*
14:03
Francky
about global system
14:04
Bertl
but for a synchronized uart interface we only need what, 3? lines to the zynq, yes?
14:04
cbohnens
changed nick to: cbohnens|away
14:05
Bertl
i.e. what do we have the other 7 lines for?
14:05
Francky
i always use 2 lines in UART communication, because i always make synchronised interface (ie : 1 master asks 1 slave)
14:08
Bertl
hmm, there is no crystal and no clock input for the PIC32
14:08
Francky
i don't know what you want to do with :) why did you provise so much pins between zynq and pic ?
14:08
Bertl
so you completely rely on the internal oscillator
14:08
Francky
it was my thought
14:09
Bertl
to answer the question: I didn't :) i.e. I just routed all available zynq I/Os to the header :)
14:09
Francky
using the internal oscillator to preserve gpio outputs
14:09
Bertl
this will probably limit the PIC32 to a lower frequency and result in more problems with synchronization
14:10
Bertl
also, what about the RTCC, it requires the secondary oscillator and a clock crystal IIRC
14:11
Bertl
and the RTCC as well as keeping time in low power mode would be something really useful
14:11
Bertl
(just commenting here)
14:13
Francky
it seems that internally oscillator is sufficient to achienve 200MHz
14:14
Francky
i have not take into consideration the RTCC
14:14
Francky
do you think a electrical cell is needed to keep the time if there is no more power ?
14:15
Francky
like there is in PC
14:18
Francky
but we can put an external one if you want to have a very precise one
14:19
Francky
for rtc it seems that there is a 32k internal clock
14:21
Bertl
okay, so that would work without any oscillator/crystal? and if so, with what precision?
14:22
Bertl
but let's take a step back and revisit how we can make good/optimal use of the zynq connection and other interface resources first
14:22
Francky
i think : if you need (a lot of) communication between pic and zynq (rtc, 10DOF, accelerometer, ...), maybe we can put several UART lines between zynq and botch to specialized each line in on (or two, or more) device ?
14:23
Bertl
from your designs so far, it doesn't seem to make much sense to connect the zynq directly to the PIC, no?
14:23
Bertl
(different voltages, different speed, no advantage there)
14:24
Francky
i don't undestand what you mean
14:24
surami
left the channel
14:24
Bertl
I mean that it wouldn't make much sense to connect the zynq directly to the PIC
14:24
Bertl
looking at the beta test board, we have a lot of space on the right side
14:24
niemand
left the channel
14:25
Bertl
which is potential space for the PIC if we decide to put it directly on the beta board
14:25
Francky
what do you mean by "directly" ?
14:25
Bertl
if, OTOH, we decide to make the PIC a shield, i.e. keep the headers
14:26
Bertl
then it would make a lot more sense to put e.g. an FPGA in the place below the shield and have that communicate with the PIC instead
14:26
Francky
ok i undestand
14:27
Bertl
the PIC still needs a direct contact to the power management
14:27
Francky
so your idead is to put a fpga "under" the pic board, to convert lvds from zynq to, for example, PMP
14:27
Bertl
i.e. a dedicated I2C connection
14:27
Bertl
yes, that would be the idea
14:27
Francky
you want that the pic control the power board ?
14:27
Francky
throught i2c ?
14:27
Bertl
we could get rid of the PSI-E which seems to be in the way
14:27
Bertl
*SPI-E
14:28
Bertl
and instead use all the HDR-SE/NE connections for PIC/zynq I/O
14:29
Bertl
that would probably allow to use the larger PIC with more GPIOs
14:29
Bertl
and still have plenty of I/Os left for LCD/buttons/etc
14:30
Bertl
does that make sense?
14:30
Francky
why do you want to get rid of the spi_e bus ?
14:30
Bertl
not the bus, the header :)
14:30
Francky
i undestood that you want to connect 10DOF on it ?
14:31
Francky
ok so you want to put a fpga between pic and sensor too ?
14:31
Bertl
we can terminate the bus on the same FPGA/CPLD which connects to the pic
14:31
Bertl
or we can just route the sensor bus to the NE/SE header
14:32
Francky
so you propose to have one big and fast bus between pic and fpga (example : pmp), and keep all other pic IO for lcd and buttons ?
14:33
Bertl
yes, that would make sense to me, unless you have a better idea?
14:34
Francky
to be honest the growing complexity make me doubt
14:35
Francky
but i am not confortable with fpga so i probably don't reflect like you
14:35
Francky
:)
14:36
Bertl
well, felxibility adds complexity, unfortunately that's always the case
14:36
Bertl
the main question is, what advantages/disadvantages do we create/get here
14:36
Francky
the challenge is to find the perfect ballance
14:36
Bertl
precisely
14:37
Francky
i see a lot of disavantages :
14:37
Bertl
let's hear then
14:37
Francky
- more chips = more expensive
14:37
Francky
- more soft = more bugs
14:37
Francky
- more soft = more difficult to developp and debug
14:37
niemand
joined the channel
14:38
Francky
but, the communication between zynq and pic could be very fast throught pmp
14:38
Francky
but you transfer the work of pic (get data from sensors) to the fpga or the fpga just convert spi to pmp ?
14:39
Bertl
maybe even fast enough to transfer a live image at some point?
14:39
Francky
there is necessarily a little bit of inteligence into the fpga ?!
14:39
Bertl
yes, but I think the small FPGA code will be a rather simple mapping
14:39
Bertl
i.e. a serialization/deserialization
14:40
Francky
ok i cannot imagine what is the difficulty here
14:40
Bertl
for a simple test, it could as well be configured to only map inputs to outputs and vice versa
14:40
Bertl
i.e. it would then become an expensive level shifter :)
14:41
Francky
:)
14:41
Francky
why do you want to transfer an image to the pic ?
14:41
Bertl
but expensive is relative, because the ICE40 for example costs about 2.5 EUR
14:42
Bertl
well, I do not want to do that now, but it might be interesting for somebody to do that lateron
14:43
Francky
maybe a small image, because 4K image is quite a huge amount of data
14:43
Bertl
yeah, of course, something suited for an LCD for example
14:43
Bertl
anyway, what I would propose is the following:
14:43
Bertl
(here with some rationale)
14:44
Bertl
we cannot change the headers right now, but we can plan a change in the next revision
14:44
Bertl
(the current headers are for testing anyway)
14:45
Bertl
so, let's design the PIC32 board for the future headers and assume whatever FPGA/CPLD/Level interface we consider apropriate
14:46
Bertl
then, we simply build an adapter board which maps the current headers to the future layout
14:46
Bertl
this way we can test it right now, and once we are confident, we simply drop the adapter board and move the content to the beta board
14:46
Francky
finally the pic board is becoming more like a "module", like you prensent modules for gamma camera ?!
14:47
Bertl
yeah, we should also consider what we can/should provide to keep it somewhat generic
14:48
Bertl
so when some atmel/TI freak comes along and wants his favorite microcontroller to work on the Beta, it doesn't require a complete redesign
14:48
Bertl
does that sound like a plan?
14:48
Francky
so the "pmp" interface, if we choose it, have to be completly generic
14:49
Francky
i think it is
14:49
Bertl
we can reduce it to having so and so many I/O pins dedicated for microcontroller communication
14:50
Bertl
whether it is PMP or 5xUART or a combination of I2C,SPI and I2S :) shouldn't matter much
14:50
Francky
but the fpga code will not be the same ?!
14:50
Bertl
all it requires is that somebody writes the correct glue code for the FPGA
14:50
Bertl
correct
15:15
niemand
left the channel
15:41
Bertl
Francky: http://pastebin.com/raw.php?i=saH3XqJa
15:41
Bertl
this might help
15:42
Bertl
I did it some time ago, and just digged it out
15:43
Bertl
and maybe this becomes useful as well: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pic32mz.lbr
15:44
Francky
thank you sorry i have a urgent thing to do
15:44
Bertl
no problem
15:45
Francky
i propose you to implement à "generic" parrallel port, 16bit data, 16 bit address, RD/WRn
15:45
Francky
sensors will be mapped in address by the fpga
15:46
Francky
and microcontroller can talk with everybody throught the pmp
15:46
Francky
it seems generic no ?
15:46
Bertl
definitely, but a lot of pins
15:48
Francky
it could be frightening for someone you just want to create its own microcontroller board just to blink a led... :(
15:49
Bertl
that's what I meant with number of I/O pins
15:49
Bertl
let's say, we define 12 or 16 I/O pins for general zynq/microcontroller communication
15:50
Bertl
then those 16 pins can be used to implement PMP to the PIC
15:50
Francky
it could be pmp 8data 8addr 1RS/WRn
15:50
Bertl
or it could be used for simple UART communication
15:50
Bertl
or in an extreme case, it could be just a board with 16 LEDs :)
15:51
Francky
why not
15:51
Bertl
so, let's figure out how many I/Os we need for PMP
15:51
Francky
can we get 17 IO to get a standard 8bit PMP ?
15:51
Bertl
8+8+2 is enough?
15:51
Bertl
write and read, no?
15:52
Francky
for me the extra 1 signal is a RD/WRn
15:52
Francky
but in the pic there are 1 RD and 1 WR
15:52
Francky
so we can put 2 extra controle signal
15:53
Bertl
okay, so let's plan with 20 I/Os for now
15:53
Francky
you are generous :)
15:53
Bertl
plus one I2C interface to connect to the power board
15:53
Francky
so the pic will have to monitor/control power regulator ?
15:54
Bertl
it would make sense to do that for low power applications
15:54
Bertl
also most of the power sensors are on that I2C bus, so monitoring those would make sense too
15:54
Francky
but why power board doesn't integrate a dedicated controller for monitoring and controle ?
15:55
Bertl
it has, no worries, the idea is just to be able to power down various subsystems
15:55
Bertl
and more importantly, to wake up the entire camera
15:55
Francky
so the pic will be the main part which will power on all the rest ?
15:56
Bertl
when in power down state, probably, yes
15:57
Francky
i think different subsystem are very dispatched, but i think you have a better vision than me about the use of the entire system
15:59
Bertl
so we have 22 I/O pins total
15:59
Bertl
the NE/SE headers have 24 pins in total
15:59
Bertl
so that looks like a good match
16:01
Bertl
we eliminate the SPI-E
16:01
Bertl
(header I mean)
16:01
Francky
yep
16:01
Francky
i need to go, i continue to reflect about this
16:01
Bertl
now the question is, what about powering the future "shield"
16:01
Bertl
okay, cya
16:01
Francky
bye
16:02
Francky
left the channel
16:09
Jin^eLD
changed nick to: Jin|away
16:19
fadro
One question Bertl, you are using eagle, but are you open to switch to a full open source application like Kicad?
16:19
niemand
joined the channel
16:19
Bertl
yes, as a matter of fact we already decided to switch to kicad
16:20
Bertl
it is just that right now it would be too time consuming for me to make the transition
16:20
Bertl
but we verified that we can export from eagle to kicad, it just needs minor rework
16:23
fadro
OK and library can also be imported...?? This is a critical & time consuming part especially for big cases
16:23
aombk2
changed nick to: aombk
16:24
Bertl
that is indeed the most problematic part, as kicad has a very different library model as eagle
16:24
Bertl
i.e. in kicad there are no components, just footprints
16:24
Bertl
and they are shared between various components
16:25
Bertl
but I'm optimistic that this is something we can handle with the help of volunteers
16:26
fadro
OK. Since i do not know anything about Kicad nor Eagle (we work on Cadstar & Altium here!) I prefer to use a complete open source app to push it up... The only big advantage of eagle is its community and library!
16:26
fadro
(i think!)
16:26
Bertl
yeah, kicad was rather problematic when I started (i.e. almost no features, very complicated to use, etc)
16:27
Bertl
this has changed since CERN has adopted the software package
16:27
mars_
which reminds me, I wanted to try out the new xsignals feature from altium 15
16:29
fadro
And concerning the 10DOF sensors embedded later, what about to use an existing open module like Adafruit 10-DOF IMU breakout? All libraries are already written and HW job is already done...
16:30
Bertl
well, the IMUs nowadays do not require many components, so it's basically a MEMs chip with a buffer capacitor
16:31
Bertl
i.e. adding a rather large breakout board would be overkill IMHO
16:31
Bertl
regarding the libraries, sure, you can use them, why not
16:31
Bertl
the IMUs we are considering are all standard solutions
16:32
Bertl
so I'm pretty sure they are supported already
16:32
Bertl
(I pasted a list yesterday)
16:36
fadro
You want to definitively integrate this feature or simply mounting it as an option?? Because in the 1st case, you are right, it's better to build it onboard, but in the 2nd case, it can be easier to solder the IMU or not.
16:36
Bertl
we can still decide to solder specific components or leave them unpopulated
16:37
Bertl
but the IMUs are rather cheap compared to the rest of the device
16:37
Bertl
so I tend to have it on board just in case it becomes useful :)
16:38
fadro
Sure you're right, the price of the camera will not change with/without this feature!
16:39
Bertl
but I was considering to keep the solder on design we have now for the center sensors
16:39
Bertl
just to allow for testing different solutions there, but I haven't found a smart way to reduce the weight
16:40
Bertl
weight/space/additional PCB
16:40
Bertl
if you look at the beta board, the center is designed to carry a diamond shaped solder on board
16:41
Bertl
which is there to provide a quick solution for testing the IMUs
16:42
Bertl
I thought about making that a cut out in the beta board, but such a solution is hard to stabilize
16:47
fadro
OK. understand...and you would like to embedded the 10DOF data into each pictures metadata??
16:54
Bertl
yes, that is the idea
16:55
Bertl
provide filtered and maybe preprocessed metadata with each frame
17:14
HoloIRCUser1
joined the channel
17:15
intracube
changed nick to: intracube_afk
17:15
Bertl
welcome HoloIRCUser1!
17:16
HoloIRCUser1
left the channel
17:17
Francky|busy
joined the channel
17:18
Francky|busy
It was me who try holoIrc :)
17:18
Bertl
ah, no problem, how was it?
17:19
Francky|busy
I'm on it now it permit tu be on irc with android
17:19
Francky|busy
It is good because no ads
17:21
Francky|busy
I reflect about our discution, shouln't be easier to provide spi + lot of CS?
17:21
Francky|busy
It is generic
17:21
Francky|busy
And we can get rid of the fpga
17:22
Bertl
how so?
17:22
Bertl
I mean, why/how do we get rid of the fpga?
17:23
Francky|busy
In fact we can use 1 spi in slave for com with zynq, and 1 spi master with lot of CS to speak with all sensors
17:23
Francky|busy
In this case no need of fpga
17:23
Francky|busy
It seems easier but i may be wrong
17:25
Bertl
well, SPI can probably do 20MHz or maybe 80MHz on the PIC
17:25
Francky|busy
25Mbp
17:25
Francky|busy
Mbps
17:25
Bertl
let's assume 80MHz, which will give us 10MByte throughput on 3/4 Zynq lanes
17:27
Bertl
we can easily do 20-50 times that with the PMP for example
17:29
Bertl
(just saying)
17:30
Francky|busy
In my job i always need to make the balance between real needs and engineer dreams, so i always have this type of reflexion
17:35
Francky|busy
Where do you imagine to put the spi protocole decoding with the pmp ?
17:36
Bertl
I'm just having another crazy idea
17:37
Bertl
give me a minute to check something
17:40
Francky|busy
\o/
17:42
Bertl
nah, won't work, but I verified that we could easily put two more ICE40 on the beta board and have 15 medium speed I/Os per ICE40 for one zynq pair or 13 for two zynq pairs
17:42
Bertl
together with the 6 medium speed I/Os we already have, that would give 19 or 21 I/Os on each side of the beta
17:43
Bertl
I didn't check if we can pick a larger ICE40 footprint, which would be an option too
17:45
Bertl
checking that now
17:45
Francky|busy
We already have 20 io
17:46
Bertl
I don't want to use the ucBGA or csBGA versions of the ICE40, because those are hard to solder/route
17:47
Bertl
but we still have 84pin QFN and a 100pin VQFP
17:51
Bertl
so the 84QN is problematic with the OSHpark rules
17:52
Bertl
let's see if we can fit the 100 VQFP on the beta board
17:52
Francky|busy
left the channel
17:53
Bertl
it's huge but it would fit
18:20
Francky|busy
joined the channel
18:20
intracube_afk
left the channel
18:22
Francky|busy
left the channel
18:31
intracube
joined the channel
19:15
Francky|busy
joined the channel
19:16
Francky|busy
Hey Bertl what do you want to do with all these io?
19:17
Bertl
actually I would be more than happy with an 48pin FPGA or something in this area
19:17
Bertl
but unfortunately suitable parts are not available
19:18
Bertl
so it seems like we have the choice between the QFN32 and the VQFP100 only
19:18
Francky|busy
You are speaking about fpga between pic and zynq right?
19:18
Bertl
yes
19:19
Francky|busy
The 32 is not big enought to implement 16bit data 16 bit addr an rd/wr
19:20
Bertl
probably not even big enough to do 8/8 proper
19:20
Francky|busy
Why?
19:20
Bertl
well, we have a total of 21 I/O pins on the QFN32
19:21
Bertl
to make it programmable, we are down to 17 I/Os
19:21
Francky|busy
18 pmp + 2 lvds
19:22
Francky|busy
Erf
19:22
Francky|busy
:(
19:22
Bertl
yeah, unfortunately all pin counts between 32 and 100 are some kind of 0.4 or 0.5mm BGA
19:22
Bertl
which doesn't work with the OSHpark PCBs
19:24
Bertl
OTOH, with the VQFP 100, we shouldn't have much problems with the routing
19:24
Francky|busy
100 is huge, can we use non pmp pins for an other function?
19:25
Bertl
and we do not need to connect everything
19:25
Bertl
yes, for sure we can add some more connectors or something like that
19:26
Francky|busy
Hey but this fpga need to be connected to sensors too no?
19:26
Bertl
yes
19:26
Francky|busy
So spi + some CS
19:27
Bertl
would be doable, if we can route it
19:27
Francky|busy
We can add i2c for power board too
19:27
Bertl
correct
19:29
Francky|busy
So maybe 100 pin is note as huge as we thought
19:29
Francky|busy
Not*
19:29
Bertl
we also need to handle some of the I/Os already handled by the current ICE40
19:30
Francky|busy
Io from zynq?
19:31
Francky|busy
What to do?
19:34
Bertl
no, if you check the current beta board
19:35
Bertl
you'll see that the ice40 connects to the interface board
19:36
Francky|busy
Ok
19:37
Francky|busy
We need to do the list of the needed connections
19:37
Bertl
so that's 12 I/Os for the interface board
19:37
Bertl
with a 3.3V level
19:38
Francky|busy
The voltage level of fpga pins are configurable?
19:39
Francky|busy
By bank
19:39
Bertl
yes
19:39
Bertl
i.e. each bank can have a separate I/O voltage
19:41
Francky|busy
How do you imagine communication on the pmp?
19:42
Francky|busy
For spi link, i imagine that an address manage a specific CS
19:42
Francky|busy
But i dont imagine the link between pic and zynq
19:43
Bertl
well, the PIC can do DMA on the PMP IIRC
19:43
Bertl
so it could be a memory mapping between zynq and PIC
19:44
Bertl
but there are more options I guess
19:44
Francky|busy
So pic will write data into zynq emulated memory throught pmp
19:44
Francky|busy
Ok
19:44
Bertl
yup
19:45
Francky|busy
It make the pic bsp very light because of the unique bus used
19:49
Francky|busy
I think about anothet disadvantage about unique pmp bus
19:50
Francky|busy
When pic will asked something to a device on the i2c bu, it will have to wait for answer a long time
19:51
Francky|busy
Because ok the low speed of i2c
19:51
Francky|busy
And all is suspend
19:51
Francky|busy
Of*
19:52
Francky|busy
Or we put the i2c and spi protocole into the fpga but in this case the pic do not have a lot of thing to do…
19:56
Bertl
well, the pic can run some userspace logic
19:56
Bertl
or we can still feed the sensor data into the PIC via the FPGA
19:56
Bertl
for processing/logging
19:57
Bertl
and of course, it can handle all the GPIO to the outside
19:57
Francky|busy
So this is fpga which implement the i2c protocole?
19:57
Bertl
we can do that if we like to
19:58
Francky|busy
I don't think it is the easiest way
19:58
Bertl
but note that the PIC has hardware support for I2C
19:58
Bertl
so it can be handled completely in interrupt
19:59
Bertl
which means that nothing has to wait for a completion or similar
19:59
Francky|busy
It is for that i propose you not to put the i2c and spi to fpga but directly to the pic
20:01
Francky|busy
But so we need more pins on connectors
20:01
Bertl
the FPGA can bridge I2C quite fine, it just needs to know the protocol
20:02
Francky|busy
What is the interest of an i2c bridge?
20:02
Bertl
I'm not saying that we need/want to do that, I'm saying that we can do that if we want to :)
20:02
Francky|busy
Why dont connect i2c from power board to pic i2c?
20:03
Bertl
I'm fine with that
20:04
Francky|busy
Ok
20:04
Francky|busy
So what is your final choice?
20:05
Francky|busy
Or pre final choice :) ?
20:05
Bertl
hehe
20:06
Bertl
I think we should sleep over that
20:06
Bertl
but the following points look very appealing to me (just to summarize)
20:07
Bertl
- replace the existing QFN32 iCE40 with a VQFP100 version on both sides of the beta board
20:07
Bertl
- put similar headers on both sides and have at least 20 I/Os on those headers plus probably one or two I2C ports
20:08
Bertl
- move the PIC32MZ on the shield
20:08
Bertl
the benefits I see in those changes are:
20:09
Bertl
- all GPIO on the high speed side can be handled by the iCE40
20:09
Bertl
- the low speed side can work even without PIC32, e.g. for debugging or really simple I/O
20:09
niemand
left the channel
20:10
Bertl
- we can potentially have two microcontroller/GPIO interface shields with similar/identical layout
20:10
Bertl
- we can easily accomodate different microcontrollers with this interface
20:10
Francky|busy
A shield is an additionnal board right?
20:11
Bertl
yes, something we plug onto the headers
20:11
Francky|busy
Ok
20:12
Bertl
the only drawback I see (which is not really a drawback IMHO) is that we need a shield to have the PIC32
20:12
Francky|busy
After a good night we'll try to specify the interface signals of the poc shiels
20:12
Francky|busy
Pic*
20:13
Bertl
sounds like a plan!
20:13
Francky|busy
Or to think about a completly new architecture :D
20:15
Bertl
yeah :)
20:19
Francky|busy
See you tomorrow
20:19
Francky|busy
Bye
20:19
Bertl
cya and thanks!
20:20
Francky|busy
left the channel
21:00
Bertl
off for a nap ... bbl
21:00
Bertl
changed nick to: Bertl_zZ
21:10
Jin|away
changed nick to: Jin^eLD