#apertus IRC Channel Logs

oh i was thinking about BitwiseAccessibleInteger, is there really a need for that or bitarray?

vup: also i added the assert that the bus word width is exactly 32 because if it's greater then the split_stages calculation has to change, right?

also not sure i 100% agree with wholesale marking the csr_domain as false path. maybe only for StatusSignals

i mean BitwiseAccessibleInteger as what the control and status signals are mapped to in pydrive. i think it would be fine if it were a regular integer

tpw_rules: I think the gateware is still correct if the bus word width is bigger than 32bits if you use the __{get,set}item__ helpers, as those mask the values accordingly

BitwiseAccessibleInteger is just use for some inbetween conversions

we were thinking about using bitarray, but we now disregarded this idea

and also some performance optimizations

a simple read for a toplevel variable (design.something) is now down to 33us from 410us for me

tpw_rules: yes it fixes the level values aswell

ohh yeah

sorry somehow I missed that

it uses memory mapping

yeah

you should be able to cast it to an array of 32 bit integers iirc

if i can figure out the git, i will rebase my PR on the main branch as it stands and delete the DevMemAccessor hack commit

�

(this is with vivado 2019.2, I would hope a newer version does even better...)

i did not

at 250 it does not pass, but i'm pretty sure in your version the gearbox runs at 125MHz

i might replace the gearbox anyway, i think it is inefficent. vivado mentions a very wide shift register, i think much wider than necessary.

also re PR #23, don't merge it yet. i think it can be made even faster. i will fiddle tomorrow too

good day

not that many though, cleaned 2 pages

tpw_rules: your problem should be fixed now: https://github.com/apertus-open-source-cinema/naps/pull/23

tpw_rules: I tested in with the camera.py design on the micro, just using

Would be curious to see if you can get it significantly faster

(For the general purpose case)

vup: https://paste.niemo.de/osucewulej.lua this is what i meant with ctypes. this drops from 33us to 24us

non-aligned offsets*

tpw_rules: interesting, would not have thought that this helps that much

yeah, are you okay with the compromise about non-aligned offsets? i think i can also add some improvements to SocMemory and the ILA to the PR

my question is why would it have unaligned addresses

i guess i still see the whole pydriver thing as mostly a debugging aid. so it makes sense to me to make illegal special cases like unaligned addresses and multiple fields per address (i.e. Value.bit_start != 0)

you too feel fancy having a jitsi session?

sounds good to me

oh sorry bad missplaning from my side I dont really have time :(

maybe later this eveneng but I cant say currently

later would be better for me too

hm, trying to write to a StatusSignal with pydriver causes a bus error

do you think the axi infra should silently ignore writes to StatusSignals, or just pydriver should catch them?

silently ignoring would be a terrible idea

vup: what exactly did you mean by "The SocMemory changes should also be reflected in the test_smoke test of soc_memory_test.py."? those tests pass

test_smoke passes, but it should probably read from aligned addresses over the whole address space, right now it reads from (with the change) unsensical addresses and only tests the first fourth of the address space

yeah

sure makes sense

(and i address your comments)

anuejn: do you see me?

blah. it keeps alternating between saying connection good and connection lost

no

bad luck

yeah me too

bope

hdmi does 60FPS, sensor max 40FPS