#apertus IRC Channel Logs

why was 143e6 chosen for the axi_hp clock speed?

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

but I wouldnt expect them to get onto the new question solving that quickly

maybe there is a way to avoid questions

https://www.mediawiki.org/wiki/Topic:Vky60p231ng9i1i4

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

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

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

if you request something that is not generatable naps will throw an error

good day

off for now ... bbl

so the gearbox and fifo both fail timing pretty substantially

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

ah okay i fixed some issues with the stream generation logic and clocked down the gearbox and now the gearbox passes timing

and the guts of the fifo inside BufferedAsyncStreamFIFO still do not pass timing. not sure if that is fixable

do you have a timing report (and matching nmigen applet) one could take a peek at?

sure

yeah, the driver_method is for sure broken

which aren't zero

looking at it now

i tried that by editing nmigen's code, but it did not help

correct, timing didn't improve much

vup: https://pastebin.com/zJ3w15LX

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...

Evening!

wiki spam continues, will disable user creation temporarily

possibly the accounts that already registered will continue to spam, lets see

sleeper cells!

tpw_rules: Ill merge #22 when the CI green, also investigated the buffer[n]_base issue and anuejn is working on a solution now

tpw_rules: I managed to make the dram writer meet timing

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

nice :)

or rather the csr_domain <-> other domains paths

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

(if vivado will treat paths marked as false paths that are literally the same clock)