#apertus IRC Channel Logs

aombk: crop factor?

like a reel

and unless the plans have changed, the Beta won't record itself

but a friend found a super8 reel shot by his grandfather and we watched it and it was random 5-10 sec clips and it was very very good

aombk: could easily write a script to generate short compilations of clips once the data is transferred to computer

yeah

i am not part of the department that thinks of what enough people would like. i know i would like that feature

and some video formats can be joined together easily by concatenating the data

good morning

good morning

hey [1]Francky! how's going?

i'm good ans you ?

you might consider registering the nick with nickserv

it is currious that thiere is no "Francky" in the user list but when i try to get it the server says that this nickname is already in use...

i am sorry not to have a lot of time for woring and speaking about pic today

no problem, I have a lot of other stuff to do as well

what do you think about this :

for the first connector

for the second connector

has*

we need to check regarding pins and board space

The pmp bus can be adapt to pin and board place if needed

the I2C (for power board) is required anyway and makes perfect sense

I have some time

i.e. we cannot easily route too many CS into the middle or to the other side of the board for example

the other option would be to use some kind of SPI multiplexer in the middle

Wait a minute : what is the need about spi/sensors?

Let's put 2 spi bus, 1 in each side

The MAIN idea of spi bus is to have high speed devices connected on it

In my mind, 10dof and accelerometers need this speed

If we need other devices, we will be able to put them on i2c bus

ie : if a hacker want to add device, he will use i2c

yes, I agree, that's the plan

okay, good point

well, yeah, but for example, the connection to the center of the board is currently limited to 3 wires

But cannot you put 1 spi on top side and one on bottom?

and the bottom layer has the 3 wires (which are already very close to the bottom high speed routing)

but we got similar 3 wires from the other side

not really a good idea

as*

it could be a spi gpio expender, wich could control the CS of sensors ?!

something like that

it is too bad to add a chip to save 1 wire don't you find ?

the 2 sensors are needed ?

and why not put one of them on the pic shield ?

might be an option

I think the most flexible and still easily doable solution would be to put one of those iCE40 together with eeprom and I2C GPIO (for programming) into the middle area and use the left connection for the I2C and then utilize the right wires to distribute the data via the right side FPGA

as long as the total I/O count doesn't exceed 15 pins

so in the midlle, we put a ice40, linked with zynq by lvds

linked with who ?

dans ice40 will make the CS by I2C

and*

(via 3 wires)

or alternatively, as it also connects to the zynq

we also can multiplex the datastreem to accomodate a number of sensors in the middle

so pic will speak with big iCE40 in spi, big iCE40 speak with small iCE40 in lvds, and small iCE40 will speak with the sensor in spi ?

if you are not afraid that this kind of architecture can add a lot of problem of debugging/communication/synchro between all of the chip, why not

in fact the limiting things on the board is the space availaible to route wire between middle to right area

so that we can try different sensor combinations without rerouting

?

it is currently a solder-on place

yes

with proto board

we have all the relevant connections on the headers

yes, but all those functions are pretty independant

yes this (fpga) world seems to be wonderfull :)

the aim is that the microcontroller don't see the fpga and speak to sensors on spi and i2c as they were directly connected to it right ?

the disavatage of virtual device is the complexity of the fpga code

?

yes, only interfaces nned to be clear right now

i.e. both FPGAs work as serializer/deserializer chain

shoot

you*

you mean, how do I decide which FPGA to use?

how do you decide that this fpga can be good for this use ?

first, there is electrical specifications/requirements

you need two voltages, e.g. 1.8V and 3.3V, then you have to pick one which has at least two I/O banks with different voltages

finally the footprint, availability and price

it is always good if devices come in different peformance/macrocell ranges

"enought power" is little bit hard to imagine when you don't have any experience with it

ok thanks

I think you will have a lot of different devices to play with on the Beta :)

precisely

off for today

back now ...

yup

Just to discuss about Zynq perfs with the LVDS lanes in the HR banks (this discussion is related to the IF board, and the ways to reduce lanes nber between the IF board and the µZ)

and from what i can see in datasheet, the max perf throuput with OSERDES is 950Mb/s in ddr mode for -1 SG

the 950 is the "well defined" and "guaranteed over the full range" value

it's not that they zynq or the software keeps you from going beyond that limit

(just to give an example)

we will check how far we can go and we will probably do that on every camera individually

which in turn will give a BER

OK. but when you design your system, you want to guaranty a minimal bandwidth, and to do so youonly rely on the guaranted specifications. Afterward, if your system can go beyong, that's even better.

there is a lot of idle communication with the sensor

well, the cmv12k has 64+3 channels

two channels are "just" clock channels

data is "only" on 64 channels at most

still leaves us with 34 "data" channels at 950Mb/s

(not considering idle data)

which would then cover 95%

Yes, agree with the fact that even if we get the full sensor throughput, we have no huge pipe to store or broadcast it anymore! This was more about to feel the limit of the system,

and synchonously send the data on 34*2 channels at up to what? 800MHz

I think what might be important is to allow for fast memory access on the interface board, so that it has some kind of frame buffer to do summing or averaging on the sensor data when transmitting at full bandwidth

In fact, since there will be no huge broadcast pipe (maxi will maybe 6Gps with picoZ on a 6G SDI link), nor storage pipe, it would make sense to reduce the size of the "bus lanes" between the IF board and the µZ. It will free LVDS lanes for others stuff...

actually 13 on the high speed side :)

yep

ah? let's hear

Well this issue is not critical, but it will prevent you from doing the current monitoring on the supplies rails for both shield pcb otions...

And since the 4 sensing layout are strictly identical, they have the same issue...

hehe, that is intentional

as we get 3 boards from OSHpark anyway, I plan to build two versions for testing

you cut on the small stop mask?

if you look at the board, on the right side of the NW1 and right above R61 for example are the cut points

OK. so my mistake! Everything goes right.

after all, I didn't document it as feature

first I had two places for resistors (with only one populated) but that got too crowded just for a test

sounds good

Other question : What do you think about switching the stacking order of the power pcb and the beta pcb??

1-power pcb will be more centric, which will reduce the overall ground loops

well, we have two "big" power rails, one supplies the MicroZed, and the other everything else

another reason for the existing stackup is that we need some space for the plugin modules

for the PicoZed, we have to add an adapter board anyway to break out the MGTs

it is from the power perspective, yes

and another 5V rail which supplies (through regulators) the BetaBoard

switching beta board and power board would result in more power connections going down to supply beta board and MicroZed

and we would immediately lose 5+1.6mm from the plugin module space

or? no, 6.6mm

anyway tha power connections you are speaking about alreay exists and their number won't change by swapping power and beta. But what is right, is that you have to carry the "heavy 5V" for the µZ through the beta in this case...

my first design had all the sensor specific power supplies on the sensor board

first, almost all sensors specify a voltage range not single voltages

and secondly, power regulation uses up a lot of space and inevitably creates heat, which we do not want to have on the sensor board

So that's it for me today. I'll digest all that informations!! Thanks. bye

you'll see that it complicates things quite a lot

Hows progress?