Current Server Time: 10:38 (Central Europe)

#apertus IRC Channel Logs

2021/07/16

Timezone: UTC


01:03
tpw_rules
yeah i remember it
03:36
fredy
joined the channel
03:42
fredy
left the channel
05:12
fredy
joined the channel
05:41
Bertl_oO
off to bed now ... have a good one everyone!
05:41
Bertl_oO
changed nick to: Bertl_zZ
07:53
metaldent
joined the channel
08:55
fredy
left the channel
08:55
fredy
joined the channel
10:09
anuejn
tpw_rules: very nice, will look into it :)
10:10
anuejn
looks really nice at first glance
11:56
anuejn
mithro: we cucrrently have a somewhat different design
11:57
anuejn
NeTV2 definitely looks cool
12:15
Bertl_zZ
changed nick to: Bertl
12:15
Bertl
morning folks!
12:41
metaldent
left the channel
12:45
Dest123
joined the channel
13:06
metaldent
joined the channel
14:13
kbeckmann
left the channel
14:13
aPinky
left the channel
14: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
14:20
vup
has set the topic
14:22
kbeckmann
joined the channel
15:21
Bertl
off for now ... bbs
15:21
Bertl
changed nick to: Bertl_oO
15: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
15: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?
15:52
mithro
MCMM support was in the process of getting merged recently
15:53
mithro
I forget the status of the DSPs
15:53
mithro
We are a long way towards having the GTPs done for PCIe
15:53
vup
oh not GTPs just the regular {I,O}SERDESE2
15:54
mithro
We can do a lot of stuff like the DDR memory and things
15: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
15:56
vup
I see, Ill look into trying some examples with SymbiFlow then
16:00
mithro
Your naps documentation looks really interesting!
16:07
vup
mithro: interesting meaning basically nonexistent? :)
16:12
illwieckz
left the channel
16:44
Bertl_oO
hmm, the jtag related scripts on beta-c seem to be broken
16:45
Bertl_oO
is this an issue with too old firmware?
16:54
vup
hmm in which way?
16:54
Bertl_oO
they use the old jtag interface it seems and the old hardcoded i2c addresses
16:55
Bertl_oO
but beta-b seems to be worse, I can't even get the axiom_prep_icsp.sh working there
16: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
16:58
vup
I don't think the changes were ever upstreamed into the firmware repository, because iirc there were some pending problems
16: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
16: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?
17:00
Bertl_oO
maybe, in any case, we should get the software/firmware side sorted, at least on the remote betas
17:01
vup
yeah
17: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
17:01
vup
so its now a matter of making the scripts work with it I would say
17:02
Bertl_oO
okay
17:02
lexano
left the channel
17:41
lexano
joined the channel
17:51
vup
tpw_rules: I had a first pass over your PR, great work!
17:58
tpw_rules
vup: do you have a moment to discuss the comments? i prefer here instead of github issues
17:58
vup
sure
18: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
18: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?
18: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
18: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
18: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
18:05
vup
I can see several reason for using a lower channel count on purpose:
18:06
vup
1. if you don't need the datarate, you probably save power by not using all the channels
18: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)
18:07
vup
Finally it would make testing lower channel counts easier on hardware that use more channels
18: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)
18:08
tpw_rules
okay that makes sense
18:08
tpw_rules
do you think i should rename the lanes in the platform file too then?
18:08
vup
yes
18:09
tpw_rules
also i think only lanes out_1 to out_32 are wired up right now
18:09
tpw_rules
well i am not sure, do you use all 32 channels on a single side, or 16 channels on each side?
18:10
vup
16 on each side
18:10
vup
so out_{1,3,5,...,61,63} are hooked up
18:10
tpw_rules
so what's hooked up now is out_1, out_3, out_5 etc
18: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
18:13
vup
sure, thats fine
18: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
18:15
vup
ah makes sense
18:15
vup
seems fine then
18:15
tpw_rules
register access through pydriver is very slow but it still trains faster than the original :)
18:16
vup
lol
18:16
tpw_rules
(seriously it is about 900us, can you improve it one day? :D)
18:17
vup
that pretty damn fast
18:17
tpw_rules
maybe i am complaining too much
18:18
vup
900us or 900ms?
18:18
tpw_rules
microseconds
18:18
vup
thats insanely fast
18:19
tpw_rules
the bus cycle time is 0.1us though
18:19
tpw_rules
but anyway.
18: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
18: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.
18:21
tpw_rules
https://github.com/apertus-open-source-cinema/axiom-firmware/blob/a078c76b0c1f8f04cb45788cdfaf57c9fc666304/software/sensor_tools/train/train.c#L384
18:23
vup
tpw_rules: hmm I don't see why such a window would not be possible with the current setup
18: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
18: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?
18:26
tpw_rules
ah, i thought it was > 64 taps.
18: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
18:27
tpw_rules
no, i redid it and got 51 taps too
18:27
vup
ah ok
18:28
tpw_rules
so i guess it was just an oversight in the original code. but i can definitely address it
18:28
vup
seems like an oversight, maybe Bertl_oO has some insight later
18: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
18: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
18:31
tpw_rules
the point is that the python register access is over 9,000 times slower than the actual bus transaction
18:32
vup
ah oh
18:32
vup
I thought the training was 900us, not the pydriver access
18:32
vup
I can look into that
18:32
tpw_rules
sorry. the training is a couple of seconds. one pydriver read is 900us
18:32
vup
ok makes sense
18:32
tpw_rules
i see why you thought that was very fast now
18:32
vup
heh
18: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 :)
18: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
18:35
vup
ohh yeah, thats another good one
18:35
vup
also spent hours on that once, even did that twice
18: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?
18:37
vup
good question
18:40
vup
I currently don't have a strong opinion about that
18:40
tpw_rules
i think i will leave it how it is. maybe it will become evident when i write the remapper
18:41
tpw_rules
it can always be changed
18:41
vup
yeah sounds good
18:42
vup
Oh also one thing I missed: why not use the ddr mode of the iserdes?
18:43
tpw_rules
that is how bertl did it in the original verilog too, double the frequency with the PLL and use sdr mode
18: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
18:46
vup
ok, either seems fine to me for now, was just wondering if there was some deeper reasoning, maybe Bertl_oO has one?
18:47
vup
tpw_rules: ok, do you have any more questions?
18:50
fredy
left the channel
18: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
18:51
tpw_rules
because the driver functions need access to the SPI during training
18: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
18: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
18:57
vup
tpw_rules: you can access anything under `self.` you assign in `__init__`, even non `{Status,Control}Signal`s
18:57
vup
so you could save the number of bits as `self.num_bits` or so
18:57
tpw_rules
oh, okay
19: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
19:01
vup
yeah, the atomic access thing is a bit pain point we should solve soon
19:03
tpw_rules
alright that is it. have fun!
19:06
vup
alright you too!
19:17
Dest321
joined the channel
19:21
Dest123
left the channel
19:24
Dest321
changed nick to: Dest123
20:35
metaldent
left the channel
20:51
anuejn
tpw_rules: nice work
20:51
anuejn
tho I am rather nervous about the cdc in PokeReg
21:14
tpw_rules
there is no cdc?
21: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
21:18
tpw_rules
oh, hm i think there is
21:19
tpw_rules
i meant to make that sync domain the csr reg domain
21:19
tpw_rules
anuejn: is that the hazard you spotted?
21:28
anuejn
yup
21:29
anuejn
okay then
21:29
tpw_rules
alright, thanks for catching that
21:29
anuejn
and I totally agree that we probably want to integrate that functionality into Control/Status signal strobes some time
21:29
anuejn
btw: the beta is currently disassembled on my desk but will be available soon again
21:30
anuejn
soon as in in a few minutes
21:30
tpw_rules
oh, i thought it was taking a little while to turn back on :)
21: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
21:38
anuejn
okay sounds good
21:38
anuejn
beta should be back up again
21:43
tpw_rules
anuejn: erm, less channels work than before
21:43
anuejn
dafuq?
21:43
anuejn
that does not sound good
21:44
tpw_rules
yesterday it was 2 did not successfully train and now it is 5
21:44
anuejn
wtf
21:44
anuejn
I am definitely not good at this "Hardware" thing
21:44
tpw_rules
(i tested with the original gateware too)
21:45
anuejn
Bertl_oO: to the rescue: what should I do? any tips other than dis-and reassembling the camera again?
21:45
tpw_rules
http://pastie.org/p/1GLLnGH6eVrWvY0fy5gOiE
21:45
anuejn
is there any way of detecting which connectors are faulty?
21:45
tpw_rules
yesterday the mask was 0xFFFFFF77
21:46
anuejn
meh
21:47
tpw_rules
also now clock alignment outputs all zeros because channel 3 has completely stopped working
21:51
anuejn
Okay will give it another shot
21:51
tpw_rules
ok i issued poweroff over ssh
21:51
anuejn
or do you want to use the beta now?
21:51
anuejn
tx
21:53
tpw_rules
is there documentation on Bundles anywhere?
21:56
anuejn
not really
21:56
anuejn
but reading the code involving Streams is a good start
21:56
anuejn
as streams are bundles
22:25
anuejn
tpw_rules: camera fixed :)
22:26
anuejn
all lanes seem to train sucessfully
22:26
tpw_rules
yay!
22:26
anuejn
sorry for the long delay
22:26
tpw_rules
i am busy compiling another bitstream then i will check. i assume it is on now?
22:26
anuejn
yup it is
22:26
tpw_rules
it's okay i was programming to fill the time
22:29
tpw_rules
working channel mask: 0xFFFFFFFF
22:33
anuejn
:):)
22:33
anuejn
with your training method?
22:33
tpw_rules
yes
22:33
anuejn
niiice
22: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?
22:34
anuejn
that is a feature I also desperately want
22:34
anuejn
tho it is not entirely trivial to do
22:35
anuejn
(see https://github.com/apertus-open-source-cinema/naps/discussions/14 for really incomplete thoughts)
22:35
anuejn
let me try to implement that...
22:36
tpw_rules
what was amigen again? not sure i want to fork migen once more...
22:36
anuejn
ah I remember what the problem was:
22:37
anuejn
the cli generates a normal nmigen build plan and injects the fatbitstream generation into the nmigen generated build script
22:38
anuejn
and there is no way of running that script only partially
22:38
tpw_rules
maybe it should be wrapped instead?
22:38
anuejn
ah sounds like a good idea
22:39
tpw_rules
injecting seems kind of weird anyway
22:40
anuejn
yup and it has some seriously evil code attached to it
22:41
tpw_rules
well i got that vibe already :)
22:41
anuejn
that plus the base64 thing is probably enough to justify rewriting that logic
22: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 ;)
22: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
22:43
anuejn
oh i see
22:43
anuejn
that seems bad
22:44
anuejn
we could and should definitely sanity check that there
22:44
anuejn
could you open an issue?
22:47
tpw_rules
sure, one moment
22:51
tpw_rules
hm, i guess nmigen does not give much more useful of a traceback, i just recognize it
22:53
tpw_rules
meh i will not bother with an issue then
22:55
anuejn
okay
22:55
anuejn
still it seems easy to catch?
22:56
anuejn
maybe also open an nmigen issue ;)
22: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.
22:58
tpw_rules
(naps just gives a generic AssertionError)
23:08
anuejn
I see
23:08
anuejn
tho the nmigen (or more specifically Fragment.get) has information to do a better job at error reporting than that
23:29
aombk2
joined the channel
23:32
aombk
left the channel
00:02
fredy
joined the channel
00:46
fredy
left the channel