Current Server Time: 06:34 (Central Europe)

#apertus IRC Channel Logs

2015/03/05

Timezone: UTC


00:37
MatthiasF
left the channel
01:26
fsteinel
joined the channel
01:56
Jin^eLD
changed nick to: Jin|away
01:57
fsteinel_
joined the channel
02:00
fsteinel
left the channel
02:00
fsteinel_
changed nick to: fsteinel
02:14
ItsMeLenny
joined the channel
03:15
intracube
changed nick to: intracube_afk
03:30
jucar
left the channel
05:45
ItsMeLenny
left the channel
05:46
ItsMeLenny
joined the channel
06:31
Bertl_zZ
changed nick to: Bertl
06:31
Bertl
morning folks!
06:37
ItsMeLenny
morning Bertl!
08:06
Francky
joined the channel
08:15
Francky
hey Bertl
08:15
Francky
you saw me yesterday that signal are 1.
08:15
Francky
1.8V on connectors on the pic board
08:15
Francky
so a converter is needed
08:16
Francky
do you have any converter references that you have already used ?
08:50
Bertl
yes, for the LVDS (i.e. signals coming from the Zynq) the other signals are 3.3V
08: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
08:53
Bertl
or 74AVC4T774 as alternative
09: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 ?
09:01
Francky
i mean jtag of pic
09:01
Francky
on the hdr ne connector
09:01
MatthiasF
joined the channel
09:03
Francky
lvds signals are JX* signals on hdr connectors right ?
09: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
09:04
Bertl
or alternatively, 4/5 of the medium speed pins from HDR-NE going to U6
09:04
Bertl
yes, the "right side" of HDR-SE and HDR-NE is from the Zynq
09:08
Francky
in my mind jtag needs 4 signals ?!
09:08
Bertl
yeah, we might need the reset as well
09:08
Francky
oh 4/5 in your sentence mean "4/5 pins" and not "the pins 4 and 5"
09:09
Bertl
yep
09:09
Francky
ok
09:09
cbohnens|away
changed nick to: cbohnens
09:13
Francky
for I2C/SPI signals, they are 1.8V level too ?
09:13
Bertl
we'll probably go for 3.3V there
09:14
Francky
so no need of GTL2002
09:14
Bertl
unless you want to connect an I2C port to the Zynq, no
09:15
Bertl
the main difference is bidirectional vs unidirectional
09: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
09:17
Francky
ok so we'll use gtl2002 for zynq lvds signal to be able to use them in bidirectionnal right ?
09:17
Bertl
it can still be SPI, if we either have only one slave or designate 1-3 of the SPI-W for CS
09: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 ?
09:35
Bertl
maybe let's use the MP-NE power for the 1.8V rail
09: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 ?
09:37
Bertl
it might be a good idea to keep digital and analog separate for noise reasons
09:38
Francky
so this is the power board which will make filtering right ?
09:38
Bertl
correct
09:38
Francky
and for 1.8V, we remove a GND signal on the MP NE connector ?
09:38
Bertl
just take the middle pin
09:39
Bertl
it is connected to the JX1-7
09:39
Francky
ok
09:39
Bertl
which is currently not connected on the power board, but easy to patch to 1.8V
09:45
Jin|away
changed nick to: Jin^eLD
09:45
fadro
joined the channel
09:54
se6astian|away
changed nick to: se6astian
09:56
fadro
Hi all
09: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
10: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.
10: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).
10:04
se6astian
changed nick to: se6astian|away
10:15
Bertl
yes, and no
10:15
Bertl
there are two problems with this approach
10: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
10:16
se6astian|away
changed nick to: se6astian
10:16
Bertl
and secondly, we would get all the heat produced by regulation, instrumentation, etc on the sensor board
10: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
10:19
se6astian
good day
10:20
Bertl
for what? hopefully not to die :)
10: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.
10:25
se6astian
for a lot of things... :)
10:27
Bertl
fadro: note that we don't require a hardware change (except for the sensor board) in the current setup either
10:28
Bertl
(because the power board can accomodate the different voltages)
10: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
10: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?
10: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
10:32
Bertl
the current power board is a test board to get something working quickly
10:32
Bertl
the final power board will feature a central power management system which can be fully programmed
10: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?
10:36
Bertl
yes
10: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
10:38
Bertl
depending on the results we might go for one or the other or a mix of both
10: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...)
10: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
10: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
10:42
Bertl
but it might make sense to have the two/four voltages for plugin modules flexible as well
10: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
10:47
fadro
by supplying several rails, you complicate the initial power board design and you are not sure to handle the plugin needs...
10: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
10: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...
10:51
Bertl
the current design prevents this by direct feedback, of course, it's not 100% but close
10:52
Bertl
but I agree, for now it is probably better to keep it simple
10: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.
10:55
fadro
I think that hackers will know better that can be anticipated what they should need...
10:57
surami
joined the channel
10:57
surami
hi
10:57
Bertl
wb surami!
10:59
surami
i would like to know things about the low light capabilities of the Beta, especially shooting timelapses
10:59
surami
i mean milkyway shots etc.
11:00
surami
is the sensor capable for this things too?
11: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??
11: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
11: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
11:01
Bertl
fadro: or alternatively pre process it in the interface FPGA
11:02
Bertl
surami: for astronomy purposes you probably want excellent cooling and you definitely need the equippment to track your object
11:02
Bertl
but the sensor itself can do very long exposures
11:03
ItsMeLenny
left the channel
11: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...
11:06
Bertl
first, we can change the interface in various ways, higher datarate, memory like single ended interface, etc
11:06
Bertl
secondly, we can avoid transferring idle data
11: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
11:07
Bertl
so yeah, it's not likely that we will do full bandwidth right now, but there are certainly options for the future
11: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.
11:11
se6astian
changed nick to: se6astian|away
11:13
Bertl
btw, any comments on the existing design, routing, choice of parts, etc?
11: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...
11:15
fadro
Comments concerning the existing design are more related to the modularity architecture the the electrical design itself
11: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?
11:17
Bertl
we know the 4 layer stackup and the dielectric constant of the substrate (FR408)
11: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.
11: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
11: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)?
11:19
Bertl
the existing 100R differential/50R single setup is the result of EM simulation
11: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)
11:21
Bertl
s/width/thickness/
11:21
Bertl
(at least as far as I know :)
11: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...
11:22
Bertl
yes, agreed
11:22
fadro
OK, you use a field solver to got the tracks width and spacement??
11:23
Bertl
yes
11:23
fadro
Polar, Hyperlinx, or maybe an online one?
11: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.
11:27
Bertl
we've mostly used ATLC but also investigated openEMS and MMTL
11:28
Bertl
there are online field solvers?
11: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
11: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....
11:31
Bertl
http://support.oshpark.com/helpdesk/attachments/4001917116
11:31
fadro
by poor FR4 quality, i'm speaking about the fiber weave with large spacement which lead to high variation in the Er
11:31
surami
@se6astian: thanks for the link, @Bertl: ok, i understand
11:31
Andrej741
left the channel
11:32
fadro
ooh, very good, give me a few seconds....
11: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!
11:39
Bertl
excellent then!
11:40
Bertl
so far, we have been very satisfied with the PCBs in almost all regards
11: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.
11:42
Bertl
page and coordinates?
11:43
Bertl
or are you referring to the "broken" ellipses around the pairs?
11:44
fadro
well, page 2, all the connections on the Xnorth and X south...And i'm speaking about the electrical connection....
11:44
fadro
But it looks like a drop error that has been saved... I get it from the server of course..
11:45
Bertl
hmm, okay, let me update the files, just to make sure
11:46
jucar
joined the channel
11:47
Bertl
okay, please redownload and check if you see the same effect
11:49
fadro
OK, this time the *.sch file is correct!
11:49
fadro
just to be back on a previous [12:06] point...
11: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...
11:50
Bertl
well, with the de/serializers in the zynq, the HR banks can still do 1.2-1.6GHz
11:51
Bertl
we have 36 pairs from the interface board to the zynq
11:51
Bertl
and we have a total of 80 pairs to the sensor board
11:53
Bertl
so it should be enough to handle the sensors we have for now
11: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??
11:59
Bertl
we already plan to support the PicoZed as well
11:59
Bertl
(and the Parallella, for those interested in image processing)
12:00
niemand
joined the channel
12:00
intracube_afk
changed nick to: intracube
12: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...)
12:01
Bertl
yes, the only problem is the minimalistic nature of the PicoZed
12:01
Bertl
i.e. no console, no ethernet, no USB, etc
12:01
Bertl
but I agree, the MGTs are very interesting
12: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 :))
12:03
se6astian|away
changed nick to: se6astian
12:03
Bertl
yeah, the most likely solution for the PicoZed will be to add another PCB which handles the MGTs and the missing interfaces
12:05
fadro
Yes, but once again, extreme care should be taken with connectors interface especially if we play with GTP/GTX signals....
12:06
fadro
And to handle this, even if it is future (as short as possible...) the modularity architecture has to be well choosen...
12:06
Bertl
that's the reason why this PCB would address the MGTs directly
12:06
fadro
to let highspeed signal in the best integrity as possible...
12: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??
12:11
Bertl
interestingly they are compatible
12:11
Bertl
i.e. the two connectors shared between MicroZed and PicoZed are identical
12:12
Bertl
all new connections are done through the third connector
12:17
fadro
Oh, I didn't care about this, so it's surprising and very interesting yet...Compatibility have been well stutied...
12: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...
12:18
fadro
*advantage
12:19
Bertl
that's why I said another PCB :)
12:23
jucar
left the channel
12: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??
12:24
Bertl
yes, that's the most likely scenario
12:24
Bertl
where of course certain boards would be a bad choice, because they have been superceeded by newer ones
12:30
jucar
joined the channel
12:35
fadro
What do you mean by superceeded?
12: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
12: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.
12:48
Bertl
yes, we hope and think so
12: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?
12:50
Bertl
we had some estimates but nothing fixed at the campaign
12:50
fadro
And what was the estimation ?
12:51
Bertl
we are good in time but due to the changes we incorporated, we will not make our (originally) planned goal
12:52
fadro
OK, so what are the changes and what is the reported estimated date??
12: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
12:54
Bertl
now we have really modular sensor boards, the interface board to allow for full bandwidth and the PCIe plugin modules
12:54
Bertl
(before those were simple shields on the front of the camera)
12: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...
12:56
Bertl
we will have early betas next month, so bold folks can probably still get a beta in april :)
12:56
fadro
:)
12: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 :)
12:57
fadro
Yes, i agree
12:57
se6astian
changed nick to: se6astian|away
12: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...??
12:59
niemand
left the channel
13: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
13:05
Bertl
for example Francky is currently working on the PIC32 "shield"
13: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, ..
13:18
Bertl
not yet, it is mostly in our minds, but there will be documentation soon
13: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...
13: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!!)
13:27
Francky
it would had help me yesterday :)
13:27
Francky
have*
13:29
fadro
Are you new comer to this project?
13:31
Francky
yes
13:32
Francky
and i had to extract lot of information from the head of Bertl :D
13: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
13:33
Francky
and as you see my english is not very good
13:38
Bertl
fadro: any help is truly appreciated
13:39
Bertl
Francky: don't worry, it is more than sufficient to communicate :)
13:40
se6astian|away
changed nick to: se6astian
13:40
se6astian
changed nick to: se6astian|away
13:41
Francky
i have difficulty with conjugation
13:42
Francky
because i'm french and we don't use conjugation very weel in french language
13:42
Francky
but i agree i undestand what you tell, and we undestand almost i said :)
13:48
fadro
Francky : You are French? I love this country!!! Vive la France ... Maybe cause that's my native one!!
13: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...
13:49
Francky
yep. Where are you now ?
13:50
fadro
But since i'm more HW than SW, i choose an open source pjct which fits my job...
13:50
fadro
Euuhhh, in France...
13:51
Francky
i undestood that you have leave France, don't know why...
13:51
Francky
for me i'm more SW than HW :)
13:52
Francky
but i like both
13:52
fadro
by SW you mean firmware & RTOS or heavier OS like linux, ... I also like both...
13:54
fadro
Bertl : For doing such king of graph, documention,... do you have prefered application and prefered way to share online doc???
13:56
Bertl
well, I did this one: https://images.indiegogo.com/file_attachments/846669/files/20140910012757-BETA_interface.jpg with tikz
13: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)
13:57
Bertl
something TeX based is probably easiest to adjust to changes and also can be easily incorporated into other documents
13:57
niemand
joined the channel
14:00
fadro
yes, agree, and how do you usually share your drafts doc for team discussion??
14:00
Bertl
many documents are either just uploaded or shared via google docs
14:01
Bertl
but we have the wiki as well for documentation
14:01
fadro
ok, good let's take goole doc as document repository... You have an open account on google doc??
14:02
Bertl
please check with se6astian when he comes back, I'm not really into google doc
14:02
fadro
OK, i will...
14:02
Bertl
(mostly because they prevent "sane" copy/paste on Linux :)
14:03
fadro
:) i see...
14:08
danieel
left the channel
14:13
danieel
joined the channel
14:18
niemand
left the channel
14:33
Francky
Bertl> do you have any time to take a look to my schematics ?
14:36
niemand
joined the channel
14:40
Bertl
sure, url?
14:43
Francky
https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.pdf
14:44
Francky
i've put spi, jtag, isp, then all IO from zynq and beta board fpga, then led on free pins
14:46
Bertl
the schematic around the pic looks a little crowded :)
14:47
Bertl
i.e. it is hard to read
14:47
Francky
yes but all pins are connectes, unless usb pins that are dedicated for usb
14:47
Bertl
and it seems to have my copyright :)
14:48
Francky
yes i have copied your schematics style
14:48
Francky
to be homogeneous
14:49
Bertl
so what is the idea how the zynq and the pic communicate?
14:49
Francky
oh a question about Eagle : how do you do to make labels with small text size and decoration aroud ?
14:49
Bertl
it is a style option for the label, you can select it in the tool bar or change it later
14:50
Bertl
the text size can be changed via the size attribute
14:53
Francky
ok i will search
14:54
Francky
for communication, there is a mappable UART RX TX on RF0 and RF1, connected to JX2
14:54
Bertl
PMP would be an option, but that requires at least PMD0-PMD7
14:54
Bertl
plus the involved control signals and some address lines
14:55
Francky
it faster, but more expensive about gpio
14:55
Francky
is*
14:55
Bertl
how much space do you have left on the board?
14:55
Francky
do we need high speed communication ?
14:55
Bertl
it might make sense for the IMU data later
14:56
Bertl
so if possible, we should keep that option open
14:56
Francky
https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.png
14:57
Bertl
so it's already rather crowded
14:57
Francky
it depends on what you want to add :)
14:59
Bertl
well, we could add some FPGA/CPLD to make better use of the zynq connection(s)
14:59
Bertl
but I think that is not an option here, too little space left
14:59
Francky
to use the lvds lines ?
14:59
Bertl
yeah
15:01
Francky
so do you have another good idea for the bus between zynq and pic ?
15:02
Bertl
you're the pic expert :)
15:02
Francky
pic datasheet says that baud rate on UART could be to 25Mbps
15:03
Francky
it depends on the real need, and you have more information in mind that me
15:03
Francky
than*
15:03
Francky
about global system
15:04
Bertl
but for a synchronized uart interface we only need what, 3? lines to the zynq, yes?
15:04
cbohnens
changed nick to: cbohnens|away
15:05
Bertl
i.e. what do we have the other 7 lines for?
15:05
Francky
i always use 2 lines in UART communication, because i always make synchronised interface (ie : 1 master asks 1 slave)
15:08
Bertl
hmm, there is no crystal and no clock input for the PIC32
15:08
Francky
i don't know what you want to do with :) why did you provise so much pins between zynq and pic ?
15:08
Bertl
so you completely rely on the internal oscillator
15:08
Francky
it was my thought
15:09
Bertl
to answer the question: I didn't :) i.e. I just routed all available zynq I/Os to the header :)
15:09
Francky
using the internal oscillator to preserve gpio outputs
15:09
Bertl
this will probably limit the PIC32 to a lower frequency and result in more problems with synchronization
15:10
Bertl
also, what about the RTCC, it requires the secondary oscillator and a clock crystal IIRC
15:11
Bertl
and the RTCC as well as keeping time in low power mode would be something really useful
15:11
Bertl
(just commenting here)
15:13
Francky
it seems that internally oscillator is sufficient to achienve 200MHz
15:14
Francky
i have not take into consideration the RTCC
15:14
Francky
do you think a electrical cell is needed to keep the time if there is no more power ?
15:15
Francky
like there is in PC
15:18
Francky
but we can put an external one if you want to have a very precise one
15:19
Francky
for rtc it seems that there is a 32k internal clock
15:21
Bertl
okay, so that would work without any oscillator/crystal? and if so, with what precision?
15: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
15: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 ?
15:23
Bertl
from your designs so far, it doesn't seem to make much sense to connect the zynq directly to the PIC, no?
15:23
Bertl
(different voltages, different speed, no advantage there)
15:24
Francky
i don't undestand what you mean
15:24
surami
left the channel
15:24
Bertl
I mean that it wouldn't make much sense to connect the zynq directly to the PIC
15:24
Bertl
looking at the beta test board, we have a lot of space on the right side
15:24
niemand
left the channel
15:25
Bertl
which is potential space for the PIC if we decide to put it directly on the beta board
15:25
Francky
what do you mean by "directly" ?
15:25
Bertl
if, OTOH, we decide to make the PIC a shield, i.e. keep the headers
15: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
15:26
Francky
ok i undestand
15:27
Bertl
the PIC still needs a direct contact to the power management
15:27
Francky
so your idead is to put a fpga "under" the pic board, to convert lvds from zynq to, for example, PMP
15:27
Bertl
i.e. a dedicated I2C connection
15:27
Bertl
yes, that would be the idea
15:27
Francky
you want that the pic control the power board ?
15:27
Francky
throught i2c ?
15:27
Bertl
we could get rid of the PSI-E which seems to be in the way
15:27
Bertl
*SPI-E
15:28
Bertl
and instead use all the HDR-SE/NE connections for PIC/zynq I/O
15:29
Bertl
that would probably allow to use the larger PIC with more GPIOs
15:29
Bertl
and still have plenty of I/Os left for LCD/buttons/etc
15:30
Bertl
does that make sense?
15:30
Francky
why do you want to get rid of the spi_e bus ?
15:30
Bertl
not the bus, the header :)
15:30
Francky
i undestood that you want to connect 10DOF on it ?
15:31
Francky
ok so you want to put a fpga between pic and sensor too ?
15:31
Bertl
we can terminate the bus on the same FPGA/CPLD which connects to the pic
15:31
Bertl
or we can just route the sensor bus to the NE/SE header
15: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 ?
15:33
Bertl
yes, that would make sense to me, unless you have a better idea?
15:34
Francky
to be honest the growing complexity make me doubt
15:35
Francky
but i am not confortable with fpga so i probably don't reflect like you
15:35
Francky
:)
15:36
Bertl
well, felxibility adds complexity, unfortunately that's always the case
15:36
Bertl
the main question is, what advantages/disadvantages do we create/get here
15:36
Francky
the challenge is to find the perfect ballance
15:36
Bertl
precisely
15:37
Francky
i see a lot of disavantages :
15:37
Bertl
let's hear then
15:37
Francky
- more chips = more expensive
15:37
Francky
- more soft = more bugs
15:37
Francky
- more soft = more difficult to developp and debug
15:37
niemand
joined the channel
15:38
Francky
but, the communication between zynq and pic could be very fast throught pmp
15:38
Francky
but you transfer the work of pic (get data from sensors) to the fpga or the fpga just convert spi to pmp ?
15:39
Bertl
maybe even fast enough to transfer a live image at some point?
15:39
Francky
there is necessarily a little bit of inteligence into the fpga ?!
15:39
Bertl
yes, but I think the small FPGA code will be a rather simple mapping
15:39
Bertl
i.e. a serialization/deserialization
15:40
Francky
ok i cannot imagine what is the difficulty here
15:40
Bertl
for a simple test, it could as well be configured to only map inputs to outputs and vice versa
15:40
Bertl
i.e. it would then become an expensive level shifter :)
15:41
Francky
:)
15:41
Francky
why do you want to transfer an image to the pic ?
15:41
Bertl
but expensive is relative, because the ICE40 for example costs about 2.5 EUR
15:42
Bertl
well, I do not want to do that now, but it might be interesting for somebody to do that lateron
15:43
Francky
maybe a small image, because 4K image is quite a huge amount of data
15:43
Bertl
yeah, of course, something suited for an LCD for example
15:43
Bertl
anyway, what I would propose is the following:
15:43
Bertl
(here with some rationale)
15:44
Bertl
we cannot change the headers right now, but we can plan a change in the next revision
15:44
Bertl
(the current headers are for testing anyway)
15:45
Bertl
so, let's design the PIC32 board for the future headers and assume whatever FPGA/CPLD/Level interface we consider apropriate
15:46
Bertl
then, we simply build an adapter board which maps the current headers to the future layout
15: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
15:46
Francky
finally the pic board is becoming more like a "module", like you prensent modules for gamma camera ?!
15:47
Bertl
yeah, we should also consider what we can/should provide to keep it somewhat generic
15: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
15:48
Bertl
does that sound like a plan?
15:48
Francky
so the "pmp" interface, if we choose it, have to be completly generic
15:49
Francky
i think it is
15:49
Bertl
we can reduce it to having so and so many I/O pins dedicated for microcontroller communication
15:50
Bertl
whether it is PMP or 5xUART or a combination of I2C,SPI and I2S :) shouldn't matter much
15:50
Francky
but the fpga code will not be the same ?!
15:50
Bertl
all it requires is that somebody writes the correct glue code for the FPGA
15:50
Bertl
correct
16:15
niemand
left the channel
16:41
Bertl
Francky: http://pastebin.com/raw.php?i=saH3XqJa
16:41
Bertl
this might help
16:42
Bertl
I did it some time ago, and just digged it out
16:43
Bertl
and maybe this becomes useful as well: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pic32mz.lbr
16:44
Francky
thank you sorry i have a urgent thing to do
16:44
Bertl
no problem
16:45
Francky
i propose you to implement à "generic" parrallel port, 16bit data, 16 bit address, RD/WRn
16:45
Francky
sensors will be mapped in address by the fpga
16:46
Francky
and microcontroller can talk with everybody throught the pmp
16:46
Francky
it seems generic no ?
16:46
Bertl
definitely, but a lot of pins
16:48
Francky
it could be frightening for someone you just want to create its own microcontroller board just to blink a led... :(
16:49
Bertl
that's what I meant with number of I/O pins
16:49
Bertl
let's say, we define 12 or 16 I/O pins for general zynq/microcontroller communication
16:50
Bertl
then those 16 pins can be used to implement PMP to the PIC
16:50
Francky
it could be pmp 8data 8addr 1RS/WRn
16:50
Bertl
or it could be used for simple UART communication
16:50
Bertl
or in an extreme case, it could be just a board with 16 LEDs :)
16:51
Francky
why not
16:51
Bertl
so, let's figure out how many I/Os we need for PMP
16:51
Francky
can we get 17 IO to get a standard 8bit PMP ?
16:51
Bertl
8+8+2 is enough?
16:51
Bertl
write and read, no?
16:52
Francky
for me the extra 1 signal is a RD/WRn
16:52
Francky
but in the pic there are 1 RD and 1 WR
16:52
Francky
so we can put 2 extra controle signal
16:53
Bertl
okay, so let's plan with 20 I/Os for now
16:53
Francky
you are generous :)
16:53
Bertl
plus one I2C interface to connect to the power board
16:53
Francky
so the pic will have to monitor/control power regulator ?
16:54
Bertl
it would make sense to do that for low power applications
16:54
Bertl
also most of the power sensors are on that I2C bus, so monitoring those would make sense too
16:54
Francky
but why power board doesn't integrate a dedicated controller for monitoring and controle ?
16:55
Bertl
it has, no worries, the idea is just to be able to power down various subsystems
16:55
Bertl
and more importantly, to wake up the entire camera
16:55
Francky
so the pic will be the main part which will power on all the rest ?
16:56
Bertl
when in power down state, probably, yes
16: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
16:59
Bertl
so we have 22 I/O pins total
16:59
Bertl
the NE/SE headers have 24 pins in total
16:59
Bertl
so that looks like a good match
17:01
Bertl
we eliminate the SPI-E
17:01
Bertl
(header I mean)
17:01
Francky
yep
17:01
Francky
i need to go, i continue to reflect about this
17:01
Bertl
now the question is, what about powering the future "shield"
17:01
Bertl
okay, cya
17:01
Francky
bye
17:02
Francky
left the channel
17:09
Jin^eLD
changed nick to: Jin|away
17:19
fadro
One question Bertl, you are using eagle, but are you open to switch to a full open source application like Kicad?
17:19
niemand
joined the channel
17:19
Bertl
yes, as a matter of fact we already decided to switch to kicad
17:20
Bertl
it is just that right now it would be too time consuming for me to make the transition
17:20
Bertl
but we verified that we can export from eagle to kicad, it just needs minor rework
17:23
fadro
OK and library can also be imported...?? This is a critical & time consuming part especially for big cases
17:23
aombk2
changed nick to: aombk
17:24
Bertl
that is indeed the most problematic part, as kicad has a very different library model as eagle
17:24
Bertl
i.e. in kicad there are no components, just footprints
17:24
Bertl
and they are shared between various components
17:25
Bertl
but I'm optimistic that this is something we can handle with the help of volunteers
17: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!
17:26
fadro
(i think!)
17:26
Bertl
yeah, kicad was rather problematic when I started (i.e. almost no features, very complicated to use, etc)
17:27
Bertl
this has changed since CERN has adopted the software package
17:27
mars_
which reminds me, I wanted to try out the new xsignals feature from altium 15
17: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...
17:30
Bertl
well, the IMUs nowadays do not require many components, so it's basically a MEMs chip with a buffer capacitor
17:31
Bertl
i.e. adding a rather large breakout board would be overkill IMHO
17:31
Bertl
regarding the libraries, sure, you can use them, why not
17:31
Bertl
the IMUs we are considering are all standard solutions
17:32
Bertl
so I'm pretty sure they are supported already
17:32
Bertl
(I pasted a list yesterday)
17: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.
17:36
Bertl
we can still decide to solder specific components or leave them unpopulated
17:37
Bertl
but the IMUs are rather cheap compared to the rest of the device
17:37
Bertl
so I tend to have it on board just in case it becomes useful :)
17:38
fadro
Sure you're right, the price of the camera will not change with/without this feature!
17:39
Bertl
but I was considering to keep the solder on design we have now for the center sensors
17:39
Bertl
just to allow for testing different solutions there, but I haven't found a smart way to reduce the weight
17:40
Bertl
weight/space/additional PCB
17:40
Bertl
if you look at the beta board, the center is designed to carry a diamond shaped solder on board
17:41
Bertl
which is there to provide a quick solution for testing the IMUs
17:42
Bertl
I thought about making that a cut out in the beta board, but such a solution is hard to stabilize
17:47
fadro
OK. understand...and you would like to embedded the 10DOF data into each pictures metadata??
17:54
Bertl
yes, that is the idea
17:55
Bertl
provide filtered and maybe preprocessed metadata with each frame
18:14
HoloIRCUser1
joined the channel
18:15
intracube
changed nick to: intracube_afk
18:15
Bertl
welcome HoloIRCUser1!
18:16
HoloIRCUser1
left the channel
18:17
Francky|busy
joined the channel
18:18
Francky|busy
It was me who try holoIrc :)
18:18
Bertl
ah, no problem, how was it?
18:19
Francky|busy
I'm on it now it permit tu be on irc with android
18:19
Francky|busy
It is good because no ads
18:21
Francky|busy
I reflect about our discution, shouln't be easier to provide spi + lot of CS?
18:21
Francky|busy
It is generic
18:21
Francky|busy
And we can get rid of the fpga
18:22
Bertl
how so?
18:22
Bertl
I mean, why/how do we get rid of the fpga?
18: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
18:23
Francky|busy
In this case no need of fpga
18:23
Francky|busy
It seems easier but i may be wrong
18:25
Bertl
well, SPI can probably do 20MHz or maybe 80MHz on the PIC
18:25
Francky|busy
25Mbp
18:25
Francky|busy
Mbps
18:25
Bertl
let's assume 80MHz, which will give us 10MByte throughput on 3/4 Zynq lanes
18:27
Bertl
we can easily do 20-50 times that with the PMP for example
18:29
Bertl
(just saying)
18: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
18:35
Francky|busy
Where do you imagine to put the spi protocole decoding with the pmp ?
18:36
Bertl
I'm just having another crazy idea
18:37
Bertl
give me a minute to check something
18:40
Francky|busy
\o/
18: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
18: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
18:43
Bertl
I didn't check if we can pick a larger ICE40 footprint, which would be an option too
18:45
Bertl
checking that now
18:45
Francky|busy
We already have 20 io
18:46
Bertl
I don't want to use the ucBGA or csBGA versions of the ICE40, because those are hard to solder/route
18:47
Bertl
but we still have 84pin QFN and a 100pin VQFP
18:51
Bertl
so the 84QN is problematic with the OSHpark rules
18:52
Bertl
let's see if we can fit the 100 VQFP on the beta board
18:52
Francky|busy
left the channel
18:53
Bertl
it's huge but it would fit
19:20
Francky|busy
joined the channel
19:20
intracube_afk
left the channel
19:22
Francky|busy
left the channel
19:31
intracube
joined the channel
20:15
Francky|busy
joined the channel
20:16
Francky|busy
Hey Bertl what do you want to do with all these io?
20:17
Bertl
actually I would be more than happy with an 48pin FPGA or something in this area
20:17
Bertl
but unfortunately suitable parts are not available
20:18
Bertl
so it seems like we have the choice between the QFN32 and the VQFP100 only
20:18
Francky|busy
You are speaking about fpga between pic and zynq right?
20:18
Bertl
yes
20:19
Francky|busy
The 32 is not big enought to implement 16bit data 16 bit addr an rd/wr
20:20
Bertl
probably not even big enough to do 8/8 proper
20:20
Francky|busy
Why?
20:20
Bertl
well, we have a total of 21 I/O pins on the QFN32
20:21
Bertl
to make it programmable, we are down to 17 I/Os
20:21
Francky|busy
18 pmp + 2 lvds
20:22
Francky|busy
Erf
20:22
Francky|busy
:(
20:22
Bertl
yeah, unfortunately all pin counts between 32 and 100 are some kind of 0.4 or 0.5mm BGA
20:22
Bertl
which doesn't work with the OSHpark PCBs
20:24
Bertl
OTOH, with the VQFP 100, we shouldn't have much problems with the routing
20:24
Francky|busy
100 is huge, can we use non pmp pins for an other function?
20:25
Bertl
and we do not need to connect everything
20:25
Bertl
yes, for sure we can add some more connectors or something like that
20:26
Francky|busy
Hey but this fpga need to be connected to sensors too no?
20:26
Bertl
yes
20:26
Francky|busy
So spi + some CS
20:27
Bertl
would be doable, if we can route it
20:27
Francky|busy
We can add i2c for power board too
20:27
Bertl
correct
20:29
Francky|busy
So maybe 100 pin is note as huge as we thought
20:29
Francky|busy
Not*
20:29
Bertl
we also need to handle some of the I/Os already handled by the current ICE40
20:30
Francky|busy
Io from zynq?
20:31
Francky|busy
What to do?
20:34
Bertl
no, if you check the current beta board
20:35
Bertl
you'll see that the ice40 connects to the interface board
20:36
Francky|busy
Ok
20:37
Francky|busy
We need to do the list of the needed connections
20:37
Bertl
so that's 12 I/Os for the interface board
20:37
Bertl
with a 3.3V level
20:38
Francky|busy
The voltage level of fpga pins are configurable?
20:39
Francky|busy
By bank
20:39
Bertl
yes
20:39
Bertl
i.e. each bank can have a separate I/O voltage
20:41
Francky|busy
How do you imagine communication on the pmp?
20:42
Francky|busy
For spi link, i imagine that an address manage a specific CS
20:42
Francky|busy
But i dont imagine the link between pic and zynq
20:43
Bertl
well, the PIC can do DMA on the PMP IIRC
20:43
Bertl
so it could be a memory mapping between zynq and PIC
20:44
Bertl
but there are more options I guess
20:44
Francky|busy
So pic will write data into zynq emulated memory throught pmp
20:44
Francky|busy
Ok
20:44
Bertl
yup
20:45
Francky|busy
It make the pic bsp very light because of the unique bus used
20:49
Francky|busy
I think about anothet disadvantage about unique pmp bus
20: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
20:51
Francky|busy
Because ok the low speed of i2c
20:51
Francky|busy
And all is suspend
20:51
Francky|busy
Of*
20: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â¦
20:56
Bertl
well, the pic can run some userspace logic
20:56
Bertl
or we can still feed the sensor data into the PIC via the FPGA
20:56
Bertl
for processing/logging
20:57
Bertl
and of course, it can handle all the GPIO to the outside
20:57
Francky|busy
So this is fpga which implement the i2c protocole?
20:57
Bertl
we can do that if we like to
20:58
Francky|busy
I don't think it is the easiest way
20:58
Bertl
but note that the PIC has hardware support for I2C
20:58
Bertl
so it can be handled completely in interrupt
20:59
Bertl
which means that nothing has to wait for a completion or similar
20:59
Francky|busy
It is for that i propose you not to put the i2c and spi to fpga but directly to the pic
21:01
Francky|busy
But so we need more pins on connectors
21:01
Bertl
the FPGA can bridge I2C quite fine, it just needs to know the protocol
21:02
Francky|busy
What is the interest of an i2c bridge?
21: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 :)
21:02
Francky|busy
Why dont connect i2c from power board to pic i2c?
21:03
Bertl
I'm fine with that
21:04
Francky|busy
Ok
21:04
Francky|busy
So what is your final choice?
21:05
Francky|busy
Or pre final choice :) ?
21:05
Bertl
hehe
21:06
Bertl
I think we should sleep over that
21:06
Bertl
but the following points look very appealing to me (just to summarize)
21:07
Bertl
- replace the existing QFN32 iCE40 with a VQFP100 version on both sides of the beta board
21: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
21:08
Bertl
- move the PIC32MZ on the shield
21:08
Bertl
the benefits I see in those changes are:
21:09
Bertl
- all GPIO on the high speed side can be handled by the iCE40
21:09
Bertl
- the low speed side can work even without PIC32, e.g. for debugging or really simple I/O
21:09
niemand
left the channel
21:10
Bertl
- we can potentially have two microcontroller/GPIO interface shields with similar/identical layout
21:10
Bertl
- we can easily accomodate different microcontrollers with this interface
21:10
Francky|busy
A shield is an additionnal board right?
21:11
Bertl
yes, something we plug onto the headers
21:11
Francky|busy
Ok
21:12
Bertl
the only drawback I see (which is not really a drawback IMHO) is that we need a shield to have the PIC32
21:12
Francky|busy
After a good night we'll try to specify the interface signals of the poc shiels
21:12
Francky|busy
Pic*
21:13
Bertl
sounds like a plan!
21:13
Francky|busy
Or to think about a completly new architecture :D
21:15
Bertl
yeah :)
21:19
Francky|busy
See you tomorrow
21:19
Francky|busy
Bye
21:19
Bertl
cya and thanks!
21:20
Francky|busy
left the channel
22:00
Bertl
off for a nap ... bbl
22:00
Bertl
changed nick to: Bertl_zZ
22:10
Jin|away
changed nick to: Jin^eLD