Conference 49.910::kav30

	Hi,

	there are some restrictions with location monitoring, which
	may not be described as clear as possible in the current
	documentation:


1) He uses two different AST routines in test 1.  HOwever, regardless of
which memory section is touched, both AST's fire.


->	correct, location monitoring is implemented in HW, there is no
	way to detect which specific address was touched...

	you should use different IPL's for that purpose 
	(KAV$M_LOCMON_IPL15 .. 17) - so you could distinguish between
	3 different pages maximum.

2) He uses the same AST but tries to use the AST_PARAM.  This should
be passed into the AST.  However, he doesn't know how the AST_PARAM
should be specified in the AST.  None of the AST examples in the documentation
declares that parameter for the AST routines.

->	in general this parameter is declared as any other parameter for
	a procedure - to give you an example, what language does your 
	customer use?

He finds that because the AST's operate in the context of the master process,
that the AST's get hung up.

->	... don't understand this..could you give us more details ?

How can he do either of the above so his AST knows which section of memory
was touched?

->	use different IPL's, see above.

Thomas

    Hi there,
    
    The declaration and passing of ast parameters from ada is non-trivial,
    the current documentation (version 1.1) describes how declare ast
    parameters in ada in section 5.2.1.1, however the example in the
    documentation does not illustrate this.  
    
    The following reply contains some sample ada code that demonstrate how
    to declare and pass ast parameters in an ada application.
    
    Graham
    

with TEXT_IO, VAXELN_SERVICES;

package AST_ROUTINES is

TRIGGERED_EVENT : VAXELN_SERVICES.EVENT_TYPE;

procedure AST_ROUTINE( AST_PARAM : in INTEGER);
                       
pragma EXPORT_PROCEDURE(AST_ROUTINE);

end AST_ROUTINES;

package body AST_ROUTINES is

procedure AST_ROUTINE( AST_PARAM : in INTEGER) is
                       

begin

   TEXT_IO.PUT_LINE("In AST routine");
   VAXELN_SERVICES.SIGNAL_EVENT( EVENT => TRIGGERED_EVENT);

end AST_ROUTINE;

end AST_ROUTINES;

with AST_ROUTINES, TEXT_IO, KAVDEF, CONDITION_HANDLING, SYSTEM,
     VAXELN_SERVICES;

procedure AST_TEST is

   STATUS : CONDITION_HANDLING.COND_VALUE_TYPE;
   SGM_ENTRY : INTEGER;
   BUS_PAGE : SYSTEM.ADDRESS;
   IN_PAGE : SYSTEM.ADDRESS;
   MAP_FUNCTIONS : INTEGER;
   UNMAP_FUNCTIONS : INTEGER;
   KAV_SERVICE_ERROR : exception;
   AST_PARAM_VALUE : INTEGER := 42;
   AST_PARAM : INTEGER;
   package STATUS_IO is new
   TEXT_IO.INTEGER_IO(CONDITION_HANDLING.COND_VALUE_TYPE);

begin

   MAP_FUNCTIONS := KAVDEF.KAV_M_MEMORY + KAVDEF.KAV_M_LOCMON_IPL17;


   VAXELN_SERVICES.CREATE_EVENT( EVENT         => 
                                 AST_ROUTINES.TRIGGERED_EVENT,
                                 INITIAL_STATE => VAXELN_SERVICES.CLEARED);


   AST_PARAM := SYSTEM.TO_INTEGER(AST_PARAM_VALUE'ADDRESS);

   SGM_ENTRY := 0;

   KAVDEF.KAV_IN_MAP( STATUS            => STATUS, 
                      SGM_ENTRY         => SGM_ENTRY,
                      PAGE_COUNT        => 1,
                      VIRTUAL_ADDRESS   => BUS_PAGE,
                      AST_ADDR          => AST_ROUTINES.AST_ROUTINE'ADDRESS,
                      AST_PARAM         => AST_PARAM,
                      MAP_FUNCTIONS     => MAP_FUNCTIONS);

   if not CONDITION_HANDLING.SUCCESS(STATUS) then
      raise KAV_SERVICE_ERROR;
   end if;



   VAXELN_SERVICES.WAIT_ANY( VALUE1 => AST_ROUTINES.TRIGGERED_EVENT);

   TEXT_IO.PUT_LINE("After call to WAIT_ANY");

   KAVDEF.KAV_UNMAP( STATUS           => STATUS,
                     SGM_ENTRY        => SGM_ENTRY,
                     PAGE_COUNT       => 1,
                     VIRTUAL_ADDRESS  => BUS_PAGE,
                     UNMAP_FUNCTIONS  => KAVDEF.KAV_M_IN);

   if not CONDITION_HANDLING.SUCCESS(STATUS) then
      raise KAV_SERVICE_ERROR;
   end if;



exception

   when KAV_SERVICE_ERROR =>
      TEXT_IO.PUT("Error detected: ");
      STATUS_IO.PUT( ITEM => STATUS, WIDTH => 8, BASE => 16);
      TEXT_IO.NEW_LINE;

   when others            =>
      raise;

end AST_TEST;
    

Hi Thomas and Graham,

Thanks for the replies.  I've subsequently been able to make progress with
the customer.  I've verified that he can now access the AST_PARAM correctly.
I'm also now having him use the different IPL level specified in the
map_functions.  This gave him some success - but here's the catch:

From his Motorola 68020 he writes to one section of memory, and then
subsequently
writes to the other section of memory.  When he uses the different IPL
levels, one AST triggers when the first memory section is touched. When
the second one is touched very quickly after the first, this is when he
can no longer trigger another AST.

On a hunch, I asked him to add a delay on the Motorola side between the time
he touches the first memory section and the second.  This appeared *to work*
when using the different IPL's.  When I asked if this would be a suitable
workaround, he was a bit hesitant.  It appears that there may be problems
if a second AST fires before the first has a chance to complete.  I'm currently
having him check what happens if he sets the second AST trigger to be at the
same IPL as the first.  I suspect he would ultimately run into a similar
problem even with the same IPL without any delay on the Motorola side.

His main concern is that he doesn't know how long he would need to delay.
He feels that the ELN KAV AST mechanism should be able to handle this.
He'd prefer to use the AST mechanism rather than have the Motorola side
actually generate an interrupt on the VME and then let the ELN side handle
the interrupt.

Is it possible to overrun the AST's causing subsequent AST's from being
triggered?  Will he have to resort to using a delay on the Motorola side?
If so, what is a minimum delay he should expect to use?

Regarding Thomas' question in .1:

>He finds that because the AST's operate in the context of the master process,
>that the AST's get hung up.
>
>->     ... don't understand this..could you give us more details ?

When I asked him to clarify his statement regarding the context of the AST,
he stated that if the Master process is halted (e.g., from the debugger),
he can not trigger the AST even the first time.  Likewise, when he gets
into this "AST hang" state, he can't halt the master process from EDEBUG.
Any thoughts as to why this is the case?  He's not at elevated IPL of course
and can access other processes in his EPASCAL job.

Thanks for any thoughts and comments,

Alan

    Hi Alan,
    
    Just a quick comment, having the second pages location monitoring at
    the same ipl level will not work.  What ipls is the customer using?
    
    Graham

Hi Graham,

The customer currently has the first memory section that is touched set up
for the AST at IPL 15,  the second at IPL 16.  It is possible that in his
code that one section of memory could be touched sequentially very quickly.
Without a delay on the Motorola side, would this get him into the same
situation if the AST doesn't complete before the memory is touched again?

Is this timing something that boils down to a hardware restriction?

(Note: Spoke with Graham off-line regarding KAV's AST's. - Thanks Graham!0)

Hi again,

Based on my conversation with Graham, I cautioned the customer about several
AST situations:

1) He should use different IPL's for the different memory section AST's set up 
   with KAV$IN_MAP.

2) Within the AST, he should not signal an event which the process who set up
   the AST is waiting upon.  This is to avoid an internal race condition
   Graham described.  In the customer's case, the master process does the
   KAV$IN_MAP calls and then creates the processes who wait upon the respective
   events.  This explains the why the customer's AST's are run in the 
   context of the master process (so if the master process is halted, the 
   AST will never be delivered.)



3) The AST with the higher IPL should be delivered first in order to avoid
   being preempted by the other AST when the other memory is accessed.

   QUESTION: What happens if an AST is preempted?  In the customer's case
      things appear to hang as described previously.  

4) Suggested using the FIFO's instead.  However, neither the customer nor we
   have any information on how to access the FIFO's from a non-KAV device on the
   VMEbus (e.g., his Motorola 68020).  

   QUESTION: Could you supply any information here?
      The customer finds this part of the doc's severely lacking.

For now, the customer will continue to use a delay in his Motorola code
to avoid any AST preemption.  However, he doesn't consider this to be
a suitable long-term solution.  He'd be glad to use FIFO's if he receives
further information.

Thanks for any further info on #'s 3 and 4 above.

Alan

Hi,

	documentation about FIFOs is at several points in the current
	doc-set:

	Programmers reference information:

	3.4 FIFO buffers -> general overview...

	Then you need several system services:

		KAV$IN_MAP -> to map the FIFO to VME space
		KAV$NOTIFY_FIFO -> to be notified on FIFO access
		KAV$FIFO_READ -> to read the data from one of the FIFOs
	
	Appendix B is an ADA coding example for a FIFO producer and consumer.


	From the VMEbus side the FIFO is an address on the bus just as all
	other ('valid') addresses:

	The KAV$IN_MAP service maps the *physical* VMEbus address (where
	you want to 'see' the KAV30 FIFOs) into the KAV30 FIFO address range.
	The actual address where you want to write to with your 68xxx processor
	now is the *physical* 'base_address' plus an offset of 0x4000 for the
	first, 0x4010 for the second .. and so on .. FIFO (see docu on
	KAV$FIFO_READ).
	
	Example: if you 'inmap' the VMEbus address to 0x1000000, the first
	         FIFO can be accessed at the VMEbus address 0x10004000 (the
		 68xxx now should write longwords to this address).

	With the KAV$FIFO_READ service you then can read the information
	(probably after you have been informed by the KAV$NOTIFY_FIFO service,
	that an access to the FIFO has occurred..).

	After sorting out all this information at various places in the
	'programmers refererence information' I agree, it is a little
	mess to go through this puzzle, we should concentrate all this 
	in one section with the next docu release...


Best regards

	Thomas