<whitequark[cis]>
i've corresponded with the author already :D
<whitequark[cis]>
their code looks really impressive
<adamgreig[m]>
looks like a really fun project
Hoernchen has joined #amaranth-lang
Hoernchen_ has joined #amaranth-lang
Hoernchen has quit [Ping timeout: 272 seconds]
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 252 seconds]
Degi_ is now known as Degi
<mcc111[m]>
<adamgreig[m]> "amaranth spotted in the wild..." <- ohhhh, this is of interest to me
<mcc111[m]>
so far every attempt of mine to set up "a cpu connected to a DAC" has been a failure lolsob
<mcc111[m]>
* to a DC coupled DAC" has
<mcc111[m]>
the closest i got was a SAMD device which had an unacceptable noise floor and an LED screen which would scroll randomly every few seconds
<whitequark[cis]>
mcc111: i was gonna link it to you
<whitequark[cis]>
the design looks incredible from both a hardware and a gateware standpoint
<whitequark[cis]>
the hardware is basically at the point where i don't think there is anything you could even dream of cramming into that much space
<mcc111[m]>
I am intrigued by the "Ex0" and "Ex1" ports.
<whitequark[cis]>
it feels, essentially, done. as in you could make another FPGA based module but like why?
<whitequark[cis]>
those are normal pmods
<whitequark[cis]>
it's 8 digital I/O
<whitequark[cis]>
it also has expansion to 24 voice channels
<tpw_rules>
the fpga board is very cute, though i assume not real m.2
<whitequark[cis]>
no
<whitequark[cis]>
i think just a way to avoid going 6L + blind vias on the entire design
<mcc111[m]>
whitequark[cis]: i actually have an existing fpga based module called a "chainsaw" I was considering trying to hack alternate firmware for but this is much nicer
<whitequark[cis]>
video synthesis and touch/proximity on all 8 jacks is just the cherry on top
<mcc111[m]>
is the knob also a pressable button, btw?
<tpw_rules>
is that really what you need for even an ecp5 25k
<whitequark[cis]>
in that space? yes
<tpw_rules>
our lab is planning to invest money into developing fpga boards and i think it's going to be a rough journey...
<tpw_rules>
have you or maybe maya ever done big pcb design and assembly like that?
<whitequark[cis]>
the button is in fact pressable
<whitequark[cis]>
maya has extensive experience with electronics design and manufacturing
<whitequark[cis]>
the type-C connector ("usb2") can do both device and host
<tpw_rules>
is matrix still a good way to contact her?
<whitequark[cis]>
teag
<whitequark[cis]>
* yeah
<tpw_rules>
okay thanks, i might do that then
<tpw_rules>
that does look really awesome even as just a general dev board
<adamgreig[m]>
with more board space you can easily do cheap 4L and normal vias for ecp5, moreso if you don't need to use every single pin
<adamgreig[m]>
but doing double-sided dense assembly on the smallest possible board while routing out a lot of the IO, yea, that part needs higher spec PCBs
<adamgreig[m]>
the touch sensitive jacks is such a clever idea
<whitequark[cis]>
it's super cool
<whitequark[cis]>
honestly the whole project seems incredibly well put together and with a lot of care
<whitequark[cis]>
i'm deeply impressed
<adamgreig[m]>
yea, it looks really slick
<adamgreig[m]>
i wish i was into modular synths so i could get one
<adamgreig[m]>
making it a usb sound card and also hdmi out is inspired too
<whitequark[cis]>
i decided im into modular synths now
<adamgreig[m]>
trademark-free hdmi anyway lol
<whitequark[cis]>
the legally distinct hdmi was really funny yes
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 276 seconds]
Degi_ is now known as Degi
<jfng[m]>
<adamgreig[m]> "amaranth spotted in the wild..." <- it would make the perfect gift for a friend of mine, maybe for 2025!
Hoernchen_ is now known as Hoernchen
Hoernchen has quit [Ping timeout: 245 seconds]
d_olex has quit [Ping timeout: 252 seconds]
Hoernchen has joined #amaranth-lang
d_olex has joined #amaranth-lang
Hoernchen has quit [Remote host closed the connection]
Hoernchen has joined #amaranth-lang
<cr1901>
Does cxxrtl have the same semantics for the Python simulator (in that "when you change the value of a signal within the c++ API, the change happens immediately and not at the next active clock edge)?
<cr1901>
If so, has cxxrtl always had this semantics since before RFC 36?
<whitequark[cis]>
cxxrtl isn't affected by RFC 36 as far as I know (since it's a completely unrelated C++ project)?
<cr1901>
So, cxxrtl has always had the "signal change happens immediately" semantics?
<whitequark[cis]>
I think so, if I understand the question
<cr1901>
I always had trouble getting cxxrtl to work whenever I tried using it. I just realized this morning that was probably using it wrong (TM) the entire time, and changing my Python sims to after RFC 36 helped with that.
<whitequark[cis]>
oh.
<whitequark[cis]>
you expected it to have the same behavior as the Migen simulator?
<whitequark[cis]>
yeah, that would absolutely not work, heh
<whitequark[cis]>
CXXRTL was inspired by the new Amaranth simulator core, which was in turn inspired by how bad the Migen simulator core was to use
<whitequark[cis]>
which is to say, it was working around the exact yield semantics issue
<whitequark[cis]>
like in some ancestral level
<zyp[m]>
speaking of cxxrtl, how does the roadmap look now for cxxsim?
<cr1901>
Now that I realize I was using it wrong (tm), this opens some opportunities
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] github-merge-queue[bot] 9167603 - Deploying to main from @ amaranth-lang/amaranth@ba1860553cacfbb5d358f9a9e0699fb7efce0451 🚀
<_whitenotifier-3>
[amaranth-lang/amaranth-lang.github.io] whitequark 8423c11 - Deploying to main from @ amaranth-lang/playground@10cce9addbce3c5c4fbf3378d3ca1f8544223039 🚀