ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 20th
<d1b2> <edbordin> I was wondering why there was obnoxiously loud background music on the podcast....turns out I forgot to stop the music I had playing -_-
Yehowshua has quit [Remote host closed the connection]
Yehowshua has joined #nmigen
Yehowshua has quit [Ping timeout: 245 seconds]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
lkcl_ has joined #nmigen
lkcl__ has quit [Ping timeout: 240 seconds]
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
mwk has quit [Ping timeout: 244 seconds]
Yehowshua has joined #nmigen
<Yehowshua> So I've got the TinyFPGA using USB->Serial as a UART. USB of course is fixed at 48MHz which means I need an AsyncFIFO to get data into faster clock domains. Been browsing for an example to use for Migen's AFIFO in `nmigen.lib`. Any pointers?
<trabucayre> Yehowshua: Sorry for yesterday:
<Yehowshua> Thanks! :)
<ktemkin> Yehowshua: what are you using for USB->Serial?
<Yehowshua> Whitequark had mentioned Luna too - but by that time, already had the dadvidthings code up and running
<ktemkin> mm, yeah, I was wondering which of the two you were using, since that'd partially inform the solution
Yehowshua has quit [Remote host closed the connection]
<ktemkin> I'm not sure any of the uses I have are especially good examples
Yehowshua has joined #nmigen
<Yehowshua> Well - I'd be happy to switch to Luna if it can do multiple domains already
<Yehowshua> Do you have any links to some AFIFO code?
<ktemkin> you shouldn't have to switch; I can pull up an equivalent step-down example
<ktemkin> just not a Great one
<ktemkin> <-- this was pretty much directly ported from some omigen code, but it shows some use for stepping down to a lower-frequency domain
Yehowshua has quit [Remote host closed the connection]
Yehowshua has joined #nmigen
<Yehowshua> Thanks.
<Yehowshua> It makes sense to me
Yehowshua has quit [Ping timeout: 245 seconds]
Yehowshua has joined #nmigen
<Yehowshua> ktemkin, I'm really liking right-aligning `.eq`. in that example code you sent.
<Yehowshua> [n]Migen's `.eq` never looked as pretty as Spinal's `:=`, but right aligning gets close
Yehowshua has quit [Ping timeout: 245 seconds]
jeanthom has joined #nmigen
mwk has joined #nmigen
hitomi2504 has joined #nmigen
chipmuenk has joined #nmigen
jeanthom has quit [Ping timeout: 258 seconds]
jeanthom has joined #nmigen
<d1b2> <286Tech> I knew there were some issues lately with pysim, and I think I'm running into them.
<d1b2> <286Tech> Unless I'm doing something wrong.
<d1b2> <286Tech> If you have a stimulus process, then just a yield will advance the clock by one cycle right? Assigning to a signal yield dut.a.eq(1) will not AFAIK.
<d1b2> <286Tech> Sorry, I meant to say that pysim seems to work correctly, but the VCD file looks off.
<d1b2> <286Tech> I set a signal to 1, do a yield, then set it to 0, and yield again, but the VCD file only shows the 1, but not the 0.
<d1b2> <286Tech> After looking at it more closely, the outputs of the DUT seems correct in the VCD file. It's just that the inputs that I assign in the stimulus process is wrong.
<jeanthom> 286Tech: could you upload your stimulus process somewhere?
<d1b2> <286Tech> Sure
<d1b2> <286Tech> I just started building an instruction fetch module, and now I've run into this.
<d1b2> <286Tech> For example, i_stall remains 1 in the VCD file (even though the outputs behave correctly), and so does i_load, i_data, and i_load_addr.
<d1b2> <286Tech> They keep the value that they were assigned first in the VCD file.
Asu has joined #nmigen
<jeanthom> 286Tech:
<jeanthom> i_stall is only 1 for one cycle
<d1b2> <286Tech> Interesting
<jeanthom> which version of nMigen are you using?
<d1b2> <286Tech> The latest
<jeanthom> weird :/ I'm running the latest too
<d1b2> <286Tech> nmigen==0.3.dev141+g5ccc212
<jeanthom> also Version: 0.3.dev141+g5ccc212
<d1b2> <286Tech> Hmm, maybe the python version?
<d1b2> <286Tech> 3.8.3 here
<jeanthom> 3.8.3 from Fedora 32 in my case
<d1b2> <286Tech> So that's the same as well. I'm on RebornOS (Arch-based).
<jeanthom> what's really weird is that your input signals gets updated on the falling edge
<d1b2> <286Tech> I don't get it either 😛
<jeanthom> oh
<jeanthom> which version of GtkWave?
<jeanthom> mine is v3.3.104
<d1b2> <286Tech> Sorry, was AFK for a second.
<d1b2> <286Tech> Uh
<d1b2> <286Tech> v3.3.104
<jeanthom> 286Tech: could you send me your VCD? moi <aaaaa>
<d1b2> <286Tech> Sent
<jeanthom> Received
<d1b2> <286Tech> Ok, so I've tried on my laptop (same OS, same nmigen and gtkwave version) and there it works fine...
<jeanthom> Have you modified parts of nMigen?
<jeanthom> how did you install nmigen?
<jeanthom> pip install?
<d1b2> <286Tech> Just pip install from the nmigen/nmigen repo.
<jeanthom> maybe check your ~/.local/lib/python3.8/site-packages/ folder and ensure you only have one nmigen version in there
<d1b2> <286Tech> I have found one difference
<d1b2> <286Tech> On this PC (wrong vcd) I have pyvcd version 0.2.1, whereas on my laptop I have 0.2.3
<jeanthom> I have pyvcd 0.2.1
<d1b2> <286Tech> And I saw that I did sudo pip install on my PC, and just pip install on my laptop.
<d1b2> <286Tech> So one is system wide, and one is local
<jeanthom> oh
<jeanthom> I actually have both pyvcd 0.2.3 and 0.2.1
<d1b2> <286Tech> pip show pyvcd says it's 0.2.1 on my pc, but when checking /usr/lib/python-3.8/site-packages/ I see 0.2.3
<d1b2> <286Tech> Python and packages...
<d1b2> <286Tech> Oh, I have one in my local as well
<d1b2> <286Tech> Let me just remove everything from system wide, and just install locally
<d1b2> <286Tech> Ok, now it works correctly 🙂
<d1b2> <286Tech> Thanks for helping me \o/
<jeanthom> My pleasure :)
chipmuenk has quit [Quit: chipmuenk]
jeanthom has quit [Quit: Leaving]
chipmuenk has joined #nmigen
electronic_eel_ has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
<FL4SHK> I might be going insane
<FL4SHK> My assembler's scope feature is supporting variables, such that you can find the offset into the stack frame via a name
<Lofty> Welcome to the club
<FL4SHK> it also supports register saving/restoring
<FL4SHK> was thinking of also supporting destructors...
<FL4SHK> via a Python `with` statement
<FL4SHK> metaprogramming is really great :^)
jock-tanner has quit [Ping timeout: 240 seconds]
<_whitenotifier-b> [nmigen-boards] rroohhh opened pull request #83: mercury: fix SPI roles -
<_whitenotifier-b> [nmigen-boards] rroohhh edited pull request #83: mercury: fix SPI roles -
Yehowshua has joined #nmigen
<Yehowshua> FL4SHK: wait - are you writing an assembler in Python?
<_whitenotifier-b> [nmigen-soc] rroohhh opened pull request #23: test: make nmigen 0.3+ compatible -
<_whitenotifier-b> [nmigen-soc] codecov[bot] commented on pull request #23: test: make nmigen 0.3+ compatible -
<_whitenotifier-b> [nmigen-soc] rroohhh commented on pull request #23: test: make nmigen 0.3+ compatible -
proteus-guy has quit [Ping timeout: 240 seconds]
<FL4SHK> Yehowshua: I'm writing it in this style: I pass a Python list to the assembler
<Yehowshua> FL4SHK : Sounds like you're doing some DSL? Using`with` is kinda neat. I noticed that nMigen's RTLIL emitter has with statements so that scopes within the AST are tab aligned.
<FL4SHK> yes, doing a DSL of sorts
<FL4SHK> that's how the assembler will be working
<Yehowshua> What ISA does it target?
<FL4SHK> custom one
<FL4SHK> I find the process fun
<Yehowshua> Haha - I bet
<FL4SHK> It's MIPS like in some ways
<Yehowshua> My friend did a haskell assembler once
<Yehowshua> Was good for catching errors cuz haskell is functional
<FL4SHK> I've built stereotypical assemblers with lexers and parsers before
<FL4SHK> this is better because it allows me to include higher level stuff in it
<FL4SHK> I always included scopes in my assemblers
<FL4SHK> that way you get local labels
<Yehowshua> That's a smart idea now that I think about it
<Yehowshua> Is it public?
<Yehowshua> The repo that is
<FL4SHK> Yes
<FL4SHK> I can point you to the instruction set
<Yehowshua> gladly
<FL4SHK> so I'm developing a video game console of sorts
<FL4SHK> ordered the audio hardware (there's not going to be much to it)
<Yehowshua> Dang - that's p awesome
<Yehowshua> FPGA?
<FL4SHK> I'm doing this with the DE0-CV
<FL4SHK> which uses a Cyclone V
<FL4SHK> had to order a PS/2 keyboard
<Yehowshua> I remember those!
<Yehowshua> Didn't know people still buy Altera though...
<FL4SHK> I mean
<FL4SHK> I also have an Arty A7 dev board
<FL4SHK> which I intend to use for faster stuff
<FL4SHK> got VGA signal generation working
<Yehowshua> I had an Arty - but the first time I programmed it with Vivado, it died
<Yehowshua> Have you tried ECP5 - the Versa is decently powerful
<FL4SHK> What is that?
<Yehowshua> versa 5g ecp5
<Yehowshua> Its a Lattice FPGA
<FL4SHK> I've never owned any Lattice FPGAs
<Yehowshua> It open source - well it was reverse engineered
<Yehowshua> It works. with yosys+nextpnr+prjtrelli ecpprog
<Yehowshua> Its also directly supported in nmigen's board utility
<FL4SHK> one thing I'd like to do at some point is put place and route on the GPU
<FL4SHK> using Cuda or OpenCL
<Yehowshua> Wait - I'm not following
<Yehowshua> Do you mean you want a GPU with FPGA fabric?
<FL4SHK> I think the place and route problem, an NP hard problem, would benefit from being implemented as an island model genetic algorithm
<FL4SHK> no
<FL4SHK> I mean I want to look at nextpnr
<FL4SHK> and make it run on a host's GPU
<Yehowshua> So nextpnr does have CUDA annealing support
<FL4SHK> oh it does?
<FL4SHK> this is good
<FL4SHK> what about OpenCL?
<Yehowshua> I think... My friend wrote one - I don't know if he did a pull request
<FL4SHK> I mean, I've got an nvidia GPU in my main machine
<Yehowshua> Lemme ask him
<daveshah> Never seen that
<daveshah> And nextpnr doesn't use annealing for the bulk of placement now anyway
<FL4SHK> island model GA is another solution
<FL4SHK> I think that's what I'd use for running it on the GPU
<daveshah> Hypothetically you could run the sparse matrix solver on the GPU but the benefit would be non-existent
<FL4SHK> I'll need to take a look at this at some point
<FL4SHK> because the place and route stage takes forever
<FL4SHK> NP hard search problems are good to place in an island model GA
<daveshah> The problem with all these things is not the algorithm but actually dealing with all the real world constraints
<FL4SHK> What do you mean?
<daveshah> I suspect that there are other faster heuristics, particularly for routing which is the pain point
<daveshah> something like GA would be my choice when I cared about QoR over runtime
<FL4SHK> island model GAs are faster than regular GAs
<FL4SHK> What's "QoR" stand for?
<daveshah> all the complexities like fracturable LUTs, placement rules, etc
<daveshah> quality of results
<FL4SHK> ah
<Yehowshua> OK - just asked him - he said he added CuBlas support for analytical
<Yehowshua> But he didn't get much speedup
<daveshah> Yes, that's what I'd expect tbh
<Yehowshua> He also did not pull request
<FL4SHK> well, all right.
<daveshah> The main problem is route time, but this is more down to the placer needing more routeability heuristics
<Yehowshua> daveshah, did you know there are some companies using nextpnr in production?
<FL4SHK> I've never used nextpnr
<daveshah> which is what I've been working on, although taking even a fairly detailed paper and example code (RippleFPGA) and actually turning it into a useful, generic, real-world implementation is quite tricky
<daveshah> That's interesting - for an existing arch or for their own FPGA arch?
<Yehowshua> For ice40
<daveshah> Nice!
<Yehowshua> Lemme find the link
<daveshah> Thanks!
<Yehowshua> Yep!
<Yehowshua> They are also looking at nMigen
<Yehowshua> They already use migen I believe
<Yehowshua> They make open source MOBOs for IBM POWER server customers
<daveshah> I would be quite tempted by one of those, if I didn't have to run vendor tools (for fuzzing)
<FL4SHK> Yehowshua: did you get a chance to look at the instruction set?
<Yehowshua> Yes
<Yehowshua> Its nice and tidy :)
<FL4SHK> 34 instructions
<Yehowshua> Although - do you have a compiler for C?
<FL4SHK> did you see `pre`?
<FL4SHK> `pre` is a bit weird
<FL4SHK> but it enables immediates to be sized up to the full 32 bits
<Yehowshua> Yes - I'm wondering what you use that for?
<Yehowshua> Ah
<FL4SHK> basically it would allow for a C compiler to not need to know the size of an immediate ever
<FL4SHK> kind of as an in-hardware optimization
<Yehowshua> That makes sense
<FL4SHK> cross-translation-unit calculations come to mind as potentially causing the C compiler to need to emit code that's less optimal
<Yehowshua> Have you tried the LLVM kaleidoscope tutorial?
<FL4SHK> `pre` completely eliminates the problem by being inserted by the assembler
<FL4SHK> No, but I've worked with GCC before
<Yehowshua> Modifying LLVM for RiSC ISA isn't bad
<Yehowshua> Ah - GCC is ugggly
<FL4SHK> I've actually made GCC spit out code for a custom architecture before
<FL4SHK> I got farther with GCC than LLVM
<FL4SHK> by that I mean
<Yehowshua> That's masochism
<FL4SHK> have you tried doing it with GCC before?
<FL4SHK> It's a lot easier than you might think
<FL4SHK> LLVM is too quickly moving than I'm okay with
<Yehowshua> No - just browsed the course a bit
<FL4SHK> so I'd have to keep updating the backend a lot more
<Yehowshua> OK - I'll give it a shot!
<FL4SHK> look into ggx/moxie
<FL4SHK> retargeting the GNU toolchain
<FL4SHK> by Anthony Green
<FL4SHK> it's ridiculously helpful
<FL4SHK> and it goes over Binutils porting, which you need
<Yehowshua> Thanks
<Yehowshua> You may also like this
<FL4SHK> you probably need that even for working with LLVM
<FL4SHK> That's neat
<Yehowshua> Right - I saw somebody do LLVM without binutils - it was really hard
<FL4SHK> I was really making this assembler, by the way, because I thought it'd be fun to make a game in assembly
<FL4SHK> I can make a game in C++ for any system
<FL4SHK> but here I get to work directly with my own hardware
<FL4SHK> I'd pick C++ if I were going to do it in an HLL
<FL4SHK> I've gotten good at developing instruction sets and then implementing them over the years
<FL4SHK> been doing it since 2016
<FL4SHK> been writing C++ since 2008
<FL4SHK> got really good at programming
<FL4SHK> write VHDL for a living now
<FL4SHK> ...or at least, sometimes my job involves writing VHDL
<FL4SHK> and sometimes it involves writing requirements
<FL4SHK> I enjoy writing requirements here because I get to make some design decisions, even
<FL4SHK> ...though I can't say much about what I do
<FL4SHK> I do work in aerospace, though
<Yehowshua> Aerospace - makes sense
<Yehowshua> I worked in defense embedded sometime back too
<FL4SHK> oh, yeah, I'm also in defense
<FL4SHK> U.S. defense, that is
<Yehowshua> Same
<FL4SHK> Do you work for a particular company or the government now?
<Yehowshua> I actually started a company
<FL4SHK> oooh
<FL4SHK> that's my goal
<Yehowshua> So I guess I work for myself
<FL4SHK> What do you do?
<Yehowshua> Have you heard of Luke Leighton's LibreSOC
<FL4SHK> I've heard of LibreSOC
<FL4SHK> this channel, no less
<FL4SHK> I think I had heard of it prior to coming to #nmigen, too
<Yehowshua> Well, I have some connections with money
<Yehowshua> We're funding that project
<Yehowshua> I'm also looking into funding nMigen as well, we've funded nMigen a little so far
<Yehowshua> We have some customer in the IBM power ecosystem
<Yehowshua> **customers
<FL4SHK> I have a future project in mind where I'll be making a full SoC, implemented in an FPGA
<FL4SHK> I want to make a single board computer
<FL4SHK> FPGA based only because I can't afford to get an ASIC made
<FL4SHK> Now, here's what I want to do
<FL4SHK> I want to be running my own hardware as my main computer
<Yehowshua> Skywater should help bring the costs down
<FL4SHK> I don't need as much room for cache in the style of CPU I plan on using
<Yehowshua> > I want to be running my own hardware as my main computer
<FL4SHK> yes
<Yehowshua> That's the spirit!
<FL4SHK> I've got this Arty A7 dev board
<FL4SHK> with 256 MB of RAM On it
<FL4SHK> which, really, isn't enough any more, so I might be connecting multiple dev boards together
<FL4SHK> short of just constructing the dev board myself
<FL4SHK> I've got some compilers background
<FL4SHK> Here's another thing I want to do
<FL4SHK> make an interpreted, statically typed language, something like Python
<FL4SHK> but with good support for creating DSLs, like Python
<Yehowshua> Rust does that already?
<FL4SHK> Rust isn't going to run on my custom architectures unless I make an LLVM backend, which I guess I could do
<Yehowshua> Oh right!
<FL4SHK> Rust is good for DSLs?
<FL4SHK> I kind of want to make my own nMigen
<Yehowshua> Jacob Lifshay says it is...
<FL4SHK> just with a different host language
<FL4SHK> I see, I've never heard of him
<Yehowshua> But he also says Rust is good for everything
<Yehowshua> I want to be running my own hardware as my main computer
<Yehowshua> Clipboard error
<Yehowshua> There
<FL4SHK> My main computer is going to be doing this thing where you work with cache lines instead of registers
<Yehowshua> He also wrote a shader for a custom architecture I think
<FL4SHK> I've built a machine like this before, in SV
<Yehowshua> daveshah, has Lattice ever reached about about a collaboration on NextPNR?
<daveshah> Yes, but things move slowly so I can't really say much yet
<Yehowshua> OK. That's fantastic
<FL4SHK> Yehowshua: so do you think having only full products for multiplies is a problem?
<FL4SHK> also, is it possible to use an unsigned full product to implement a signed full product?
<Yehowshua> Can you expand a bit? I haven't heard of the term full product before
<FL4SHK> multiply two 32-bit numbers, producing a 64-bit result
<Yehowshua> I don't think its a problem
<Yehowshua> In fact, I think its quite useful!
<Yehowshua> Especially with fixed point
<FL4SHK> for this video game console, there's no floating point
<Yehowshua> Oh - I see. You don't have a mvfhi instruction?
<FL4SHK> this isn't quite MIPS
<FL4SHK> multiplies encode both hi and low into the instruction
<FL4SHK> `mulu rA, rB, rC, rD`
<FL4SHK> I think I might just include signed full products
<Yehowshua> That's clever
<daveshah> Have you factored into this the cost of two write ports?
<FL4SHK> two write ports of what?
<daveshah> Or are your multiplies multicycle?
<daveshah> Wherever your two destination registers are
<FL4SHK> oh, for the register file
<FL4SHK> I didn't think about it, no
<FL4SHK> Probably going to just make multiplies multi-cycle
<Yehowshua> That's fascinating thought. I'm actually testing multi port writes on the ice40 this afternoon
<Yehowshua> See how it affects BRAM
<FL4SHK> since the register file is rather small, I can probably just implement registers out of logic
<Yehowshua> **BRAM count
<FL4SHK> but BRAM is probably faster
<daveshah> Unfortunately, Yosys doesn't do any tricks to map multiple write ports
<daveshah> So it will end up as FFs
<FL4SHK> I could just use two memories
<Yehowshua> Yeah - that's what I suspected
<daveshah> There are various ways round it, either using a XOR trick
<FL4SHK> My way seems to be "just use more block RAM!!!1one"
<daveshah> or a small FF based memory to track which was last written
<FL4SHK> honestly, though
<FL4SHK> I might just expand the pipeline
<daveshah> You don't just need more block RAM, you also need one of those tricks
<FL4SHK> probably make it so there are two write stages
<Yehowshua> Also, daveshah, if you want to show validity of nextpnr in industry, I know a couple place where its used, in case that comes up in future convos with Lattice
<daveshah> Yes, that would definitely be helpful.
<FL4SHK> daveshah, does having two write stages cause much of a problem?
<daveshah> You mean you only do one write per cycle?
<FL4SHK> well, yeah, and it solves the race condition when you encode the destination registers as the same
<daveshah> I guess that will create a bubble when you multiply
<FL4SHK> there's already going to be a bubble
<FL4SHK> because it's multi cycle
<daveshah> I don't know enough about CPU arch to know if that's a major issue
<daveshah> Right
<daveshah> If your multiply is already multicycle then it's probably going to be cheaper than a two write ported file
<daveshah> If that's the only thing you need two write ports
<FL4SHK> I believe it's the only thing I need two write ports for
<daveshah> If you dual issued other instructions, then the cost of two write ports would be much more worthwhile
<FL4SHK> this machine isn't intended for maximum performance
<FL4SHK> CPU dev was my main draw into hardware
<daveshah> For a game console, other accleration is probably more interesting anyway
<daveshah> Lots of fun to be had with video and audio
<FL4SHK> this is going to be kind of like a GBA
<FL4SHK> got the VGA signal generation done
<FL4SHK> but it'll be running at a high enough clock rate for software 3D
<FL4SHK> if the GBA can do software 3D, so can this thing
<Yehowshua> What company do you do AERO for - if you can say...
<daveshah> Yeah
<Yehowshua> I was at GTRI
<FL4SHK> Boeing
<FL4SHK> I had nothing to do with the incidents last year though
<Yehowshua> Yeah - no shame man
<FL4SHK> so for this assembler I'm making
<FL4SHK> I've even got stack frame stuff set up...
<FL4SHK> decided upon this structure
<FL4SHK> fp + 0: register save area
<FL4SHK> fp + register_save_area_size: local variables
<Yehowshua> I'm kinda impressed actually
<Yehowshua> How long did that take you?
<FL4SHK> to do what now?
<FL4SHK> the assembler?
<FL4SHK> It's not done!
<Yehowshua> stack fram structure
<FL4SHK> oh, that was pretty easy
<FL4SHK> I've done this before, but it's been a while
<FL4SHK> it's very simple
<FL4SHK> look at the description
<FL4SHK> that's all there is to it
<Yehowshua> I'm writing a compiler for my thesis - and still haven't finished the stack - by my ISA is intended for CNNs - go figure
<Yehowshua> **but
<FL4SHK> fp + register_save_area_size + local_variables_size: stack
<FL4SHK> that's all there is to the stack frame
<Yehowshua> OK - so pretty simple
<FL4SHK> yeah
<Yehowshua> CNNs - convolutional neural networks. Mainly reducing convolutions, then freeing up the heap
<FL4SHK> I forget how to compute convolutions, but I think it was like, a dot product?
<FL4SHK> I didn't get very far into signals and systems
<FL4SHK> took two course on the stuff
<FL4SHK> but I don't remember how to do it
<FL4SHK> I also don't remember how to do calculus beyond some really simple stuff
<Yehowshua> Convolutions are basically equivalent to polynomial dot products
<FL4SHK> there was a continuous form using integrals, also
<Yehowshua> Yup!
<FL4SHK> I do think I want to learn some filter stuff at least
<FL4SHK> I want to build a DAC of some sort
<FL4SHK> PDM + a filter
<Yehowshua> I did a lot of e-mag some time ago that made heavy use of convolutions. But CNNs are mainly for AI in image recognition.
<d1b2> <emeb> easy to do
<d1b2> <emeb> (pdm dac)
<FL4SHK> I don't know how to pick the parameters for such a DAC
<FL4SHK> nor how to compute PDM just yet
<FL4SHK> I've got some capacitors and a lot resistors
<FL4SHK> just ordered some breakout boards for audio
<FL4SHK> gotta have something for audio in my game console
<d1b2> <emeb> make an accumulator the same width as your data. use the carry out as the pdm output bit
<FL4SHK> oh?
<FL4SHK> that's all it takes?
<d1b2> <emeb> yep
<FL4SHK> that's really easy
<d1b2> <emeb> very
<FL4SHK> what am I accumulating? samples?
<d1b2> <emeb> yes
<FL4SHK> nah, I've got it
<FL4SHK> though I might take a peek
<FL4SHK> I don't think I'll ever go back to SV outside of work
<FL4SHK> nMigen covers my needs far, far too well
<d1b2> <emeb> then on the output pick R & C so the corner is at or below nyquist of the sample rate.
<d1b2> <emeb> for my system the sample rate is << clock rate
<Yehowshua> yes, nMigen is quite good. I tried to switch some courses at my school that I help teach to nMigen
<Yehowshua> The students totally freaked
<FL4SHK> they freaked out?
<Yehowshua> But I think if nMigen were to become heavily used, it would have to be taught early on
<Yehowshua> Yeah - they had never seen git or python before
<FL4SHK> oh, this must be low level coursework, then
<Yehowshua> They also didn't know how to install thing with package managers
<d1b2> <emeb> that's a lot to take in all at once
<Yehowshua> Yeah, like sophomore year
<FL4SHK> I studied a lot of computer science stuff on my own
<FL4SHK> don't have a degree in it
<FL4SHK> I have a mechanical engineering undergrad degree and an electrical engineering master's degree
<Yehowshua> I'm computer engineering - although I didn't really learn any of my compiler RTL skills in school
<Yehowshua> I have an iMac G3, and only FOSS FPGA tools work on it haha
<Yehowshua> So that's how I got into this stuff
<FL4SHK> I got into CPU dev because I really wanted to make CPUs, haha
<d1b2> <emeb> iMac G3 - now that's historic hardware!
<Yehowshua> Yup! I tried running yosys on my MacSE 1987 too!
<Yehowshua> But doesn't have enough memory.
<d1b2> <emeb> heh
<Yehowshua> I don't believe that you should upgrade hardware just because something better exists
<Yehowshua> Good software should run on old hardware
<d1b2> <emeb> I was proud of myself for getting icestorm/yosys/nextpnr running on an RPi Zero. You win.
<Yehowshua> lolz
Yehowshua has quit [Remote host closed the connection]
<_whitenotifier-b> [nmigen-soc] whitequark commented on pull request #23: test: make nmigen 0.3+ compatible -
hitomi2504 has quit [Quit: Nettalk6 -]
<FL4SHK> emeb, regarding picking R and C "so the corner is at or below nyquist of the sample rate", what's the "corner"?
<d1b2> <emeb> the corner frequency of an RC low-pass filter is F = 1/(2piR*C)
<FL4SHK> I don't know my analog foo very well
<d1b2> <emeb> so pick your R and C values so that F is at about 1/2 the sample rate.
<d1b2> <emeb> ie - I wanted about a 20kHz corner frequency so I used a 100 ohm R and a 0.1uF C
<FL4SHK> Is F the highest frequency that'll get passed through?
<agg> bear in mind if you are just using a single RC filter, it rolls off very slowly, so you might actually want to put the -3dB frequency a lot lower than half your sample rate
<d1b2> <emeb> Well, a single-pole RC lowpass doesn't roll off fast. That's where it starts to ramp down at 6dB/oct
<FL4SHK> I don't know what "rolling off" means
Yehowshua has joined #nmigen
<Yehowshua> Well is signal processing, you can delete frequencies - they are attenuated smoothly
<Yehowshua> **can't
<Yehowshua> **in not is
<d1b2> <emeb> If you plot a curve of attenuation vs frequency - roll off is how it slopes downward with increasing freq
<FL4SHK> I suppose I don't really need to know much about advanced filtering for what I'm trying to do
<d1b2> <emeb> not really. this is pretty fool-proof
<FL4SHK> going to be really cool to hear this working
<FL4SHK> I want to make, like, Gameboy type audio hardware
<FL4SHK> ...with a better wave channel
<DaKnig> if you are using a first order filter (one resistor and one cap) then look at the red line
<DaKnig> cutoff frequency here is W=1. notice how its 3 dB below the pass band amplification. note the slope.
<DaKnig> @Yehowshua wdym "you cant delete frequencies"? is that not what notch filter does (in theory at least)?
<FL4SHK> filtering is outside my area!
<FL4SHK> I understand high pass and low pass
<Yehowshua> DaKnig - you can't bring a frequency perfectly to zero...
<Yehowshua> Well, technically in discrete yes
<FL4SHK> you can unplug it
<FL4SHK> then it's zero!
<DaKnig> I just wanted to show you what cutoff frequency is and how it looks on a graph..
<Yehowshua> Still not then, brownian motion says that no frequency of any event is every zero
<DaKnig> its not "the last freqency that passes"
<DaKnig> that does not equist
<Yehowshua> from photon emission lines to actually particle vibration
<Yehowshua> **actual
<Yehowshua> So in conclusion, in discrete processing - yes you can delete. Natural phenomena - no.
<lkcl_> dlb2, 286Tech, jeanthom: "For example, i_stall remains 1 in the VCD file" this is a known issue
<lkcl_> you need to revert to commit 303ea18cb temporarily
<lkcl_> it was discussed and triaged a few days ago, let me see if i can find the bugreport
<lkcl_> dlb2, 286Tech, jeanthom: this one -
<lkcl_> it's nothing to do with pyvcd or gtkwave. it's to do with a reorganisation.
<lkcl_> "<FL4SHK> also, is it possible to use an unsigned full product to implement a signed full product?"
<lkcl_> FL4SHK: yes. although typically what is done (both RV and POWER9 do this) is an unsigned low-low, unsigned hi, and signed hi
<lkcl_> say you have a 64-bit multiplier in hardware, taking 32-bit inputs: there are *three* instructions
<lkcl_> one returns the low 32-bits of that 64-bit multiply
<lkcl_> one returns the *high* 32 bits of that 64 bit multiply (as unsigned)
<lkcl_> one returns the high 32-bits... as signed
<lkcl_> you can do a small amount of voodoo magic incantation before and after to make the inputs to the mul unsigned (abs) then convert afterwards.
<lkcl_> microwatt does exactly that:
<lkcl_> and you can see the absolut-ing of the inputs, here:
<d1b2> <286Tech> lkcl_: I just removed everything and installed nmigen locally, and now it works again as far as I can test 🙂
<lkcl_> dlb2, 286Tech: it may be the case that whitequark has fixed that bug in latest master nmigen
<lkcl_> FL4SHK: we converted that microwatt code to nmigen for the Libre-SOC multiply pipeline. this is the pre-analysis phase:
<lkcl_> signed/unsigned 32/64 bit detection starts at line 38. so everything is converted to doing an unsigned multiply, first
<lkcl_> then the post-analysis
<lkcl_> bottom line, it can be done, and it's dead simple :)
<DaKnig> by default, do sync clock domains have synchronous reset?
<FL4SHK> all resets are synchronous with nMigen DaKnig
<Yehowshua> there is a `reset_less` attribute in signals too
<lkcl_> nmigen/hdl/ - ClockDomain
<lkcl_> def __init__(self, name=None, *, clk_edge="pos", reset_less=False, async_reset=False,
<lkcl_> local=False):
<FL4SHK> oh
<FL4SHK> wait, I remembered wrongly
<FL4SHK> lkcl_
<FL4SHK> high -= (a >> (BITS - 1)) * b + (b >> (BITS - 1)) * a
<FL4SHK> that's all you need to translate an unsigned full product to a signed one
<lkcl_> FL4SHK: cool!
<FL4SHK> I got this from a friend, though
<lkcl_> a*b + b*a ...
<lkcl_> *curious*... why are there two multiplies?
<FL4SHK> a[0] * b + b[0] * a
<FL4SHK> wait no
<FL4SHK> a[len(a) - 1] * b + b[len(b) - 1] * a
<FL4SHK> that's what you use ^
<FL4SHK> it's not really a multiply
<FL4SHK> it's a mux
<lkcl_> ok yes top bit, yep.
<FL4SHK> high.eq(high - (a[len(a) - 1] ? b : 0) + (b[len(b) - 1] ? a : 0))
<lkcl_> FL4SHK: if you're going to do 2-port regfile write, you could consider doing "LD/ST-with-update" just like in PowerISA.
<FL4SHK> currently thinking of going with a simpler method
<lkcl_> (the address-generation part gets written back into the 1st register)
<FL4SHK> will just implement the register file out of logic
<DaKnig> lkcl_ whats that
<lkcl_> FL4SHK: we have a mix of register files. one of them is only 8 entries but it needs 6R and 5W. it's maasssiiive.
<lkcl_> DaKnig: LD/ST-with-update instructions? when you do a LD/ST you usually compute the address from 2 operands: one register and either an immediate and another register
<lkcl_> LD/ST-with-update will write that calculated address into an outgoing register.
<lkcl_> basically using the LD/ST as an ADD unit, saving one instruction in computationally-intensive loops.
<FL4SHK> 5 watts?
<lkcl_> FL4SHK: 6R5W - 6 read 5 write
<FL4SHK> oh
<FL4SHK> I see
<lkcl_> sorry, convention when discussion regfiles: N (read) M (write) e.g 4R1W porting, sorry i assumed you'd be familiar with the terminology.
<FL4SHK> nah
jeanthom has quit [Ping timeout: 260 seconds]
lkcl__ has joined #nmigen
lkcl_ has quit [Ping timeout: 240 seconds]
Yehowshua has quit [Ping timeout: 245 seconds]
phire has quit [Remote host closed the connection]
phire has joined #nmigen
jeanthom has joined #nmigen
lkcl__ is now known as lkcl
jeanthom has quit [Ping timeout: 260 seconds]
<DaKnig> is there a tutorial for Xilinx stuff that goes from writing code to actually putting the bitstream on the board?
<d1b2> <Benny> Look at the digilent learn site
<DaKnig> digilent has articles about nmigen?
<DaKnig> my search engine doesnt bring up anythin
<DaKnig> g
<d1b2> <Benny> No but a couple on how to upload the bitstrean
<Lofty> nmigen-boards does most of the heavy lifting for you
<DaKnig> then is there a tutorial for that?
chipmuenk has quit [Quit: chipmuenk]
<Lofty> Not really, but it's simple enough that I can give you one here
<Lofty> What board do you have?>
<Lofty> ->
<DaKnig> I have a zynq arty z7
<Lofty> from nmigen_boards.arty_z7 import ArtyZ720Platform # at the top of your code
<Lofty> ArtyZ720Platform().build(YourTopLevelModule(), do_program=True)
<Lofty> At the bottom of your code
<Lofty> That's it(tm)
<DaKnig> (lemme write actual code and try this)
<Lofty> You can demo it with `python3 -m nmigen_boards.arty_z7`, and it'll build and program blinky onto your board
<DaKnig> ok where should I put the board file? or how should I install that?
<Lofty> You can install nmigen-boards the same way you did with nmigen
<DaKnig> are you sure that this above command would work?
<Lofty> Yes
<Lofty> Because it's what I do for the DE10-Nano that I own
<DaKnig> I installed nmigen-boards via pip just now and it says `No module named nmigen_boards.arty_z7`
<Lofty> You'll probably need to use the git URL
<DaKnig> download that linked file and run it?
<Lofty> No, because that relies on other nmigen-boards internal stuff
<DaKnig> what do you mean by "git URL" then
<_whitenotifier-b> [nmigen-soc] rroohhh commented on pull request #23: test: make nmigen 0.3+ compatible -
<_whitenotifier-b> [nmigen-soc] rroohhh synchronize pull request #23: test: make nmigen 0.3+ compatible -
<_whitenotifier-b> [nmigen-soc] codecov[bot] edited a comment on pull request #23: test: make nmigen 0.3+ compatible -
<DaKnig> oh right. I did not install yosys.. guess I'm gonna have to build that from source (not available on my package manager's repos)
<_whitenotifier-b> [nmigen-soc] codecov[bot] edited a comment on pull request #23: test: make nmigen 0.3+ compatible -
jeanthom has joined #nmigen
Yehowshua has joined #nmigen
<Yehowshua> Hmm... nMigen can be installed with hosts built in
<Yehowshua> using wasm
<Yehowshua> pip install --upgrade nmigen[builtin-yosys]
<Yehowshua> **yosys
<TD-Linux> yes it's pure wq magic
<Yehowshua> Wq wizardry
<Yehowshua> Gotta have alliteration
* Lofty wonders if witchcraft is the more appropriate term
<Yehowshua> Oh ya - tru dat
<DaKnig> tldr it didnt work
<DaKnig> it still says I need yosys in PATH
<Lofty> And if you run `yosys` from the terminal?
<DaKnig> not found
<DaKnig> do I really have to build from source, on this aweful machine :(
<Yehowshua> Maybe try from head?
Asu has quit [Read error: Connection reset by peer]
<Yehowshua> pip install --user 'git+[builtin-yosys]'
Yehowshua has quit [Remote host closed the connection]
Asu has joined #nmigen
<DaKnig> "Distutils was imported before Setuptools. This usage is discouraged"
<trabucayre> DaKnig: stupid question $HOME/.local/bin is in your PATH?
<DaKnig> it is
<DaKnig> hm seems like it now errors on something else. good! progress!
<DaKnig> still cant run yosys from commandline but at least it doesnt complain about it
<Lofty> What's it erroring on now?
Yehowshua has joined #nmigen
<Yehowshua> Yeah, nMigen calls yosys internally I believe
<Yehowshua> go ahead and try emitting some RTLIL
<DaKnig> it says that I should put the vivado path in VIVADO variable
<Yehowshua> internally for the wasm version that is
<DaKnig> wait doesnt wasm require a browser
<Lofty> No?
<Lofty> It's a bytecode format
<DaKnig> ok.e
Yehowshua has quit [Remote host closed the connection]
<Lofty> It just needs a compiler that understands wasm
<Lofty> DaKnig: anyway what the Vivado error says is that you need Vivado.
<DaKnig> yeah I get taht. I just have to figure out how to point it to vivado.
<DaKnig> tried to point it to where the main `vivado` executable is, doesnt help
<Lofty> There's a Vivado environment script, right?
<DaKnig> environment script?
<DaKnig> I run it with this bash script: (source /tools/Xilinx/Vivado/2019.2/ && vivado) &
<Lofty> export NMIGEN_ENV_Vivado=/tools/Xilinx/Vivado/2019.2/
<Lofty> And then try again
<Lofty> ``NMIGEN_ENV_Vivado``, if present."
<Lofty> " The environment is populated by running the script specified in the environment variable
<DaKnig> it does something!
<DaKnig> thanks
<DaKnig> looks like it statrs vivado
<Lofty> Yep
<DaKnig> I wish yosys would have support for 100% of the series 7 hardware
<Lofty> synth_xilinx...kinda does
<DaKnig> I hear they are missing some parts (iirc some parts of the DSP slices were not fully REd?), that's why Im using vivado
<DaKnig> maybe my information is a bit outdated
<DaKnig> wait it is using the WebPACK version? I think I have the licence that allows me to use the version that doesnt collect data about me
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
Asu has quit [Client Quit]
Asu has joined #nmigen
<DaKnig> it still errors out when I try the blinking led example
<DaKnig> ` No such file or directory: 'xc3sprog': 'xc3sprog'`
key2 has quit []
key2 has joined #nmigen
<DaKnig> oh no. now I really have to compile a lot of things.
jeanthom has quit [Ping timeout: 256 seconds]
<DaKnig> hwo do I get `libftd2xx`? cant find that online
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
Asu has quit [Read error: Connection reset by peer]
Asuu has joined #nmigen
<DaKnig> I guess I'd have to pass on using nmigen-boards
<DaKnig> too much stuff to recompile
<DaKnig> I get many compilation errors and I am not sure if this is the right place to ask for help about them
<DaKnig> how can I get the verilog files from nmigen code?
<DaKnig> I might still be able to use the Vivado GUI and work like that
<Lofty> DaKnig: `from nmigen.back import verilog` then `foo = YourTopLevelModule(); ports = [, ... ]; with open("out.v", "w") as f: f.write(verilog.convert(foo, ports=ports))`
<Lofty> But I want you to think about this: compiling Yosys is pretty easy. So too is xc3sprog.
Asuu has quit [Quit: Konversation terminated!]
<DaKnig> I tried compiling xc3sprog. it says `package 'libftdi' not found
<DaKnig> the thing is, I installed that package a moment earlier
<DaKnig> as it turns out, my package manager has an old version of this
<DaKnig> then the same for libftd2xx. but there the package manager didnt have this, and this error persisted after I installed this according to the official tutorial (just downloading, extracting the tar and putting stuff in the right place, linking some files etc)
Yehowshua has joined #nmigen
<Yehowshua> General rule of thumb - avoid Vivado haha
jeanthom has joined #nmigen
<Yehowshua> I've never gotten Vivado to work
<Yehowshua> Even with GUI standalone
<DaKnig> the vivado gui works
<DaKnig> it just works
proteus-guy has joined #nmigen
<DaKnig> I didnt have to mess with much stuff
<DaKnig> I'd really rather not use that GUI though, thats one reason I wanted to move to nmigen or something that has CLI tools for this
<Yehowshua> Well, I used Vivado to program my zedboard two years ago with a simple blinky program. Merely programming the board bricked it. It never worked again. That's my only experience with Vivado
<Yehowshua> Maybe the board was bad
<DaKnig> lol that kinda happens sometimes
<DaKnig> what are you doing now then
<Yehowshua> Yes, nMigen has support for Vivado CLI
<Yehowshua> I use Lattice
<DaKnig> with xilinx boards
<DaKnig> ah
<Yehowshua> ECP5
<DaKnig> thats one solution
<Yehowshua> Never had a single issue with openOCD or TInyProg
<DaKnig> <Yes, nMigen has support for Vivado CLI> as long as you can get that to work.. which is what I am struggling with rn
<Yehowshua> Do you know if your Xilinx board supports another programmer besides x3s?
<DaKnig> idk
<Yehowshua> I just was able to install xc32 in Ubuntu
<Yehowshua> x3cs
<Yehowshua> Its in the ubuntu apt as well as arch AUR
<DaKnig> I am using centos 7
<DaKnig> with a few more repos
<Yehowshua> OK. Grab docker and do a wrapper
<DaKnig> installed that because vivado officialy supports taht and nothing newer
<DaKnig> is there a docker for xc3sprog?
<DaKnig> I never used docker...
<Yehowshua> Nah - it won't take two seconds to make one
<Yehowshua> In fact I can make one real quick
<DaKnig> I probably have an old version of docker... lemme see... 1.13.1
<vup> DaKnig: you only need xc3sprog if you want to program your board using nmigen-boards. If you have some other way to program it, you can just program it yourself, the bitstream is located in the `build` folder.
<Yehowshua> Try that
<DaKnig> any way to call vivado to do that for me in CLO?
<Yehowshua> You can create a file name `dockerfile`
<Yehowshua> then `docker build -t xc3sprog .`
<Yehowshua> Then `docker run xc3sprog`
<Yehowshua> You may want to alias `xc3sprog` to `docker run xc3sprog`
<DaKnig> CLI**
<DaKnig> ok how do I start docker?
<Yehowshua> looks like CentOS uses `systemctl`
<Yehowshua> try `sudo systemctl start docker`?
<Yehowshua> One thing I wonder is if you have to inform the docker file about the hosts device tree
<miek> this is all getting very complicated..
<Yehowshua> If x3cs writes directly to devices
<Yehowshua> Yeah...
<miek> re: libftdi, you probably just need to install `libftdi-dev`
<DaKnig> no such thing on the repos
<DaKnig> well nvm it is just called differently
<DaKnig> miek and what are you suggesting for that other thing Im missing?
<miek> oh right, centos, sorry
<DaKnig> ah and installing that package didnt help. it is still missing that when Im trying to compile it
<Yehowshua> So clearly Xilinx was lying about CentOS7 being "officially" supported... Seeing as xc3s is in apt but not YUM
<DaKnig> its not even Centos 7
<DaKnig> its an old version of centos 7 iirc
<DaKnig> 7.6? or something
<DaKnig> when I realized I was installing a slightly newer version , it was a bit too late, not that it matters
<miek> looks like centos installs it as libftdi1, so that's why it's not being found
<DaKnig> since the version it "requires" is nowhere to be found
<DaKnig> miek no such package
<DaKnig> you mean without the l?
<DaKnig> if so, I already have that
<DaKnig> but it doesnt detect it
jeanthom has quit [Ping timeout: 240 seconds]
<Yehowshua> Well, you can try that docker thing I mentioned I guess... Although docker 1.13.1 is VERY old
<miek> no, i mean when you install the package `libftdi` you end up with ``, `/usr/lib64/pkgconfig/libftdi1.pc`, etc. so this fails to find it:
<DaKnig> Yehowshua: this doesnt work, saying I dont have the permissions
<Yehowshua> Sudo is your friend
<Yehowshua> so make that `sudo docker build -t xc3sprog .`
<Yehowshua> Or make a user group for docker
<DaKnig> notice my username
<DaKnig> when running that
<Yehowshua> Oh smh
<DaKnig> what's that RUN thing?
<DaKnig> does it run this inside the docker
<DaKnig> if so, does it really matter if its with sudo or not
<Yehowshua> yes - it runs it in its own special CNAME linux space
<Yehowshua> It shouldn't. I've never had that problem...
jock-tanner has joined #nmigen
<Yehowshua> Well, one thing I can tell you is that if you can install a recent version of Ubuntu or Arch box, all these problems will magically disappear...
<DaKnig> you see- moving the vivado install would require a new licence as mine only worked for 5 machines, and I already spent all 5
<Yehowshua> You have the commercial license?
<DaKnig> or using the webpack version that tracks what Im doing
<DaKnig> I have a commercial license yes
<DaKnig> got a voucher for 10$
<Yehowshua> Does your particular FPGA need that commercial?
<DaKnig> no but I prefer that because that allows me to disable the data it sends over to xilinx
<Yehowshua> Makes sense. Well I don't see any easy solutions.
<DaKnig> not using nmigen-boards looks like the only one
<Yehowshua> Well, Xilinx still uses SOME command to program your FPGA
<Yehowshua> You can change that command in nMigen boards
<Yehowshua> For example, modify that line
<DaKnig> I would ask about that on ##fpga I guess
<Yehowshua> Watch the TCL script output in your GUI and see what command it uses - OR just emit verilog - which would probably be easier
<Yehowshua> yeah
<DaKnig> but wait, this would require me to change the source and reinstall, then maintain a version of nmigen-boards with that line changed
<DaKnig> I guess that's a good solution still
<Yehowshua> You can actually just make a particular file for you FPGA an import that directly
<Yehowshua> You don't need all of nMigen-boards
<miek> you can run the build with do_program=False, or derive from that class and override toolchain_program
<DaKnig> Yehowshua: can you both show an example?
<DaKnig> I just looked at the link from your last message; yeah I know how subprocesses work in python, I think I could change this.
<Yehowshua> So you could just place that file in the same directory as, and then modify the ` def toolchain_program(self, products, name)` to what you want, or like miek said, just change `do_program` in to false
<miek> DaKnig: something like this
Yehowshua has quit [Remote host closed the connection]
<DaKnig> I think I'd rather take the function given in nmigen-boards and use that as the base material
<DaKnig> I cant find the __init__ of the platform, if that doesnt exist then where do arguments passed to the constructor end up?
<DaKnig> ok nevermind I was doing that wrong
<DaKnig> miek: so if I pass it False there , it just spits out the bitstream?
<miek> DaKnig: yup, you'll have all the build output in `./build/`
<DaKnig> I see a ton of files there
<DaKnig> I did not know its possible to call verilog vars `\$10`
<DaKnig> (then again my verilog is not that great)
<DaKnig> so which file si the bitstream? top.bit?
<miek> i don't use vivado/xilinx so i don't know which file you need
<DaKnig> thank you very much for all the help today.
<miek> no problem :)
<DaKnig> ok now I see that my thing is unused, and indeed I forgot to pair the output signal with an LED (test program)
<DaKnig> how do I do this? the LEDs on the board are described as LEDResources
jeanthom has joined #nmigen