ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at https://github.com/nmigen · logs at https://freenode.irclog.whitequark.org/nmigen · IRC meetings each 1st & 3rd Monday at 1800 UTC · next meeting July 20th
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #nmigen
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #nmigen
jaseg has quit [Ping timeout: 260 seconds]
jaseg has joined #nmigen
<Falteckz> Nice.
<Falteckz> Completely burnt out and it's only Tuesday, but today is the day I write some darn nMigen! <3
<whitequark> do be careful with that burnout
<Falteckz> I appreciate that, thank you!
<Falteckz> I've got simulation and gtkwave working in Windows in a snap, too easy. I've got boards working, just need the toolchain. What's the quickest way to get the TinyFPGA BX toolchain setup in Windows? With fusesoc I was doing everything through a docker container but I don't see a nice way to plug that into nmigen
<whitequark> try `pip install yowasp-yosys yowasp-nextpnr-ice40-8k`
<Falteckz> No worries if it's just one of those awkward things that Windows devs have to deal with, I'll tackle it
<Falteckz> Oh!!
<Falteckz> What's the env variables now ?
<Falteckz> I assume I've a PATH= YOSYS= NEXTPNR= python ./blinky.py or something?
<whitequark> YOSYS=yowasp-yosys NEXTPNR_ICE40=yowasp-nextpnr-ice40 ICEPACK=yowasp-icepack
<whitequark> and `python -m nmigen_boards.tinyfpga_bx` should smoke-test that toolchain setup
<Falteckz> Is the smoke test mostly quiet/silent?
<Falteckz> (or has it hung, heh)
<whitequark> it can take a while the first time you run it
<Falteckz> Crashes
<whitequark> I suspect you're hitting https://github.com/YoWASP/yosys/issues/1
<Falteckz> Alright, thanks! Looks unfixed and upstream for now
<whitequark> the wasmtime folks are working on it, uh, actually fix is available https://github.com/bytecodealliance/wasmtime/pull/1983
<Falteckz> Funny enough, it actually runs
<whitequark> it's probably going to be fixed in the next few days at worst, in the meantime you could try https://github.com/open-tool-forge/fpga-toolchain
<whitequark> Falteckz: the bug is triggered by specific input code
PyroPeter_ has joined #nmigen
<whitequark> well
<Falteckz> Ah right, I thought it was crashing with just -V
<whitequark> hang on
<whitequark> that's the case
<whitequark> what if you do `echo %errorlevel%` after running it?
<whitequark> in some cases it crashes completely silently and you'd have no idea it did crash if you weren't checking
<Falteckz> What's the errno var in bash?
<whitequark> $?
<Falteckz> $? or something
<Falteckz> Ye
<Falteckz> Ye, non-zero
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter_ is now known as PyroPeter
electronic_eel_ has quit [Ping timeout: 258 seconds]
zignig has joined #nmigen
electronic_eel has joined #nmigen
<_whitenotifier-b> [YoWASP/yosys] whitequark pushed 1 commit to develop [+1/-0/±0] https://git.io/JJLQv
<_whitenotifier-b> [YoWASP/yosys] whitequark a457fb4 - [skip ci] Add an auto-updater.
<Falteckz> Yeah looks like it's being actively fixed, last activity an hour ago
<Falteckz> Nice to see.
chipmuenk has joined #nmigen
<zignig> Falteckz: what are you looking to do on your tinybx ?
<zignig> I've been noodling with nmigen on mine for a while now.
<Falteckz> I've just plugged a SiLabs USB/UART breakout in and am going to get UART working first - but after that I want to start working on an ALU, eventually getting my own CPU going. Either that or render some graphics to an OLED display at a high framerate, something that I've been unable to achieve previously with microcontrollers.
<Falteckz> I've run a RISC-V core on it already, outside of nMigen, and I've played around with PWM, memory mapped IO and a few other concepts
<Falteckz> I really want to put something together to be more useful than it's logical parts. Counters and basic peripherals are very cool to play with and learn from, but I would be unlikely to choose an FPGA in production just for those simple needs when something off the shelf for 30 cents will do it.
<Falteckz> Oh! Also, DDS DAC! I want to play some music and see how good that sounds when compared to an 8bit resistor ladder
rattboi has quit [Ping timeout: 260 seconds]
rattboi has joined #nmigen
<Falteckz> What have you already done on yours, zignig ?
<zignig> sounds cool , I have been working on a similar thing.
<zignig> I have got @whitequarks boneless processor going as a SOC, with timer , CRC , serial ports.
<Falteckz> What is meant by boneless?
<Falteckz> I've designed a couple processors in Logisim and Digital https://github.com/hneemann/Digital and would love to move some of those to gateware
<zignig> nice 16 bit processor , that is really flat with no crazyness in the instruction set.
<Falteckz> That project is worth it's wait in gold just for the assembler in itself
<Falteckz> I've written too many assemblers and all of them were an awful mess
<whitequark> hah!
<Falteckz> s/wait/weight/
<Falteckz> Though it's Python - so maybe I don't correct that :P
<whitequark> haaah
<whitequark> it's not too slow
<whitequark> one of the tests goes through all 65536 encodings
<Falteckz> My last assembler was asyncio, so I've no leg to stand on with this accusation
<zignig> Falteckz: and it in python , so you wrap it in classes and python structures. and build up constructs.
<zignig> I have been bashing at some libs and a bootloader for way to long.
<Falteckz> Solved jump labels that hadn't been discovered yet with cheeky yields. Saved doing multiple passes but I do not think the extra complexity was worth it
<zignig> RL keeps getting in the way.
<Falteckz> RL?
<zignig> real life (TM)
<Falteckz> Gotcha.
<Falteckz> I thought you meant Rocket League which would have been fitting because I'm coding on nMigen while listening to the soundtrack
<zignig> hehe
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 3 commits to master [+0/-0/±4] https://git.io/JJLQa
<_whitenotifier-b> [nmigen/nmigen] whitequark 23758e3 - Remove everything deprecated in nmigen 0.2.
<_whitenotifier-b> [nmigen/nmigen] whitequark 8f6eab0 - back.pysim: simplify. NFC.
<_whitenotifier-b> [nmigen/nmigen] whitequark c9ac85a - back.pysim: simplify. NFC.
<Falteckz> Smoke test passed
<Falteckz> A very excited LED is blinky
<zignig> blinky ?
<Falteckz> Aye
<whitequark> Falteckz: sweet! is that with open-tool-forge?
<Falteckz> Yep!
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJLQo
<_whitenotifier-b> [nmigen/nmigen] whitequark 4c0a7ee - Deploying to gh-pages from @ c9ac85a045b142e28ec9ae06da63b62c446152ab 🚀
<zignig> it's a good start.
<Falteckz> It is a good start!
<Falteckz> I wish I had buttons and LEDs for the TinyFPGA BX
<Falteckz> I need something tactile to keep me motivated haha
<Falteckz> UART next tho, how hard can that be 😅
<whitequark> there's one in nmigen-stdio
<zignig> https://github.com/nmigen/nmigen-stdio/ has one already built.
<Falteckz> *blink*
<Falteckz> Well okay I guess I'll use this kindly supplied stdlib and do nothing hahaha
<zignig> stand on the shoulders of giants ?
<Falteckz> I am absolutely all about that to be honest
<Falteckz> Devoid of humour though, I stand on the shoulders of giants in my hobbies and reinvent the wheel in my professional life and I would really prefer roles were reversed
<zignig> indeed, I know exactly what you mean.
<Falteckz> If reinventing the wheel wasn't fun sometimes we wouldn't have Blinky, Hell World or Todo apps :D
<Falteckz> s/Hell/Hello/
<Falteckz> 2020 Typo
<zignig> I like Hell world better.
<zignig> i'm in au , so all we need is war and pestilance... it's only july...
<tpw_rules> didnt you have those already
<Falteckz> I'm going to grok "au" as Australian
<Falteckz> tpw_rules: How do you think they got there :D
<zignig> tpw_rules: just fire and drought and pandemic.
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJLQQ
<_whitenotifier-b> [nmigen/nmigen-boards] whitequark 55bff3e - setup: update dependencies.
<_whitenotifier-b> [nmigen/nmigen-stdio] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJLQ7
<_whitenotifier-b> [nmigen/nmigen-stdio] whitequark bbf52a3 - setup: update dependencies.
<_whitenotifier-b> [nmigen/nmigen-soc] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/JJLQ5
<tpw_rules> pestilence is definitely the same as pandemic
<_whitenotifier-b> [nmigen/nmigen-soc] whitequark 5509bd2 - setup: update dependencies.
<zignig> That said we did have war against the Emu in the 1900s and lost.
<Falteckz> How does one add more Resources for their board?
<whitequark> platform.add_resources(...)
<Falteckz> I see they are both optional and preferred way to allocate pins
<Falteckz> Right, I do that in my top module?
<Falteckz> __init__ ?
<whitequark> if you're doing it in an elaboratable, probably do it in the elaborate function of the toplevel one
<Falteckz> Gotcha, okay
<whitequark> but really anywhere that's convenient works
<whitequark> remember that platforms are only usable once though
<Falteckz> You've lost me, usable once how?
<whitequark> you have to construct one platform object per design you're building
<whitequark> i.e. you can't do `platform.build(...), platform.build(...)`
<Falteckz> offtopic: GitHub has References and Definitions linking for Python code now, oh golly that is neat!
<Falteckz> whitequark: Got it, `platform` is a platform factory and you must make only one
<whitequark> uhm, not exactly
<whitequark> so let's say you use tinyfpga bx
<whitequark> you create a platform: `platform = TinyFPGABXPlatform()`
<whitequark> you can now use this platform to build something: `platform.build(design)`
<whitequark> what you *can* do: reuse the `design` after that
<whitequark> what you *can't* do: reuse the `platform` after that
<whitequark> you need to throw the platform out and start over, using the `TinyFPGABXPlatform()` constructor again
<whitequark> in practical terms this means that passing a platform into an __init__ method of a design component would not work well
<whitequark> one of the purposes of a platform object is to record all the state that's created and mutated during elaboration
<whitequark> which is why they're single-use
<Falteckz> I see
<Falteckz> The instance is short lived so there would be no need to store it on an Elaboratable instance
<d1b2> <edbordin> zignig: thanks for reminding me the emu war was a thing XD
<whitequark> yeah, and it's provided to you anyway
<zignig> edbordin: 40 kg of murder chicken with the brain the size a pea.
<d1b2> <edbordin> yep, also an aussie, am familiar haha
<zignig> :)
<d1b2> <edbordin> the cassowary is the really scary one though
<zignig> indeed they are sneaky and nasty, emu are just stoopid
<Falteckz> How would I make a buffer in nMigen?
<whitequark> like a FIFO?
<Falteckz> Sorry. Um.. ROM
<Falteckz> fixed memory
<Falteckz> "Hello World"
<Falteckz> for uart tx
<whitequark> oh! Memory
<whitequark> examples/basic/mem.py
<Falteckz> Appreciated!
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 3 commits to master [+0/-0/±4] https://git.io/JJL7q
<_whitenotifier-b> [nmigen/nmigen] whitequark e012e62 - back.pysim: synchronize terms with cxxrtl. NFC.
<_whitenotifier-b> [nmigen/nmigen] whitequark 2efeb05 - back.pysim: synchronize waveform writing with cxxrtl.
<_whitenotifier-b> [nmigen/nmigen] whitequark db4529a - back.pysim: simplify. NFC.
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJL73
<_whitenotifier-b> [nmigen/nmigen] whitequark b4f7e39 - Deploying to gh-pages from @ db4529a1780141223899b4e79989e3a20ff640e4 🚀
<Falteckz> Is init synthesised?
<Falteckz> Memory(init=[])
<tpw_rules> yes
<Falteckz> It takes ints that fit into the width?
<tpw_rules> most FPGAs can store an initial RAM state in the bitstream
<tpw_rules> yes
<Falteckz> Rad, thanks! Memory(width=8, depth=11, init=map(ord, 'Hello World'))
<whitequark> init=b'Hello World'
<whitequark> also works
<whitequark> or IIRC should
<Falteckz> oh
<Falteckz> oh my
<tpw_rules> yeah that should
<Falteckz> that wasn't clear from looking at init.setter, but I'm glad!
<tpw_rules> iterating a bytes yields ASCII ints
<Falteckz> Of course
<Falteckz> `list(b'')`
<tpw_rules> (or well the full range if \xNN)
<Falteckz> Is Signal explicitly equivilent to a `wire` and not a `reg` ?
<whitequark> no
<Falteckz> That doesn't seem right, surely it's both
<Falteckz> Right. Yes
<whitequark> Signal is like SV logic
<Falteckz> I don't know SystemVerilog but I'll just interpret it as "yes, use it for state"
<whitequark> yep
<Falteckz> Sorry, I've less than 10 hours of FPGA experience. My knowledge on the matter is practically void
<whitequark> that's ok
<Falteckz> Do ternary operators work in `.eq(...)` ?
<whitequark> you can use Mux
<Falteckz> Alright!
<Falteckz> Stab in the dark with a whitequark flash light to guide:
<Falteckz> m.d.sync += rom_addr.eq(Mux(rom_addr == (self.rom_len - 1), 0, rom_addr + 1))
<Falteckz> Look fine?
<whitequark> ah, you could do that
<whitequark> but I'd probably use m.If
<Falteckz> Alright, yeah that might look cleaner
<Falteckz> Correct usage?
<whitequark> I'd invert the condition and use ==
<whitequark> then you avoid a carry chain
<Falteckz> Hahaha
<Falteckz> Yes. Of course
<Falteckz> Adder pain
<Falteckz> and here I was thinking "What if rom addr magically escapes the bounds and leaps over, I wanna grab it."
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/JJL7a
<_whitenotifier-b> [nmigen/nmigen] whitequark c9030eb - back.pysim: simplify. NFC.
<_whitenotifier-b> [nmigen/nmigen] whitequark cee43f0 - back.pysim: simplify.
<whitequark> bigger problems then
<Falteckz> Yeah - it's probably in space
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJL7o
<_whitenotifier-b> [nmigen/nmigen] whitequark 781246c - Deploying to gh-pages from @ cee43f0de14020e91c047808f0ea092d92841c76 🚀
<awygle> whitequark: what is the error message for "This is neither a Shape nor a correctly-typed tuple"? i started by saying "not a shape or a 2-tuple" but that's inaccurate since you can't compare with ("egg", "mcmuffin") obviously
<awygle> "Shapes may be compared with other Shapes and (int, bool) tuples, not {!r}" maybe?
<awygle> also i guess i should add a test for rejected comparisons huh...
<Falteckz> I presume that Memory.data doesn't need to be updated on clock edge, and can be combinatorial?
<Falteckz> Provided that what it is attached to, is synchronous
<zignig> Falteckz: on ice40 I think it needs a cycle to load.
<Falteckz> My thought is that this should be fine:
<Falteckz> Because rom_addr is incremented on clock
<Falteckz> Provided it meets timing, tx.data will be updated some time after rom_addr changes
<_whitenotifier-b> [nmigen] awygle synchronize pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJIDW
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<Falteckz> Well... it's something! Hahaha https://usercontent.irccloud-cdn.com/file/KTmpILn7/image.png
<Falteckz> On the upside, it's consistently garbage
<d1b2> <edbordin> at least the garbage is probably made of the characters you wanted haha
<Falteckz> Haha yes! That too!
<Falteckz> I wonder if that combinatorial thing is actually a problem, maybe the bits are not updating fast enough - I wouldn't think so though. It should have raised a timing error
<Falteckz> The address bits I mean.
<_whitenotifier-b> [nmigen] whitequark reviewed pull request #422 commit - https://git.io/JJL7A
<Falteckz> That makes no difference.
<Falteckz> Time to work out how to use the Simulator I guess. I hope this reproduces
<_whitenotifier-b> [nmigen] awygle synchronize pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJIDW
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] codecov[bot] edited a comment on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJID0
<_whitenotifier-b> [nmigen] whitequark closed pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJIDW
<_whitenotifier-b> [nmigen] whitequark closed issue #421: Adding Shapes gives counterintuitive results - https://git.io/JJkGI
<_whitenotifier-b> [nmigen/nmigen] whitequark pushed 1 commit to master [+0/-0/±2] https://git.io/JJL52
<_whitenotifier-b> [nmigen/nmigen] awygle 659b0e8 - hdl.ast: don't inherit Shape from NamedTuple.
<_whitenotifier-b> [nmigen] whitequark commented on pull request #422: Don't inherit Shape from NamedTuple - https://git.io/JJL5a
<awygle> yey
<_whitenotifier-b> [nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/JJL5V
<_whitenotifier-b> [nmigen/nmigen] whitequark ac00576 - Deploying to gh-pages from @ 659b0e8189fdf99be678d5713259ba59726d991b 🚀
<Falteckz> Received unsupported command in `pysim.py` ?
<Falteckz> Getting weird vcd output https://www.irccloud.com/pastebin/shlvcQZl/
<Falteckz> Ah! It's `clock(16E-6)` not `clock(16E-3)`
<Falteckz> Ah! It's `clock(16E-6)` not `clock(16E+6)`
<zignig> and the crowd goes wild AAAAAAAAAAAAAAAAAAAAAAAAHHHHH!
<zignig> nice work Falteckz, on the nmigen train now ...
<Falteckz> I am indeed!
<Falteckz> Face deep in gtkwave trying to work out why it breaks at higher transmit rates haha
<zignig> what speed are you failing at ? 115200 works fine for me.
<zignig> it also may be your serial converter, I assume that you are just using TX/RX on a usb<->serial tranceiver.
<Falteckz> 115200 works fine if I'm shifting the characters in 10/second
<Falteckz> But when I shift the characters in as fast as possible it comes out as garbage
<Falteckz> I'm trusting that `tx.rdy` is reliable, maybe it isn't
<Falteckz> It's weird that it's in a START state when the shift register is empty
<Falteckz> I would expect the state machine to wait for data to be present and then do START, BITS, STOP
<zignig> could be an interlock at your loopback.
<zignig> perhaps 2 fifos , to buffer it up before you get to the loopback.
<zignig> let me have a look for an example.
<Falteckz> There is no loopback
<Falteckz> I've "Hello World" in ROM which I print
<zignig> so out only.
<Falteckz> It works fine at a slow clock rate (baud rate still 115200)
<Falteckz> Yes, out only
<zignig> and it BORKS at higher than that.
<Falteckz> It BORKS at theoretical maximum/2
<Falteckz> I'm looking at the AsyncSerialTX and I don't actually see logic for start and stop, the signals are set (and I don't know if they are sent correctly) but I don't see them used anywhere either
<zignig> could be the read delay on the Memory.
<Falteckz> The data that goes into the UART shift register is valid
<Falteckz> In my screenshot, the "e" in data[7:0] goes to shreg__data[7:0] as 0x65
<Falteckz> Have you tested nmigen-stdio:serial to it's maximum effort?
<Falteckz> The implementation is so easy to understand in nMigen, I really appreciate how much cleaner it is
<zignig> I have but only to 115200.
<zignig> and it has significantly less footguns than verilog.
<Falteckz> Did you saturate the bus at 115200?
<Falteckz> I assume that's 11,520 characters / second saturated
<zignig> didn't try , it was just a console for my boneless.
hitomi2504 has joined #nmigen
<Falteckz> How does one perform POR with nMigen?
<zignig> POR ?
<d1b2> <Darius> power on reset I assume
<d1b2> <Darius> if you are targeting an FPGA you might not need one..
<d1b2> <286Tech> Falteckz: Congratulations on getting it working \o/
<d1b2> <Darius> @286Tech I think you meant to send that to Falteckz 🙂
<d1b2> <286Tech> Oh oops, yeah you're right 😄
<d1b2> <Darius> that is a very.. curious note
zignig has quit [Ping timeout: 258 seconds]
zignig has joined #nmigen
samlittlewood has quit [Quit: samlittlewood]
Asu has joined #nmigen
jeanthom has joined #nmigen
jeanthom has quit [Quit: Leaving]
zignig has quit [Remote host closed the connection]
zignig has joined #nmigen
chipmuenk has quit [Read error: Connection reset by peer]
chipmuenk has joined #nmigen
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtJd
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtJN
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtUu
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtkN
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtIZ
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 is now known as chipmuenk
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk1 is now known as chipmuenk
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtLe
<_whitenotifier-b> [nmigen-boards] jeanthom reviewed pull request #71 commit - https://git.io/JJtLr
<_whitenotifier-b> [nmigen-boards] jeanthom reviewed pull request #71 commit - https://git.io/JJtLo
jeanthom has joined #nmigen
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJttS
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJttb
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtqk
<_whitenotifier-b> [nmigen-soc] Fatsie reviewed pull request #21 commit - https://git.io/JJtqC
<_whitenotifier-b> [nmigen-soc] Fatsie commented on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJtqS
<_whitenotifier-b> [nmigen-soc] Fatsie edited a comment on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJtqS
<_whitenotifier-b> [nmigen-soc] Fatsie commented on issue #18: Wishbone access from initiator bus with data_width smaller than the one of the subordinate bus. - https://git.io/JJtmL
marc842 has joined #nmigen
<_whitenotifier-b> [nmigen-boards] jfng synchronize pull request #71: Add ECPIX-5 support. - https://git.io/JJJhU
<_whitenotifier-b> [nmigen-boards] jfng commented on pull request #71: Add ECPIX-5 support. - https://git.io/JJtmu
<_whitenotifier-b> [nmigen-soc] Fatsie synchronize pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJhA
<_whitenotifier-b> [nmigen-soc] codecov[bot] edited a comment on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJjf
<_whitenotifier-b> [nmigen-soc] codecov[bot] edited a comment on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJjf
<_whitenotifier-b> [nmigen-soc] codecov[bot] edited a comment on pull request #21: [WIP]wishbone.Connector class - https://git.io/JJJjf
Asu has quit [Ping timeout: 256 seconds]
Asuu has joined #nmigen
marc842 has quit [Remote host closed the connection]
marc842 has joined #nmigen
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
marc842 has quit [Remote host closed the connection]
hitomi2504 has quit [Quit: Nettalk6 - www.ntalk.de]
jjeanthom has joined #nmigen
jeanthom has quit [Remote host closed the connection]
<_whitenotifier-b> [nmigen-boards] jeanthom opened issue #74: DDR pins and *_n signals - https://git.io/JJtgV
<d1b2> <ld;cd> key2: if you're looking for a zynq board I would recommend the pynq-z1 or z2
<d1b2> <ld;cd> A lot more exposed io, probably better documentation, and more periphetals
<key2> i wasnt looking
<key2> just saw this one
<key2> so I shared
<d1b2> <ld;cd> And can be got on sale for around 90 ish
<d1b2> <ld;cd> Oh, well thanks for the tip, the form factor is a little tempting
<FL4SHK> so for my 2D GPU, I'm thinking of having per-tile priority
<FL4SHK> though it might make more sense to leave that out
<FL4SHK> I'm unsure how to make providing access to the GPU generic
<FL4SHK> I want like, a fixed tilemap element format
<FL4SHK> this way I can guarantee that it fits nicely within byte-aligned thing
jjeanthom has quit [Ping timeout: 264 seconds]
<FL4SHK> I guess I can programmatically set up the byte stuff?
SpaceCoaster_ has joined #nmigen
SpaceCoaster has quit [Ping timeout: 260 seconds]
jjeanthom has joined #nmigen
chipmuenk has quit [Ping timeout: 244 seconds]
chipmuenk has joined #nmigen
jjeanthom has quit [Ping timeout: 240 seconds]
jjeanthom has joined #nmigen
lkcl__ has quit [Quit: Leaving]
lkcl__ has joined #nmigen
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 256 seconds]
chipmuenk1 is now known as chipmuenk
<_whitenotifier-b> [nmigen-soc] jfng reviewed pull request #21 commit - https://git.io/JJtyP
Asuu has quit [Remote host closed the connection]
<FL4SHK> now thinking of just building a small CPU to use for drawing into a framebuffer
<FL4SHK> nope, too much work for right now
chipmuenk has quit [Quit: chipmuenk]
<lkcl__> FL4SHK: look up richard herveille's vgalcd. it does RGBTTL and VGA screen buffer driving.
lkcl__ is now known as lkcl
<FL4SHK> lkcl: already built VGA signal driving
<FL4SHK> just need something more general to do it
<lkcl> FL4SHK: oh - drawing *into* a framebuffer, rather than driving *from* a framebuffer. got it :)
<FL4SHK> Is there any way to have a signal of the same length of a record and copy one to the other?
<FL4SHK> two questions, really
<FL4SHK> I need to do this
<FL4SHK> Mostly because I need a `Memory` of `Record`s
<ktemkin> You shouldn't need to do the copy
<ktemkin> a Record behaves like a packed struct
<FL4SHK> ah, that's the behavior I was hoping for
<ktemkin> and when it's treated like a Value, you get all its bits
<FL4SHK> I didn't realize the behavior extended that far
<FL4SHK> that's basically like SV packed structs
<_whitenotifier-b> [nmigen-soc] whitequark reviewed pull request #21 commit - https://git.io/JJtQV
<FL4SHK> Why is there a separation between shapes and types?
<Lofty> Because Python, more or less
<FL4SHK> Here's what I'm thinking: records could have been implemented as shapes
<FL4SHK> as such, you'd *always* use a Signal or a Const
<FL4SHK> It seems a little awkward to me to have Records always be basically signals
<FL4SHK> Oh, and I have a question
<FL4SHK> I have a value stored in a signal that I want to use an index for a Python list
mithro has quit [Ping timeout: 246 seconds]
<FL4SHK> Can I convert it back to a Python integer via any method?
guan has quit [Ping timeout: 246 seconds]
<whitequark> FL4SHK: records are their own thing for a few reasons, largely historical ones (but that doesn't mean it'll necessarily change)
<FL4SHK> Cool
<whitequark> nMigen is built around all Signals being integers. it didn't have to be that way, but it is that way
<FL4SHK> ahhh
<FL4SHK> Maybe I'm thinking too much in terms of VHDL
<FL4SHK> on to my second question
<whitequark> Signals do not store values. please read https://nmigen.info/nmigen/latest/lang.html#assigning-to-signals
<FL4SHK> oh, yeah, that explains it
<whitequark> \o/
<FL4SHK> it's just an AST
<FL4SHK> or something
<FL4SHK> I do need to somehow convert the HDL signal's value into "which memory am I accessing"
gravejac has quit [Ping timeout: 272 seconds]
futarisIRCcloud has quit [Ping timeout: 260 seconds]
<whitequark> aha
levi has quit [Ping timeout: 256 seconds]
key2 has quit [Ping timeout: 256 seconds]
daveshah has quit [Ping timeout: 244 seconds]
rohitksingh has quit [Ping timeout: 260 seconds]
<whitequark> you can use an Array for that, or a bunch of m.If/Elif constructs
<FL4SHK> that or perhaps I could serialize accesses to the memory
<whitequark> if you just need to choose one of the memory read ports, use an Array
<FL4SHK> an Array of memories? I was thinking that wouldn't work
<FL4SHK> Here I need to use block RAM
pdp7 has quit [Ping timeout: 265 seconds]
<whitequark> nope, an array of read port data outputs
_florent_ has quit [Ping timeout: 260 seconds]
<FL4SHK> can I attach that to a Memory?
sorear has quit [Ping timeout: 244 seconds]
ianloic has quit [Ping timeout: 272 seconds]
ktemkin has quit [Ping timeout: 246 seconds]
Cynthia has quit [Ping timeout: 240 seconds]
esden has quit [Ping timeout: 260 seconds]
<FL4SHK> lots of ping timeouts...
bubble_buster has quit [Ping timeout: 246 seconds]
Falteckz has quit [Ping timeout: 272 seconds]
<FL4SHK> oh, here's the thing
<FL4SHK> I need to be able to read from multiple addresses at once
<FL4SHK> the m.If business might work if I did a for loop
<FL4SHK> I think I want a runtime for loop
<whitequark> you'd have to describe what you want in more detail for me to suggest anything useful
<FL4SHK> the number of memories is provided as a generic
<FL4SHK> something like: for i in range(len(memory_arr)) { if memory_index == i { m.d.sync += do something with memory_arr[i] } }
<FL4SHK> specifically, I need that `for` loop and that `if` statement to happen in the FPGA itself, or in simulation
<FL4SHK> not at build time
<FL4SHK> in VHDL I'd just use a for loop
<FL4SHK> a Python for loop won't work for this
<whitequark> what is `memory_arr` in this case?
<FL4SHK> a Python list of `Memory`s
<FL4SHK> wait
<whitequark> if it's a Python list of memories, it's constant during synthesis and everything after, right?
<FL4SHK> a Python for loop seems to work
<whitequark> yep
<FL4SHK> I think I got this wrong
<FL4SHK> excellent
<FL4SHK> I thought I had stumbled upon my weakness in languages habit
<FL4SHK> nMigen has very few of those
<FL4SHK> it covers almost anything I'd want to do
<_whitenotifier-b> [nmigen-boards] whitequark commented on issue #74: DDR pins and *_n signals - https://git.io/JJt7b