#apertus IRC Channel Logs

off to bed now ... have a good one everyone!

morning everyone!

hello !

I need to start my laundry but should be back just before the meeting :)

as we have no clue about FPGAs :)

Hello fabrizio1

hi there

Hi Philip

hello fabrizio1!

hi!

Hi Dave, how are you?

Hi. Sorry for the delay in responding. Getting used to the web interface.

public is great

so since we already covered the basics via email lets jump right into the core of what we wanted to talk about

ok

that you plan to develop something similar would be a great synergy!

sounds god

currently we have no money though, just to be clear :)

We want to develop a low-cost Zynq module. We thought Axiom might serve as a possible application for it.

and we are prepating the EU grant which you might have seen on the website

if that works out we will have the money to cover such developments

So you're satisfied if it is $9.999?

I am guessing you mean <$10k

but at this stage its just guessing

for the 6k camera, you expect SD, usb3 and battery?

which high speed interface is not yet decided

SD card

i.e. micro SD holding the FPGA bitstream and OS

will be sent over SDI, hdmi, etc

How much buffering memory within the camera?

the storage module (SSDs) is an additional module, if we will be able to develop that in parallel to the camera depends mainly on the level of success of the crowd funding campaign

what is the bit rate needed for the DDR3 memory?

one image is 18.874,368 bytes

What does the FPGA do as the image streams by?

i.e. typically on a color sensor that will be:

- denoise, demosaic, color correction, optional subsampling

- image analysis (peaking, histogram)

Are these operations typically done within a single frame, or using image data across multiple frames?

devbisme_: probably depends on the application, but the typical use will require 2 frames max (most will work with 1 frame or less)

and delay between reading image data and outputting it over an interface should be kept minimal

Dave, the current Zeb board has a 533MHz DDR3 memory

what about a camera like the Red Epic? does it process one frame at the time?

nobody knows :)

they are all closed source :)

for monitoring purpose it can be somehow dirty and won't be at faster speed than what an sdi out would provide (max 30-50 fps), we could frame skip for example

for the normal case, the output would be at the same framerate as sensor imho, with the monitoring tool accepting different "standard" framerate, 24, 25, 30p

this is as much innards as anyone got to see so far I am afraid: http://cdn.cinescopophilia.com/wp-content/uploads/2012/01/RED-EPIC-X-Teardown-T7.jpg

I see

to say it otherwise, there are two very different use cases : sending live data to sdi, and recording

anyway, not sure where we are heading ...

we were thinking of having the SD card on the same PCB where the FPGA is. Is is bad?

So we have an FPGA taking 30 Gbps (?) from the sensor, putting it into a frame buffer and also sending that (after some processing) out through HDMI?

SD card on FPGA board is fine I would say

fabrizio1: you can't expect it to hold 4k raw data :)

plus a reset button

Our initial plans were a Zynq + LPDDR + SD card + USB 2.0 interface.

on a system on module pcb

We're trying to see what it would take to do that and if it can be cost effective.

in the first step, it will in 99% of all cases leave the camera via SDI

in a later step, we plan to develop a recording module

the recoding module will have an other FPGA?

yes

or it might utilize the MGT ports of 7015/7030

if that works bandwidth wise (we do not know yet)

devbisme_ with something like that : http://www.convergent-design.com/Products/Odyssey7.aspx

OK.

(there are cheaper options as well)

lens mount, sensor PCB, FPGA PCB and I/O PCB

there is also a battery part, but I leave that out for now

the I/O PCB can be adapted to the needs, e.g. provide the drivers for SDI, have some HDMI chip, generate SATA, etc

I created a collaborative google doc which we can use to summarize this discussion: https://docs.google.com/document/d/1B5hAG5BJu_7NUyJa21HbjewR95UuEjKAD48wP0NoIXU/edit#heading=h.rcqm5jdjd3rv

I added some datarates and image sensor specs already

what is the datarate of the data leaving the fpga module <- SDI is limited to 3Gbit/s, SATAIII is limited to 6Gbit/s

reload maybe?

I see

for the SDI output, I am guessing we need to use some SDI chipset?

right

fabrizio1 it seems sdi can be accomplished with the high speed transceivers of the 7015 or 7030

so in case of SDI, those will go to 4 SDI line drivers

another option to tackle the high speed recording is to use a much larger RAM and fill it up until full with images, then save them to recording media at a much lower speed <- this is how most(if not all) high speed cameras are doing it at the moment

so the Zynq is not really doing much

fabrizio1: there is a lot to do actually, and I fear that the 7015 might be too small to do it, but it should work for most things

understand

how many pins of the FPGA are actually needed for the SDI chip?

it requires only a tx pair from the MGT

A practical question, I have seen some posts about the modular design of the camera but I'd like to know the size of the PCB that needs to fit the FPGA and everything else

so a PCB could be in the 9x10cm range

but the enclosure design is still flexible

well Dave, I dont know you but I see lots of pins and lots of very bloody fast signals

we see the same, so we probably have a similar picture now :)

question, would you guys be happy with a 2Gb RAM

What is the interface from the sensor? Is it 64 bits of LVDS @ 600 MHz?

note that a preliminary check shows that the clg485 is just enough to get it done (no PL memory) and the 676pin packages of the 7030 should be sufficient for all needs

Yes, that's what I meant to say.

but we can do, with 32 for a simpler/cheaper version of the FPGA board

about priorities: 30 FPS are absolutely required, anything higher we can support is nice but not demanded (in case we need to decide some compromised with the design)

we can easily do that with even less LVDS, but we should be definitely fine with 32 for a 7015 board

http://www.xilinx.com/publications/prod_mktg/zynq7000/Zynq-7000-combined-product-table.pdf

fwiw, a list of sdi bandwidth on page 7 : http://www.ti.com/lit/an/snla114a/snla114a.pdf

yes, which one of the 4

philippej: that is quite old. Today we have 6G (uhd 16:9 4:2:2 as 4 FHD quadrants)

any I guess

guesst, if you have some docs, please add to the doc

note that we could potentially do 4x12G with the 7030 (with careful design), but personally I'd stop at 4x6G in this setup

you can get 4k over 3G, if you do not conform to those silly standards :)

nobody monitors on a set at higher resolution than hd 24p

(for example)

so the ARM will not be used?

we can always put a 7030 on the clg485 board, they are pin compatible

I see the 64 pins for the sensor and a few MGT for the SDI output.

(silly question) how many layers are you expecting this PCB to be?

back

What size is the BGA on the Zed? That uses 8 layers.

No way we'll route those internal pins with four layers.

especially if we talk about 700 pin

What are the 50 I/O pins for? Are they single-ended or differential (thus, 100 pins).

the 700 pin Zynq is $300

they get significantly cheaper after 500 (we were told)

what about the 7015 board then?

that would be clg485, already provide the MGT ports, and work as low end board for our purpose

sorry if it's a silly question, is it possible to find two 7xxx, one cheap and one expensive with the same pin count/layout that could be put on the same board ?

i do not think so

Zedboard is 400$ retail price btw and it sells pretty well

Zedboard is underpriced as all devkits (usually the cost of fpga on them is about the price of the whole board)

XC7Z020-1CLG484C Z

the 7020 is the zed chip

IMHO there is no point in creating a new zedboard

we are making a system on module board not a protoboard

good point

(just not open hardware)

guys the ping count scares me not only because of the pop price for the Zynq but also for the gazillion layers of this PCB

the 676 pin version I presume? because the 484 shouldn't be much different from the 400 (routing wise) and I doubt you want to go for anything less

agreed just 192 pins more in same grid

depends on where to route it :)

XC7Z030-1FBG484C would not fit the bill?

which one can do 8 MGT ?

nothing available under the WebPack license

fabrizio1: mostly because the 485 package wouldn't be different, but allow for the 7015 as well

(or PL memory, or whatever you want to do with those I/Os)

7045 is >$1k

so if I understand well there is not Zynq with less than 680 pins that would make you guys happy?

what I'm trying to say is, if you don't want to go for the 676 pin version, go for the 485 pin 7015 and design for the 485 pin 7030

another point is that it would be wasted efforts to not work on this together imho :-)

absolutely

It looks like a 485-pin version would serve?

doesn't mean that we won't plan for a 676pin version as well

i.e. interfaces to sensor board should reflect that in some way

as I said, more LVDS connections to the sensor board

hum.. the sensor board is?

sorry Bertl but I am a little lost

for example, the CMV12000

oh, how many lines has this chip? I thought it had only 64 lines

you havent got the HPC variant :)

we are using only 32LVDs for data, plus 3 more for clock/control

So we would be looking at a higher-density connector (more expensive) if we went to the 676-pin package?

We do not plan to use FMC connectors for the final axiom camera

164 pins each IIRC

inspired at freescales elevator ? :)

does the CCD board have more than 150 pins?

it shows the dual backplane concept with SODIMM connectors instead of PCIe

fabrizio1: as we already have 140 pins for LVDS + Control, yes, we will need a lot more to transfer power or a separate connector

another concept image uses two FCI connectors as Bertl mentioned: https://www.apertus.org/sites/default/files/open-modules-concept-front-V1.jpg

very cool

or maybe Arris

at least they should be scared a bit ;)

at least there are options for routing all those pins

the recording format would cinema dng : http://en.wikipedia.org/wiki/CinemaDNG

fabrizio1: note that you usually do not want lossy compression

OK

yes

we'll use the half bit technology :)

well I hope one day Tarantino will appreciate all this effort

Bertl: like the one in MLC chips right ? :)

(or short burst stored in ram, and slowly copied to disk)

Dave are you there? or you passed out thinking about all these pins to route?

philippej: 30Gb/s at 2Gbit memory is.. a 66 msec burstie :)

we do not plan to use less than 512MB :)

to at least 2049 MB :)

that is not significant. you have to do double/quarduple of what competition got to make it equal when you release

1GB is 10 Gb ... that is lots of RAM too

just kidding

fabrizio1: the microzed features 1GB already

i think the discussion about ram size is insignificant. you can be fine with 288mbit of memory given that it got the bandwidth

next step is about 32+ GB to make it worth, in between - no gain

Bertl: my I present a workable solution for all?

go ahead, we are always open to suggestions

plan mechaniclally for a big fpga, and 4 channel memory, but actually do the first design with the smaller one

that is for adjusting the module to various form factors and customizing i/o interfacing

so far sounds like we are planning to do

that will give you the max framerate you can do.

nothing new yet, let's hear your solution

I presume you are referring to the 'core' as routed layout, yes?

so they can form a dimm card from it, or a pcie card - on single board

well, this is how you can work with open designs

also the core could be replaced with the 7045 once software is freed or somebody got a license

only in the smaller footprint if available

but you cannot design a layout for a 676 pin package and use a 485 pin chip instead :)

and if you have the outer design

okay, that might be feasable, if you consider the additional I/O lines properly

so in summary I think we discussed the essential questions and defined requirements to a certain extent now

This discussion is in a Google doc somewhere?

her: https://docs.google.com/document/d/1B5hAG5BJu_7NUyJa21HbjewR95UuEjKAD48wP0NoIXU/edit#

yes that would be great

lets go for the 700 pin for now? Dave?

700 pin means a lot more layers.

we have working SDI :) as you may know

4:3

guesst: we haven't seen any open hard or software regarding SDI

Bertl: xilinx core is bound to a license?

Let's list a 450 pin option too

fabrizio1: why not plan for a 676pin version space wise (as guesst suggested) and go for the 485pin for now?

"but actually do the first design with the smaller one"

you can plan for 676+4 ram chips

I did not expect to talk about such a large ping count

devbisme_: also any high speed buffer memory on the PL side might be a big win

as guesst stated, about 64MB would suffice

sounds good

64 MB?

PL side, i.e. for the fabric

i thought of PL mem only :)

the cores need memory as well, not using the PS memory controller would be a waste

but it could be reduced to low bandwidth low pincount memory

Bye, guys. Thanks!

feel free to ask specific questions regarding axiom anytime here on the channel or via email

i will

bye!

what memory speed can be achieved on zynq?

Speed

(on the PS controller)

the PS has 32 or 16 bit width

arm/fpga should be easier

probably then a 4 chip design, 1+3 should do the full bandwidth when not used for same speed output, just caching, right?

gd nght