<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 edited a comment on pull request #547: vendor.lattice_machxo_2_3l: fix sdc generation - https://git.io/Jkojb
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]
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?
<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 design.py
<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.)
<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
<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.