nyanotech has quit [Remote host closed the connection]
nyanotech has joined #amaranth-lang
nak has joined #amaranth-lang
urja has quit [Read error: Connection reset by peer]
urja has joined #amaranth-lang
josuah has quit [Quit: josuah]
josuah has joined #amaranth-lang
cr1901_ is now known as cr1901
vipqp has joined #amaranth-lang
<vipqp>
how can I find more information about using control structures?
<vipqp>
for example, there is a little stub that mentions use of m.FSM() but I'm not sure how that works or implementation, other than a vivonomicon blog post which isn't totally clear to me.
<whitequark>
it's in a section of manual that's not yet written, apologies
<whitequark>
what m.State("X") does is similar to m.If(state == N) where N is some number assigned to the name X, except it manages the state variable and the number<>state assignment itself
<vipqp>
ah, ok!
vipqp has quit [Quit: Client closed]
vipqp has joined #amaranth-lang
<vipqp>
another quick question: regarding layouts, is it possible to use multiple layouts to decode a signal?
<vipqp>
maybe this is a bit abstract... but for a primitive CPU like MIPS there are R type, I type, J type instructions
Degi has joined #amaranth-lang
<whitequark>
yes! you can create three of them with the same signal
<whitequark>
also, you can have overlapping fields in a single layout
<vipqp>
I was thinking to use layouts to define the bit fields of the instruction. it's possible to decide what type it is from the first few bits, could I use some controls to switch which one is decoded?
<vipqp>
wow! that's great
<vipqp>
ok, I will try this and see if I can make it work! thanks for your help!
<whitequark>
re: switch which one is decoded, no, and this is caused by _phasing_
<whitequark>
it is not possible to change the variable of the Python object depending on some Signal bit because the Python code runs once and handles every possible combination of input bits
<whitequark>
the m.If(x) isn't the normal if x: not because you can't reuse the syntax (you can), but to indicate that it isn't a Python conditional; it is a way to build up multiplexer trees
<vipqp>
ok, so maybe the best way to handle this is with one layout with overlapping fields for all types of instructions and then just handle the logic based on the first (shared across all instruction types) field
<vipqp>
that should work?
<whitequark>
you could do either that or three layouts; a layout per instruction format, if I recall MIPS right, will probably be a little easier
<whitequark>
in that it will result in lighter weight syntax for defining formats and a little less ambiguity in using them
<whitequark>
oh, and for the toplevel type access I'd probably index it directly. but you could do this in most ways and really it doesn't matter very much, do whichever you prefer!
<vipqp>
last thing for today: hardware question: i was thinking about picking up the alchitry copper but didn't see any board definition for this. is that just because nobody is using it and submitted a definition? or is there some issue with using both iCE40 tool + alchitry loader? (Au board use xilinx 7 series instead, with the same 'loader'). is the
<vipqp>
loader really just an interface for the ft2232 usb chip they used?
<vipqp>
(there are existing board definitions for the alchitry au, just not the cu)
<whitequark>
probably the former, Amaranth places no restriction on the programming tools, and proprietary Xilinx tools are supported
<vipqp>
ok, great! i'll see if i can cook up a working one.
<whitequark>
(toolchain_program() is a freeform function that can shell out to anything or really do anything at all)