<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Magnus,<br>
<br>
<i>always @ (posedge CLK50M) clk <= ~clk;<br>
<br>
</i>This is also a bad practice. clk edge are not aligned with
CLK50M in a uncontrolled fashion. So, this is a kind of asynchronism
for the rest of FPGA.<br>
<br>
Walter<br>
<br>
<br>
<div class="moz-cite-prefix">El 2016-02-16 a las 15:14, Magnus
Karlsson escribió:<br>
</div>
<blockquote cite="mid:56C36723.2000101@saanlima.com" type="cite">
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
<div class="moz-cite-prefix">Walter, be careful here. The code
you list is specific to OberonStation, it does not look like
this on the original Digilent Spartan3 board nor on Pepino. <br>
This is the (somewhat messy) way OberonStation creates the 25
MHz CPU clock and the 75 MHz pixel clock for a 60 MHz input
clock.<br>
<br>
Both the Digilent board and Pepino uses a 50 MHz input clock and
the clock generation code is much simpler and looks like this:<br>
<br>
25 MHz CPU clock (clk) is created by dividing the input clock by
2:<br>
<i>always @ (posedge CLK50M) clk <= ~clk;</i><br>
<br>
75 MHz Pixel clock (pclk) is generated by multiplying the CPU
clock by 3 using a DCM:<br>
<i>DCM #(.CLKFX_MULTIPLY(3), .CLK_FEEDBACK("NONE"),
.CLKIN_PERIOD(40.000))</i><i><br>
</i><i> dcm(.CLKIN(clk), .CLKFB(1'b0), .RST(1'b0), .PSEN(1'b0),</i><i><br>
</i><i> .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0),
.CLKFX(pclk));</i><br>
<br>
<br>
Magnus<br>
<br>
<br>
<br>
On 2/16/2016 9:22 AM, Walter Gallegos wrote:<br>
</div>
<blockquote cite="mid:56C35ABD.6010900@waltergallegos.com"
type="cite">I've waited long time before post this topic because
could be misunderstood, believe me this is a positive post. Try
to address a methodology issue in RISC 5 implementation. <br>
<br>
The gold rule is "FPGA design must be synchronous". Have a clock
do not means synchronous. <br>
<br>
Building the hardware from Verilog description. <br>
<br>
DCM_SP #( .CLK_FEEDBACK("NONE"), .CLKDV_DIVIDE(2.0),
.CLKFX_DIVIDE(2), <br>
.CLKFX_MULTIPLY(5), .CLKIN_DIVIDE_BY_2("FALSE"), <br>
.CLKIN_PERIOD(16.667), .CLKOUT_PHASE_SHIFT("NONE"), <br>
.DESKEW_ADJUST("SYSTEM_SYNCHRONOUS"),
.DFS_FREQUENCY_MODE("LOW"), <br>
.DLL_FREQUENCY_MODE("LOW"), .DUTY_CYCLE_CORRECTION("TRUE"),
<br>
.FACTORY_JF(16'hC080), .PHASE_SHIFT(0),
.STARTUP_WAIT("FALSE") ) <br>
dcm ( .CLKIN(OSCIN), .CLKFX(clkfx), .CLKFB(1'b0), .RST(1'b0),
<br>
.DSSEN(1'b0), .PSCLK(1'b0), .PSEN(1'b0), .PSINCDEC(1'b0), <br>
.CLKDV(), .CLKFX180(), .CLK0(), .CLK2X(), .CLK2X180(), <br>
.CLK90(), .CLK180(), .CLK270(), .LOCKED(), .PSDONE(),
.STATUS()); <br>
<br>
This implement a DCM with OSCIN as input clock to generate
clkfx; for DCMs the XILINX recommend some period in reset with
CLKIN active and stable. Work yes, recommended no. Is also a
good practice rebuild the input clock with the DCM and not only
generate a new one. <br>
<br>
always @(posedge clkfx) begin <br>
clk0 <= ~clk0 & ~clk1; This implement a FF feeback
= not clk0 and not clk1. <br>
clk1 <= clk0; clk1 is also another FF
taking clk0 as data. <br>
pclk <= ~pclk; pclk is a FF feedback Q
in D <br>
end <br>
<br>
Please note, clk0, clk1 and pclk are not aligned, they are
different FF with different placement and routing. <br>
If used as clock, this one of the worst cases, edges are closed,
not the same, routed into uncontrolled skew general propose
routing resources, don't forget of metastability. <br>
<br>
Next, <br>
<br>
always @(posedge clk0) clk <= ~clk; <br>
<br>
"posedge" force the implementation tool to use the clock edge
detection available in each FPGA FF; so, this sentence force the
tool to connect a general purpose interconnection network as FF
output is to the clock distribution tree. <br>
<br>
And again a signal ( not a clock in the FPGA world ) is used as
clock. <br>
<br>
always @(posedge clk) <br>
.... <br>
end <br>
<br>
There are also another hidden problem, the RISC clock clk, that
was generated in the logic farm, is not aligned with clkfx by a
variable unknown delay. This delay depend of several factor as
temperature, power supply voltage and implementation run, that
means in two implementation runs of same code as the tool could
select different placement and routing could result in
different delays. <br>
<br>
The correct way to handle clock is with a clock manager; I
strong recommend avoid clock dividers in logic. The challenge is
select a correct oscillator and/or the appropriate multiply
divide parameters. <br>
<br>
And after correct this problems don't forget to modify : <br>
<br>
assign SRwe0 = ~wr | clk, SRwe1 = SRwe0; <br>
<br>
Here clk is used as signal, so if clk is a clock must not be
connected to a LUT input. <br>
<br>
Regards, <br>
<br>
</blockquote>
<br>
<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>
<br>
<pre class="moz-signature" cols="72">--
Walter Daniel Gallegos
Programmable Logic & Software
Consultoría, Diseño, Entrenamiento.
Montevideo, Uruguay
EMAIL <a class="moz-txt-link-abbreviated" href="mailto:walter@waltergallegos.com">walter@waltergallegos.com</a>
Tel +598 26 23 44 60 | Cel +598 99 18 58 88
</pre>
</body>
</html>