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?
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).
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.
In reply to Nizamudheen A:
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?
In reply to touse:
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?
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.