<d1b2>
<TiltMeSenpai> are switch statements match first or match last
<d1b2>
<emeb> redundant matches are allowed?
<d1b2>
<TiltMeSenpai> like I want to match against 0b01--, but 0b0100 is a special case, what goes first
lkcl_ has joined #nmigen
lkcl has quit [Ping timeout: 240 seconds]
<awygle>
It's first match wins
<awygle>
TiltMeSenpai
<d1b2>
<TiltMeSenpai> oh cool
Yehowshua has joined #nmigen
<Yehowshua>
I do confirm that nextPNR and yosys work on the ARM pinebook pro for Xilinx Basys AC7
<Yehowshua>
Is that a first?
jaseg has quit [Ping timeout: 244 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
Yehowshua has quit [Ping timeout: 245 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter_ is now known as PyroPeter
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #nmigen
emeb_mac has quit [Ping timeout: 265 seconds]
emeb_mac has joined #nmigen
alexhw has quit [Remote host closed the connection]
Lord_Nightmare2 has joined #nmigen
Lord_Nightmare has quit [Ping timeout: 265 seconds]
Lord_Nightmare2 is now known as Lord_Nightmare
hitomi2507 has joined #nmigen
jeanthom has joined #nmigen
emeb_mac has quit [Quit: Leaving.]
zignig has quit [Remote host closed the connection]
lkcl__ has joined #nmigen
Asu has joined #nmigen
lkcl_ has quit [Ping timeout: 246 seconds]
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
awe00 has joined #nmigen
<d1b2>
<EmilJ> Aren't there two parts to that? 1: toolchain tested on whatever ARM core the pinebook has, 2: toolchain tested with whatever artix-7 part your board has (couldn't Google basys ac7) as target
awe00_ has quit [Ping timeout: 240 seconds]
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
<DaKnig>
Yehowshua : now for the big challenge :) try that on the pinephone
<DaKnig>
"program your FPGA anywhere, anytime!"
<DaKnig>
@EmilJ: its just a novelty
jeanthom has quit [Ping timeout: 246 seconds]
alexhw has joined #nmigen
alexhw has quit [Remote host closed the connection]
alexhw has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua>
d1b2 Emily, ur right, meant basys3 artix 7
<Yehowshua>
typo. ac7 is a ocmpletely different xilinx fpga
<Yehowshua>
DaKnig, could try a pinephone, although I think I'll try it on my PowerbookG4 first
<Yehowshua>
Building Yosys on that thing took an entire day
<Yehowshua>
Which probably means building nextPNR will take the better part of the weekend
Yehowshua has quit [Remote host closed the connection]
emeb has joined #nmigen
nelgau has quit [Remote host closed the connection]
nelgau has joined #nmigen
awe00_ has joined #nmigen
awe00 has quit [Ping timeout: 264 seconds]
jeanthom has joined #nmigen
nelgau has quit [Ping timeout: 240 seconds]
<d1b2>
<EmilJ> > Emily lul
XgF has joined #nmigen
<DaKnig>
is there an easy way to extract the hierarchy of the Modules in a given directory?
<DaKnig>
I tried making a python script that does that; gave up.
<lkcl_>
moony: you create a list of tuples, [("name", length), ("name2", length2)], pass that in to a Record, and you get an object back which has fields obj.name obj.name2 etc. as Signals
<lkcl_>
you can then either do obj.name.eq(something) or you can do obj.eq(something)
<lkcl_>
then at line 39 in that same file you can see it being used
<moony>
TiltMeSenpai: Yes, it turns out it's hard to read.
<lkcl_>
to create a wisnbone bus, self.bus
<TiltMeSenpai>
do you have a specific question?
<lkcl_>
moony: note that e.g. at line 23 there's an entry in the list for "adr"?
<lkcl_>
and at line 66 this is why it is then possible to do "self.bus.adr" because that list containing the layout created a Signal, of the required width, named "adr" in the Record "bus".
<lkcl_>
there's not much to overthink, here :)
<lkcl_>
moony: think of it like a way to construct a python class.
<moony>
I understand it now
<moony>
just didn't know how to build a Layout
<lkcl_>
there's 2 "versions" of the tuple entries. one is only 2 long ("name", length)
<lkcl_>
the other is 3 long and you can specify the direction.
<lkcl_>
for anything with a direction like that you have to use Record.connect()
<lkcl_>
which tests the direction and wires them up with thing.eq(record.thing) or record.thing.eq(thing) depending on whether it's a FANIN or FANOUT
<lkcl_>
but, butbutbut, do bear in mind that Record is to be superceded within a few months [by something that does the same job]
<lkcl_>
if you really _really_ want to use Record after that, you'll need to take a copy of rec.py
<TiltMeSenpai>
is it going away or just getting another class that does a better job
<lkcl_>
TiltMeSenpai: both.
<TiltMeSenpai>
wait are Records not an omigen thing?
<lkcl_>
i don't know what omigen is, apologies
<lkcl_>
i've heard it mentioned
<TiltMeSenpai>
old migen, opposed to nmigen, which is new migen
<TiltMeSenpai>
idk maybe I'm just being lazy but I'll chip in if Record doesn't get a compat layer when there's actual code :P
<TiltMeSenpai>
by "maybe I'm being lazy" I mean "I'm being lazy"
<lkcl_>
TiltMeSenpai: there's so much code in libresoc that depends on Record, that we'll almost certainly have to copy it to nmutil (the general-purpose nmigen utility library) for some time
<TiltMeSenpai>
maybe on Monday it would be worth figuring out copying rec.py to nmigen.compat vs writing an equivalent api to whatever supersedes it? idk
<TiltMeSenpai>
I have no clue what Record is being used for to begin with, so no real expertise to add here
<moony>
what's a good way to estimate the space on an FPGA some portion of my design will take? Black boxes (and if black boxes, how do I make them :P)
<moony>
?
<lkcl_>
moony: have you got some code already?
<moony>
yes
<lkcl_>
ok then generate an ilang file
<lkcl_>
import it into yosys
<lkcl_>
then run "proc" and "synth_ecp5"
<moony>
won't it just get optimized away
<lkcl_>
(or, whatever command represents the FPGA you have)
<lkcl_>
the last part of the output shows the actual number of LUT4s, etc. etc. etc. needed
<lkcl_>
so you don't need to estimate
<lkcl_>
mmm oh i see, sub-portions. then write a short routine to output just that class to an ilang file
Asu has quit [Ping timeout: 240 seconds]
Asu has joined #nmigen
<awygle>
TiltMeSenpai: yes, we would migrate the nmigen.compat version of Record to be based on top of the Record replacements we're discussing
<TiltMeSenpai>
ok, cool
<awygle>
moony: you can do synthesis with Yosys and out-of-context placement/routing with nextpnr, if you're on an ecp5
<moony>
out-of-context?
* moony
looks at how to enable that
<awygle>
it's a command line arg
<awygle>
it's experimental so sometimes it breaks, but it's worked reasonably well for me
<awygle>
oh you want to use it with `--placer sa` as well
<moony>
huh, good to know
<moony>
mk
<awygle>
the HeAP placer gets a singular matrix and explodes
<moony>
also, just an odd little thing
<moony>
but whenever I build a design for the ULX3S_85F_Platform platform, it always shows up as a 45F in nextpnr
<awygle>
is that in nmigen_boards?
<moony>
mhm
<TiltMeSenpai>
can you flash the bitstream?
<awygle>
yes it is
<moony>
TiltMeSenpai: I don't have the board yet, I've only been using it as a way to see how big a design comes out
<moony>
so I can't check for you, sorry
<TiltMeSenpai>
ah
<awygle>
hm that really should work
<moony>
awygle: --out-of-context presumably works, but I'm assuming yosys is optimizing away the block
<TiltMeSenpai>
hmm nmigen-boards suggests it should be an 85F part
<TiltMeSenpai>
idk maybe you'll have to wait until you get one or ask someone to try flashing a bitstream
<awygle>
yeah, it looks correct to me
<TiltMeSenpai>
if nextpnr really thinks it's a 45F, you'll get an IDCODE mismatch
<awygle>
don't have advice other than "make sure everything's up to date"
<moony>
forcing nextpnr-ecp5 to use the 85k with --85k does work
<awygle>
you're just calling platform.build, right?
<moony>
mhm
<moony>
oh i see
<moony>
i forgot to specify some files to the manual nextpnr call
<awygle>
as for optimization my yosys command line is `yosys -f verilog -b json -p synth_ecp5 -abc9 -o out.json <filepath>` and that works for me
<moony>
my fault, again
<awygle>
ah ok
<awygle>
if you'd like i can share the script i'm using to do this from within nmigen/python
<moony>
sure
<moony>
is there, maybe, some sort of black-box i should be using?
<TiltMeSenpai>
moony: in the generated SVF, there should be some lines that look like `SDR 32 TDI (00000000)` around line 10, what's the TDO that follows that?
<TiltMeSenpai>
(this is where the IDCODE gets checked)
<moony>
TiltMeSenpai: I just said, i forgot to actually include some files with the nextpnr call. My bad.
<d1b2>
<TiltMeSenpai> ah, ok
<TiltMeSenpai>
I thought you were talking about the out of context place, not the device type, sorry
<moony>
also, is it just me or does it look like someone made a copy-paste error for a lot of the connectors
cr1901_modern has quit [Client Quit]
cr1901_modern has joined #nmigen
<DaKnig>
try something like `platform.request("gpio",0)["1+"]`
<DaKnig>
not sure about the ["1+"] part, but that's how you request a connector
<moony>
doesn't work, resource doesn't exist
<DaKnig>
I just recently had to fix up the board file on nmigen-boards, so there's a high chance it happened to you too :)
<whitequark>
you can't request a connector at all
<whitequark>
you can only request a resource
<DaKnig>
oh?
<DaKnig>
why?
<moony>
filing an issue, then, as not all the diff pairs even have a resource, and there's a copy-paste error
<_whitenotifier-3>
[nmigen-boards] moonheart08 opened issue #108: ULX3S IO is screwy - https://git.io/JULYr
<DaKnig>
> issue < why not just fix it for yourself, test, pr?
<DaKnig>
:)
<whitequark>
ulx3s was contributed by someone else and none of the maintainers, AFAIK, have one
<moony>
DaKnig: I don't have a ULX3S :P
<whitequark>
so unless you track down the original contributor your best bet is fixing it yourself
<moony>
I'm only using the board's platform rn in prep to get one
<moony>
i can fix it myself when I get the board
<moony>
anyway, so I can't use connectors at all?
<whitequark>
you can
<whitequark>
you need to add a resource that uses the connector
<awygle>
the contributor was ktemkin I believe
<whitequark>
resources describe interfaces of ICs, like the IO of an SPI flash
<DaKnig>
moony: you can always look at the schematics
<whitequark>
so they have subsignals, directions, and so on
<whitequark>
connectors, by themselves, don't have those, with rare exceptions
<moony>
I can't test though.
<whitequark>
a pmod connector doesn't have inputs or outputs, a pmod extension board does
<moony>
I'll fix the obvious issues at least
emeb_mac has joined #nmigen
lkcl__ has joined #nmigen
<moony>
whitequark: There's a total of 27 diff pairs, so presumably it's OK if I generate them from the GPIO list instead of typing them out by hand? :p
<whitequark>
moony: I don't know why are there gpio_diff resources and I don't really think there should be
<moony>
mk
lkcl_ has quit [Ping timeout: 265 seconds]
pdp7 has joined #nmigen
Asu has quit [Remote host closed the connection]
<DaKnig>
what happens when you assign short signed signals to longer unsigned signals?
<DaKnig>
sign extend?
<DaKnig>
I mean current behavior
<DaKnig>
`Signal(3).eq(Signal(signed(1))`
jeanthom has joined #nmigen
<Lofty>
It gets sign extended, since the signal there is signed
Yehowshua has joined #nmigen
<Yehowshua>
whitequark, its seems `from nmigen.sim.pysim import Simulator` has now become `from nmigen.sim.core import Simulator`
<whitequark>
`from nmigen.sim import Simulator`
<whitequark>
that's what the deprecation warning recommends now
<whitequark>
but yes
<whitequark>
since `nmigen.sim.pysim.Simulator` has never appeared in a release I just changed it
<Yehowshua>
ah ok
<Yehowshua>
I think that was in some tutorial somewhere
<Yehowshua>
Just pulled from master and `nmigen.sim.pysim.Simulator` doesn't give a deprecation warning
<Yehowshua>
Not sure its a big deal, just something to note
<awygle>
i think the deprecation warning is on nmigen.back.pysim?
<Yehowshua>
Yup!
<Yehowshua>
you're right
<DaKnig>
how would I get more than one port for Memory?
<Yehowshua>
just request another
<Lofty>
Just call that port again
<whitequark>
Yehowshua: `nmigen.sim.pysim.Simulator` is just gone, since it was never in a release
<Yehowshua>
That video series from Baruch, he made extensive use of formal
<whitequark>
oh :/
<Yehowshua>
Although he suggest to make your own sby file, but it doesn't take long to find FHDLTestCase haha
<whitequark>
oh so he *doesn't* suggest to use it
<whitequark>
that's a relief
<awygle>
i think FHDLTestCase became popular mostly because going through all the sby rigamarole manually is hugely irritating
<jeanthom>
i think FHDLTestCase became popular because nMigen was "advertised" on Twitter as having first-class support for formal verification, and the only examples of formal in nMigen were FHDLTestCase-based so people thought it was the normal way to do it
<whitequark>
oh
<whitequark>
yeah, those all seem true
<whitequark>
that's not what i meant by "first-class support" but... that's entirely on me
<Yehowshua>
whitequark, I mentioned before that I like to run sim.run right after one another
<Yehowshua>
But, sync_process, yields Tick() before starting
<Yehowshua>
So you get an extra cycle in between every subsequent `sim.run()`
<whitequark>
yeah
<Yehowshua>
So I end up doing `sim.add_process` and manually adding `yield Tick()`
<Yehowshua>
Which is usually fine, except in multi-domain simulations
<whitequark>
you can do Tick("domain")
<Yehowshua>
I have to remember to change `domain=` for Tick
<Yehowshua>
If add_sync_process had some option like `prime=False`, that would solve those pain points
<whitequark>
nope, not going to happen
<whitequark>
add_sync_process isn't designed for testbenches in first place
<Yehowshua>
Hmm, what do you have in mind?
<whitequark>
instead of piling more and more options on top of a fundamentally flawed interface this is going to wait until #228 is done
Yehowshua has quit [Remote host closed the connection]
Yehowshua has joined #nmigen
<whitequark>
it's not "priming" of any kind, anyway
<whitequark>
the idea behind the existence of add_sync_process is that you can use it to replace a bunch of synchronous logic with behavioral Python
<whitequark>
in that case, not having the initial Tick() is just incorrect
* awygle
resets "days since I last clicked an issue reference and had my irc client open a useless channel" counter
<whitequark>
ouch
<whitequark>
we should get a bot here that expands github issue links or something
<awygle>
I do this constantly lol
<Yehowshua>
whitequark, I see
<Yehowshua>
Do you see a path where running smaller benches in succession becomes more natural?
<Yehowshua>
I know its not really intended to do that at the moment
<whitequark>
sure, seems something that's reasonable to support, especially with the startup latency of cxxsim
<awygle>
I +1 the use case
<awygle>
Although my motives are somewhat ulterior
<awygle>
Fuck, the sun is bright, I forgot
<Yehowshua>
Vampire troubles?
<awygle>
Quarantine + "it rains a lot here"
<Yehowshua>
Oddly enough, quarantine changed almost nothing for me
<Yehowshua>
14 hours a day in a basement in front of a computer
<Yehowshua>
whitequark, perused #228. Are there a lot of people using oMigen in nMigen?
<whitequark>
I'm not sure
<whitequark>
the nmigen.compat simulator interface will stay
<Yehowshua>
Anyways, getting the simulation interface right is clearly not trivial
<Yehowshua>
Theres a lot to think about
<Yehowshua>
awygle, why did you want support for succession of testbenches?
jeanthom has quit [Ping timeout: 256 seconds]
<awygle>
I have dreams of a responsive graphical simulator
<Yehowshua>
Maybe something in nMigen to make that simpler
<Yehowshua>
No idea how that would work
<whitequark>
mhm
<whitequark>
I think it's possible to have something like that in the core simulator
<whitequark>
it's not trivial, sure
<Yehowshua>
Yeah
<Yehowshua>
Next level stuff
<awygle>
If I had a python package for a non VCD Waveform format would that need core nmigen intervention to use with pysim/cxxsim
<whitequark>
yes
<Yehowshua>
hmm, are you think that could be the consumed by your hypothetical GUI?
<whitequark>
well
<whitequark>
you could do it without core nmigen intervention (or with minimal intervention), but with cxxsim it will be incredibly slow
<awygle>
hmm
Yehowshua has quit [Remote host closed the connection]
<whitequark>
awygle: the pysim engine has (or rather used to had, i removed it for uninteresting reasons) an internal abstract interface for waveform writers
<whitequark>
we could bring that back and make it public if there's lots of interest
<whitequark>
the cxxsim engine does not, and cannot
<whitequark>
in its model, every new waveform writer is implemented on the C++ side so you don't nullify the performance advantage by doing lots of roundtrips through ctypes
<whitequark>
awygle: can you take a look at ValueCastable etc?
<whitequark>
other than the two cxxsim bugs currently in the milestone, that's the only things that block 0.3 release
<whitequark>
(that said, the cxxsim bugs will take a while to fix; it requires a new C++ module, a new C API, new bindings, etc)
<awygle>
i see, i see, and yeah
<awygle>
i have been drowning in work lately, ValueCastable is #3-ish on my list to do this weekend though.