X hits on this document





9 / 13

The entire PROM is then erased and the memory must be fully reprogrammed from the serial bus, including both firmware and all MP3 files.

After this upgrade, the controller program is “rebooted” with a jump to the reset vector. The memory upload protocol is as follows:

BNF grammar

<transfer> <chunk> <header> <eofmark>

::= ::= ::= ::=

<chunk>+ <eofmark> <header> <bytes> $aaaaaaaa $llllllll $FFFFFFFF $FFFFFFFF

Where $aaaaaaaa is the destination address of the chunk, and $llllllll is the length of the chunk.

The firmware upload functionality also makes it necessary to have separate hardware ports for storing bytes in the Flash. When writing bytes to the memory, the CPU will inhibit during the writing process so that writing may commence.

All this firmware upload and flash write functionality was added to the design, but at the place and route stage it was eventually removed from the topmost component as it intro- duced project hazards. The logic is in there, but it is not used.



Synthetization of the design was performed using the Synopsys tool from Mentor Graphics. At first synthesis try, many parts of the design didn’t work. This was due to several facts:

First, a faulty toolkit from the vendor was used. This resulted in flip-flop arrays being replaced by erroneously mapped scan-path flip-flops. This was solved by downgrading to a previous toolkit for an older version of the Synopsys compiler.

Second, we had some apparent glitches in our design. This was solved in most cases by moving the signal-driving logic to a clocked process. In some cases asynchronous signals had to be used (as for the “halt” signal to the CPU) but this was apparently OK.

Third, the generated RAM memory would not work. During post-synthesis simulation, it appeared as if the RAM memory did not even exist: no signals would come out of it. This problem was a lot trickier to solve.

At first consultation with development engineers the team was informed that the RAM memory could not be added to the interior of the controller so the signals for it had to be moved to the top of the controller component, so that the post-synthesis simulation would be able to use the generated memory. Acting on this advice, the connections to the RAM memory were moved to the top component, and the generated simulation model for the RAM was then added to the testbench.

This line of thinking is not unreasonable, but was in fact incorrect in this case: RAM:s may in fact be instantiated at any point in the design. The problem was of a considerably more subtle nature: a library part of the RAM had somehow been created in the “WORK” library, taking precedence over the generated post-simulation RAM library. By removing (rm

  • -

    rf work), recreating (vlib work) and recompiling the “WORK” library (“make clean”), this

ghost-component was removed and all things started to work as expected.

From this it was learned the hard way that these tools are never intuitive and may not be trusted. In fact, they do not abstract away any part of the underlying interiors of the design tools, so a technical documentation of how Modelsim use the underlying “library


Document info
Document views34
Page views34
Page last viewedSat Dec 10 20:46:03 UTC 2016