OPENCORES.ORG

"mul" and "mac" instructions have their results ready after three cycles.

Pretty much correct everything that you said in your original email.

> "mul" and "mac" instructions have their results ready after three cycles.
>

"mac" takes effectively one clock cycle if there is no data hazard.
Otherwise it takes 3.

>
> Things I'm not clear on:
> - How does the MMU affect LSU execution time?

It doesn't. Except in some rare cases when you flip from one page to the
other during fetch. This happens rarely with 8KB pages helping in this. When
there is page flip it takes an additional clock cycle to fetch first
instruction on next page.

> - Can the LSU accept another load/store while a load/store is currently
> in execution? (Would a store instruction have to wait, like, 10 cycles
> when a load instruction missed?)

Unfortunately this is calar design and as such every insn has to execute
(with an exception of mac). So if load is delayed i nexecution, everything
behind load has to wait.

>
> Based on these assumptions, this is the gcc function unit definition I'm
> proposing:
>
> (define_function_unit "alu" 1 0 (eq_attr "type"
> "shift,add,logic,extend,move,compare") 1 1)
> (define_function_unit "alu" 1 0 (eq_attr "type" "mul") 1 3)
> (define_function_unit "lsu" 1 0 (eq_attr "type" "load") 2 2)
> (define_function_unit "lsu" 1 0 (eq_attr "type" "store") 1 1)
>
> I'm also pondering how to implement an option to freely specify LSU
> latencies from the gcc command line for cache-less implementations.

This would be nice. Although I don't think it would be of much use since
code scheduled with above rules would already be optimal for cache less
sytems anyway. So what is the point?

BTW what would be excellent is if you had a look at code size. It seems
current toolchain is not very efficient when it comes to code size. I know
that folks have used MIPS compiler in the past and mapped generated code to
openrisc. The two architectures are similar enough that this is possible. I
hear that MIPS compiler generates smaller codee than GCC. So investing in
direction of code size would be very much valuable (I know a couple of
openrisc based ASIC projects where code size is very important...)

regards,
Damjan

>
> Heiko
> _______________________________________________
> http://www.opencores.org/mailman/listinfo/openrisc