Current Server Time: 18:06 (Central Europe)

#apertus IRC Channel Logs

2021/07/16

Timezone: UTC


00:03
tpw_rules
yeah i remember it
02:36
fredy
joined the channel
02:42
fredy
left the channel
04:12
fredy
joined the channel
04:41
Bertl_oO
off to bed now ... have a good one everyone!
04:41
Bertl_oO
changed nick to: Bertl_zZ
06:53
metaldent
joined the channel
07:55
fredy
left the channel
07:55
fredy
joined the channel
09:09
anuejn
tpw_rules: very nice, will look into it :)
09:10
anuejn
looks really nice at first glance
10:56
anuejn
mithro: we cucrrently have a somewhat different design
10:57
anuejn
NeTV2 definitely looks cool
11:15
Bertl_zZ
changed nick to: Bertl
11:15
Bertl
morning folks!
11:41
metaldent
left the channel
11:45
Dest123
joined the channel
12:06
metaldent
joined the channel
13:13
kbeckmann
left the channel
13:13
aPinky
left the channel
13:20
Topic
apertus° - open source cinema | www.apertus.org | join the apertus° Lab: http://lab.apertus.org/ | IRC Logs available at: http://irc.apertus.org | Weekly IRC meeting: Monday 18:00 CET/CEST
13:20
vup
has set the topic
13:22
kbeckmann
joined the channel
14:21
Bertl
off for now ... bbs
14:21
Bertl
changed nick to: Bertl_oO
14:46
mithro
anuejn: We should see if we can get your stuff running through the SymbiFlow open source tools - we do have Zynq support but nobody has really tested it
14:52
vup
mithro: what is the status of the more advanced block with the SymbiFlow flow, like MMCM, SERDES and DSPs? Last I checked atleast MMCM was not supported yet?
14:52
mithro
MCMM support was in the process of getting merged recently
14:53
mithro
I forget the status of the DSPs
14:53
mithro
We are a long way towards having the GTPs done for PCIe
14:53
vup
oh not GTPs just the regular {I,O}SERDESE2
14:54
mithro
We can do a lot of stuff like the DDR memory and things
14:54
mithro
We probably still missing various modes - but if there is an example design which is using them it is pretty quick and easy to fix
14:56
vup
I see, Ill look into trying some examples with SymbiFlow then
15:00
mithro
Your naps documentation looks really interesting!
15:07
vup
mithro: interesting meaning basically nonexistent? :)
15:12
illwieckz
left the channel
15:44
Bertl_oO
hmm, the jtag related scripts on beta-c seem to be broken
15:45
Bertl_oO
is this an issue with too old firmware?
15:54
vup
hmm in which way?
15:54
Bertl_oO
they use the old jtag interface it seems and the old hardcoded i2c addresses
15:55
Bertl_oO
but beta-b seems to be worse, I can't even get the axiom_prep_icsp.sh working there
15:57
Bertl_oO
I think I fixed the axiom_pic_jtag_cso.py script on beta-c, but it doesn't give the expected result (i.e. doesn't control the CSO LEDs) so I wanted to test it on beta-b
15:58
vup
I don't think the changes were ever upstreamed into the firmware repository, because iirc there were some pending problems
15:59
vup
but I remember that we were playing around with the pic firmware a lot to get the jtag for the machxo2 on the usb plugin module via rfdev working
15:59
vup
So maybe beta-c actually had the old pic interface and thus matching scripts, but then we updated it to get that working, which now means the old scripts don't work anymore?
16:00
Bertl_oO
maybe, in any case, we should get the software/firmware side sorted, at least on the remote betas
16:01
vup
yeah
16:01
vup
so iirc the pic firmware on beta-c should be in a sane / good state, as iirc there were some problems before, but those were fixed by updating the firmware
16:01
vup
so its now a matter of making the scripts work with it I would say
16:02
Bertl_oO
okay
16:02
lexano
left the channel
16:41
lexano
joined the channel
16:51
vup
tpw_rules: I had a first pass over your PR, great work!
16:58
tpw_rules
vup: do you have a moment to discuss the comments? i prefer here instead of github issues
16:58
vup
sure
17:01
tpw_rules
so re the sensor lane naming, i am not sure the best way to select lanes. suppose you make a cut down version of the beta with only 16 sensor lanes, would you call those lvds_0, lvds_2, etc? the only reason they are separate names now is because nmigen can't express the fact that some of the lanes are inverted in a single signal
17:03
tpw_rules
changing it to select lanes according to the table in the datasheet makes sense if you plan to use less lanes than you've wired, but why would you do that?
17:03
tpw_rules
but i'm not sure it makes sense if you want to use that module on a platform with less lanes wired to begin with
17:04
vup
my argument for naming the lanes according to the names used in the sensor datasheet would be mainly that it makes everything easier to understand imo
17:05
vup
right the naming only works if the order actually matches the readout mode wanted, so it only ever works with one readout mode for a specific board
17:05
vup
I can see several reason for using a lower channel count on purpose:
17:06
vup
1. if you don't need the datarate, you probably save power by not using all the channels
17:06
vup
2. Getting a bit of usage out of a broken sensor (maybe only two lanes are broken and by selecting a lower number of channels you can actuallly still use the sensor)
17:07
vup
Finally it would make testing lower channel counts easier on hardware that use more channels
17:08
vup
(It would be nice to be able to test for example the four channel mode on the beta before one tries it on hardware that can only do four channels)
17:08
tpw_rules
okay that makes sense
17:08
tpw_rules
do you think i should rename the lanes in the platform file too then?
17:08
vup
yes
17:09
tpw_rules
also i think only lanes out_1 to out_32 are wired up right now
17:09
tpw_rules
well i am not sure, do you use all 32 channels on a single side, or 16 channels on each side?
17:10
vup
16 on each side
17:10
vup
so out_{1,3,5,...,61,63} are hooked up
17:10
tpw_rules
so what's hooked up now is out_1, out_3, out_5 etc
17:12
tpw_rules
okay, so i can change that. it looks like it will be somewhat difficult to make the same logic compatible with single side mode so i will make a note that that doesn't work
17:13
vup
sure, thats fine
17:15
tpw_rules
so re var_load mode, i chose to use it instead of having a register which can be set to any delay like the VHDL because it saves a lot on logic and register access. there's only 5 registers instead of 32 and all the channels can be accessed in parallel
17:15
vup
ah makes sense
17:15
vup
seems fine then
17:15
tpw_rules
register access through pydriver is very slow but it still trains faster than the original :)
17:16
vup
lol
17:16
tpw_rules
(seriously it is about 900us, can you improve it one day? :D)
17:17
vup
that pretty damn fast
17:17
tpw_rules
maybe i am complaining too much
17:18
vup
900us or 900ms?
17:18
tpw_rules
microseconds
17:18
vup
thats insanely fast
17:19
tpw_rules
the bus cycle time is 0.1us though
17:19
tpw_rules
but anyway.
17:20
tpw_rules
for the case where window = 0b1111_0000_0000_0000_0000_0000_0000_1111, i am not sure that's possible? the original training code does not handle it properly either and i have not seen it in testing. i think because half a bit time is wider than all the possible delays, i don't see "mixes" like that
17:20
tpw_rules
all the training logic will need reworking if the clock speed is increased anyway i think. i just copied it from the C code more or less.
17:21
tpw_rules
https://github.com/apertus-open-source-cinema/axiom-firmware/blob/a078c76b0c1f8f04cb45788cdfaf57c9fc666304/software/sensor_tools/train/train.c#L384
17:23
vup
tpw_rules: hmm I don't see why such a window would not be possible with the current setup
17:24
vup
I imagine it looking like 0b111_1111_1111_1111_1111_1111_0000_0000_0000_0000_0000_0000_1111 if you had the full ~51 taps needed to cover a whole bit
17:25
vup
maybe this doesn't occur in practice because of how the pcb layout and such works out, but why should it not be possible to encounter this in theory?
17:26
tpw_rules
ah, i thought it was > 64 taps.
17:27
vup
maybe I fucked up the calculation, but afaik the taps are supposed to be about 78ps each, there are 32 which gives about 2.5ns
17:27
tpw_rules
no, i redid it and got 51 taps too
17:27
vup
ah ok
17:28
tpw_rules
so i guess it was just an oversight in the original code. but i can definitely address it
17:28
vup
seems like an oversight, maybe Bertl_oO has some insight later
17:30
vup
the 0.1μs bus cycle time seems to boil down to the 10MHz AXI frequency, Just making that faster would probably improve the bus cycle time aswell
17:31
tpw_rules
next, for "I don't think this code is correct for non periodic signals.". i think you are right. i was not able to convince myself it was correct, but i'm not 100% sure it is wrong either. i will have to puzzle that out more
17:31
tpw_rules
the point is that the python register access is over 9,000 times slower than the actual bus transaction
17:32
vup
ah oh
17:32
vup
I thought the training was 900us, not the pydriver access
17:32
vup
I can look into that
17:32
tpw_rules
sorry. the training is a couple of seconds. one pydriver read is 900us
17:32
vup
ok makes sense
17:32
tpw_rules
i see why you thought that was very fast now
17:32
vup
heh
17:33
vup
re halfword: yeah its really hard to think about especially because all the training is with periodic data where it can just magically work even if its wrong. anuejn and I spent hours thinking about this for the hispi phy and some other cores :)
17:35
tpw_rules
well it is good to know i am not alone. don't ask me how long it took to figure out that the serdes output bits were reversed
17:35
vup
ohh yeah, thats another good one
17:35
vup
also spent hours on that once, even did that twice
17:36
tpw_rules
do you think the output of the phy should have the same lane numbering as the input? or be contiguous like it is now?
17:37
vup
good question
17:40
vup
I currently don't have a strong opinion about that
17:40
tpw_rules
i think i will leave it how it is. maybe it will become evident when i write the remapper
17:41
tpw_rules
it can always be changed
17:41
vup
yeah sounds good
17:42
vup
Oh also one thing I missed: why not use the ddr mode of the iserdes?
17:43
tpw_rules
that is how bertl did it in the original verilog too, double the frequency with the PLL and use sdr mode
17:44
tpw_rules
not sure if either way is better. but sdr makes slightly more sense to me and was a bit easier for debugging
17:46
vup
ok, either seems fine to me for now, was just wondering if there was some deeper reasoning, maybe Bertl_oO has one?
17:47
vup
tpw_rules: ok, do you have any more questions?
17:50
fredy
left the channel
17:50
tpw_rules
one last comment is that i patterned the modules on the hispi PHY and stuff, but i think i will refactor it into a Controller module that also has the SPI stuff
17:51
tpw_rules
because the driver functions need access to the SPI during training
17:51
tpw_rules
also, is there a good way to get the number of lanes into the driver methods? i hardcoded it for now because e.g. len of the properties doesn't work
17:54
vup
re: Controller module: seems fine, this is one of the first more complex cases with interdependencies between different pydriver methods, so maybe we can use it sometime to think about how to handle those cases better
17:57
vup
tpw_rules: you can access anything under `self.` you assign in `__init__`, even non `{Status,Control}Signal`s
17:57
vup
so you could save the number of bits as `self.num_bits` or so
17:57
tpw_rules
oh, okay
18:00
tpw_rules
also the last last comment: we should discuss EventReg and the read and write strobes of Status and ControlSignal some time. EventReg does what i want now, but i think there should be a way to make it work for accesses > 32 bits, or fold its logic into Status/ControlSignal with the strobes
18:01
vup
yeah, the atomic access thing is a bit pain point we should solve soon
18:03
tpw_rules
alright that is it. have fun!
18:06
vup
alright you too!
18:17
Dest321
joined the channel
18:21
Dest123
left the channel
18:24
Dest321
changed nick to: Dest123
19:35
metaldent
left the channel
19:51
anuejn
tpw_rules: nice work
19:51
anuejn
tho I am rather nervous about the cdc in PokeReg
20:14
tpw_rules
there is no cdc?
20:15
tpw_rules
the IDELAY blocks are run off the AXI clock for the delay incand there is a PulseSynchronizer to the faster ISERDES clock for the bitslip
20:18
tpw_rules
oh, hm i think there is
20:19
tpw_rules
i meant to make that sync domain the csr reg domain
20:19
tpw_rules
anuejn: is that the hazard you spotted?
20:28
anuejn
yup
20:29
anuejn
okay then
20:29
tpw_rules
alright, thanks for catching that
20:29
anuejn
and I totally agree that we probably want to integrate that functionality into Control/Status signal strobes some time
20:29
anuejn
btw: the beta is currently disassembled on my desk but will be available soon again
20:30
anuejn
soon as in in a few minutes
20:30
tpw_rules
oh, i thought it was taking a little while to turn back on :)
20:31
tpw_rules
as for the PokeReg, maybe we can change the name when we discuss EventReg. same with the separate ctrl and clock registers. i really wanted that to be all one big register but EventReg does not work properly for > 32 bits and i could not think of a way to simply fix it which is why i added the assert
20:38
anuejn
okay sounds good
20:38
anuejn
beta should be back up again
20:43
tpw_rules
anuejn: erm, less channels work than before
20:43
anuejn
dafuq?
20:43
anuejn
that does not sound good
20:44
tpw_rules
yesterday it was 2 did not successfully train and now it is 5
20:44
anuejn
wtf
20:44
anuejn
I am definitely not good at this "Hardware" thing
20:44
tpw_rules
(i tested with the original gateware too)
20:45
anuejn
Bertl_oO: to the rescue: what should I do? any tips other than dis-and reassembling the camera again?
20:45
tpw_rules
http://pastie.org/p/1GLLnGH6eVrWvY0fy5gOiE
20:45
anuejn
is there any way of detecting which connectors are faulty?
20:45
tpw_rules
yesterday the mask was 0xFFFFFF77
20:46
anuejn
meh
20:47
tpw_rules
also now clock alignment outputs all zeros because channel 3 has completely stopped working
20:51
anuejn
Okay will give it another shot
20:51
tpw_rules
ok i issued poweroff over ssh
20:51
anuejn
or do you want to use the beta now?
20:51
anuejn
tx
20:53
tpw_rules
is there documentation on Bundles anywhere?
20:56
anuejn
not really
20:56
anuejn
but reading the code involving Streams is a good start
20:56
anuejn
as streams are bundles
21:25
anuejn
tpw_rules: camera fixed :)
21:26
anuejn
all lanes seem to train sucessfully
21:26
tpw_rules
yay!
21:26
anuejn
sorry for the long delay
21:26
tpw_rules
i am busy compiling another bitstream then i will check. i assume it is on now?
21:26
anuejn
yup it is
21:26
tpw_rules
it's okay i was programming to fill the time
21:29
tpw_rules
working channel mask: 0xFFFFFFFF
21:33
anuejn
:):)
21:33
anuejn
with your training method?
21:33
tpw_rules
yes
21:33
anuejn
niiice
21:33
tpw_rules
so the fatbitstream builder seems smart enough to do nothing if the code hasn't changed; it just exits at "exiting soc code". is there a way to make it smart enough to not recompile the verilog if only the driver methods changed?
21:34
anuejn
that is a feature I also desperately want
21:34
anuejn
tho it is not entirely trivial to do
21:35
anuejn
(see https://github.com/apertus-open-source-cinema/naps/discussions/14 for really incomplete thoughts)
21:35
anuejn
let me try to implement that...
21:36
tpw_rules
what was amigen again? not sure i want to fork migen once more...
21:36
anuejn
ah I remember what the problem was:
21:37
anuejn
the cli generates a normal nmigen build plan and injects the fatbitstream generation into the nmigen generated build script
21:38
anuejn
and there is no way of running that script only partially
21:38
tpw_rules
maybe it should be wrapped instead?
21:38
anuejn
ah sounds like a good idea
21:39
tpw_rules
injecting seems kind of weird anyway
21:40
anuejn
yup and it has some seriously evil code attached to it
21:41
tpw_rules
well i got that vibe already :)
21:41
anuejn
that plus the base64 thing is probably enough to justify rewriting that logic
21:42
anuejn
there is nothing more cursed than https://github.com/apertus-open-source-cinema/naps/blob/main/naps/soc/tracing_elaborate.py which basically monkey patches nmigen during elaboration ;)
21:42
tpw_rules
while i am whining that code was giving me trouble the other day. i have a nasty habit of forgetting to `return m` and that file just threw an assertionerror with no info
21:43
anuejn
oh i see
21:43
anuejn
that seems bad
21:44
anuejn
we could and should definitely sanity check that there
21:44
anuejn
could you open an issue?
21:47
tpw_rules
sure, one moment
21:51
tpw_rules
hm, i guess nmigen does not give much more useful of a traceback, i just recognize it
21:53
tpw_rules
meh i will not bother with an issue then
21:55
anuejn
okay
21:55
anuejn
still it seems easy to catch?
21:56
anuejn
maybe also open an nmigen issue ;)
21:57
tpw_rules
the problem is that the system doesn't keep track of where the faulty value came from. nmigen just says "Object None cannot be elaborated" but the elaborate method isn't in the traceback so it's a bit useless.
21:58
tpw_rules
(naps just gives a generic AssertionError)
22:08
anuejn
I see
22:08
anuejn
tho the nmigen (or more specifically Fragment.get) has information to do a better job at error reporting than that
22:29
aombk2
joined the channel
22:32
aombk
left the channel
23:02
fredy
joined the channel
23:46
fredy
left the channel