Re: Testing hte CPU

"Jamil Khatib" <[email protected]> Sat, 09 Aug 2003 06:50:41 +0000
Newsgroups gmane.org.handasarabia.ofoq
Message-ID <[email protected]>
Hi,
I think in our case the lase approach is the best one.=20
I am going to make a small proposal about a bridge between the PC and on
board SRAM.
Please keep us informed about the memory controller status because I may need
it to design the bridge.

I hope that we can get a small program that turns some leds on the board to
test the CPU. Anyone can do it?

Best regards,
Jamil Khatib

On 8/6/2003, "Soban Shoeb Chawre" <[email protected]> wrote:

>Hello Jameel,
>
>It is true that we have not progressed much on the project. But I have
>started working on memory controller.
>
>Here is part of mail from opencores mailing list  on same issue. Hope it
>helps...
>
>I can think of three possible approaches (there are no doubt more),
>which
>are as follows:
>
>1) Make the CPU RAM dual-ported. Then use an external micro or host to
>hold
>the CPU in reset and write the contents of the CPU's code and
>initialised
>data into the CPU RAM. Then release the reset line.
>2) Code a simple bootstrapper/monitor into CPU ROM which can load the
>CPU
>RAM from an external source and switch memory maps after it has loaded.
>3) Make a hardware bootstrapper which can hold the CPU in reset, load
>the
>CPU RAM from an external source and release the reset line.
>
>(1) is a suitable approach for a development platform where the FPGA CPU
>is
>hosted by another CPU, for example, a PCI card hosted by a PC.
>(2) is more appropriate for an embedded platform where the external
>source maybe a serial EEPROM (which will still need to be programmed
>somehow) or a serial line communicating via XMODEM or something similar.
>eCos Redboot is an example of this sort of system.
>(3) is a similar approach to (1) but uses an active hardware
>bootstrapper to
>control the loading as opposed to a host CPU.
>
>This may at least get you thinking on what is appropriate for your
>platform.
>
>Best Regards,
>-Soban.
>
>Jamil Khatib wrote:
>>
>> Hi all,
>> I am trying to figure how can I test the CPU on the board to make sure
that
>> it is alive. I am thinking turning some leds on the board but I do not
know
>> how to do the software for that and where the software should reside.
>>
>> The memory controller is still not available besides that I do nto have a
>> flash programmer at home to burn the flash each time I want ot make a
test, I
>> can program it at work or university only.
>>
>> I do not know if we can dump a binary file to the SRAM directly then
allow
>> the CPU to use it. I may write a small VHDL code to get the binary data
from
>> the PC parallel port then write it to the SRAM do you think it will work?
Did
>> anyone check the OpenRisc debug port? can we use it for this reason?
>>
>> Please let me know your comments so as to make some progress with the
project
>> we have not done anything for long time.
>>
>> Best regards,
>> Jamil
>>
>> -------------------------------
>> OFOQ Mailing List
>> Handasa Arabia Organization
>> http://www.handasarabia.org
>>
>> Message number 57
>
>-------------------------------
>OFOQ Mailing List
>Handasa Arabia Organization
>http://www.handasarabia.org
>
>Message number 58

-------------------------------
OFOQ Mailing List
Handasa Arabia Organization
http://www.handasarabia.org

Message number 60