<ktemkin>
I can see the utility of it; but I'm concerned it might become a junk drawer if the use isn't at least carefully documented
<ktemkin>
mm
<ktemkin>
whitequark: so, are you okay with having that kind of "misc const" structure on a peripheral, but not okay with the lack of e.g. typing on the type?
<ktemkin>
^ agreed with that last statement
<ktemkin>
the idea is roughly that e.g. a header generator would be able to iterate over it and dump out peripheral-related constants in header files, right?
<ktemkin>
might be good to finish focusing on current/planned work and then move on to future/desired work
<ktemkin>
I don't have anything I can think of
<ktemkin>
so, is this the scheduled nMigen meeting time (or five past), or am I off?
2020-07-04
<ktemkin>
but he can tweak the bot settings to never translate his Discord tags~
<ktemkin>
yep
<ktemkin>
oh, cool, and I can toggle it on and off of myself to hide and show the channel for me
<ktemkin>
a mod will have to do it for now; but theoretically one of the bots in there can be configured to let you take the roles on and off
<ktemkin>
tpw_rules: okay, I brought it up to esden, and assuming he's cool with the role being set up I'll stick it on you
<ktemkin>
if you'd rather use IRC for the bridged channels
<ktemkin>
tpw_rules: I can probably just add a role that removes access to that channel
<FL4SHK>
ktemkin: thanks
<ktemkin>
"pacman -Ql qemu-arch-extra" has "qemu-arch-extra /usr/bin/qemu-x86_64" on x86_64, I assume it does on alarm
<ktemkin>
FL4SHK: try `qemu-arch-extra`
2020-07-03
<ktemkin>
which made Wayland compositors very angry
<ktemkin>
I gave up on Chromium on my XPS a while back; since its rendering process kept interfacing with the kernel in ways that made it hard for other things to use the GPU
<ktemkin>
*when combined
<ktemkin>
combine with one of the qbasic LLVM frontends
<ktemkin>
LLVM HLS backend that creates the ideal CPU to run your GORILLAS.BAS
<ktemkin>
if someone wants to do something entirely cursed, I would adore the dadaism of a new-HDL embedded in QuickBASIC 4.5
<ktemkin>
obviously { matches } and `do` matches `end`~
<ktemkin>
just, for the love of all that's sacred, please don't make anyone write "end else begin"
<ktemkin>
having to write some cursed code to make a cursed thing happen seems reasonable
<ktemkin>
I mean, you could do the terribly cursed thing and write a little behavior description in Verilog, and then Instance that
<ktemkin>
I mean, nMigen's not going to stop you from invoking an Instance that has your desired latch behavior
<ktemkin>
at least, in the sense of "unusal" that matches explicitly wanting a latch on an FPGA
<ktemkin>
cr1901_modern: I'm good with the idea of having to spend unusual effort to do unusual things
<ktemkin>
forgive that joking, though; I don't mean to actually pick on the work
<ktemkin>
if you don't provide footguns, you won't be able to brag about your excellent diagnostics that sometimes detect them
<ktemkin>
ah, that's right
<agg>
ktemkin: but if they didn't allow inferring latches, they wouldn't need to write CheckInferedLatchesPass to detect them!
<ktemkin>
it kind of amazes me that someone would get to the point of designing a new (domain-specific-)language and then be like "hmm... the ability to infer latches... yes, we need that"
<ktemkin>
who has enough characters for the extra "elf"? =P
<ktemkin>
pretty reasonable for code inset in a paper
<ktemkin>
I like the sound of splitting them
<key2>
ktemkin: as flo's work on usb3 is based on it
<key2>
ktemkin: we tried the liteiclink on the usb3
<ktemkin>
but I think I wrote it from their recommended process, it worked, and then I didn't test without the REFRESH
<awygle>
ktemkin: how did you add the refresh to the svf?
<ktemkin>
I do the REFRESH every time; and I think that was because somewhere Lattice said you needed to either do that or strobe PROGRAMN to multiple consecutive configs over jtag
<daveshah>
I think someone (ktemkin ?) reported that they needed a REFRESH command added to the svf file
2020-06-28
<jock-tanner>
ktemkin thank you, it all makes sense now
<ktemkin>
you'll want to use .o for output, and .oe to decide when the pin is being driven by the signal you assign to .o
<ktemkin>
.i, .o, and .oe
<ktemkin>
jock-tanner: for bidirectional pins, you'll wind up with a tri-state triple
<ktemkin>
I dunno what that result would even look like, since normally my goal is to squirt the data over to Qyriad's ViewSB
<ktemkin>
speaking of which: is there any point in me squishing any FS USB analysis stuff over into Glasgow?
<ktemkin>
^_^
<zignig>
ktemkin: got LUNA examples running on tinybx, hooray USB gateware phy.
2020-06-26
<ktemkin>
so it needs a tutorial, a book, and an API reference~
<ktemkin>
FL4SHK: be sure to stick around, then; that's a useful talent
<ktemkin>
(where content can be either the content as a string, or a python file-like/IO object)
2020-06-20
<ktemkin>
1800 UTC is decent for me; 1600 UTC tends to be a bit early during non-DST hours here
<ktemkin>
1800 UTC is 1400 EST, right?
<ktemkin>
UTC minus 4
<ktemkin>
that'd be the other way around
<ktemkin>
eastern time?
<ktemkin>
since a meeting on the 1st might conflict with one of my weekly meetings some months but not others
<ktemkin>
whitequark: I find it often works better to do something like "1st and 3rd Monday"
<FL4SHK>
ktemkin: IRCing from my cell phone is something I'd do if I had an SSH client set up on my phone
<ktemkin>
also, +1 to whitequark’s periodic meeting idea
<ktemkin>
(sorry for my terseness, I’m IRC’ing from my cell phone as I wait for something)
<ktemkin>
(that kind of dichotomy makes it clear how/when you’re building logic trees and avoids VHDL’s tendency to have complexity explosions when using blocking assignments)
<ktemkin>
for other things, you’d e.g. use an intermediary Signal as you’d use a non-blocking assignment in VHDL or a continuous assignment in Verilog
<ktemkin>
*blocking
<ktemkin>
Er
<ktemkin>
That gives you the Good Parts of what you can do with a VHDL non-blocking assignment
<ktemkin>
if b and c are signals, a = (b & c) winds up storing essentially a logic netlist that’s (B AND C) in the python variable “a”
<ktemkin>
You can build intermediary logic trees store in regular python variables
<whitequark>
so for example, ktemkin could mention what GSG/LUNA needs, jfng could mention what LambdaConcept needs, someone from LibreSOC (I'm not sure who is on IRC from that project) what they need, and so on
<FL4SHK>
ktemkin: thanks, I was mostly looking for "how do I use these classes"
<ktemkin>
FL4SHK: like you would any other python package; it just is a package that provides the various *Platform() classes
2020-06-15
<ktemkin>
it's definitely going to be nice for stuff like USB-analyzer-hardware-triggering; and maybe next-generation-facedancer, where asking users to install a whole toolchain is non-ideal
<agg>
It seems like a really nice enabler for even higher level projects like ktemkin's sdr idea where I imagine requiring your sdr users have yosys master and nextpnr installed on the system is a pretty big jump over just python
<ktemkin>
the wasm toolchain?
<ktemkin>
lol, it definitely fits vtr
<ktemkin>
s/Runtime/Redistributable, if you like
<ktemkin>
accompanied by HORNET, the Horribly Overengineerined Runtime for Netlist Elaboration and Translation
<ktemkin>
we'll see some of what it's like today, hopefully -- Brian over there suggests docs / repos will be sent out sometime today :)
<ktemkin>
that was fast
<whitequark>
ktemkin: he did!
<ktemkin>
whitequark: okay, I messaged the QuickLogic guy who reached out to me; we'll see if he follows up with you
<ktemkin>
if you're interested in playing with one (Cortex M4 + FPGA fabric w/ vendor supported open tools), I can poke someone over there and recommend they send you one
<whitequark>
ktemkin: I don't think they did
<ktemkin>
not much to do with it without docs, though :)
<ktemkin>
daveshah: per tracking, mine's downstairs
<ktemkin>
they've mailed me one, but I don't have docs, yet -- if what they have winds up looking reasonable, I might add support to nMigen
<ktemkin>
whitequark: by the way, is QuickLogic sending you any of their pre-release open-toolchain FPGAs?
<ktemkin>
IIRC, if you _do_ want to add a reset condition for a particular unit, you can use a ResetInserter to transform the Fragment/Elaborable; though in many cases you're better off making it explicit in your logic
<ktemkin>
or, in other words, the `reset` argument is the reset value, not the reset condition (which is implicitly pulled in with the clock domain)
2020-05-19
<ktemkin>
mood
2020-05-18
<ktemkin>
with m.fStrictVolatileBitFields():
<ktemkin>
with m.ThisTimeIMeanIt():
2020-05-12
<ktemkin>
well, that saves me the hassle of typing an equivalent out
<ktemkin>
look at how other ALUs generate their Signed Overflow bit
2020-05-08
<Sarayan>
ktemkin: I find twitter a little too public, and DM to oeasily leading to misinterpretations
<ktemkin>
Sarayan: seems like an odd place for it, but thanks for the compliment ^^
<ktemkin>
but this is the kind of context I'm missing :)
<ktemkin>
it sounded to me like the inputs they wanted were test simuli, rather than anything in the hardware, in which case one can just manage the array using normal python and then loop to yield to the appropriate signals
<ktemkin>
(I still don't exactly grasp what they're trying to do)
<ktemkin>
e.g. `collection = Array(Signal(16) for _ in range(16))` then allows you to do `output.eq(collection[another_signal])`
<ktemkin>
if you want a collection that can be indexed by a -signal-, Array will give you what you want
<ktemkin>
unless I'm misreading, that's what Array is for
<ktemkin>
but I am curious what you're trying to do :)
<ktemkin>
to answer the literal question: you can treat the problem more or less like any other python program
<Bernhard2>
ktemkin -> [Signal(16) for _ in range(count)] true this was allready wrong from my side :(
<ktemkin>
an equivalent that _does_ create `count`> unique signals would be [Signal(16) for _ in range(count)]
<ktemkin>
[also, that code -probably- doesn't do what the author intended; since that creates a single Signal(16) and then effectively adds it to the relevant list (n+1) times]
<ktemkin>
Bernhard2: what's your question?
2020-04-25
<ktemkin>
cr1901_modern: ^^
<cr1901_modern>
Incidentally I've wanted this for a while now too, so ty ktemkin for bringing it up :P
2020-04-23
<ktemkin>
I suspect there's a whole class of warnings like that one that'd be more cleanly implemented as e.g. linter plugins
<ktemkin>
</probably-too-much-info>
<ktemkin>
this all essentially boils down to the behavior that you're describing
<ktemkin>
so you'd wind up with logic that says "the next state of `x` is `0` if `a` is false, or `1` if `a` is true" in your netlist
<ktemkin>
https://gist.github.com/ktemkin/a070b9ec8cc9cdb85e5cbf18638dac87 <-- in this case, the .eq() inside the m.If() changes the netlist by adding a mux that selects between the existing next-`x` logic, and the newly assigned next-`x` logic based on the value of `a`
<ktemkin>
if you're in a special block (e.g. m.If), the way the netlist is updated changes to "match the block's behavior"
<ktemkin>
if you're not in a special block (like a "with m.If"), it more or less just replaces that logic, like you have there (the const `2` replacing the const `1`)
<ktemkin>
I think about it as: every time a python .eq() executes, it updates the netlist that decides the next value of a given signal (non-comb) or the value of a given signal (comb)
<ktemkin>
pretty much, yeah
2020-04-20
<ktemkin>
daveshah: added to the (now open) PR :)
<ktemkin>
I though those looked off
<whitequark>
ktemkin: sometimes you have to break the code to fix it
<ktemkin>
(an option that'd both compat friendly and user-friendly might be to set the override ourselves -and- set 25F; but that feels a bit like carrying around legacy cruft)
<ktemkin>
I'd expect user expectations going forward to be that they can set "LFE5U-12F" and it'd just work, since nextpnr now does
<ktemkin>
nmigen doesn't automatically add it on getting device = "<...>-12F"
<ktemkin>
cr1901_modern: it does; but every platform needs to specify the override itself
<ktemkin>
so there /are/ valid platform files that could contain 12F and --idcode{}; those'd be broken on older nextpnrs
<ktemkin>
it does if you add an IDCODE overrride
<awygle>
ktemkin: the current "treat it like a 25F" doesn't actually work (can't program) so I can't imagine there's a compat hazard. I'm not wq tho
<ktemkin>
whitequark: are we okay to start using the nextpnr --12k option that was added a month or so ago, in master?
2020-04-16
<ktemkin>
excepting that I'm inevitably going to wind up using it again without thinking, I agree
<ktemkin>
(maybe this makes me a poor pedant, but I’ve seen those words used to describe so many subtly-different concepts that they feel so context-dependent as to not have a single prescriptivist definition)
2020-04-12
<ZirconiumX>
ktemkin: enabling Jedi gives me a popup with IntelliCoe Python support requiring me to use the Microsoft Python Language Server
<ktemkin>
but yeah, not defending it as much as suggesting maybe it'd be better with some config
<ktemkin>
*modules
<ktemkin>
(if it can't find the module for the relevant interpreter; it typically assumes the wrong one and then gets grumpy at you and tells you it can't find your moduels)
<ktemkin>
ZirconiumX: it might get better if you install jedi; I think it tries to use that for autocomplete if it's around
<ktemkin>
ZirconiumX: this is part of the reason why I said "works pretty well for me"; it tries to use whatever tooling you have around to generate those popovers, and I'm not sure it always winds up with the right ones
<ZirconiumX>
ktemkin: the vscode-python documentation for Elaboratable is "Elaboratable"
<ktemkin>
vscode-python works pretty well for me
2020-04-11
<whitequark>
ktemkin: hey, pysim uses eval in a reasonable way.
<ktemkin>
locals() is kind of like eating something that's been dropped on the ground; eval() is like reaching down and eating a handful of dirt
<awygle>
ktemkin displaying her scars there, re: "milquetoast"
<ktemkin>
"if you're gonna abandon everything good about language design from the last two decades" <-- for one-offs made for the hell of it, there's something cathartic about not having to care what's a good idea
<ktemkin>
*its objects
<ktemkin>
just following it and prodding it's objects is relatively milquetoast
<ktemkin>
it's not as cursed as it would be if you were modifying the locals dict
<whitequark>
like ktemkin says, yeah
* whitequark
stares at ktemkin and awygle
<ktemkin>
but without any restructuring, you can grab locals by name with locals() and your local object properties with getattr()
<ktemkin>
one thing that might help might be to bundle your signals up e.g. by name, in a dict
<ktemkin>
(there might be a system task that'd work, but I don't remember one off the top of my head)
<ktemkin>
I assume you're talking about DPI, which has a similar brain-feeling, except it feels -unclean- at the same time >.>
<ktemkin>
part of my brain is just "you're setting a signal from an environment variable? what abstraction barriers have you transgressed?"
<ktemkin>
usb.full_speed_only.eq(1 if os.getenv('LUNA_FULL_ONLY') else 0)
<ktemkin>
wrote this line in a little section of (synthesized) test code, and my brain is just wriggling at how weird this construct feels:
<ktemkin>
(wouldn't have been four hours except that I tested the design first on a board where the two conflated domains shared a clock; and then was confused why it didn't work on another design; and my brain latched onto "what's different in the hardware, here?")
<ktemkin>
achievement unlocked: wasted four hours probing signals because I typed the wrong clock domain name
2020-04-10
<ktemkin>
there's one per IOLOGIC tile, IIRC
<whitequark>
this is a completely different definition of "behavioral" that i think ktemkin is using here
<ktemkin>
or, in the simple case of m.If(a) / m.Elif(b), I mean "why not just use the nMigen constructs that do this?"
<ktemkin>
"why not let the language generate" <-- yeah, I mean "why not use python to strum along nMigen in such a way that it does this"
<ktemkin>
it's like you're building a "vocabulary" out of those concrete pieces, and then using that to express your ideas
<ktemkin>
you can reach behavioral levels by taking those concrete transforms and using them to build abstractions
<ktemkin>
in nMigen, you start with a collection of concrete transforms on netlists; and build your way up from there
<ktemkin>
in Verilog, you often describe "abstract behaviors", and let the synthesis tool figure out what the logic is that implements your behavior - you let the tools "infer down" from your description
<ktemkin>
I can see how that'd be confusing
<ktemkin>
are you confused specifically by me saying "you can adopt structural or behavioral paradigms"?
<ktemkin>
also: "I thought you said it was functionally correct, now" / "sure, but it could be functionally correcter"
<ktemkin>
or "I'll optimize once things are functionally correct"; however you want to phrase that~
<ktemkin>
my priority encoders there are stand-ins that'll eventually be replaced, in many cases, with good ol' or-the-signals-together bussing; the priority encoders just make it more obvious what's going on in simulation
<ktemkin>
I suspect the case of my code mentioned above is a bad example for this particular discussion, anyway
<ktemkin>
awygle: you can adopt structural -or- behavioral paradigms in nmigen; so it's as possible to say <generate the select logic> --> <build your mux with it>
<ktemkin>
awygle: for cases like with m.If(condition_A) / m.Elif(condition_B), why not have the language generate the priority logic for you?
<awygle>
i mean it'll eventually emit muxes like ktemkin said, so idk why we wouldn't drop to that level personally. but maybe there's a good reason i'm not aware of?
<ktemkin>
(which then drive mux selects)
<ktemkin>
an m.If/M.Elif chain generates priority encoders
<ktemkin>
Degi: they're not semantically equivalent
<ktemkin>
tpw_rules: took me a bit to realize those existed, too :)
2020-04-09
<ktemkin>
and thanks; I'm gradually refining my sense of how-I-want-to-use-nmigen :)
<ktemkin>
it'll loop over priority-encoder conditions and go m.If, m.Elif, m.Elif
<ktemkin>
it's just metaprogramming that strums along nmigen's context managers
<ktemkin>
I can tell you that the part that detects setup packets has at least 18,446,744,073,709,551,616~
<ktemkin>
I'm vaguely tempted to look at the total number of register bits and report on how many states it has, now
<Sarayan>
ktemkin: how is your fsm going? ;-)
<ktemkin>
(nmigen has some support functionality for them)
<ktemkin>
awygle: you can use Python enums
2020-04-06
<ktemkin>
and you can do dual simplex by toggling the pull resistors rather than using those bits, if you don’t mind it being slow
<ktemkin>
bits [11:10] are the state of D+/D-; and bits [19:16] let you e.g. force the lines to J or K
<ktemkin>
or in
<ktemkin>
‘course, if you want to you can bingbang UART out the USB lines using the PORTSC1 register
<ktemkin>
I’m pretty sure in a just world I’d have been banned from using a computer a long time ago
<ktemkin>
I did terrible things via usb for a bit; and then gave up and just bitbanged UART using the GPIO in the intel GPU that are used for DDC, and just had UART on the DisplayPort
<ktemkin>
and the damned thing wouldn’t do the usual trick where you’d use frequency modulate data out the pc speaker (whose freq can be modified with a single portio write)
<ktemkin>
this discussion reminds me of back when I had to implement hypervisor stuff specifically for the Surface Pro, which only had two USB ports and a DisplayPort; and I wanted UART output
<ktemkin>
and thanks, I try ^^
<ktemkin>
I know this works because I’ve done it by accident
<ktemkin>
none of your peer devices know where those packets are coming from; so you’re the bus master now
<ktemkin>
and then you just inject your own e.g token packets in the interpacket delay after a transaction
<ktemkin>
another is to find a hub that doesn’t mind forwarding packets to downstream peers, which exist
<ktemkin>
that’s one way
<ktemkin>
it just makes the host a bit unhappy
<ktemkin>
I mean, technically speaking, it’s pretty easy to bus master the USB bus, too
<ktemkin>
pci-e is a great idea; I’ve always been disappointed that my mouse can’t bus master