Re: [oc] some questions

[jimmy87@sunplus.com.tw]

> 1. no uncached region defined in OR1K? You know it's important for I/O.

I/O region defined in MMU (didn't I put this in virtual memory doc?).

^^^
In fact, sometimes, if your MMU goes wrong, the whole TLB may be closed.
Then, how do you do memory access? I think we had better not let CPU
access TLB every time the load/store insns are accessed or whenever
insns are accessed.
AHHH..gotta go home. talk to you tomorrow morning. it's 9:00pm here in Taiwan.
Best regards,
Jimmy






"Damjan Lampret" <lampret@opencores.org> 於 2000/03/02 07:25:32 PM

請回應 給 cores@opencores.org

收件人：  cores@opencores.org
副本抄送： (副本密送： jimmy87/Sunplus)

主旨：    Re: [oc] some questions



First OR1K is family. A lot things depends on implementation. And docs are
bad (who has the time to write docs ;-).

> 1. no uncached region defined in OR1K? You know it's important for I/O.

I/O region defined in MMU (didn't I put this in virtual memory doc?).

> 3. no flags for privilieged-mode access? for example, kernel mode?

Current status in Machine Status register. Access to pages in page tables
(if MMU enabled).

> 4. I try to use i386 gcc but segmentation fault whenever I run it.

Try to compile gcc 2.95.2 (apparently your linux is a bit different then
mine). Sources are available on web.

> 5. It seems that or1k has only 16 GPRs(according to 4-bit reg insn
encoding),
>     but there are 32 GPRs in or1ksim.

You can set whatever number of registers you want in simulator but only
lower 16 are used. If it bothers you just set MAX_GPRS and recompile
or1ksim.

> 7. Right, what's the latency and throughput of your MUL and DIV insn? Will
you

Implementation specific.

> 8. What's your entry replacement strategy of 64-entry unified TLBs?

OR1001 has 2x16 TLBs.

> 9. OR1K's architecture is Harvard or VonNeumon? If Harvard, does OR1K have
one
> Instruction TLB, which is separated
>     from 64-entry TLB?

You mean Stanford. Implementation specific.

> 10. Any software interrupt instructions for OS's syscalls?

Yeah. If I remember correctly it is not yet in ISA (which is pretty old
BTW).

> 11. The chip bus interface is also important for embedded usage. I still
can't
> see the document.

Sure it is. Currently proprietary (and quite simple) but will be replaced
with AHB. Sorry, no docs yet. Working on docs.

regards, Damjan