#apertus IRC Channel Logs

morning folks!

Yeah I did! I actually need to head to bed. I flashed the new firmware and booted it up. Ran the axiom-start.sh script and trying to check the HDMI feed but it isn't displaying right on this particular monitor...

if so, compare the setup scripts with your previous settings

I'm on my way to the hub now, but we can chat after you had some sleep ...

cya

good day

I have attached the new VCD fiie. You can take a look :)

Also what is the priority of T728 Image sensor simulation

Could anyone tell that in our CV we going to submit, do we need to mention only the points relevant to your organisation?

in T731 "Bidirectional Packet Protocol"

the lattice FPGAs are used as io expanders

which would then be controlled / readout over the packet protocol

as I understood: the ZYNQ will communicate with the two MachXO2 with a fixed protocol over the LVDS and in the header of that packet it will tell the MachXO2 which protocol ( I2C, SPI, ...) to communicate with the sensors ?

yes something like that

did you read the comments below the task? there is some more information you can find there

vup2: nope, it is transparent to any protocol then, instead of making a more semantic protocol aware transport

but i agree, making the transport independent of the actual protocol used at the machxo2 side has certain benefits

sure

its hard to do when the people do not know what it shall be used for exactly.. so I miss a more precise definition, and maybe the architecture shall be set by who requested such thing to be made

well there are some more specific examples in the comments

but yes they should probably be added to the task description

but the general idea is, that the the `routing fpga's` act as io expanders mainly for the plugin modules and the shields

there are direct connections between the plugin modules and the zynq for high speed data transfer (for example for the hdmi plugin module: the actual video signal)

they are for example used to communicate with the hdmi ic on the hdmi plugin module over i2c to set various parameters

and similar tasks

but there could for example be a plugin module that is connected to a external shutter

hope that helps a bit to see how this ties in into the whole system

where are they from?

ah no both are in the picture

azfoo: check out the GSoC 2019 workboard, specifically the first column: https://lab.apertus.org/project/view/20/

aSobhy: the challenge with the routing fabric protocol is that it needs to be generic or flexible enough to handle various plugins or shields or even CSOs but also able to generate deterministic events for things like shutter or exposure

Yeah i began to catch :)

Should the link be sent to IOBUF?

Hey BAndiT1983 , In Context to "add dokany to fuse", For proting the fuse based frameserver to windows we will be using dokany, right

?

OC even supports mac, tested it long time ago in a virtualbox

aSobhy: both is fine, the important part is to make it obvious which parts are incorporated (by crediting the sources in the code) and what you've added

hint: incorporating existing IP properly is not as trivial as it may look at first glance :)

Hello AntGeorge!

sure

Because armv7 has 2 cores

and one more question...

I am checking my code with checkpatch to find if is follow the linux kernel coding style

should i split it?

ok thanks

as mentioned, there are a number of different data pathes between the routing fabrics (MachXO2) and 'other' parts of the AXIOM Beta

for example, the RFs (routing fabrics) connect to the CSO (center solder on area)

this information is transferred either via SPI or via I2C (or maybe both if different sensors are used)

if you want to do some kind of image stabilization or 3D tracking, you want to get a few hundred measurements per second and they require very acurate time stamps

now for the ZYNQ I didn't understand what danieel means "or you can just transfer register access and interrupts "

PCIe for example goes that route quite successfully

this can happen in one 'very' generic type or in several layers depending on the priority

Okay :)

there have been some discussions on the IRC channel as well and you should find those in the logs

you're welcome!

sure, drop me a note when it is ready for checking

Bertl did you check my task?

Yes thanks

correct, but if done properly, the necessary timing information can be added by the FPGAs

the PCIe allows pipelining/multithreading, which is quite an overkill, maybe that aspect should be specified - that how many concurrent operations shall be open at one time

high priority would be "immediate" values in each packet

while it might otherwise be handled with a few bits

if the latency is the target, then a very simple bit vector synchronization, with difference and compression can be used :) it might need one sideband signal for training/syncing though