let's get Variable delay merged

[cozzyd]

and then a release drafted?

[barawn]

I'm probably going to have to cherry-pick stuff and move it in rather than just using Git stuff thanks to Xilinx stupidity. Hopefully once I finish the repo tools migration branches/merges will be easier.

[cozzyd]

nitpick, but can we also update the minor version again? There are now two different v0.4.0 firmwares running around (one which locks up...)

[barawn]

yeah, the 2022.2 build, with no other changes, will be 0.5.0 and then merging the variable delay branch should probably be 0.6.0 even

[barawn]

let's see how Git tools handles stuff...

[barawn]

the 2022_2_migration branch builds at this point and is using the repo tools, so it might be as simple as just merging it to the other one. I'll have to resolve the version number and README conflicts again I think

[barawn]

@cozzyd The merge seems like it worked but I need to tweak the build directives a bit to get it to build reliably and meet timing.

[cozzyd]

on that note, while this firmware is meant to run at 2.4 GSPS, there was no corresponding change to the constraints file (maybe that's what you mean by "build directives.") I don't anticipate any future desire to run at 3.2 GSPS, but maybe it's not too hard to parametrize that somehow?

[barawn]

Uh, I don't see any changes to the constraints file even in this pull. Did anyone at PSU actually change the constraints to step it back? The base sysclk is still listed at 25 MHz.

There are ways in Vivado to test if a design works at slower clocks but I never tried automating it. I'll see what I can do.

[cozzyd]

Yeah sorry that's what I meant either the constraints weren't modified or not pushed. As you mentioned in your other post, hopefully the SPI bus will still work glitch free at full speed (48 MHz) even with a slower base clock.

On April 2, 2024 5:33:11 PM CDT, Patrick Allison @.***> wrote:

Uh, I don't see any changes to the constraints file even in this pull. Did anyone at PSU actually change the constraints to step it back? The base sysclk is still listed at 25 MHz.

There are ways in Vivado to test if a design works at slower clocks but I never tried automating it. I'll see what I can do.

-- Reply to this email directly or view it on GitHub: https://github.com/RNO-G/firmware-radiant/pull/15#issuecomment-2033215856 You are receiving this because you were mentioned.

Message ID: @.***>

[barawn]

No, I segregated off all the derived clocks from sysclk a while ago. The trigger (400M), SPI clock (300M), and the Wilkinson clock (200M) need to stay fixed regardless of sysclk, so they're derived from the 50M onboard clock rather than the input system clock.

[barawn]

0.6.0 rebuild is in the releases as a pre-release

although I don't remember what you need to program it? the bin file is there, I can't remember if you guys use that or an MCS or something

[cozzyd]

The flashing script expects an .mcs (see https://github.com/RNO-G/radiant-python/blob/summit-branch/examples/build_image.sh) but it probably can be modified as needed (is an offset required?)

[cozzyd]

actually wait it can take either, I've only used it with .mcs though

[cozzyd]

It looks like it converts .mcs files to .bin files, but they're padded to a certain size. Does that mean that a .bin file must also be padded properly?

[cozzyd]

I guess since they're catted together, the answer is obviously yes. I'll modify the script to pad the bin files if needed.

[barawn]

They definitely need to be padded, they're always going to be random length. You're just building up a binary image the full size of the SPI flash.

I just realized I need to check to see if the bin file that gets generated actually has the SPI header stuff in it though...

[barawn]

yup, just checked, they're identical. That's useful to know because I can make the bin file autogenerated in the build process but the MCS requires an extra step. I'll add the v0r6p0 MCS file though so you can compare the two processes and make sure they're identical

[cozzyd]

No, I segregated off all the derived clocks from sysclk a while ago. The trigger (400M), SPI clock (300M), and the Wilkinson clock (200M) need to stay fixed regardless of sysclk, so they're derived from the 50M onboard clock rather than the input system clock.

Looking at https://github.com/RNO-G/firmware-radiant/blob/master/hdl/rad_id_ctrl.v#L586 Does this actually care if the period specified for the input clock isn't correct? Or if it's slower it's probably fine? (it specifies 40 ns still).

I guess another change I didn't appreciate until now (though it's obvious) is that since sys_clk is used for trigger timestamping, the granularity is slightly reduced. I guess this isn't such a big deal (13.33 ns is still plenty good, I think), but it might surprise some people that sys_clk_last_pps - sys_clk_last_last_pps is now ~75 MHz.

[barawn]

sigh, I should probably add this stuff to my personal wiki so I don't have to constantly look it up:

I think the CLKIN1_PERIOD specification there is so that the design rule check (DRC) can directly verify that the VCO inside the MMCM is within range - for the RADIANT I think it's 600-1440 MHz since it's speed grade 2. The VCO's frequency is fin*(M/D) where M is CLKFBOUT_MULT_F and D is DIVCLK_DIVIDE, which are 40 and 1 respectively there. I don't think it uses it for anything other than that - at least from the timing results I saw the outputs are still timed at the lower clock input when you change the input period spec.

At 25 MHz, the VCO is 1 GHz, and at 18.75 MHz it's 750 MHz, so thankfully still within range.

It's probably worth noting somewhere that the event timestamp isn't the time of the trigger, it's just synchronizing the event in time. You could attempt to record the actual time of the trigger (which is always running at 2.5 ns granularity) but I don't understand the point of that because you can rederive a trigger condition with the waveform to even higher precision than that (although I constantly underestimate other people's desire to avoid having to do work, ha).