<mwk>
(not waiting on any clock edges or anything)
<alyssa>
and once the whole network settles both intermediate and final will be what I expect them to be
<mwk>
yup
<alyssa>
got it
<alyssa>
electronics are scary but maybe not /that/ scary :-p
* alyssa
cowers
<whitequark>
:3
<mwk>
hey, you looked upon GPUs already, IME making own electronics is nothing compared to that :p
* alyssa
cries in wanting to make own GPU
<mwk>
... seems to be a common side-effect of looking upon them
<alyssa>
(Eventually. Need to learn how the wires and the volts work first :-p)
* alyssa
meditates on electronics
<alyssa>
ohm...
cr1901_ is now known as cr1901
<tpw_rules>
this probably doesn't sound very helpful but try to picture the wires and gates you're getting
<tpw_rules>
and muxes and latches
<adamgreig[m]>
and then watch as yosys optimises your logic to something else anyway :P
<adamgreig[m]>
(though i agree with it being a helpful way to design the circuit, definitely, and yosys keeps equivalence)
<alyssa>
tpw_rules: nah, that's helpful :+1:
<alyssa>
and yes I can picture the schematic of, computing final directly but having an extra wire poking out for intermediate ("intercepting" the result)
<alyssa>
tpw_rules: realized the bug my unit test picked up a few days ago that I dismissed was in fact a real bug with a simple fix
<alyssa>
drawing out the schematics for before/after is informative
<alyssa>
(two lines of useful HDL and still managed to botch it, I'm new :-o)
bl0x_ has quit [Ping timeout: 250 seconds]
<alyssa>
thank you :)
bl0x_ has joined #amaranth-lang
RobertJrdens[m] has quit [K-Lined]
mikolajw has quit [K-Lined]
modwizcode has quit [K-Lined]
jfng[m] has quit [K-Lined]
esden[m] has quit [K-Lined]
disasm[m] has quit [K-Lined]
pho has quit [K-Lined]
xiretza[m] has quit [K-Lined]
jevinskie[m] has quit [K-Lined]
egg|matrix|egg has quit [K-Lined]
cesar has quit [K-Lined]
adamgreig[m] has quit [K-Lined]
whitequark has quit [K-Lined]
<cr1901>
Did all of matrix k-line or just some?
Degi_ has joined #amaranth-lang
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
egg|matrix|egg has joined #amaranth-lang
nelgau has joined #amaranth-lang
egg|matrix|egg has quit [Quit: Client limit exceeded: 20000]
whitequark has joined #amaranth-lang
cesar has joined #amaranth-lang
xiretza[m] has joined #amaranth-lang
pho has joined #amaranth-lang
mikolajw has joined #amaranth-lang
RobertJrdens[m] has joined #amaranth-lang
disasm[m] has joined #amaranth-lang
jevinskie[m] has joined #amaranth-lang
esden[m] has joined #amaranth-lang
adamgreig[m] has joined #amaranth-lang
jfng[m] has joined #amaranth-lang
modwizcode has joined #amaranth-lang
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #amaranth-lang
bvernoux has joined #amaranth-lang
Vonter has quit [Ping timeout: 250 seconds]
Vonter has joined #amaranth-lang
Vonter has quit [Ping timeout: 245 seconds]
Vonter has joined #amaranth-lang
<FL4SHK>
hello
<FL4SHK>
I just found out about the name change
<FL4SHK>
Or, well, I just found out what it is
egg|matrix|egg has joined #amaranth-lang
<FL4SHK>
I have been working on my roguelike in my spare time exclusively lately
<FL4SHK>
so I haven't been writing HDL code outside of work
<FL4SHK>
my roguelike is progressing smoothly... working on it in C++
<FL4SHK>
anyway
<FL4SHK>
cheers
Bluefoxicy has joined #amaranth-lang
<Bluefoxicy>
Hi, Vivado seems to not like the code generated by my trivial carry-save example
<Bluefoxicy>
it seems to find `input [31:0] A` okay, but `input SubA` or `input clk` just complain that a non-net port cannot be of mode input, and fails
<tpw_rules>
how are you getting it into vivado?
<Bluefoxicy>
copied the .v file and told it it's a Verilog source file
<tpw_rules>
which you exported using back.verilog from amaranth? hm
<d1b2>
<dub_dub_11> looks like a default_nettype issue, the exported stuff seems to assume default_nettype wire
<Bluefoxicy>
yeah
<Bluefoxicy>
I'm setting `default_nettype none in other source files, since I spent like 5 hours one day trying to debug my code only to figure out I used a signal I hadn't declared... :|
<Bluefoxicy>
testdriving amaranth right now
Vonter has quit [Ping timeout: 240 seconds]
Vonter has joined #amaranth-lang
* alyssa
did not expect the comb vs sync signal distinction to be so subtle for her
<alyssa>
think it finally clicked tho :]
<alyssa>
Is Amaranth/Yosys smart enough to optimize bitwise ORs/ANDs to Cat()/slices?
<alyssa>
(If X is a Signal(8), will "X | 0x100" be as efficient as "Cat(X, 0x1)"?)
<alyssa>
(What about "0x200 | (X << 1) | 0x1"? vs "Cat(0x1, X, 0x1)")
<alyssa>
I guess I'm a compiler person, if this matters in a design the answer is to submit a PR to yosys....
<alyssa>
I assume that Yosys (or Amaranth itself?) has to split up Signals into single-bit Signals... scalarizing in compiler parlance
<alyssa>
And once split up, going from bitwise ops to Cat / a bunch of wires is applying "(x | 0) -> x" over and over
<alyssa>
which yosys opt_expr.cc seems to do
<alyssa>
So that implies that yes, those optimization happen but I won't find a dedicated "optimize bitwise math" pass
<d1b2>
<dragonmux> it depends on the target device, but yosys (well, probably actually ABC) will apply that kind of transformation as part of synthesis, yes
<alyssa>
ABC?
<d1b2>
<dragonmux> it's the name of the logic optimisation and synthesis tool that yosys calls in to when performing graph reductions
Vonter has quit [Ping timeout: 250 seconds]
Vonter has joined #amaranth-lang
Vonter has quit [Client Quit]
<alyssa>
ah
<alyssa>
I definitely know what all those things are ;)
<mwk>
alyssa: yes, this transform will happen
<mwk>
in opt_expr indeed
<mwk>
yosys basically has bit-granularity signals, so concat is not even an operation, it just lowers to a signal that's made from bits belonging to several wires
<mwk>
alyssa: also, what hardware are you targetting?
bvernoux has quit [Read error: Connection reset by peer]
<alyssa>
mwk: ok, good to know my intuition was right with concat/opt_expr
<alyssa>
not targetting any hardware yet because I'm overwhelmed by the choice of FPGAs
<alyssa>
..so effectively targetting PySim
<mwk>
so, here's the thing
<mwk>
the opt_expr thing will run, but only when you actually use yosys as the synthesis tool, ie. target one of the platforms supported by the open source toolchain
<mwk>
if you target eg. xilinx, yosys is only used as a Verilog emitter, and the optimization will be performed by the vendor tools instead
<alyssa>
oh, interesting
* alyssa
assumed yosys would spit back optimized verilog
<mwk>
nope
<mwk>
I mean, it can do that as well
<mwk>
but in Amaranth, yosys is called with the bare minimum of passes to get it to emit Verilog
<alyssa>
got it
<alyssa>
Woo! My (simulation of a) soft-CPU can now execute the all important program, "L: JMP L".
<mwk>
ah yes, the second greatest joy in FPGA development, successfully doing nothing in a very complex way
<mwk>
the greatest joy being, of course, blinking a LED in a very complex way
<mwk>
congrats :3
<jn>
a very good thing to do, as there is almost no bound on the complexity you can use in order to blink an LED
<mwk>
correct
<alyssa>
mwk: thanks :-p
<alyssa>
now writing CPU unit tests so i can do this the Right way
<alyssa>
apparently the way I wrote emulators as a kid wasn't the right way
<mwk>
hm?
<alyssa>
(Step 1. Do no testing, yeet!, Step 2. Get very sad when nothing actually works)
<mwk>
ah yeah, happens
<agg>
i'm pleasantly surprised by how often my hardware modules work correctly when put together, compared to software anyway
<agg>
but probably this is down to interfaces usually being a bit simpler and each module being better tested in isolation...
<agg>
i really like pytest for amaranth unit tests, it all works just like normal pytest unit/integration tests, very convenient
<alyssa>
pytest i should probably use that and not just do random asserts
<agg>
i have a pytest fixture that takes a module and testbench and drives the simulator to cut down a little boilerplate
<agg>
i mean pytest mostly still just looks like asserts :P the only difference is you just write a function like test_bla_bla() and put asserts in it, and "pytest bla.py" will find all the test functions and run them for you
cesar has quit [Quit: Bridge terminating on SIGTERM]
whitequark has quit [Quit: Bridge terminating on SIGTERM]
disasm[m] has quit [Quit: Bridge terminating on SIGTERM]
pho has quit [Quit: Bridge terminating on SIGTERM]
mikolajw has quit [Quit: Bridge terminating on SIGTERM]
jevinskie[m] has quit [Quit: Bridge terminating on SIGTERM]
xiretza[m] has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
esden[m] has quit [Quit: Bridge terminating on SIGTERM]
jfng[m] has quit [Quit: Bridge terminating on SIGTERM]
modwizcode has quit [Quit: Bridge terminating on SIGTERM]
RobertJrdens[m] has quit [Quit: Bridge terminating on SIGTERM]
egg|matrix|egg has quit [Quit: Bridge terminating on SIGTERM]
egg|matrix|egg has joined #amaranth-lang
whitequark has joined #amaranth-lang
xiretza[m] has joined #amaranth-lang
<whitequark>
Bluefoxicy: `default_nettype shoudl not matter for Amaranth-exported code, please report this as a bug
<xiretza[m]>
whitequark: FYI the bridge doesn't work toward IRC atm, your last two messages didn't make it through
<whitequark>
alyssa: Amaranth doesn't scalarize; it generally does few transformations on your code, none of which are optimization-like
<d1b2>
<geo> whitequark: regarding the `default_nettype issue, this is because write_verilog doesnt explicitly declare wires to be wires if they are input or output ports (https://github.com/YosysHQ/yosys/blob/master/backends/verilog/verilog_backend.cc#L435). I imagine this else if could be changed to an else so either reg or wire is written for every signal but wasnt certain if there was a reason why the verilog backend special cases this
modwizcode has joined #amaranth-lang
cesar has joined #amaranth-lang
esden[m] has joined #amaranth-lang
pho has joined #amaranth-lang
mikolajw has joined #amaranth-lang
adamgreig[m] has joined #amaranth-lang
jfng[m] has joined #amaranth-lang
disasm[m] has joined #amaranth-lang
Raito_Bezarius has quit [Quit: free()]
RobertJrdens[m] has joined #amaranth-lang
jevinskie[m] has joined #amaranth-lang
mikolajw has quit [Quit: Client limit exceeded: 20000]
egg|matrix|egg has quit [Quit: Client limit exceeded: 20000]
modwizcode has quit [Quit: Client limit exceeded: 20000]
pho has quit [Quit: Client limit exceeded: 20000]
modwizcode has joined #amaranth-lang
mikolajw has joined #amaranth-lang
pho has joined #amaranth-lang
<Bluefoxicy>
@whitequark, bug to yosys's verilog backend, or amaranth?
<mwk>
... so this is as simple as removing the `if` in line 435, writing the `wire` unconditionally
<mwk>
but this being the Verilog backend, I'm afraid to actually do this, for who knows what insane target it could break
Raito_Bezarius has joined #amaranth-lang
<Bluefoxicy>
ha
<mwk>
... well
<mwk>
AFAICS it could only break with a target that doesn't accept valid Verilog in the first place
<mwk>
so there goes the PR
<mwk>
worst case, we'll add a "broken output" flag
<d1b2>
<geo> yeah by the standard this should be fine
<Bluefoxicy>
it'd be nice if Amaranth also had yosys-0.13 in pip but yosys seems to be suddenly active and it may be a little early to ask why amaranth's current yosys-included release is falling behind
<Bluefoxicy>
how long did it go without an official release? Like 2 or 3 years?
<alyssa>
whitequark: Got it. So for more questions like that go to the yosys channel then..? or just trust the magic computer
<d1b2>
<dragonmux> Yosys changed release cadences to 6-monthly
<d1b2>
<dragonmux> alyssa: sorry, should have more clearly explained with what we said about ABC - when we said "graph reduction", we're talking about logic graphs which is the name of the internal representation of your logic that ABC uses (easier to work on a graph than a series of textual lines)
<Bluefoxicy>
Nice. Now we just need to get Debian/Ubuntu to keep it packaged.
<mwk>
to monthly, actually
<d1b2>
<dragonmux> oh, right.. sorry
<Bluefoxicy>
Huh. Did the development process change?
<mwk>
no, we just package whatever is in master more often
<Bluefoxicy>
ah. I thought you might have switched to a workflow that better supports that kind of cadence or something.
<d1b2>
<dragonmux> specifically because of that no release for ages and a ton of stuff having changed (if we've understood correctly)
<Bluefoxicy>
Some people complain about git flow, but they really did nail down a good foundation for keeping your release code in a known-good state
<Bluefoxicy>
and yeah, my biggest issue was when I tried to do formal verification in SV and found out that…what was it called, properties? Stuff didn't work.
<Bluefoxicy>
and someone said that was all up in the master branch
<d1b2>
<geo> aiui there is no open source tool that supports systemverilog assertions (of which properties are a part) at the moment
<Bluefoxicy>
ah.
<d1b2>
<geo> (the closest to open source you can get for sva is yosys with the verific frontend)
<Bluefoxicy>
"Both of these newer forms, however, currently require the Verific enabled version of yosys.
<Bluefoxicy>
" Oh ok
<Degi>
Does Const(123, signed(10)) yield -123?
<mwk>
no
<mwk>
it gives you a 123, but in a signed 10-bit container
Raito_Bezarius has quit [Quit: free()]
<Bluefoxicy>
heh.
<Bluefoxicy>
Anyone used FxpMath?
<Bluefoxicy>
I've been using that to generate things like look-up tables, which I can now just integrate directly into my code with amaranth
<Bluefoxicy>
But afaik I still need to manually manage fixed-point arithmetic in the RTL itself
<SimonSapin>
Hello. For a learning project I’d like to write modules in Amaranth HDL and manipulate their definition programatically. At what "level" would you recommend doing this? amaranth.hdl.* python objects? Parsing Verilog output? Something in-between?
<Degi>
Nevermind, my numbers were out of range. Now it works.
<Degi>
(Since + Const(32768, signed(16)) had the same effect as - Const(32767, signed(16)))
<tpw_rules>
SimonSapin: IMO you've got those flipped around. write a program to generate amaranth HDL
<SimonSapin>
tpw_rules: Circuit transformation and emulation is what I want to play with. But I need some HDL to define those circuits, and it’s nice if that HDL has an existing known-good emulator
<whitequark>
SimonSapin: what kind of transformation and emulation are you interested in?
<whitequark>
Amaranth has a simulator, but it doesn't really have public APIs that let you transform circuits you define in it
<SimonSapin>
whitequark: it’s still somewhat vague in my head but: restricting to a subset of the HDL either by rejecting some kinds of constructs or converting them to something lower-level, then either simulating in Amaranth (so the transformation would need for example to emit other AST objects) or write a simulator for the subset in Rust
<SimonSapin>
I understand that the AST is not a public API and can change in future versions, I don’t mind pinning to a specific Amaranth version
<whitequark>
I'm not sure if Amaranth is a particularly good fit for this project, but then I'm not sure what HDL would be a good fit...
<whitequark>
Verilog certainly isn't
<whitequark>
there's some transformations defined in the hdl.xfrm module already
<SimonSapin>
yeah, there’s more of make-your-own-tools than in more "typical" projects that could use Amaranth, but I don’t mind
<whitequark>
as long as I don't have to support your modifications in future versions, it's fine
<SimonSapin>
of course
<whitequark>
(I very much wish Python had any functional way to separate public and private API namespaces...)
<alyssa>
whitequark: i feel that so hard
<alyssa>
("as long as..")
<whitequark>
i mean, i know of a way to deal with it, but it's cursed
<whitequark>
you need imports to be in the global namespace
<SimonSapin>
whitequark: xfrm looks interesting. If I make a *Visitor or *Transformer subclass, what’s the entry point to apply it to a module?
<mwk>
... oh, right
Yehowshua has quit [Quit: Client closed]
<mwk>
this is python
<whitequark>
SimonSapin: inst(...)
Raito_Bezarius has joined #amaranth-lang
<whitequark>
mwk: you could make a custom module loader that doesn't have this issue, i think
<whitequark>
but this is even more cursed, as it changes the language semantics
<whitequark>
and you also need to make the loader actually be used, which causes dependency issues
<alyssa>
mwk: I admittedly like Python less the more I use it.
Raito_Bezarius has quit [Max SendQ exceeded]
<alyssa>
[Same goes for C, for different reasons ;-) ]
<mwk>
... a function, called at the end of module, that copies the original module namespace to another dict, changes f_globals of every function in it to the copy, then clears everything from the namespace except for __all__
<mwk>
hmm
<mwk>
are function objects mutable...
<mwk>
oh it's called __globals__ now, and it's immutable
Raito_Bezarius has joined #amaranth-lang
<whitequark>
you also have to do this to methods
<mwk>
yes, yes, recurse into classes, of course
<whitequark>
and, consider methods that have been decorated
<whitequark>
they capture closures that have the f_globals you're mutating
<mwk>
hrm
<mwk>
... okay this may actually not be possible
<mwk>
I'm having a little too much cursed fun with the python interpreter right now to stop, though
<mwk>
.. bleh, module.__dict__ is also immutable
<SimonSapin>
oh I see, `inst` as in an instance of my visitor class since it has __call__
<whitequark>
you have to eval the actual module code in a temporary context
<whitequark>
SimonSapin: yes
<SimonSapin>
thanks!
<mwk>
yes, module.__dict__ has to be different than whatever the __globals__ are when evaluating the module body
<mwk>
... this will need import hackery
<mwk>
meh
* alyssa
keeps getting bit by scoping rules
<whitequark>
mwk: yes
<whitequark>
this is probably the most singularly badly designed aspect of the language
<mwk>
oh, you can have custom __getattr__, but it can only *add* new names