<lkcl__>
i couldn't be bothered to write a module at all :)
<lkcl__>
or a class.
<lkcl__>
i just needed to test something very quickly
<DaKnig>
yeah
<DaKnig>
that makes sense
<DaKnig>
the examples put everything as members of the class
<lkcl__>
however further up... ah yes, i was getting to that :)
<DaKnig>
well thats probably for debugging
<lkcl__>
look further up in the elaborate function of class Rotator
<lkcl__>
you see there are some variables marked "temporaries"?
<DaKnig>
yeah I saw that
<DaKnig>
I was talking about that
<lkcl__>
those, if they were exposed to the outside world (self.x), a python developer would look at those and go "ehn? do i have to set these externally or not??"
<DaKnig>
I didnt know python allowed a constructor to see the name attached to the new instance
<DaKnig>
yeah that makes sense
<DaKnig>
more than the tutorial
<lkcl__>
btw i do strongly recommend that you follow a convention of _i and _o on signal names.
<lkcl__>
it is _such_ a bitch to read code that doesn't do that.
<DaKnig>
I dislike that style
<lkcl__>
particularly for wishbone
<lkcl__>
yehh there are instances where it's definitely not a good idea
<DaKnig>
encoding information as part of a name is ugly imo
<DaKnig>
things like hungarian notation
<lkcl__>
example: places where a Record is used as input in one class and as output in another
<DaKnig>
why not just add _u8_i while we're at it
<lkcl__>
lol
<DaKnig>
ah yeah I could see that being useful
<lkcl__>
there, you definitely don't want to add _i or _o to the Record
<DaKnig>
.... I should go learn how to use ctags and such
<lkcl__>
so... and i appreciate you might not like this: what i do is add the Record instance to *another* object that is named _i or _o :)
<DaKnig>
o no :(
<lkcl__>
honestly when you get to create pipelines and are passing data around, and have to think about ready/valid from the perspective of the sender *and* the receiver, it's so insanely confusing
<lkcl__>
no, not sender/receiver: pipeline-stage 1 -> pipeline-stage 2
<lkcl__>
you get the idea.
<DaKnig>
yeah
<lkcl__>
in the nmutil pipeline API, it was awful, until we came up with a "prev / next" and "input / output" naming convention
<lkcl__>
if they were just called "ready" and "valid" it would be almost impossible to work out what was supposed to be connected to what
<DaKnig>
yeah of course.
<DaKnig>
input_valid and such is preferrable there
<lkcl__>
GPIO is... hard to get right, which is which direction. datasheets for peripherals and bus APIs usually include I or O in the name somewhere.
<lkcl__>
you know the convention about "N" at the end of a name to indicate "inversion" i take it?
<DaKnig>
yes
<lkcl__>
oh, another one, back to those locals: there's a convention in python to use an underscore to indicate private (c++ "protected") members
<DaKnig>
yeah I know that one
<lkcl__>
if you really needed access to one of those temporaries (from a simulation for example) then you'd do "self._xxx = "...
<lkcl__>
:)
<DaKnig>
its even enforced in recent versions
<DaKnig>
iirc
<DaKnig>
for __foo
<lkcl__>
sigh
<lkcl__>
that's going to cause absolute havoc.
<lkcl__>
changing strongly-established 20+ year old conventions, when there's literally billions of lines of code world-wide, what on earth do they think they're playing at??
<lkcl__>
sigh
<DaKnig>
not 20+
<DaKnig>
only count for python3
<DaKnig>
python2 is long dead
<lkcl__>
python's been around for...
<DaKnig>
and it already broke many things
<lkcl__>
weeelll.. they *declared* it "dead" - that's not the same thing.
<lkcl__>
i've worked in military environments so i'm aware that there are huge legitimate issues surrounding upgrading arbitrary software (as in: it's just not practical)
<agg>
python2 also name-mangled __members, that's not new
<DaKnig>
I am aware of that. but in those cases the new versions of python doesnt matter
<lkcl__>
there's a bank that is still using python2 as well, because they have several million lines of mission-critical code
<lkcl__>
agg: except, DaKnig's point is: because python2 is frozen, code that uses __foo conventions is not going to suddenly break
<DaKnig>
some banks use old versions of windows for computers connected to the internet exposing the users to security risks
<agg>
py3 made lots of backwards-imcompatible changes but the underscore handling isn't one of them
<lkcl__>
because there will *be* no upgraded version of python2 :)
<agg>
not sure it matters though, still can't run py2 code in py3 in general
<lkcl__>
oh! that's new to me! ha, funny, using python for 20 years and had never used a variable named __x :)
<DaKnig>
oh you can make a whole clock domain resetless!
<DaKnig>
thats handy!
<lkcl__>
then it's not a convention that's being broken, it's a convention that's already there
<lkcl__>
DaKnig: yes.
<Lofty>
You can, but you probably shouldn't.
<agg>
Lofty: what's the issue with it (on an fpga)?
<agg>
i've often got clock domains where i'm never going to drive the rst line, so apart from the weird ice40 brams-taking-3µs-to-init thing I don't think it will do anything?
<Lofty>
agg: you can invoke undefined behaviour, which is a small problem.
<agg>
(and probably just get optimised out if undriven?)
<Lofty>
It gets optimised out if undriven
<Lofty>
Trying to figure out how to write LUTRAM.
<Lofty>
For that I'd probably need to use actual memories for LUTs instead of shift registers
<lkcl__>
Lofty: that's how commercial FPGAs do it, you've no doubt seen the code-comments in nmigen and other places
<lkcl__>
about how some FPGA SRAMs don't respect write-through, some don't reset properly etc. sigh :)
<lkcl__>
2R1W seems to be standard. people can "gang" two SRAM cells together to get 4R1W, that way. that's standard practice, as you're no doubt aware
<Lofty>
Yep
<lkcl__>
some FPGAs i did hear - vaguely - had CAM. typically useable for creating caches.
<lkcl__>
but i could be wrong about that
<Lofty>
Well, you could possibly get away with 1R1W with some fuckery
<lkcl__>
:)
<lkcl__>
that'd be really small, as well.
<Lofty>
The LUT would have to be loaded through the write port, which is then optionally exposed to the user
<Lofty>
This results would result in an 8-address by 8-bit logic module
<Lofty>
s/results//
<Lofty>
Which is definitely quirky :P
<lkcl__>
:)
chipmuenk1 has joined #nmigen
chipmuenk has quit [Ping timeout: 260 seconds]
chipmuenk1 is now known as chipmuenk
<Lofty>
It's so much fun watching Yosys erase most of your design because you made a mistake somewhere
<Lofty>
It's somewhere in my memories, I think
<lkcl__>
Lofty: haha. one of the reasons why i want to get coriolis2 gate-level simulations running.
<Lofty>
I added some things and the design is now smaller, and that's never a good sign :P
proteus-guy has joined #nmigen
<whitequark>
lkcl__: there's no actual change in behavior of __x variables between py2 and py3, if you're going to write a rant on some topic, try to make sure you actually understand it first
<whitequark>
i'm so tired of this tilting at windmills
<lkcl__>
whitequark: further in the conversation, you'll see that i learned something new, that i wasn't aware of. you'll see that it was something that DaKnig wasn't aware of, either.
<lkcl__>
i'm grateful to agg for teaching me something that i didn't know.
<whitequark>
the problem with __fields is that they are called, in official documentation, "private variables", which is just wrong
<whitequark>
this feature has nothing to do with visibility; it is a namespacing mechanism!
* lkcl__
is in the middle of a formal correctness proof for PowerISA rld* instructions. doing my head in :)
<lkcl__>
it was fascinating to learn that the reason these shift-and-mask instructions exist (at all) is because they're used in a micro-coding fashion by LD and ST in the very first POWER processors
<lkcl__>
there was pressure to keep the gate count down so they wired up 5 broadcast lanes (RA/RB/RC/RS/RT) between LD/ST, Shift-Rot, and Register Files, and allowed LD/ST to interact with Shift-Rot through operand-forwarding
<lkcl__>
very elegant and fascinating design decision.
jeanthom has quit [Ping timeout: 265 seconds]
hitomi2504 has quit [Quit: Nettalk6 - www.ntalk.de]
lkcl__ has quit [Ping timeout: 256 seconds]
lkcl__ has joined #nmigen
chipmuenk has quit [Quit: chipmuenk]
jock-tanner has joined #nmigen
<DaKnig>
does nmigen have something for PLL or do I have to use primitives?
<Lofty>
You have to use primitives
<Lofty>
There's not even a portable way of instantiating a PLL in Verilog, let alone in nMigen
<DaKnig>
there's no portable way in Verilog to do BRAMs and such :) some toolchains would use flipflop ram instead
<Lofty>
Well, there are patterns that most toolchains figure out
<agg>
it does make sense, since nmigen does have a concept of clock domains and could work out frequencies and all that
<agg>
just like it has Memory and you don't need to use primitives to instantiate vendor BRAMs, although you still could
<cr1901_modern>
>and expressing it in the form of Diophantine equations?
<cr1901_modern>
Huh... never thought of that
<TD-Linux>
any thoughts about nmigen.cli for projects with a Platform?
<awygle>
my thought generally boils down to "don't use nmigen.cli"
<TD-Linux>
is the intent for nmigen projects to have their own higher level build system?
<cr1901_modern>
My own experience is argparse feeding into the build() functions
<awygle>
my impression (wq will correct me if i'm speaking out of turn) is that nmigen.cli was a "good enough" solution for the time, and we'll eventually circle back around to making it nicer, but for now there are higher priorities and just calling platform.build() is good enough for most use cases
<awygle>
if you need args you can use argparse or click or whatever
<TD-Linux>
(my question is not so much what to do now but what the end goal is)
<agg>
TD-Linux: i have my own very short main() that works out what device i'm building, instantiates the relevant Platform and Top classes, runs platform.build(top, ...), then programs the resulting binary (over network/usb/whatever is required)
<agg>
in the end what i want to do is custom enough (and easy for me to do) that i can't imagine i'd start using a built-in cli
<whitequark>
DaKnig: 1364.1 exists
<whitequark>
awygle is correct about nmigen.cli
<TD-Linux>
cool ok
<TD-Linux>
also would it make sense at all to add a cxxrtl "platform"
<whitequark>
no
<DaKnig>
and does 1364.1 define what code tools should understand as bram?
<whitequark>
for the same reason qemu is not an architecture
<whitequark>
DaKnig: yes, sections 5.6 and 5.7
<whitequark>
even lets you choose between BRAM and FFRAM
<DaKnig>
I dont see any mention of eithe ffram or bram in sections 5.6 and 5.7
<DaKnig>
no wait there's no 5.7 in the pdf I have
<whitequark>
DaKnig: (*synthesis,ram_block*) and (*synthesis,logic_block*)
<whitequark>
that's how the spec calls BRAM and FFRAM (FFRAM/LUTRAM are the Yosys terms that I suggested, I'm not sure how prevalent are they. some people call LUTRAM "DRAM" which is confusing as hell)
<FL4SHK>
"DRAM" is a terrible name for any type of memory you find in an FPGA
<DaKnig>
thanks, I thought it was up to a tool to decide
<DaKnig>
Im looking at an example. what does this mean `assert not (yield dut.ovf)`? I know what yields and asserts are, but what does the co-simulator send for this one, what does the `yield` there return?
<d1b2>
<TiltMeSenpai> In my opinion, the generator-style coroutines are horrifically confusing, even though they let you express things that async/await can't. The value = yield ... pattern is part of the fact that generator-style coroutines are generators, and have a sort of bidirectional communication channel built into them. This could help clear it up? https://stackoverflow.com/questions/34469060/python-native-coroutines-and-send
<d1b2>
<TiltMeSenpai> value = yield ... will result in value holding whatever gets send()'ed to the coroutine
<awygle>
in the case you described, (yield dut.ovf) will return the current value of the dut.ovf signal
<DaKnig>
yeah but my question was what does it send?
<DaKnig>
in this specific case
<DaKnig>
when you let the simulator do its thing
<DaKnig>
oh oops the answer was the next message
<DaKnig>
thanks.
_whitelogger has joined #nmigen
chipmuenk has joined #nmigen
chipmuenk has quit [Client Quit]
jock-tanner has quit [Remote host closed the connection]
jock-tanner has joined #nmigen
<lkcl__>
is it possible to do "Assert x == y" when both x and y are (identical) Record instances, and to expect that that will work?
<_whitenotifier-b>
[nmigen] FFY00 opened pull request #435: dsl: issue a warning if defining a case after the default - https://git.io/JJscJ
<_whitenotifier-b>
[nmigen] FFY00 commented on issue #404: Unused cases in a switch do not trigger warnings - https://git.io/JJscI
Asu has quit [Quit: Konversation terminated!]
<_whitenotifier-b>
[nmigen] codecov[bot] commented on pull request #435: dsl: issue a warning if defining a case after the default - https://git.io/JJsc5
<_whitenotifier-b>
[nmigen] codecov[bot] edited a comment on pull request #435: dsl: issue a warning if defining a case after the default - https://git.io/JJsc5
<_whitenotifier-b>
[nmigen] codecov[bot] edited a comment on pull request #435: dsl: issue a warning if defining a case after the default - https://git.io/JJsc5
<_whitenotifier-b>
[nmigen] codecov[bot] edited a comment on pull request #435: dsl: issue a warning if defining a case after the default - https://git.io/JJsc5
<_whitenotifier-b>
[nmigen] FFY00 commented on issue #405: Making an assignment to an input results in unclear assertion error - https://git.io/JJsCq
<_whitenotifier-b>
[nmigen] FFY00 edited a comment on issue #405: Making an assignment to an input results in unclear assertion error - https://git.io/JJsCq
<_whitenotifier-b>
[nmigen] whitequark commented on issue #404: Unused cases in a switch do not trigger warnings - https://git.io/JJslk
<_whitenotifier-b>
[nmigen] whitequark commented on issue #405: Making an assignment to an input results in unclear assertion error - https://git.io/JJslW