ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting November 23th
<lsneff> Ah, it was a compressed instruction
emeb has quit [Quit: Leaving.]
<lsneff> Apologies for all my questions and issues recently. Here's the last one for today: I've gotten the cpu to work EXCEPT, when I add the ice40 pll to my design, it stops working.
<lsneff> It's not possible (AFAIK) to simulate with the pll in, so ¯\_(ツ)_/¯
<lsneff> I'm not actually using the pll clock domain for the softcore, I'm using it for some other stuff that I know works
<whitequark> basically yeah, the PLL is not simulatable
<lsneff> Could messing with the clock domains for the pll be screwing up the clock that's getting to the softcore?
<lsneff> Yeah, looking at the generated verilog, something fishy is going on
<lsneff> And it all works! Thank you for all your help, everyone!
<_whitenotifier-f> [nmigen] whitequark commented on pull request #547: vendor.lattice_machxo_2_3l: fix sdc generation -
<_whitenotifier-f> [nmigen] whitequark edited a comment on pull request #547: vendor.lattice_machxo_2_3l: fix sdc generation -
Degi has quit [Ping timeout: 246 seconds]
Degi has joined #nmigen
<lsneff> Well, it's not working now, tries to write to the stack pointer, which is pointing to a high address for some reason. Oh well, I'll work on it again tomorrow.
peepsalot has joined #nmigen
peeps[zen] has quit [Ping timeout: 256 seconds]
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 272 seconds]
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 272 seconds]
PyroPeter_ is now known as PyroPeter
ming__ has quit [Quit: Connection closed for inactivity]
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined #nmigen
jeanthom has joined #nmigen
ming__ has joined #nmigen
Lord_Nightmare has quit [Quit: ZNC -]
Lord_Nightmare has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
chipmuenk has joined #nmigen
Shari2 has joined #nmigen
samlittlewood has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 240 seconds]
chipmuenk1 is now known as chipmuenk
chipmuenk has quit [Read error: Connection reset by peer]
chipmuenk1 has joined #nmigen
chipmuenk1 has quit [Read error: Connection reset by peer]
chipmuenk has joined #nmigen
emily has quit [Quit: Bridge terminating on SIGTERM]
jfng has quit [Quit: Bridge terminating on SIGTERM]
whitequark[m] has quit [Quit: Bridge terminating on SIGTERM]
cesar[m] has quit [Quit: Bridge terminating on SIGTERM]
gkelly has quit [Quit: Bridge terminating on SIGTERM]
chipmuenk has quit [Quit: chipmuenk]
chipmuenk1 has joined #nmigen
cesar[m] has joined #nmigen
chipmuenk1 is now known as chipmuenk
jeanthom has joined #nmigen
gkelly has joined #nmigen
jfng has joined #nmigen
emily has joined #nmigen
whitequark[m] has joined #nmigen
jeanthom has quit [Ping timeout: 246 seconds]
Shari2 has quit [Quit: Leaving]
<d1b2> <OmniTechnoMancer> @Sarayan MIPS while endian switchable is traditionally used in big endian mode so perhaps a loongson or something might help you?
<d1b2> <OmniTechnoMancer> Unsure what loongson use though
<d1b2> <OmniTechnoMancer> oh no apparently they are all little endian :/
ming__ has quit [Quit: Connection closed for inactivity]
FFY00 has quit [Remote host closed the connection]
FFY00 has joined #nmigen
zignig has quit [Ping timeout: 260 seconds]
chipmuenk has quit [Quit: chipmuenk]
chipmuenk has joined #nmigen
<lkcl> microwatt has full LE/BE support now as of about 4-6 weeks ago
jeanthom has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
emeb has joined #nmigen
electronic_eel_ is now known as electronic_eel
<lsneff> Is nmigen supposed to be able to catch signals that go cross domain?
<Lofty> lsneff: no
<Lofty> Well, it can catch driver conflicts
nfbraun has joined #nmigen
<whitequark> not yet
<lsneff> Oh okay
<Lofty> (I think?)
chipmuenk has joined #nmigen
<lsneff> Does nmigen have a way of outputting how many LUTs the design is using?
<d1b2> <TiltMeSenpai> like natively?
<d1b2> <TiltMeSenpai> if you're using nexpnr-based tools, there's some info in like the .rpt and .tim files
chipmuenk has quit [Quit: chipmuenk]
<whitequark> lsneff: nmigen doesn't have this data and doesn't generally have a reliable way to obtain it
jjeanthom has joined #nmigen
<whitequark> if you want to do a super quick estimate, try NMIGEN_verbose=1 python3
<whitequark> this should print it to your terminal once synthesis is done
jeanthom has quit [Ping timeout: 240 seconds]
<lsneff> Oh huh, thanks
emeb_mac has joined #nmigen
<nfbraun> Hi! I am currently trying to develop an nMigen AXI slave (on Xilinx Zynq).
<nfbraun> I noticed that, if the slave returns DECERR for a read transaction, this causes an "imprecise external abort", but for a write transaction, it seems to be ignored.
<nfbraun> It that expected behavior?
<whitequark> i'm not sure if there are any people in here who have used AXI4 that closely
<whitequark> all i can say is "this doesn't seem uncommon"
<whitequark> i've hit the same problem with wishbone
<d1b2> <DX-MON> I'd have to go digging in my old AXI peripheral sources to tell you if that's expected behaviour, which I currently don't have the bandwidth to do - sorry
<nfbraun> I tried googling it, but found it surprisingly hard to find anything. You'd think this kind of stuff would be documented somewhere :/
<daveshah> Yeah this matches my experience of ending up in the more esoteric corners of the Zynqs too
<d1b2> <DX-MON> the "documentation" is generally the Xilinx IP cores for the Zynq
<d1b2> <DX-MON> or see if you can find the right part of ARM's website
<daveshah> You are sure the write is actually happening and there isn't something odd like write-combine or caching going on?
<daveshah> Seems obvious but its the kind of thing that's bitten me with this stuff before
<nfbraun> I have counters that count the number of write address / write data / write response, and they all increment as expected.
<nfbraun> (As in, they increment by 1, just like for a legal write.)
jjeanthom has quit [Ping timeout: 256 seconds]
<lsneff> Well, I gotta get the fpga to communicate with my laptop now, I guess serial is the way to go witht hat.
<whitequark> yeah
<lsneff> I noticed that the generated verilog has src loc annotations. Do any tools actually use that info?
flow has joined #nmigen
<whitequark> i'm not entirely sure
<whitequark> the support is definitely *poor*, but i think there was a nextpnr patch?
<lsneff> Do you think a debugger that's shows you which conditionals in your nmigen/verilog code are activated on a particular clock cycle would be possible with that info?
<lsneff> Something akin to a regular debugger, but for fpga simulations
<whitequark> yes, and I would quite like to do that
<whitequark> unfortunately, the only viable route at the moment is integrating with gtkwave
<whitequark> and gtkwave is the ninth circle of hell
<lsneff> Why's that?
<whitequark> take a look at its source code
<whitequark> just... scroll through several files. you'll see.
<lsneff> No, like why is it only possible by integrating into gtkwave?
<lsneff> I'm not surprised it has terrible source, all those old gui programs written in C seem to be.
<flow> I just got started with nMigen and have no Idea about it yet. I am trying to access a PLL in an ECP5 but I did not find any hints how to access hard IP from nMigen. Can someone point me to resources explaining how to do it?
<whitequark> lsneff: there are no other waveform viewers that can replace gtkwave
<whitequark> well, no open-source ones
<whitequark> pulseview is sadly not even close for HDL developer purposes
<whitequark> as for terrible: i could live with terrible. gtkwave takes it to 11.
<whitequark> it invents several new ways to be terrible in that i would not previously consider possible
<whitequark> like, communicating with gtkwave on windows involves the MSVC bitfield ABI *and* Cygwin
<d1b2> <OmniTechnoMancer> What a joyous blessing it provides
<whitequark> it's almost if someone went out of their way to make it as painful as possible to do from something like Python
<whitequark> you know, on top of all the normal terrible stuff
emeb has quit [Quit: Leaving.]
<agg> flow: might help
<agg> (use `ecppll` or diamond to find suitable values for ICP_CURRENT, LPF_RESISTOR, and the dividers if you want too
<flow> Ahh thanks that is what I was looking for!
<agg> the key thing is Instance, with attributes like a_BLA, parameters like p_BLA, inputs like i_BLA, outputs like o_BLA, etc, but yea you get the idea
<agg> and if you're making a PLL you probably want your own sync clock domain instead of the default one, which is what that snippet does, but up to you
<whitequark> thanks agg
<lsneff> whitequark: hmm, I was thinking something that would integrate into vscode or an editor like that, vim etc. Maybe using two tools would work? (gtkwave + debugger)
<lsneff> Also, gtkwave doesn't strike me as incredibly difficult to copy in functionality. I definitely could be wrong and probably aren't using gtkwave to its full.
<whitequark> yes, my plan was to write something that integrates with sublime text
<whitequark> (maybe use the LSP protocol? no idea)
<whitequark> regarding rewriting gtkwave: if you succeed, an enormous amount of people will be grateful forever
<agg> so long as you keep or improve the bootup splash image, anyway :p
<whitequark> ha
<agg> which i swear i only get to see after restarting my whole system or something
<lsneff> Hmm
<lsneff> What functionality does gtkwave have outside of being able to view signals over time and changing how they're interpreted?
<agg> you can give it a few gigabytes of .vcd and it doesn't choke and draws them without missing edges, which i guess isn't that complicated but probably accounts for some of it
nfbraun has quit [Quit: leaving]
<agg> plus like a hundred little but useful features: loading enum names from the file, running filter code on values, the long list of interpretations, wave highlights, a vaguely useful skip-to-next-edge on arrow keys, searching for values, all that
<whitequark> the mipmapping of very large vcd files is the killer feature
<whitequark> any replacement *must* be built from ground up to handle extremely large VCDs, larger than the RAM even
<whitequark> the rest is mostly incidental
<lsneff> Alright, yeah, that should be okay. I have some experience with rendering very large scenes. Wrote some software that rendered a couple hundred million atoms for molecular visualization stuff earlier this year.
<lsneff> I'll give it a go
<d1b2> <Hardkrash> There is this for the mac
<d1b2> <Hardkrash> re: gtkwave