Tiva-tm4c129.c macro blocks pbuf_alloc() payload from SRAM bit-band address space?

BTW: Consequently the pbuf's payload comes off the Heap when we Transmit a packet, placed in the TX-FIFO by EMAC0 DMA.
Does it not stand to reason the DMA-able payload write space is defined by hardware alone not the software restriction macro?

Perhaps to misunderstand the reason why ever need to copy (pBuf) from Bit band SRAM onto the Heap. Better yet how (pBuf) could ever escape the Heap after or during pbuf_alloc(). 

Macro text suggest it will only copy the pointers to buffers (pBuf) if NOT found in physical DMA memory. Oddly pointer (p)->Buffer allocation is seemingly read/write via Heap never accessed bit band memory directly. Again the scatter gather hardware process handles transfer from the Heap to physical data SRAM data locations. 

The same may not hold true of Tx/Rx Descriptors stored in physical memory awaiting later allocation to a (pBuf) assigned by LWIP to be placed on the Heap.

*Note: Discovered STATS debug is enabled on all sections (tiva-tm4c129.c) when the user has set DEBUG=0 in (lwipopts.h) or other location. Simply remove (def) and leave the (if) from all debugs make them inactive code. We use bubble gum pink for inactive code preference in CCS and  think of watermelon bubble gum most all day long. :-)

May we note that the "addition" of "?" - to terminate an (otherwise) declarative sentence - may confound/confuse...   (i.e. thread's title)
My read - such (often) constitutes a "shout" - in which the writer seeks to (overwhelm) - does not (really) seek a 2nd opinion...

You Sir - prove once more - to be a master communicator.     Some may challenge such methods - I'm merely a simple reporter...

Have come to know CB1 that master of phonetics. Often requires lessor intellects time to decipher the advanced and sometimes encrypted payloads meaning.

Perhaps should merely ask: Why is physical memory referred to as SRAM when it doesn't appear to be physically accessible?

Bit Banded SRAM to me is considered logical being the memory map address size exceeds the physical kilobytes by 2x. The logical addressable map space does not directly represent stored data bit span 256KBytes in 1:1 ratio. The logical approach stems back to 1980's Intel days when address segment offsetting gained access to 1 megabyte of physical DRAM via 16 bit registers of the 8086 CPU. Recall Intel first broke the 128KB, later 256KB address space barrier. Reminds of those RAS/CAS refresh cycle days.

Data sheet states descriptor Lists are located and stored in physical memory and SRAM both. 

How can SRAM be both physical and logical in the same paragraph, leaves puzzled looks of apprehension ones face. The datasheet puts forth no evidence of there being any physical addressable memory at 0x2000.0000-2003.FFFF or 256KB. Instead the memory map shows Bit band 0x2000.0000-0x2006.FFFF or 512KB. The MPU architecture claims to have 256KB of SRAM.

Where on Earth would a pBuf exist other than SRAM after the DMA retrieves or transfers the data to or from the FIFO and the pBuf freed or re-allocated?

By the datasheet text the pointer (p) could never exist outside of DMAable SRAM as Bit Band memory address space bus control prohibits such mayhem. Or does it? Time bomb payload acts like some kind of C+ embedded virus that sneaks in under the radar.

Tivaware complains sub set out of range upon trying to assign any address value other than 0x0000.0000 to both REG-55 or 56. Seemingly the struct configured in ~ListSet believes Reg-55,56 should always be zero so why then even have these registers? Seems to me a ground stomping Hatfield & McCoy's feud rises flags inside TM4c kingdom and neither side is willing to admit or submit to any turf gained.

  //
  // Set descriptor pointers [physical SRAM address] in the hardware.
  //
  EMACRxDMADescriptorListSet(EMAC0_BASE, &g_pRxDescriptors[0].Desc);
  EMACTxDMADescriptorListSet(EMAC0_BASE, &g_pTxDescriptors[0].Desc);

The hosts physical memory is located where in the data sheet memory map or might that imply the Heap?

According to the data sheet REG-55 ,56 points to the physical start address where the descriptor list exists, Not to the actual struct alias pointer to the descriptor.  Reason deducts that address to be 0x2000.0000. Have read several program notes, refers the Host to be the CPU and at times the application. Very confusing this word host used in the context of physical memory.

//*****************************************************************************
//
//! Sets the DMA receive descriptor list pointer.
//!
//! \param ui32Base is the base address of the controller.
//! \param pDescriptor points to the first DMA descriptor in the list to
//! be passed to the receive DMA engine.
//!
//! This function sets the Ethernet MAC's receive DMA descriptor list pointer.
//! The \e pDescriptor pointer must point to one or more descriptor
//! structures.
//!
//! \return None.
//
//*****************************************************************************
void
EMACRxDMADescriptorListSet(uint32_t ui32Base, tEMACDMADescriptor *pDescriptor)
{
    //
    // Parameter sanity check.
    //
    ASSERT(pDescriptor);
    ASSERT(((uint32_t)pDescriptor & 3) == 0);

    //
    // Write the supplied address to the MACRXDLADDR register.
    //
    HWREG(ui32Base + EMAC_O_RXDLADDR) = (uint32_t)pDescriptor;
}

Not Explicitly clear in the memory map and placed below the topic of Enhanced DMA descriptors is found that mysterious Physical memory.