<_whitenotifier-f>
[nmigen/nmigen] github-actions[bot] pushed 1 commit to gh-pages [+0/-0/±13] https://git.io/Jk3d7
<_whitenotifier-f>
[nmigen/nmigen] whitequark 70392c6 - Deploying to gh-pages from @ 44318149e00ccce6e63ba39361daff7ecc505bbe 🚀
chipmuenk has joined #nmigen
jjeanthom has joined #nmigen
jeanthom has quit [Read error: Connection reset by peer]
Asu has quit [Remote host closed the connection]
Asu has joined #nmigen
emeb_mac has joined #nmigen
<d1b2>
<TiltMeSenpai> how do I rename sync for the current module
<d1b2>
<TiltMeSenpai> wait maybe I figured it out
<d1b2>
<TiltMeSenpai> or at least I have a different error now
<d1b2>
<TiltMeSenpai> nope, did not figure it out
<awygle>
TiltMeSenpai: what do you mean exactly? typically you use sync in the module itself and use DomainRenamer to change it when you instantiate the module at a higher level
<d1b2>
<TiltMeSenpai> yeah, I sort of want to not do that
<d1b2>
<TiltMeSenpai> context is a usb serial design with LUNA, the pipe runs at 12mhz but I keep getting bugs bc I'm accidentally sticking pipe logic in the 48mhz domain
chipmuenk has quit [Ping timeout: 260 seconds]
<awygle>
you can create another clock domain and use it if you want
<awygle>
i think it's something like m.d['new'] = ClockDomain()?
<awygle>
and then m.d.new += [stuff]
<awygle>
I think I mostly don't understand what you have and what you want
<d1b2>
<TiltMeSenpai> there's already m.d.usb, where everything that interacts with the pipe should live, but I want to use m.d.sync as m.d.usb
<d1b2>
<TiltMeSenpai> bc I have modules where all the logic should be m.d.usb, and the original m.d.sync should never be used
chipmuenk has joined #nmigen
<whitequark>
you need DomainRenamer, I think
<_whitenotifier-f>
[nmigen-boards] AsuMagic opened issue #122: Defining adv7513 resource for a new board with subsignals different from DE10-Nano - https://git.io/JksBo
<d1b2>
<TiltMeSenpai> so the only way is to have the caller use DomainRenamer?
<d1b2>
<TiltMeSenpai> I'd ideally like to avoid that, but that is a solution
<vup>
@TiltMeSenpai you can also use m.d.usb directly instead of m.d.sync
<whitequark>
why do you want to avoid that? that might make it easier to come up with a satisfying solution
<d1b2>
<TiltMeSenpai> debugging the domain issues wasn't exactly a fun process, I'd like to avoid "You must use DomainRenamer on this submodule before using it, otherwise strange bugs happen" as a contract if possible
<d1b2>
<TiltMeSenpai> I guess explicitly using m.d.usb instead of m.d.sync is possibly the best option, I just have to actually remember to do that
<vup>
well the other option is to just return DomainRenamer("usb")(m) instead of just m in the end
<Sarayan>
How do FFs in fpga work? Specifically, clocks have a delay in reaching the ffs, so how come their inputs are not already transiting when the edge happens? It's just that relatively the logic is slow enough?
<d1b2>
<TiltMeSenpai> ah, renaming it at the end would definitely work
<whitequark>
Sarayan: the job of a PNR tool is to lay out the clocks and the data paths so that the hazard you described doesn't happen
<whitequark>
clocks generally use global distribution networks that are much faster than normal routing or LUTs
<daveshah>
And, importantly, a tree structure so the delay at any location is roughly the same
<daveshah>
In many FPGAs the worst case clock skew plus hold requirement is less than the clock to out plus minimum route time, so if global routing is used the PnR tool doesn't even need to do anything special
<daveshah>
Fancier FPGAs (notably UltraScale+) have programmable delays in the clock tree structure to ensure no skew regardless of where the clock comes from, as they have multiple clock roots
<cesar[m]>
The input of one FF is likely derived from the output of another. So, even if the delay from the clock pins to the FF itself is large, internally you only have the skew to worry about.
<daveshah>
Yep indeed
<daveshah>
Occasionally there are edge cases in some arches, like crossing clock regions or routing to special cases like IOLOGIC - but still this is down to the PnR tool to deal with by adding some extra delay
<daveshah>
eg by adding a route through LUT to the offending signal
<Sarayan>
interesting
<Sarayan>
I guess the same holds for enable signals in dffe
<Sarayan>
which, at least on the cyclonev, don't go through the clock network
ademski has joined #nmigen
<daveshah>
No, enable signals have essentially the same constraints as data ones
<daveshah>
They need to meet setup and hold constraints relative to the clock just like data signals
<daveshah>
There is no need for enable signals to be any lower skew than data, although using global networks for them is done solely to reduce general routing congestion
<Sarayan>
yeah, "the same holds" as in the low-skew clock ensures everything is stable at the right time