Yes, and this should also work for distributed memory since the reads are asynchronous. You need to make sure that a given memory cell is written well before it's read. The sync blocks add so much latency that that's not a problem.
With TROZ, we had one weird problem with a non-sync fifo (all in the same clock domain) where we were trying to read a cell too soon after it was written, and there was some issue with that. I don't think we'll have that problem here, though. On 6/8/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Sometimes, the fpga have synchronous memory bloc with 2 clocks, one for > each port. > > nicO > > > I get the idea. This forces the data from domain 1 to sit still on > > the data_hold register for at least 2 clock1 periods before it's gated > > into > > out_data on clock2. That doesn't guarantee with perfect certainty that it > > will settle in time, but with any modern register the odds in favor are > > extreme. > > I think I did something like this in VHDL about 4 years ago. The > > memories are pretty hazy now, but I think I might have used clocked data > > registers, more gates, and fewer flip-flops. (There are still the > > handshake > > signals to add.) > > Seems like there should be a textbook solution to this. My second > > book on Verilog arrived yesterday, which concentrates on how to apply it > > rather than its syntax. I haven't been into it yet; I'm still reading up > > on > > the language itself. > > I guess the main problem this solves in OGP is that the dotclock > > can't synchronize to the host bus handshake, short of adding a complicated > > kind of phase-locked loop. Theoretically doable, I suppose, but > > cross-domain data buffering looks a lot easier to implement. > > > > > > > > On Tue, Jun 07, 2005 at 04:29:56PM -0400, Timothy Miller wrote: > >> The biggest problem with getting data between clock domains is > >> metastability. Metastability can occur where you try to latch a > >> signal at time when that signal is in transition. What we need is a > >> reliable means to ensure that one register's Q's are going to meet the > >> setup and hold time for another register's D's. To do this, we store > >> data (the payload) in a register in one clock domain and make sure we > >> hold it there unchanged long enough to ensure that we can reliably > >> store it into a register in the other domain. To ensure that payload > >> data is held long enough, we handshake between the two clock domains > >> by, essentially, passing a token back and forth, and when > >> metastability affects the token, the worst case is a slight additional > >> delay in passing the payload. > >> > >> > >> Here's a circuit diagram: > >> > >> http://opengraphics.gitk.com/sync.gif > >> > >> > >> And here's the source code: > >> > >> > >> > >> module sync( > >> in_clock, > >> in_data, > >> > >> out_reset, > >> out_clock, > >> out_data); > >> > >> parameter HIGHBIT = 7; > >> > >> input out_reset; > >> input in_clock, out_clock; > >> input [HIGHBIT:0] in_data; > >> output [HIGHBIT:0] out_data; > >> > >> reg flag_1, flag_2, flag_3, flag_4, flag_5; > >> reg [HIGHBIT:0] data_hold, out_data; > >> > >> always @(negedge in_clock) flag_1 <= !flag_5; > >> > >> always @(posedge in_clock) begin > >> if (!flag_2) data_hold <= in_data; > >> flag_2 <= flag_1; > >> end > >> > >> always @(negedge out_clock) begin > >> if (out_reset) begin > >> flag_4 <= 0; > >> end else begin > >> flag_4 <= flag_3; > >> end > >> end > >> > >> always @(posedge out_clock) begin > >> if (out_reset) begin > >> flag_3 <= 0; > >> flag_5 <= 1; > >> out_data <= 0; > >> end else begin > >> flag_3 <= flag_2; > >> flag_5 <= flag_4; > >> if (flag_4 & !flag_5) out_data <= data_hold; > >> end > >> end > >> > >> endmodule > >> > >> > >> > >> > >> > >> Note that the placement of the inverter is somewhat arbitrary. Since > >> inverters are usually free, we can do this. If the inverter were a > >> separate component, it would be better to put it between registers of > >> the same clock domain. > >> > >> _______________________________________________ > >> Open-graphics mailing list > >> [email protected] > >> http://lists.duskglow.com/mailman/listinfo/open-graphics > >> List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > _______________________________________________ > > Open-graphics mailing list > > [email protected] > > http://lists.duskglow.com/mailman/listinfo/open-graphics > > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > > > > > _______________________________________________ > Open-graphics mailing list > [email protected] > http://lists.duskglow.com/mailman/listinfo/open-graphics > List service provided by Duskglow Consulting, LLC (www.duskglow.com) > _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
