Changes between Version 3 and Version 4 of 802.11/wlan_exp/log
- Timestamp:
- Mar 22, 2014, 4:26:33 PM (10 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
802.11/wlan_exp/log
v3 v4 9 9 * The first byte of the log space will always be the first byte of a log entry header (see below). Even when wrapping is enabled individual log entries will always be continuous in DRAM, starting at the beginning of the log DRAM space. 10 10 * The logging system will never truncate a log entry at the end of the DRAM. The logging code remembers the index of the last byte of the last log entry written (called the "soft end" in code). 11 12 The logging code does not enforce any alignment on the user-supplied entries. The 802.11 Reference Design hardware includes alignment handling code and logic (MicroBlaze unaligned access exception handling and data realignment engine (DRE) in the axi_cdma) to handle arbitrary alignment of data in DRAM. However it is recommended that the size of user-defined log entries be a multiple of 4 bytes. This will improve performance in reading and writing log data from the 32-bit MicroBlaze processor and ease the parsing of log data after an experiment. 11 13 12 14 === Indexing === … … 24 26 === Wrapping === 25 27 26 For many experiments the pre-allocated DRAM space will suffice to record the full log. However for long experiments the log may reach the end of the DRAM allocation. The logging system implements wrapping which, if enabled, will begin overwriting the oldest log entries as new log entries are created. Wrapping enables experiments to run non-stop for very long periods28 For many experiments the pre-allocated DRAM space will suffice to record the full log. However for long experiments the log may reach the end of the DRAM allocation. The logging system implements wrapping which, if enabled, will begin overwriting the oldest log entries as new log entries are created. Wrapping allows experiments to run non-stop for very long periods (limited only by the 32-bit {{{num_wraps}}} value). 27 29 28 30 Wrapping can be used two ways: 31 * The user can read the log data continuously, retrieving log entries faster than they are written. This approach extends the limit on log size to the storage capabilities of the user's PC (typically much larger than the WARP v3 node's DRAM). 32 * The MAC code records log entries continuously, wrapping as needed, with an application-defined stop condition implemented in the MAC code. Once stopped the log will be preserved for eventual retrieval by the user. This approach mimics a trigger condition on a logic analyzer. Following the trigger the user can look backwards in time to understand the series of events the preceded the trigger event. 29 33 30 34 == Log Entry Format == … … 37 41 * '''Log data''': log data supplied by the application. The logging system performs no processing of log data - user code must enforce whatever structure is required by the application. 38 42 39 40 41 43 An example of the log memory layout is illustrated below. 42 44 … … 45 47 [[Image(wiki:802.11/files:wlan_exp_log_layout.png, width=500)]] 46 48 49 A few things to notice in this example: 50 * Every log entry begins with an 8-byte log entry header 51 * The user-supplied entry type ID is arbitrary 52 * Log entries of the same type can be different sizes, as the (type, length) tuple is supplied by the application per-entry.
