Franananachi has quit [Remote host closed the connection]
<_whitenotifier-3>
[nmigen] awygle commented on issue #336: FSM state transition weirdness - https://git.io/JvPhj
Asu has joined #nmigen
hell__ has quit [Remote host closed the connection]
hell__ has joined #nmigen
_whitelogger has joined #nmigen
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #nmigen
electronic_eel has quit [Ping timeout: 250 seconds]
electronic_eel has joined #nmigen
Franananachi has joined #nmigen
Franananachi has quit [Remote host closed the connection]
Franananachi has joined #nmigen
Franananachi has quit [Ping timeout: 256 seconds]
<_whitenotifier-3>
[nmigen] jchidley opened issue #337: Mistyping device definition leads to unclear errors. - https://git.io/JvXtQ
Franananachi has joined #nmigen
Franananachi has quit [Client Quit]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
jchidley has joined #nmigen
<jchidley>
noob here. Trying to get my head around this
<jchidley>
If I have understood nMigen correctly, it is a Python language that directly generates RTLIL code. That code is consumed by Yosys
<mwk>
something like that, yes
<mwk>
(though that's not the only thing you can do, there's also a simulator)
<jchidley>
in that sense nMigen appears to similarly constructed to Chisel FIRRTL and SpinalHDL (although this seems to output Verilog)
<jchidley>
So the really important ideas are RTL Register Transfer Level and FSM Finite State Machine
<jchidley>
I can see that there are simulation and formal verification tools to help
<sorear>
spinalhdl is a fork of chisel 2.0, it's not an independent design
<jchidley>
Ah, yes. That makes sense as they are both Scala
<jchidley>
Migen had the same ideas as nMigen but targeted Verilog directly.
<jchidley>
?
<mwk>
yes, nmigen is a refinement of the ideas in migen
<mwk>
emitting verilog is quite messy (it's not a good target language, or a good language at all for that matter), so for nmigen it was decided to reuse the write_verilog code in yosys instead of writing custom code
<jchidley>
Presumably designed that way for the same reasons that Yosys targets RTLIL even though it input and outputs Verilog
<mwk>
yosys doesn't "target" RTLIL, it uses it as its IR
<sorear>
verilog is a language for writing general event-based simulators. it is possible to use it to define hardware, but only in the sense of 'a good FORTRAN programmer can write FORTRAN in any language'
<mwk>
and it doesn't output Verilog, it outputs many different formats
<jchidley>
I had assumed that learning Verilog was going to be helpful but that seems like a waste of t8me for me. I madman sure that if you already know Verilog it is helpful
<sorear>
for some reason, this practice has become entrenched in the industry, but it's still painfully indirect
<jchidley>
Spelling! damn not Madam, time not t8me
<jchidley>
Yes, thanks for the targeting vs intermediate thing
<jchidley>
FORTRAN77 was my very first language
jchidley has quit [Ping timeout: 240 seconds]
nihilant has joined #nmigen
jchidley has joined #nmigen
nihilant has quit [Quit: Ping timeout (120 seconds)]
jchidley has quit [Ping timeout: 240 seconds]
<awygle>
what's the vibe on nmigen-soc, currently? is it considered to be fairly complete, usable, a proof of concept?
<jfng>
the wishbone and CSR APIs should be usable, modulo existing bugs (issue #4, notably)
<jfng>
the peripheral API proposal (#10) is still waiting further review/consensus
<awygle>
ah right i commented on #10
<awygle>
so what's the actual work involved there? just "make a decision" basically?
<awygle>
i.e. if i am developing an IP for a short-term project with no intention to include it in nmigen-soc anytime soon, #10 is not relevant to me?
<jfng>
yes, I don't expect the existing APIs to change much
<awygle>
mk
<awygle>
reading through #1 now, trying to get a grip on those APIs. i am only vaguely familiar with CSRs, certainly not beyond a conceptual level.
<awygle>
i guess i could pass any of these intervening things to any "bus masters" that might exist, so there's no _need_ for there to be a single coherent memory map.... that feels pretty gross tho lol
<awygle>
so i guess i just won't do it
<jfng>
the highest-level can be whatever you want it to
<jfng>
for example, you could have a wishbone.Decoder at the top-level, then a WishboneCSRBridge, then a csr.Decoder, then some csr.Multiplexers at the bottom of the hierarchy
<awygle>
shouldn't only one thing be allowed to drive the bus at a time? presumably an arbiter?
<awygle>
also is there a latency or Fmax implication to deeply nested hierarchies?
<jfng>
yes, if you had multiple initiators, you would connect a wishbone.Arbiter to the decoder
<jfng>
I don't expect the hierarchy to go deeper than that
<awygle>
would i present an interface to an external memory, like an external SRAM, as an array of CSRs added to a Multiplexer? i guess the CSRs are comb, not sync?
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<awygle>
hmm actually that doesn't make sense. would it be a wrapper around a multiplexer, or maybe something inheriting from a multiplexer? or just a memory map?
<jfng>
mmh, I'd expose the external memory directly behind a csr.Interface
<awygle>
Can I do that? I thought those had to be bus width or smaller
<jfng>
ah, if the port to your memory has e.g. a bigger data width than the bus, it would not work yes
<jfng>
in that case, a wrapper class with a csr.Multiplexer and some CSRs for e.g. address and data would indeed work, I think
<jfng>
the multiplexer enforces atomic updates, so writing to a 32-bit CSR over an 8-bit wide bus should not be a problem
<awygle>
oh maybe i'm not clear
<awygle>
what i'm envisioning isn't "write address to 0, write count to 1, read 2 until your read is finished", i was envisioning memory-mapping the memory directly onto the bus
<awygle>
so the controller gets all accesses to addresses X through X+N and translates them into SRAM (or flash or DRAM or whatever) reads/writes
<awygle>
to addresses 0 through N of the external memory
<jfng>
you could use a wrapper class exposing a csr.Interface whose `addr_width` parameter is big enough to cover your external memory
<jfng>
the wrapper would then do the translation
<jfng>
hmm, I think I see the issue, if your memory port does
<jfng>
'nt match the data width of the csr interface, (e.g memory port is smaller) then you would need dense address translation
<jfng>
something that e.g wishbone.Decoder provides, but I don't think you can easily do that with the csr interface
Asu has quit [Ping timeout: 246 seconds]
<jfng>
so this would only work if the csr bus and your memory port have matching data widths
<awygle>
when you say "memory port" what do you mean exactly? i think that might be where i'm getting mixed up
<awygle>
the external connection?
<jfng>
yeah, that
<jfng>
sorry if I'm not clear
<awygle>
oh, well i can handle all that junk by just like, buffering stuff
<awygle>
although i spose it'd be nice if the CSR layer handled it for me
<awygle>
so a csr.Interface is what i want (basically a window on the memory map)? and the actual _register_ is a csr.Element? and moving between the two is "manual", i.e. done in the elaborate method of my IP core?
<jfng>
yeah, but the csr.Element is just an interface to a single CSR
<jfng>
so you can make it behave like a register by assigning assigning `w_data to r_data when w_stb is asserted
<jfng>
in the elaborate() method of your core, yep
<awygle>
so in the case of the "map external memory" thing, there would be a csr.Interface but no csr.Elements backing it
<awygle>
and you use the fields of the Interface Record to figure out what your controller is supposed to be doing
<awygle>
hm, no backpressure though, which is a bit tricky for anything more DRAM-ish than SRAM-ish
<jfng>
yes, the csr interface does not have an `ack` signal or whatsoever
<awygle>
so any memory that can't be accessed in a single cycle should use a wishbone.Interface instead of a csr.Interface?
<jfng>
btw, why not use wishbone ? it would be much more adapted to a memory-like interface
<jfng>
yeah
<jfng>
I think
<awygle>
"because my mental model of what a CSR is was wrong", basically
<awygle>
my new mental model is "CSRs for AXILite-style things, WB for AXI-style things"
<jfng>
your core can still have CSRs, you'll just need to bridge a subordinate csr bus to your wishbone bus
<awygle>
my old mental model was "CSR is just a bus-neutral way of talking about a thing with an address on a bus, then when you actually build up your SoC all the CSR business gets replaced with your choice of WB/AXI/Avalon/etc"