#apertus IRC Channel Logs

tpw_rules: anuejn and I did a quick naps hacking sessions: https://github.com/apertus-open-source-cinema/naps/pull/20

(and contains some misc other improvements, like making unbreaking running / loading the fatbitstream via ssh)

alright, let me give it a spin in a few minutes

ah ok

i don't know, there's no docs :P

heh

are you sure?

oh, i just didn't install it correctly

great

I feel like nmigen or yosys should escape that

at least i think it does, one moment

the aforementioned line is simply: reg \initial = 0;

lots of modules being with that line

in any case if i change that variable to e.g. `initialx` everything synthesizes fine

also SocMemory does not work properly

it's my bedtime so tomorrow i can confirm the diagnoses and maybe send a PR if you all don't get to it first

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

good day

not bad -> https://wiki.apertus.org/index.php/Special:Log/newusers

we had "Is apertus° about cameras or carrots?"

apparently these were compromised

previously the question already contained the answer options, I guess thats bad practice

what color is the ocean

lets see how that turns out

morning folks!

interesting find about the SocMemory, as is has been successfully used quite extensively by anuejn I think

vup: indeed, the SocMemory and ILA tests both pass. but i get behavior on the hardware consistent with the observation that `addr` is bytes, not words

but I agree something is fishy about this

I think it was mostly used with the JtagSoc backend and not the AXI one

the latter works when using it over the JtagSoc, but I it feels like it could cause problems when using it with AXI

i think it still works even if memory_width is > 32

there is not clear flat address space in the JtagSoc

but you cannot access the bytes of a word individually

s/is still/is still 32bits/

well

so we have to fix it in SocMemory

I mean thats what they do right now, no?

no, the handle_read address is in bytes but it expects to read a 32 bit quantity

so the AXI infra should maybe do a divide by 4

AXI in principle allows unaligned accesses

what do you mean by that?

hmm ok I think I agree

so we should just divide the address by the data bus size in the AXI infra

*do a meaningful thing

well one upon a time we thought being able to pack registers would be nice

exactly

sure go for it

in principle yes, but not right now

off for now ... bbl

https://twitter.com/ApertusOSCinema/status/1422990533258059779

Good Evening!

tpw_rules: the SocMemory "hack" seems fine for now

as the ILA uses the block ram of the fpga it will be impossible to store a full frame this way

ok

yes

make sense

with the possible exception of what you pointed out earlier of not doing padding so we aren't wasting 1/4 of the DRAM bandwidth

(not using any padding)

it does afaict, the StreamResizer expands the 4 pixels from 48 to 64 bits

why was that changed?

oh hm

oh so it gears the 48 bits to 64?

(maybe it can't ;P)

it even has a expansive test suite that covers all sorts of cases :P

but hopefully vivado can optimize it enough

but on the other hand i think i can simply make it a part of the fifo_chop type implementation

btw is the stream contract documented anywhere?

the stream contract is the normal AXI4 Stream contract, its semi documented in naps/stream/formal_util.py

but usually stuff recovers from it quite well

some fifo overflowing for example

yeah that makes some sense

oh, that is great that there is formal logic. i was interested in seeing how that works. can you point me to an example?

hmm why not make atleast the remapper output a ImageStream? That way the chop fifo would have a Stream interface aswell and thus be easier to use in other situations aswell

you simply give it a Elaboratable and it then checks the stream at `TheElaboratable.output`

It is possible, that your Module requires a valid input stream to generate a valid output stream, then you can use the support_modules thing, see for example here: https://github.com/apertus-open-source-cinema/naps/blob/9ebbc0fc431652497e7429d7da465949669f63a6/naps/cores/stream/gearbox_test.py#L369

thats what the hispi receiver (another protocol for reading out some sensors) is doing aswell

i guess in that case i could use the StreamGearbox, if it is fast enough

sure, i will give that a try. saves some effort on my end

i guess during the last pixel of the last line, and during the last pixel of each line respectively?

during

nope

also all payload signals must not change when valid is high and ready is low

can ready depend combinatorially on valid?

but if you are worried about meeting the stream contract: there is StreamBuffer which is a cheap & cheesy way to meet it

yup, that is correct

(like this: https://github.com/apertus-open-source-cinema/naps/blob/9ebbc0fc431652497e7429d7da465949669f63a6/naps/cores/hdmi/rx/hdmi_rx.py#L119)

do we ever intend to support subsampling or binning? what about one side readout? or 8 or 10 bits?

I think subsampling and binning are really interesting

reduced bit depth also

seems to work well enough. 41.67MHz with ~400 bits sampled. i don't really know how to read the timing report for vivado but it passes

ah yeah I ment readout

ooof

but i think it is issuing a separate read call to /dev/mem for every 4 bytes and doing a bunch of bitmath

but maybe we have to optimize that one day

i mean it can probably be down to several milliseconds if you simply read all the memory at once

btw, what do you think of the hacks on SocMemory?