<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Apologies, Spanish typo in my post.  "de" => "the".<br>
    <br>
    <div class="moz-cite-prefix">El 2016-02-24 a las 11:07, Walter
      Gallegos escribió:<br>
    </div>
    <blockquote cite="mid:56CDB930.50802@waltergallegos.com" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      <font face="Courier New, Courier, monospace"><br>
        DCM #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"),
        .CLKIN_PERIOD(20.000))<br>
          dcm(.<b>CLKIN(CLK50M)</b>, .CLKFB(clk), .RST(1'b0),
        .PSEN(1'b0),<br>
              .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0), .CLKFX(pclk),
        .<b>CLK0(clk)</b>,<br>
              .CLK90(clk90));</font><br>
      <br>
      clk = CLK0 = CLKIN = CLK50M.  Can this version of RISC5 run at
      50MHZ as is ?<br>
      <br>
      Here my simulation using de Cypress SRAM VHDL simulation model
      with ALDEC simulator.<br>
      <br>
      Label : "Potential Issue", If you read the SRAM and - in the next
      clk cycle - try to write the same SRAM data bus we could wait some
      ns of bus contention at this point.<br>
      If RISC5 can read then write in consecutive clk cycles the issue
      is easy worked capturing de SRAM data with 90° clock rising_edge
      and releasing oen soon. <br>
      Important note : This functional simple test bench do not take in
      count internal RISC5 timing issues.<br>
      <br>
      Question to RISC5 fathers and adopters : Someone build an
      "official" test bench set for RISC5 ? That means module by module
      plus one total. <br>
      Is the test bench available ? <br>
      <br>
      <img src="cid:part1.09030702.00020309@waltergallegos.com" alt=""><br>
      <br>
      I'm more interested in practical uses; as an -industrial grade-
      embedded RISC5; how many in this list, <span id="result_box"
        class="short_text" lang="en"><span class="hps">in addition to
          those</span> <span class="hps">we</span> <span class="hps">already

          know,</span></span> walk in the same direction ? <br>
      <br>
      Best regards<br>
      Walter<br>
      <br>
      <br>
      <div class="moz-cite-prefix">El 2016-02-23 a las 13:49, Magnus
        Karlsson escribió:<br>
      </div>
      <blockquote cite="mid:56CC8D81.90804@saanlima.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">Walter,<br>
          <br>
          I tried your proposed solution and couldn't make it work.  It
          "almost" works in that it starts the boot process and reads
          from the SD-card, but then hangs with the LEDs showing 0x84.<br>
          Maybe I didn't do it correct, I instantiated the ODDR2 buffer
          directly at the top module and modified the DCM instantiation
          to create the clk90 clock.<br>
          <br>
          Here is the code, can you look it over and see if this is what
          you had in mind or if something is wrong:<br>
          <br>
          <font face="Courier New, Courier, monospace">DCM
            #(.CLKFX_MULTIPLY(3), .CLKIN_DIVIDE_BY_2("TRUE"),
            .CLKIN_PERIOD(20.000))<br>
              dcm(.CLKIN(CLK50M), .CLKFB(clk), .RST(1'b0), .PSEN(1'b0),<br>
                  .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0),
            .CLKFX(pclk), .CLK0(clk),<br>
                  .CLK90(clk90));<br>
            <br>
            ODDR2 #(.INIT(1'b1))<br>
              oddr2(.Q(wr_enable), .C0(clk90), .C1(~clk90), .CE(1'b1),
            .D0(1'b1),<br>
                  .D1(~wr), .R(1'b0), .S(1'b0));</font><br>
          <br>
          <font face="Courier New, Courier, monospace">assign SRwe =
            wr_enable;<br>
            <br>
          </font><br>
          wr is the active-high write signal from the RISC5 CPU, and
          SRwe is the short active-low write-enable signal to the SRAM.<br>
          <br>
          Just to recap, this is the code I used to generate the short
          write pulse, using a 2x clk instead.  This version seems to
          run fine:<br>
          <br>
          <font face="Courier New, Courier, monospace">reg wr_enable;</font><br>
          <br>
          <font face="Courier New, Courier, monospace">DCM
            #(.CLKFX_MULTIPLY(3), .CLKFX_DIVIDE(2), .CLKDV_DIVIDE(2),
            .CLKIN_PERIOD(20.000))<br>
              dcm(.CLKIN(CLK50M), .CLKFB(clk2x), .RST(1'b0),
            .PSEN(1'b0),<br>
                  .PSINCDEC(1'b0), .PSCLK(1'b0), .DSSEN(1'b0),
            .CLKFX(pclk), .CLKDV(clk), .CLK0(clk2x));<br>
            <br>
            always @(negedge clk2x)<br>
              wr_enable <= wr & ~wr_enable;<br>
            <br>
            assign SRwe = ~wr_enable;<br>
            <br>
          </font><br>
          Any idea what's wrong?<br>
          Magnus<br>
          <br>
          <br>
          On 2/19/2016 9:58 AM, Walter Gallegos wrote:<br>
        </div>
        <blockquote cite="mid:56C757AE.5070807@waltergallegos.com"
          type="cite">
          <meta content="text/html; charset=windows-1252"
            http-equiv="Content-Type">
          Let us concentrate in the problem...<br>
          <br>
          How to generate an output pulse shorter than clock period?<br>
          <br>
          You can make a pulse shorter with help of DCM and DDR ( dual
          data rate output registers ) see the simulation capture <br>
          <br>
          <img src="cid:part2.08080809.05030903@waltergallegos.com"
            alt=""><br>
          <br>
          clk25f90 is the DCM clock output with 90° phase shift.<br>
          <br>
          The VHDL code is : ( without DCM instantiation )<br>
          <br>
          ENTITY PulseShaper IS<br>
              PORT  (CLK25F90 :  IN STD_LOGIC;<br>
                       RESET :  IN STD_LOGIC;<br>
                          WE : IN STD_LOGIC;<br>
                      WESRAM : OUT STD_LOGIC<br>
                   );<br>
          END PulseShaper;<br>
          <br>
          ARCHITECTURE RTL OF PulseShaper IS<br>
          <br>
             CONSTANT zero : STD_LOGIC := '0';<br>
             CONSTANT one : STD_LOGIC := '1';<br>
             <br>
             SIGNAL clk90n: STD_LOGIC;<br>
          <br>
          BEGIN<br>
          <br>
             clk90n <= NOT(CLK25F90);  -- This is valid because the
          tool use the clock inverter available in IOB<br>
          <br>
             Dly : ODDR2<br>
             PORT MAP (<br>
                Q => WESRAM,     <br>
                C0 => CLK25F90,  <br>
                C1 => clk90n, <br>
                CE => one,    <br>
                D0 => one,    <br>
                D1 => WE,     <br>
                R => zero,    <br>
                S => zero     <br>
             );<br>
          <br>
          END RTL;<br>
          <br>
          Someone know if exist a FPGA testbench for RISC5 ?<br>
          <br>
          Regards,<br>
          Walter<br>
          <br>
          <div class="moz-cite-prefix">El 2016-02-19 a las 11:33, Magnus
            Karlsson escribió:<br>
          </div>
          <blockquote cite="mid:56C727AF.5020201@saanlima.com"
            type="cite">In all fairness, since I have generated and
            tested code for one way to solve the problem, can you then
            give us your code proposal for generating the SRAM write
            signal, with 25MHz and 75MHz generated by a DCM?  The write
            signal must be asserted after all other SRAM control signals
            are valid, and be de-asserted before any of the control
            signals go invalid, and last for at least 5 nS.  The SRAM
            control signals are generated by the 25MHz clock and last
            for one clock cycle. <br>
            <br>
            I will be more than happy to try it out on a board and
            report the result. <br>
            <br>
            Magnus <br>
            <br>
            <br>
            On 2/19/2016 4:57 AM, Walter Gallegos wrote: <br>
            <blockquote type="cite">Have a solid and coherent clock
              distribution is basic for FPGA design, my proposition was
              keep both 25MHZ and 75MHZ, generated by DCM. <br>
              <br>
              Run all in 75 MHZ is unnecessary; also, clock enable
              approach add unnecessary complexity to the design. Make a
              design synchronous don't necessary means use the same
              clock for all the design. <br>
              <br>
              Continue using 25MHZ for the core and peripherals, the
              only concern is the CDC (clock domain crossing). As both
              clock was generated by the same DCM is minor problem;
              correspondent rising edges are aligned by design in DCMs;
              metastability is not an issue. Using DCMs and constraining
              input clock (50MHZ) the constraints propagation rules
              constraint both clocks, 25MHZ and 75MHZ. If no methodology
              errors all design are constrained from first to last
              register element in the chain. Beware of combinational
              logic in outside this elements. <br>
              <br>
              In my opinion, taking care of CDC keep both clock is the
              appropriate solution. <br>
              <br>
              Best regards, <br>
              Walter <br>
              <br>
              El 2016-02-18 a las 19:58, Magnus Karlsson escribió: <br>
              <blockquote type="cite">So I have been thinking about this
                some more and decided to modify/update the design to
                remove all the concerns raised by Walter and Wojtek. <br>
                <br>
                Just to recap, Walter's concern is that the clocks are
                generated using flip-flops and use logic fabric
                interconnect instead of dedicated clocking elements and
                pathways, and that all clocks should be generated by a
                DCM module instead (DCM = Digital Clock Manager). 
                Wojtek's concern is that there are unspecified timing
                relations between the 25MHz and the 75MHz clock domains.
                <br>
                <br>
                Both concerns are valid and in my opinion the correct
                way to fix both issues is to make the design completely
                synchronous.  This means that all clocked elements in
                the design (like flip-flops, memories etc.) should be
                clocked with a single clock signal, which in this case
                is the 75MHz clock.  The CPU and I/O subsystem, which
                before was clocked by a separate 25MHz clock, are now
                also clocked by the 75MHz clock but are only enabled to
                be clocked on every third clock cycle.  This means that
                all "always @ (posedge clk)" statements have been
                changed to include "If (enable) ...", where "enable" is
                a signal that is true on every third clock cycle.  The
                asynchronous SRAM interface is also changed so that the
                write signal is asserted on the middle-third clock phase
                of the three clock CPU cycle. <br>
                <br>
                While the Verilog changes to do this are very straight
                forward, one complication here is that the Xilinx ISE
                tool used to create the bit file for the FPGA do not
                understand that the CPU and I/O subsystem are only
                clocked on every third clock and will basically try to
                make the CPU run at 75MHz, and will fail since this is
                too fast the FPGA.  The solution to this problem is to
                tell the tool that all clock paths in the CPU and I/O
                subsystem can actually take three clocks to complete
                (this is called multi-cycle paths). With the multi-cycle
                paths added to the .ucf file the design compiles with no
                timing violations <br>
                <br>
                With those changes the 75MHz clock is now generated by a
                DCM and the unspecified timing relations that Wojtek
                brought up are now gone since everything is clocked with
                a single clock.   The modified design have been tested
                on Pepino and seems to run fine. <br>
                <br>
                The complete ISE project with those changes are
                available at the Pepino GitHub repository: <a
                  moz-do-not-send="true" class="moz-txt-link-freetext"
href="https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino"><a class="moz-txt-link-freetext" href="https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino">https://github.com/Saanlima/Pepino/tree/master/Projects/RISC5Verilog_Pepino</a></a><br>
                <br>
                Any comments or critique are welcome. <br>
                <br>
                Cheers, <br>
                Magnus <br>
                <br>
                <br>
                <br>
                On 2/17/2016 2:16 PM, Walter Gallegos wrote: <br>
                <blockquote type="cite">Hi Magnus, <br>
                  <br>
                  You are welcome to continue with FPGA specific topics
                  by private e-mail if you want. <br>
                  <br>
                  Regards <br>
                  Walter <br>
                  <br>
                  El 2016-02-17 a las 18:30, Magnus Karlsson escribió: <br>
                  <blockquote type="cite">Hi Walter, <br>
                    <br>
                    Since this is really Paul's design, I guess it would
                    be more appropriate to discuss it with him, I was
                    just trying to explain why it looks like it does. <br>
                    <br>
                    Cheers, <br>
                    Magnus <br>
                    <br>
                    <br>
                    On 2/17/2016 1:15 PM, Walter Gallegos wrote: <br>
                    <blockquote type="cite">Magnus, <br>
                      <br>
                      Some of messages was delayed; so, I continue from
                      here to not overload the list. <br>
                      <br>
                      If I understand you correctly, you justify a
                      uncontrolled delay because they simplify the SRAM
                      handling. <br>
                      Sorry, is as using the old circuit with an
                      and/inverted to generate a pulse. If you need a
                      delayed signal you should use the DCM 90°, 180° or
                      270° clock outputs and keep all under control, I
                      think don't need a state machine in this case. <br>
                      <br>
                      About ISE warnings, be careful, non warning do not
                      means good methodology. <br>
                      <br>
                      About XILINX docs; really, I don't remember. Doing
                      training, first as Xilinx ATP and now as
                      independent consultant, I touch this problem in my
                      trainings. Have an uncontrolled delay in clock is
                      a big door to random problems. FPGA design must be
                      synchronous all times; no exceptions. <br>
                      <br>
                      Regards, <br>
                      Walter <br>
                      <br>
                      <br>
                      El 2016-02-17 a las 14:41, Magnus Karlsson
                      escribió: <br>
                      <blockquote type="cite">Walter, <br>
                        <br>
                        I agree with you that the "pure" way of doing
                        this is as you stated, with a DCM to directly
                        generate both clk and pclk. So how come Paul
                        didn't do that?  It's not like he doesn't know
                        how to use the DCM, after all the current code
                        generates pclk from clk using a DCM, and there
                        would probably be less code to do it like you
                        suggest. No, the reason for this is very subtle
                        and is easy to miss if you just take a quick
                        look at the code, and it has to the asynchronous
                        SRAM interface. <br>
                        <br>
                        One of the most critical aspects of using SRAM
                        is to control the write signal - ideally the
                        write signal should be asserted after all other
                        control signals (like address, data,
                        byte-enable, read, oe) are valid, and should be
                        de-asserted well before any of the other control
                        signals go invalid, to avoid spurious writes.
                        However, this is not that easy to do in a
                        synchronous system where all signals change at
                        the clock edge.  The most common way to do this
                        is to have a state machine that is clocked at
                        say 4x the CPU clock so that you can divided the
                        SRAM access cycle into several phases and assert
                        the write signal on some of those phases. <br>
                        <br>
                        However, this is not the way Paul choose to do
                        it, instead he choose to do a less "pure" clock
                        generation by generating clk from a flip-flop
                        rather than from a DCM. By doing so, he actually
                        generates an early version of the clock signal
                        called clk that is leading the global clock
                        signal clk_BUFG by the delay of the BUFG
                        buffer.  Since this early version of the clock
                        signal is generated like any other logic signal,
                        he could use this signal to gate the write
                        signal to the SRAM such that write signal will
                        be de-asserted well before the other control
                        signals (clocked by clk_BUFG) will change, and
                        thus avoiding the need to have a state machine
                        controlling the write signal.  The price for
                        this is that the clock signal is now generated
                        in a less "pure" way, but still a valid way as
                        long as you know what you are doing. The BUFG
                        clock driver can be driven from a PLL, a DCM or
                        from the logic fabric.  The first two are speed
                        optimized paths going directly from the PLL or
                        DCM to the BUFG and can be clock at much higher
                        clock rate, while the logic fabric path is
                        limited by the maximum clock rate of the logic
                        fabric. However, at the clock rate we use (25
                        MHz) this is not an issue.  When you do this
                        there are no warnings generated by ISE that this
                        is not a good idea, and I have not read anywhere
                        in the Xilinx clocking resource guide that you
                        should avoid doing this. Basically, the BUFG
                        clock driver is designed to do this, the tool
                        will allow you to do it and at the clock rate we
                        use it has no performance implications. As I see
                        it, this is another place where the goal of
                        simplification has driven the implementation of
                        the system at the expense of a slightly less
                        "pure" clock generation. <br>
                        <br>
                        Just my 2c <br>
                        <br>
                        Magnus <br>
                      </blockquote>
                    </blockquote>
                  </blockquote>
                </blockquote>
                <br>
                -- <br>
                <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 <br>
                <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>
                <br>
                <br>
              </blockquote>
              <br>
            </blockquote>
            <br>
            -- <br>
            <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 <br>
            <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>
            <br>
            <br>
          </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>
          <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>
        <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>