2 files changed, 63 insertions, 2 deletions
diff --git a/src/include/usr/hwpf/fapi/fapiUtil.H b/src/include/usr/hwpf/fapi/fapiUtil.H
index 0540a79cf..b7659d280 100644
--- a/src/include/usr/hwpf/fapi/fapiUtil.H
+++ b/src/include/usr/hwpf/fapi/fapiUtil.H
@@ -20,7 +20,7 @@
 
 #include <stdint.h>
 #include <stddef.h>
-
+#include <fapi.H>
 
 namespace fapi
 {
@@ -33,6 +33,37 @@ namespace fapi
  */
 void fapiAssert(bool i_expression);
 
+
+/**
+ * @brief Delay this thread. Hostboot will use the nanoseconds parameter
+ * and make a syscall to nanosleep. While in the syscall, the hostboot
+ * kernel will continue to consume CPU cycles as it looks for a runnable
+ * task.  When the delay time expires, the task becomes runnable and will soon
+ * return from the syscall.  Callers of delay() in the hostboot environment
+ * will likely have to know the mHz clock speed they are running on and
+ * compute a non-zero value for i_nanoSeconds. 
+ * 
+ * On the FSP, it was sometimes acceptable to just provide zero for the
+ * sleep delay time, causing the task to yield its time slice. By the
+ * time the calling task could run again, it was pretty certain enough
+ * host cycles had past.  This is probably not acceptable in
+ * the hostboot environment. Callers should calculate and provide a
+ * sleep value in nanoseconds relative to host clock speed.  
+ *
+ * On FSP when VBU is the target, then the i_simCycles parameter will be
+ * used instead.  The FSP needs to use the simdispatcher client/server
+ * API and issue a command to the awan to advance the simulation the
+ * specified number of cycles. 
+ * 
+ * @param[in] i_nanoSeconds    nanoseconds to sleep 
+ * @param[in] i_simCycles      count of Awan cycles to advance
+ * 
+ * @return ReturnCode. Zero on success, else platform specified error.
+ */
+ fapi::ReturnCode delay( uint64_t i_nanoSeconds, uint64_t i_simCycles );
+
+
+
 }
 
 #endif // FAPIUTIL_H_
diff --git a/src/usr/hwpf/plat/fapiPlatUtil.C b/src/usr/hwpf/plat/fapiPlatUtil.C
index 8a3e22bf9..7962ba4bb 100644
--- a/src/usr/hwpf/plat/fapiPlatUtil.C
+++ b/src/usr/hwpf/plat/fapiPlatUtil.C
@@ -7,8 +7,10 @@
  */
 
 #include <assert.h>
+#include <fapi.H>
 #include <trace/interface.H>
-#include <fapiPlatTrace.H>
+#include <sys/time.h>
+
 
 //******************************************************************************
 // Trace descriptors
@@ -37,4 +39,32 @@ void fapiAssert(bool i_expression)
     assert(i_expression);
 }
 
+//******************************************************************************
+// delay
+//
+// At the present time, VBU runs hostboot without a Simics
+// front end. If a HW procedure wants to delay, we just make the
+// syscall nanosleep().  In the syscall, the kernel will continue to consume
+// clock cycles as it looks for a runnable task. When the sleep time expires,
+// the calling task will resume running.
+//
+// In the future there could be a Simics front end to hostboot VBU. Then
+// a possible implementation will be to use the Simics magic instruction
+// to trigger a Simics hap. The Simics hap handler can call the simdispatcher
+// client/server API to tell the Awan to advance some number of cycles.
+//
+// Monte  4 Aug 2011
+//******************************************************************************
+
+fapi::ReturnCode delay( uint64_t i_nanoSeconds, uint64_t i_simCycles )
+{
+    FAPI_DBG( INFO_MRK "delay %lld nanosec", i_nanoSeconds );
+    nanosleep( 0, i_nanoSeconds );
+    return fapi::FAPI_RC_SUCCESS;
+}
+
+
+
+
+
 }