#apertus IRC Channel Logs

morning Bertl!

hey Bertl

1.8V on connectors on the pic board

do you have any converter references that you have already used ?

for I2C we have been using the GTL2002 and similar, for unidirectional signals the 74LVC125 or 74AVC4T245 seems to do a good job

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 ?

on the hdr ne connector

lvds signals are JX* signals on hdr connectors right ?

or alternatively, 4/5 of the medium speed pins from HDR-NE going to U6

in my mind jtag needs 4 signals ?!

oh 4/5 in your sentence mean "4/5 pins" and not "the pins 4 and 5"

ok

for I2C/SPI signals, they are 1.8V level too ?

so no need of GTL2002

the main difference is bidirectional vs unidirectional

ok so we'll use gtl2002 for zynq lvds signal to be able to use them in bidirectionnal right ?

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 ?

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 ?

so this is the power board which will make filtering right ?

and for 1.8V, we remove a GND signal on the MP NE connector ?

it is connected to the JX1-7

which is currently not connected on the power board, but easy to patch to 1.8V

Hi all

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.

there are two problems with this approach

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

for what? hopefully not to die :)

for a lot of things... :)

(because the power board can accomodate the different voltages)

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?

the current power board is a test board to get something working quickly

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?

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

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...)

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

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

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

the current design prevents this by direct feedback, of course, it's not 100% but close

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.

wb surami!

i mean milkyway shots etc.

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??

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

surami: for astronomy purposes you probably want excellent cooling and you definitely need the equippment to track your object

first, we can change the interface in various ways, higher datarate, memory like single ended interface, etc

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

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.

btw, any comments on the existing design, routing, choice of parts, etc?

Comments concerning the existing design are more related to the modularity architecture the the electrical design itself

we know the 4 layer stackup and the dielectric constant of the substrate (FR408)

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

the existing 100R differential/50R single setup is the result of EM simulation

s/width/thickness/

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...

OK, you use a field solver to got the tracks width and spacement??

Polar, Hyperlinx, or maybe an online one?

we've mostly used ATLC but also investigated openEMS and MMTL

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

http://support.oshpark.com/helpdesk/attachments/4001917116

@se6astian: thanks for the link, @Bertl: ok, i understand

ooh, very good, give me a few seconds....

excellent then!

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.

or are you referring to the "broken" ellipses around the pairs?

But it looks like a drop error that has been saved... I get it from the server of course..

OK, this time the *.sch file is correct!

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...

we have 36 pairs from the interface board to the zynq

so it should be enough to handle the sensors we have for now

we already plan to support the PicoZed as well

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...)

i.e. no console, no ethernet, no USB, etc

Ah, that right, you have to do your own connector IF, BUT, we have your powerfull plugin architecture, so I see no problems :))

yeah, the most likely solution for the PicoZed will be to add another PCB which handles the MGTs and the missing interfaces

And to handle this, even if it is future (as short as possible...) the modularity architecture has to be well choosen...

to let highspeed signal in the best integrity as possible...

interestingly they are compatible

all new connections are done through the third connector

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...

that's why I said another PCB :)

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??

where of course certain boards would be a bad choice, because they have been superceeded by newer ones

What do you mean by superceeded?

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.

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?

And what was the estimation ?

OK, so what are the changes and what is the reported estimated date??

now we have really modular sensor boards, the interface board to allow for full bandwidth and the PCIe plugin modules

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...

:)

Yes, i agree

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...??

I'm doing most of the work on the electronics and software at the moment, but that will hopefully change in the near future

Is there any existing documents for describing the overall modular architecture? What are the inputs, the options, and also things like dataflows, supply trees, ..

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...

it would had help me yesterday :)

Are you new comer to this project?

and i had to extract lot of information from the head of Bertl :D

and as you see my english is not very good

Francky: don't worry, it is more than sufficient to communicate :)

because i'm french and we don't use conjugation very weel in french language

Francky : You are French? I love this country!!! Vive la France ... Maybe cause that's my native one!!

yep. Where are you now ?

Euuhhh, in France...

for me i'm more SW than HW :)

by SW you mean firmware & RTOS or heavier OS like linux, ... I also like both...

well, I did this one: https://images.indiegogo.com/file_attachments/846669/files/20140910012757-BETA_interface.jpg with tikz

something TeX based is probably easiest to adjust to changes and also can be easily incorporated into other documents

yes, agree, and how do you usually share your drafts doc for team discussion??

but we have the wiki as well for documentation

please check with se6astian when he comes back, I'm not really into google doc

(mostly because they prevent "sane" copy/paste on Linux :)

https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.pdf

the schematic around the pic looks a little crowded :)

yes but all pins are connectes, unless usb pins that are dedicated for usb

yes i have copied your schematics style

so what is the idea how the zynq and the pic communicate?

it is a style option for the label, you can select it in the tool bar or change it later

ok i will search

PMP would be an option, but that requires at least PMD0-PMD7

it faster, but more expensive about gpio

how much space do you have left on the board?

it might make sense for the IMU data later

https://dl.dropboxusercontent.com/u/782577/axiom_beta_pic_board_v0.1.png

it depends on what you want to add :)

but I think that is not an option here, too little space left

yeah

you're the pic expert :)

it depends on the real need, and you have more information in mind that me

about global system

i always use 2 lines in UART communication, because i always make synchronised interface (ie : 1 master asks 1 slave)

i don't know what you want to do with :) why did you provise so much pins between zynq and pic ?

it was my thought

using the internal oscillator to preserve gpio outputs

also, what about the RTCC, it requires the secondary oscillator and a clock crystal IIRC

(just commenting here)

i have not take into consideration the RTCC

like there is in PC

for rtc it seems that there is a 32k internal clock

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

from your designs so far, it doesn't seem to make much sense to connect the zynq directly to the PIC, no?

i don't undestand what you mean

I mean that it wouldn't make much sense to connect the zynq directly to the PIC

what do you mean by "directly" ?

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

the PIC still needs a direct contact to the power management

i.e. a dedicated I2C connection

you want that the pic control the power board ?

we could get rid of the PSI-E which seems to be in the way

and instead use all the HDR-SE/NE connections for PIC/zynq I/O

and still have plenty of I/Os left for LCD/buttons/etc

why do you want to get rid of the spi_e bus ?

i undestood that you want to connect 10DOF on it ?

we can terminate the bus on the same FPGA/CPLD which connects to the pic

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 ?

to be honest the growing complexity make me doubt

:)

the main question is, what advantages/disadvantages do we create/get here

precisely

let's hear then

- more soft = more bugs

but you transfer the work of pic (get data from sensors) to the fpga or the fpga just convert spi to pmp ?

there is necessarily a little bit of inteligence into the fpga ?!

i.e. a serialization/deserialization

for a simple test, it could as well be configured to only map inputs to outputs and vice versa

:)

but expensive is relative, because the ICE40 for example costs about 2.5 EUR

maybe a small image, because 4K image is quite a huge amount of data

anyway, what I would propose is the following:

we cannot change the headers right now, but we can plan a change in the next revision

so, let's design the PIC32 board for the future headers and assume whatever FPGA/CPLD/Level interface we consider apropriate

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

yeah, we should also consider what we can/should provide to keep it somewhat generic

does that sound like a plan?

i think it is

whether it is PMP or 5xUART or a combination of I2C,SPI and I2S :) shouldn't matter much

all it requires is that somebody writes the correct glue code for the FPGA

this might help

and maybe this becomes useful as well: http://vserver.13thfloor.at/Stuff/AXIOM/BETA/pic32mz.lbr

no problem

sensors will be mapped in address by the fpga

it seems generic no ?

it could be frightening for someone you just want to create its own microcontroller board just to blink a led... :(

let's say, we define 12 or 16 I/O pins for general zynq/microcontroller communication

it could be pmp 8data 8addr 1RS/WRn

or in an extreme case, it could be just a board with 16 LEDs :)

so, let's figure out how many I/Os we need for PMP

8+8+2 is enough?

for me the extra 1 signal is a RD/WRn

so we can put 2 extra controle signal

you are generous :)

so the pic will have to monitor/control power regulator ?

also most of the power sensors are on that I2C bus, so monitoring those would make sense too

it has, no worries, the idea is just to be able to power down various subsystems

so the pic will be the main part which will power on all the rest ?

i think different subsystem are very dispatched, but i think you have a better vision than me about the use of the entire system

the NE/SE headers have 24 pins in total

we eliminate the SPI-E

yep

now the question is, what about powering the future "shield"

bye

it is just that right now it would be too time consuming for me to make the transition

OK and library can also be imported...?? This is a critical & time consuming part especially for big cases

that is indeed the most problematic part, as kicad has a very different library model as eagle

and they are shared between various components

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!

yeah, kicad was rather problematic when I started (i.e. almost no features, very complicated to use, etc)

which reminds me, I wanted to try out the new xsignals feature from altium 15

well, the IMUs nowadays do not require many components, so it's basically a MEMs chip with a buffer capacitor

regarding the libraries, sure, you can use them, why not

so I'm pretty sure they are supported already

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.

but the IMUs are rather cheap compared to the rest of the device

Sure you're right, the price of the camera will not change with/without this feature!

just to allow for testing different solutions there, but I haven't found a smart way to reduce the weight

if you look at the beta board, the center is designed to carry a diamond shaped solder on board

I thought about making that a cut out in the beta board, but such a solution is hard to stabilize

yes, that is the idea

welcome HoloIRCUser1!

ah, no problem, how was it?

It is good because no ads

It is generic

how so?

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

It seems easier but i may be wrong

25Mbp

let's assume 80MHz, which will give us 10MByte throughput on 3/4 Zynq lanes

(just saying)

Where do you imagine to put the spi protocole decoding with the pmp ?

give me a minute to check something

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

I didn't check if we can pick a larger ICE40 footprint, which would be an option too

We already have 20 io

but we still have 84pin QFN and a 100pin VQFP

let's see if we can fit the 100 VQFP on the beta board

it's huge but it would fit

Hey Bertl what do you want to do with all these io?

but unfortunately suitable parts are not available

You are speaking about fpga between pic and zynq right?

The 32 is not big enought to implement 16bit data 16 bit addr an rd/wr

Why?

to make it programmable, we are down to 17 I/Os

Erf

yeah, unfortunately all pin counts between 32 and 100 are some kind of 0.4 or 0.5mm BGA

OTOH, with the VQFP 100, we shouldn't have much problems with the routing

and we do not need to connect everything

Hey but this fpga need to be connected to sensors too no?

So spi + some CS

We can add i2c for power board too

So maybe 100 pin is note as huge as we thought

we also need to handle some of the I/Os already handled by the current ICE40

What to do?

you'll see that the ice40 connects to the interface board

We need to do the list of the needed connections

with a 3.3V level

By bank

i.e. each bank can have a separate I/O voltage

For spi link, i imagine that an address manage a specific CS

well, the PIC can do DMA on the PMP IIRC

but there are more options I guess

Ok

It make the pic bsp very light because of the unique bus used

When pic will asked something to a device on the i2c bu, it will have to wait for answer a long time

And all is suspend

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…

or we can still feed the sensor data into the PIC via the FPGA

and of course, it can handle all the GPIO to the outside

we can do that if we like to

but note that the PIC has hardware support for I2C

which means that nothing has to wait for a completion or similar

But so we need more pins on connectors

What is the interest of an i2c bridge?

Why dont connect i2c from power board to pic i2c?

Ok

Or pre final choice :) ?

I think we should sleep over that

- replace the existing QFN32 iCE40 with a VQFP100 version on both sides of the beta board

- move the PIC32MZ on the shield

- all GPIO on the high speed side can be handled by the iCE40

- we can easily accomodate different microcontrollers with this interface

yes, something we plug onto the headers

the only drawback I see (which is not really a drawback IMHO) is that we need a shield to have the PIC32

Pic*

Or to think about a completly new architecture :D

See you tomorrow

cya and thanks!

off for a nap ... bbl