instance support :: Bugtracker

The openrisc bugtracker has been moved to: bugzilla.opencores.org. This page is read-only

instance support

Information:
Type :: REQUEST
Status :: CLOSED
Assigned to :: Jeremy, Bennett

Description:
or1ksim is written by C and uses many global variables.
So cannot place multiple number of it.

And then it cannot be allowed to use same address between two or1ksim.

Could you support this in the future?
At least two CPU instance should be supported.

Regards,
swaka

Comments:

Bennett, Jeremy	Jul 4, 2011
Transferred to OpenRISC bugzilla (Bug 43). Marking closed in this bugtracker.

Bennett, Jeremy

Jul 4, 2011

Transferred to OpenRISC bugzilla (Bug 43).

Marking closed in this bugtracker.

Wallentowitz, Stefan	Mar 19, 2009
Dear all, I have finished with this job. If anybody is interested in testing my patch, please contact me. The solution of a container struct for all global variables is rather ugly, but may be a starting point for further modularization. Next I will start with advanced testing, but have a problem building the toolchain and getting the vmware image respectively. Stefan

Wallentowitz, Stefan	Mar 17, 2009
Hi everybody, I have recently started to remove the global variables to a container and explicit referencing of this object in function calls. This is not the nicest way, but might work. I think by the end of this week, the result might be available for testing. Please contact me in case of interest in it. Best regards, Stefan

yang, jungsook	Feb 13, 2009
Hi, Actually I've been working on this problem. I've implement C++ version or or1ksim and connect the cores with SystemC network-on-chip implementation. I'll try to elaborate it and make it public soon! jungsook

Bennett, Jeremy	Jan 15, 2009
Hi Swaka This a historic relic of how Or1ksim was written, many years ago (I was not the original author, I am just the latest maintainer). It was intended that any multiprocessor behavior would be modelled within the single Or1ksim executable. This is so deeply ingrained within Or1ksim that I believe a complete rewrite will be needed. I sympathise with the problem. It would be nice to wrap multiple instances of Or1ksim in SystemC and link them together as a multiprocessor system. The only way I can think to do this is to run each as a separate process, and provide a communication module to link them together. However this would not be very efficient. Jeremy

Bennett, Jeremy

Jan 15, 2009

Hi Swaka

This a historic relic of how Or1ksim was written, many years ago (I was not the original author, I am just the latest maintainer). It was intended that any multiprocessor behavior would be modelled within the single Or1ksim executable.

This is so deeply ingrained within Or1ksim that I believe a complete rewrite will be needed.

I sympathise with the problem. It would be nice to wrap multiple instances of Or1ksim in SystemC and link them together as a multiprocessor system. The only way I can think to do this is to run each as a separate process, and provide a communication module to link them together. However this would not be very efficient.

Jeremy