#apertus IRC Channel Logs

Good afternoon, Can anybody see there why Remote Beta e is refusing ssh connection?

morning folks!

Thanks

and me also

working :)

great! :)

I will say it was good and productive, I went through ftdi documentation for preparing presentation, was able to get urJTAG work ie read idcode with my hardware. Currently I and aSobhy are trying to program the remote beta's machXO2.

yes as apurvanandan[m] said we are working on the first programe to write on the beta now

Is there a meeting today?

ok

Bertl: how can I share a the terminal screen with apurvanandan[m]

does the one who sharing suppose to do a different action( command)

aSobhy: the shared screen is not started there, one of you needs to use 'screen -S share' to create it (but only one)

apurvanandan[m]:

you're welcome!

what do you want to use it for?

I made a backup and adjusted the I2C addresses accordingly, so should work now

hi! Good afternoon

wow! I didn't see it! I send you the reply now

meeting time!

as you have probably read in today meeting reminder email the meeting is now every week, same day, same time, same place

just come here every week :)

please pm me now if you want to report/share, like usual!

dev_: please go ahead

Hello Everyone !!

https://github.com/kakashi-Of-Saringan/opencine/commit/65ab5a55fce45efe423a61313b157c6d36da61b1 This is my last commit in my forked repo for mlv file.

Thanks

Okay , Bertl !!

No se6astian , that's it

great, apurvanandan[m] you are next

everything as you expected regarding remote hardware?

see my comment earlier here on the channel :)

Yes, it is working! Thanks ^_^

thanks, apurvanandan[m]

the DHL package to you was labeled today and will be picked up tomorrow

its DHL express so it should arrive quite quickly

Bertl: Yes it was

se6astian: Can I get the tracking details of the package when you have it?

Hi fares

In then last week I completed a basic lj92 pipeline with the basic functionality and committed it to the repo, https://github.com/FaresMehanna/JPEG-1992-lossless-encoder-core

dev_ can we have a chat on call?

yes sraj

Fares: history still shows initial commit 5 days ago?

okay

yes the packing module took too much time

no problem, just curious

okay, that would be all :) thank you!

thanks fares

maybe it also sends a notification not when the shipment has been created but when its been picked up

Yeah fine

hi, on this week I have been learning about debouncing test, so learning about interrupt routines

and basically that's it, getting deeper on it and making sure I know how to do everything

sounds good, you should also get your hardware soon

till then, let me know if you want to test something on the Remote, I'll can probably run it for you

that's all, thank you!

Hi all

cuerntly I'm teaming with apurvanandan[m] to do our first test on the beta testing that our code has been successfully writen on the MachX02

excellent! feel free to report your success with the remote Beta on the channel

No, Thanks se6astian :)

Bertl: your turn

BAndiT1983 would very much like to hear from him as well, so when you read up on the logs, please give a brief report

(and mentoring GSoC students of course :)

(might be interesting to collect the data in the Wiki btw :)

(hint for our students :)

great, did you push it to gh already?

(all changes were uploaded to my server as usual, no GH commits as I didn't modify the codebase there (yet))

(will check and let you know)

anything else?

that's it from my side for last week

https://github.com/apertus-open-source-cinema/AXIOM-Remote/tree/master/AXIOM_Remote_Prototype_V01.X/reference

thanks Bertl

quick updates from me

also saw fairphone there

couple of other things

he basically builds a DIY open source analog camera toolkit

I invited him to visit the AXIOM office today but he unfortunately wasnt able to fit it into his schedule

with focus rather on artistic lens effects, not super sharp high end glass which will not easily be possible with DIY

thats it from my side

otherwise same time, same place next week

Yes I do

(just as a note)

great, when is it planned to happen?

apurvanandan[m]: but if you have other preferences, that's fine as well

great, noted

vup: I read a little about SRL16/32 and I don't really know if the inference happens automatically or not, so mainly what I try to do is to ((old_data << count_new_data) | new_data)

so I add converter to make "((old_data << count_new_data) | new_data)" work with smaller registers, it now took around 500 LUTs and I still looking in how to make it better, the buffer now is 128bits

so you get bit 0, 16 and one of your choice

No I need to access 32bits of the buffer in the same cycle

the reading input loop and output loop are asynchronous to each other

can you explain more? I mean not totally asyn but both can happen at the same cycle with shared clk and shred buffer

is count_new_data constant?

vup: no, count_new_data was up tp 128 in value but after adding the converter it is up to 36 in value

let me explain, the main pipeline output data is from 4 to 124bits of data, usually most of them less than 36bits

it is crucial to handle new input / new output every cycle

what more can be done in the problem of packing variable length data?

any way to constrain the 36 bits even further

to less than 36bits?

yes

every cycle 4 pixels are inserted, 4*12=48bits

constraining the 36 to smaller is easy but will effect the throughput

ok i see

last week I worked on sysfsAdapter and the EnvironmentModule (Module to monitor temperature and voltages) ,Currently the base functionality has been completed however ,this module is limited to temperatures and voltages defined in zynq_info.sh .We might want this module to be extended to cover all the temp/voltage sensors . However I don't have much information about these sensors .

Also Modules and Adapters were separated into different folders for cleaner structure.

Fares_: the pipeline runs at about 100MHz, right

Correct

and only allowing a maximum shift of 18 bits per cycle

way less

a barrell shifter is quadratic

if you have 4 bits, you basically need 4x4 cross points for all variants

yeah, but here the buffer lenght is constant / has a fixed lower limit

okay, so it's a reduced barrel shifter

because of the size of the LUTs

yeah, possible, but a bit of that is offset by the fact that more controll logic is needed

another funny idea could be to use the DSP48 and a multiply + add operation

I searched into that but I think DSP48 work with smaller number of bits

sure

it's fine for the fabric but it might become tricky with timing

Aha okay

There is another idea of reversing the order of the bits, but I don’t think it will help much, I will look into it and checking what parts can benefit from increased MHZ

but you might need to set multicycle pathes or similar

it should be able to do more

but with only a 25x18 multiplier i don't see how you would do bigger shifts

depends on what part you are interested in

then you are obviously limited by the 48 bit P reg

which means you can for example shift 24 bit by up to 24 bit

why not?

there is a shift by 17 somewhere

but not sure it can be used in this case

(control logic to enable is when the shift amount is >=17 and disable when lower)

(have to verify that)

/path

as the gpio.py is for the ZYNQ

change number of bits..*

those connected to the PIC can be inspected with the pic_gpio.py

those connected to e.g. the shields or plugin slots need a debug shield/plugin to check

Fares: i think it should atleast about half the number of luts

so that should be the same effect if count=5bits and new_data=31bits correct?

number of LUTs is dependent on the left shift or the OR-ing?

Fares: the shift

https://github.com/kakashi-Of-Saringan/opencine/commit/65ab5a55fce45efe423a61313b157c6d36da61b1

Actually I am having problem in loading frames of MLV

why do you init parameters there, as the loader is the one responsible for getting values, especially bayer pattern

describe your approach please

Bertl: we are planing to use PIC's gpio for testing the our code on MachXO2, can you please tell which pins are unused ( will not interfere with normal functioning).

dev_, i also miss a bit a loop which gets all frames from MLV

please point me to the loop which loads all frames

BAndiT1983: Thanks for help, Now my programmer is able to detect jtag chain by using urjtag. I used the c51 fx2 firmware (had to compile on Windows due to deprecated packages :p ) on the platform cable and it worked under UsbBlaster.

apurvanandan[m], glad to hear, that it helped, will also try to rework my XUP to general jtag for pic32

dev_, and where does the code fail?

apurvanandan[m], that's exactly what is required

SDO_W, SCK_W and #SS_W

apurvanandan[m]: and of course SDO_E, SCK_E and #SS_E on the East side

Bertl: Ok great, thanks

, i see, as you are trying to break the loader right away : I tried to load one frame even using initparameter function : but that worked

which problem do you suspect?

example for qtcreator -> https://i.stack.imgur.com/9md8n.png

right ??

so why when i retrive it back , it is not giving me correct data :(

yes, it should allocate fixed size for the chunk

normally the loader should predefine the size of each channel or image data, as it's the one who knows it

yes, and can we also retrieve it back using offset which we storing in _pointerMap(in static allocator.h , line 22 )

first note, you are not storing pointers there, as i see size_t

third note, ensure that it returns proper offset

Yes, please see GetData function (line 33 staticallocator.cpp)

Hey Bertl , we have MachXO2 LCMXO2-1200HC-TQFP100-4 fpga in RFW no?

third note, ensure that it returns proper offset : Yes , I tried to print it , they are correct

first time you allocate the memory, but second time you assign data from frame processor

dev_, as the code is rather old for OCImage etc., there are many artefacts which should be removed, e.g. channel related setters

can try to assist tomorrow, as today it's late in the evening and i will leave IRC soon

start with bare minimum

yes, remove everything memory related in OCImage first, so it doesn't allocate it's own memory

start with setredchannel

BAndiT1983, are u there ?

remove memmove there and also new[]

so, off for today, please continue to write here, then i will read logs tomorrow or just write an email

will try to be tomorrow longer available, had other stuff to accomplish today

No problem , BAndiT1983, Good night

we have a bunch of I2C/SPI/JTAG connections from the main board

(only the clock capables are special there)

Because I was wondering what kind of FPGA you wanted to put here. I remember somebody during our chat introduced an Artix-7, but if it just a basic packet handling from the sensor, and then a direct transmission of the pixel values, I suppose I can have a look at Lattice products

I think the Artix-7 might be a good choice, mainly because of the similar architecture and the high data rates over LVDS

i.e. with a Lattice we probably can't do 1.2GBit over the 36 LVDS channels :)

(over each of them that is :)

okay, so I'll have a look to the Artix-7 then

ok, I take note

and Diamond is kind-of free as well, similar to Vivado

(of course)

sounds great!

perfect! tx!

and for the MachXO2 are we use LCMXO2-1200HC-TQFP100-4 that apurvanandan[m] mentioned ?

aSobhy: check out the build scripts for MachXO2 here http://vserver.13thfloor.at/Stuff/AXIOM/BETA/LATTICE/

i remember i saw the model no but where didn't remember (dory memory)

you're welcome!

I saw a command like that

nah, don't bother