Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics

On Jul 24, 4:43 am, Joseph <joseph....@xxxxxxxxxxxxxxxxxxxx> wrote:
rickman wrote:
Nope it isn't, the AVR32 running at 66 MHz will run mostly
at zero waitstates due to its interleaved flash controller design.
Each flash access done by the memory controller
will have 1 waitstate, but since the memory controller can do
two accesses in parallel, the CPU will only see waitstates
during jumps, and no waitstates during non jump instructions.
If you do jumps 20% of the time, then the average number of waitstates is
0,2.
On top of that you will be able to perform dataaccesses to the flash
while eating from the instruction queue wihout any performance penalty.

That is pointless. It does not matter how large the FIFO is, if you
are pulling data out at a given rate and you can only put data in at
that same rate, as soon as you have to stop instruction reads to do a
data read, you will not be filling the FIFO as fast as it is being
emptied and performance will suffer. Run through a simulation and see
if that is not true. Based on the info you provided, this is the
result.

On Cortex-M3 (and possibly AVR32 ? ), many instructions are 16-bit.
As a result, the instruction bus (32-bit) fetch upto two instructions
each cycle, while most of the time only one instructions is executed per
cycle. So it is possible to stall the instruction fetch for a cycle to
to fetch data from flash, without seeing any stall at the execution stage.

Joseph

Sure, but that does not require a FIFO. Any processor that fetches 32
bits from memory and executes 16 bit instructions will automatically
have a 2 instruction queue. There is not much point extending the
FIFO beyond that really. It is only a small fraction of the time that
you will make use of the additional stages.

Ulf seems to be mixing the idea of a prefetch FIFO and a pipelined
processor. If the processor is pipelined, you need to have data in
each stage or there is a stall. The point of a FIFO is that it can
hold a *variable* number of data elements. Combining them means you
either have stalls anytime the FIFO does not have enough data or that
the FIFO has to stay full. Either way you gained nothing from the
combination of the two. You really need to keep them separate and
have pipeline registers which are kept full as much as possible (else
you get a stall) and a small FIFO (one or two memory words) for the
prefetch. Regardless, every time you hit a branch both the FIFO and
the pipeline must be emptied, so the FIFO should have the lowest
priority (relative to data fetches) to avoid wasted memory bandwidth.
Increasing the size of the FIFO just wastes memory bandwidth without
reducing the likelihood of a pipeline stall.


.

Relevant Pages

  • Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
    ... at zero waitstates due to its interleaved flash controller design. ... Each flash access done by the memory controller ... while eating from the instruction queue wihout any performance penalty. ... but that does not require a FIFO. ...
    (comp.arch.embedded)
  • Re: FSL or DMA w/ FIFO?
    ... I would use a FIFO on the FSL. ... I'm assuming I would get one interrupt per 200 ... random access to the BRAM via the local memory bus. ...
    (comp.arch.fpga)
  • Re: New ARM Cortex Microcontroller Product Family from STMicroelectronics
    ... freeze all stages of the pipeline while you wait for the Flash to ... The prefetch mechanism loaded 32 bits into this FIFO each access. ... to determine the length of the instruction and if the FIFO ... zero waitstate operation allows to fetch almost two instructions per cycle. ...
    (comp.arch.embedded)
  • Debugging ideas.
    ... I am having problems debugging my memory controller. ... to capture a frame and display the same frame continuously. ... I think that the problem lies with an asynchronous fifo used to buffer ...
    (comp.arch.fpga)
  • Amount of free mem decreasing..
    ... The part that seems odd to me is the memory. ... ws1-hr# top -b ...
    (comp.unix.bsd.freebsd.misc)