<cr1901_modern>
ZipCPU: You are seriously taking all my blog posts ._. I _also_ wanted to do a post on how to do an async FIFO but there's no point after your CDC article lol
<ZipCPU>
:ROTFL:
<cr1901_modern>
The EETimes article on CDCs is the most referenced article on the entire site- and for good reason. But it doesn't talk about how to implement a FIFO between clock domain crossings nor why it works,
<cr1901_modern>
nor potential pitfalls (such as not using a gray code on the current index to read/write)
<cr1901_modern>
Just says "use your vendor-provided FIFO -_-"
<ZipCPU>
Did you see that comment on reddit?
<ZipCPU>
Or was that from the EETimes article?
<cr1901_modern>
Idk... I don't use reddit :P
<cr1901_modern>
Oh, "use your vendor FIFO" is embedded somewhere in the EETimes article IIRC
<ZipCPU>
You'll find a link there to the CDC article, with 14 fascinating comments.
<cr1901_modern>
"and place and route tools need to know how long of a propagation delay is acceptable" I'm not sure how you can calculate an acceptable prop delay when clocks are not in phase...
<cr1901_modern>
or rather "phase relationship is unknown*"
<ZipCPU>
Heheh yeah, exactly, but they did present the solution, IIRC
<ZipCPU>
The basic solution is to state that, from the old clock FF to the new clock FF a delay of X is acceptable.
<ZipCPU>
Usually X is one over the period of the ... new clock or old clock? I can never remember. I'd just take the period of the faster clock.
<cr1901_modern>
Idk what a false path is, tbh
<cr1901_modern>
(or I used to but forgot
<ZipCPU>
Yeah ... I'm going to have to look up that term myself.
<ZipCPU>
Keep reading to the end, though, they got into the solution I was familiar with.
<cr1901_modern>
"95% of the time the correct solution is to set a max delay from the source clock domain to the destination clock domain of slightly less than one source clock period."
<ZipCPU>
Yeah, that comment.
<cr1901_modern>
ZipCPU: So this is a stupid q (and I'm a bit too tired to read the blog post), but what actually _does_ happen if prop delay is longer than one source clk in a clk domain crossing? >>
<cr1901_modern>
Allow me to explain my thought process
<cr1901_modern>
If you go the multiFIFO/gray-counter route, there's no way to guarantee if your source value, upon being generated after the edge of the src clk, will reach the dest domain >>
<cr1901_modern>
errr, let me start over, sorry
<cr1901_modern>
let's consider a 1-bit 2-FIFO signal to cross a clock domain.
<ZipCPU>
Really? "no way to guarantee if your source value ... will reach the dest domain"??
<cr1901_modern>
ZipCPU: Hence I started over :P
<cr1901_modern>
I was rambling/not making sense. I know what I want to say at least
<ZipCPU>
Well ... that's good ... it's getting late here too.
<cr1901_modern>
When your new value reaches the first of the 2-FIFOs to cross a clock domain, there's no guarantee whether the output of the first FIFO will reflect the old or new value _after_ the first tick of the dest clk.
<cr1901_modern>
Ditto with the second FIFO's output. It depends how close to the edge of the dest clk your new value was when it reached the 2-FIFO
<cr1901_modern>
makes sense, right?
<ZipCPU>
Are you sure you want to talk about 2-FIFOs, and not two FF's?
<cr1901_modern>
Yes, I meant 2-FFs
<ZipCPU>
I'm not sure I'd understand why you'd cascade FIFO's together ...
* cr1901_modern
is really not in the frame of mind to ask this q, but needs to minddump before he forgets
<ZipCPU>
Ok, now it makes sense ...
<cr1901_modern>
I meant 2-FFs*
<cr1901_modern>
Because you can't control when the new value reaches the 2-FF, there is some uncertainty from when your new value was generated in the src domain
<cr1901_modern>
until the dest domain actually _sees_ the new value
<ZipCPU>
Yes. Go on.
<cr1901_modern>
So I don't understand how you can promise that that a new value will be in the dest domain within one period of the src clk
<cr1901_modern>
b/c depending on the dst clk's phase, the 2-FF may settle on the old value for an extra cycle
<cr1901_modern>
extra cycle* of the dst clk
<cr1901_modern>
Does this q make sense?
<ZipCPU>
Ahh ... you mean the timing specification thing?
<cr1901_modern>
yes
<ZipCPU>
You can't guarantee that. That's not the point.
<ZipCPU>
The point is to keep the P&R from routing your wire all over the chip with an unreasonable timing delay.
<ZipCPU>
You don't want further time delays added to the signal.
<cr1901_modern>
Oh, so its a fail-safe essentially so the P&R doesn't do something stupid?
<ZipCPU>
As I understand things ... yes.
<ZipCPU>
It's also to simplify the job of the timing analyzer, proving that P&R continued to maintain timing relationships.
<cr1901_modern>
Okay that makes more sense
<ZipCPU>
It's sort of an arbitrary time relationship, but it makes the timing tool shut up.
<cr1901_modern>
I wonder why it's "slightly less than one clock period", as opposed to one clock period
<ZipCPU>
Not sure.
<cr1901_modern>
ZipCPU (Okay so I lied and I _do_ actually have a reddit acct I don't use) I might actually have to comment tomorrow if I can't think of a good answer
* cr1901_modern
plays a videogame to unwind from meatspace
<ZipCPU>
ZipCPU feels like a clock, which just enough winding left in him to crawl into bed ...
digshadow has quit [Ping timeout: 246 seconds]
leviathanch has joined #yosys
Brando753-o_O_o has quit [Quit: o_O_o]
_whitelogger has joined #yosys
m_t has joined #yosys
digshadow has joined #yosys
nrossi has joined #yosys
digshadow has quit [Ping timeout: 240 seconds]
eduardo_ has joined #yosys
eduardo has quit [Ping timeout: 260 seconds]
aw- has joined #yosys
leviathanch has quit [Remote host closed the connection]
m_t has quit [Quit: Leaving]
oldtopman has quit [Ping timeout: 258 seconds]
oldtopman has joined #yosys
_whitelogger has joined #yosys
aw- has quit [Quit: Leaving.]
gnufan has joined #yosys
proteusguy has quit [Remote host closed the connection]
leviathanch has joined #yosys
m_t has joined #yosys
m_t has quit [Quit: Leaving]
nrossi has quit [Quit: Connection closed for inactivity]
gnufan1 has joined #yosys
gnufan has quit [Ping timeout: 248 seconds]
dys has joined #yosys
aynah[m] has quit [Ping timeout: 246 seconds]
pointfree1 has quit [Ping timeout: 240 seconds]
jayaura has quit [Ping timeout: 246 seconds]
swick has quit [Ping timeout: 248 seconds]
lok[m] has quit [Ping timeout: 276 seconds]
marbler has quit [Ping timeout: 252 seconds]
digshadow has joined #yosys
brandonz has quit [Quit: bbl]
brandonz has joined #yosys
MatrixTraveler[m has joined #yosys
leviathanch has quit [Remote host closed the connection]
Guest62224 has joined #yosys
swick has joined #yosys
lok[m] has joined #yosys
pointfree1 has joined #yosys
marbler has joined #yosys
aynah[m] has joined #yosys
gnufan1 has quit [Quit: Leaving.]
danieljabailey has quit [Quit: ZNC 1.6.4+deb1 - http://znc.in]