<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 597494a - Deploying to main from @ amaranth-lang/amaranth@598cf8db287c42e9ea97aa82fda8d8f9d7fb68b6 🚀
<mcc111[m]>
Asking these last couple questions because I'd eventually like to hook up hdmi (ideally driven by the fpga somehow) and usb host, and it doesn't seem to have these things (although it has something I've never heard of called "SYZYGY" and it also has an M.2 connector, so maybe I can get what I want with those)
<mcc111[m]>
(These are general fpga questions not amaranth questions, hope that's ok, but my like step 3 in setting it up is gonna be trying to run amaranth on it
<tpw_rules>
i assume they mean the usb-c has OTG support
<tpw_rules>
which idk if that's really a term for usb-c
<tpw_rules>
isn't the synthesis tools for those completely closed and licensed
<whitequark[cis]>
OTG does not apply to USB type-C at all
<whitequark[cis]>
"SerDes" can mean a bunch of different things depending on the vendor but you probably don't need those for HDMI
<whitequark[cis]>
however if you did drive HDMI with those, well, you can probably do like, 8K@60?
<mcc111[m]>
tpw_rules: they claim i get a license because i bough tthe board
<Wanda[cis]>
hm, are there plans to migrate lib.{cdc,coding,crc} to be lib.wiring-based (I assume with lib.fifo we're waiting for streams)?
lf has quit [Ping timeout: 264 seconds]
<tpw_rules>
mcc111[m]: yeah, it just makes the "revolutionary new open source horizons" ring a bit hollow
<whitequark[cis]>
Wanda: lib.cdc and lib.crc yeah. lib.coding should be deprecated and removed
<whitequark[cis]>
actually for lib.crc we're also kinda vaguely waiting on streams
<mcc111[m]>
tpw_rules: It's unclear to me if the USB-C can be used or host or only for client. I'm still early in looking at the docs…
<mcc111[m]>
I assume I'd have to supply power through the screw terminals because it looks like USB-C is how I'm expected to power it to start?
<tpw_rules>
"DO NOT APPLY VOLTAGE TO ANY I/O PIN WHEN POWER IS NOT SUPPLIED TO THE BOARD. IT WILL DAMAGE THE PROCESSOR AND VOID THE WARRANTY." scary
<whitequark[cis]>
the power part and the data part of USB-C is basically separate
<whitequark[cis]>
you can have a host that is a power sink
<tpw_rules>
they don't seem to document the syzygy connector at all, but it is a recognized standard:
<mcc111[m]>
whitequark[cis]: nice
<Wanda[cis]>
"deprecated and removed", now that I can easily do
<whitequark[cis]>
nice :3
<mcc111[m]>
tpw_rules: I agree, but also I don't know of a second device that has the specific properties this device has so I'm still excited.
<whitequark[cis]>
for the removal reason, basically, we probably want that functionality to be available in something lighter than a function
<tpw_rules>
mcc111[m]: what sort of properties?
<whitequark[cis]>
considering that most of those are one-line and you need more than one-line to invoke them
<whitequark[cis]>
* than a module, like an (Amaranth) function
<whitequark[cis]>
however since we don't have the ability to have function scopes yet, we can't replace it with that
<whitequark[cis]>
also it's not just super useful functionality
<tpw_rules>
mcc111[m]: i kinda wanted one for cursed nix stuff, do you intend on digging into the linux much at all?
lf has joined #amaranth-lang
<tpw_rules>
i still need to boot my vision five though
<tpw_rules>
cause if you want a pocket-alike with those other properties, de10 nano all the way
lf has quit [Ping timeout: 256 seconds]
omnitechnomancer has joined #amaranth-lang
<omnitechnomancer>
The usb-c port is attached via a ulpi PHY to the MSS io block so I expect there is a USB2 controller in the CPU complex
lf has joined #amaranth-lang
<mcc111[m]>
<tpw_rules> "cause if you want a pocket-alike..." <- MiSTER isn't exactly open hardware either :(
<mcc111[m]>
idk SOMEDAY i'll figure out how to get these usb host ports built for my colorlight…
<galibert[m]>
mcc111: it's close, you have all the schematics of the nano
<tpw_rules>
at least it does not require a license
<whitequark[cis]>
but no layout?
<whitequark[cis]>
that's not OSHW
<galibert[m]>
it's not
<whitequark[cis]>
and you can't reuse it afaik
<galibert[m]>
but it's well documented
<whitequark[cis]>
those are orthogonal?
<galibert[m]>
yeah, but you don't have schems for the pocket afaik
<tpw_rules>
looks like the beagle v fire has published gerbers but it doens't seem that it's proper OSHW
<tpw_rules>
or at least all i can find is "terms and conditions"
<mcc111[m]>
tpw_rules: *scrunching up face* quartus has a free tier but is it really correct to say it does not require a license
<galibert[m]>
you don't need to talk with altera to use it
<tpw_rules>
^
<tpw_rules>
i don't have to do mac address gymnastics or whatever either. i just execute it and it makes the file
<whitequark[cis]>
any fpga toolchain can be easily set up in this manner :)
<tpw_rules>
yes i know i've done that too
<mcc111[m]>
i mean clearly the situation with beaglev fire is seriously problematic but it's like, if i want something ideologically correct for correctness's sake i still think it looks more like the colorlight than the de10
<tpw_rules>
i see. i think my 2 cents are just that the de10 nano is a lot more practical and rather similar ideologically, but i don't want to cramp your style and i'm interested of hearing about your journey
<tpw_rules>
(and annoyed by its fpga situation in general, but i don't judge purchasers about that one)
<tpw_rules>
i do want to make my own opengl gpu some day too incidentally
<tpw_rules>
idk if you ever read ryg's blog posts about rasterization and GPU structure
<galibert[m]>
I recommend you go for vulkan instead, must easier
<tpw_rules>
i've never actually programmed vulkan
<tpw_rules>
it took me a while to make it to shaders :)
<tpw_rules>
if you have a tutorial i'm all ears
<mcc111[m]>
i have attempted to program vulkan and it's a fucking nightmare, but partially for the reasons that it is a nightmare to program i think it might be relatively (???) easy to implement
<galibert[m]>
yeah, it's way closer to the hardware
<omnitechnomancer>
The OTG seems to be in reference to the USB controller inside the SoC they have an ID line hooked to the ulpi PHY from the CC chip
<mcc111[m]>
I am mildly considering attempting to design a version of webgpu that can bypass vulkan and talk directly to the gpu, but that seems… like a bad idea… and also I'd probably have to learn to write drivers… but also I want to learn to write Linux drivers for unrelated reasons… so I don't know.
<whitequark[cis]>
omnitechnomancer: yep sounds about right
<whitequark[cis]>
it's ... not very useful
<mcc111[m]>
omnitechnomancer: OK thanks. So how would I actually use this?
<mcc111[m]>
or does this come back to "the usb-c can run as either host or client" (I thought this was something USBC could always do?!)
<mcc111[m]>
> <@_discord_157742445801504768:catircservices.org> The OTG seems to be in reference to the USB controller inside the SoC they have an ID line hooked to the ulpi PHY from the CC chip
<mcc111[m]>
* OK thanks. So how would I actually use this, in the sense of connecting devices?
<mcc111[m]>
or does this come back to "the usb-c can run as either host or client" (I thought this was something USBC could always do?!)
<omnitechnomancer>
You should be able to convince the USB controller to run in host mode though
<mcc111[m]>
<tpw_rules> "i see. i think my 2 cents are..." <- anyway if my pocket cores become successful (unlikely) i'll probably feel compelled to port them to mister, so maybe i'm getting a mister at some point anyway.
<tpw_rules>
mcc111[m]: fwiw i do not have a mister and have not used their system or libraries at all
jjsuperpower_ has quit [Ping timeout: 256 seconds]
<whitequark[cis]>
Wanda: the componentization of `lib.cdc` is going to be ... problematic
<whitequark[cis]>
given how they currently take signals in the constructor
<Wanda[cis]>
... yeah
<whitequark[cis]>
sure, you could assign them in elaborate, but assigning your own input is fairly unprecedented
<whitequark[cis]>
and the precedent would be pretty bad
<whitequark[cis]>
also it's just verbose
<Wanda[cis]>
I think we can just deprecate the signal arguments in the constructor?
<whitequark[cis]>
that's the "verbose" part
<whitequark[cis]>
writing stdio cores with lots of synchronizers is going to take 3x more space
<whitequark[cis]>
and it's pretty verbose in first place
<whitequark[cis]>
kind of a pain :S
<tpw_rules>
i definitely like them taking signals in the constructor, what exactly is wrong with that?
<tpw_rules>
oh you mean turning into a wiring.Component
<whitequark[cis]>
not compatible with lib.wiring
<tpw_rules>
what is the benefit of that? you could connect(m, ...) through e.g. a synchronizer?
<whitequark[cis]>
well, if we say that you should basically always use wiring.Component for your modules, our standard library better do that uniformly
<tpw_rules>
oh, i didn't know that that was said
<tpw_rules>
i thought not even Elaboratable was mandatory
<whitequark[cis]>
well, a lot of people are really enthusiastic for doing that, like galibert
<whitequark[cis]>
and right now the guide says > The Amaranth standard library provides components: elaboratable objects that also include a description of their interface. Unless otherwise necessary, an elaboratable should inherit from amaranth.lib.wiring.Component rather than plain Elaboratable.
<tpw_rules>
i think it's nice in a lot of cases, sure
<tpw_rules>
idk i think making it uniform in the standard library is not necessary, especially if it makes things harder to use
<whitequark[cis]>
Elaboratable actually should probably be mandatory, there's basically no reason to not require it. it's vestigial
<tpw_rules>
that's where kind of weird things can happen sometimes
<whitequark[cis]>
tpw_rules: well, again, if we say that `wiring.Component` is *the* way to go, we should follow our own advice
<whitequark[cis]>
the standard library is supposed to be better than downstream code, not worse
<tpw_rules>
if it can be a bit grody to make downstream code better i think that's okay
<whitequark[cis]>
if we do not say that we need clear guidelines on when to use wiring.Component and when to use Elaboratable
<whitequark[cis]>
tpw_rules: I don't
<whitequark[cis]>
the standard library must be exemplary in both the interface and the implementation
<whitequark[cis]>
because it sets the standard for everyone who looks at it
<tpw_rules>
do people often look at software standard libraries?
<whitequark[cis]>
irrelevant question, amaranth.lib is explicitly designed separate from the core language rather than tied to it
<whitequark[cis]>
so the only thing that's "standard" about it is that it ships with the language, rather than being privileged by it
<tpw_rules>
so it's sort of a more reference library
<whitequark[cis]>
also, people look at the Amaranth library a lot, historically, because we haven't bothered documenting shit for years
<tpw_rules>
that is probably true
<whitequark[cis]>
as well as other pieces of the implementation. I mean you look at the CSR sources constantly
<whitequark[cis]>
you should read the Rust standard library sources sometime
<tpw_rules>
my specific 2 cents are that trying to remove constructor arguments of objects in `lib.cdc` is not a great move. but i'll let you ponder that, it's my bedtime
<whitequark[cis]>
I've seen research papers with both worse writing and less rigor
<tpw_rules>
most research papers are like that :P
<whitequark[cis]>
tpw_rules: sure, if it was obviously a way to go, I would've done it already
<tpw_rules>
i think most of my rust experience has been without std funnily enough
<whitequark[cis]>
core is the rust standard library
<whitequark[cis]>
dunno what that "std" thing is
<whitequark[cis]>
anyway, I don't know whether keeping those things in lib.cdc is worth writing out a long document indicating when you'd want to use Elaboratable and when Component
<whitequark[cis]>
because if we keep them we'll have to either write it, or contend with people inventing their own folk knowledge about when to use one or the other, which is worse
<tpw_rules>
maybe that is another thing that needs postponement to when functions are possible
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 0c3ad9c - Deploying to main from @ amaranth-lang/amaranth@d6bf47d5496da964afbd306f9ac3ca900607f04d 🚀
<_whitenotifier-6>
[amaranth-lang/rfcs] whitequark be678ae - Update table of contents in README.
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] whitequark 8434662 - Deploying to main from @ amaranth-lang/rfcs@be678ae6279ef0c09504c1bac3bdd659e3e5dc8f 🚀
<whitequark[cis]>
>>> f"abc{a # This is a comment }"
<whitequark[cis]>
... + 3}"
<whitequark[cis]>
'abc5'
<omnitechnomancer>
And someone decided they had a burning need for comments in f string replacements?
<omnitechnomancer>
Not having anything except line comments does mean that is the expected result
<whitequark[cis]>
I imagine it was probably a result of making the lexing more regular
<whitequark[cis]>
but still, it looks unhinged
<galibert[m]>
Very pythonic :-)
<zyp[m]>
the way I see it, a natural divide between Elaboratable and Component is whether it should have a signature or not, but RFC #45 already set a precedent for making components with empty signatures
<zyp[m]>
and if we follow that, the discussion isn't whether something should be an Elaboratable or a Component, but whether we should put things in the signature or take stuff as constructor arguments and have an empty signature
<whitequark[cis]>
that's actually a good point
<zyp[m]>
and we could do both, we could add stuff to the signature iff it's not passed via constructor arguments
<_whitenotifier-6>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 946758a - Deploying to main from @ amaranth-lang/amaranth@25698864645e711ae337c097cdb65bdf71462b3d 🚀
<tpw_rules>
omnitechnomancer: python has adjacent string concat like C so it's easy to just make a bunch of lines of f strings...
<omnitechnomancer>
Sure
<omnitechnomancer>
Having had a look at the device trees for the SoC in linux the USB controller in there seems to be the same as was in some TI parts and seems ill suited to general USB host stuff
<whitequark[cis]>
wrong channel?
peeps[zen] has joined #amaranth-lang
<omnitechnomancer>
Follow up from PolarFire stuff earlier
<zyp[m]>
the reply reference didn't carry over from discord to matrix
eldiem has joined #amaranth-lang
<mcc111[m]>
Hey so another general question if it's ok. The Microchip/BeagleFire people are recommending I buy a FlashPro5 or FlashPro6 dongle and they're a little expensive and I kind of don't want to.
<mcc111[m]>
Are there $5 aliexpress clones for this?
<mcc111[m]>
Alternately, can the Glasgow replace the FlashPro5? Is this when I finally get around to getting a Glasgow?
<mcc111[m]>
* FlashPro6 dongle for flashing/debugging the Microchip and they're
<whitequark[cis]>
it's just a JTAG adapter right?
<whitequark[cis]>
glasgow should work
<whitequark[cis]>
looks like it only does JTAG and SPI, so Glasgow will do that
<_whitenotifier-5>
[amaranth-lang/amaranth-lang.github.io] whitequark a50fea5 - Deploying to main from @ amaranth-lang/rfcs@43f8f04e2a563381573c9e6cc9b12a67ac8f71fb 🚀
ldcd[m] has joined #amaranth-lang
<ldcd[m]>
If you have a beaglebone black or raspberry pi you can use those for programming and they are officially supported
frgo has joined #amaranth-lang
<ldcd[m]>
* officially supported. The expensive part is the tag connect cable which I think is patent encumbered and clones are harder to find.
<mcc111[m]>
<ldcd[m]> "If you have a beaglebone black..." <- Oh, so does that mean that it's maybe not going to cost much more to just buy a real FlashPro
<ldcd[m]>
I didn't think the flash pro comes with a tag connect cable
<ldcd[m]>
I have a (to be honest probably counterfeit given what I payed but it works) tag connect cable and have been using my black magic probe but you should be able to get pretty much anything to work
<ldcd[m]>
Yeah the implementation is not my favorite but it does exist
<ldcd[m]>
Oh completely unrelated question
<ldcd[m]>
Is there any scenario you can think of where pysim should be non deterministic with the same module and a deterministic test bench
<whitequark[cis]>
just one testbench?
<ldcd[m]>
Yeah
<whitequark[cis]>
sounds like a bug
<ldcd[m]>
Ok I'll try and make a minimal test case
<ldcd[m]>
I get it in both 0.4.4 and main
<whitequark[cis]>
zyp: when would a stream need to assert `ready` in response to `valid`, but not otherwise?
<tpw_rules>
(isn't that illegal in axi?)
<whitequark[cis]>
the opposite is illegal
<whitequark[cis]>
ready in response to valid is legal, for some weird reason
<tpw_rules>
i mean prohibiting the otherwise
<whitequark[cis]>
"not otherwise" = "keep it deasserted the rest of the time"
<ldcd[m]>
My guess would be power gating
<ldcd[m]>
You can only have one of the two and ready in response to valid makes more sense than the converse if you want to power down a peripheral until it's used
<whitequark[cis]>
that sounds implausible
<ldcd[m]>
I guess clock gating is more realistic from a latency perspective but I have never actually seen it used that way
<zyp[m]>
<whitequark[cis]> "zyp: when would a stream need to..." <- maybe a stream arbiter, where valid would act as a request and ready would act as a grant
<zyp[m]>
with add_testbench your code passes with zero failures
<zyp[m]>
I suspect the nondeterminism comes from the racing tasks being sorted by hashes derived from memory addresses, which will vary from execution to execution
<ldcd[m]>
ok I was wondering if I needed to insert a delta cycle somewhere
<polysci_00232[m]>
Im wondering if anyone has resources on good potential options for amaranth code style guides. Or if anyone has found a particular python formatter to work well with amaranth projects