Current Server Time: 19:42 (Central Europe)

#apertus IRC Channel Logs

2021/08/04

Timezone: UTC


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