ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at
_whitelogger has joined #nmigen
<_whitenotifier-3> [nmigen-boards] TiltMeSenpai opened pull request #48: Add Alchitry Au board definition -
<whitequark> awygle: i'm going to take a look at all the changesets that accumulated over it soonish
<whitequark> and then i'll be able to answer
<awygle> copy
<awygle> i'm gonna be trying to get sump2 up this weekend, gonna need a serial port to glue it to, probably will use that
<awygle> unless you have another suggestion
<whitequark> i think that branch is pretty broken, try the UART that's in nmigen examples
<awygle> mk
<awygle> thinking i'll glue a draft stream thing in between it and sump2
<awygle> give us something to talk about at least
proteus-guy has joined #nmigen
<_whitenotifier-3> [nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±2]
<_whitenotifier-3> [nmigen/nmigen] whitequark 36f498e - README: consolidate requirements in the Installation section.
<_whitenotifier-3> [nmigen/nmigen] whitequark 66f4510 - README: link to IRC channel.
<_whitenotifier-3> [nmigen/nmigen-soc] whitequark pushed 2 commits to master [+0/-0/±3]
<_whitenotifier-3> [nmigen/nmigen-soc] jfng 3737595 - csr.bus.Element: fix src_loc_at.
<_whitenotifier-3> [nmigen/nmigen-soc] jfng 2d18ac7 - memory: add support for address space extension.
<_whitenotifier-3> [nmigen-soc] whitequark commented on pull request #7: Add support for extending the address space of a memory map -
<_whitenotifier-3> [nmigen] Success. 82.30% (+0.11%) compared to 3b67271 -
<_whitenotifier-3> [nmigen] Success. Coverage not affected when comparing 3b67271...66f4510 -
<_whitenotifier-3> [nmigen] Success. 82.18% remains the same compared to 3b67271 -
<_whitenotifier-3> [nmigen] Success. 82.18% (+0.00%) compared to 3b67271 -
<_whitenotifier-3> [nmigen-soc] Success. No report found to compare against -
<_whitenotifier-3> [nmigen-soc] Success. No report found to compare against -
<_whitenotifier-3> [nmigen-soc] Success. Coverage not affected -
<electronic_eel> just saw that the logo in still contains "migen" as text
<electronic_eel> is that intentional or should it be changed to nmigen?
<electronic_eel> or "nMigen"?
<whitequark> electronic_eel: it'll be changed soon
<electronic_eel> ok
* Sarayan waves
<Sarayan> how do I sign-extend a value to use it in an add? It's just a copy of the top bit, but I'm not sure what's the nicest way to do it (counter is 24 bits, value to add is 16)
<ZirconiumX> Sarayan: I believe signed values get sign-extended automatically
<ZirconiumX> But you can also do it manually using Cat(foo, Repl(foo[15], 8))
<whitequark> Sarayan: as of nmigen master, you could use v.as_signed()
<whitequark> (if v isn't already signed)
<Sarayan> hmmmm, making it signed, that's a good idea
<Sarayan> this is not C++, it means different things there
<Sarayan> interesting, to bad I'm no good at reading verilog
miek has joined #nmigen
<Sarayan> great, I have multiple things not working and no idea why
<Sarayan> hardware is hard, let's go shopping
anuejn has joined #nmigen
<Sarayan> Oh nice, I managed to segfault nmigen, didn't think it was even possible
<Sarayan> strack blowup on infinite(?) recursion
<Sarayan> -r
<whitequark> it's surprisingly easy to segfault python
<whitequark> usually not with pure python code though
<Sarayan> nmigen is pure python isn't it?
<whitequark> yes
<Sarayan> that's why I was surprised, looks like an infinite recursion when instanciating Simulator
<Sarayan> I didn't think I was doing anything funky
proteus-guy has quit [Ping timeout: 256 seconds]
<Sarayan> pushed to github if you're interested in having a look
<Sarayan> the code doesn't do what I want, so I wanted to try getting a gtkw to look at things, and poof, blowup :-)
<whitequark> if you can reduce this to an MCVE i'll fix it faster
<Sarayan> hmmm, I have no idea what's going on, that makes it harder...
<Sarayan> gonna try anyway
<_whitenotifier-3> [nmigen-soc] emilazy opened pull request #8: setup: require nmigen>=0.1,<=0.3 -
<_whitenotifier-3> [nmigen-soc] emilazy synchronize pull request #8: setup: require nmigen>=0.1,<=0.3 -
<_whitenotifier-3> [nmigen-soc] Success. Coverage not affected when comparing 2d18ac7...0ca2941 -
<_whitenotifier-3> [nmigen-soc] codecov[bot] commented on pull request #8: setup: require nmigen>=0.1,<=0.3 -
<_whitenotifier-3> [nmigen-soc] emilazy synchronize pull request #8: setup: require nmigen>=0.1,<=0.3 -
<_whitenotifier-3> [nmigen-soc] codecov[bot] edited a comment on pull request #8: setup: require nmigen>=0.1,<=0.3 -
<_whitenotifier-3> [nmigen-soc] Success. Coverage not affected when comparing 2d18ac7...36b9219 -
<_whitenotifier-3> [nmigen-soc] Success. 100% remains the same compared to 2d18ac7 -
<_whitenotifier-3> [nmigen-soc] codecov[bot] edited a comment on pull request #8: setup: require nmigen>=0.1,<=0.3 -
<_whitenotifier-3> [nmigen-soc] emilazy edited pull request #8: setup: require nmigen>=0.1,<0.3. -
<_whitenotifier-3> [nmigen-soc] Success. Coverage not affected when comparing 2d18ac7...f1b009c -
<_whitenotifier-3> [nmigen-soc] codecov[bot] edited a comment on pull request #8: setup: require nmigen>=0.1,<0.3. -
<_whitenotifier-3> [nmigen-soc] whitequark closed pull request #8: setup: require nmigen>=0.1,<0.3. -
<_whitenotifier-3> [nmigen/nmigen-soc] whitequark pushed 1 commit to master [+0/-0/±1]
<_whitenotifier-3> [nmigen/nmigen-soc] emilazy f5b5cd5 - setup: require nmigen>=0.1,<0.3.
<_whitenotifier-3> [nmigen-soc] whitequark commented on pull request #8: setup: require nmigen>=0.1,<0.3. -
<_whitenotifier-3> [nmigen-soc] Success. 100.00% (+0.00%) compared to 2d18ac7 -
<_whitenotifier-3> [nmigen-soc] Success. Coverage not affected when comparing 2d18ac7...f5b5cd5 -
<Sarayan> In a Memory, is depth the number of entries or the address bus width?
<Sarayan> looks like it's size, as I thought. Well, the Simulator init blows up when I have a memory of depth 0x20000, not when the depth is 0x200
<whitequark> number of entries
<whitequark> and currently memory simulation isn't optimized at all
<Sarayan> width 8, so it's just 128K
<whitequark> it's 128K of very very expensive entries
<whitequark> (well, more like 256K)
<whitequark> (there are some 'double buffering' shenanigans going on)
<Sarayan> yeah, that's not a problem as-is
<Sarayan> we're talking python-level sim there, not C++, right
<whitequark> yes
<Sarayan> looks like the Simulator, when initing a Memory, does a recursive call with a number of instances proportional to the memory depth
<Sarayan> that's kinda deadly :-)
<whitequark> hm
<whitequark> wait really?
<whitequark> that seems like i should fix it regardless
<Sarayan> indeed
<Sarayan> there's slow, and there's insane :-)
<Sarayan> I don't mind if it's slow, even if I'm tempted to do a thing starting with an import llvm ;-)
<whitequark> cxxsim is roughly equivalent to starting with import llvm
<Sarayan> yeah, what's missing is the recording of everything to a gtkwave
<Sarayan> otherwise I wouldn't use the python sim anymore
<whitequark> hm.
<whitequark> yes, i had some plans for it
<whitequark> but.. have you considered the amount of generated data?
<Sarayan> not as much as you think for what I do
<Sarayan> it's only 400K clocks
<Sarayan> so 20K bits of state before you even hit a gigabyte
<Sarayan> I've worked in 2004 on setups generating 1GB/minute, I'm kinda used to it
<Sarayan> I agree that at some point there should be *some* kind of filtering, likely giving the list of modules you actually want to trace
<whitequark> ok, makes sense
<whitequark> one thing is that this will make the design possibly significantly slower even if you don't select anything for writing
<whitequark> because it has to keep those bits of state
<whitequark> right now it will optimize away intermediates if possible
<Sarayan> yep
<Sarayan> it will be be a couple of orders of magnitude faster than python
<Sarayan> I really, really like nmigen mind you, but running things in pure python is always gonna be slow
<whitequark> right now it's 3 orders of magnitude faster, right?
<Sarayan> yep
<Sarayan> at least
<whitequark> try lowering -O number you give to cxxsim
<whitequark> to -O0
<whitequark> (not to clang, clang still should be used with -O2)
<Sarayan> I'm not running things long enough to be able to notice the time it takes
<whitequark> ok
<Sarayan> in practice I'm generating two frames, and the first is just to be sure everything is synced
<whitequark> ah, gotcha
<whitequark> can you dump the state to a csv manually and then convert that to vcd with some other tool?
<whitequark> I'm afraid I won't be able to work on the proper solution just yet
<Sarayan> depends on what you mean by proper solution, fixing Simulator with Memory or tracing on cxxsim?
<whitequark> latter
<Sarayan> because the latter is just something that would be nice someday, but I can do without easily
<Sarayan> I just bring up the signals I want, works perfectly well
<whitequark> former could be done more easily i think
<Sarayan> if I can have the option to run with Simulator one in a while when I really don't understand what's going on I'm good
<Sarayan> once
<Sarayan> and even then, it's more of a case of "It's blowing up, whitequark may want to know about it" :-)
<whitequark> gotcha. still, do you have code to repro it? if yes I can try to fix it real quick
<Sarayan> lemme try to make some
<Sarayan> what I have is stil lannoyginly complex
anuejn has quit [Quit: - Chat comfortably. Anywhere.]
anuejn has joined #nmigen
<whitequark> thanks!
<whitequark> hm, yes, segfaults
<whitequark> that's funny
<Sarayan> drop down the size and it doesn't anymore and shows I fucked the rest of the code a little too :-)
<Sarayan> sim = Simulator(mm)
<Sarayan> that's what blows up
* Sarayan blinks
<Sarayan> is the full state of the rom dumped in the gtkwave for each cycle?
<whitequark> yes
<whitequark> a Memory is treated just like a bunch of Signals
<whitequark> .. oh
<Sarayan> ouchouchpuch
<whitequark> I just figured out exactly why you hit a stack overflow
<whitequark> because each memory access is transformed into a really large ternary operator
<whitequark> well, more or less
<Sarayan> that's, like, bad
<whitequark> hm, wait, no, i fixed that a while ago
<whitequark> probably because it sucked
<whitequark> oh
<whitequark> Sarayan: well
<whitequark> it's because Python treats long if/else chain more or less the same as long ternaries
<whitequark> it recursively compiles them
<Sarayan> ouch
<Sarayan> in any case, I won't be able to run that sim
<Sarayan> 1.6Mb of state per cycle is a tad too much
<Sarayan> even for me
<Sarayan> (I have two roms at that size)
<whitequark> yeah
<Sarayan> too bad there's no delta-packing going on
<Sarayan> or rle, whatev'
<whitequark> i think there is
<whitequark> in pyvcd
<Sarayan> I love how some of the twitter replies assume I was doing something insane
<_whitenotifier-3> [nmigen] peteut commented on issue #301: vendor.xilinx_7series: Vivado TIMING-2 Warning -
<Sarayan> so now the
<Sarayan> question is pretty much how am I going to debug my crap :-)
vup has joined #nmigen
<whitequark> well
<whitequark> i could try add a proper model for memories to pysim tomorrow
<Sarayan> don't hurry anything on my behalf
<Sarayan> I'll find a way
<whitequark> it's actually a longstanding issue
<whitequark> pretty ugly part of nmigen that i ought to fix long ago
<Sarayan> zheh :-)
_nihilan_ has joined #nmigen
_nihilan_ has quit [Remote host closed the connection]
<awygle> whitequark: are there examples of using Instance besides the one in nmigen/examples? if not, should i try to use some Migen examples? none of the nmigen examples i've found seem to do anything (or i'm missing some context which i can't seem to glean)
<whitequark> hm
<whitequark> what do you mean by "do anything"
<awygle> okay, the cpu submodule is an Instance called "CPU"
<awygle> now what?
<awygle> i expected to see 1) a source file for the Instance in some other HDL 2) an indication to nmigen of what other HDL it is 3) at the very least
<awygle> (sorry, no 3)
<whitequark> ohhh
<whitequark> right so that was written before, i think
<whitequark> try `with open(filename) as f: platform.add_file(filename, f)`
<whitequark> the extension determines the file type
<whitequark> there is no way to add verilog definitions or alter include paths, currently
<whitequark> `filename` can include directories, which are always separated by forward slashes (this gets handled correctly if you build on Windows)
<whitequark> does not, and will not, let you refer to files outside of the build directory
<awygle> and the "CPU" in the Instance should be ther Verilog module name?
<whitequark> yes
<whitequark> there is also something called "connect_rpc"
<whitequark> which lets you instantiate nmigen modules from verilog
<whitequark> you could even have a pair of mutually recursive nmigen and verilog modules
<awygle> that's a bit hardcore for me currently :) thanks for clarifying
<awygle> btw, what does nmgien.cli.main do?
<awygle> when i tried to run the example as written it complained about an unused module
<awygle> err elaboratable
<whitequark> try --help
<whitequark> it's kind of a silly idea in retrospect
<awygle> ahhh
<awygle> is there a use case for Instance still elaborating even if it never finds the corresponding external module?
<whitequark> how would I detect this case?
<whitequark> nmigen doesn't have a Verilog parser, and elaboration happens before it runs Yosys (for that matter, you may choose to never run Yosys, or even not have Yosys on the machine where you elaborate)
<awygle> ah
<awygle> interesting
<whitequark> hm, wait
<whitequark> most of the uses of Instance would in fact not have the external module
<whitequark> because they're vendor black boxes.
<awygle> mmm
<awygle> if nmigen calls yosys or the vendor tools to do synthesis, and an error is reported, does nmigen ... take cognizance of that error, for lack of a better term?
<whitequark> what nmigen does is create a shell script that runs the entire pipeline
<whitequark> and runs it, optionally
<whitequark> if this shell script fails, will raise an exception
<whitequark> if this shell script succeeds when a vendor tool has failed, it is a bug in nmigen
<awygle> "fails" determined by "returns nonzero error code", presumably
<whitequark> yes
<whitequark> well, for the shell script
<whitequark> the vendor tools generally return nonzero error codes on failure, i think.
<awygle> if nmigen runs the shell script, does it capture stdout and stderr from it? or no?
<whitequark> but if they don't then nmigen will have to work around it.
<whitequark> does not.
<whitequark> the tools are generally configured to write logfiles.
<awygle> mm, fair enough
<awygle> (you can assume a rant about the general "get fucked"edness of the proprietary fpga ecosystems to be here, i'll spare us both expanding it)
<whitequark> tbh vivado has a surprisingly well thought out Tcl API
<whitequark> so far i found it the only FPGA toolchain that was actually nice to use, scripting wise
<awygle> to expand my thought process slightly, i am envisioning a way for nmigen to report sensible uniform errors from each backend toolchain, provided it has been educated on how to do so (which would be optional, obviously)
<whitequark> well, that sounds horrifying
<whitequark> to implement
<awygle> as usual with these "infinite work" types of features i am envisioning putting the optional support in place and leaving it to folks to add specific cases one at a time as they need them
<awygle> which in practice means there will never be more than like, two or three cases supported
<awygle> so it's an admittedly utopian vision
<whitequark> i assume you can goad diagnostics in a nice format out of like, quartus and vivado
<whitequark> i'm pretty sure quartus can do it
<awygle> it falls out of following folks on twitter who _really_ care about rustc error messages
<whitequark> i suspect vivado can do it based on the general written-for-humanness of its UI
<whitequark> wait, wanna hear something funny?
<awygle> and seem to be able to just poke new ones in there whenever they're needed without having to do a ton of surrounding work
<awygle> sure
<whitequark> little bird told me xilinx considers vivado a failure, internally, because it didn't let them corner the market any more than they already had
<awygle> lol, and also, sob
<whitequark> it's especially amazing given that vivado is like, actually pretty okay for an fpga toolchain.
<whitequark> kinda shows you why they all suck so much.
<awygle> yep
<awygle> maybe that "failure" combined with the abysmal ratio of cost to develop / revenue percentage of their software tools will convince xilinx to invest in open source instead
<awygle> (and maybe butterflies will fly out of my ass, but i can dream)
<awygle> thinking about backends, i assume you looked at edalize and decided not to use it?
<whitequark> it did
<whitequark> it did convince them to invest in open source
<whitequark> they're now claiming it is "core part of their strategy" or w/e, and they did re-release rapidwright (after nuking it with dmca carpetbombing)
<whitequark> (except it's now less open source than before)
<awygle> oh, so they're "embracing open source" in their clumsy corporate behemoth way
<whitequark> yes. precisely.
<awygle> lovely
<awygle> Simulator explicitly does not use a platform, is there a way for me to test Instances in simulation?
<whitequark> it's going to be amusing/depressing to watch
<whitequark> yes, sort of
<whitequark> Instances are Fragments so you can add a Module into one that simulates what it does
<whitequark> Simulator is not able to cosimulate with any Verilog simulator so there's no other way
<whitequark> going forward I plan to *not* add cosimulation to pysim, but rather add first-class cxxsim support, where the entire thing would be processed by Yosys first
<awygle> mmm bummer. is cxxrtl - yes
<whitequark> is what
<whitequark> i mean, migen didn't have cosimulation support either
<awygle> i was going to ask "is cxxrtl/cxxsim the way forward on that front"
<Sarayan> I'd say so, at least
<whitequark> yeah
<Sarayan> cxxrtl works extremely well connected to any C++ code
<whitequark> it was the plan for a very long time, although mostly not publicly
<awygle> is cxxrtl in a state where this cosimulation approach exists as a possibility, even if mostly/completely untested? or no
<Sarayan> yosys/cxxrtl can handle any systemverilog, right?
<whitequark> hahaha no
<awygle> seems like Sarayan is having a good experience but with a slightly different use case
<whitequark> yosys can handle like 1% of systemverilog
<whitequark> well
<Sarayan> oh?
<whitequark> no synthesis toolchain can handle all systemverilog because most of it isn't synthesizable
<whitequark> there's no equivalent of 1364.1 for systemverilog because ieee 1800 sucks.
<whitequark> they can't even write a formal semantics for always_ff
<Sarayan> ok, systemverilog as used in fx68k, e.g. jotero's 68000 reimplementation in verilog that's used in mister
<whitequark> yes
<whitequark> *on top of* that, yosys' systemverilog support is *extremely* incomplete.
<Sarayan> e.g real stuff, not imaginary corner cases :-)
<awygle> somebody gotta glue that new google sv parser to yosys' ast framework :p
<Sarayan> (which are not so imaginary when you hit them)
<whitequark> it's of course impossible to say how incomplete because there's no actual spec.
<whitequark> awygle: yes, i think that's actually the plan
<awygle> oh cool
<awygle> beats the hell out of Verific
<whitequark> now, only someone has to do it
<awygle> so anyway, not to quash this interesting discussion, but should i try and swap over to the cxxsim branch like Sarayan, given that my use case is to simulate this sump2 wrapper before dropping it into hardware?
<whitequark> hm
<awygle> or is that not going to work as things stand
<whitequark> either that or just use iverilog
<whitequark> whichever is easier
<awygle> oh, generate verilog out of the nmigen wrapper and simulate that with iverilog?
<whitequark> i expect this won't be an issue long term since cxxsim was explicitly written to be easy to integrate with nmigen
<awygle> suppose that'd work
<whitequark> yeah
<whitequark> so... short term just use any workaround you like
<awygle> i'd like to give cxxsim a shot
<awygle> as long as it's not 0% of a chance to work
<Sarayan> my current cxxrtl integration:
<Sarayan> well, whitequark's, truly, I just made it more unixy
<awygle> cool, i'll give it a shot after lunch
<awygle> thank you both
<whitequark> yay
<awygle> hm arright so i'm still struggling with platforms a bit. i guess i should remove the `platform.add_file` call now that i'm using cxxrtl? it's currently preventing me from elaborating (because i stuck it in the `elaborate` method, which seems wrong)
<whitequark> yes, i think so
<whitequark> i'm not yet sure what to do with platforms when simulating
<whitequark> like, on one hand, you do *not* want e.g. FFSynchronizer to expand to a vendor primitive when you're simulating
<whitequark> on the other hand, maybe you're actually simulating with vendor sim libraries
<awygle> i kind of expected a SimulationPlatform
<awygle> and then maybe specializations like e.g. ECP5SimulationPlatform which use the vendor sim libraries
<whitequark> possible, but why shouldn't it just be a normal Platform?
<whitequark> most of Platform's functions should still happen in simulation
<awygle> oh sure, i meant SimulationPlatform(Platform)
<awygle> whether it's ECP5SimulationPlatform(SimulationPlatform) or ECP5SimulationPlatform(Platform) would fall out of what ended up in SimulationPlatform, presumably
<whitequark> that seems like it'd result in diamond inheritance
<awygle> it does have the potential to end up in diamond inheritance or in a bunch of duplicate code. i'm just saying, that's kinda what i expected to see, coming into it blind
<whitequark> ack
<whitequark> i suspect simulation would be more of a platform mode than a different platform
<whitequark> but frankly, i'm not sure
<whitequark> could go either way
<awygle> it really depends on what you're doing. i could see having both
<awygle> because lots of the time i want to simulate abstract HDL (see: now)
<awygle> but also lots of the time i want to simulate things on a board (see: hopefully like, tomorrow)
<awygle> so maybe an abstract SimulatorPlatform and then modes for the concrete platforms makes sense? something to think about at least
<whitequark> i'm not actually sure how simulating things on a board should work end-to-end
<whitequark> for example, if you simulate a SoC, you will plug in a model of an SPI flash or Ethernet most likely
<whitequark> but it'll be a behavioral model
<whitequark> so you do *not* want an IOB instantiated
<awygle> on the other hand, if it's relevant you might want a simulation model of an IOB instantiated
<whitequark> well, you would need a simulation model of an IOB if you have an IOB in your netlist atall
<whitequark> so, yeah
<whitequark> there's an open issue by zignig i think
<awygle> awesome, i got sump2 synthesized into c++
<awygle> that was shockingly simple
<whitequark> \o/
<awygle> hm i think it might have eaten the verilog bits actually, oops
<awygle> i don't think it likes how i'm doing reset and clock. how can i map an instance to be in the same clock domain as my module? `m.d.sync.clk` did not work as i expected, apparently that's not a Domain it's a _ModuleBuilderDomain