<Vinalon>
Is there any reason why defining a custom 'sync' clock domain would cause 'Warning: No clocks found in design' messages from nextpnr?
<Vinalon>
It is connected to a platform output, and the design builds normally when I comment it out and use the default 'sync' domain
<Vinalon>
It's just a `clock = ClockDomain("sync", clk_edge="pos")` followed by `clock.rst = self.clk_rst` and adding it to `m.domains`
Vinalon_ has joined #nmigen
Vinalon has quit [Read error: Connection reset by peer]
Vinalon_ is now known as Vinalon
<whitequark>
kc5tja: txs0108e is one of those awwful things with one shot accelerators
<whitequark>
if you are using them to translate signals clocked by something else, it might work
<whitequark>
do not EVER use them for ANY asynchronous signals or clocks, no matter how benign
<whitequark>
kc5tja: actually, scratch that
<whitequark>
txs0108e does seem to be a more advanced example of that concept
<whitequark>
i would very cautiously evaluate it in your application
<whitequark>
but prepare for async signals over it to not really work
Degi has quit [Ping timeout: 264 seconds]
Degi_ has joined #nmigen
Degi_ is now known as Degi
<kc5tja>
whitequark: Actually, I've found out that the whole circuit doesn't work at all. :(
<kc5tja>
Without the FPGA, and thus with outputs open, the computer boots and I can see 3.3V signals that are crisp and clean.
<kc5tja>
Put the FPGA in-circuit, though, and look out. 52MHz oscillations that seem to happen randomly (on the 3.3V side, at least), and some very distorted signals on the 5V side.
<kc5tja>
As you might expect, the computer fails to boot while the FPGA and level shifters are in-circuit. Take any one of them out, and the computer boots fine.
<kc5tja>
I suspect there must be some kind of feedback happening.
<kc5tja>
I would like to swap these out for 74LVC8T245s next; but, these don't come in a usable form for me (something that can plug into a solderless breadboard). Break-out boards have pin headers and such, but they have a 2x3 block of headers in the middle of the PCBs, which renders them simply useless for my hack circuit.
<kc5tja>
Vinalon: You might have to assign the clock to the default clock property for your platform.
<Vinalon>
it's probably something like that; I guess I thought that naming it 'sync' would do that automatically
Vinalon has quit [Ping timeout: 258 seconds]
Vinalon has joined #nmigen
_whitelogger has joined #nmigen
kc5tja has quit [Quit: leaving]
_whitelogger has joined #nmigen
<daveshah>
Vinalon: usually that warning is because all sequential logic has been optimised away for some reason so there are no intraclock timing paths
_whitelogger has joined #nmigen
<adamgreig>
Vinalon: you need to drive clock.clk with a clock input
Asu has joined #nmigen
Vinalon has quit [Ping timeout: 240 seconds]
proteus-like has joined #nmigen
proteus-dude has quit [Ping timeout: 258 seconds]
Vinalon has joined #nmigen
<awygle>
if i .connect two records together and then later assign to one subsignal, that should override the connection, right?
<awygle>
so i can use that to do "partial connections", where everything is the same except one signal?
_whitelogger has joined #nmigen
rohitksingh has quit [Ping timeout: 240 seconds]
<Vinalon>
thanks, it looks like I do need to set '.clk' - the build includes the clock domains when I comment out the custom 'sync' domain, so I don't think it's optimized out.
<Vinalon>
But when I try to set 'my_clk.clk = m.d.sync.clk', I get an AttributeError: "'_ModuleBuilderDomain' object has no attribute 'clk'"
<Degi>
What is my_clk?
<Degi>
Is that a my_clk=ClockDomain()?
<miek>
Vinalon: if you just want to change the clock signal, set platform.default_clk to the name of the resource & let nmigen create the sync domain for you
<Vinalon>
Yes, I set it up so that I could reset it from a signal created in the class which inherits from Elaboratable.
<Vinalon>
I tried using 'platform.request("sync")' and 'platform.request(platform.default_clk)', but both result in "Resource does not exist" errors
<Vinalon>
Do I need to re-do the logic from 'vendor/lattice_ice40.py' in my module?
<Degi>
Cant you use platform.default_clk?
<adamgreig>
Vinalon: what problem are you trying to solve?
<Vinalon>
That returns a string, because I'm using the internal SB_HFOSC clock
<adamgreig>
oh, you're trying to clock sync from SB_HFOSC?
<adamgreig>
have you created an Instance for the SB_HFOSC?
<Vinalon>
Yeah. And I'm trying to add a reset signal which is defined by my design to the default 'sync' domain
<Vinalon>
and the 'create_missing_domains()' function usually does that
<adamgreig>
you want to do something like m.d.comb += my_clk.clk.eq(hfosc_instance.clkhf)
<Vinalon>
I'd also be happy with something like, "m.d.comb += m.d.sync.rst.eq( self.clk_rst )", but I get a "'_ModuleBuilderDomain' object has no attribute 'rst'" error when I try that
<adamgreig>
oh
<adamgreig>
you can also just use ResetSignal() for that
<Degi>
I think you need to do ClockSignal("sync") for that (or just ClockSignal())
<adamgreig>
if your default sync clock domain is fine except you need to wire reset up to it, use ResetSignal() to get at the reset signal, and you can comb set it equal to something
<adamgreig>
if your default sync clock has the wrong input anyway, probably easiest to make a new clock domain as you're currently doing, and connect its clk signal to the hfosc output
<Vinalon>
okay; I tried "m.d.comb += ResetSignal( domain = "sync" ).eq( self.clk_rst )", but I'm guessing that's wrong because I get an AssertionError from 'hdl/ir.py' at "assert defs[sig] is self"
<Degi>
Oh no... that weird thing
<Degi>
how is clk_rst declared?
<Vinalon>
"self.clk_rst = Signal( reset = 0b0, reset_less = True )" in the __init__ method
<Degi>
weird
<Vinalon>
(thanks for the help and explanations, and sorry to bury awygle's question)
<awygle>
s'ok :p
peeps[zen] has joined #nmigen
peepsalot has quit [Ping timeout: 265 seconds]
<Vinalon>
well, it looks like I can call `platform.create_missing_domain("sync", reset=self.clk_rst)` with a small change to let the create_missing_domain method accept a reset signal.
<Vinalon>
I tried setting 'platform.default_rst' to avoid making a code change, but I got a "TypeError: unhashable type: 'Signal'".
<whitequark>
awygle: ideally do not use Record.connect at all, I think that API is a mistake
<awygle>
yeah increasingly coming around to that point of view tbh
<whitequark>
it was added to Migen for the easy case of conencting Wishbone interfaces
<awygle>
it's valuable in like, exactly one circumstance, but it _looks_ like it'll work in a lot more
<whitequark>
when one of them feeds the other directly
<whitequark>
and *even then* it doesn't work with unmodified Wishbone
<whitequark>
yep
<whitequark>
we should actually just deprecate it completely
<awygle>
~*~someday~*~ we'll have a better option
<whitequark>
feel free to write a PR or an issue for that, or I'll do it if I won't forget
<awygle>
sure i'll file an issue
<whitequark>
thanks!
<awygle>
yw :p it's quite literally the least i could do
<whitequark>
Vinalon: regarding your clock troubles, it seems like you're trying to do something useful but i'm not sure about your approach
<whitequark>
if you file an issue we can discuss the best approach there, I suspect it will require nmigen modifications in the end
<_whitenotifier-3>
[nmigen] awygle opened issue #342: Deprecate `Record.connect` - https://git.io/Jv7U7
<whitequark>
yes
<whitequark>
use Signal(range(n...)) instead
<whitequark>
the problem with `max` was that it is exclusive
<cr1901_modern>
hmm... I see
<whitequark>
so it was very misleading and a source of bugs in corner cases
<whitequark>
you still can get those bugs with range() but at least people who write Python probably already know that
<whitequark>
that's one issue with it
<whitequark>
the other issue with it was that you couldn't use min/max when defining signals in a Record
<whitequark>
which was a really annoying inconsistency
<whitequark>
now there's the Shape, and shape-like objects
<awygle>
i am always afraid i'm going to do range(n) to replace max=n when it needs to be range(n+1) (or vice versa)
<awygle>
but i am not the target audience :p
<whitequark>
awygle: that's why the warning literally tells you which code to write instead
<awygle>
yes
<awygle>
it's very nice
<whitequark>
i spent like a hour on the code for the warning alone
<whitequark>
speciically to avoid this issue
<awygle>
i appreciate it every time
<whitequark>
:)
<cr1901_modern>
when is min used to determine the shape of a signal?
<awygle>
speaking of appreciating shit you've done - i now understand something you once said about smoltcp, that tcp and ip are not actually separate protocols
<whitequark>
yup
<awygle>
i spent a bunch of time writing an IP packet framer thinking i could write a separate UDP one, only to find out that _nope_
<whitequark>
that isn't something i discover, there are rants on the topic that are older than i am
<whitequark>
hahahahahahahahaha
<whitequark>
yep
<awygle>
:shrug: live and learn
<whitequark>
it's pretty depressing isn't it?
<awygle>
it is, but also, at least IP exists
<awygle>
i'd rather have it than not
<whitequark>
well
<whitequark>
it could have sucked less
<whitequark>
but yeah
<whitequark>
we have ethernet, and ethernet is really good, and then it just goes downhill from there basically
<awygle>
the longer i work in this field the more i appreciate anytime we all just collectively decided to _pick one thing and use it_ regardless of how bad it is
<whitequark>
i have the exact opposite experience, actually
<awygle>
(and the more angry things like the proliferation of 3D graphics APIs make me)
<whitequark>
well, it's not quite exact opposite
<whitequark>
for example, posix looks like one thing, but isn't one thing, which is most of the problem with it
<awygle>
yeah maybe "regardless of how bad it is" is overstating it. but you get the idea
<whitequark>
monocultures are powerful in many ways
<whitequark>
which is why glasgow is aggressively vertically integrated
<awygle>
ugh yes, i am very annoyed by "standards" that are more exception than standard
<whitequark>
signal is a poster child simultaneously for and against the concept you are discussing
<whitequark>
it's a monoculture on purpose, which supposedly exists to give it the capability to be good,
<whitequark>
which i guess sort of makes sense
<whitequark>
but it's also aggressively horrible in every conceivable aspect
<awygle>
isn't signal closed-source tho? so it's a bit different because one can't make it better
<awygle>
in general my desire is for the flow to be "let's all get together on $BADTHING, so we stop half-reinventing it, and _then_ make it better"
<whitequark>
the client is open-source
<awygle>
but that's admittedly wishful thinking
<whitequark>
but the company behind it will harass you if you try to make your own client basically
<whitequark>
because they want to control the client too
<awygle>
bleh
<awygle>
well, in conclusion, thanks for writing good warnings, and also good job on smoltcp :P
<whitequark>
and like, the server isn't closed source to be proprietary
<awygle>
i'ma go eat lunch
<whitequark>
the server is closed source because moxie considers federation harmful
<whitequark>
or third party networks etc
<whitequark>
"only we can ship crypto that's correct" this kind of thinking
<whitequark>
meanwhile their desktop app is an electron piece of shit full of XSS
<whitequark>
or used to be full of XSS, anyway, i think they started sanitizing untrusted input
<cr1901_modern>
moxie is a control freak
<cr1901_modern>
there I said it
<whitequark>
world's worst anarchist
<whitequark>
a lot of this would be forgivable if signal actually worked. unfortunately, it does not
<cr1901_modern>
I'm not gonna pretend that I don't understand the temptation though.
<whitequark>
when i want to talk to someone, i have a choice between forcing them to use signal or just going to telegram
<cr1901_modern>
Nice use of "vertically integrated" to describe Glasgow, btw
<whitequark>
cr1901_modern: that's the whole concept behind it
<whitequark>
it looks like NIH syndrome, and you could call it that to some extent, but really the gains are quite significant
<whitequark>
and the downsides, too
<cr1901_modern>
Sure, but I couldn't pull that concise description from the aether
<whitequark>
spend more time on twitter
<whitequark>
it's good for this kinda thing and bad for everything else
<ZirconiumX>
I think that's the only time somebody's ever recommended spending more time on Twitter
* cr1901_modern
should be spending less time, not more...
<whitequark>
i find twitter pretty helpful overall
<ZirconiumX>
I haven't reached that point yet
<whitequark>
the main problem is that if you have a lot of follwers, the small % of fuckwits among them can ruin your (and your friends') day big time. so you have to express yourself very clearly, and then block everyone who doesn't use their brain
<cr1901_modern>
something something leon tweet something
<cr1901_modern>
leyawn*
<ZirconiumX>
I don't even know how big my block list is
<ZirconiumX>
I basically started by mass-blocking everyone who follows Glinner and went from there
<awygle>
Twitter is the only social media that has any appeal to me
<awygle>
But yeah block early block often. And I have barely any followers and a ton of privilege
<ZirconiumX>
I do feel like I have too big a digital footprint as @ZirconiumX though
<ZirconiumX>
Often in moments of despair I think about burning my Twitter account to the ground and using my alt as my main @
<ZirconiumX>
Decided to compromise by giving my tweets a six-month timespan
<Vinalon>
Has it gotten any better in the past few years, or has the filtering just improved? I haven't looked into social media since quitting everything years ago...
<_whitenotifier-3>
[nmigen] WRansohoff opened issue #343: Provide a way to add a reset Signal() to default clock domains - https://git.io/Jv7k3
<ZirconiumX>
...Isn't this just ResetInserter?
<Degi>
I mean there's mastodon too heh
<Vinalon>
Maybe - that name does sound like what I'm looking for
<whitequark>
Vinalon: filtering? I don't use that at all, twitter's idea of what i want to see is not aligned with mine one bit
<Vinalon>
I dunno, it always felt like a firehose with bad signal:noise that I couldn't keep up with
<Vinalon>
Also, is there a reason I'd be getting "ERROR: Max frequency for clock 'clk': 11.71 MHz (FAIL at 12.00 MHz)" when I'm using a 6MHz clock signal?
<ZirconiumX>
Which chip?
<ZirconiumX>
Main reason I ask is that 12MHz is the nextpnr default frequency for iCE40
<Vinalon>
And thanks - how do you create a valid '_ControlInserter' statement?
<whitequark>
Vinalon: i unfollow people who tweet too much. you can also disable retweets or mute. but it boils down to "you can be friends with people you don't follow"
<whitequark>
Vinalon: _ControlInserter is internal, what do you actually want to do?
<Vinalon>
UP5K - it might have something to do with the way it sets up the internal oscillator
<whitequark>
i think you need to add a clock constraint for HFOSC manually on UP5K
<whitequark>
or rather, the platform code should be doing this for you, but doesn't
<ZirconiumX>
ResetInserter(something)(module) is my educated guess.
<Vinalon>
I reported it in #343 - insert a reset signal to an existing clock.
<whitequark>
hmm
<whitequark>
or perhaps nextpnr
<whitequark>
Vinalon: ahhh yeah, you can put all of your code in some other module, and wrap it in ResetInserter(your_reset)
<Vinalon>
yeah, the error comes from nextpnr; I wonder where it gets the clock frequency from
<whitequark>
12 MHz is the default if nothing else is specified, I think
<whitequark>
like ZirconiumX said
<_whitenotifier-3>
[nmigen] whitequark commented on issue #343: Provide a way to add a reset Signal() to default clock domains - https://git.io/Jv7kd
<_whitenotifier-3>
[nmigen] WRansohoff commented on issue #343: Provide a way to add a reset Signal() to default clock domains - https://git.io/Jv7kN
<_whitenotifier-3>
[nmigen] WRansohoff closed issue #343: Provide a way to add a reset Signal() to default clock domains - https://git.io/Jv7k3
<Vinalon>
Ha, I like the idea of separating 'social media' and 'social life'. I wonder why it's so natural to think of those things as inseparable.
<Vinalon>
so...how would I go about hinting to nextpnr that the clock signal should be N Hz? Or can I tell it to treat that constraint as a warning?
<MadHacker>
I have a number of close friends in real life I absolutely will not follow on twitter.
<MadHacker>
I think a lot of people take some sort of facebook obligatory-friendsness approach to twitter and there's no need.
<whitequark>
Vinalon: well, two things
<whitequark>
you can use `platform.add_clock_constraint(ClockSignal(), 48e6)` to apply a 48 MHz constraint for example
<whitequark>
(which should really be done by nextpnr I think)
<Vinalon>
so...how would I go about hinting to nextpnr that the clock signal should be N Hz? Or can I tell it to treat that constraint as a warning?
<Vinalon>
sorry...hit up, enter
<whitequark>
the constraint is in fact a warning
<whitequark>
wait
<whitequark>
it used to be, now it isn't
<whitequark>
which is good, but you can use --timing-allow-fail to turn it into a warning
<Vinalon>
hm...'platform.add_clock_constraint( ClockSignal("sync"), platform.default_clk_constraint() )' results in "TypeError: 'Clock' object is not callable"
<whitequark>
hm
<whitequark>
`platform.default_clk_constraint` (no parens)
<whitequark>
but i doubt that will work
<whitequark>
since it, well, by definition applies the default constraint in nmigen
<whitequark>
(the platform does)
<Vinalon>
'--timing-allow-fail' seems to work (and so does the resulting program), but it might not be the most ideal long-term solution
<whitequark>
please file an MCVE and i'll take a closer look at it
<whitequark>
it really should just work out of the box
<Vinalon>
yeah, without the parens it says "TypeError: Object (clk sync) is not a Signal"
<daveshah>
Let me fix this on the nextpnr side, nextpnr-ecp5 auto-inserts constraints for oscs, so ice40 should too
<Vinalon>
ooh, that'd be nice - thanks! Should I hold off on making an nmigen issue, then?
<daveshah>
yeah, I'll do the nextpnr side now
<whitequark>
Vinalon: oh, the type error is a different issue
<daveshah>
OK, nextpnr should be creating these constraints now
<cr1901_modern>
Ty miek and pdp7 for bringing this to my attention. Fixed.
<Vinalon>
huh - it does seem to work if I call `self.add_clock_constraint( clk_i, 6e6 )` at the end of the 'create_missing_domain' platform method. ('default_clk_constraint' returns a Clock rather than a number)
<Vinalon>
but I guess that might not be necessary now - thanks!
<whitequark>
cr1901_modern: the current stability policy is as follows: if your code works at version 0.X without warnings, it will surely work on 0.X+1
<whitequark>
Vinalon: you could use `default_clk_frequency`
<whitequark>
but yes
<cr1901_modern>
What about max being removed? I don't recall any warnings around that when I first wrote these examples (that doesn't mean much tho).
<whitequark>
I -think- that was before 0.1
<cr1901_modern>
ahh
<whitequark>
and I -think- there was a warning
<whitequark>
ah, wat
<whitequark>
*wait
<whitequark>
one issue with Python is that it stopped showing warnings by default in some cases
<whitequark>
which we'll need to address
<whitequark>
you might hve hit that
<cr1901_modern>
Ahh, I see.
<cr1901_modern>
/me will check now
<cr1901_modern>
... after I check out the source (huh, I never installed nmigen on the new hard drive it seems ._.)
<Vinalon>
ah, 'self.default_clk_frequency' works too; thanks. Would that be a helpful change, or is it moot now that nextpnr can figure it out?
<whitequark>
what would be, specifically?
<Vinalon>
`self.add_clock_constraint( clk_i, self.default_clk_frequency )` at the end of 'create_missing_domain(...)'. But that probably wouldn't be robust enough for designs with multiple clocks, would it?
<whitequark>
ok, so, that's already done elsewhere if you use a resouce that has a Clock() in it
<whitequark>
but that doesn't work for internal oscillators because the assumption is that the toolchain knows it already
<whitequark>
in other words, the answer is no, nextpnr is supposed (and wwas supposed) to do it
<Vinalon>
cool, thanks for the context
<cr1901_modern>
Hrm I can't seem to install nmigen for some reason... seeing if I can figure it out myself and if not I'll open a PR
<cr1901_modern>
I can install other packages just fine
<whitequark>
oh, you're using *msys*.
<cr1901_modern>
yes
<whitequark>
that'll be a pull request to setuptools_scm then
<whitequark>
in principle the only windows configuration i consider supported is using it natively
<whitequark>
i've never really considered msys a viable platform. you're about the only person i know using it
<whitequark>
we... could in theory support it, but if it needs changes to nmigen, it'll also need changes to nmigen-boards, nmigen-soc and nmigen-stdio
<cr1901_modern>
It has been relatively well-behaved since I started using migen period
<cr1901_modern>
But I also have e.g. GNU ABI Rust installed, OCaml, so switching isn't convenient
<cr1901_modern>
Anyways, can I dummy out the check locally as a temp workaround?
<whitequark>
the version of the package will be wrong then
<whitequark>
but yeah
<whitequark>
just make sure no one relies on the version embedded in build artifacts
<ZirconiumX>
whitequark: what about WSL? It seems to behave nicely here
<ZirconiumX>
I suppose WSL2 is for all intents Linux, so
<cr1901_modern>
WSL isn't native binaries
<cr1901_modern>
I don't think
<ZirconiumX>
They're Linux binaries
<cr1901_modern>
I already know the problem/how to fix it ("git rev-parse --show-toplevel" only returns Unix-style paths. Use cygpath or something to convert). I'll open an issue upstream for further input.
<whitequark>
it's kind of like when people ask me to support software that has a native Linux port built under wine
<whitequark>
yes, i know wine is more convenient *for you*. that's not necessarily a reason *for me* to spend effort on it
<ZirconiumX>
Okay
<whitequark>
(that was responding to cr1901_modern, not ZirconiumX)
<whitequark>
(WSL is fine precisely because it *is* Linux)
<cr1901_modern>
Someone is building native Linux software under Wine ._.?
<whitequark>
er, I've explained that badly
<whitequark>
someone runs native Linux software's Windows port under wine
<whitequark>
that was before snap and flatpak became prevalent, and said person did not want to spend the effort necessary to build it on their ancient system
<cr1901_modern>
Inertia sucks and I sincerely wish I didn't have that problem.
<whitequark>
i understand that you really like Windows, which frakly is fine and first class Windows support is something I try to do in my software
<whitequark>
but... msys2 is very much second class on Windows, almost by definition
<Sarayan>
Do you need msys2 for nmigen? I'd have thought "native" python was enough
<whitequark>
yes, it should be
<whitequark>
since I cut out bitarray at least
<cr1901_modern>
Oh I'm sure it works fine on native python. I'd like to avoid stressing myself out by having to maintain two separate python installations at once. One can (reasonably!) argue it was a mistake to use the msys2 python.
<cr1901_modern>
I still need gcc for stuff that uses autoconf (openocd)
<whitequark>
the problem is actually yosys
<whitequark>
which I think you need msys2 to build
<cr1901_modern>
there's a visual studio build
<whitequark>
ah
<cr1901_modern>
but if you want to support plugins, tcl, etc
<cr1901_modern>
you need to do an msys build
<awygle>
you can also build it in cygwin
<awygle>
just to add fuel to the fire
<cr1901_modern>
cygwin is far less native than msys is
<awygle>
oh i know lol
<whitequark>
i wish i could back in time to destroy cygwin somehow
* awygle
uses cygwin every day
<whitequark>
i'm not entirely serious but
<_whitenotifier-3>
[nmigen] WRansohoff commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/Jv7qC
<_whitenotifier-3>
[nmigen] whitequark commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/Jv7qg
<_whitenotifier-3>
[nmigen] WRansohoff commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/Jv7qV
<Vinalon>
I always feel like saying something like, 'sorry for your loss' when people need to use third-party Windows shells. I still have bad dreams about the forked msys2 that used to be required for Windows ESP32 development
<cr1901_modern>
Would be a little different if autoconf didn't cling so hardly to posix
<_whitenotifier-3>
[nmigen] whitequark commented on issue #341: nMigen should avoid emitting very large wires that cause issues in Yosys - https://git.io/Jv7qP
<Vinalon>
At least WSL is starting to get good. But good luck!
<whitequark>
autoconf doing that is why I use cmake so much
<whitequark>
even though cmake is a blight and a plague on software development
<whitequark>
at least cmake doesn't penalize non-*nix developers so much
<whitequark>
makes everyone equally miserable :)
<cr1901_modern>
indeed... anyways the whole setuptools_scm thing is giving me a headache, and I'm drained now. I'll fix it later
<cr1901_modern>
There very well might've been a warning before max was removed
<cr1901_modern>
I checked out the commit _just_ before it was removed to test
<Vinalon>
I wish that CMake was better supported in embedded development...wouldn't it be great if you could target IDEs like Keil as easily as MSVC/Eclipse/etc?