#apertus IRC Channel Logs

yeah i remember it

off to bed now ... have a good one everyone!

looks really nice at first glance

NeTV2 definitely looks cool

morning folks!

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?

I forget the status of the DSPs

oh not GTPs just the regular {I,O}SERDESE2

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

Your naps documentation looks really interesting!

is this an issue with too old firmware?

they use the old jtag interface it seems and the old hardcoded i2c addresses

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

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

maybe, in any case, we should get the software/firmware side sorted, at least on the remote betas

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

okay

vup: do you have a moment to discuss the comments? i prefer here instead of github issues

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

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

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

1. if you don't need the datarate, you probably save power by not using all the channels

Finally it would make testing lower channel counts easier on hardware that use more channels

okay that makes sense

yes

well i am not sure, do you use all 32 channels on a single side, or 16 channels on each side?

so out_{1,3,5,...,61,63} are hooked up

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

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

seems fine then

lol

that pretty damn fast

900us or 900ms?

thats insanely fast

but anyway.

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.

tpw_rules: hmm I don't see why such a window would not be possible with the current setup

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?

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

ah ok

seems like an oversight, maybe Bertl_oO has some insight later

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

ah oh

I can look into that

ok makes sense

heh

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

also spent hours on that once, even did that twice

good question

i think i will leave it how it is. maybe it will become evident when i write the remapper

yeah sounds good

that is how bertl did it in the original verilog too, double the frequency with the PLL and use sdr mode

ok, either seems fine to me for now, was just wondering if there was some deeper reasoning, maybe Bertl_oO has one?

because the driver functions need access to the SPI during training

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

so you could save the number of bits as `self.num_bits` or so

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

alright that is it. have fun!

tpw_rules: nice work

there is no cdc?

oh, hm i think there is

anuejn: is that the hazard you spotted?

okay then

and I totally agree that we probably want to integrate that functionality into Control/Status signal strobes some time

soon as in in a few minutes

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

beta should be back up again

dafuq?

yesterday it was 2 did not successfully train and now it is 5

I am definitely not good at this "Hardware" thing

Bertl_oO: to the rescue: what should I do? any tips other than dis-and reassembling the camera again?

is there any way of detecting which connectors are faulty?

meh

Okay will give it another shot

or do you want to use the beta now?

is there documentation on Bundles anywhere?

but reading the code involving Streams is a good start

tpw_rules: camera fixed :)

yay!

i am busy compiling another bitstream then i will check. i assume it is on now?

it's okay i was programming to fill the time

:):)

yes

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?

tho it is not entirely trivial to do

let me try to implement that...

ah I remember what the problem was:

and there is no way of running that script only partially

ah sounds like a good idea

yup and it has some seriously evil code attached to it

that plus the base64 thing is probably enough to justify rewriting that logic

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

that seems bad

could you open an issue?

hm, i guess nmigen does not give much more useful of a traceback, i just recognize it

okay

maybe also open an nmigen issue ;)

(naps just gives a generic AssertionError)

tho the nmigen (or more specifically Fragment.get) has information to do a better job at error reporting than that