<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 2/16/2016 12:33 PM, Magnus Karlsson
wrote:<br>
</div>
<blockquote cite="mid:56C387AB.3080906@saanlima.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">On 2/16/2016 11:37 AM, Walter
Gallegos wrote:<br>
</div>
<blockquote cite="mid:56C37A96.7010801@waltergallegos.com"
type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
Magnus<br>
<br>
"This logic signal <i>clk</i> is then connected to a clock
buffer BUFG that will feed one of the global clock nets"<br>
<br>
My apologies, clk routing is : <br>
<br>
The logic clk signal -using general propose routing lines and
connection matrix- is connected to a clock buffer to be able to
be connected to FF edge detectors. This is the only way that the
tool can address the HDL definition.<br>
<br>
So, RISC5 use general propose resources to routing a clock
signal. <br>
<br>
Walter.<br>
<br>
</blockquote>
<br>
There is absolutely nothing wrong with generating a clock signal
like this. <br>
Yes, the output from the flip-flop is routed using general routing
resources, there is no other option. But after it's sent through
the BUFG it's a perfectly legit clock signal.<br>
<br>
I have created a small project to demonstrate this, it's available
on GitHub and it will only take ISE a few seconds to generated a
bit file. <br>
<b>ISE will go through this project without a single warning being
generated.</b> Anyone with ISE experience will tell you that it
will generate warning for every little detail it will find
questionable.<br>
<br>
The project is available here: <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/Saanlima/Pepino/tree/master/Projects/Pepino_clktest">https://github.com/Saanlima/Pepino/tree/master/Projects/Pepino_clktest</a><br>
<br>
Magnus<br>
</blockquote>
<br>
This can of course also be done using dedicated clocking resources
like a DCM or a PLL instead of just a simple flip-flip, and I guess
Paul Reed is the correct person to defend why it was done like this
but I have a pretty good hunch why. <br>
<br>
The SRAM interface is asynchronous in nature and care must be taken
so that the timing of the write signal is such that it prevents
accidental writes to other memory locations during a write cycle.
If all the signals controlling the SRAM (like address, chip enable,
read, write, and output enable) are generated synchronously using
the CPU clock then the timing of the write signal relative to the
other control signals are uncertain and can vary depending on the
routing of the chip. By gating the write signal with the "early"
version of the clk signal (i.e. the clk version of the signal, not
the clk_BUFG version) which is guaranteed to lead the clk_BUFG
signal by the delay caused by the buffer, then the write signal to
the memory is guaranteed to be removed before the other signals can
change. If the clk signal is generated by a DCM or a PLL then this
early version of the clk signal is not available like Walter pointed
out and the write timing must be controlled by some other mechanism,
like a state machine clocked at say 2x or 4x the CPU clock.<br>
<br>
Magnus<br>
</body>
</html>