This is the Log Book for the Level 1.5 Calorimeter Trigger started 16-NOV-1994 the file ARIEL_HARDWARE_SOFTWARE.LBK no longer exists. Its contents are recorded at the end of this file. ============================================================================== SHORT TO MEDIUM TERM TO DO LIST remove "temporary" MFP handling code from Local DSP's L_SCAN to cut about 900 ns from "Scan Loop" time. *** DONE 17-NOV-1994 *** once Local Object List has overflowed, stop scanning towers, being careful to not cause extra delay for "normal" processing, and also being careful to restore program and processor context when aborting the scan. *** DONE 18-NOV-1994 *** change 68K_Service "GDSP to D3" timeout to "max legal" time, without breaking interfaces to rest of experiment, this requires study. change 68K_Service "error recovery" action from "dump event on floor" to "try to send event to L2 with an error recovery flag," without breaking interfaces to rest of experiment, this requires study. ============================================================================== LONG TERM TO DO/NOTE/IDEAS LIST (technical NOT algorithm ideas) cut Local-to-Global transfer time. possible ideas: - shorter lists (this meets with resistance) - variable length lists (send list length as 1st longword) - CPU vs. DMA? (speedup unlikely because need to use || instructions to get speedup, but Comm Ports not necessarily operating exactly in ||) - hardware path between Locals and Global to eliminate bottleneck - 2-stage transfer, only transfer details if event accepted Path Select P2 paddleboard does not guarantee "That's Me" set before "Something Happened," currently 68K reads twice to be sure to not miss "That's Me." Start ERPB Data Transfer sooner Programming information into TRGMON Re-think about always running all 4 Terms ============================================================================== Date: 19-DEC-1995 At: MSU Topics: more eWjj coding L_SCAN.A40 Change: R0, R1: Total Et TT data (not EM) AR0, AR1: Pointer to Total Et TT data (not EM) various comments pass Wake_Up_Word to L_TL_NPx in memory not a register L_TL_NPx.A40 Change: R0, R1: Total Et TT data (not EM) AR0, AR1: Pointer to Total Et TT data (not EM) AR6, AR7: Pointer to EM Et TT Data (not Total) Add 5x5 code add memory locations for Seed pedestal-free EM Et, Tot Et change Tool compares and Object List entry writing to be much cleaner account for fact that AR0, AR1, R0, R1 contents are Tot-related, not EM-related. remove ".include macros.inc" MACROS.INC Remove all Tool-related Macros L_TOOL.INC Add Tool-related Macros START_TOOL EM_TOOL JET_TOOL WRITE_OBJECT END_TOOL ============================================================================== Date: 18-DEC-1995 At: MSU Topics: more eWjj coding L_TL_INI.A40: Add memory locations + .def: Term_Type_{0:3}_Loc Seed_Min_EM_Et_Cut_{0:3}_Loc Seed_Min_Tot_Et_Cut_{0:3}_Loc Seed_Max_Eta_Cut_{0:3}_Loc Tot_Et_5x5_Thresh_{0:3}_Loc Eta_Nplus{2:5}_5x5_Tot_Offset_Loc Change: Tool_Number_{0:3}_Loc to contain eWjj_Tool GET_LOCAL_PARAMS macro to get 8 Parameters, but not range-check the final 5. comment out the Ref Set Type check make the 5x5 Total Et Offsets but do NOT put them in the Derived Constants sections PARAM_05.A40: (this is a dummy file for testing only) Bring local + global up to current parameter map G_TL_INI.A40: Add memory locations + def's: Term_Type_{0:3}_Loc Phi_Search_Word_{0:3}_Loc Change: Number_of_Parameters_Expected = 3 (from 1) Tool_Number_Loc = eWjj_Tool GET_GLOBAL_PARAMS macro to get 3 Parameters (rather than 1) but not range-check the last 2 **** NOTE: haven't yet decided on Phi Search Mask format from TCC yet **** G_PARAMS.A40 Change expected Tool # to eWjj_Tool Assemble, link, test...at least it runs. ============================================================================== Date: 15-DEC-1995 At: MSU Topics: Start coding work on eWjj Start writing code for the eWjj Tool. So far, the following changes have been made: CONSTANT.INC: LDSP_CountList_Length 6 ( from 2 ) GDSP_Longwords_per_Entry 6 ( from 2 ) GDSP_Entries_per_List 16 ( from 32 ) add MFP_Type_3_Tool_4_Entry_Length add Tool # for eWjj_Tool add Tool_4_Derived_Const_Length change LDSP_MFP_Section_Length to use Tool_4 quantities L_PARAMS.A40: change expected Tool # to eWjj_Tool L_TL_INI.A40: change Number_of_Parameters_Expected to 8 change MFP_Derived_Const_Length to use Tool_4 quantities L_SCAN.A40: Add Term_{0:3}_Jet_Phi_Mask_Loc, clear at beginning, add .def store Term_{0:3}_Jet_Phi_Mask_Loc as LW #3:6 of the Local Count List ============================================================================== Date: 11-MAY-1995 At: MSU Topics: Test new EM_Fraction processing code. Code and test transfer for LDSP B1. Test the new EM_Fraction processing (first w/o worrying about the transfer). This testing is reasonably straightforward because the changes were limited. No change was made in the conditions under which an Object is accepted/rejected for a Term. The only changes were: - No longer abort the scan loop when the Object List has overflowed - Keep a separate Object Count for each Term which is not affected by Object List Overflows. This Object Count does NOT include failed Objects kept during MFP events. The tests were: - Verify that scan loop is not aborted upon Object List overflow during either normal or MFP events. - Verify that the per-Term Object Count is incremented (or not) when appropriate. Test this for each Eta Ring. - verify correct Count incremented when Object passes even if Object List has overflowed - verify no Counts incremented when Object fails even during MFP events - Also verify that the Object Count/Overflow Flag in the Local Object List header works as before Note that I did NOT have to revisit the topic of whether Objects were passed/failed correctly according to the Local Parameters. This did not change. After that work on the 2-part DMA transfer for LDSP B1. This involves changing quite a bit of code, especially in the L_DSP_B1 module. This will have to be carefully propagated to the other node-specific modules. The first idea is to pull the Local-to-Global-to-Next transfer definition out of the node-specific modules into L_DMACMN where a lot of other transfers are defined. This required adding some new symbols to L_DSP_xx to customize the transfer definition. A thing to watch out for is that some of these symbols are just assigned to STRINGS (which are identical to the names of other symbols) rather than VALUES (which come from the contents of symbols). This is done because the assembler will not allow: Symbol_B .set Symbol_A where Symbol_A is not well-defined (i.e. is an external reference). The assembler allows .asg "Symbol_A", Symbol_B which does not assign Symbol_B the VALUE of Symbol_A, but instead will substitute "Symbol_A" wherever Symbol_B occurs in the code. This lets me get around the problem with .set above. Test this transfer with LDSP B1. This DSP has no "previous" DSP and its "next" DSP is the Global DSP. Set up the Global DSP as an infinite sink so we don't have to worry about synchronization. Make the following tests: For normal events: - verify that the count transfer does not start until it is told - verify that the count transfer properly interrupts the CPU when finished - verify that the object transfer does not start until it is told - verify that the object transfer properly interrupts the CPU when finished - verify that the correct information is transferred to the Global DSP For MFP events - verify that the count transfer does not start until it is told - verify that the count transfer properly interrupts the CPU when finished - verify that the object transfer does not start until it is told - verify that the object transfer DOES NOT interrupt the CPU when it is finished - verify that the MFP data transfer occurs immediately after the object transfer finishes - verify that the MFP data transfer properly interrupts the CPU when it is finished - verify that the correct information is transferred to the Global DSP Verify also that we can switch between MFP events and normal events "at random." There are now 2 more classes of LDSP to fix--those with 1 previous DSP and those with 2 previous DSP's. Plus of course the Global. ============================================================================== Date: 10-MAY-1995 At: MSU Topics: Begin work on EM_Fraction code Revision 3 (Local) and Rev 2 (Global) The physics groups have requested a change in the way the L15CT handles Local Object List Overflows. The new idea is to keep a separate count of the Objects which were accepted for each Term regardless of whether they fit in the Object List or not. These new Counts will be transferred to the Global DSP before the Object Lists are transferred. The Global DSP will use these Counts, not the Objects, to determine the Term Answers. We can get back to 68K with Term Answers about 50 us faster this way, at the expense of increasing the time spent "reading out" after Front-End Busy drops. Also 68K needs to have control over shipping new ERPB data to the Local DSP's, because they won't necessarily be ready before Front-End Busy drops. Today worked on the driver documents, and started code work on the processing changes. Have also added new code to support the modified transfer, but this code is currently commented out to allow for testing the new processing without worrying about the transfer. ============================================================================== Date: 23-MAR-1995 At: MSU/FNAL Topics: Switch to EM_Fraction code Revision 2 at Fermi Steve and Dan switched the Global DSP code to use EM_Fraction (Tool 3) Revision 2. This is the revision which "correctly" sets the Terms Passed Mask from the Global DSP to the 68K during Mark and Force Pass events. This involved a change in the Global DSP code, and also a change in the 68K_Services code (only to change the Global DSP Software Revision Number, no functional changes were made in the 68K code). NO changes were made in Local DSP code, in fact none of the Local executables were even reassembled and the Local executables on D0HTCC's disk have not been touched. ============================================================================== Date: 9-JAN-1995 At: MSU/FNAL Topics: Switch to EM_Fraction code at Fermi Steve and Brajesh switched to Trigger List V10.2 which uses EM_Fraction (Tool #3) code in the L1.5 CT. The details of this swap are recorded in TRGBOOK:D0_HALL_LOGBOOK.LBK. ============================================================================== Date: 12-DEC-1994 At: MSU/FNAL Topics: Re-examine EM_Fraction code at MSU, test-load this code at Fermi Steve re-visited EM_Fraction code on the test rack at MSU. A bug was found (and fixed) in L_Tl_Np4. This bug would have caused the 1x2 EM Et sum for all objects at eta Np4 to be incorrect (it would have only included the "neighbor" tower, not the "central" tower). This bug was fixed and the fix tested. EM_Fraction code was "test loaded" at Fermi in a non-serious configuration, but removed before global running began. This was between stores #5270 and #5271. Dan Owen recorded ~200 events of noise. ============================================================================== Date: 21-NOV-1994 At: MSU Topics: Continue testing of EM_Fraction code with "abort scan loop" action, fix bug in this code A bug in L1.5 CT Global DSP code was discovered today which affects the Terms returned to the L1.5 Framework. If any Local Objects were in LDSP C2, the "Terms to L1.5 Framework" byte could have had extra bits set that should not be (i.e. a Term might have been answered "yes" when it should have been answered "no"). - relatively infrequent that LDSP C2 has local objects (it services eta +19, +20 ). - Terms never accidentally cleared (i.e. never rejected an event which should have been kept) - If LDSP C2 has an Object, the event should have been kept (according to the Parameters which have always been used in L15CT). i.e. we probably never kept an event which should have been rejected. This bug has been present in the DSP software running at Fermilab since approximately 18-AUG-1994. The bug has been fixed in the EM_Fraction DSP code, but we will NOT change the code running at Fermilab since the bug is not damaging triggering. Offline testing people may discover it by looking at the "Terms returned to L1.5 FW" byte in the L1.5 Cal Trig Data Block, but it is not likely. Continue testing "abort scan loop" action in DSP code, using Test Stand at MSU and "baby no-check DSP control" 68K software running on MVME133. ------------------------------------------------------------------------------ Date: 18-NOV-1994 At: MSU Topics: Add "abort candidate scan if Local Object List overflowed." Minor simple speedups, timing measurements of code fragments, how to "correct" 8-JUL-1994 timing measurements for current code. work on test stand at MSU. Added and tested the "abort candidate scan upon Local Object List overflow" behavior to Local DSP code AT MSU ONLY. This costs nothing for "normal" event processing. Also converted a few BR's into BRD's or BRAT's where clearly safe (and testable) to do so. Did NOT change anything in Node- Specific modules. Timing measurements of code fragments at MSU: Local DSP recognizing that all ERPB Data has arrived to Local DSP signalling 68K that Local-to-Global-to-next Transfer has begun (assuming no PREVIOUS LDSP in chain): 29.1 us [ this is the Candidate Scan, with no Tool Calls, and with a few instructions executed before and afterwards -- this was not directly measured in the 8-Jul-1994 measurements ] ONE Local Tool Call: all 4 Terms FAIL: 8.6 us ONE Local Tool Call: all 4 Terms PASS: 11.2 us [ i.e. each "Object Write" costs (11.2 - 8.6)/4 = .65 us ] [ tested: can interpolate to get 1, 2, 3 Terms PASS ] 128 Local Tool Calls: all 4 Terms FAIL: 1092.8 us [ this is approximately 128 * 8.6 us, again can interpolate to get 2, 3, ..., 127 Local Tool Calls ] Sanity check on Local Tool Call timings: 8-JUL-1994 timing measurements gave 3.6 us/Tool Call. Note that this measurement was for 1x2 Isolation Tool evaluating one Term. migration to 4 Terms added 20 instructions = 1 us per additional Term (i.e. the 3 additional Terms gave 6.6 us/Tool Call as quoted in TI and NSS papers--I believe that this measurement was for FAILURE of all 4 Terms). addition of EM_Fraction (while still keeping Isolation) added 2 us to bring us to 8.6 us/Tool Call (for FAILURE of all 4 Terms). [ find and store Total Et of "nearest neighbor" ] 3 instructions per Neighbor * 4 Neighbors = 12 inst. [ calculate EM Fraction and set "reject" flag if needed ] 7 instructions per Term * 4 Terms = 28 inst. (12 + 28) instructions * 50 ns per instruction = 2 us [ dropping Isolation would gain about 20 + 4*7 = 48 inst. or 2.4 us ] Adjustments to 8-JUL-1994 timing: (1) Local DSP's Each Local Tool Call: 3.6 us --> 8.6 us (4 Terms FAIL) to 11.2 us (4 Terms PASS) (2) Global DSP's In the Global DSP's, the measured "Global DSP recognizes that all Local Object Lists have arrived until Global presents Term Answers to 68K" time of 2.5 us must be broken up into the following categories: GDSP recognizes Object Lists until Global Candidate Scan Finished 3.70 us Each Global Tool Call w/ 1 Object 0.9 us (i.e. 1 Object in 1 LDSP) (each additional Object in 1 LDSP) 0.45 us GDSP Candidate Scan Finished until GDSP presents Terms to 68K_Services 1.25 us (3) 68K_Services The only major 68K changes since 8-JUL-1994 do not affect the timing flow between "Start Digitize HIGH" and "Front-End Busy LOW" for an individual event which occurs in isolation. Only the time required for readout and preparing for the next event (and thus the maximum throughput of the L1.5 CT) were affected, and they were most likely improved. If we define the "standard" situation (for measurement purposes ONLY, not implying that this is the most frequent occurence) as: "1 candidate in 1 Local DSP, passing 1 Term and making 1 Object in its Local Object List" then the 8-JUL-1994 measurement of "Start Digitize rising edge until Hold Transfer falling edge" of 131 us becomes: 131 + (8.6 + .65 - 3.6) + (3.70 + .9 + 1.25 - 2.5) = 140 us note that the L1.5 CT actually presents its Answers to the L1.5 Framework approximately 10 us before the falling edge of Front-End Busy, or at 130 us. Start to re-build Test Stand at MSU using MVME133 rather than MVME135. Install MVME133, modify "baby 68K software" to use 133 rather than 135, add a PDM "take" file to make Hydra-II VSB Crate Controller (DO NOT do this in DSP code but rather from the outside via a take file), add 2.7 Kohm pull up resistors on Hydra-II BGIN* and BGOUT* lines. Control software looks OK but Hydra-II cannot see MVME214. What is wrong? ANSWER: No VSB terminators. ------------------------------------------------------------------------------ Date: 17-NOV-1994 At: MSU Topics: Start L15CT.LBK, remove "temporary" double-checking and history-keeping of Event Type (MFP vs. "normal") Create offical L1.5 Cal Trig Logbook: TRGBOOK:L15CT.LBK. At MSU ONLY, remove "temporary" code near the beginning of L_SCAN.A40 which double-checks the event type and keeps a history of the event type for the last 2 events. This piece of code was used to debug an early problem with event type checking which was traced to an Interrupt Service Routine which was munging a register. This test code cost approximately 900 ns between receiving the Wakeup Word and first starting to look for the arrival of all ERPB data. This 900 ns wasn't really "in the way," but it served no useful purpose and would have become a factor when we speed up the starting of the ERPB Data Transfer. ------------------------------------------------------------------------------ ****************************************************************************** ----- Steve's formerly "private" L1.5 Cal Trig DSP code modification logbook ----- is appended below Level 1.5 Calorimeter Trigger DSP code time summary and logbook =============================================================== 3x3 vs. 5x5 --> 1x2 vs. 3x3 modification ======================================== E-mail negotiations with Dan Owen on specification -------------------------------------------------- 2,4-April-1994: 1 hour 11-MAY-1994: 1 hour Total 2 hours Writing formal specification ---------------------------- 6-APR-1994: 1 hour 15-APR-1994: 3 hours 19-APR-1994: 15 minutes 10-MAY-1994 30 minutes 11-MAY-1994 30 minutes Total 5 hours 15 minutes Writing notes for driving Tool Code development ----------------------------------------------- 20-APR-1994: 1 hour 10-MAY-1994: 30 minutes 11-MAY-1994: 30 minutes Total 2 hours Writing code ------------ 10-MAY-1994: 1 hour 11-MAY-1994: 4 hours 12-MAY-1994: 1 hour 13-MAY-1994: 2 hours 16-MAY-1994: 1 hour Total 9 hours Testing code ------------ 11-MAY-1994: 1 hour 12-MAY-1994: 5 hours 13-MAY-1994: 3 hours 16-MAY-1994: 3 hours Total 12 hours Grand Total 28 hours 15 minutes Minor changes made between 16-MAY-1994 and 15-JUN-1994 =================================================== Code 100% frozen from 15-JUN-1994 until 16-AUG-1994 =================================================== Working code archived into [TRG_C40.ARCHIVED_1X2_SINGLE_TERM_CODE...] on 16-AUG-1994 Next major revision begun: "Single Tool Multiple Terms/Parameter Sets" 15-AUG-1994 ----------- Negotiations with Dan Owen and Dan Edmunds about what the next step should be. Need to solve immediate problem--L15CT must be applied to multiple Specific Triggers with multiple parameter sets but the same Tool. Time spent: ---------- 2 hours discussion with Dan E/Dan O about what to do 4 hours writing high-level description about what we will do (description sent to Dan E/Dan O/Philippe 1 hour reviewing code to develop plan of attack 16-AUG-1994 ----------- Currently running code archived into [TRG_C40.ARCHIVED_1X2_SINGLE_TERM_CODE...] Work on Common and Local code: in MACROS.INC - COMPARE_1X2 gets threshold as argument - COMPARE_RATIO gets threshold as argument - TOOL_ACCEPT_REJECT gets rewrite to not exit to Scan - TOOL_SUCCESS removed - END_TOOL added in L_Tl_Ini.A40 - Receive 4 sets of parameters - space for 4 Type 3 Entries (common data between entries is just duplicated) in L_Tl_Np%.A40 - change syntax to use new macros - evaluate 4 Terms instead of just 1 in Constant.Inc - change a few constants in L_DSP_%%.A40 - ideally nothing would have happened, but the "MFP_DC_Section_Length" was something + 1 and it really now needs to be something + 4 (because there are 4 Type 3 Entries now). I changed it to just be something, and took care of the +4 in L_Tl_Ini. Testing--looks OK at first pass. Time spent ---------- Coding: 7 hours Testing: 1 hour Documenting: 1 hour 17-AUG-1994 ----------- Work on Global code, add "intelligent Object List scan." in G_Scan.a40 - Add Object List scan which calls a tool if any Valid Objects are in a List - Add Threshold comparisons for new Term evaluation add modules G_Tl_Evn.a40, G_Tl_Odd.a40 - These are the multi-Term Global Tool modules Time spent: ---------- Designing structure: 4 hours Coding: 3 hours Testing: 2 hours 18-AUG-1994 ----------- Add downloadable Parameters to Global DSP code: in G_Params.a40 - remove the Parameter range checking, migrate this to G_Tl_Ini.a40 - Modify status to TCC generation to support G_Tl_Ini.a40 add module G_Tl_Ini.a40 - This does Global Tool Initialization, similar to L_Tl_Ini Negotiate with Owen about how to hide the 4-Term requirement from COOR--TCC will take up the slack via a DEFAULT_CONFIG file. Reset version #'s to 1 and copy source and executables to FNAL. Time spent ---------- Negotiation: 2 hours Designing structure: 1 hour Coding: 2 hours Testing: 3 hours ============================================================= Software 100% frozen between 18-AUG-1994 and mid-October 1994 ============================================================= Working version archived 18-OCT-1994 into MSUTRGROOT:[TRG_C40.ARCHIVED_1X2_3X3_ISOLATION_CODE...] mid-October 1994 ---------------- Understand from R. Genik/D. Owen that isolation is not optimal---the 3x3 Total Et is "too big" (spatially), and good W-electrons can be lost (same effect has been seen by Meena). EM_Fraction is proposed. Negotiate details verbally with Dan Owen. 18-20 October 1994 ------------------ Official written driver document negotiated with D. Owen, also an "executive summary" of the changes is released with the driver document. High-confidence-level verbal approval from D. Owen. Time spent ---------- Negotiation: 2 hours Specification: 3 hours 19-OCT-1994 ----------- Modify L_Params, L_Tl_Ini to recognize new Tool Number (3) and additional Parameter (also change limits on both "ratio" parameters). Modify G_Params, G_Tl_Ini to recoginize new Tool Number (3). Modify COMPARE_RATIO macro to be generic (so it can be used for both "ratio" compares). Modify L_Tl_Np2 to calculate 1x2 Total Et and also reject on all 3 Parameters. Modify other Local Tools to reject on all 3 Parameters (but not yet calculate 1x2 Total Et). Test initialization, Parameter passing, L_Tl_Np2 data addressing, rejection, Data Block building. Time spent ---------- Designing structure: 2 hours Coding: 3 hours Testing: 4 hours 20-OCT-1994 ----------- Modify other Local Tools to calculate 1x2 Total Et. No tests performed. Time spent ---------- Coding: 3 hours 24-OCT-1994 ----------- Test Local Tool data addressing, rejection, Data Block building Time spent ---------- Testing: 3.5 hours Fixing errors: 0.5 hours Clean up directories at MSU, transfer new good source and executables to D0 (NOT to TCC!). We do NOT start using this code in running system at this time. ****************************************************************************** ----- The file ARIEL_HARDWARE_SOFTWARE.LBK has been removed. Its ----- contents are now below. ************************************************************************ Key to comment codes: !How-to! = How-to "tip" !Set-up! = Set-up comment !CommPt! = 'C40 Communication Port information ************************************************************************ Date: Topics: ************************************************************************ Date: 19-JUL-1994 Topics: Receive repaired Hydra S/N 7010 (MSU S/N-1) We received the repaired Hydra-II S/N 7010 (MSU S/N-1) today. It appears to have been repaired correctly. We also received some errata sheets for the Hydra User's Guide, but they still appear incorrect in some aspects (for example, the NMI/IIOF2 interrupt tables described in the 15-FEB-1994 entry of this file are still incorrect). We also received a Hydra System Software User's Manual and a Hydra Bus Mastership User's Manual. Both of these manuals describe software that we do not currently use. ************************************************************************ Date: 14-JUL-1994 Topics: Contact at Ariel for repair work Today I received a call from Dave Durning at extension 261. He called to let me know that the Hydra-II card is now really fixed (after its second trip back to Ariel). He said that we should call directly to him if we have other repair problems. email DDurning@Ariel.com ************************************************************************ Date: 15-FEB-1994 Topics: Hydra Interrupt Control Registers The description (found on pages 29-31 of the Hydra-II User's Manual) of the Interrupt Control Registers is incorrect. The best estimate of the correct information is as follows: All of the text appears to be correct. Tables 2-14 and 2-15 are wrong. We think the correct tables are as follows: Table 2-14 IIOFMUXA IIOFMUXB *IIOF2EN Interrupt Source Comment -------- -------- -------- ---------------- ------- X X 1 Disabled correct in book 0 0 0 Push Button correct in book 0 1 0 GND not VSB! 1 0 0 VSB IRQ* not GND! 1 1 0 Mailbox Interrupt correct in book (i.e. in the table in the book it appears that IIOFMUXA and IIOFMUXB have been swapped) Table 2-15 (this table as given in the book is gibberish) NMIMUXA NMIMUXB *NMIEN Interrupt Source -------- -------- -------- ---------------- X X 1 Disabled 0 0 0 Push Button 0 1 0 GND 1 0 0 VSB IRQ* 1 1 0 Mailbox Interrupt (i.e. the logic for NMI is exactly the same as the logic for IIOF2). The data for determining this was obtained by testing the various sources of interrupt. We discovered that programming the IIOF2 source as GND (according to the table in the book) with the VSB bus terminated (i.e. VSB IRQ* pulled high [inactive]) resulted in NO IIOF2 interrupt to the C40. Removing the terminators (allowing IRQ* to drift low) resulted in the C40 receiving an IIOF2 interrupt. The NMI responded in the same fashion. Under all tested situations, programming NMI or IIOF2 for the VSB interrupt always resulted in an interrupt being sensed by the C40. That is, programming the ICR to use the VSB Interrupt as the source resulted in behavior consistent with GROUND being used as a source and vice-versa. We conclude that the tables 2-14 and 2-15 are incorrect and provide replacement tables. ************************************************************************ Date: 14-JAN-1994 Topics: Setup of the VSB bus interface on the Hydra-II See the file: [D0_Text.Level_15.CalTrig.Hardware_Software_Text] VSB_Setup_Hydra_II_and_MVME135.txt for a discussion of setting up the VSB bus interface on a Hydra II card. ************************************************************************ Date: 6-DEC-1993 Topics: Receipt of 4 Hydra-II Packages, 1 Assembler Package, and 2 Debugger Packages Today we received the following from Ariel: 1. Four (4) Ariel Hydra-II Hardware and related manuals included in each package were: BOOK: Preliminary User's Manual for the no number found Hydra-II Document Version 0.20, September 1993 BOOK: Motorola MVSB2400 VSBChip User's Manual MVSB2400UM/D3 (June 1991) BOOK: Cypress Semiconductor VIC068A/VAC068A No number found User's Guide (June 1992) BOOK: TI TMS320C4x User's Guide (1991) SPRU063 aka 2564090-9761 Rev. B CABLE: 8-pin round DIN to DB-25 female No number found ADAPTER: DB-9 female to DB-25 male No number found (RS-422 to RS-232 adapter) ADAPTER: DB-25 male to DB-25 male No number found (gender bender) HARDWARE: Ariel Hydra-2-4-S1 Revision B S/N 7044, 7052, 7047, 7046 1. One (1) TI 320 Floating-Point DSP Assembly Language TMDS3243850-02 Tools PC Release 4.50 (dated 18 Dec 1992) aka 2617572-0641 Rev. B included in this package were: BOOK: TI TMS320 Floating-Point DSP Assembly Language Tools User's Guide (1991) SPRU035A BOOK: TI TMS320 Floating-Point DSP Code Generation Tools Release Notes (1992) 2564094-9741 Rev. C BOOK: TI Hex Conversion Utility Addendum to (SPRU081) TMS320 Assy. Lang. Tools U.G. (1992) 2617615-9741 Rev. * BOOK: TI Microprocessor Development Systems Products Customer Support Guide 2563578-9741 Rev. C DISKS: TI 320 FLT-PT DSP Assembly Language 2617572-1641 Rev. B Tools Rev. 4.50 MS-DOS and OS/2 Disks and 1 and 2 (5.25" high-density floppies) 2617572-1642 Rev. B (dated 21-Oct-92). 3. Two (2) White Mountain Mountain-510/40 Emulator (JTAG Debugger) Systems included in each package were: BOOK: TI TMS320C4x C Source Debugger User's 2547296-9671 Rev. A Guide (1992) (SPRU054) BOOK: TI Parallel Debug Manager Addendum to 2617619-9741 Rev. * the TMS320C4x and TMS320C5x C Source (SPRU094) Debugger User's Guides (1993) BOOK: Mountain-510/40 System Installation No number found Guide (1993) Rev. A DISKS: White Mountain DSP Mountain-510/40 No number found System disks. These are 2, 3.5" disks. HARDWARE: White Mountain DSP Mountain-510/40 Rev 2 (C) S/N CB5D180B, CB50170B HARDWARE: White Mountain DSP Mountain-510 Adapter Pod ************************************************************************ Date: 24-NOV-1993 Topics: Calls to Ariel about the AXDS-PCX Debugger We received a call from Steve Curtin from Ariel about the AXDS debugger. He now understands the reason why we need it. He suggested that we purchase one from White Mountain DSP system (603-883-2430). I said no, that it would take too long to get a PO and I did not want to spend the extra $xk. His best estimate is 2 or 3 week of December for theirs to ship. His email username is src. He said that Ted Reinwalt (sp) is the main Hydra person at Ariel. I'm emailing to Steve Curtain the Nov 2nd note from Tony that said an AXDS would ship ASAP. ************************************************************************ Date: 22-NOV-1993 Topics: C40 Simulator Matt today figured out how to generate interrupts on the simulator. To generate an interrupt, you modify the appropriate CPU register in the register window setting the appropriate interrupt flag bit. Also discovered that when specifying addresses in hex you need to use the 'C' type format of 0x* not *h or *H. The simulator assumes decimal as the default and ignores the h or H at the end of an address. The simulator can use either the object code from the assembler or the COFF file from the linker. But the COFF code is preferable because it will be put the code into the appropriate memory locations. ************************************************************************ Date: 22-NOV-1993 Topics: OS/2 command scripts Matt created several OS/2 command scripts for assembling, linking, and hex converting. The command scripts are on the PC in the C40play directory and are also on the TRGUSER account in the DSP_WORK directory. asm .a40 This command script will assemble the source code, generate a object file and a listing file. There name will be .o40 and .lst. You provide only the first eight letter of the file name, the script assumes .a40 extension. link .o40 This command script will link your object file(s). It will create a COFF file called .x40 and a map file called .map. It uses hydra2.lnk which defines the hydra2 memory map. If you need to link multiple files, or have different sections located in memory other than the onboard RAM you will need to use an additional linker command script or edit hydra2.lnk to your needs. hex .x40 This command script will produce a bootloader ready file in motorola s-records format called .hex. It will also produce another map file called .mxp. It uses the file called hex.dir which contains the dirrectives for setting up the bootloader. Make sure the correct values for the local and global MICR's are being used for the DSP that the code will be executed on. ************************************************************************ Date: 12-NOV-1993 Topics: Com Ports !Comm-Pt! also DEFINES.EQU include file defined Steve experimented today with Comm Ports. I was able to transfer data from one DSP to another via the Comm Ports. I was able to turn the token around (i.e. perform a write to a Comm Port which wakes up as an input port and the Comm Port becomes an output). An important thing to note is that upon processor reset, the Comm Port FIFOs are cleared. This means that it is not possible to load and run a "Comm Port writing" program on DSP #i, and THEN load and run a "Comm Port reading" program on DSP #j (connected to DSP #i via Comm Port). Loading the program involves a processor reset, and the data stored in the Comm Port Input FIFO on DSP #j is lost at reset. I also broke the standard constants and macros out from my source code and created DEFINES.EQU which defines constants and macros. ************************************************************************ Date: 12-NOV-1993 Topics: Utilization of the IIOF lines on the HydraII After reading through the HydraII manual, I beleive that the IIOF lines are used in the following way, but if you think I have made an error please let me know(Matt). IIOF0 DSP#1 Connected dirrectly to the UART Needs to be setup as a negative edge triggered interrupt. DSP#2 It is used as an output to access the VSBTCR. It should be 1 for normal operation of the local bus SRAM, and it should be set to 0 to access the VSBTCR when ever the LSTRB0 is active. DSP#3-4 It is available on the expansion port. It has a 1K pull-up resistor on the HydraII card. IIOF1 DSP#1-4 This line seems only to be used by the boot control register during reset, to specify where to boot from. Changing the boot control register after reset has been removed does not seem to effect the signal the 'C40 receives. IIOF2 DSP#1-4 This line is also used during boot up, but after reset has been removed and the first IACK has occured this line becomes an interrupt source to the 'C40. The signal can be programmed to come different sources. See the HydraII manual page 28. IIOF3 DSP#1-4 This line is also used during boot up, but after reset has been removed. It can be used to generate VME interrupts from the 'C40. See the HydraII manual page 18. ************************************************************************ ************************************************************************ Date: 11-NOV-1993 Topics: More interrupt-driven DMA, notes on assembler, notes on LDI instruction Today Steve got interrupt-driven DMA working properly, including allowing the DMA Controller to generate a CPU interrupt for signalling. Matt discovered a bug in the 'C40 assembler. It can be illustrated with the illegal instruction: sti 0ffffh, @SomeAddress ; would it assemble with ANY ; immediate operand? The obvious problem with this instruction is that immediate sources are not allowed with the sti instruction. However, the 'C40 assembler happily assembled this instruction. The opcode indicated a store, with a REGISTER source, and the 5-bit register code was 1fh. This is not a valid register code. It is important to note that the 'C40 silicon will EXECUTE this instruction. The result is that, after execution, the value 0ffffffffh will be stored in the longword located at SomeAddress. The odd thing is that this is exactly what this instruction would do if it were allowed. I should try this instruction with a different immediate operand (i.e. not 0ffffh) and see whether the assembler allows the instruction. Note that immediate operands are sign-extended. ************************************************************************ Date: 10-NOV-1993 Topics: Interrupt-driven DMA operation Steve tested interrupt-driven DMA programs today. The DMA Control Registers are described in section 9.3 of the 'C40 User's Guide. The DMA Interrupt Enable (DIE) register is described in section 3.1.8. The DMA Controller Memory Map is given in section 3.4.2.5. First note that not every DMA controller can be driven by every interrupt. In particular DMA Channels #0 and #1 have limited control of their interrupt sources. Next note that for a DMA controller to be driven by an interrupt, it is NOT NECESSARY for the interrupt to be enabled as a CPU interrupt (in the IIF register). I also think (but have not yet proven) that it is not necessary to set the global interrupt enable (GIE) bit in the status register. Also, note that "interrupt-driven" DMA operation actually is more properly called "interrupt-synchronized" DMA operation. That is, a single interrupt will force the DMA Controller to perform A SINGLE DMA cycle (NOTE: not the whole DMA list). This is at least the case for edge-triggered interrupts. I have not tested level-triggered interrupts. On page 9-40 of the 'C40 User's Guide there is a comment that it is best to use edge-triggering with external interrupts to ensure that only one interrupt is recognized. That leads me to believe that using level-triggered interrupts works but if the DMA controller auto-initializes it may cycle through its list more than once. If the controller does not auto-initialize it could be forced to only run its list once but there is no guarantee that it would finish (i.e. if the interrupt was removed halfway through the list the controller would stop transferring). If one desired to transfer an entire DMA list based on an interrupt the best way is to use a "two-element" DMA list. The first element would be a "dummy" transfer which is synchronized to an interrupt, while the second element would be the "real" unsynchronized transfer. See for example Example 12-51 on p. 12-107 of the User's Guide. Another way I can think of is to have the CPU handle the interrupt and have an interrupt service routine that kicked the DMA controller. This has some cost in CPU cycles but not as much as doing the whole DMA list via CPU transfers. Finally, note that if the DMA controller is to be auto-initialized, then you must store a "clean" set of auto-initialize values in memory. That is, you cannot just set the Link Pointer to point to the Control Register of the DMA Controller. ************************************************************************ ************************************************************************ Date: 10-NOV-1993 Topics: C40 MICR usage with the HydraII There is no difference between the local and global MICRs from the C40's point of view other than the local bus uses the lowwer half of the address space while the global uses the upper half of the address space. The MICR's control the cutoff position in the address space at which the C40 switches from STRB0^ to STRB1^ active. STRB0^ will be active form the bottom of it's busses address space to the cutoff-1, while STRB1^ will be active form cutoff to the top the busses address space. On the HydraII the cutoff is always set at the bottom of the SRAM on that bus. The next two parameters you can control is the page sizes of the memories conected to the STRB0^ and the STRB1^ signals. The MICRs also control the generation of the memory ready signal. Each STRBx^ signal can be controled seperately. There are 4 modes available (see table below). If internally generated wait states are needed you can program from 0 to 7 H1 clock cycles. There is also 1 bit to control the addition of 1 delay cycle when switching strobes, in all cases Arial has set it to 0, which corresponds to no delays. For detailed breakdown of the register see the TI C40 reference guide at the begining of chapter 7. The following is the values that Ariel is using for each of the MICRs and there meaning. Global MICR on DSP#1-4 is set to 1DEA4000h. This corresponds to STRB0^ active range of 8000 0000 to BFFF FFFF page size of 1Kwords uses externally generated ready signal connectted to the shared dual port RAM STRB1^ active range of C000 0000 to FFFF FFFF page size of 1Gwords uses externally generated ready signal connectted to the global SRAM Local MICR on DSP#1 is set to 1DE70750h. This corresponds to STRB0^ active range of 0000 0000 to 3FFF FFFF page size of 512Mwords uses internally generated ready signal of 7 wait states connectted to the flash memory and the UART STRB1^ active range of 4000 0000 to 7FFF FFFF page size of 512Mwords uses internally generated ready signal of 0 wait states connected to the local SRAM Global MICR on DSP#2 is set to 1DCC4000h. This corresponds to STRB0^ active range of 0000 0000 to 3FFF FFFF page size of 256Kwords uses externally generated ready signal connected to the VSB interface (STRB0^ is also connectted to the VSBTCR in which case the MICR should be set to 1DCC4010. Which uses an internally generated ready signal of 0 wait states) STRB1^ active range of 4000 0000 to 7FFF FFFF page size of 64Mwords uses externally generated ready signal connected to the local SRAM Global MICR on DSP#3-4 is set to 1DCC4000h. This corresponds to STRB0^ active range of 0000 0000 to 3FFF FFFF page size of 256Kwords uses externally generated ready signal not connected to anything, but is available through expansion port STRB1^ active range of 4000 0000 to 7FFF FFFF page size of 64Mwords uses externally generated ready signal connected to the local SRAM ************************************************************************ Date: 9-NOV-1993 Topics: Notes on 'C40 interrupts Steve today wrote and ran a program which is interrupt-driven. There are multiple classes of interrupts. One important division between interrupts is the NMI vs. all other interrupts. The NMI is "hard-wired" as an edge-triggered, latched interrupt. It is always enabled. The other interrupts are programmable. A sub-class of "other interrupts" is the IIOF(3..0) interrupts. These interrupts must be programmed in both the IIF register, and "globally enabled" in the ST register (using the GIE bit). These interrupts may be either edge-triggered (latched) interrupts or level-triggered (unlatched) interrupts. A single assertion of a level-triggered interrupt may call its interrupt service routine multiple times, depending on how long the interrupt is asserted for, and how long the ISR takes to execute, i.e. if upon return from the ISR, the interrupt is still asserted (and enabled, and no other interrupt must be serviced...) then the ISR will be called again. If the interrupt is defined as an edge-triggered (latched) interrupt, a single assertion of the interrupt results in (at most) one execution of the ISR, i.e. if upon return from the ISR, the interrupt is still asserted, the ISR will not be executed again. The ISR routine does not need to know whether it is called by an edge- triggered or level-triggered interrupt. That is, the return from interrupt is the same in both cases (a reti instruction). The "clearing" of the latched interrupts is handled by the 'C40 naturally (i.e. the "user program" or "isr" does not need to handle the clearing of interrupts). Note that a stack pointer must be defined in order for the interrupt servicing to operate as expected. ************************************************************************ Date: 5-NOV-1993 Topics: Second try with the DSP program Steve today succeeded in assembling, linking, loading, and running a simple DSP program. The program is in TRGUSERROOT:[DSP_WORK.STEVES_CODE. C40]FLASHLED.HEX. In TRGUSERROOT:[DSP_WORK.STEVES_CODE.68K] there is a program to copy 1023 S-Records from $40000 (MVME135 on-board RAM) to $A00000 (Hydra-II Dual-Port Shared Memory). The copy is done with longwords and there are no changes made in the data as it is moved from $40000 to $A00000. This program should be loaded and executed at address $30000 (again MVME135 on-board RAM). Before we write too many of these toy 'C40 and 68K programs we must make a list of the programs we want. I have created a directory: MSUTRGROOT:[D0_TEXT.LEVEL_15.CALTRIG.HARDWARE_SOFTWARE_TEXT] in the TRIGGER account (both at MSU and D0). This is where we should make notes about the software that exists and what we want to do. It probably isn't the final division we'll make but we need to do something. We need to call Ariel sometime soon (not necessarily immediately). When we call we should address all questions we can think of. So, as we think of questions add them to a list in the HARDWARE_SOFTWARE_TEXT directory I have created. DON'T PUT QUESTIONS IN THIS LOGFILE OR WE'LL NEVER FIND THEM. I read the SUN/OS device driver disk. The files are sitting in Steve's account on the Engineering computers (not the Physics VAX). It is a big directory structure but a lot of it is a repeat of the DOS disk. Steve will sort out the wheat from the chaff and then bring the wheat to (somewhere) on the Physics VAX (which account??). ************************************************************************ Date: 4-NOV-1993 Topics: Writing, assembling, linking, and boot-loading a DSP program Today Steve wrote a simple DSP program for the 'C40. The development work was done in the TRGUSER account, in the new directory tree TRGUSERROOT:[DSP_WORK.STEVES_CODE.C40]. The notes for today summarize the steps involved. (1) Writing the DSP code I wrote a very simple program to access the Global Dual Port RAM. I used the 'C40 User's Guide as my assembly language reference book. Nothing particularly stunning was learned, except perhaps that it is not possible to use immediate addressing with a 32-bit (immediate) operand. Also I learned that, for reasons that become apparent at link-time, it is useful to label the first executable instruction of a program, and specify that label as a global label using the ".global" assembler directive. The program did not make use of interrupts, or HydraMon, or anything even remotely complex. The program was written on the VAX and ftp'd to prospero. (2) Assembling the DSP code. Steve wrote an OS/2 command file to call the assembler. This command file is called flashasm.cmd. This file calls the assembler with the following command line (the assembler must be called once for each assembly language source file -- the simple program for today had only one source file): asm30 flashled.a40 flashled.o40 -v40 -l -q -DVC40II=1 ^ ^ ^ ^ ^ ^ ^ | | | | | | ` ????? | | | | | | | | | | | ` "quiet" mode | | | | | | | | | ` make listing file | | | | (flashled.lst) | | | | | | | ` produce c40 code (not c30 code) | | | | | ` object (output) file specification | | | ` source (input) file specification | ` the assembler program on prospero This command file was based on a command file written earlier by Dan (which was based on a command file from Ariel). The input file to this command is: flashled.a40 source file The output files from this command are: flashled.o40 object file flashled.lst listing file (3) Linking the DSP code Steve wrote another OS/2 command file [flashlnk.cmd] (again based on Dan's, which was based on Ariel's) to call the linker. This command file calls the linker with the following command line: lnk30 -e flash_led -o flashled.x40 flashled.lnk ^ ^ ^ ^ | | | ` linker command file | | | (input) specification | | | | | ` executable (output) file specification | | | ` global label pointing to first executable instruction | ` the linker program on prospero Additionally, Steve wrote a linker command file (flashled.lnk). Each object file which is to be included in the executable (output) file must be listed in the linker command file. Additionally, the memory model of the program, and the locations of the start of the various sections (i.e. .text, .data, .const, etc) must be specified in the linker command file. Note that this description in the linker command file should describe where the program should RUN in 'C40 memory. For an example of a linker command file see the TI TMS320 Floating-Point DSP Assembly Language Tools User's Guide, or any of the various command files written by Dan and/or Steve in the TRGUSER account or on the PC. The input files to this command are: flashled.lnk linker command file (all object code modules specified in flashled.lnk, in this case only flashled.o40) The output files from this command are: flashled.map map file flashled.x40 executable file (4) Creating an on-chip ROM Boot Loader loadable image Steve then wrote a hex30 (Hex Conversion utility) command file (not an OS/2 command file, the name of this command file CANNOT be typed at the command line prompt) to create an on-chip ROM Boot Loader loadable image of flashled. This command file is called by typing: hex30 flshboot.cmd at the OS/2 command prompt. The command file flshboot.cmd looks like the following: FlashLED.X40 /* Input file, this is the Linker output */ -o FlashLED.hex /* Output filename */ -m /* Motorola S Format */ -map FlashLED.map /* Map filename */ -memwidth 32 /* Memory system width */ -romwidth 32 /* ROM width */ -byte /* Number output file by BYTES */ -boot /* Convert all Sections into bootable form */ -bootorg 000000000h /* Addresses in S-records will begin at 0 */ -e 0002ff800h /* Force execution to start at "flash_led" */ -cg 01dea4000h /* Global Memory Configuration Register */ -cl 01dcc4000h /* Local Memory Configuration Register */ -ivtp 0 /* Interrupt Vector Table Pointer */ -tvtp 0 /* Trap Vector Table Pointer */ -iack 040000000h /* IACK memory location */ Some of these options are obvious and some are not. I will treat them one-by-one: -o: specify output file name (in this case output will be S records) -m: generate Motorola S-Records. This will only generate S1-type records (with 2-byte address fields in the range 0000-FFFF). This will be a difficulty for us, as we would ideally like S3 records. -map: specify map file to use. The map file is generated by the linker -memwidth: specify memory-system width. This should be 32 (bits) for the Dual-Port memory. This value will be used to generate the "memory width" word used by the on-chip ROM Boot Loader. If not specified it will default to 32. -romwidth: this should actually be called "output file width." Again it should be 32 (bits). Recall that we are only using one output file. This option is used to generate byte-wide output files useful for programming byte-wide ROMs. If not specified it will default to 32. -byte: specify addresses in the output file should increment by bytes (not words or longwords). This is necessary for S-Records. S-Record addresses increment by bytes ("character pairs"). -boot: generate an on-chip ROM Boot Loader readable image. -bootorg: specify the address from which to boot. This does not make sense to me. The address from which to boot is specified by the IIOF(3..1) pins on the 'C40, which are driven by the Boot Control Register on the Hydra-II. I think this line actually only controls the address field of the output file (in our case S-Records). -e: Address from which to begin execution. This is an address in 'C40 format which specifies the location of the first executable instruction. This option is not needed if the first word of the executable (filespec.x40) is the first executable instruction. -cg, -cl: The MICR word for the "global" and "local" address busses. These have been copied directly from the Hydra-II manual. I do not yet fully understand them but am just using them "as-is." It is important to decode these values soon. -ivtp, -tvtp: The addresses for the IVTP and TVTP. These are 'C40 addresses. I have left them blank for now because I am not using interrupts. -iack: IACK memory location. (5) Copy the image into the Dual Port RAM I tried to use MVME-135BUG to load the S-Records into the Dual Port memory. This did not work. First, the addresses in the S-Records were only 16-bit addresses (S1 format). This can be fixed by using an offset load (lo A00000;x=type flashled.hex) to add A00000 hex to the address specified in each S-Record. That is just fine but the Dual-Port memory must be accessed as longwords. 135BUG did not do that, but probably accessed the memory as bytes. IS THERE AN OPTION TO LOAD TO FIX THIS???...MUST CHECK IN 135 BOOK. Either I must find a way to cause 135BUG to write as long-words or I will resort to the "Dan-standard" 2-step method. I can just copy Dan's "copy_s_record" program and modify it a bit. So I did not actually execute my program on the 'C40. I didn't even load it but I have made progress with the tools (which is the important thing). ************************************************************************ Date: 3-NOV-1993 Topics: Loading Hydra-Mon into a DSP using the on-chip ROM Boot Loader (assuming Hydra-Mon is stored in the DP RAM as described by Dan's note of 3-NOV-1993) First, an "on-chip ROM Boot Loader"-readable image of Hydra-Mon must be assembled and stored in the Dual Port RAM [beginning at address $A0 0000 in VME space/address 8000 0000h in DSP space]. The generation of this image is described in Dan's entry of 3-NOV-1993 "Making a Loadable Program Image...". Hydra-Mon, once running, requires two arguments: the DSP # (which is provided by the HOST, not innate to the DSP [although by convention Ariel has defined DSP #1,2,3,4 as described in the various documents. We will use that convention as well when providing the DSP# argument to Hydra-Mon {in fact we will use that convention WHENEVER we refer to DSP#'s}]), and the interrupt # which should trigger Hydra-Mon. Note that the interrupt # should be provided as the offset into the IVT corresponding to the appropriate interrupt. See the 'C40 User's Guide page #3-16 for details of the IVT. I loaded Hydra-Mon to DSP #3, and told it to trigger on interrupt IIOF2 (which is offset #5 in the IVT). This was done by modifying the "argument area" in the Hydra-Mon "on-chip ROM Boot Loader"-readable image stored in the Dual Port SRAM. Operand #1: (VME Address $A0 0120): 00000003 [DSP #3] Operand #2: (VME Address $A0 0124): 00000005 [IIOF2] Then I put DSP #3 into the RESET state and set up the RESETLOC(1,0) pointer to use the contents of 0000 0000h [the beginning of the on-chip ROM) as its RESET vector (this will cause the on-chip ROM Boot Loader to execute when the DSP is brought out of RESET), and set up the IIOF(3..1) flags to tell the on-chip ROM Boot Loader to load an image from DSP address 8000 0000h (the beginning of the Dual Port RAM). This was done by writing to the Boot Control Register of DSP #3: VME Address $A1 0808: 00000010 Then I took DSP #3 out of RESET without changing the RESETLOC or IIOF signals. This caused the on-chip ROM Boot Loader to execute, pulling Hydra-Mon out of the Dual Port RAM and then handing program control over to Hydra-Mon on DSP #3. Again done by writing to the Boot Control Register of DSP #3: VME Address $A1 0808: 00000030 When the processor was taken out of RESET, the Dual Port access LED for DSP #3 flashed briefly. I had confidence that "something useful" happened, because Longword #0 of DSP #3 HydraMon Control Area was changed from FFFFFFFF to 00000000. This was VME Address $A0 7F40. Next I wanted to test Hydra-Mon. I decided to load the command for Copy into the DSP#3 HydraMon Control Area and provide an IIOF2 interrupt. The steps are described below. I first verified that the Interrupt Control Register for DSP #3 was programmed to allow the push-button to generate an IIOF2 interrupt. That is: VME Address $A1 0818: 00000004 I then programmed the DSP#3 HydraMon Control Area as follows: VME Address $A0 7F40: 00000003 (command = Copy) VME Address $A0 7F44: 80000008 (source address) VME Address $A0 7F48: 80000000 (destination address) VME Address $A0 7F4C: 00000004 (# of longwords to copy) I then put some unique pattern in the beginning of the Dual Port RAM. This overwrote the HydraMon load image previously stored there. I then provided an IIOF2 using the push-button interrupt. I saw no activity on the DSP#3 Dual Port RAM Access LED. This was not surprising. I then looked at the beginning of the Dual Port RAM. The requested copy had been performed. I then looked at longword #0 of the DSP#3 HydraMon Control Area. It had been replaced by a 00000001 [as described in the HydraMon documentation] indicating that HydraMon had completed its task. We now know how to assemble, load, and execute a DSP program. We also know how to communicate with HydraMon. ************************************************************************ Date: 3-NOV-1993 Topics: Pages in the Ariel Hydra-II Preliminary User's Guide that talk about the C40 Memory Interface Control Registers In the Ariel Hydra-II Preliminary User's Guide from 14-OCT-1993 the following pages talk about the Memory Interface Control Registers Global MICR Local MICR ------------- ------------ pg 12 pg 37 pg 40 pg 43 pg 52 pg 52 pg 54 pg 54 pg 56 pg 56 pg 58 pg 58 pg 103 pg 107 ************************************************************************ Date: 3-NOV-1993 Topics: Making a Loadable Program Image that can be read by the C40 on-chip Boot Loader example of HydraMon. Current Steps in Building and Loading HydraMon ---------------------------------------------------- 1. On Prospero copy all of the *.A40 files and the one .EQU file from \Hydra\Monitor\Hydra-II\Host to the directory \C40Play\. 2. From the [Edmunds.Spare_5] directory get the three *.CMD files and copy them to \C40Play\ on Prospero. These files are DansAsm.cmd, DansLink.cmd, and DansBoot.cmd. 3. On Prospero in \C40Play\ execute the DansAsm.cmd, and then the DansLink.cmd, and last DansBoot.cmd. Execute the assemble and link CMD files by just typing their names. Execute the Boot.CMD file by typing at the Prospero prompt Hex30 DansBoot.CMD 4. The output of Hex30 is an image of HydraMon that can be read by the C40 on-chip Boot Loader. This is in a file called Monitor.Hex The image of HydraMon in the Monitor.Hex file is stored as Motorola S Records. 5. There are a couple of problems with the output of Hex30 as it stands. 1. Hex30 only knows how to make S1 type S Records i.e. 2 bytes of address. With the Motorola 68k assembler we use S3 type S Records which have 4 byte addresses. Thus Hex30 can not directly make the S Record file that will load a $00A0 0000 or 8000 0000h for the C40 on-chip Boot Loader to read. So Hex30 is told to build an image that loads a address $0000. 2. The only way to get Hex30 to produce the proper S Record Byte numbering is to have it make byte wide ROM output. Note that Hex30 needs to be told the byte ordering (MSB First). The only problem with this is that the on-chip Boot Loader needs to be told to read 32 bit wide data. This will be taken care of in step #7 below. 3. The output from Hex30 does not contain any arguments for the BootMon section of HydraMon. This will be taken care of in step #7 below. 6. Use the 135Bug to load the Monitor.Hex file. Do this with the command 135Bug>> LO ,$40000;X=Type Monitor.Hex This will add an offset of $40000 to the S Records as they are loaded into memory on the MVME135 card. Note that you can not directly load into the Hydra-II Dual Port shared RAM because the 135Bug LO command uses byte or word writes and not LongWord writes and thus everything is scrambled in the Hydra dual port shared memory. 7. Now load into the MVME135 module the program from [Edmunds.Spare_4] called Copy_S_Records.abs and execute it at $30000. The Copy_S_Records program will copy the HydraMon image from $40000 to the address range starting at $00A0 0000 i.e. to the beginning of the Hydra-II's dual port shared RAM i.e. 8000 0000h as seen by the C40. The Copy_S_Records program then patches the first longword of the image stored at $00A0 0000 so that this word is a $20 and not a $08 i.e. tell on-chip Boot Loader to read 32 bit words. The Copy_S_Records program then patches the 5 words in the BootMon_Args section. This selects the DSP number and the C40 interrupt that HydraMon will use. Note that the image at $00A0 0000 is patched and the image at $40000 is left untouched so that it can be copied again to the range $00A0 0000 with different patches from the Copy_S_Records program to load a different DSP. 8. Who's Next ?? ************************************************************************ Date: 2-NOV-1993 Topics: Dead Start of a C40 Part 2 Steve experimented with reproducing the "auto-boot" functionality provided by the Hydra-II card (recall that if J4 is installed, then on either VME Reset or power-up reset, the Hydra-II card to boot from the on-board flash memory). First of all, we believe that what gets loaded during auto-boot is NOT HydraMon. For lack of a better term, we are calling the program that is loaded from the on-chip flash memory the "Sanity and Configuration Checker." Note that this is DIFFERENT from both the on-chip ROM Boot Loader (intrinsic to the 'C40 silicon itself, this utility is provided by TI on ALL 'C40s) and HydraMon. The "Sanity and Configuration Checker" is provided by Ariel (not TI), but we do not have source code for the "Sanity and Configuration Checker." The function of auto-boot appears to be: On DSP #1: using the on-chip Boot Loader, extract the "Sanity and Configuration Checker" from the flash memory and begin running it (it = "SCC"). On DSP #2..4: using the on-chip Boot Loader, try to load the "SCC" from Com Ports (note: NOT from Global Shared Dual-Port Memory). Note that the on-chip Boot Loader does not specify WHICH COM Port to use as the loading media, but simply waits for activity on ANY COM Port. Once the "SCC" is loaded begin running it. That is, auto-boot simply sets up the environment for the 'C40 on-chip ROM Boot Loader for each of the 'C40s, and then allows the Boot Loader to execute by providing a rising edge on the RESET signal for each 'C40. The on-chip ROM Boot Loader then loads the "Sanity and Configuration Checker" through the appropriate media for each DSP. The function of the "Sanity and Configuration Checker" seems to be: On DSP #1: Test the Local SRAM for DSP #1. Test the Global SRAM. Test the Dual-Port SRAM. Provide a copy of itself through the COM port connected to DSP #2. Listen for results from DSP #2 through the COM port. Send characters to the RS-232 port documenting its activities. It also prints the board configuration via the RS-232 port. It must receive information about the other 3 'C40s on the board via the COM port connected to DSP #2. It somehow knows when it has been loaded to all DSPs. Maybe this is done by waiting for a copy of itself to come in through a COM port, indicating that the circle has been completed. Or maybe it knows some other way. On DSP #2: It may do memory tests like on DSP #1. It certainly determines the memory configuration for DSP #2 (i.e. how much Local SRAM and Global SRAM is connected to DSP #2). It provides a copy of itself through the COM port connected to DSP #3. It returns results to DSP #1 via the COM port. It receives information about the other 2 'C40s on the board via the COM port connected to DSP #3. Then what does it do??? On DSP #3: It may do memory tests like on DSP #1. It certainly determines the memory configuration for DSP #3 (i.e. how much Local SRAM and Global SRAM is connected to DSP #3). It provides a copy of itself through the COM port connected to DSP #4. It returns results to DSP #2 via the COM port. It receives information about the other 'C40 on the board via the COM port connected to DSP #2. Then what does it do??? On DSP #4: It may do memory tests like on DSP #1. It certainly determines the memory configuration for DSP #4 (i.e. how much Local SRAM and Global SRAM is connected to DSP #4). It either returns information to DSP #3 or directly to DSP #1 through its COM ports. I expect that it tries to load a copy of itself to DSP #1 through the COM port connected to DSP #1. The "SCC" on DSP #1 may be waiting to see itself coming in through the COM port, indicating that all DSP's have been loaded (or maybe it knows this through some other means). Then what does it do??? All of this happen "automatically" when J4 is installed. But it is possible to "simulate" auto-boot conditions by programming the appropriate values in the Hydra-II MCRs. I have done that, and it works. The appropriate sequence of operations follows: First, remove jumper J4 and then apply power to the Hydra-II. I did a power-cycle to verify that we were starting with "raw" 'C40s. Next, put all of the 'C40s in the RESET state. At the same time, set up the IIOF(3..1) flags to indicate to each 'C40's on-chip ROM Boot Loader where it should be loading its source program from. That is: For DSP #1: flash memory (address = 0030 0000h; IIOF(3..1) = 1 1 0) For DSP #2..4: COM port (IIOF(3..1) = 1 1 1) To do this, program the following values into the MCR (via VME access, using 32-bit writes. Note that these are only 8-bit registers so only the LSByte of each 32-bit write is used). See the Hydra-II User's Manual page 26-28 for details of the Boot Control Registers. $A1 0800: 00000004 [Boot Control Register for DSP #1] $A1 0804: 00000000 [Boot Control Register for DSP #2] $A1 0808: 00000000 [Boot Control Register for DSP #3] $A1 080C: 00000000 [Boot Control Register for DSP #4] Note that these writes will typically fail due to both the usage of 32-bit writes for 8-bit registers, AND also the fact that the upper 2 bits of the Boot Control Register for each DSP are not write-able. Next take DSP #2..4 out of the RESET state (while leaving DSP #1 in reset) [NOTE: it may be possible to do this in a different order but this is the most rational order. Note that via VME they cannot all be taken out of RESET simultaneously]. This is again done via the Boot Control Registers, using 32-bit writes. Do NOT change the values of the IIOF(3..1) signals to these DSPs. $A1 0804: 00000020 [Boot Control Register for DSP #2] $A1 0808: 00000020 [Boot Control Register for DSP #3] $A1 080C: 00000020 [Boot Control Register for DSP #4] Finally take DSP #1 out of the RESET state, while not changing the IIOF(3..1) signals to this DSP. Again this is done through the Boot Control Register. $A1 0800: 00000024 [Boot Control Register for DSP #1] Now the "SCC" begins running on DSP #1, displaying information and also trying to load itself to DSP #2. Once it is loaded on DSP #2 it also starts running on #2 and trying to load itself to #3, etc. I believe that performing the actions above is alost 100% equivalent to using the "auto-boot" feature of the Hydra-II. The only differences I can determine are: Bit 7 of each of the Boot Control Registers is "1" after auto-boot, but "0" after a simulated-auto-boot. Bit 2 of the Boot Control Register for DSP #1 is "0" after auto-boot, but "1" after a simulated-auto-boot. Note that the most significant bit (bit #7) of the Boot Control Registers appears to indicate whether jumper J4 is installed (in which case it will read back a "0") or not installed (in which case it will read back a "1"). In the Hydra-II User's Manual, this bit is described as "RESERVED." ************************************************************************ Date: 31-OCT-1993 Topics: Dead Start of a C40 The following is my understanding to date about how a C40 starts up. The sections of the C40 User's Guide to read are the following: 1. Section 6.6 pages 6-18:6-22. 6-22 shows CPU register contests after Reset. 2. Section 12.1 starting on page 12-3 for an example of an initialization. 3. Section 13.2 starting on page 13-5 describes the on-chip ROM Boot Loader. The steps as I currently understand them are the following: 1. The RESET* pin is held voltage low for 10 or more H1 clock cycles. 2. When RESET* comes high the Reset Vector is read from a location that is determined by the state of the RESETLOC(1,0) pins. The Reset Vector is loaded into the processor PC register and execution begins. The location in address space from which the Reset Vector is fetched is determined by RESETLOC(1,0) as follows: State of the The Reset Vector RESETLOC(1,0) Pins is Read from Address -------------------- ---------------------- 0 0 0000 0000h 0 1 7FFF FFFFh 1 0 8000 0000h 1 1 FFFF FFFFh Note: If the ROMEN pin is voltage high then the on-chip ROM is enabled. On-chip ROM appears in the address range 0000 0000h through 0000 0FFFh. Thus, if RESETLOC(1,0) = 0 0 and if ROMEN = high, then the Reset Vector is read from on-chip ROM. This vector points to the beginning of the on-chip Boot Loader in ROM. 3. If in set 2 above the Reset Vector that points to the on-chip Boot Loader was selected then execution continues with this Boot Loader. The on-chip Boot Loader can load a user program from either a Communication Port or from an inexpensive slow off-chip ROM. The off-chip ROM can be either byte, 16 bits, or 32 bits wide. Note, that the on-chip Boot Loader need not execute to dead start a C40, i.e. a different Reset Vector can be selected in step 2. Also note that the on-chip Boot Loader does not contain any initialization code of the type described in section 12.1 of the C40 User's Guide. 4. If the on-chip Boot Loader is selected, then the source and the memory address from which the on-chip Boot Loader will try to load the user program is determined by the state of the IIOF(3:1) pins. This is shown in the following table: Source and Address Location from which the On-Chip IIOF3 IIOF2 IIOF1 Boot Loader Will Try to Load the User Program ----- ----- ----- -------------------------------------------------- 0 0 0 Reserved 0 0 1 Load Program from Memory Address C000 0000h 0 1 0 Load Program from Memory Address A000 0000h 0 1 1 Load Program from Memory Address 8000 0000h 1 0 0 Load Program from Memory Address 6000 0000h 1 0 1 Load Program from Memory Address 4000 0000h 1 1 0 Load Program from Memory Address 0030 0000h 1 1 1 Load Program from a Communication Port. 5. All of the above is more or less consistent with the explaination on pages 22 through 28 of the Hydra-II Preliminary Users Manual 14-OCT-1993. I think that pages 26, and 27 in this manual may have some inverted statements about what happens when Hydra-II Auto-Boot is enabled vs what happens when Auto-Boot is disabled. Note that the Hydra-II Flash EPROM starts a memory address 0030 0000h i.e. it fits the above table. ************************************************************************ Date: 26-OCT-1993 Topics: Hydra-II VME memory map, MVME135 documentation. I have stated (and mostly written) a detailed memory map of the Hydra-II's use of VME address space. This file is still in the [Edmunds.Spare_4] area but I will move it as soon as we have an official Hydra-II text area. I have written a lot of how to use the MVME135 module notes in the VMEText: area in a file called Using_the_MVME135.txt. ************************************************************************ Date: 18-OCT-1993 Topics: Received some more software and documentation from Ariel. Installed on PC. We received: Hydra General Release Notes October 1, 1993 Hydra Release Notes SunOS/UNIX Software Release 2.0 October 1, 1993 Hydra Release Notes DOS/EPC Software Release 2.0 October 1, 1993 3.5" Disk Hydra - SunOS 4.1.x Driver, Library, Monitor, Demos Release 2.0 Disk 1 of 1 3.5" Disk Hydra - DOS / EPC Driver, Library, Monitor, Demos Release 2.0 Disk 1 of 1 Steve installed the DOS/EPC Driver, Library, Monitor, Demos Release 2.0 disk on the PC. Instructions for this were found in the Hydra Release Notes for the DOS/EPC Software Release 2.0 (dated October 1, 1993). I put the disk in the A: drive and typed A:INSTALL. I chose to install the software in the directory C:\HYDRA. This directory was automatically created on the C: disk. The release notes describe several changes that can/should be made to the DOS environment (changing the PATH statement, defining some environment variables). I DID NOT do this. I will wait until (a) we understand more about what we will do with this software, and (b) I understand which changes are necessary and the best way to make them (i.e. in some DOS AUTOEXEC.BAT file, or via OS/2 [how???]). !Set-up! The Hydra DOS/EPC device driver disk was installed in the C:\HYDRA subdirectory. The recommended DOS environment changes (as described in the release notes for the DOS/EPC device driver disk) WERE NOT made pending further understanding of our requirements. ************************************************************************ Date: 16-OCT-1993 and 18-OCT-1993 Topics: Jumpers as found on the Hydra II SN# 7010 as delivered Notes about addressing the VME bus and the Hydra II as seen from the 68k on a MVME-133A20 card. | +-----------------------------------------------+ | +-----+ +-----+ +---| | | C40 | D D D D | IDT | | | Map | JP x | DSP | S S S S | 7025| | | of the | 6 x | No3 | P P P P +-----+ | | Hydra II | +-----+ 1 3 3 1 +-----+ | | P1 | | IDT | | | | +-----+ L L G G | 7025| | | | | C40 | S S S S +-----+ | | | | DSP | R R R R +--+ | | | | No1 | A A A A | | x JP +---| | +-----+ M M M M +--+ x 4 | | +---------+ xx| Front | | MX68C153| P xx| Panel | JP1 JP2 JP3 +---------+ 14 xx| VME | xxx xxx xxx xx| Connectors | +-----+ D D D D JP x | | | C40 | S S S S 5 x +---| | | DSP | P P P P | | | | No2 | 4 2 2 4 +------+ | | Component | +-----+ | JTAG | | | Side | L L G G +------+ | | View | +-----+ S S S S +-----+ | | P2 | | C40 | R R R R | | | | | | DSP | A A A A | VSB | | | | | No4 | M M M M | | | | | +-----+ +-----+ +---| +-----------------------------------------------+ | Jumper Settings as Found and Jumper Functions Jumper Setting Function ------ ------- -------- JP1 x x-x Sector Protection of the JP1 x x-x Advanced Micro Devices Am29F010 JP1 x x-x Flash Memory JP4 x-x Installed --> Auto-Boot from on-board flash memory JP5 x-x Installed --> A24 Removed --> A32 JP6 x x This jumper is used to tie together "MPI" and "MPO" signals on the SCC2691 UART. P14 x-x A17 Jumper nearest the TOP of Hydra II x-x A18 0 x-x A19 x-x A20 x-x A21 x-x A22 8 Jumper Installed --> x x A23 VME Adrs Bit must be a 0 x x A24 x-x A25 Jumper Removed --> x x A26 5 VME Adrs Bit must be a 1 x-x A27 x x A28 x-x A29 x x A30 5 x-x A31 Jumper nearest the BOTTOM of Hydra II Notes: 1. Let's all of us try using the Motorola "$" notation when talking about 68k addresses or VME addresses and use the Texas Instruments "h" notation when talking about Hydra II C40 addresses. 2. Hydra II always takes up 128k BYTES of VME Address Space 3. The Dual Port SRAM on this card is 8k words of 32 bits. This is 32k bytes of VME address space. This Dual Port SRAM is made from two IDT7025 devices of 8k x 16 data bits each. 4. As delivered this unit has a VME base address of 5580 0000h Thus the Dual Port SRAM would appear in VME address space from $5580 0000 through $5580 7FFF 5. The normal setup of the MVME-133A-20 modules (factory default which is what we have been using) is to have: J17 jumper pins 1&2 (i.e. VME bus is 32 bit data when address line [A24] is low and 16 bit data when address line [A24] is high. e.g. as seen from the 68k: $0000 0000 to $00FF FFFF or $0200 0000 to $02FF FFFF or $0400 0000 TO $04FF FFFF have [A24] LOW and thus are 32 bit VME data $0100 0000 to $01FF FFFF or $0300 0000 to $03FF FFFF or $FF00 0000 TO $FFFF FFFF have [A24] HI and thus are 32 bit VME data J18 jumpers pins 2&3 (i.e. VME bus contains both A24 and A32 devices: 68k addresses from $0010 0000 through $00EF FFFF cause A24 VME addressing and 68k addresses from $00F0 0000 through $FFEF FFFF cause A32 VME addressing. 6. WILL THE MVME-135 WORK THE SAME WAY ????? 7. RECALL the relation of address bit label to address bit value: AAAA AAAA AAAA AAAA AAAA AAAA AAAA AAAA 3322 2222 2222 1111 1111 1198 7654 3210 1098 7654 3210 9876 5432 10 xxxx xxxx xxxx xxxx xxxx xxxx xxxx xxxx 2152 1631 8321 5216 3184 2152 1631 8421 GG15 2426 MMMM 1524 2610 0015 2426 26 8MMM 268K KK99 4226 8 MM M KKK 26 84 8. What we want for the Hydra II is A24 addressing and 32 bit VME data. So for now with the MVME-133A20 (and perhaps with the MVME-135) lets pick the following VME base addresses for the Hydra II modules: Hydra II VME Base Hydra II is Contained within Module Address the VME Address Range -------- ------------ --------------------------------- A $00A0 0000 $00A0 0000 through $00A1 FFFF B $00B0 0000 $00B0 0000 through $00B1 FFFF C $00C0 0000 $00C0 0000 through $00C1 FFFF Note that these addresses keep away from all of the addresses currently used by the MVME-214 memory modules and by the VBD data cable driver. 9. So for now I will set the Hydra II module SN# 7010 to continue to use A24 addressing and to have a VME base address of $00A0 0000 i.e. Jumper [A31] : [A24], [A22], [A20] : [A17] Open [A23], [A21] I wish that I had some more of these small jumpers for the Hydra II. Because we are doing A24 VME addressing I can use some of the jumpers from the [A23] through [A31] range. 10. Note that for now the only way that things appear to work it to remove JP5 (which should give 32 bit VME addressing) and to give the 68k bug monitor 24 bit addresses. So I do not yet really understand how this all works. ************************************************************************ Date: 15-OCT-1993 Topics: Notes about Hydra-II Comm Ports !CommPt! Today I looked at the Comm Ports on the Hydra-II. Note that the Comm Ports with BLUE connectors wake up as OUTPUT (i.e. with token), while the Comm Ports with BLACK connectors wake up as INPUT (i.e. without the token). !CommPt! When looking at the front of the Hydra-II, a Comm Port connector on the motherboard looks like: Pin # Signal ----- ------ 13 GND 25 GND 12 GND 24 *CREQ 11 *CSTRB 23 *CACK 10 VCC 22 *CRDY 9 D0 21 GND 8 *DSPRESET 20 D1 7 VCC 19 D2 6 RESERVED 18 GND 5 D3 17 D4 4 VCC 16 D5 3 D6 15 D7 2 GND 14 GND 1 GND !CommPt! Upon power-up or after the RESET button (leftmost red button near top of Hydra card, above the RS-232 connector) is pressed, the voltage levels seen on each connector are: !CommPt! Connectors corresponding to OUTPUT ports (BLUE) *CREQ +4.935 V *CACK +4.935 V *CSTRB +4.935 V *CRDY +0.010 V to -0.010 V D0-D7 +0.010 V !CommPt! Connectors corresponding to INPUT ports (BLACK) *CREQ +4.935 V *CACK +0.010 V to -0.010 V *CSTRB +4.935 V *CRDY +4.935 V D0-D7 +0.010 V !CommPt! This measurement must be done carefully. For example, simply probing the *CREQ pin on an OUTPUT port is sufficient to "turn the token around" and convert the port to an INPUT port. Recall that the *CREQ line is pulled to VCC through a 10Kohm resistor on the Hydra-II. It appears that probing this pin with the Fluke is sufficient to introduce a momentary low-going spike on this signal. That looks like a "token request" to the Comm Port, and the Comm Port gives up the token to become an output port. ************************************************************************ Date: 14-OCT-1993 Topics: Receive Hydra II docs from Ariel. We received a package today from Ariel containing: BOOKS: Preliminary Hydra-II User's Manual Version 0.20 Motorola MVSB2400 VSBChip User's Manual MVSB2400UM/D3 There is no mention in the Hydra-II manual about Hydra-Mon. But, there is a jumper on the Hydra-II for A24/A32 decoding. We still do not have "device driver" stuff. ************************************************************************ Date: 13-OCT-1993 Topics: Call to Ariel about our Hydra II books. More PC setup I called Bob Yarrow (sp?) at Ariel to see where our Hydra II books are. He was waiting for the Hydra Driver software to be released and then he was going to send the Hydra II books and the Driver all at the same time. Now he understands that we need the Hydra II Docs and he said that he will over night mail them to us. I said that I had not OKed purchasing to pay the invoice. I double verified that he had the proper address. The device driver will ship in a couple of days. He understands that we will not be running on a Sun 3-4 but that we want to look at the source of the device driver. He says that they also have and are shipping an IBM/PC device driver (it used a "bit3" to make the pc bus to VME hop). He is checking about the schedule for the XDS510 JTAG stuff. He will call us when he has a ship date. He now understands why we need it. !Set-up! Steve created a directory called C:\C40PLAY for temporary playtime C40 work. Dan and Philippe are now authorized FTP users with access only to C:\C40PLAY. !How-to! To start the assembler, linker, hex conversion utility, or debugger from the PC, use the icons in the "C40 Tools" folder. The command-line method (described earlier) still works. Dan and Steve plugged the Hydra-II in to the VME rack and began to experiment with the card. We used PM-Terminal to listen to the RS-232 port. If you RESET the Hydra-II using the Reset pushbutton on the front panel, some status information comes out the RS-232 jack. We were unable to invoke Hydra-Mon (the resident monitor) as described in the Hydra-I manual, and are waiting for the Hydra-II manuals for further guidance. !How-to! To listen to the Hydra-II RS-232 jack, connect the jack to the PC's COM1: port (labelled COM A:). Use PM-Terminal to talk to the COM1: port. This is done using the "profile" called "Hydra". ************************************************************************ Date: 12-OCT-1993 Topics: Edmunds notes about the first shipment of DSP equipment. Notes so far about the Hydra II and its software that arrived 8-OCT-1883 1. To touch GND on the Hydra II card the following points are convenient: On the component side touch the metal shield around the circular DIN connector. On the solder side at the very top and the very bottom edges of the card near the center of the card there are plate through vias to GND and Vcc for a Tantalum cap on the component side, 2. The resistors in the Comm Ports lines to the front panel 25 pin connectors appear to be the following: 25 Pin D Pin # Signal Ohms D pin to IC pin -------- -------- ------------------------ 23 CAck direct connection 24 CReq direct connection with 10k pull up 22 CRdy 47 ohm 11 CStrb 47 ohm with 10k pull up 15 CD7 direct connection 3 CD6 direct connection This was checked for DSP #1 Comm Port #5. The other front panel Comm Ports appear to be the same. There also appear to be the same resistors in the lines that go to the high density AMP connectors that will go up to the expansion comm port mezz board. 3. The layout of the Hydra board as to which C40 is which number appears to be the following: +----------------------------+ | +-----+ +---| | | C40 | | | | | DSP | | | | | No3 | | | | +-----+ | | P1 | +-----+ | | | | C40 | | | | | DSP | | | | | No1 | +---| Front | +-----+ | VME Panel | +-----+ | Connectors | | C40 | +---| | | DSP | | | | | No2 | | | Component | +-----+ | | Side | +-----+ | | P2 View | | C40 | | | | | DSP | | | | | No4 | | | | +-----+ +---| +----------------------------+ 4. It does not appear like it will be possible to solve the A24 to A32 problem by just reprogramming a PAL on the Hydra II card. All of the Hydra II programmable devices are soldered directly to the circuit board. This leaves either changing a part on the Vertical Interconnect or else doing something external to both of these cards. 5. The Hydra Monitor program in on board Flash EPROM provides functions that can be used by a "device driver" running on the host. That is, there is code in Hydra-Mon that can give the Hydra side of the connection some intelligence, e.g. load a program, boot a DSP, stop a DSP. It may not be necessary to load via the JTAG stuff. Also note that on page 2-17 it says that source code for the TMS320 COFF Loader is available from the TI DSP Bulletin Board. 6. We will have to think about VAX file name format so that the first 8 characters mean something so that it can work on the OS/2 machine. 7. When we start to think about data structures in memory we will have to think about all of the views of memory: the VME address, the address from the DSP, the address from the TCC, the address from the 68k. 8. The reason that there is a RESET signal on the 25 pin Comm Ports is not to send a reset into the Hydra card but so that a reset can come out of the Hydra card to the Ariel Buffered Comm Cables. ************************************************************************ Date: 11-OCT-1993 Topics: Receive Hydra II, manuals, etc Install Assembler, Simulator/Debugger Dan picked up the first shipment of the Hydra-II order from Ariel at the end of last week. It was shipped to Fermilab. Included in this shipment were: 1. TI 320 Floating-Point DSP Assembly Language Tools TMDS3243850-02 PC Release 4.50 (dated 18 Dec 1992) aka 2617572-0641 Rev. B included in this package were: BOOK: TI TMS320 Floating-Point DSP Assembly Language Tools User's Guide (1991) SPRU035A BOOK: TI TMS320 Floating-Point DSP Code Generation Tools Release Notes (1992) 2564094-9741 Rev. C BOOK: TI Hex Conversion Utility Addendum to (SPRU081) TMS320 Assy. Lang. Tools U.G. (1992) 2617615-9741 Rev. * BOOK: TI Microprocessor Development Systems Products Customer Support Guide 2563578-9741 Rev. C DISKS: TI 320 FLT-PT DSP Assembly Language 2617572-1641 Rev. B Tools Rev. 4.50 MS-DOS and OS/2 Disks and 1 and 2 (5.25" high-density floppies) 2617572-1642 Rev. B (dated 21-Oct-92) These disks have been copied to 3.5" HD floppies. The originals are stored in the "Original Disk" drawer upstairs, the copies are stored with the PC downstairs. 2. TI TMS320C04x Simulator Software System TMDS3244851-02 PC Release 1.3 (dated 04 May 1993) aka 2576335-0641 Rev. B included in this package were: BOOK: TMS320C4x User's Guide (1991) SPRU063 aka 2564090-9761 Rev. B BOOK: TMS320C4x C Source Debugger User's SPRU054 Guide (1992) aka 2547296-9761 Rev. A BOOK: TMS320C4x Simulator Release 1.30 2617664-9741 Rev. * Release Notes (1993) BOOK: TMS320C4x Simulator Installation Guide 2617614-9741 Rev. * (1992) BOOK: TI Microprocessor Development Systems 2563578-9741 Rev. D Products Customer Support Guide DISK: TI TMS320C4x Simulator Software 2576335-1641 Rev. B PC Release 1.30 (5.25" HD floppies) (dated 29-Apr-93) These disks have been copied to 3.5" HD floppies. The originals are stored in the "Original Disk" drawer upstairs, the copies are stored with the PC downstairs. 3. Ariel Hydra-II Hardware and related manuals included in this package were: BOOK: User's Manual for the V-C40 Hydra No number found Document Version 0.54 (August 1993) Note: this is the manual for the Hydra-I, NOT the Hydra-II. Dan called Ariel and requested the Hydra-II manual. Ariel will send it via a fast (paper) mail path directly to the Electronics Shop (not Fermilab). BOOK: Motorola MVSB2400 VSBChip User's Manual MVSB2400UM/D3 (June 1991) BOOK: Cypress Semiconductor VIC068A/VAC068A No number found User's Guide (June 1992) BOOK: TI TMS320C4x User's Guide (1991) SPRU063 aka 2564090-9761 Rev. B CABLE: 8-pin round DIN to DB-25 female No number found ADAPTER: DB-9 female to DB-25 male No number found (RS-422 to RS-232 adapter) ADAPTER: DB-25 male to DB-25 male No number found (gender bender) HARDWARE: Ariel Hydra-2-4-S1 Revision B S/N 7010 I installed the Assembler and Debugger as described in the Installation Guides (see L15_CALTRIG_PC_LOGBOOK.LBK) for details. !How-to! To invoke the assembler, execute the file C:\320TOOLS\ASM30.EXE. This can be done from an OS/2 command line (I have edited the OS/2 CONFIG.SYS file to include C:\320TOOLS in the PATH statement. !How-to! To invoke the simulator, execute the file C:\SIM4X\SIM4X.EXE. This is a DOS program so it should be run in a DOS window or a DOS full-screen session. I have executed it by clicking on its icon under the DRIVE view of the OS/2 Presentation Manager and it appears on the screen but I don't know whether this is a "legal" mode of operation. I have edited the DOS AUTOEXEC.BAT file to include C:\SIM4X in the PATH statement. !Set-up! For the simulator, I have included a few lines in the DOS AUTOEXEC.BAT file. These set up some options and logical names for the simulator. They will probably have to be changed later. They are: D_DIR=C:\SIM4X (this tells the simulator where some of its set-up files are) D_SRC=C:\SIM4X (this tells the simulator where its C source files are) D_OPTIONS=-b (this tells the simulator what "options" to use when running) ************************************************************************