#apertus IRC Channel Logs

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

I need to shutdown the remote access beta for a bit, anyone doing anything on it currently?

Ok thanks :)

Hi Bertl

I am having problem in syncing the PRNGs, I am stuck in it :/

okay

Good evening everyone

sorry for the delay

Good evening

Fares you start please

In the last two weeks I almost completed the documentation for all the files and few high level documentation

I also completed fifo, simple address generator and bit conversions module for the axihp_reader|writer

is the documentation already on github? I didnt see anything on the wiki yet

the documentation is technical and describe what every module does in the encoding process

where is the documentation going to be hosted you wrote so far?

high level documentation and general overview with links to further content (code, documentation, usage examples, et.) on the wiki would be great

great! that was everything I was working on last two weeks, I want to schedule a suitable time with you to present the LJ92 algorithm and describe how the core is working in high level and also to determine which modules will be in the final version, as I need time before GSoC deadline to write supporting software.

lets discuss that presentation time afterwards

great, thank you.

Hi all,

Worked on LutConfModule which uses the Blob Packet to set gamma_correction_lut's.( Though the file format has not been decided for LUT file ,Currently I have assumed it to be 4096*4 values.)

what are "values" for you?

are LUT values really float?

The ones generated using the formula were'nt

Shouldn't be a problem for int values too

I think it is important to differentiate between values stored in files and the values set in LUT registers

i.e. floats between 0.0 and 1.0

How do we interpret these values (0.0 to 1.0) for register settings ?

i.e. if the LUT has 16bit, you want to spread the 0-1 interval to the full 16bit range

I also finally worked on setting and getting i2c values directly through DaemonCLI (This has to be tested in Beta.)

That would be it from my side .thanks

great, thanks for the update

ok, thank you

I have done it for one button, so now it has to be 'extended' to work on all of them

well, I have tested it on the remote, so checking that the leds did what I expected

as I have two leds I used one of them to show if it has detected 'for real' that the button has been pushed, and the other one for 'fake' pulses

which means the button just didn't bounce at all, no?

this would be all

Dev_: your turn

last week, I spent most of the time in understanding of task for making an eventbus and event driven architechture for OC which will be used by frameserver

which occured

Form yesterday, i was working on VideoClip class and it is almost complete. Inclusion of videoclip class has reduced many responsiblity and unnecessary function from static allocator

??

Yes BAndiT1983, I know

https://github.com/apertus-open-source-cinema/opencine/tree/dev/Source/OCcore/Events

Okay , I will work on it

After Eventbus in working state , we can go for fuse

thanks Dev_, anything else?

great

hi all

simulating the Machxo2 side right now

okay, please keep me updated

I left it for now and will find another 8b/10b open source code to see if my code that had the problem or not

thanks, anything else?

great

felix_: ?

great!

Hi everybody

I had pm you

After I had successfully completed the BER testing model on post route simulation, I worked of finding the BER on harware ie real BER. I had to debug a lot on the hardware even if everything was perfectly working on post simulation and for debugging I had only one LED. But this is what I have achieved: Every thing is working good on hardware except that I am not able to synchronise the PRNGs so BER is coming to be

50% but in case of counter the BER is remains constant that means it is definitely less than 10^-9. Once I am able to synchronise the PRNG I would then decrease the updates rates so that I can test for lower BER.

well, 50% sounds nice, how did you output the counter values?

doesn't really answer my question though :)

you said, you 'measured' a BER of 50%

this requires that you did count the wrong bits somehow and also that you did read out that value in some way

ahh sorry, I measured it by sending it to my laptop by the ft601q

It gets updated after counting everytime 2^28 bits ,

great, anything else to add?

thanks!

we scheduled the next team talk video shooting for next week

we have been accepted to do a booth at maker faire hannover in august

nothing relevant to report from my side

right, then thanks everyone for attending again! meeting concluded, please discuss the things with your mentors now that we previously mentioned

my pleasure, I am off for dinner now, fares can we schedule the presentation a bit later or alternatively via email?

sure

BAndiT1983, I would start working on eventbus (extend) from today itself , Then I can go for Fuse also in next of half of week

The videoClip class is also ready, I will push changes today

Ealier I was using the switch from control codes to non control codes for syncing but it didn't seem to do well, so now I am changing to all zeroes method.

what do you mean with 'constant BER'?

That means the problem is PRNGs aren't synced right?

i.e. about 50% (half of all transmitted bits) would be wrong

Okay ,

By constant I mean, the reported bit errors are exactly equal. In case of PRNG they are slightly varying but still very close to 50%

But anyways, syncing only seems a possible issue.

yeah, that's what you'd expect from unsynchronized PRNGs

sideband?

Yeah, also a good method

if you have two clocks, probably yes

if you are clocking your data with the FT60x clock, there is no need to do that

Yes, I'm here

Also I have some confusion between DRR x2 and x4, they are the same on input side ie simple DDR but the DDR x4 forms eight bit words from it while DDR x2 forms 4 bit words right?

you are referring to the MachXO2 hardened IP?

okay sounds good, is that good with Bertl?

Yes Bertl, the problem is the max frequency DDRX4 IP allows is 378MHz which is less than what I require

thats 36 minutes ago in 2 days

Well done and thanks for the updates everyone.

why 3Mbit/s ?

No I am getting 600MBits with DDR X4 at 300 MHz

How can the speed change, if the sampling scheme is same in both case which is DDR?

Does not the DDR X4 means you are just grouping the signal in chunks of 8 bits like you do grouping of 4 in DDR X2?

so, 100MHz means 2 bit per clock cycle on DDR

DDR x2 and DDR x4 increase the gear ratio accordingly

se6astian*

apurvanandan[m]: but you are likely to hit a limit on the clock there

i.e. while your gear ratio can be 1:8, your clock cannot

either that or any protocol error

Bertl Is there a clock limit in the fpga fabric?

So 378MHz won't be above that I guess

but you can easily start testing at 100MHz

I am currently testing everything at 300 MHz

good then

Np

That would be it from my side .thank

off to bed, good night