<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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:part1.02090108.03090906@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 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><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 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 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 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 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 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>