From: Roeber <fjr@ssd.ray.com>
Newsgroups: comp.os.vxworks
Subject: MVME167 timing
Date: Thu, 5 Nov 1992 10:37:00 -0500
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

Hello,  Back in august, there was some discussion on initializing the timer
control registers correctly on a MVME167 card.  Well, now I have to use a
167 card so I was going through the information that was discussed.  One thing
came up that seems very important but never seemed to get resolved.  Phil
Perillat of Arecibo Observatory wrote:

> The mv167 board has another set of timers in the vmechip2:
>
> /*
>  *              VMEbus Arbiter Timeout Control Register         0x4c    31-24
>  *              DMAC Ton/Toff Timers and VMEbus Global Timeout  0x4c    23-16
>  *              VME Access, Local Bus and Watchdog Timeout      0x4c    15-08
>  *              Prescaler Control Register                      0x4c    07-00
>  */
> #define VMECHIP2_TIMEOUTCR      VMECHIP2_ADRS(0x4c)
>  
> I looked in sysLib.c to see if they had made the same mistake setting the
> prescaler control register (~BCLK vs - BCLK) for the vmechip2. What i found
> was:
> /* set VMEbus global timeout to 64us
>      * set VMEbus access timeout to 1ms
>      * set local bus timeout to 64us
>      * set watchdog timeout to 16ms
>      */
> 
>     *VMECHIP2_TIMEOUTCR         = (TIMEOUTCR_VGTO_64US  |
>                                    TIMEOUTCR_VATO_1MS   |
>                                    TIMEOUTCR_LBTO_64US  |
>                                    TIMEOUTCR_WDTO_16MS);
> 
> But no setting of the prescaler adjust??? Looking at 0xfff4004c also shows
> the prescaler adjust set to zero??? paraphrasing the mv167 Programmers Ref
> guide pg. 2-62...
> 
> If the prescaler is not correctly programmed, the bus timers do not generate
> their specified values and the VMEbus reset time may be violated...
>  
> Have i missed something here ?????

I think Phil is completely correct.  The way the VME chip is set up, the
prescaler is not being set so all of the timing values should be coming
out wrong.  This means that people could get timeouts when they might not
expect them or other such problems (just like people have been mentioning).
Also, the Motorola manual recommends a set of timeout settings that are
different from what is used (see pg 1-45 of the 167 HW manual).  I feel that
the initialization line above should be:

     *VMECHIP2_TIMEOUTCR         = (TIMEOUTCR_ARBTO       |
                                    TIMEOUTCR_VGTO_256US  |
                                    TIMEOUTCR_VATO_1MS    |
                                    TIMEOUTCR_LBTO_8US    |
                                    TIMEOUTCR_WDTO_512MS  |
                                    (256 - BCLK));
This should make bus activity much more reliable (and also let people use
the two timers in the VME chip for additional timing capabilities).  Note
that I also am enabling arbitration timeout so that a card glitch can't hang
the whole backplane. What do other people think?  Is this a fix that has
already been tried out by anyone?    Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|