• State Accepted Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 9 replies
  • Subscribers 349 subscribers
  • Views 9097 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

ARM9 replacing Cortex M3

Michael von Hauff
  • 0
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    RAM size and Flash size are not factors (even the smallest amounts available are enough)

    I am aware that the DMA does not run as fast, which is why the Cortex M3 is not sufficient. The fastest available cortex m3 is 72Mhz, which gives a DMA transfer speed of 18Mbytes/s. A 100MHz version is going to be available soon but I am not holding my breathe as it would barely fit the requirements (maybe not even).

    I am interfacing to devices capable of 40MByte/s transfer speeds. The peripheral is not the current limitation. The DMA is.

    All I care about!:
    Standby Power
    Wake time
    DMA transfer speed

    Wakeup time is the hardest thing to find out. But I am hoping someone has had some experience with an ARM9 varient and will share that knowledge with me.

    Thanks,

    Mike.
  • 0
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    Sim,

    From what I can see from the app notes and data sheet, the DMA transfers a word every 4 cycles (5 according to the HITEX guide). which is 18Mword/s =>36Mbytes/s  at 72MHz

    Unfortunately that is not quite enough. I am outputing to two external highspeed 8bit DACs at min of 36Mbytes/per dac. So even if I interleave the data I will still only be sending to the DACs at 18Mbytes/s per DAC.

    Please tell me if I am wrong about the DMA speed! If so I will get going with trying out the cortex m3!

    thanks,

    Mike.
  • 0
    Note: This was originally posted on 8th January 2009 at http://forums.arm.com

    Hi,

    Thanks for the input everyone.

    Oops about using word to describe a halfword (16bit). The Cortex M3 is limited to 16bits for interfacing with the outside world (FMCS and GPIO ports are 16bit). So 16bits is my limit!

    There are definitely other issue to contend with (bus contention is one). But the reason I am so focused on the three things I mentioned (wake time, dma transfer speed, and power consumption) is because those three characteristics are the absolute deal breakers. If they are not met, the mcu in question is dropped without a second glance. Other issues that crop up will be dealt with later.

    However, since I am not an arm expert, I was hoping to gain some insight from other arm users!

    That is a good thing to know about the dma being a factor based on the vendor and not ARM. The GPIO pin issue was something else I was looking at, so thanks for the input on that too! The STM32 data sheet says you can drive the GPIOs (some ports) at 50MHz tops. That's fast enough for me!

    I am thinking that even a 133MHz bus would be fast enough if a DMA transfer take 4 bus cycles (Nyquist theorem, need >= 20MSamp/s pushed to DACs)


    So to direct the thread a little bit away from the DMA issue and more onto the wake time.

    Anyone have experience with ARM9 variants concerning wake time?

    The M3 was my first choice because it has a high speed internal oscilator, so you can be up and running at 8MHz (good enough for the first couple hundred instructions), and then switch over to the HS external.

    But now that I am looking at ARM9s I have to contend with no HSI. I was thinking that a specialized oscillator that has a fast start up time (they exist apparently) would help cut wake time, but what about the PLL? anyone know what the PLL lock time is on their ARM9 (ie, if you are using some arm9 variant, does your data sheet or experience tell you the pll lock time?)

    Thanks for all the input.

    Mike.
  • 0
    Note: This was originally posted on 8th January 2009 at http://forums.arm.com

    Oh ya, about the FPGA. I am actually looking into that in parallel. IGLOO FPGAs look promising because of the low power characteristics. I am going slower on that though, I dont have a lot of knowledge concerning FPGAs (have done some simple projects but nothing that took a FPGA to its limit), so looking at the data sheets is not as illuminating as mcu data sheets..

    The big hurdle in that is convincing my bosses. To go the FPGA route can be a huge money sink, which would be ok if we had any idea what the size of this sink would be :)

    If we exhaust all mcu options we will be turning to FPGAs to see what we can do.
  • 0 Arm Employee Badge
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    ARM9 MCUs are only just starting to hit the market, but most major vendors are now starting to ship them. Googling "ARM9 microcontroller" seems to produce a lot of interesting hits, including one with a 400MHz clock speed. 

    What MCU you chose will probably depend on other factors such as RAM size, Flash size, and what IO or peripherals are available. There are normally a thousands of possible options across all of the ARM partners for this, so I can't really recommend any particular device.

    I guess the other question is DMA from what to what? RAM to RAM will possible faster than Flash to RAM, and will certainly be faster than Peripheral to RAM given slow IO speeds on most MCUs. It is also worth noting that DMA is not normally related to the core speed, but the busbandwidth and the interface type of the component being DMA'd. DMA'ing a tranfser from a fast RAM to a different location in the same RAM can be slow because it breaks up burst accesses to the memory, and non-sequential access to DRAM can be very slow.
  • 0 Arm Employee Badge
    Note: This was originally posted on 9th January 2009 at http://forums.arm.com

    If you cannot find a system which can get the performance out of an ARM+DMA, there are some ARM-based SoC designs which provide two ARM cores. One ARM could act as a DMA, and the other could run the rest of your software. The ARM core is designed to run at high performance, so should be able to supply data to the main bus as fast as the external pins can accept it.

    The active power would be higher than a suitable ARM+DMA, but you already stated that you did not think this is a design constraint.
  • 0 Arm Employee Badge
    Note: This was originally posted on 8th January 2009 at http://forums.arm.com

    Bear in mind that on ARM, a word is 32 bits. Therefore, 18Mwords/s equates to 72MB/s.

    If your DACs are external, your biggest problem is likely to be the rate at which you can drive the physical pins on the chip. The GPIO peripherals on most MCUs are fairly slow as it takes a relatively large amount of power to drive them quickly. Of course, this depends on how you are interfacing with the DAC, but most serial protocols implemented in MCU peripherals will not be able to transfer data that fast. Typically, they require at least two bus clocks for each bit that is sent, and they tend to have additional overheads too.

    If the DACs are on-chip, you may not have this problem. On-chip DACs often don't have a sufficiently high precision for some applications, but you said that you only require 8 bits so if they're fast enough they may be worth considering. Also bear in mind that many on-chip DACs can be made to run faster at the cost of some precision, so a 10-bit DAC that isn't quite fast enough may be configurable to allow it to run faster if you accept that the lowest two bits will not be correct. This is certainly the case with the ADCs on NXP's LPC devices as I've used them before, and DACs are often similar in implementation to ADCs.
  • 0
    Note: This was originally posted on 8th January 2009 at http://forums.arm.com

    Hi Mike,

    The issue you are facing is not a limitation of the CPU core, but a limitation of the system level design.  Even with a 200MHz or 400MHz ARM9, it might not be able to reach your targeted DMA speed because the DMA bandwidth is limited by a number of factors outside the CPU core:
    - DMA controller design (microcontroller vendor specific)
    - bus frequency (cpu clock, system bus and peripheral bus can all have different operation frequency. E.g. the Atmel's AT91SAM9G20 can reach 400MHz for the CPU core, but system bus is 133MHz)
    - Peripheral bus bridge latency (If GPIO is on APB periheral bus, each transfer takes at least 2 cycles, and bus bridge itself might add additional latency)
    - SRAM access speed (usually it is zero waitstate for internal SRAM)
    - Bus access priority (if both CPU and DMA try to access SRAM/GPIO at the same time, which one has higher priority?)

    I am not saying it cannot be done. I just want to point out the areas you need to check. Hope this can help your device selection.

    On a completely different approch, have you consider using FPGA with Cortex-M1?
    Joseph
  • +1 Arm Employee Badge
    Note: This was originally posted on 7th January 2009 at http://forums.arm.com

    Mike,

    What are you trying to achieve? A 72MHz Cortex-M3 should be able to move upto around 144 MBytes per second using word transfers or around 36MBytes per second using byte transfers.

    s.