<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 basic.py 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 sram_soc.py 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?
<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 - www.ntalk.de]
<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?
<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>
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 >.>
<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>
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 three.co.uk 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
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 libresoc_versa_ecp5.py 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 ulx3s.py - https://git.io/JJy9g
Asu has quit [Quit: Konversation terminated!]
<_whitenotifier-b>
[nmigen-boards] GuzTech commented on pull request #103: Add GPDI pins to ulx3s.py - https://git.io/JJy5b