Timing Clarifications

Andrew E Mileski

This is an attempt to gather-up under one roof all Parallax timing clarification posts that I've deemed important. Perhaps fodder for a future datasheet update <hint, hint>

I highly recommend reading them all, and browsing the full threads they appear in.

I'll edit as I find more.

MSG 175639
Title:Overclocking the propellor?

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

While the official maximum speed is 80 MHz, spot tests show the room temperature failure point is 110-120 MHz; but it's not wize to be operating it at the very limit of it's operation. You could use a 6.5MHz crystal to achieve 104MHz operation and increase the likelyhood any particular Propeller would work at the frequency, but please be aware that we do not guarantee every Propeller will work at this frequency.

MSG 200355
Title: Understanding Assembler

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

Hi Jan,
To clarify a point, waitpeq is deterministic with respect to the pin state. The reason it is listed as 5+ is it takes 4 clocks to process the instruction, plus however many cycles of compare necessary to achieve the wait state. If the value is true at the beginning it will take 5 cycles since only one compare cycle occurs. For situations where more than one compare cycle occurs, the next instruction begins execution on the next clock cycle after a comparison evaluates true.

MSG 200372
Title: Understanding Assembler

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

The next instruction will begin executing the next clock cycle, since at 80MHz each clock cycle is 12.5 ns, the first stage of the next instruction will begin executing between 0 and 12.5ns after the line goes high, since that is the resolution of the comparator.

MSG 262722
Title: I/O cycle timings

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

The Full pipeline looks like this:

IdSDER               'first instruction
    IdSDER           'second instruction
        IdSDER       'third instruction

These stages are I= fetch instruction, d=decode instruction, S=fetch source operand, D=fetch destination operand, E=execute instruction, R=write result. Stage d is an internal operation, ie no access to memory is performed. I, S and D are all read operations, so that only leaves 1 stage to make an "effect". So all alterations of a cog's state is performed in the Result stage, whether it's writing to outa or whatever. INA is sampled during Execute, and that value is written to the destination the following clock cycle.

MSG 269439
Title: I/O cycle timings

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

Sorry for the confusion, Full Description of the pipeline is:
1) fetch next instruction
2) decode instruction
3) fetch source value
4) fetch destination value (this stage is nop for certain instructions (the unary operators))
5) execute instruction
6) write result to destination (this stage is nop when nr option specified)

MSG 269220
Title: Waitpeq/waitpna resume timing

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

I have verfied that that WAITPxx does indeed take 6+ cycles to execute, we will be updating our documents to reflect this. Nice catch.

MSG 269401
Title: Waitpeq/waitpna resume timing

Paul Baker, Propeller Applications Engineer, Parallax, Inc. said...

Kuroneko, I too confirm a 7 cycle delay for an already established wait period + mov instruction, but I don't concur with your conclusion. I have discussed this behavior with another engineer and this is what we think is happening. But first a review of the Propeller Pipline:

IdSDeR                 1st instruction
    IdSDeR             2nd instruction
        IdSDeR         3rd instruction

Where
I = instruction fetch
d = decode
S = fetch source
D = fetch destination
e = execute
R = write result

When a waitxxx instruction is executed, the pipeline stalls. Now we know that the output of the mov is done in the result stage. If we count back 7 cycles that places us in the D stage of the waitcnt, but this doesn't make sense because this is not a logical place for the waitcnt to stall (whereas stalling at stage e makes sense).

So a further examination of the waitxxx behavior is needed:

The following is a representation of a pin state a waitpxx instruction is performing on. The | represents a clock boundry, a _ represents no change of the pin and a / represents a change of the pin

|_|_|/|_|_|
1 2 3 4 5 6

as you can see the event happens between cycle 3 and 4. At clock cycle 4 the waitpxx registers a true condition, but this does not immediately result in restarting the pipeline because the true condition must be given time to propagate throughout the cog. Therefore the cog does not restart the pipeline until cycle 5. When the pipeline restarts it will be at the R stage of the waitxxx and the d stage of the following instruction. Take the 2 cycles needed to register and propage the true condition plus the 5 remaining stages of the next instruction we are left with 7 cycles.

While I am not absolutely certain this is precisely whats going on, it is a good enough explanation of observed behavior that it should suffice to think of waitxxx's behavior in this way.

One further note, the tests that we both did were synchronous in nature, for asynchronous test it will be found that the response time will be (6,7] or anything between 6 and 7 cyles, but not including 6 itself (ie any marginal value above 6 such as 6.02).

Post Edited (Andrew E Mileski) : 12/12/2008 7:41:54 PM GMT

Andrew E Mileski

Reserved for future use.

Andrew E Mileski

Reserved for future use.