Current Server Time: 08:32 (Central Europe)

#apertus IRC Channel Logs

2021/08/04

Timezone: UTC


00:04
Dest123
left the channel
00:04
Dest123
joined the channel
00:07
Dest123
left the channel
00:49
intrac
left the channel
01:00
vup
tpw_rules: anuejn and I did a quick naps hacking sessions: https://github.com/apertus-open-source-cinema/naps/pull/20
01:01
vup
this should now unload previously loaded devicetree overlays
01:01
vup
(and contains some misc other improvements, like making unbreaking running / loading the fatbitstream via ssh)
01:03
intrac
joined the channel
01:03
tpw_rules
alright, let me give it a spin in a few minutes
01:03
tpw_rules
"Better fatbitstream API for command insertion" does this mean there's a way to add another python file to use in the fatbitstream?
01:04
intrac
left the channel
01:04
vup
not yet
01:04
intrac
joined the channel
01:04
vup
just a way to insert shell commands to the front (and the back)
01:04
tpw_rules
ah ok
01:05
vup
oh but, is adding another python file not already possible?
01:05
tpw_rules
i don't know, there's no docs :P
01:06
vup
you should be able to do `FatbitstreamContext.get(platform) += File("name", "contents")`
01:06
vup
heh
01:20
tpw_rules
vup: the patch to place build in the current directory does not seem to work?
01:20
vup
are you sure?
01:20
vup
it works for me...
01:24
tpw_rules
oh, i just didn't install it correctly
01:32
tpw_rules
vup: ooh, there's color now. but it all seems to work and switches overlays correctly. thank you
01:33
vup
great
02:26
tpw_rules
anuejn: what exactly does the `initial` variable in the ILA mean? for whatever reason xilinx balks at the name and it needs to be changed. how about `never_triggered`?
02:32
vup
I feel like nmigen or yosys should escape that
02:33
tpw_rules
it does but vivado gets confused anyway
02:33
tpw_rules
at least i think it does, one moment
02:38
tpw_rules
yes it dies with ERROR: [Synth 8-2442] non-net port initial cannot be of mode input [/home/thomas/apertus/naps/build/pattern_test_Beta_Zynq/gateware/pattern_test.v:2411]
02:38
tpw_rules
the aforementioned line is simply: reg \initial = 0;
02:41
tpw_rules
oh hm, i think the problem is something else uses the name initial
02:41
tpw_rules
lots of modules being with that line
02:48
tpw_rules
not sure where it comes from
02:48
tpw_rules
in any case if i change that variable to e.g. `initialx` everything synthesizes fine
02:51
tpw_rules
(but that line does not change)
02:59
tpw_rules
also SocMemory does not work properly
03:04
tpw_rules
namely it assumes that addr indexes 32 bit words instead of bytes in handle_read and handle_write, and that the _memory_accessor address is offset from address 0 instead of the memory base in __getitem__ and __setitem__
03:04
tpw_rules
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
03:05
tpw_rules
there might also be a CDC violation in there or the ILA but that i am not so confident about
03:37
Bertl_oO
off to bed now ... have a good one everyone!
03:37
Bertl_oO
changed nick to: Bertl_zZ
06:00
fredy
left the channel
06:47
fredy
joined the channel
07:04
se6astian
good day
08:08
se6astian
wiki is getting spammed again, will look into changing the registration riddle
08:28
BAndiT1983
not bad -> https://wiki.apertus.org/index.php/Special:Log/newusers
08:35
se6astian
so we need a new security question
08:35
se6astian
we had "Is apertus° about cameras or carrots?"
08:35
se6astian
and "Is apertus° about open source or closed source?"
08:36
se6astian
apparently these were compromised
08:36
se6astian
it can be something more tricky I guess, real wiki editors are clever people :)
08:41
se6astian
previously the question already contained the answer options, I guess thats bad practice
08:41
se6astian
tried now 2 questions:
08:41
se6astian
what color is the ocean
08:41
se6astian
what does a camera record
08:41
se6astian
lets see how that turns out
08:48
fredy
left the channel
09:06
fredy
joined the channel
11:14
Bertl_zZ
changed nick to: Bertl
11:14
Bertl
morning folks!
11:31
balrog
left the channel
11:52
balrog
joined the channel
12:15
vup
tpw_rules: what I mean is, even if it is not escaped properly right now, it should be done by nmigen or yosys
12:15
vup
interesting find about the SocMemory, as is has been successfully used quite extensively by anuejn I think
12:28
fredy
left the channel
15:56
tpw_rules
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
16:10
vup
tpw_rules: hmm which `addr` do you mean?
16:12
vup
but I agree something is fishy about this
16:12
tpw_rules
vup: `def handle_read(self, m, addr, data, read_done)` line 25 of soc_memory.py (and the corresponding handle_write)
16:13
vup
I think it was mostly used with the JtagSoc backend and not the AXI one
16:15
vup
tpw_rules: yeah I think I see what you mean, I think the problem is, that the address used here is not one belonging to a flat address space with 1 byte sized elements like AXI, but rather uses the address as if the unit size of the address space was min(memory_width, 32)
16:15
vup
the latter works when using it over the JtagSoc, but I it feels like it could cause problems when using it with AXI
16:16
tpw_rules
is the address sized in units of 32 in JtagSoc?
16:16
tpw_rules
i think it still works even if memory_width is > 32
16:17
tpw_rules
that's what that whole split_stages is about
16:17
vup
there is not clear flat address space in the JtagSoc
16:18
vup
it has a maximum size of 32 bits per "memory access" you do
16:18
vup
but you cannot access the bytes of a word individually
16:20
vup
Yes it works when memory_width > 32, but then the maximum "data unit size" is still because it is split into 32bits sized parts
16:20
vup
s/is still/is still 32bits/
16:22
tpw_rules
is this a problem with the AXI infra or SocMemory?
16:24
vup
well
16:24
vup
it would be nice if we could make the AXI infra work like we expect it here, but I think thats impossible, because that part is part of how the arm cpu does its AXI accesses
16:24
vup
so we have to fix it in SocMemory
16:25
tpw_rules
i mean maybe we can say handle_read and handle_write always use an address in units of the data size?
16:27
vup
I mean thats what they do right now, no?
16:27
vup
the problem is I think, that the cpu always does the AXI access aligned to 32bits and then extracts the subdata from that if the address you actually read is not aligned to 32bits
16:28
tpw_rules
no, the handle_read address is in bytes but it expects to read a 32 bit quantity
16:28
vup
Ah now I understand
16:28
tpw_rules
so the AXI infra should maybe do a divide by 4
16:29
vup
well maybe
16:29
vup
AXI in principle allows unaligned accesses
16:30
tpw_rules
then maybe the AXI infra should also do the sub-data extraction?
16:30
vup
what do you mean by that?
16:31
tpw_rules
what i'm saying is i don't think unaligned access should be a problem handled by handle_read
16:36
vup
hmm ok I think I agree
16:37
vup
so while AXI allows unaligned writes (where then actually only the addressed part is written), for unaligned reads, the master (in this case the cpu) is the one that has to handle that, the slaves always just returns the data at ((addr // 4) * 4) (for a 32bit bus)
16:40
vup
so we should just divide the address by the data bus size in the AXI infra
16:41
vup
ah wait but we of course also have writes, where actual unaligned addresses are supported
16:42
vup
*do a meaningful thing
16:42
tpw_rules
do we need to support those though?
16:48
vup
well one upon a time we thought being able to pack registers would be nice
16:48
vup
but we currently don't use unaligned writes I think
16:53
tpw_rules
exactly
17:03
tpw_rules
i've made all the necessary tweaks to get the ILA working on the beta. i was gonna submit a draft PR and we can figure out what we want to take and how to revise it
17:04
vup
sure go for it
17:12
tpw_rules
is there a way to test the JTAG access on the Beta ?
17:13
vup
in principle yes, but not right now
17:13
vup
it would require anuejn to actually hook something up to the jtag port of the beta
17:22
Bertl
off for now ... bbl
17:22
Bertl
changed nick to: Bertl_oO
18:39
se6astian
https://twitter.com/ApertusOSCinema/status/1422990533258059779
20:11
Dest123
joined the channel
20:11
Dest123
Good Evening!
20:37
tpw_rules
vup: check the PR
21:01
vup
tpw_rules: the SocMemory "hack" seems fine for now
21:01
vup
what made you go the ILA route for reading out a frame?
21:02
vup
as the ILA uses the block ram of the fpga it will be impossible to store a full frame this way
21:03
tpw_rules
oh, this is sort of temporary. i just wanted to be able to read out a few rows in order to verify the sensor timings. i plan to duplicate the rows into a full frame, then feed it into simulation so i can test and develop receiving a full frame into the main DRAM
21:04
vup
ok
21:04
vup
do you plan on using the (Image)Stream stuff down the line?
21:04
tpw_rules
yes
21:05
tpw_rules
i was going to model everything on the existing camera.py applet
21:05
vup
make sense
21:05
vup
*makes
21:05
tpw_rules
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
21:06
vup
I mean camera.py already does that
21:06
vup
(not using any padding)
21:07
vup
ohh whoops
21:07
tpw_rules
it does afaict, the StreamResizer expands the 4 pixels from 48 to 64 bits
21:07
vup
It used to do that
21:07
tpw_rules
why was that changed?
21:08
vup
not sure, I think at one point anuejn lost faith in the StreamGearbox and decided to (temporarily) avoid it
21:09
tpw_rules
oh hm
21:10
vup
for example camera_ethernet.py is doing it
21:11
tpw_rules
oh so it gears the 48 bits to 64?
21:11
tpw_rules
i didn't think it could do weird ratios like that
21:11
tpw_rules
(maybe it can't ;P)
21:13
vup
oh the gearbox can do weird ratios
21:14
vup
it even has a expansive test suite that covers all sorts of cases :P
21:14
vup
the main point I would be worried about is not meeting timing with it
21:15
vup
but hopefully vivado can optimize it enough
21:15
tpw_rules
yeah it will be running at 250MHz
21:18
tpw_rules
but on the other hand i think i can simply make it a part of the fifo_chop type implementation
21:18
tpw_rules
where i think it will be free
21:18
tpw_rules
btw is the stream contract documented anywhere?
21:18
tpw_rules
i am a bit worried about what happens if some fifo overflows and we have to reset the pipeline because some pixels of the image got lost
21:20
vup
the stream contract is the normal AXI4 Stream contract, its semi documented in naps/stream/formal_util.py
21:21
vup
I mean a fifo overflow should not happen during normal operation, so having to reset everything is probably fine
21:21
vup
but usually stuff recovers from it quite well
21:22
tpw_rules
recovers from what?
21:22
vup
some fifo overflowing for example
21:22
vup
because the ImageStream provides the line_last and frame_last signals, so atleast after one frame the system should be in order again
21:26
tpw_rules
yeah that makes some sense
21:29
vup
If you create any new things that do complicated things with streams (like maybe the remapper or the fifo chop thing will) I would also recommend to do formal checking of it (using verify_stream_output_contract), anuejn and I have found a lot of bugs using it
21:35
tpw_rules
oh, that is great that there is formal logic. i was interested in seeing how that works. can you point me to an example?
21:35
tpw_rules
btw i don't think the remapper will use the stream interface. the chop fifo will probably have a stream interface on the output and then stream logic will be used for the rest
21:36
vup
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
21:38
vup
a simple example for the formal stream checking can be found here: https://github.com/apertus-open-source-cinema/naps/blob/9ebbc0fc431652497e7429d7da465949669f63a6/naps/cores/stream/gearbox_test.py#L291
21:39
vup
you simply give it a Elaboratable and it then checks the stream at `TheElaboratable.output`
21:40
tpw_rules
i guess the remapper would just output a 32*12 bit wide stream?
21:41
vup
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
21:41
vup
yeah re remapper, a NUM_CHANNELS*12 bit wide ImageStream
21:42
vup
thats what the hispi receiver (another protocol for reading out some sensors) is doing aswell
21:42
tpw_rules
oh ok
21:42
tpw_rules
i guess in that case i could use the StreamGearbox, if it is fast enough
21:43
vup
yeah, I would hope vivado can optimize it to basically the same logic as the fifo chop thing
21:43
tpw_rules
sure, i will give that a try. saves some effort on my end
21:49
fredy
joined the channel
22:07
fredy
left the channel
22:55
tpw_rules
vup: when exactly should frame_last and line_last be asserted?
22:58
tpw_rules
i guess during the last pixel of the last line, and during the last pixel of each line respectively?
22:58
tpw_rules
or is it after?
23:00
anuejn
during
23:00
tpw_rules
also, is it illegal to assert valid if ready is not asserted?
23:00
anuejn
nope
23:02
anuejn
the only non intuitive rule is that valid must not depend combinatorialy on ready
23:02
anuejn
also all payload signals must not change when valid is high and ready is low
23:05
tpw_rules
so i can't just completely ignore ready, i have to wait for it to go high before sending off the next word?
23:06
tpw_rules
can ready depend combinatorially on valid?
23:06
anuejn
yup
23:06
anuejn
but if you are worried about meeting the stream contract: there is StreamBuffer which is a cheap & cheesy way to meet it
23:07
tpw_rules
then is hispi_rx.py in violation? it does not seem to reference ready anywhere
23:09
anuejn
yup, that is correct
23:09
anuejn
that would need a StreamBuffer on its output
23:09
anuejn
(like this: https://github.com/apertus-open-source-cinema/naps/blob/9ebbc0fc431652497e7429d7da465949669f63a6/naps/cores/hdmi/rx/hdmi_rx.py#L119)
23:14
tpw_rules
what do you guys think we should do about the sensor configuration? there's a whole bunch of tables in the datasheet relating to lanes, mode, frequency, etc
23:14
tpw_rules
do we ever intend to support subsampling or binning? what about one side readout? or 8 or 10 bits?
23:16
tpw_rules
i think it would be good to support varying LVDS frequencies, lane count, and possibly bit depth
23:24
anuejn
I think subsampling and binning are really interesting
23:24
anuejn
(since I want to use the beta as a webcam ;) )
23:25
anuejn
reduced bit depth also
23:25
anuejn
btw. how slow is the ila on the zynq?
23:26
tpw_rules
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
23:26
tpw_rules
readout is pretty slow but that's pydriver's fault
23:27
anuejn
ah yeah I ment readout
23:27
tpw_rules
it's several seconds to read 400 bits * 1024 samples
23:27
anuejn
ooof
23:27
anuejn
thats slow
23:28
tpw_rules
but i think it is issuing a separate read call to /dev/mem for every 4 bytes and doing a bunch of bitmath
23:28
anuejn
yup, tho I hoped for a tad more performance
23:28
anuejn
but maybe we have to optimize that one day
23:29
anuejn
I can imagine, that the bitmath is not really fast in python
23:29
tpw_rules
i mean it can probably be down to several milliseconds if you simply read all the memory at once
23:30
tpw_rules
but the cpu in the zynq is not excessively fast, is it?
23:30
tpw_rules
btw, what do you think of the hacks on SocMemory?