<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">No, those are not clocks. A clock
signal is a signal that is used in a <i>always @(posedge clk)</i>
statement or directly connected to the clock input of a clocked
element (like flip-flops and BRAM etc.).<br>
In the RS232 code the clocked elements are all clocked using the
25 MHz clock but the clock is only acted upon when the baud-rate
counter indicates that it's time to shift out the next bit. This
is how you typically create a slower "clock" in a synchronous
system - you clock all sequential elements with the same clock but
only enable the slower running elements when it's time to act on
the clock.<br>
<br>
Magnus<br>
<br>
On 2/27/2016 6:29 AM, Jörg Straube wrote:<br>
</div>
<blockquote cite="mid:18D0AEB0-01FC-43C3-AF9E-8E0DE8952FF5@iaeth.ch"
type="cite">
<pre wrap="">Walter
Magnus rewrote the clock generation according to your recommendation to use DCMs for clock generation and not general logic circuitery.
One question as I'm not at all an expert with clocks: If I look at the FPGA sources of the RS232 drivers, I still find the method that the clock to drive the RS232 is generated by dividing the clk with "normal" circuitery.
Would that be okay for you? Or in other words: why might it be okay there but not for SRAM access?
br
Jörg
</pre>
<blockquote type="cite">
<pre wrap="">Am 26.02.2016 um 18:59 schrieb Magnus Karlsson <a class="moz-txt-link-rfc2396E" href="mailto:magnus@saanlima.com"><magnus@saanlima.com></a>:
One outcome of the discussion about the Oberon RISC5 verilog code is that I did a deeper study about the clock limits for the project and found that the RISC5 CPU in itself can be clocked at up to about 66 MHz but the external SRAM path is too slow for that speed (read is the problem). The asynchronous nature of the SRAM interface makes it hard to constrain the ISE compiler to work hard on this path.
I did trace the SRAM read data path and found that it takes about 10 ns from the SRAM data input pins to the Z register bit (this is the longest path). The address output path is about 5 nS and with a 10 nS SRAM access time the fastest system clock cycle should be around 25 nS.
To test this out I created a version of the code that runs the CPU at 37.5 MHz (26.666 nS) instead of 25 MHz, i.e. the CPU is running 1/2 the video clock rate instead of 1/3, and it seems to run fine of both the LX9 and the LX25 version of Pepino. All timing constants (UART Rx, UART Tx, SPI and millisecond timer) have been changed to reflect the 50% faster clock rate.
If anyone want to try it, the project (including bit files) is available here:
<a class="moz-txt-link-freetext" href="https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino_fast">https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino_fast</a>
Cheers,
Magnus
--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">--
<a class="moz-txt-link-abbreviated" href="mailto:Oberon@lists.inf.ethz.ch">Oberon@lists.inf.ethz.ch</a> mailing list for ETH Oberon and related systems
<a class="moz-txt-link-freetext" href="https://lists.inf.ethz.ch/mailman/listinfo/oberon">https://lists.inf.ethz.ch/mailman/listinfo/oberon</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>