Migen question: I need some unique identifier for the clock domain that a module will end up being clocked by. How should I do this? Things I've tried:
jryans has joined #litex
sajattack[m] has joined #litex
shoragan[m] has joined #litex
dcallagh has joined #litex
CarlosEDP has joined #litex
david-sawatzke[m has joined #litex
DerekKozel[m] has joined #litex
vomoniyi[m] has joined #litex
leons has joined #litex
promach[m] has joined #litex
Las[m] has joined #litex
jevinskie[m] has joined #litex
bluecmd has joined #litex
- Ask the module to keep hold of it as self.clk or whatever. This does not work because strings like 'sys' are not unique until .finalize() is finished.
willcode4[m] has joined #litex
Crofton[m] has joined #litex
(and in fact 'sys' might get renamed for a variety of reasons, so...)
amstan has joined #litex
a3f has joined #litex
nrossi[m] has joined #litex
CarlFK has joined #litex
- Have a ClockSignal() in the module in question. ClockSignal's self.clk *will* be updated by the visitor when ClockDomainsRenamer walks the tree. This is better, because now I can get the real clock domain from the module after .finalize()
but, this still doesn't work because eventually the module doing the walking (via xdir()) must also be a submodule, and *its siblings* will not be finalized by the time the walker's do_finalize() is running, so the same caveat about 'sys' not being the real clock domain still applies
So, what to do? The ultimate goal is to learn which clock each module is using so I can connect it to the appropriately-clocked bus
(Also, is this easier in nMigen?)
Degi_ has joined #litex
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
thirtythreeforty has quit [Ping timeout: 252 seconds]
thirtythreeforty has joined #litex
rlittl01 has joined #litex
thirtythreeforty has quit [Ping timeout: 260 seconds]
rlittl01 has quit [Remote host closed the connection]
thirtythreeforty: I'm not sure to understand correctly your question, but for this, I would probably do the opposite: Have a clock domain in the submodule, expose it and clock the logic with this clock domain. Then at the top, connect the clocks of each submodule. In fact in a way very similar to traditional (S) Verilog/VHDL designs.
thirtythreeforty: if this is not answering your question, can you create an issue in LiteX to discuss this and share minimal code of what you are trying to do?
Coldberg has quit [Ping timeout: 260 seconds]
_whitelogger has joined #litex
_franck_ has quit [Read error: Connection reset by peer]
Yeah this one seems fairly intrusive. Changed repo URL, changed default branch, changed folder structure
_florent_: Or possibly not ... works even without --loopback which it should definitely not ...
Should litex_setup support different branches? Seems to be master only atm
Took all of 10 seconds. clone="recursive",branch="main") but unsure if breaking some convention if everything else uses master
str1 has quit [Quit: WeeChat 2.3]
mtretter has quit [Remote host closed the connection]
Python package is also amaranth-yosys now, broke ci. How rude
andresmanelli has joined #litex
andresmanelli has quit [Client Quit]
zjason` is now known as zjason
So looks like the "tx freq is at 122.88" (the measured one in the pastebin above is bad because of measurement imprecision since litex_server is remote though vpn and forwarded ports etc ...).
and the rx freq is actually 0 ...
So that's obviously not good.
FabM has quit [Quit: Leaving]
Any clue how to debug ?
whitequark has joined #litex
hey folks, I know the nMigen to Amaranth name change was going to break a few things
I'd be happy to assist in fixing the breakage
cc: paultech, I posted the log into #amaranth-lang with your msgs highlighted. I have no idea why CI broke
but I have some symlinks and program settings that depend on the old nmigen name, and I'd rather wait to break those settings until litex has handled the name change
cr1901, whitequark, Don't think anything is broken on litex side yet. The setup script broke due to lack of a master branch but since remaining packages are still available I believe litex CI will build (apart from the previously mentioned failure with the setup script)
Will leave that to _florent_to test out
Hi whitequark, thanks for letting us know, nice new name! The breakage should be limited and easy to fix for LiteX. I'll have a closer look in the next days.
tnt: the first thing to look at is the TX/RX initialization, the TX/RX freqs
tnt: so maybe you could add LiteScope and verify the TX/RX initialization FSM
The TX freq looks fine. RX freq is zero. rx_ready stays at 0. I'm digging into the RX init fsm right now.
I've never used litescope actually, no idea how that works.