<FL4SHK>
File "/media/other_data/fl4shk_home_stuff/Documents/programming_and_electronics/electronics/nmigen/small_projects_and_tests/vga_test/src/top_mod.py", line 47, in __elab_build_pll100
<FL4SHK>
AttributeError: '_ModuleBuilderDomain' object has no attribute 'clk'
<FL4SHK>
hopefully three lines of paste isn't a problem...
<vup>
FL4SHK: to get the clock signal you should use ClockSignal("domain_name")
<vup>
and for add_clock_constraint the easiest would be to constrain the signal actually driving the ClockSignal (because you cant use ClockSignal with add_clock_constraint)
<FL4SHK>
vup: how do I map a `Signal` to a clock domain?
<vup>
can you elaborate? I am not sure I get your question
<FL4SHK>
so there's going to be some kind of `Signal` that I'd use for an `always @(posedge clk)` if this were Verilog
<Lofty>
m.domains?
<vup>
FL4SHK: this is basically what ClockSignal is doing
<Lofty>
But nmigen has sync which is effectivelyequivalent
<FL4SHK>
I have two clock signals
<FL4SHK>
I'm creating a second one with a PLL
<FL4SHK>
I wish to use the PLL primarily
<vup>
sure
<Lofty>
What are the two clock frequencies?
<FL4SHK>
50 and 100
<FL4SHK>
that's not the issue I've got. I had Quartus generate the Verilog code for a PLL.
<vup>
you should create a new ClockDomain("domain_name") add it to m.domains and then you can use m.d.domain_name += stmt instead of m.d.sync += stmt
<Lofty>
In that case, I think you should use `DomainRenamer` to rename the `sync` domain to your 100MHz PLL
<vup>
right DomainRenamer is the other option
<FL4SHK>
Lofty: what about the general case
<FL4SHK>
vup: I need to tell Quartus about the constraints
<Lofty>
The general case is m.domains
<FL4SHK>
I tried `m.domains.pll100`
<vup>
to actually drive a ClockDomain you can just assign the pll output to ClockSignal("domain_name")
<FL4SHK>
it doesn't work, either
<FL4SHK>
oh
<FL4SHK>
via maybe `m.d.comb`?
<Lofty>
You assign the domain to m.domains and then use it as m.d.pll100
<vup>
FL4SHK: yes something like m.d.comb += ClockSignal("pll100").eq(pll.output_clock)
<Lofty>
While m.domains has its uses, I really feel like using it is an antipattern
<vup>
Lofty: well not everything can live with just a single clock domain, especially things like gearboxes, io serdes and stuff like that
<Lofty>
And that's why I said it has its uses
<whitequark>
huh? how can it possibly be an antipattern?
<whitequark>
this is like saying "variable declaration is an antipattern"
<Lofty>
Unintentional CDC
<whitequark>
`m.domains +=` binds a name, `m.d.<domain> +=` uses a name
<whitequark>
unintentional CDC is far more likely when no explicit domains are involved at all
<whitequark>
usually you'll get it with async inputs
<FL4SHK>
finally got it
<whitequark>
or to a lesser extent async outputs
<whitequark>
FL4SHK: what helped?
<FL4SHK>
using a separate signal for the output of the PLL
<FL4SHK>
then using `m.d.comb += ClockSignal("pll100").eq(pll.output_clock)`
<whitequark>
oh, yeah, that works fine
<whitequark>
another option is to do something like...
<whitequark>
for a `domain`, the `domain.clk` field contains a perfectly normal signal
<vup>
whitequark: btw is there a reason you can't use ClockSignal in add_clock_constraint?
<FL4SHK>
yay, my example works
<FL4SHK>
I am driving four LEDs with a counter running at 50 MHz, and another four with a counter running at 100 MHz
<whitequark>
vup: yes; a ClockSignal is meaningful only in the context of a specific module
<whitequark>
there's currently no way to bind it to such a context though
<whitequark>
we should probably fix it some day
<vup>
I see
<whitequark>
for now i'm fine with it as a limitation
<vup>
sure, its easy to work around it, it just feels a bit strange, as ClockSignal otherwise feels like a normal signal
<whitequark>
it's very much not
<whitequark>
another issue with it is passing the ClockSignal to a different module
<vup>
yes, which is why i say, it feels like one (atleast in my usecases)
<whitequark>
right, makes sense
<vup>
also another add_clock_constraint question, is there a deeper reason why one can't pass slices to it, or is it something planned in the future aswell?
<whitequark>
so the problem is that the constraint has to be applied when invoking the backend
<whitequark>
and it's not clear if all backends even *support* what you want
<vup>
ah hmm too bad (would be useful for example when dealing with the PS7 instance on zynq, as it passes in 4 clocks as a 4 bit Signal)
<whitequark>
you could try making a case for it by going through all supported toolchains (quartus, diamond, ise, vivado, nextpnr-{ice40,ecp5}) and making sure they allow expressing that in constraints
hitomi2500 has quit [Quit: Nettalk6 - www.ntalk.de]
<awygle>
whitequark: bikeshed, how would you feel about adding an optional file argument to Instance (assuming this was possible for the moment)?
<awygle>
We get that question a lot it seems, including from *checks notes* me
lkcl_ has joined #nmigen
<FL4SHK>
awygle: that seems like a good idea to me
lkcl__ has quit [Ping timeout: 265 seconds]
<FL4SHK>
mainly because otherwise you have to add it to the platform or something
<awygle>
adding it to the platform is still required to be supported, i think, for more advanced use cases. but if it's possible having a shortcut way to do that as part of the Instance constructor may be valuable.
<awygle>
on the other hand if it's not going to work in the common cases, it may cause more confusion than is necessary, which i'm sure wq has thought about
<whitequark>
awygle: there are two main issues i can think of
<whitequark>
1. so far, i've tried to keep the core language separate from the platform stuff. so you don't have to use the platform stuff at all, or you could reinvent your own platform, or something like that
<whitequark>
meaning that if there is a file argument, it's going to be an alias for platform.add_file but like with more steps
<whitequark>
2. the current add_file interface is basically a proof of concept
<whitequark>
it doesn't let you set verilog definitions, it doesn't let you control file ordering (important because of verilog definitions) and so on
<whitequark>
extending Instance in any straightfordward way will double these problem
<whitequark>
*problems
<awygle>
mk, makes sense
<whitequark>
what problem does it solve?
<awygle>
it doesn't solve any problem per se, it's just that that seems to be a common stumbling block for beginners
<whitequark>
right, yeah
<awygle>
and verilog etc interop is a pretty core use case for nmigen imo
<whitequark>
there should be an entire section on verilog interop
<whitequark>
in the docs
<awygle>
so i thought i'd ask the question
<awygle>
also this has led me to another question which is "how can i do cosimulation since simulator has no platform" but i'm pretty sure that's already an issue that's been filed
<awygle>
and iirc you had Plans
<whitequark>
yeah #113
* awygle
suddenly remembers getting pinged about an issue yesterday or the day before
<whitequark>
for cosimulation i think what i'll do is introduce a "generic platform"
<whitequark>
won't have registered IO, will use plain inout for tristates
<awygle>
oh it's a PR that's why i couldn't find it
<whitequark>
this is also helpful for other reasons, like people trying to target efinix or quicklogic or other families not supported directly
<awygle>
mhm
<awygle>
i like the idea of a generic platform
<whitequark>
basically the same thing as migen did if you didn't customize the platform
jeanthom has joined #nmigen
jeanthom has quit [Ping timeout: 256 seconds]
<awygle>
re: #369 - i haven't worked on this at all since we last talked about it, life has been busy. i am back to a more normal cadence now and my nmigen-related priorities are 1) finish the ILA stuff i was doing 2) finish #369 and #368 (and the pre-req mentioned there) 3) back to my funtimes FSM stuff
<whitequark>
ack
<whitequark>
so i'm interested in FSM stuff but records and streams are higher priority
<awygle>
i agree with that, but i have a prototype stream thingy i'm already using, and i need (well, would really like) better FSMs for my DDR2 controller project
<awygle>
and last time we talked about streams you weren't ready to dig in on them
<awygle>
so i've been working on a prototype FSM (HSM, statechart) implementation for use in that project, and figured someday you'd be ready to dig in on FSMs too, some time after the date where we did detailed work on streams
<whitequark>
yep, sounds reasonable
<awygle>
what's your list looking like? (understanding that it's subject to change for any number of reasons)
jeanthom has joined #nmigen
<whitequark>
it's pretty stable actually
<whitequark>
- ship cxxsim
<whitequark>
- release 0.3
<whitequark>
- ship the first approximation of docs
<whitequark>
- fix records
<whitequark>
- ship streams
<whitequark>
- ship FSMs
<whitequark>
somewhere after the streams there will be more stdio work, and somewhere after 0.3 there will be more SoC work
<awygle>
huh, SoC before Streams/Stdio?
<awygle>
anyway that doesn't sound surprising, pretty much what i figured you were working on
<awygle>
i have some "how do i live alone again?" type chores to do the next couple days but probably i'll be spending my evenings on nmigen stuff starting approx. wednesday. it will be competed with only by monster hunter world.
<whitequark>
cool, thank you
<whitequark>
SoC has been unfairly neglected for some time, let's fix that
<whitequark>
there is some low-hanging fruit even before streams go into action
<tpw_rules>
i had a really dumb idea for a reimagining of FSMs which i'm calling "task machines". each state becomes a task that other tasks can enable or disable so they can pipeline. i feel like it would be very dangerous though
<tpw_rules>
i also didn't think about it beyond that
<whitequark>
the general direction of FSM evolution i'm thinking about is "whatever helps implementing finite state transducers"
<tpw_rules>
i'll have to see if i can figure that out
<lkcl_>
tpw_rules: i spent some considerable time on infrastructure that would allow combinatorial blocks to be used for either FSMs or pipelines.
<lkcl_>
it was... complex.
<awygle>
> open wiki article on FSTs
<awygle>
ow ow my eyes, my brain, ow
<lkcl_>
it was part of the conversion of jon dawson's ieee754fp code to nmigen
<tpw_rules>
awygle: my thoughts precisely
<awygle>
i already _know_ what an FST is even
<lkcl_>
in the end i gave up and focussed on pipelines.
<awygle>
it's just that of all the groups of CS people who are incapable of communicating their ideas clearly, language/automata theorists are among the incapablest
<lkcl_>
tpw_rules: at one point however it did actually work
<whitequark>
awygle: yes
<whitequark>
i also find the terminology obnoxious
<whitequark>
though i have a much better grasp of it these days
<tpw_rules>
the thing i wanted to solve was like if you have an IDLE -> BUSY -> FINISH, how do you express that FINISH can transition directly to BUSY without replicating IDLE's logic in FINISH?
<awygle>
lmao "Stochastic FSTs (also known as probabilistic FSTs or statistical FSTs) are presumably a form of weighted FST.[citation needed] "
<tpw_rules>
"presumably" is the stochastic part
<awygle>
tpw_rules: are you familiar with HSMs/statecharts?
<awygle>
they solve that in a quite elegant way, imo
<awygle>
that's what i've been working on implementing
<lkcl_>
tpw_rules: ah that sounds slightly different from the focus of the FSM work i did.
<tpw_rules>
i remember working with statecharts but not anything hierarchical
<tpw_rules>
do you know if there's a system which would have it?
<awygle>
the UC OskiCat one suggests an ebook exists
<awygle>
if i still lived in california and there wasn't a pandemic i'd just go to the library and photocopy it
<tpw_rules>
our ebsco-based system can't find anything that looks relevant
<awygle>
if i did get a scan of it, say over my mother's birthday at the end of july, i wonder what the best way to distribute it so people could get at it would be
<awygle>
just in case anyone but me ever cares
<tpw_rules>
i've kind of wondered how to submit stuff to sci-hub
<tpw_rules>
not sure it's possible?
<awygle>
wasn't whitequark accidentally running a library at one point too? lol
<awygle>
(called the whitequarchive, i assume)
<whitequark>
tpw_rules: you can submit stuff to libgen
<tpw_rules>
incidentally holy crap do i love sci-hub. it makes dealing with papers so much easier
chipmuenk has quit [Quit: chipmuenk]
Asu has quit [Remote host closed the connection]
<_whitenotifier-f>
[nmigen] alanvgreen commented on issue #409: _yosys fails to parse Yosys version from fomu-toolchain - https://git.io/JfxkK
<_whitenotifier-f>
[nmigen] whitequark commented on issue #409: _yosys fails to parse Yosys version from fomu-toolchain - https://git.io/JfxII
<awygle>
Augh, that reason for 2 being impossible
<awygle>
the saddest thing
<whitequark>
yeah, very long term we have to migrate off RTLIL
<whitequark>
and this is an important reason to have Yosys on PyPI: then you can manage dependencies with `pip freeze`
nengel has quit [Ping timeout: 258 seconds]
<awygle>
frrtl when
<whitequark>
no longer sure about firrtl
<whitequark>
I talked to Chris Lattner about it and turns out everything except LoFIRRTL is soft-deprecated
<whitequark>
we do need only LoFIRRTL
<whitequark>
but he was encouraging creating something *based* on LoFIRRTL moreso than using it wholesale
<whitequark>
we can probably still lower to it, it's just not entirely clear exactly how much benefit it will bring over time
<awygle>
mm, lame. we need _something stable_ that people can get behind
<whitequark>
yep
<Lofty>
The xkcd standards comic but the 3rd panel is "there are 15 buggy competing standards"
<whitequark>
rtlil isn't even a standard
<awygle>
what's the other one besides firrtl
<awygle>
didn't one of the other projects have one?
<whitequark>
I'm not sure what you mean
<awygle>
there's also LNAST and its IR which i can't remember the name of
<awygle>
i mean another HDL IR besides RTLIL and FIRRTL, i thought there was another one that was "popular", associated with Chisel or Spinal or one of the other nuHDL projects
<whitequark>
chisel uses firrtl
<awygle>
LLHD is the LNAST one
<whitequark>
spinal uses uh... verilog/vhdl
<awygle>
oh wait no LLHD is another thing, LNAST's IR is LGraph
<whitequark>
>Note: It is not yet clear whether LLHD will provide alloc and free instructions to create and destroy memory slots in an infinite heap data structure.
<whitequark>
OMwhy
<whitequark>
*why
<awygle>
idk i feel like "␛OMwhy" was what your heart really had to say
<awygle>
oh wait doesn't symbiflow have an IR
<awygle>
fasm or something?
<Lofty>
fasm is way too low level for this
<awygle>
ah, k
<awygle>
literally all i know about it is "somebody tweeted 'TIL about fasm' the other day"
<mwk>
fasm is not an IR, it's basically just textual bitstream format (and a bad one at that)
<cr1901_modern>
It's "used" by nextpnr-generic as the final output
<whitequark>
so, something i wanted to discuss
<whitequark>
i'm currently writing docs (intro page, etc) for YoWASP
<whitequark>
the outline i'm going with is something like: - what is it? - why is it useful? - what are limitations? (platform support etc) - how to install it? - how to use it with my tools? (eg nmigen env vars)
<whitequark>
anything else i should add?
<cr1901_modern>
> how to use it with my tools?
<cr1901_modern>
>>How does yowasp interact with non-WASM yosys and nextpnr? Any potential gotchas?
<cr1901_modern>
This might not be worth mentioning, but can't hurt
<whitequark>
good topic
<whitequark>
it's actually something important that i missed
<awygle>
what i would want to know is something like "how can i write my code so that yowasp is used if there's no yosys/nextpnr available natively" but that may be uh... too specific
<awygle>
or alternately something that everybody who is Good At Python already knows
<whitequark>
this is actually kind of a hard problem i don't know how to solve yet
<whitequark>
the other direction is easy
<whitequark>
so
<whitequark>
python lets you install "scripts" which go to ~/.local/bin usually, or in the virtualenv
<whitequark>
yowasp will ship all binaries prefixed with yowasp-
<tpw_rules>
wassup-yo?
<whitequark>
lol
<whitequark>
so normally you'd have to do something like