Contact US

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

Variable delay loop accurate to the instruction cycle?

Variable delay loop accurate to the instruction cycle?

Variable delay loop accurate to the instruction cycle?

After searching your forum I haven't been able to come up with anything that fits my predicament.  I'm hoping one of you experts can point me in the right direction.

I'm working on removing jitter from a clock that connects to a PC through an ISA bus.  The system in question was designed and built around 18 years ago and all of the designers have since retired.  At the moment we have around 6 us of jitter in the clock, but since we're using it to synchronise data collection at a wide variety of points across Canada (synched to a GPS time signal) it needs to be even better.

We've managed to track the jitter to a simple loop that basically waits for an interrupt.  Because the interrupt can happen at any time during the loop and on any instruction, there are around 4 cycles of variablility (at approx 1.61 us / cycle).  To remove this jitter all I need to do is synch the entry into that loop with a known instruction cycle.  I can access a free running counter to determine the current cycle, but that takes time.  Ideally I'd determine how many cycles I need to count, subtract the overhead from the calculation, and then count out that number.  However, I can't come up with a way to count out a variable number of cycles that is accurate to the cycle.  For instance, if I used a simple loop like


to count out X cycles I'd still be working with a 3 cycle delay every time I hit the branch.  To my thinking that means my loop can only count in multiples of 4 instruction cycles.  Is there a simple way of counting out an exact (but variable) number of instruction cycles?

The system we're using runs a Hitachi HD6303X microprocessor and I've been using a WinTek compiler.  The interrupt I'm waiting for is an output compare interrupt triggered when the free running counter equals the output compare register.  I tried briefly to use the WAI command to simply wait for the next interrupt but I'm not sure if it only waits for a hardware interrupt or if the OCI will successfully trigger it.

I know this message is really long winded but I wanted to give as much info on my problem as I could.  Also no, this isn't a school project, but if anyone here has helpful information I'd be more than willing to assign them a mark based on just how helpful they were.

Thanks to anyone who reads this whole thing, and double thanks to anyone who tries to help.


RE: Variable delay loop accurate to the instruction cycle?

I'm not sure if I understand, but if you want to have a system doing something accurate to one cycle on any processor I'd have doubts about whether it's possible. There are all sorts of things that can hold the processor up for several cycles, including dynamic ram refresh, which can inflict wait-states. Remember, even if the loop is entirely inside the processor's cache and independant of the world, the moment the interrupt happens, the processor will need to interact with the world, and if the world is busy refreshing its dram, you'll have a delay. But I'm not an expert so ignore this if it's all rubbish!

RE: Variable delay loop accurate to the instruction cycle?

Perhaps this pseudo code.


    ; read current cycle count
    ; subtract overhead
    ; jmp to zero_time - result
    ; as many more nops for your max delay
    ; start of critical routine

Essentially, you have a big list of nop instructions (usually 1 cycle), and you compute a jump to the right spot which would give you the delay you calculated.

The larger the delay, the further away from zero_time you jump to and the more nop instructions you end up executing.

If you have a particularly large time interval to burn, then consider using some other function to wait for the bulk of the time and use this to wait for the accurate remainder.


RE: Variable delay loop accurate to the instruction cycle?

The 6303 from hitachi and also the 6803 from motorola only read the interrupt pin during a instruction fetch.
So in your example the minimum delay would be that of
the branch that takes 3 cycle's to execute (if branch taken).
The minimum delay possibly with the 6303 is indeed the nop
but it takes 2 cycle's.
There is no instruction in the 6303 that actualy needs only 1 cycle.

You can use the wait instruction to sychronise since
it take's just in cycle to start the interrupt handling
but only afther the wait has done some work for it one.
Afther that it scans the interrupt pint and the internal
interrupt at every clock cycle.
So if you do not want the timer overflow or anny other
internal interupt take over your interrupt pin disable
the internal interrupt sources first.

The tomer output compare interrupt will be handled if you
enable it.

Succes, Tessa

RE: Variable delay loop accurate to the instruction cycle?

First off thanks to all for the replies.

Lionel: Yeah, I have the nagging suspicion that what I'm trying to do might be close to impossible but they're paying me to give 'er a go, so I'd better do what I can. At this point I'm mostly hoping to get the clock jitter as small as possible, and I think I can improve on it's current state.

Salem: I'm actually trying to get that method to work right now. I figure that if the interrupt always triggers on a NOP then I can effectively eliminate jitter beyond the length of a single null operator (not including other delays as mentioned by Lionel). The first couple attempts haven't had much success, but at least I feel like I'm getting somewhere.

Tessa: Is there anything more to the WAI command than just putting it where you would like the code to wait? The output compare interrupt is already enabled (it's integral to the operation of our clock) but I simply tossing the WAI command in where I wanted the delay caused the system to hang (I assume waiting for an interrupt that never came). I'll try playing around with it a bit more to see if I can work it out.

Thanks again for the replies. It's been a while since I spent time with assembler so I'm still trying to remember the subtleties.


RE: Variable delay loop accurate to the instruction cycle?

You can put the wait allmost anywere, but be sure that
you let the global interrupt enabled.
That is: use a CLI before you goto the WAI instruction
else it can only be interrupted by the non maskeble
There is something that you have be sure of: the WAI
instruction can only do its proper work if it has the
time to put the register on the stack, so it has to be
executed in a time-slot that you know that the previous
interrupt has occurred and the next is to come only
afther +- 11 cycles.

Plaese don't get confused by the way the 80x86 interrupt
mask, it work just in the oposit.

So to  enable the interrupt use CLI
   to disable the interrupt use SEI.

Succes, Tessa

p.s. Using the WAI instruction is the only way to get the
     minimum clock jitter, since that is the only
     instruction that puts de registers on stack and
     then waits for a interrupt.
     From that point there is a stable cycle count when
     a interupt is handled.
     Even using the NOP can't garanty that.

RE: Variable delay loop accurate to the instruction cycle?

A plusses (plusi?) all around.  I used a combination of the two ideas to create a loop that eats up most of the time (down to the last 13 or so cycles) and then hits the WAI command.  At first glance I'm now working with a nicely negligable jitter that's less than 1.5 us.  I'm sure there are things that could cause it to jump around a little in certian situations, but if it stays around there during regular operation I'm more than happy.

Thanks again for the replies and advice.  It's always good to have my ideas validated by someone who actually knows what they're doing.


Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close