Current Server Time: 14:04 (Central Europe)

#apertus IRC Channel Logs

2021/08/05

Timezone: UTC


01:05
tpw_rules
why was 143e6 chosen for the axi_hp clock speed?
01:40
tpw_rules
hm, how would i enable register retiming in vivado?
02:40
Dest123
left the channel
05:29
intrac
left the channel
05:31
intrac
joined the channel
05:34
Bertl_oO
off to bed now ... have a good one everyone!
05:34
Bertl_oO
changed nick to: Bertl_zZ
07:14
lexano
left the channel
07:25
lexano
joined the channel
08:02
fredy
joined the channel
08:33
intrac
left the channel
08:38
se6astian
good day
08:39
intrac
joined the channel
08:40
se6astian
more wiki user registrations even after riddle change... weird
08:44
BAndiT1983
maybe someone looked at it manually and adjusted the bot script, although i doubt that, as the only purpose is to spread spam and i can't imagine anyone to work hard for that
08:45
se6astian
they do pay or trick people into solving captchas, etc.
08:45
se6astian
but I wouldnt expect them to get onto the new question solving that quickly
08:45
BAndiT1983
ah, forgot about that one (not really into this whole crap)
08:46
BAndiT1983
maybe there is a way to avoid questions
08:53
se6astian
I hope not...
08:55
BAndiT1983
https://www.mediawiki.org/wiki/Topic:Vky60p231ng9i1i4
08:55
BAndiT1983
maybe something like this, but was just a guess
08:56
BAndiT1983
also by just looking at the list of new users it's pretty close thing, that questions are either solved, hacked, some bug is there or misconfiguration
08:59
BAndiT1983
also this is pretty concerning (was mentioned at the end of discussion): https://phabricator.wikimedia.org/T168783
09:04
se6astian
well I just tested creating a new user through https://wiki.apertus.org/index.php?title=Special:CreateAccount and there is no obvious way around the captcha
09:12
anuejn
tpw_rules: no, the cpu on the zynq side is really not fast
09:14
anuejn
tpw_rules: re the hacks in soc_memory: I think it is a okay workaround for now but should rather be handled by the axi infra
09:15
anuejn
143e6 seems like a wired frequency but the fclocks cant generate too many distinct frequencies and probably that was the one in range?
09:16
anuejn
if you request something that is not generatable naps will throw an error
09:16
anuejn
re register retiming: I have no idea; maybe ask Bertl_zZ here?
09:25
fredy
left the channel
09:45
fredy
joined the channel
10:59
metaldent
joined the channel
11:27
vup
tpw_rules: it does not really do a `read` to /dev/mem, as it is memory mapped, but I think the bit twiddeling is the culprit here
11:47
aombk
left the channel
11:57
aombk
joined the channel
12:35
Bertl_zZ
changed nick to: Bertl
12:35
Bertl
morning folks!
12:45
se6astian
good day
14:19
fredy
left the channel
14:20
fredy
joined the channel
15:01
metaldent
left the channel
17:23
Bertl
off for now ... bbl
17:23
Bertl
changed nick to: Bertl_oO
17:46
tpw_rules
so the gearbox and fifo both fail timing pretty substantially
17:47
tpw_rules
and it looks like they do in the camera.py applet as well. did they ever pass at one point? does it still work?
17:53
tpw_rules
also writing the data to DRAM only kind of works. not sure if it is a timing issue or what. the StreamGearbox orders the bits in a really weird way
17:56
tpw_rules
also DramPacketRingbufferCpuReader for reasons which don't really make sense? why are all of the bufferN_base values read out as 0? they should be a constant...
18:58
tpw_rules
ah okay i fixed some issues with the stream generation logic and clocked down the gearbox and now the gearbox passes timing
18:58
tpw_rules
but that means we probably can't speed up the sensor clock by much, maybe from 250 to 300MHz, because the stream is now 100% utilized
18:59
tpw_rules
and the guts of the fifo inside BufferedAsyncStreamFIFO still do not pass timing. not sure if that is fixable
19:00
tpw_rules
(on the axi_hp side)
19:02
vup
do you have a timing report (and matching nmigen applet) one could take a peek at?
19:03
tpw_rules
yeah give me a bit to finish fiddling
19:03
vup
sure
19:05
tpw_rules
can you also look at DramPacketRingbufferCpuReader? something there is pretty weird
19:06
vup
yeah, the driver_method is for sure broken
19:06
tpw_rules
yes it is, but all the bufferN_base and bufferN_level values it would use don't work either. they show up as 0 in pydriver, despite the fact that the bufferN_base values are constants
19:06
tpw_rules
which aren't zero
19:07
tpw_rules
current_write_buffer works...
19:17
vup
looking at it now
19:18
vup
re retiming, I think its a option you just give to `synth_design`, which is impossible with the current nmigen infrastructure, but seems like a simple enough addition to the 7series vendor implementation
19:19
tpw_rules
i tried that by editing nmigen's code, but it did not help
19:19
vup
did not help wrt to timing?
19:19
tpw_rules
correct, timing didn't improve much
19:20
vup
interesting
19:35
tpw_rules
vup: https://pastebin.com/zJ3w15LX
19:35
tpw_rules
https://github.com/tpwrules/naps/blob/cmv-pattern-dram/applets/cmv12k/pattern_dram_test.py
19:36
tpw_rules
it all appears to work. i haven't checked the downloaded pattern carefully because i don't understand the ordering of the StreamGearbox, but i assume it is invertible...
21:03
Dest123
joined the channel
21:03
Dest123
Evening!
21:27
tpw_rules
vup: i left a review on #22. could you look at that then merge it?
21:40
se6astian
wiki spam continues, will disable user creation temporarily
21:49
se6astian
done
21:50
se6astian
possibly the accounts that already registered will continue to spam, lets see
21:50
se6astian
any of that that already spammed has been blocked but maybe some still sleep
21:51
Bertl_oO
sleeper cells!
21:54
se6astian
exactly
23:06
fredy
left the channel
23:28
fredy
joined the channel
00:03
vup
tpw_rules: Ill merge #22 when the CI green, also investigated the buffer[n]_base issue and anuejn is working on a solution now
00:37
fredy
left the channel
00:41
vup
tpw_rules: I managed to make the dram writer meet timing
00:41
vup
ill upload a diff somewhere
00:42
vup
I did not actually change any of the logic, but marking the axi_hp (which is used for the dram writer) <-> axi_lite (which is used for the csr registers) path as false path almost made it pass, and then removing some of the `StreamInfo` instances for debugging makes it pass
00:43
vup
anuejn: fyi ^
00:44
anuejn
nice :)
00:44
vup
we should think about marking the axi_lite to any other clock as false path by default
00:45
vup
or rather the csr_domain <-> other domains paths
00:45
anuejn
sounds reasonable
00:46
vup
the only think I fear is, that maybe someone creates a new ClockDomain based on the csr_domain, that is actually used for csr stuff
00:46
vup
I am not sure what happens then
00:47
vup
(if vivado will treat paths marked as false paths that are literally the same clock)