2 Replies Latest reply on Oct 18, 2017 6:59 AM by richard.aston_1660756

    Datapath timing

    richard.aston_1660756

      Perhaps some of you clever folks can explain what I'm doing wrong.

       

      As an exercise, I want to use a Datapath (DP) and a state machine (SM) to create a simple serial out like a SPI-lite.  My initial implementation was really screwy so I went back to basics to see how the timings work.

       

      What is screwy?  My data is shifted out before the DP reaches the instruction to do it.

       

      I have a three-state SM and the state value is used to step the DP so INSTR_ADDR[0] is SM[0] and INSTR_ADDR[1] is SM[1].  So, naturally, as the SM steps unconditionally between the states, the value stored in SM immediately following a clock is that of the forthcoming state and not the one we're in.  So if I have a pin where SM == Ready (my states are named Ready, Steady & Go) and another where the pin is set on entering the state and cleared on leaving, the latter is a clock cycle behind the former.

       

      OK.  I'm cool with that.  If there were an imaginary 2-bit latch, the D-inputs are the value of SM and the Q-outputs are the actual state.

       

      My problem is that my three states control a DP so I expect that the next instruction is set up by the value of SM and actioned at the clock cycle.  I have three actions: load the A0 from D0 (loaded with 0x80), shift out the '1', shift out the '0'.

       

      Sorry for being so long-winded.

       

      I expect my data out to change when I enter the 'Steady' state.  The SM is set to 1'b1 immediately following entry to the Ready state so when the next clock arrives, I would expect the SM to enter the Steady state and the data appear at the output pin.

       

      It doesn't.  It changes as it enters the preceding state.  In other words, it behaves as if the clock for the DP were a few nanoseconds behind the change of value of the SM or that the DP were too impatient to wait for the clock and actioned the instruction when the value of SM changed.

       

      Bringing the clock out to a pin, the SM == Ready pin changes 6.6ns behind the clock, the flag set within the state is 3.3ns after the clock and the data changes 4.7ns after the clock.  So it can't possibly be a wacky clock.

       

      So, please, why is my data coming out one whole state before it's due?

       

      I'm using a CY8CKIT-050.

        • 1. Re: Datapath timing
          ntan

          I just open your project an looking into the "TestComp4" component.

           

          As you described in the discussion, the state machine state is assigned as follows.

          StateCode
          Ready1'b0 = 2'b00
          Steady2'b10
          Go1'b1 = 2'b01

           

          On the other hands, the Datapath's instruction code is assigned as follows.

          InstructionCode
          Ready3'b000
          Steady3'b001
          Go3'b010

           

          "Steady" and "Go" are exchange code each other.

           

           

          You are mention about the skew between the clock output and the signal output from the state machine.  There is a static timing analysis result file "CompTest2_timing.html" in the project directory.  You can find the file at the "Results" tab on the "Workspace Explorer"

          GS003318.png

          In the "Clock To Output Section" the delay between the internal clock and the output pin.  The delay values are different between pins.

           

          It is found that the delay between the Pin_7 (clock output) and the internal Clock_1(routed) is faster than other pins.  But there is no description about the delay between the internal Clock_1 and the Clock_1(routed)  So, It is not clear if the clock output is faster than other signals.

           

          Regards,

          Noriaki

          • 2. Re: Datapath timing
            richard.aston_1660756

            Hello, Noriaki,

             

            Thank you for reading my post and looking over my work.  It is really appreciated that you take the trouble and time to respond.

             

            The labelling of the states is an error but doesn't alter the effect.  Basically, the two ALU instructions are the same so it doesn't really matter if they are exchanged.  Quickly correcting the code and debugging it bears this out.

             

            Thanks for pointing me in the direction of the timings output.  I'll take a closer look.

             

            Regards,

            Richard.