Current Server Time: 22:07 (Central Europe)

#apertus IRC Channel Logs

2014/02/05

Timezone: UTC


00:04
gwelkind
left the channel
00:08
gwelkind
joined the channel
00:59
gwelkind
left the channel
01:14
bootstrap
joined the channel
01:29
rexbron
left the channel
01:29
rexbron
joined the channel
01:29
rexbron
left the channel
01:29
rexbron
joined the channel
02:02
gwelkind
joined the channel
04:50
gwelkind
left the channel
06:42
Bertl
off to bed now ... have a good one everyone!
07:08
bootstrap
left the channel
07:52
philippej
joined the channel
08:47
jucar
joined the channel
09:12
fabrizio1
joined the channel
09:13
fabrizio1
Hi guys, just testing the client
09:14
fabrizio1
left the channel
12:15
rexbron_
joined the channel
12:16
rexbron
left the channel
12:38
rexbron_
left the channel
12:38
rexbron
joined the channel
12:38
rexbron
left the channel
12:38
rexbron
joined the channel
12:43
rexbron_
joined the channel
12:45
rexbron
left the channel
14:20
philippej
left the channel
15:50
philippej
joined the channel
16:34
philippej
left the channel
16:44
Bertl
morning everyone!
17:05
philippej
joined the channel
17:39
se6astian
joined the channel
17:40
se6astian
good evening
17:42
philippej
hello !
17:43
philippej
anything we need to prepare?
17:43
se6astian
I need to start my laundry but should be back just before the meeting :)
17:43
se6astian
prepare, not really I d say
17:43
se6astian
as we have no clue about FPGAs :)
17:43
philippej
:-)
17:50
fabrizio1
joined the channel
17:51
fabrizio1
hello guys
17:52
philippej
Hello fabrizio1
17:52
se6astian
h there
17:52
se6astian
hi there
17:53
fabrizio1
Hi Sebastian
17:53
fabrizio1
Hi Philip
17:54
fabrizio1
I guess we will need to wait a little for Dave
17:54
Bertl
hello fabrizio1!
17:56
fabrizio1
hi Bert
18:00
devbisme_
joined the channel
18:01
Bertl
welcome devbisme_!
18:02
se6astian
hi!
18:02
se6astian
I think we are complete then
18:03
fabrizio1
Hi Dave, how are you?
18:03
se6astian
is it OK for you if we continue here on the public channel or should we switch to a private one?
18:03
devbisme_
Hi. Sorry for the delay in responding. Getting used to the web interface.
18:04
devbisme_
Public is fine with me.
18:04
fabrizio1
public is great
18:04
se6astian
great!
18:05
se6astian
so since we already covered the basics via email lets jump right into the core of what we wanted to talk about
18:05
devbisme_
ok.
18:05
fabrizio1
ok
18:06
se6astian
We want to get closer to finalizing our technical specifications for our FPGA module in the Axiom camera
18:06
se6astian
that you plan to develop something similar would be a great synergy!
18:06
se6astian
we could split development tasks and production costs
18:07
fabrizio1
sounds god
18:07
fabrizio1
good
18:07
se6astian
currently we have no money though, just to be clear :)
18:07
fabrizio1
haha, no problem
18:07
devbisme_
We want to develop a low-cost Zynq module. We thought Axiom might serve as a possible application for it.
18:08
se6astian
but we are preparing a crowd funding campaign to presell a good amount of axiom cameras soon
18:08
se6astian
and we are prepating the EU grant which you might have seen on the website
18:09
devbisme_
What price range do you see for the Axiom?
18:09
se6astian
if that works out we will have the money to cover such developments
18:09
se6astian
our motto is "below 10.000$"
18:09
devbisme_
So you're satisfied if it is $9.999?
18:10
se6astian
no :)
18:10
fabrizio1
I am guessing you mean <$10k
18:11
se6astian
hopefully we will be able to reach a retail range of 6000-7000
18:11
se6astian
but at this stage its just guessing
18:11
devbisme_
OK, I just wanted to see where your expectations were.
18:12
fabrizio1
for the 6k camera, you expect SD, usb3 and battery?
18:13
se6astian
battery will be third party
18:13
se6astian
which high speed interface is not yet decided
18:13
Bertl
SD as in secure digital? if so, just for the software
18:13
fabrizio1
SD card
18:13
se6astian
micro sd card to hold the camera firmware yes
18:13
Bertl
i.e. micro SD holding the FPGA bitstream and OS
18:14
fabrizio1
and the actual video?
18:14
Bertl
will be sent over SDI, hdmi, etc
18:14
fabrizio1
oh, there is an HDMI out?
18:14
devbisme_
How much buffering memory within the camera?
18:15
Bertl
we currently work with 512MB of DDR3 memory
18:15
se6astian
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
18:15
Bertl
we would prefer dedicated PL side memory with about 64M+ for buffering
18:15
fabrizio1
what is the bit rate needed for the DDR3 memory?
18:16
se6astian
the sensor has 4096x3072 pixels and can provide up to 150 frames per second at 12 bit
18:16
se6astian
one image is 18.874,368 bytes
18:16
Bertl
we produce about 30Gbit/s at the highest framerate
18:17
devbisme_
What does the FPGA do as the image streams by?
18:18
Bertl
whatever is necessary to get a proper image :)
18:18
Bertl
i.e. typically on a color sensor that will be:
18:18
se6astian
normal framerates like 25 FPS will result in moderate datarates of around 450 Mbytes/s
18:19
Bertl
- denoise, demosaic, color correction, optional subsampling
18:19
fabrizio1
not sure u have this info but what is the current DDR3 memory clock?
18:19
Bertl
- image analysis (peaking, histogram)
18:20
philippej
image is then sent to sdi out to an external recorder, and at a later stage, a built in recorder will be developed
18:20
devbisme_
Are these operations typically done within a single frame, or using image data across multiple frames?
18:20
Bertl
we currently work with the zedboard and we are almost at the bandwidth limit of the onboard DDR3
18:21
Bertl
devbisme_: probably depends on the application, but the typical use will require 2 frames max (most will work with 1 frame or less)
18:21
philippej
would it be possible to do all the processing without memory buffer at all ?
18:21
se6astian
and delay between reading image data and outputting it over an interface should be kept minimal
18:22
Bertl
philippej: yes, to some degree, but it would require synchronization of the output speed with the sensor
18:22
fabrizio1
Dave, the current Zeb board has a 533MHz DDR3 memory
18:23
philippej
I was already wondering about that, for example a complex debayering algorithm might need info from several lines behind, but never a complete frame behind
18:24
fabrizio1
what about a camera like the Red Epic? does it process one frame at the time?
18:24
Bertl
philippej: for example, HDMI out (think viewfinder) doesn't work with the high data rates of the sensor
18:24
se6astian
nobody knows :)
18:24
fabrizio1
Black Magic?
18:24
se6astian
they are all closed source :)
18:25
fabrizio1
nobody has ever looked inside to see how much memory there is?
18:25
philippej
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
18:26
Bertl
you still need to buffer at least a frame though
18:26
philippej
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
18:26
Bertl
note: the sensor sends the data at the highest speed regardless of the exposure time
18:27
se6astian
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
18:27
Bertl
fabrizio1: I'm sure somebody did, but none of us
18:28
fabrizio1
I see
18:28
Bertl
so on the image I see a number of 'memory like' chips
18:28
philippej
to say it otherwise, there are two very different use cases : sending live data to sdi, and recording
18:29
Bertl
they are not so different from the memory/buffer PoV
18:29
Bertl
anyway, not sure where we are heading ...
18:30
se6astian
yes we are drifting off topic a bit :)
18:30
fabrizio1
we were thinking of having the SD card on the same PCB where the FPGA is. Is is bad?
18:30
Bertl
devbisme_: what kind of hardware do you have in mind?
18:30
devbisme_
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?
18:30
se6astian
so to summarize: we need high bandwidth :)
18:31
se6astian
SD card on FPGA board is fine I would say
18:31
Bertl
fabrizio1: as I said, SD card is nice (micro sd) to hold the firmware/OS
18:31
Bertl
fabrizio1: you can't expect it to hold 4k raw data :)
18:31
se6astian
we also had in mind to put a ethernet and UART/JTAG mini usb connetor on the same board
18:31
se6astian
plus a reset button
18:31
philippej
Maybe fabrizio1 and devbisme_ you can talk a bit about the future board you have in mind ?
18:32
devbisme_
Our initial plans were a Zynq + LPDDR + SD card + USB 2.0 interface.
18:33
devbisme_
Obviously, that wouldn't meet your needs.
18:33
fabrizio1
on a system on module pcb
18:33
Bertl
hehe, right
18:33
devbisme_
We're trying to see what it would take to do that and if it can be cost effective.
18:33
fabrizio1
Hold on a second, I do not understand where is the final raw movie going to be stored when not leaving the camera
18:34
Bertl
in the first step, it will in 99% of all cases leave the camera via SDI
18:34
fabrizio1
I see
18:34
Bertl
in a later step, we plan to develop a recording module
18:34
Bertl
which will store the data on SSD raid
18:34
fabrizio1
the recoding module will have an other FPGA?
18:35
Bertl
(either SATA or custom solution)
18:35
Bertl
yes
18:35
fabrizio1
I see
18:35
Bertl
or it might utilize the MGT ports of 7015/7030
18:35
devbisme_
So how is the camera used if there is currently no storage unit?
18:35
Bertl
if that works bandwidth wise (we do not know yet)
18:35
Bertl
external recorder, PC card, etc
18:36
philippej
devbisme_ with something like that : http://www.convergent-design.com/Products/Odyssey7.aspx
18:36
philippej
(for cinema use at least)
18:36
devbisme_
OK.
18:36
Bertl
one idea was to design the zynq board in such a way, that it can function as PCIe card (with a carrier)
18:36
philippej
(there are cheaper options as well)
18:36
Bertl
so basically think of the camera as the following parts:
18:37
Bertl
lens mount, sensor PCB, FPGA PCB and I/O PCB
18:37
fabrizio1
what is the datarate of the data leaving the fpga module?
18:37
Bertl
there is also a battery part, but I leave that out for now
18:37
Bertl
the FPGA PCB receives and processes the data from the sensor PCB and streams it out via MGT ports
18:38
Bertl
the I/O PCB can be adapted to the needs, e.g. provide the drivers for SDI, have some HDMI chip, generate SATA, etc
18:39
Bertl
the FPGA board could also function as the receiver (different firmware) for a PCIe card
18:39
se6astian
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
18:39
devbisme_
Excuse me for a sec. Someone at door.
18:39
se6astian
I added some datarates and image sensor specs already
18:40
Bertl
hmm, ends after the second line here?
18:40
se6astian
what is the datarate of the data leaving the fpga module <- SDI is limited to 3Gbit/s, SATAIII is limited to 6Gbit/s
18:40
se6astian
hmm, strange
18:40
se6astian
reload maybe?
18:41
Bertl
tried that, no change
18:41
fabrizio1
I see
18:41
se6astian
what is the datarate of the data leaving the fpga module <- other options: SFP+ (10Gbit/s), USB3 (5Gbit/s)
18:41
fabrizio1
for the SDI output, I am guessing we need to use some SDI chipset?
18:41
se6astian
none of that solutions can cover the full speed the sensor could provide
18:41
fabrizio1
right
18:42
se6astian
but there might be a soltuin in the future so we do not want to limit ourselves artificially already
18:42
philippej
fabrizio1 it seems sdi can be accomplished with the high speed transceivers of the 7015 or 7030
18:42
Bertl
fabrizio1: we plan to utilize the 4 multi gigabit tranceivers present in 7015 and 7030 to transfer the output data
18:43
Bertl
so in case of SDI, those will go to 4 SDI line drivers
18:43
philippej
the IO board could provide up to 4 sdi out for instance, and the remaining lines would be used (in the future) to connect to the recording module
18:43
se6astian
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
18:44
fabrizio1
I see
18:44
fabrizio1
so the Zynq is not really doing much
18:44
se6astian
for the SDI output, I am guessing we need to use some SDI chipset? <- a cable driver or interface chip connected to one of the 4 multi gigabit tranceivers (as Bertl mentioned)
18:45
Bertl
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
18:45
philippej
as I see it, the key is to have fast ram (if needed at all), and multigigabit transceivers (7015 or 7030)
18:45
fabrizio1
understand
18:46
devbisme_
What is the most demanding task for the FPGA that makes the 7015 too small?
18:46
fabrizio1
how many pins of the FPGA are actually needed for the SDI chip?
18:47
Bertl
depends on what chip and what solution, in the optimal case only a few, including the MGT ports
18:47
guesst
it requires only a tx pair from the MGT
18:47
Bertl
correct
18:49
fabrizio1
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
18:49
se6astian
currently the size of the camera enclosure is 10x11cm (looking from the front)
18:50
se6astian
so a PCB could be in the 9x10cm range
18:50
fabrizio1
I see
18:50
se6astian
but the enclosure design is still flexible
18:50
se6astian
if we see we will not fit the parts/PCBs in that boundaries we can easily increase the size
18:51
fabrizio1
well Dave, I dont know you but I see lots of pins and lots of very bloody fast signals
18:51
devbisme_
I agree.
18:52
Bertl
we see the same, so we probably have a similar picture now :)
18:52
fabrizio1
haha
18:52
rexbron_
left the channel
18:52
rexbron
joined the channel
18:52
rexbron
left the channel
18:52
rexbron
joined the channel
18:52
fabrizio1
question, would you guys be happy with a 2Gb RAM
18:52
fabrizio1
?
18:52
devbisme_
What is the interface from the sensor? Is it 64 bits of LVDS @ 600 MHz?
18:53
se6astian
yes
18:53
Bertl
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
18:53
se6astian
ah sorry, 64 lines
18:53
devbisme_
Yes, that's what I meant to say.
18:53
Bertl
yes, the full sensor connection is 64 LVDS lanes at 600MHz (300MHz ddr)
18:54
Bertl
but we can do, with 32 for a simpler/cheaper version of the FPGA board
18:54
Bertl
s/do, with/do with/
18:54
se6astian
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)
18:54
se6astian
*compromises
18:55
Bertl
we can easily do that with even less LVDS, but we should be definitely fine with 32 for a 7015 board
18:55
fabrizio1
could you send me the Zynq module you are happy with?
18:55
se6astian
http://www.xilinx.com/publications/prod_mktg/zynq7000/Zynq-7000-combined-product-table.pdf
18:56
Bertl
fabrizio1: i.e. a description for a 7015/7030 design, yes?
18:56
philippej
fwiw, a list of sdi bandwidth on page 7 : http://www.ti.com/lit/an/snla114a/snla114a.pdf
18:57
Bertl
yes, unfortunately it doesn't cover any 4k modes
18:57
fabrizio1
yes, which one of the 4
18:57
fabrizio1
?
18:58
guesst
philippej: that is quite old. Today we have 6G (uhd 16:9 4:2:2 as 4 FHD quadrants)
18:58
se6astian
brb, laundry is ready :)
18:58
fabrizio1
any I guess
18:58
guesst
and we have checked out 12G.. but that is quite short range (<25m)
18:58
philippej
guesst, if you have some docs, please add to the doc
18:59
guesst
no docs, 6G should be already at SMPTE
18:59
Bertl
note that we could potentially do 4x12G with the 7030 (with careful design), but personally I'd stop at 4x6G in this setup
19:00
Bertl
should still be more than enough to get the data out in 90% of all cases
19:00
guesst
you can get 4k over 3G, if you do not conform to those silly standards :)
19:01
philippej
the story is very different when you consider talking to to the real world (existing equipment people own trough sdi), and what we can do at a later stage with our recorder
19:02
philippej
nobody monitors on a set at higher resolution than hd 24p
19:02
fabrizio1
this one could be ok: http://www.digikey.com/product-detail/en/XC7Z030-1FBG484I/122-1893-ND/3925766
19:02
philippej
(for example)
19:03
Bertl
this is the 484 BGA, when we pick the 7030 (or for the 7030 FPGA board) we should target the 676pin version
19:03
fabrizio1
so the ARM will not be used?
19:03
fabrizio1
676 pins.... that is lots of pins
19:03
Bertl
we can always put a 7030 on the clg485 board, they are pin compatible
19:04
devbisme_
What are all the extra pins for?
19:04
devbisme_
I see the 64 pins for the sensor and a few MGT for the SDI output.
19:04
Bertl
mostly supply as usual, but also 50 I/O pins
19:04
fabrizio1
(silly question) how many layers are you expecting this PCB to be?
19:05
Bertl
at least 6 I guess, more like 8 or 10 probably
19:05
se6astian
back
19:05
fabrizio1
hum.. that is lots of layers
19:05
devbisme_
What size is the BGA on the Zed? That uses 8 layers.
19:05
Bertl
well, if you can do it realiably with 4, I'm fine with that :)
19:06
devbisme_
No way we'll route those internal pins with four layers.
19:06
fabrizio1
not even with 6
19:06
fabrizio1
especially if we talk about 700 pin
19:07
Bertl
the zedboard is a clg484
19:07
devbisme_
What are the 50 I/O pins for? Are they single-ended or differential (thus, 100 pins).
19:08
Bertl
in our case, they would either be for additional sensor LVDS or for PL memory, depending on the 7015 PCB
19:09
fabrizio1
the 700 pin Zynq is $300
19:09
Bertl
between 300 and 400 USD in the single piece price range
19:10
Bertl
they get significantly cheaper after 500 (we were told)
19:10
fabrizio1
guys the problem is that I and Dave would be interested in making and selling this fpga board to other people too. But with a $340 FPGA, I am not sure how many people would be interested. Dave what do you think?
19:11
Bertl
what about the 7015 board then?
19:11
devbisme_
There is a market at the high end, but I'm not sure we can access it.
19:12
Bertl
that would be clg485, already provide the MGT ports, and work as low end board for our purpose
19:12
fabrizio1
$150
19:12
philippej
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 ?
19:13
fabrizio1
not silly at all
19:13
guesst
i do not think so
19:13
Bertl
yes, the 7030 in clg484 works on the clg485
19:13
se6astian
Zedboard is 400$ retail price btw and it sells pretty well
19:13
fabrizio1
but if you guys are talkin about 700 pins...
19:14
guesst
Zedboard is underpriced as all devkits (usually the cost of fpga on them is about the price of the whole board)
19:14
Bertl
from xilinx DS190: The Z-7015 device in the CLG485 package and the Z-7030 device in the SBG485 package are pin-to-pin compatible
19:14
fabrizio1
XC7Z020-1CLG484C Z
19:15
devbisme_
No MGT on that one.
19:15
Bertl
the 7020 is the zed chip
19:16
fabrizio1
yeah at 485 pins
19:16
Bertl
IMHO there is no point in creating a new zedboard
19:16
Bertl
there are more than enough 7010/7020 boards out there
19:16
fabrizio1
we are making a system on module board not a protoboard
19:16
Bertl
the MGTs are new in the 7015, so that would be an interesting system
19:16
fabrizio1
good point
19:17
Bertl
fabrizio1: there are many 7010/7020 boards out there as well
19:17
Bertl
(just not open hardware)
19:17
fabrizio1
good point Bertl
19:17
fabrizio1
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
19:18
devbisme_
It would be challenging.
19:19
Bertl
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
19:20
Bertl
the 225 package has only 54 PL I/Os, so not much one can do with that
19:20
se6astian
agreed just 192 pins more in same grid
19:20
fabrizio1
ahaha well yes routing 700 pins is something I would never do
19:20
guesst
depends on where to route it :)
19:21
fabrizio1
:)
19:21
fabrizio1
XC7Z030-1FBG484C would not fit the bill?
19:21
Bertl
would be an unfortunate choice
19:21
guesst
which one can do 8 MGT ?
19:21
fabrizio1
I see
19:21
Bertl
nothing available under the WebPack license
19:21
devbisme_
7045
19:22
Bertl
fabrizio1: mostly because the 485 package wouldn't be different, but allow for the 7015 as well
19:22
Bertl
fabrizio1: but it wouldn't give the benefit of having more sensor LVDS available
19:23
Bertl
(or PL memory, or whatever you want to do with those I/Os)
19:23
fabrizio1
I am afraid it wont be easy to pull those pin out of the board
19:24
fabrizio1
7045 is >$1k
19:26
guesst
so thats out even for me :)
19:26
fabrizio1
so if I understand well there is not Zynq with less than 680 pins that would make you guys happy?
19:26
devbisme_
So is it the Axiom position that 676 pins is a necessity at this point?
19:26
Bertl
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
19:27
Bertl
in this case it can be used with the 7015 _and_ 7030, allowing for low price/high performance versions
19:27
philippej
another point is that it would be wasted efforts to not work on this together imho :-)
19:27
Bertl
and if designed properly, we can also use it as low pin count version for the axiom
19:27
fabrizio1
absolutely
19:28
fabrizio1
so what's the answer to Dave's question?
19:28
devbisme_
It looks like a 485-pin version would serve?
19:28
Bertl
the 676 pin question? No at this point it isn't a necessity
19:29
Bertl
doesn't mean that we won't plan for a 676pin version as well
19:29
fabrizio1
what advantage would u get from the 676?
19:29
Bertl
i.e. interfaces to sensor board should reflect that in some way
19:29
philippej
and let's not forget that we can at an higher level (carrier board / connectors) allow for further upgrades with higher pincounts
19:29
Bertl
as I said, more LVDS connections to the sensor board
19:30
Bertl
we probably can
19:30
fabrizio1
hum.. the sensor board is?
19:30
Bertl
't do 64LVDs on the 485 package
19:30
fabrizio1
sorry Bertl but I am a little lost
19:30
Bertl
the board connecting to the FPGA board, and carrying the sensor chip :)
19:31
Bertl
for example, the CMV12000
19:31
devbisme_
Aren't you using 64 lanes with the Zed board?
19:31
fabrizio1
oh, how many lines has this chip? I thought it had only 64 lines
19:31
Bertl
devbisme_: no, the FMC doesn't allow for that many
19:32
guesst
you havent got the HPC variant :)
19:32
se6astian
LVDS are pairs around 144 lines to the image sensor in total
19:32
Bertl
we are using only 32LVDs for data, plus 3 more for clock/control
19:32
Bertl
guesst: correct, the zedboard doesn't feature a HPC variant
19:33
devbisme_
So we would be looking at a higher-density connector (more expensive) if we went to the 676-pin package?
19:33
guesst
i can see here an option how can be everybody happy to the max given the constraints involved
19:34
se6astian
We do not plan to use FMC connectors for the final axiom camera
19:34
se6astian
rather we are thinking about 2x PCIe connectors
19:34
se6astian
164 pins each IIRC
19:35
se6astian
and a dual backplane to connect the boards with the image sensor and the FPGA together in a stack
19:35
guesst
inspired at freescales elevator ? :)
19:36
Bertl
or just simple FCI connectors with 150/200 pins each
19:37
fabrizio1
does the CCD board have more than 150 pins?
19:37
se6astian
Added an old concept image to google doc: https://docs.google.com/document/d/1B5hAG5BJu_7NUyJa21HbjewR95UuEjKAD48wP0NoIXU/edit#heading=h.9ovdvybs2w0j
19:37
se6astian
it shows the dual backplane concept with SODIMM connectors instead of PCIe
19:37
fabrizio1
I see
19:38
Bertl
fabrizio1: as we already have 140 pins for LVDS + Control, yes, we will need a lot more to transfer power or a separate connector
19:38
Bertl
and even with power on a separate connector, you will require shielding, so 200pin is probably the minimum
19:39
se6astian
another concept image uses two FCI connectors as Bertl mentioned: https://www.apertus.org/sites/default/files/open-modules-concept-front-V1.jpg
19:39
Bertl
and it is a CMOS sensor in our case :)
19:39
fabrizio1
very cool
19:39
fabrizio1
Red will definitely try to buy us !
19:40
fabrizio1
or maybe Arris
19:40
philippej
here with lateral connectors only for sensor front-end <-> fpga connection : http://public.philippejadin.be/axiom.png
19:41
se6astian
at least they should be scared a bit ;)
19:41
fabrizio1
is it impossible to think of doing the image compression on the same FPGA?
19:41
philippej
at least there are options for routing all those pins
19:42
se6astian
image compression would be one of the things on the list of things that are "nice to have" in the future but not essential in the first stage
19:42
philippej
the recording format would cinema dng : http://en.wikipedia.org/wiki/CinemaDNG
19:43
philippej
(be)
19:43
Bertl
fabrizio1: note that you usually do not want lossy compression
19:43
philippej
which is basically raw sensor data in a nicer wrapper
19:44
fabrizio1
OK
19:44
fabrizio1
so same datarate? 30Gbps?
19:45
se6astian
yes
19:46
guesst
when your hardware offers at most 4x 6G links, you might have a little dificulty storing 30G
19:47
Bertl
we'll use the half bit technology :)
19:47
fabrizio1
I see
19:47
fabrizio1
well I hope one day Tarantino will appreciate all this effort
19:47
philippej
the practical limit for now would be two fast ssd's together. Beside that, it won't be that useful imho
19:47
guesst
Bertl: like the one in MLC chips right ? :)
19:48
Bertl
yes
19:48
philippej
(or short burst stored in ram, and slowly copied to disk)
19:48
philippej
(which is an even more specific use case)
19:49
fabrizio1
Dave are you there? or you passed out thinking about all these pins to route?
19:49
devbisme_
Just listening.
19:49
guesst
philippej: 30Gb/s at 2Gbit memory is.. a 66 msec burstie :)
19:50
guesst
can anybody of you be a little bit more real
19:50
Bertl
we do not plan to use less than 512MB :)
19:50
se6astian
yes, if we decide to go the burst route we would need to significantly increase the amount of RAM
19:50
se6astian
to at least 2049 MB :)
19:51
fabrizio1
that is lots of RAM
19:51
guesst
that is not significant. you have to do double/quarduple of what competition got to make it equal when you release
19:51
Bertl
fabrizio1: don't worry, 512MB seems to be working fine, 1GB would be nice to have
19:51
philippe_
joined the channel
19:51
philippe_
left the channel
19:52
fabrizio1
1GB is 10 Gb ... that is lots of RAM too
19:52
Bertl
guesst: we'll quadruple everything every two years
19:52
philippe_
joined the channel
19:52
fabrizio1
I see that there is a 900 pin FPGA
19:52
fabrizio1
just kidding
19:52
se6astian
:)
19:52
Bertl
fabrizio1: the microzed features 1GB already
19:53
Bertl
that's two tiny DDR chips
19:53
guesst
i think the discussion about ram size is insignificant. you can be fine with 288mbit of memory given that it got the bandwidth
19:54
fabrizio1
well the 600 MHz RAM worries me as well
19:54
guesst
next step is about 32+ GB to make it worth, in between - no gain
19:54
Bertl
lets say 432mbit, but yes, I agree, for the PL side, this is probably the essential miminum
19:55
guesst
Bertl: my I present a workable solution for all?
19:55
devbisme_
Go ahead!
19:55
Bertl
go ahead, we are always open to suggestions
19:55
guesst
so listen
19:56
guesst
plan mechaniclally for a big fpga, and 4 channel memory, but actually do the first design with the smaller one
19:56
guesst
also a mechanical reserved space should be present at sides of this fpga/ram core
19:56
guesst
that is for adjusting the module to various form factors and customizing i/o interfacing
19:56
guesst
as for axiom, choose the max zynq you can code in webpack
19:56
Bertl
so far sounds like we are planning to do
19:57
guesst
and plan the bandwidth to match the equality of sensor interface vs. ram (vs. gtp out)
19:57
guesst
that will give you the max framerate you can do.
19:57
guesst
the guys from hardware will have a core which can be reused for other projects - when they customize the pcb
19:58
Bertl
nothing new yet, let's hear your solution
19:58
guesst
e.g. add whatever plugs or interfaces it needs
19:59
Bertl
I presume you are referring to the 'core' as routed layout, yes?
19:59
guesst
yes.
19:59
guesst
so they can form a dimm card from it, or a pcie card - on single board
20:00
guesst
or just your apertus interconnect system
20:00
Bertl
well, this is how you can work with open designs
20:00
Bertl
no need to build everything from scratch there
20:00
guesst
also the core could be replaced with the 7045 once software is freed or somebody got a license
20:01
guesst
there is currently no high performance core (like a 4x 16bit ddr3)
20:01
Bertl
only in the smaller footprint if available
20:02
Bertl
but yes, there is no reason not to utilize a 7045 once it is covered by the WebPack
20:02
Bertl
but you cannot design a layout for a 676 pin package and use a 485 pin chip instead :)
20:03
guesst
you can reserve space for it
20:03
guesst
and if you have the outer design
20:03
guesst
you just replace the center of the board.. without doing a complete modification
20:04
Bertl
okay, that might be feasable, if you consider the additional I/O lines properly
20:04
guesst
also doing a fixed core (group of chips) would mean, that when one uses that, it could be populated at those designers... with the rest done by hand on each custom layout
20:04
se6astian
so in summary I think we discussed the essential questions and defined requirements to a certain extent now
20:04
se6astian
are there any further questions?
20:05
devbisme_
This discussion is in a Google doc somewhere?
20:05
se6astian
or should we conclude the continue via email/google doc after this first successful get-together
20:05
se6astian
her: https://docs.google.com/document/d/1B5hAG5BJu_7NUyJa21HbjewR95UuEjKAD48wP0NoIXU/edit#
20:06
fabrizio1
please lets continue in the next days writing down all the components we like
20:06
se6astian
yes that would be great
20:06
guesst
se6astian: what is the point of always calculating with full aperture ? anamorphic is expensive and not that used these days
20:06
fabrizio1
lets go for the 700 pin for now? Dave?
20:06
se6astian
btw do you have any experience/preference with the interfaces: USB3, SATA, SDI or SFP+ ?
20:07
devbisme_
700 pin means a lot more layers.
20:07
philippej
left the channel
20:07
guesst
we have working SDI :) as you may know
20:07
se6astian
guesst, what do you mean with "full aperture"?
20:07
guesst
4:3
20:07
se6astian
aperture is a lens element
20:07
Bertl
guesst: we haven't seen any open hard or software regarding SDI
20:07
fabrizio1
I know....
20:08
guesst
Bertl: xilinx core is bound to a license?
20:08
fabrizio1
SATA would be good i think
20:08
fabrizio1
Let's list a 450 pin option too
20:09
fabrizio1
guys it was great to talk to you
20:09
Bertl
fabrizio1: why not plan for a 676pin version space wise (as guesst suggested) and go for the 485pin for now?
20:09
guesst
Bertl: that is what i suggested
20:09
guesst
"but actually do the first design with the smaller one"
20:09
devbisme_
Fabrizio, we should go through the discussion, pull out the agreed-upon specs and then run two versions using 485 and 676 and see what the cost implications are.
20:09
guesst
you can plan for 676+4 ram chips
20:10
guesst
and then see what you can do with the smaller fpga
20:10
fabrizio1
I did not expect to talk about such a large ping count
20:10
guesst
i am worried about ram channel count when you use a massive amount of pins for sensor (unnecesarily)
20:10
Bertl
devbisme_: also any high speed buffer memory on the PL side might be a big win
20:11
fabrizio1
lets all try to come up with actually components
20:11
Bertl
as guesst stated, about 64MB would suffice
20:11
fabrizio1
on a shared document
20:11
Bertl
sounds good
20:11
se6astian
great
20:11
fabrizio1
64 MB?
20:11
se6astian
please bookmark the google doc: https://docs.google.com/document/d/1B5hAG5BJu_7NUyJa21HbjewR95UuEjKAD48wP0NoIXU/edit#
20:11
Bertl
PL side, i.e. for the fabric
20:11
se6astian
it can freely be access and edited by anyone who has the link
20:12
guesst
i thought of PL mem only :)
20:12
se6astian
*accessed
20:12
Bertl
the cores need memory as well, not using the PS memory controller would be a waste
20:12
fabrizio1
ok, give us sometime to do some reading on what it takes to route 600 pins
20:13
Bertl
but it could be reduced to low bandwidth low pincount memory
20:13
se6astian
sure, many thanks for your time and being here
20:13
devbisme_
Bye, guys. Thanks!
20:13
fabrizio1
buy guys
20:13
Bertl
feel free to ask specific questions regarding axiom anytime here on the channel or via email
20:13
fabrizio1
ok i sill
20:14
fabrizio1
i will
20:15
fabrizio1
buy guys
20:15
fabrizio1
left the channel
20:16
philippe_
bye!
20:16
se6astian
bye!
20:16
devbisme_
left the channel
20:18
guesst
what memory speed can be achieved on zynq?
20:28
philippe_
left the channel
20:34
Bertl
Speed
20:34
Bertl
of up to 1333 Mb/s for DDR3 is supported.
20:35
Bertl
(on the PS controller)
20:36
Bertl
the PL could go up to 1866Mb/s DDR3 on higher grade zynq
20:36
Bertl
the PS has 32 or 16 bit width
20:44
guesst
i hate these ps/pl :)
20:44
guesst
arm/fpga should be easier
20:47
philippej
joined the channel
20:47
guesst
probably then a 4 chip design, 1+3 should do the full bandwidth when not used for same speed output, just caching, right?
20:48
guesst
by chip i mean 16bit, never saw a wider one
20:49
philippej
left the channel
20:54
philippej
joined the channel
20:55
FergusL
left the channel
21:31
philippej
left the channel
21:37
FergusL
joined the channel
22:47
se6astian
tme f bd
22:47
se6astian
gd nght
22:47
se6astian
damn keyboard
22:48
se6astian
left the channel