From mendoza@fnal.gov Thu Jan 11 16:57:30 2001
Date: Thu, 11 Jan 2001 16:20:29 -0600
From: Daniel_Mendoza <mendoza@fnal.gov>
To: buchholz@fnal.gov, Thomas_Nunnemann <nunne@fnal.gov>, edmunds@pa.msu.edu,
     Huaming Wang <wanghm@lotus.phys.nwu.edu>,
     Jadwiga Warchol <warchol@d0mino.fnal.gov>
Cc: Jaehoon Yu <yu@fnal.gov>
Subject: VRBC Status


Dear All.

A status report on the VRBC "saga" (*), My apologies for
the extension of the message. Please get back to me if you
find omissions/flaws/misinterpretations


* saga:

saga n. [WPI] A cuspy but bogus raving story about N random broken people.
...from Dictionary.com

/-----------------------------------------------------------/


1. CFT Crate
   ---------

PROBLEM: 

	L1 BZ comes up after a random number of events when
	cosmic rays triggers are used. This problem does not
	show up when using pulser triggers.

DIAGNOSTIC:

	By looking at the SCL Status register, Thomas and
	I observed that the READOUT_BZ* signal remains 
        asserted. This is probably caused by a missing 
        end of record or a truncated event.

FIX:

	Somebody should to make sure that the events are
        transferred correctly to the VRB. We will take it
	from there.

************************************************************

2. SMT CRATE:
   ---------

PROBLEM: 	

	L1 Asserted when the PPC boots up


DIAGNOSTIC: 

	It could be that since the PPC reads all the VRBC's 
	VME registers when booting up, some of these reads
	cause some commands to take place. The sequence of 
	commands could be such that an event is triggered
	when the VRB is not yet prepared to accept data and
	READOUT_BUSY* is never released.

FIX:

	I changed the code so that the VRBC does not take
	any action on VME read transactions (for those which 
	perform some action on data taking); yet those 
	transaction will be acknowledged as valid by the processor
	in the crate.

****************************************************************

3. TFW CRATE:

PROBLEM # 1:

	Single Buffer VRBC - L1 BZ Asserted after a L2
	Reject.

DIAGNOSTIC:

	Originally the "single buffer VRBC" raised L1
	BZ on L1 Accept and dropped it when the event
	was successfully transferred to the VBD. L2
	rejects were not taken into account.

FIX:

	Changed the code so that L1 BZ is de-asserted 
	on a L2 Reject.

PROBLEM # 2:

	Single Buffer & Multiple Buffer

	Dan requested to release SLV_RDY* on SCL_INIT to get
	rid of hung states in the VBD due to bad event transfers
	or any other cause.

DIAGNOSTIC:

	It is Okay to do that as long as the VBD is cleared
	before the next event takes place. Dan says:

"One very nice thing about the VBD is that from one event to the next
it does not carry over any context.  So it ususally does not get hung.
For example:  it may trash event "N" but event "N+1" is a completely
new game to it."


FIX:

	The code has been changed to allow SCL_INIT to
	release SLV_RDY*


PROBLEM #3

	L2 BZ after 3000+ events

DIAGNOSTIC:

	Probably old version of the code

FIX:

	Upgraded VRBC


PROBLEM # 4.

	L2 Accept LED lit on L2 Reject

DIAGNOSTIC:

	L2 Accept L2 connected to the L2 Decison signal

FIX:

	changed the code to connect it to right signal.

*********************************************************
	
	
4. SDAQ


See message below from Dave Buchholz:


Subject: silicon work

This morning we meet for the silicon software meeting and identified
getting the calibration process working with interrupts and block
transfers as the highest priority. After the meeting Huaming, Daniel
and I discussed the timing that is used to generate interrupts. 
Currently the interrupts are generated after the slave ready/finished
signals. These signal are generated either by the VRBC/VBD handshaking 
or by software. For calibration pulses you do not know when the external
pulses come from the framework so generating the slave ready/finished
signals is a problem. Daniel agreed to change his firmware to generate
the interrupt on Level 1 accepts. The software will generate the necessary
slave ready/finished signals.
        We will have to come back to the issue of when interrupts are
generated for monitoring purposes since this will be different. Daniel
expects to have this ready to be tested by Saturday morning. Huaming and
Daniel plan to test the hardware/software on Saturday morning.
                                        Dave