ChanServ changed the topic of #nmigen to: nMigen hardware description language · code at · logs at · IRC meetings each Monday at 1800 UTC · next meeting August 17th
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 264 seconds]
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
cr1901_modern has joined #nmigen
emeb_mac has quit [Ping timeout: 256 seconds]
emeb_mac has joined #nmigen
<tannewt> ktemkin: are these comments used in docs somewhere? they didn't work directly with sphinx when I tried to use it with them
<ktemkin> I believe they work with the Sphinx configuration provided with LUNA
jaseg has quit [Ping timeout: 256 seconds]
<ktemkin> (I believe you need the napoleon sphinx extension enabled)
jaseg has joined #nmigen
FL4SHK has quit [Ping timeout: 256 seconds]
FL4SHK has joined #nmigen
<tannewt> k, thanks ktemkin.when I was poking lambdasoc there were some categories that didn't map
electronic_eel has quit [Ping timeout: 265 seconds]
electronic_eel has joined #nmigen
PyroPeter_ has joined #nmigen
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #nmigen
<emeb_mac> tannewt: I'm trying out your systemonchip stuff. It tries to build but I get this error: TypeError: 'DecoderWindow' object is not subscriptable
<tannewt> emeb_mac: only the timer will work at the moment
<emeb_mac> ah, so other stuff is enabled in which needs to be turned off?
<tannewt> Ya. I haven’t fixed that up fully. You can run timer directly with ‘python -m systemonachip.peripheral.timer’
<tannewt> I haven’t tested it with a cpu yet
<emeb_mac> ok, makes sense. thx
<tannewt> Though I’m probably not that far off
<tannewt> I was going to try and get an i2c to csr bridge going so I could test peripherals over i2c
<emeb_mac> cool - sounds like it could be useful.
<tannewt> Ya I hope so. Maybe I’ll look at basic though since you are interested
<tannewt> I think I know how to change the decoder stuff
<emeb_mac> no rush - I've got an nmigen-based functional block that I'd like to put under CPU control at some point but I've got a lot of learning / thrashing to do to prepare.
<tannewt> Kk. That’s good for me to know. Would the i2c bridge help?
<emeb_mac> I do have some use for I2C in the future, but not immediately.
<tannewt> I’m thinking as a way to test your block. What board are you testing on?
<d1b2> <emeb> I'm on an orangecrab
<tannewt> kk, I have one of those. I'm poking at the basic example now
<d1b2> <emeb> FWIW lambdasoc will build for orangecrab if you add a uart resource
<d1b2> <emeb> (the example)
<tannewt> 👍
<tannewt> emeb_mac: well, I have the basic file not crashing. no idea if it works
<emeb_mac> tannewt: oh fun. I'll take a look next time you push
* tannewt pushes
lkcl__ has joined #nmigen
<emeb_mac> got it. for some reason it doesn't see the new bus_bridge. Do I need to rerun the setup?
<tannewt> maybe I forgot to add the file
* tannewt looks
<tannewt> what is the error?
lkcl_ has quit [Ping timeout: 256 seconds]
<emeb_mac> but I can see the file there
<tannewt> did you pip install systemonachip?
<tannewt> I'm surprised that decoder works but bridge doesn't
<tannewt> I run with `env PYTHONPATH=. python3 examples/ nmigen_boards.orangecrab_r0_2.OrangeCrabR0_2Platform`
<tannewt> (in fish)
<emeb_mac> interesting - that gets further. no longer getting the bus bridge error.
<emeb_mac> but now it bombs out with a yosys error
<tannewt> I get a warning about no clocks but it makes it to dfu
<tannewt> here is the version I have `Yosys 0.9+2406 (open-tool-forge build) (git sha1 bd959d5d, gcc 9.3.0-10ubuntu2 -Os)`
<emeb_mac> also running open-tool-forge, same version but different sha1
<emeb_mac> (about 2 wks old)
<tannewt> mine is about that too
<tannewt> the +2406 is the number of commits after 0.9
<emeb_mac> pretty close then
<d1b2> <edbordin> eh the +2406 hasn't changed for a while now... but I left it as-is because nmigen checks it
<tannewt> ah, hrm. is the sha the best version id then?
<emeb_mac> mine is git sha1 57af8499
<d1b2> <edbordin> yeah the sha is jsut a yosys commit id
<tannewt> kk, will look at the log
<d1b2> <edbordin> (although in very early open-tool-forge builds the sha was wrong, but 2 wks old should be fine)
<tannewt> mine is from july 24th
<emeb_mac> july 21 here
<emeb_mac> I'll try updating to current
<emeb_mac> still gets same error
<tannewt> hrm
<tannewt> let me update too
<tannewt> now I get four extra wire warnings but not an error
<tannewt> I might have mods to the other libraries. let me check
<emeb_mac> I tweaked my to add a UART. might be that.
<tannewt> I don't see anything
<tannewt> ya, I don't have any mods to boards
<emeb_mac> nope - commenting out the uart resource didn't change it.
<tannewt> though I started sketching out xo2
<emeb_mac> perhaps I'll rerun the pip install requirements
<emeb_mac> no change
<tannewt> -e
<tannewt> -e
<tannewt> -e
<tannewt> -e
<tannewt> -e
<tannewt> these are the ones I have installed from git directly
* emeb_mac checks
<emeb_mac> my git skill is not strong - what's the cmd to get those versions?
<tannewt> I did `pip freeze`
<tannewt> those are the ones that I did `pip install -e` in the repo instead of installing from pypi
<emeb_mac> OK - looks like something in the lamdasoc requirements.txt has downgraded my nmigen to v0.2
<emeb_mac> just love the way python dependencies can do that to you.
<emeb_mac> enough - zzz time. gn
emeb_mac has quit [Quit: Leaving.]
<tannewt> me too. gn
Asu has joined #nmigen
Asu has left #nmigen [#nmigen]
jeanthom has joined #nmigen
jeanthom has quit [Remote host closed the connection]
jeanthom has joined #nmigen
proteus-guy has joined #nmigen
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
jeanthom has joined #nmigen
hitomi2507 has joined #nmigen
emeb has joined #nmigen
proteus-guy has quit [Ping timeout: 256 seconds]
DaKnig has quit [Read error: Connection reset by peer]
<lkcl__> emeb: morning? :)
lkcl__ is now known as lkcl
<lkcl> did you sort out the DomainRenamer() thing and did you see the review comments i gave about missing setup of ResetSignal()?
<emeb> lkcl: gm. Yes - got my multiple clock domains working just peachy.
<emeb> lkcl: thanks for the help with that!
<lkcl> ah fantastic. i spotted that the newsyncdomain_rst would have been a totally separate signal
<lkcl> ah - and it still is :)
<lkcl> at line 29 you can do "sync_adc.rst.eq(ResetSignal())
<lkcl> and that will merge the reset from "standard sync domain" into the sync_adc domain
<lkcl> or you can connect it up externally, but this is "top", which means that when you convert to verilog / ilang you should find that a seemingly-random (floating, unconnected) signal called "sync_adc_rst" appears on the list of ports
<emeb> lkcl: yes - I tried that
<emeb> But for some reason it seems like the OrangeCrab platform definition has the top-level resetless.
<emeb> so it complained that ResetSignal() wasn't a valid signal to connect
<lkcl> oink?
<lkcl> good word, "oink". got it from Tom Holt's books :)
hitomi2507 has quit [Quit: Nettalk6 -]
<emeb> heh
<whitequark> the sync_adc_rst signal isn't random
<whitequark> if you run convert() without ports= specified, all signals not explicitly driven become toplevel inputs, including clock domain clk/rst signals
<whitequark> if you use a platform, however, it always takes care of setting ports= for you
<lkcl> ah thank you for clarifying, i used the word "random" to (ambiguously) mean/imply that.
* lkcl currently trying to upload a litex versa_ecp5 build of libre-soc
<lkcl> blinky works from nmigen-boards after some modification due to the wrong JTAG ID
<lkcl> 0x01112043 rather than 0x81112043
<d1b2> <TiltMeSenpai> lkcl: is this on an ecp5-12F?
<lkcl> ecp5-45F
<lkcl> bought from Mouser
<d1b2> <TiltMeSenpai> ah ok
<d1b2> <TiltMeSenpai> oh are you loading a bitstream built for a smaller ecp5
<daveshah> Sounds like you are mixing up the 5G and 3G serdes variants
<lkcl> honestly don't know. <Name>LFE5UM5G-45F</Name>
<lkcl> that's in the migen boards file
<lkcl> nmigen-boards does get this right
<daveshah> What is printed on the chip?
<lkcl> i think however litex doesn't have it
<lkcl> 1 sec
<lkcl> let me get the magnifying glass :)
<daveshah> LiteX definitely has the 5Gbps variant too
<lkcl> LFE5UM-45F
<daveshah> Then you have a mismatch
<daveshah> I think nmigen has a board file for that variant too, not sure about litex
<lkcl> loovely
<daveshah> There is the Versa ECP5 and the Versa ECP5-5G for the different serdes speed grades
<daveshah> You have the former
<d1b2> <TiltMeSenpai> are the ecp5 bitstreams pretty interchangeable (provided you don't use a nonexistent resource)
<daveshah> As they run at different Vcore the logic timings are different too
<d1b2> <TiltMeSenpai> ah, ok
<daveshah> So a bitstream that works on the 5G might not on the regular even if it doesn't use the serdes above 3Gbps
<lkcl> i've changed the litex openocd "searching for" string to 0x01112043
<lkcl> yeah i'm not using the serdes (yet)
<lkcl> starting off small, just want to get uart tx/rx operational
<lkcl> litex sim of libresoc.v works perfectly fine
<lkcl> i may however have to track down a litex uart "echo" example or something
<lkcl> although trying the "led chaser" example i just found might be even simpler and eliminate any possibility of "untested" code getting in the way
<daveshah> Changing the openocd string isn't enough
<daveshah> The idcode is also in the bitstream itself
<lkcl> daveshah: yes i grepped and found that it was there, modified the versa_ecp5.svf file by hand... of course if it's checksummed that won't work
<daveshah> Yes it is CRC16d
<daveshah> The data inside the svf is also reversed
<miek> you just need to get your top level part selection right, you shouldn't be grepping through and replacing it at random spots
emeb_mac has joined #nmigen
<lkcl> miek: i _love_ doing things like that when i don't know what i'm doing - sometimes they work :)
<whitequark> ^
<lkcl> ok hmmm so how do i select the correct top level part?
<daveshah> Set the nmigen device correctly
<whitequark> platform.device = "LFE5UM5G-45F"
<d1b2> <TiltMeSenpai> yeah, you actually have a different part. I think the only place where replacing IDCODE was the right approach is on the 12F, you used to build bitstreams for a 25F and swap out the 12F IDCODE at some point, but that's because the 12F is a 25F with a different IDCODE lol
<lkcl> daveshah: it's migen, not nmigen.
<daveshah> Ah right, should still be the same thing
<lkcl> whitequark: thank you - when i'm using nmigen-boards i'll remember that.
<ktemkin> you can pass the FPGA type as an argument to the LiteX build, IIRC
<lkcl> gotta find it though
<lkcl> ktemkin: ahh
<whitequark> that actually doesn't let you configure the density
<whitequark> why do -45F Versas exist, anyway?
<daveshah> All Versas are 45F
<lkcl> click: device
<lkcl> --device=
<daveshah> The difference is the serdes
<ktemkin> Platform(device="LFE5UM-45F") <-- is the typical LiteX way
<daveshah> I suspect it originated because of availability issues of the 5G devices early on
<whitequark> er, right
<whitequark> i was looking at ecp5-5g-evn
<daveshah> But yeah, it's also strange they didn't go for an 85F for the Versa
<daveshah> Maybe availability reasons too
<awygle> imo they had yield issues early on and got them worked out
<ktemkin> I love the non-5G Versas, because they just scribble over the -5G silkscreen everywhere with black marker
<lkcl> ktemkin: yes found it too, from looking at litex/boards/targets/
<lkcl> ktemkin: lol
<sorear> wasn't there one Lattice devboard where they sent out a batch with the wrong (not matching docs) chip soldered on?
* lkcl checks
<daveshah> Yes, Edmund ordered a 5G and got a non 5G
<lkcl> sorear: i heard about that. someone released some code to reprogram the FTDI to set the right ID
<daveshah> There were some early batches of non 5G versas that genuinely didn't have 5G on the silkscreen
<daveshah> Then they presumably decided it was cheaper to use one PCB design and have someone with a sharpie at the production line
<lkcl> ktemkin: no scribbles. i'm disappoitned :)
<ktemkin> they sent me the wrong one in fulfillment, so now I have both
<lkcl> cool!
<lkcl> haha that's really funny
<lkcl> oooo blinky lights!
<daveshah> Great!
<lkcl> the blinky lights litex example works when selecting LFE5UM
<lkcl> yeah
<awygle> the company i work at bought some LFE5UM-85F-5Gs and got a tray of LFE5U-45Fs instead
<awygle> not related to versas tho
<daveshah> scammed lol
<lkcl> awygle: urrrr
<ktemkin> gods, this board I'm working on has no I/O at all, so I'm currently getting my I/O through a DDR2 sodimm
<lkcl> ktemkin: lol
<awygle> oof
<awygle> some idiot (me) designed this board with no general purpose I/O or test points too
<lkcl> there was a modular computer design that used sodimms to put the processor+memory+nand on it
<whitequark> misusing sodimms for that seems common
<lkcl> dang the libresoc design's big. an unavoidable side-effect of planning to do out-of-order and multi-issue, the register files are unary-addressed and can't use FPGA SRAMs.
<ktemkin> yep
<lkcl> the connectors are mass-produced, and cheap, and the pins small and proven to run at high speed.
<ktemkin> I ordered one of these things that'll be here in a couple of weeks so I can have so gods-damned LEDs >.>
<whitequark> what the heck is that
<awygle> i designed 3/4s of an ecp5 sodimm compute module before realizing it wasn't actually useful in its intended application
<daveshah> Signal integrity, hold my beer
<awygle> might finish it someday
<lkcl> ha! uploaded, and it already has blinky-lights incorporated. nothing from the UART yet though
<ktemkin> whitequark: it's LEDs tied to SODIMM pins for ambiguous testing
<daveshah> I wonder if those are integrated resistor LEDs or whether they just rely on the current limits/controlled impedance drive
<whitequark> ambiguous testing
<whitequark> i love it
<daveshah> Oh, I thought it was a pass through
<ktemkin> daveshah: I'm assuming they rely on the forward voltage of the LEDs being a bit higher than the signaling voltages
<whitequark> why does it have a battery holder
<daveshah> Makes slightly more sense as just a thing
<ktemkin> whitequark: I have _no idea_
<ktemkin> possibly the signaling forward voltage isn't enough for the LEDs and they use a coin cell to power the LEDs and then rely on the coin cell voltage to 0 being enough to turn the LEDs on, but the coin cell to 1 not being
<ktemkin> that's a good sentence, there
<daveshah> that must rely on the battery adding voltage somehow
<ktemkin> lithium coin cells output like 3v, which is enough to turn on an LED
<ktemkin> so either they expect you to jab a lithium cell in there or it's series'd with 1v8
<ktemkin> I'll find out when I get this thing
<daveshah> It might just be testing that there is some kind of circuit
<d1b2> <TiltMeSenpai> it's to detect shorts I think?
<whitequark> >2.Using patch components, no hurt to your hands.
<d1b2> <TiltMeSenpai> > 4.Reversed insertion or misinsert will not burn any parts after power on. I don't believe you for some reason
<ktemkin> I mean, you can see the traces, there -- one side on each LED is to a plane (ostensibly VBATT) and one side is to the the DDR signals
<ktemkin> it's perfect for if you want to yoink off the oversized battery socket, add one bodge, and then have terrible LEDs
<whitequark> >Strong Exuberant Electronics (HK) Co., Ltd
<ktemkin> the best part is that you can convince yourself it was whomever made the thing that sinned, and not you -- you only plugged it in to the sodimm you're abusing, after all
<daveshah> yeah, who needs gamer RGB RAM
<daveshah> just put lights on the DDR lines themselves
<sorear> who called it "a CCD with a Bayer filter" and not "RGB memory"
<whitequark> lol
<ktemkin> well, this conversation's invoked in me... well, whatever the opposite of inspiration is
<ktemkin> there's an old spanish proverb that says "take what you want and pay for it"
<ktemkin> I wanted an LED, and I can only assume it'll cost me my soul
<whitequark> heh
<ktemkin> (and I didn't want to modify the base board)
<awygle> is that actually a spanish proverb? i think i heard it first in a wheel of time book lol
jeanthom has quit [Ping timeout: 246 seconds]
<awygle> apparently it's also in at least one agatha christie novel
<ktemkin> yep; it's not just Siuan~
<awygle> while i mostly find discord et al to be an unnecessary increase in complexity over irc, i admit i do miss the emoji-react convention for indicating "heh, yes, good, we are having a shared cultural moment, i enjoy this" without having to type it out
<awygle> (the other good thing about them is moderation tools)
<ktemkin> I was all prepared to be old and hate discord, but I actually appreciate a bunch of what it adds over IRC
<emeb_mac> haha
<whitequark> the main reason i hate discord is that it gives me a new inbox that constantly fills unless i actively mute everything
<whitequark> so i just refuse to check it regularly
<whitequark> which in practice means that i don't use it at all
<awygle> i was all prepared to not be old, because i usually don't hate new things, but discord insists on eating all of my RAM for some reason
<awygle> the web app must be leaky or something, idk
<whitequark> that's the second reason i don't like discord
<awygle> the "desktop app" (electron) doesn't leak but i don't have it installed on e.g. my work laptop
<emeb_mac> the attention-sink nature of it is a problem. gotta manage those mutes
<whitequark> i refuse to manage the mutes
<whitequark> i already have enough make-work without that
<ktemkin> I just ignore everything
<awygle> i kinda roam from one unmuted discord to another over time
<whitequark> yes, i mean, i ignore everything, by not running discord
<ktemkin> I mean, I ignore IRC, too, most of the time
<whitequark> if people want to contact me? well, that's their problem now
<awygle> currently i have one unmuted channel in an n64 homebrew discord, and then the digital design discord, and that's all i pay attention to
<whitequark> irc is easy to ignore because it doesn't have desktop notifications or red unread counters
<awygle> oh yeah i turned both of those off immediately
<awygle> talk about user-hostile designs
<whitequark> wait, you can turn off unread counters?
<whitequark> that would make discord almost usable
<awygle> i think so? i only get them for DMs now, which i actually want
<whitequark> how?
<awygle> hm, i actually don't know. you can turn off the red unread badge entirely in Notifications under App Settings
<awygle> but i have that on....
<awygle> in each server you can right-click and hit "notification settings" to turn off notifications
<ktemkin> the "unread badge" is for the whole-app badge, like the win10/mac/iOS red dot on the app icon
<ktemkin> it doesn't affect the badges on servers
<awygle> i have all of mine set to "@mentions only", but i definitely didn't do that one-by-one so i don't know why it defaults to that (though it's nice)
<awygle> dear god who would ever turn on "text-to-speech notifications", that sounds like a nightmare
<whitequark> i've set them one-by-one and then i just never opened discord again
<whitequark> awygle: deaf people?
<whitequark> er
<whitequark> blind
<awygle> even then i'd expect they'd want more control. talk about "tool for other people to give you intrusive thoughts"
<whitequark> yeah i don't really know
<whitequark> it's just my guess
<awygle> but ok, fair, that was definitely ablist of me
<awygle> ableist? probably ableist
<whitequark> great. someone dm'd me on discord but it doesn't load
<ktemkin> I mean, the service was originally gamer-centric; I wouldn't be surprised if people used it with controllers in their hands and text-to-speech on
<whitequark> oh
Asu has joined #nmigen
<lkcl> discord's... *sigh*. some friends of mine formed a group on it (business related).
<lkcl> the web interface is... not exactly functional (on an android smartphone chrome browser)
<Lofty> That's because they expect you to use the app, really.
<Lofty> Not saying that's necessarily a good thing
<lkcl> i'm impressed with the plugin system
<whitequark> i've never been one of the anti-smartphone types, but in the last few years i lean towards using smartphones as anything *other* than a personal communication device
<whitequark> it's a perfectly fine camera, map, etc
<whitequark> but everything communication-related seems to be full of evil
<lkcl> whitequark: yeah. after 9 smartphones back in 2003-4 doing xda-developers research, i got fed up with them. i like dumb-phones :)
<lkcl> the donated Asia Samsung N9005 i have, *all* google services i disabled, and side-loaded an adb browser package.
<whitequark> i don't like dumbphones at all
<whitequark> the only reason they are useful to me at all is awful services that require 2FA (mostly banks), and the only thing i get from them is frustration
<lkcl> the reason: it was downloading "updates" to google play / store / everything, which got to *12 gigabytes* of the 16GB eMMC
<lkcl> ahh yehh despite the warnings about SMS being hackable / fakeable
<whitequark> no i don't even care about the security of SMS
<whitequark> the only result of 2FA being required, in my case, is that when it for some reason doesn't work, i can't use the service
<whitequark> and SMS delivery is anything but reliable
<lkcl> yeah we have a UK bank account and when in TW that's an absolute frickin nuisance
<d1b2> <TiltMeSenpai> sms is evil, mms is worse somehow
<d1b2> <TiltMeSenpai> like as a protocol, do not like
<lkcl> last time we happened to be back in the UK we had to get a UK SIM just to receive 2FA SMSes
<lkcl> in order to get access to the internet banking.
<whitequark> does mms still... work?
<whitequark> i don't think i ever managed to send or receive one, but i stopped trying a decade ago
<d1b2> <TiltMeSenpai> I think "work" was always a definition that was stretched
<whitequark> ok let me rephrase
<whitequark> does mms still exist?
<whitequark> beyond a technical standard on paper?
<tannewt> ya, I think it's used by android and mixed os group texts
<daveshah> Yes, I received one recently
<d1b2> <TiltMeSenpai> I can send/recieve mms in the US I think
<whitequark> huh
<TD-Linux> in the us it's used heavily
<daveshah> Older people in the UK definitely use it still
<TD-Linux> it's WAP based therefore cursed
<daveshah> Despite the fact it is usually pretty expensive
<daveshah> 50p/message level
<d1b2> <TiltMeSenpai> why do telcom companies (ok I'm done complaining about how cell phones are fundamentally fucked for now)
<lkcl> TiltMeSenpai: lol
<cr1901_modern> What's an MM?
* lkcl has litex picorv32 running up to the litex bios
<lkcl> which is another good sign
<lkcl> (UART works)
<daveshah> Very good
<lkcl> hmmm ahh i have a 37.7ns "routing" delay reported by nextpnr-ecp5
<tannewt> mms is multimedia message (a form of texting)
<lkcl> which works out at around a 27mhz clock (1/37.7e-9/1e6)
<cr1901_modern> ahhh
<lkcl> just to "get things working initially" how would i drop the clock down to say.... mmm... 16 mhz in litex?
<d1b2> <TiltMeSenpai> and mms works by essentially sticking a url in an sms (normally unencrypted http, and relying on network traffic never leaving carrier controlled space) and telling your phone to go fetch it
<lkcl> i'm not entirely expecting it to be as simple as "--sys-clk-freq=16e6" :)
<whitequark> there's a #litex channel, right?
<lkcl> whitequark: oh! duh, good point :)
<cr1901_modern> #litex or #timvideos are good for Litex discussion
<daveshah> lkcl: you need to add logic delay too
<daveshah> But even simpler, look at the maximum frequency nextpnr prints :)
<lkcl> daveshah: logic delay?
<lkcl> daveshah: :)
<daveshah> show me the timing report
<lkcl> 22.61 MHz
<lkcl> Warning: Max frequency for clock '$glbnet$sys_clk': 22.61 MHz (FAIL at 75.01 MHz)
<daveshah> Yeah, that's your max freq
<lkcl> ok cool. i can sort that later
<daveshah> Sounds very typical for an ASIC core on an FPGA :)
<d1b2> <TiltMeSenpai> ok I might have a hyperfocus round 2 on the USB HID stuff, if I were to write a generic HID builder, what would be preferable: a python dict of metadata, builder pattern, or context managers everywhere
<d1b2> <TiltMeSenpai> or something I'm not thinking of
<tannewt> TiltMeSenpai: what are you doing with USB HID?
<ktemkin> I should probably start using the channel I made for LUNA instead of letting it fill up #nmigen, huh? >.>
<d1b2> <TiltMeSenpai> I've been working on adding USB HID to ktemkin's LUNA project
<d1b2> <TiltMeSenpai> oh, there's a LUNA channel?
<lkcl> daveshah, yeah. you heard about the IBM A21?
<whitequark> i don't mind LUNA chat here fwiw
<ktemkin> TiltMeSenpai: mostly on the usb-tools discord, but it's bridged to #luna-usb
<ktemkin> I haven't told people about it because I'm hiding from everyone~
<d1b2> <TiltMeSenpai> ah, didn't know there's a discord. Should I move convo over there?
<ktemkin> anywhere's fine
<ktemkin> TiltMeSenpai: for a generic HID IN endpoint, I was thinking of a builder around SignalInEndpoint
<lkcl> urrr i miss Makefiles. intermediary files get built and don't need rebuilding
<lkcl> one mistake on "integrated" build tool command-line options and it's a 10-60 minute rebuild
<ktemkin> TiltMeSenpai: in the same style that many of the LUNA modules are builders
<whitequark> makefiles don't have many advantages for FPGAs since (esp with FOSS tools) you do an equivalent of a software LTO build
<whitequark> sure, you don't have to resynthesize if you only change p&r options. but this is rare
<lkcl> whitequark: yeah i totally get it, repeatability is important apart from anything.
<d1b2> <TiltMeSenpai> hmm maybe I should just open a RFC issue on LUNA or something like that. Would you be opposed?
<ktemkin> TiltMeSenpai: off the top of my head, I can imagine that as having a function like .add_report_item(), which takes both metadata that describes the type of the report item, and the signal that carries the relevant report chunk -- and then the module might Cat together the various report chunks appropriately and squish 'em in a SignalInEndpoint
<ktemkin> and yes, RFCs are Very Good
<lkcl> and yeah now i think about it, the PnR would change completely even for the smallest change in the "source"
<d1b2> <TiltMeSenpai> ok, also did you see my comment about the HID descriptor/HID Report descriptor stuff? no rush if not, don't want to stress you
<lkcl> new experience, different paradigm
<daveshah> Incremental builds are _theoretically_ possibl
<daveshah> particularly for small design changes
<daveshah> but the tooling for them is not really there, even in the vendor toolchains
<whitequark> conversely, all the dependency tracking adds complexity and potential issues
<daveshah> Yes
<whitequark> migen's makefiles did not work well on windows, for example
<lkcl> daveshah: yeh thinking it through after wq mentioned about pnr it doesn't make sense
<whitequark> so i just ditched them
<daveshah> Oh incremental PnR is definitely doable
<tannewt> I do like ninja for managing dependencies and what to rebuild
<whitequark> yeah but... it's even more obscure than make
<daveshah> doing it while getting both a decent build speedup and limited QoR cost is a lot harder
<whitequark> you and i have it, but i don't think that everyone should
<tannewt> I was considering trying to take an nmigen build plan and convert it to ninja
<tannewt> I liked ninja because it solves the problems I don't want to and not much more
<tannewt> I'm happy to have python generate the ninja file and not need to hand edit it
<whitequark> i don't see what problems ninja would solve here
<tannewt> it handles the problem of what to rebuild
<whitequark> like i said, i don't think this is a problem that exists
<tannewt> that's a fair
<tannewt> :-)
<tannewt> my main interest is the other end of system level nmigen apis :-)
<whitequark> it would be technically simple to support generating make or ninja files or such. it just won't do anything useful beyond getting people to stop suggesting this
* lkcl ngggggh 3rd time rebuilding changing the sys_clk_freq parameter in nggggh
<lkcl> i'd bang my head against the keyboard of the laptop if it wasn't so insanely expensive :)
Asu has quit [Quit: Konversation terminated!]
Asu has joined #nmigen
<tannewt> lkcl, sounds like you have time to add ninja support to litex :-P
<lkcl> tannewt, don't tempt me lol
<daveshah> sys_clk_freq changes the design too slightly
<daveshah> The UART baud rate default value
<daveshah> And the PLL setting is in the Verilog, not passed straight to the PnR
<lkcl> daveshah: figures
<daveshah> So I don't see how ninja would directly help
<daveshah> If it's a hack and you want to save time, you could change the PLL divider in the JSON manually
<daveshah> And use something flexible for the UART
<lkcl> appreciated the hint on that one
<lkcl> holy cow it worked
<lkcl> ok, well, the memory test/initialisation failed probably because i have the clock too low (8mhz)
<daveshah> Oh yeah, I think 48MHz or so is the lowest that has been tested
<daveshah> (also, we should probably continue and discussion of that in #litex :)
<lkcl> good idea.
TiltMeSenpai has joined #nmigen
<_whitenotifier-b> [nmigen-boards] whitequark commented on pull request #103: Add GPDI pins to -
Asu has quit [Quit: Konversation terminated!]
<_whitenotifier-b> [nmigen-boards] GuzTech commented on pull request #103: Add GPDI pins to -
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 260 seconds]
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #nmigen