Hi, all!
When using C6474 simulator to simulate one program, from the datasheet, it seems that any core can access any memory on-chip through the global memory map! The problem is when core 0 tried to access the L1D sram in core1 ( which is configured as L1d sram, not cache), the simulator terminated because of serious error!
As all the on-chip memory has its unique global address, so it should be accessed directly by any DSP core, is that right? What caused the CCS simulator to be terminated then?
Thanks all!
touse
Digital Signal Processing, ARM DSPs, Embedded System, Multi-core Programming
The problem you noticed (I am reading his ‘the simulator terminate because of serious error’ statement as simulator becoming unresponsive) could be related to a usability gap in the multi-core simulator configurations (that includes the C6474 simulator configuration).
Essentially, the simulator becomes unresponsive on an asynchronous simulator-run (some specific scenarios). I am planning a simple fix by popping-up error messages in such scenario and prompt user to perform a sync-run. For the time being, I recommend you to use sync-run.
What does the sync-run mean? run the three cores synchronously? How to run the multi cores at the same time then?
The simulator I chose is 'TCI6474 simulator symmetric ', the problem is whether I can access the other core's in-chip L1 and L2 memory configured as SRAM and How can I access? Before accessing, the core may not know the configuration of the other core's in-chip memory. that is, the present core doesn't know whether the other core's in-chip memory cache or SRAM!
From the data sheet, it seems any core can access any in-chip memory through the global address, is that true?
Sync-run: The sync-run means issuing a run-command from CCS to all the cores in the system. This is possible thru the 'Parallel DEbug Manager' (the first window -- the small one-- that pops-up when you invoke the simulator).
In TCI6474, i beleive each core can access the internal memory of the other cores, thru global address. The application running on each core should know the memory-map of the device. Hope this helps.
well, I found the errata of async-run for multi-core DSPs in http://wiki.davincidsp.com/index.php?title=CCSv3.3_SR12_Simulation_Errata !
So I patch the errata zip as instructed, but still when I run one core to write something to the other core's memory, the CCS hangs with no response! Can the errata zip solve the problem of asyn-run error of multi-core simulation?
I am not sure if you used the 'sync-run'.
The recommendation is to use the 'run' command from the 'CCS Parallel Debug Manager' , rather than the run command from the individual CCS. Please confirm this
I tried the parallel run in "Parallel Debug Manager" as well as the the individual run of every core! The CCS hangs no matter parallel run or not!
From the solution guide listed at http://wiki.davincidsp.com/index.php?title=CCSv3.3_SR12_Simulation_Errata, I think the asyn-run problem can be solved after the replacement of the configure files!
Did replacing the configuation file help? If not, will you be able to share the code that cause the problem, and the steps to run it on the simulator?
I replaced the configuration files with the extracted files from the errata zip, and now I can run one core after another! But when I use sync-run, the CCS hangs! Is it because of the cache configuration! I split the 32KB L1D of each core into 2 part, one 16KB for cache, one 16KB for L1DSRAM! When the cores run synchronously, how could the present core know the state of the on-chip memory allocation of the other cores especially when I'd like to access the other core's on-chip memory?
I think, The application has to 'develop' knowlegde of the current cache configuration acorss all the core's in the system. It should maintain state in the application
Given a Chip specification, a given core can identify
However this is not possible when one core wants to inpect the cache Vs RAM partition on other core's cache. Becuase, i beleive, L2CFG register is not accessible from other core. Hence the run-time Cache Vs RAM partition cannot be inferred.
So, I advise ........The application has to 'develop' knowlegde of the current cache configuration acorss all the core's in the system.
As one core can't access the other core's cache configuration registers, so I think the work of devoloping knowledge of cache configuration across all the core's may not be necessary. If the other cores have already initialized the cache configuration registers, the current core can access the other core's on-chip memory even if it doesn't know how to access the configuration registers!
So is it possible for the current core to access the other core's on-chip memory after the other core's DSP/BIOS memory configuration initialization?
>> So is it possible for the current core to access the other core's on-chip memory after the other core's DSP/BIOS memory configuration initialization?
Yes. It is possible for one core to access the other core's intenral RAM.