ADSP-BF70x secure boot painfully slow

Question

The BF70x datasheet proclaims "Fast secure boot for IP protection", but it seems to be anything but fast in practice. 
 In my testing, a mere 6,948 byte BFp loader image with the BF70x (silicon revision 1.1) takes a glacial 183.8 milliseconds between when the SPI transfer finishes and execution is transferred to the user code. 
 In a non-secure mode, this time is practically instantaneous. 
 What am I missing? Why is a high performance DSP with integrated SHA accelerator so darn slow (37801 bytes/sec)? 
 P.S.: if Analog Devices ever makes a revision to EE-366, they really owe it to the would-be reader to mention the 0x80000002 "BCODE" attribute (presently only documented in the ADSP-BF70x Blackfin+ Processor Hardware Reference in the Secure Boot section). It is presently omitted from the EE-366 attribute list. When signtool.exe inhales a loader image, it discards the -bcode argument provided to elfloader.exe, and the resultant image is painfully slow to boot (since it defaults the slowest SPI single-bit mode). Note that this slow-as-molasses time is in addition to the secure boot image verification described further above.

pinaz · Accepted Answer

Four months after I submitted a ticket, I finally got a disappointing answer from tech support. Here it is for anyone searching for the same problem. 
 The gist is that it is an ADSP-BF70x design flaw. (It seems likely that Analog could improve/fix it with revised Boot ROM software, but that would require a mask ROM silicon change that Analog probably isn't interested in doing.) 
 The so-called "Fast secure boot for IP protection" Boot ROM code is inefficient in that it takes more than 180 milliseconds just to initialize the authentication code. If the boot code takes less than 180ms to load into memory, the secure boot DSP sits twiddling its thumbs in the interim. 
 Consider that most, if not all, SPI flash parts will clock out data in single-bit mode at 40 to 50MHz. Even assuming the slowest case (40MHz), 900kBytes would clock in 180ms. (In theory, the BF70x has provision for reading data faster from dual and quad wide flash parts, but as you'll see, the secure Boot ROM delay would be the overriding limitation on timing.) 
 900kBytes is nearly all the internal memory in the largest memory part (ADSP-BF707), so the customer's first stage secure bootloader would have to be so bloated as to occupy the entire memory before the boot time would not be slowed down by the Boot ROM.)