#apertus IRC Channel Logs

morning folks!

off for now ... bbl

evening everybody!

aSobhy: you aroud?

delay*

(see private message :)

hey Fares!

I have completed the first part of the lj92 pipeline, which take 4 pixels and encode them to [4-124] bits long

I pushed the code to Github https://github.com/FaresMehanna/JPEG-1992-lossless-encoder-core

in the last few days I also added a fifo block after the pipeline and a module to pack the data from variable length to 64bit

I will stop here to test it and try it on fpga, the last stage in the encoding after that is a bit challenging

No that is, but I was working locally before making the repo, I will keep it updated

understood

the last part is to detect any 0xFF byte and add after it 0x00 byte, it is a must in JPEG standards, since a header is represented with 0xFF-0xMarker, so to differentiate a header from a normal data, any 0xFF byte in encoded data must be followed with a 0x00 byte, should I write several modules to handle this or can this be handled in serdes or in the driver for example?

as the stream itself doesn't have any metadata (yet) it is probably better to do in the driver or where the headers get added

as the data needs to be processed byte by byte again :)

yes that is correct :)

yes, it doesn't have an MCU we can access

so that you can put it into the stream without affecting the rest of the pipeline

okay I will do that

any specific issues so far?

okay, did you work on the DMA side as well?

of course

please go ahead, ask

and I understood all of them but I 'm having hard time to pick the best one

is that the best possible design or should I consider handshake / buffered handshake?

there is no such things as 'best possible design'

in general reducing synchronization overhead is a good thing when your pipeline requires highest throughput

yes, if you can work with that throughout your encoder, that's great

you cannot work with a global valid there anymore

no problem!

felix_: are you at the GPN?