• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 439 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

C6474 EVM

C6474
Prodigy 20 points

step 1 :  I loaded the led project into C64PLUS_1A. The leds flashed.

step 2: I loaded the led project into C64PLUS_1B. The leds flashed much slow than the step above.

The core 1A and core 1B should be both at 1Ghz. How could the core 1A is faster than 1B on led project?

  • 0
    TI__Mastermind 18130 points

    I remember running into this problem when I tried it out several months ago, but sadly I never got to go back and figure out why this happened. I suspect this may have something to do with the GEL file configuration of core B, but I cannot be certain.

  • 0
    TI__Guru* 84110 points

    The LED test application was specifically intended to run on C64PLUS_1A. There is not a good reason for that, but it is certainly an acceptable thing to do.

    The linker.cmd file uses 0x108xxxxx for the L2 addresses, so this defines the memory space for the LED program to be in the globally address memory area for C64PLUS_1A which is refered to as Core 0 in the datasheet. At this address, Core 0 is able to access the internal program and data at full L2 speeds while the other cores have a slower path to here. So when you load the program and run with Core 0, the program runs at full speed as it was intended; when you run the same program with Core 1 from the same 0x108xxxxx address, the speed is significantly slower because of the longer logic distance required for the memory paths.

    The EVMC6474 BSL library uses simple 'for' loops for the delays, so slower program and data accesses will cause the actual delay to be longer. This is why the LEDs blink at a slower rate when the test is run with Core 1.

    If you change the addresses in the linker.cmd file to use 0x008xxxxx, then each core would load and run from its own local address range and you would see the faster execution from each core.

    This is a very good demonstration for the efficiency that you get when using the internal memory that is closely associated with a core rather than using other internal memory that is not closely associated with that core. You would likely get similarly slower speeds if you placed the program and data in DDR2 memory space. And if you enable caching, I would expect the blinking to speed up again no matter where the program and data are located. Please note that I did not look closely at the caching configuraiton for this reply, so the previous statement is offered "as is".