<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    repost <br>
    <br>
    <div class="moz-cite-prefix">El 2016-02-16 a las 18:27, Walter
      Gallegos escribió:<br>
    </div>
    <blockquote cite="mid:56C3942E.3070600@waltergallegos.com"
      type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      Magnus, <br>
      <br>
      The correct technique to solve this is use a DCM with 50MHZ
      connected to CLKIN, connect clk to CLKDIV and pclk to CLKFX.
      Setting the divider to 2 and M/D to 3/2. Is the same DCM used to
      generate the pixel clock, so have no sense use a "bad practice"
      solution when the correct is used in the project.<br>
      <br>
      Regards,<br>
      Walter<br>
      <br>
      <div class="moz-cite-prefix">El 2016-02-16 a las 16:52, Walter
        Gallegos escribió:<br>
      </div>
      <blockquote cite="mid:56C37DED.50900@waltergallegos.com"
        type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        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 moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">--
<a moz-do-not-send="true" 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 moz-do-not-send="true" 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 moz-do-not-send="true" 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


El presente correo y cualquier posible archivo adjunto está dirigido únicamente
al destinatario del mensaje y contiene información que puede ser confidencial. 
Si Ud. no es el destinatario correcto por favor notifique al remitente 
respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los 
posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier 
utilización, difusión o copia de este e-mail por cualquier persona o entidad 
que no sean las específicas destinatarias del mensaje.

This e-mail and any attachment is confidential and is intended solely for the 
addressee(s). If you are not intended recipient please inform the sender 
immediately, answering this e-mail and delete it as well as the attached files.
Any use, circulation or copy of this e-mail by any person or entity that is not
the specific addressee(s) is prohibited. 

</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


El presente correo y cualquier posible archivo adjunto está dirigido únicamente
al destinatario del mensaje y contiene información que puede ser confidencial. 
Si Ud. no es el destinatario correcto por favor notifique al remitente 
respondiendo anexando este mensaje y elimine inmediatamente el e-mail y los 
posibles archivos adjuntos al mismo de su sistema. Está prohibida cualquier 
utilización, difusión o copia de este e-mail por cualquier persona o entidad 
que no sean las específicas destinatarias del mensaje.

This e-mail and any attachment is confidential and is intended solely for the 
addressee(s). If you are not intended recipient please inform the sender 
immediately, answering this e-mail and delete it as well as the attached files.
Any use, circulation or copy of this e-mail by any person or entity that is not
the specific addressee(s) is prohibited. 

</pre>
  </body>
</html>