Hi Jason,
On 02/21/2012 03:24 AM, Jason Zheng wrote:
Hi,
I wasn't sure if this is the right channel to provide feedback, but
since your e-mail addresses are in the header of the file and the
opencores's forum is too disorganized I am sending this comment
directly to the authors.
we have mailing lists that are more suited than the forums for this kind
of communication, I have put them in CC.
I very much appreciate all the efforts that have been put behind the
openrisc project and I am currently experimenting with it on an Atlys
board. After my firrst synthesis/par run I noticed a lot of timing
errors in the static timing report. After examining the report and
comparing to the RTL files I came to the conclusion that there is a
clock-domain crossing issue in the xilinx_ddr2_if.v:
The signal ddr2_calib_done signal comes from the ddr2 clock domain,
while wb_req is treating it as if it came from wb_clk domain. As a
result the timing analysis tool assumed a worst case scenario of 5ns
between the two domains and the results were miserable.
While we can argue that this is a multi-cycle path, the fact is that
ddr2_calib_done feeds into multiple logic sinks and can potentially
cause meta-stability issue in the design. My solution was to add a
2-clock meta-stability filter to address both the timing problems and
the meta-stability concern:
That sounds like a good idea.
reg [1:0] ddr2_calib_done_z;
always @ (posedge wb_clk)
ddr2_calib_done_z[1:0]<= {ddr2_calib_done, ddr2_calib_done_z[1]};
then replace ddr2_calib_done in the wb_req assignment with ddr2_calib_done_z[0]
Please use _r to describe a registered signal, to keep it consistent with the
current code.
Please let me know if you can incorporate this change to the svn
repository. Thanks.
While I agree with the change and it would be easy change to just drop in,
the preferred workflow is to have patches posted to the mailinglist(s).
So, If you could post a patch to the addresses I put in the CC field,
it would be great.
Stefan
_______________________________________________
OpenRISC mailing list
[email protected]
http://lists.openrisc.net/listinfo/openrisc
