<_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 - https://git.io/Jvn6e
<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>
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)
<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 nmigen.build, 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>
nmigen.build 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, nmigen.build 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>
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