<_whitenotifier-e>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] f623e9a - Deploying to main from @ amaranth-lang/amaranth@28139f5f4bdc328045f2e28f4126518255237645 🚀
<cr1901>
I'm kinda stuck... how would you expose remote build system config to pdm/amaranth, so that a user need not have to type out SSH params each time they want to use remote build (and not hardcode it to my machine/settings in the source code)?
<cr1901>
(Anyone who uses pdm w/ Amaranth and remote build can answer)
<iposthuman[m]>
well, i have the HRAM verilog source from Machdyne's Zucker SoC and I could adapt that to Amaranth but I'm not sure which memory resource to use as a template. i'm thinking SPIFlashResources?
<whitequark[cis]>
yeah
notgull has quit [Ping timeout: 256 seconds]
<iposthuman[m]>
speaking of Glasgow, i have no idea when i'll get mine--i wasn't in the early bird crowd.
<whitequark[cis]>
I don't either! i
<whitequark[cis]>
*I'm just maintaining the open source project
<iposthuman[m]>
Wow! i thought you would have been given super duper early version 😉
<whitequark[cis]>
I got one from the early bird batch, together with everyone else in that batch (maybe slightly earlier?)
<iposthuman[m]>
atleast my Cynthion will ship on my birthday!
<whitequark[cis]>
I also got a revC2 prototype
<_whitenotifier-e>
[amaranth] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-982-28139f5f4bdc328045f2e28f4126518255237645 - https://github.com/amaranth-lang/amaranth
<_whitenotifier-e>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] fae19ef - Deploying to main from @ amaranth-lang/amaranth@ab6503e352825b36bb29f1a8622b9e98aac9a6c6 🚀
<cr1901>
This file is meant to be a smorgasboard of "functionality I find useful for bringing up the SoC example". In the future, I hope parts of it get moved out of this file into a more shareable form, and maybe some ideas can form the basis of RFCs
<cr1901>
(E.g. icebram support for building amaranth-soc firmware would be useful, and it's something I wish litex had)
<whitequark[cis]>
hm. yes, that sounds feasible to add to the platform class. though the algorithm would have to be reimplemented
<whitequark[cis]>
typo: "prescalar" (should be "prescaler")
<cr1901>
(Noted) Q: What do you get when cross a mosquito with a mountain climber? A: You can't take the cross product of a vector and a scaler.
<cr1901>
Actually, looking at this, I don't even really remember why I do the RNG/hex file gen in Python. I think it was a combo of "I don't want to write a hexfile parser, I know it's easy, I just don't want to think", and "I don't want to depend on riscv-objcopy for the examples"
<tpw_rules>
galibert[m]: with your PLL code, is it possible to say "output 0 needs to be exactly frequency X" and then "output 1 needs to be at least frequency Y"? currently if the frequencies are not something quartus likes down to the Hz it just explodes
<tpw_rules>
(maybe it doesn't help that i specify desired frequencies in Hz?)
<galibert[m]>
Perhaps :-)
<galibert[m]>
I mean the verilog is very simple, it’s all Quartus after that
<tpw_rules>
sure, i guess i'm asking if you understand the underlying instance more and how to do that
<galibert[m]>
Ah ok :-) Ok, iirc your output frequencies must have a common multiple that's between something like 800 and 1600Mhz
<galibert[m]>
and the divider to get them must be between 1 and 511 (maybe 512, not sure)
<galibert[m]>
There's a lot more leeway on how to reach the common multiple because it's a fpll, not a simple pll. IOW, it can dither between two frequencies to get what you want
<galibert[m]>
Also there's an optional /2 in the path that could allow you to go down to 400Mhz in the common frequency (in reality, to have 2x1...2x511 divider), dunno if its activation is transparent with the instance
<galibert[m]>
also, you have multiple fplls on the die (how many depends on your model) so you can create really unrelated frequencies, but beware CDC of course
<tpw_rules>
using the multiple PLLs would require another PLL instance tho right
<tpw_rules>
multiple FPLLs
<galibert[m]>
Yeah, it's one fpll per instance
<tpw_rules>
ok
<tpw_rules>
that's just what i decided to do, make two PLL instances for my two clocks
<tpw_rules>
cause i want their frequency to be automatically calculated according to changeable design parameters
<galibert[m]>
the plls are dynamically reprogrammable, but I didn't work on that yet (I'll have to if I want to support EDID correctly...)
<tpw_rules>
i didn't mean that, i meant at verilog generation time
<galibert[m]>
Yeah, I got it
<galibert[m]>
just letting you know
<cr1901>
galibert[m]: I'll fix that, albeit it'll be "see examples/attosoc.py" for now (and possibly a code snippet connecting sentinel.top.Top to a wishbone.Decoder)