Changes between Version 63 and Version 64 of library_stdio

Timestamp:

Apr 11, 2015, 10:57:52 PM (10 years ago)

Author:

alain

Comment:

--

library_stdio

@@ -45 +45 @@
  ==  __Coprocessors related system calls__ ==
 
-The GIET_VM allows user applications to use hardware accelerators (called coprocessors). These coprocessors can be distributed in the architecture, but there is at most one coprocessor per cluster, identified by the cluster (x,y) coordinares. To be supported by the GIET_VM, a coprocessor must use the ''vci_mwmr_dma'' component, that is a multi-channels DMA controller.
+The GIET_VM allows user applications to use hardware accelerators (called coprocessors). These coprocessors can be distributed in the architecture, but there is at most one coprocessor per cluster. To be supported by the GIET_VM, a coprocessor must use the ''vci_mwmr_dma'' component, that is a generic multi-channels DMA controller.
 
 On the coprocessor side, it provides TO_COPROC or FROM_COPROC ports, that implement FIFO interfaces. Coprocessor can request to transfer one or several bursts of 32 bits words on a TO_COPROC or FROM_COPROC port, without address. The burst size (generally a cache line), the number of TO_COPROC and FROM_COPROC ports, and the number of bursts for a given port are hardware parameters. Each port define a private communication channel between the coprocessor and a user memory buffer. The total number of channels cannot be larger than 16. A channel is identified by an index, and the TO_COPROC channels have the smallest indexes.
@@ -56 +56 @@
 '''WARNING''' : For all channels, the memory buffer address and size  must be multiple of the hardware burst size.
 
-Several channels can simultaneously run in different modes. The VCI transactions corresponding to different channels are interleaved and parallelized on the VCI network. 
+The VCI transactions corresponding to different channels are interleaved and parallelized on the VCI network. 
 
 Besides these communication channels, the ''vci_mwmr_dma'' component support up to 16 coprocessor-specific configurarion/status registers. The ''configuration'' registers are Read and Write. The ''status'' registers are Read only.
 
 
-The list of supported coprocessors and their characteristics are defined below:
+The list of currently  supported coprocessors and their characteristics are defined below:
 ||  coproc_type               ||     Function                             ||nb_to_coproc || nb_from_coproc || nb_config  || nb_status ||  
 || COPROC_TYPE_GCD ||   Greater Common Divider      ||    2                 ||          1               ||       1         ||       0        ||
@@ -67 +67 @@
 || COPROC_TYPE_CPY  ||   Memory Copy                      ||    1                 ||          1               ||        1        ||       0        ||      
 
- === 1) void '''giet_coproc_alloc'''( unsigned int   coproc_type,  unsigned int*  info,  unsigned int*  cluster_xy ) ===
+ === 1) void '''giet_coproc_alloc'''( unsigned int   coproc_type,  unsigned int*  coproc_key,  unsigned int* coproc_info ) ===
 This function allocates a private coprocessor to the calling task, taking a lock to grant exclusive ownership.
 In the current implementation, the task exit if there is no coprocessor of requested type in the same cluster as the calling task.
 In case of success, it returns the coprocessor characteristics in the '''coproc_info''' and '''cluster_xy''' variables.
  * '''coproc_type''' : see supported types above
- * '''coproc_info''' :  nb_to_coprocs = info[7:0] / nb_from_coproc = info[15:8] / nb_config = info[23:16] / nb_status = info[31:24]
- * '''cluster_xy''' : cluster coordinates
-
- === 2) void '''giet_coproc_release'''( unsigned int   cluster_xy ) ===
+ * '''coproc_key''' (return value) : identifier for coprocessor access
+ * '''coproc_info''' (return value) :  nb_to_coprocs = info[7:0] / nb_from_coproc = info[15:8] / nb_config = info[23:16] / nb_status = info[31:24]
+
+
+ === 2) void '''giet_coproc_release'''( unsigned int  coproc_key ) ===
  This function releases the coprocessor allocated to the calling task.
  * '''cluster_xy''' cluster coordinates
@@ -315 +316 @@
 
 
-