#apertus IRC Channel Logs

Bertl : This is a link to a paper I found online for inter-fpga communication and error correction. I'd like to know if this is suitable for our purposes. https://drive.google.com/open?id=1-9r3mRJ8aLwDKwKp5StMqOcKi8VaH4DG

morning folks!

@paper: well, they use a 33+ signal bus, so that's not an option for us, besides that it seems to be designed as a multi drop system or so and we only have/want a master/slave connection

ymc98: you still around?

Bertl : I have seen the logs. I also would like to know the tool required. I am familiar Vivado. I don't know the design tools required for MachXO2.

okay, so Vivado for Zynq and Diamond for the MachXO2

I would also like to know the data specifications that Zynq outputs

yes, we should have a talk about the protocol and how to make it efficient

yes, 8/10 encoding is a good idea for the physical layer transport

i.e. what happens when nothing needs to be transported

Is this a good way to take care of idle states?

we have a common clock between Zynq and MachXO2 so it shouldn't be a problem with synchronization when pausing the data flow

IMHO first step is to get a reliable communication working

Absolutely

Before the first evaluation.

both Vivado and Diamond do static timing analysis during implementation so that shouldn't be a problem

anyway 8b10b for me seems unnecessary - there is no need to ac coupling, nor clock recovery

above the 1.25G for regular ioserdes/lvds?

that AC spec is not related to 8b10b..

that is rather a solution for interference/coupling over long cables, there is no tmds for short/internal busses

we'll see

(sort of mipi way - sample on edges, with discontinuous clock)

we have a common clock but it is not sure how well the LVDS channels align to that

but stopping the clock is not a good idea

if the bitrate is low enough, it can be captured directly (we do on A7 up to 600mbit ~ 300mhz ddr)

because it is common for both MachXO2 s

yeah, having low transition idle symbols is definitely one option

probably up to 300MHz but I don't know (the datasheet should have some clues)

off for now ... bbl

BAndiT1983: hi :)

been caught up in a few things, nothing much, how's it going?

*adjustments

any new progress on raw container?

I am currently looking at the two ways g3gg0 told me I could take

which ways? could read the logs, but don't want to distract myself from daemon

that's what I am auditing right now..

which is what we have

to change MLVFS or to change the bit encoding to canon

hmm

HDR settings?

remember the meeting?

AXIOM camera have...

(maybe I could be wrong)...

so, is that mechanism for single frame shoot? or can be even used in videos... I am wondering

http://www.cmosis.com/news/press_releases/cmosis_shows_upgraded_cmv12000_offering_300_fps_at_full_resolution

have a great night ahead, BAndiT1983 :)

ah, TofuLynx is also here

what's the latest news?

I wanted to talk with you regarding that git practise with development branches and also regarding the task I finished

basically, if I understood correctly, I will create a new branch for every feature I wish to implement, and then I delete the branch when the feature is implemented and fully functional and mergend onto master.

yeah, but the link you gave goes more to the extreme

i know, the link was an example

for our case the dev branch is more suited?

from my experience, yes

as in the future the master branch has to be stable, so we will focus on dev branch and feature branches

Did you check the unit test?

just looked through it quickly, as i was at work, when i saw your PR

I have some questions regarding the catch

it executes all the tests it finds

I had some problems with it, as I was getting segfault with pre processor

also segfaults are a problem, because of some whacky implementations there

have you tried to activate travis ci for your repo yet?

alright, now you should try to activate it for dev branch, so we are on the same setup, more or less

roger, should I update the dev branch?

what do you mean by which way?

ah xD put it on par with master branch

so, off for a bit to get some stuff

ok :)

BAndiT1983:

what would you prefer to do next?

I think finishing the debayer class

I meant the bilinear debayer

what is general functionality?

correct debayering

Hmm, what do you suggest to do?

what about trello board?

ok, i see base debayer class, not a bad idea, but needs some investigation

as they should take care of it, depending on the needs of the related format

or to be precise, later they would request the buffer from static allocator and just assign the pointer to ocimage

but this is also continuous process, tests will be added in the course of gsoc

I left some "blank days" for code improvement

we still have some days left, before gsoc coding starts oficially, although google allows to start before it, so you can choose your task freely for that period

what about 2 pools, one for final frames and one for raw data arrays?

so the stuff can be processed in parallel

for what purposes?

while first array is processed, second one is loaded and can be processed, maybe also third one, depends on the system, then first one will be removed and replaced by 4th frame data and so on

So, we have to implemente the pool allocator

so, off for today, see you

See you!

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