Re: [openrisc] OR1200 ASIC Success probabilities.

["Damjan Lampret" <lampret@opencores.org>]

Christian,

first I need to say that OR1200 has been intentionally split into many
submodules for better overview. It does not mean that many modules mean
slower design. You can put everything in a single module and it will be just
as slow as many modules. However it is true to say if you would synthesize
OR1200 submodule by submodule then results would not be good as inter module
optimization might be less effective.

It is important to point out that all the effort so far went mostly into
making sure the core works properly and only limited effort went into speed
optimizations. All speed optimizations are welcome (I'm thinking to create a
branch that could be used by people to optimize it for speed).
Looking at this path it looks strange indeed. The dbg module and sprs module
up to genpc/spr_pc_we could be path of one path and the rest should be a
different path. Second path starting in genpc_taken is part of insn fetch
logic, instruction cache/immu abort logic. Because OR1200 has only 5 stage
pipeline this path is a bit long due to a lot of different logic needed to
perform all the necessary steps in insn fetch (and more important if insn is
aborted, fetch stalled resulting in stall of pipeline etc etc).

It is important to take into account speed of your RAMs. As in some cases it
can happen that RAMs used for data/insn caches and for MMUs are so slow that
in fact those paths starting at RAMs are timing critical and not this path
that you brought up.

So in this case I think it is possible to split this path and save 1ns.

regards,
Damjan

----- Original Message -----
From: "Christian Melki" <christian.melki@axis.com>
To: <openrisc@opencores.org>
Sent: Thursday, June 05, 2003 5:03 AM
Subject: [openrisc] OR1200 ASIC Success probabilities.


> Hi ppl.
>
> Im back with a few more questions. This time on the ASIC
> synthesis timing analysis from the OR1200. Take a look at the following
> timing path attached as a file. ( because wrapping text makes the
> data much harder to read. ). Ill give you the short version right here
> though.
>
> dbg_op_i[2]
> in du/dbg_op_i
> out du/du_write
>
> in sprs/du_write
> out sprs/pc_we
>
> in genpc/spr_pc_we
> out genpc/taken
>
> in ctrl/branch_taken
> out ctrl/no_more_dslot
>
> in genpc/no_more_dslot
> out genpc/icpu_adr_o
>
> in cpu/icpu_adr_o
> out icpu_adr_cpu
>
> in immu_top/icpu_adr_i
> out immu_top/icpu_err_o
>
> in immu_top/icpu_err_o
> out immu_top/icpu_err_i
>
> in if/icpu_err_i
> out if/if_stall
>
> in freeze/if_stall
> out freeze/ex_freeze
>
> in except/ex_freeze
> out except/flushpipe
>
> in ctrl/flushpipe
> out ctrl/alu_op_reg ( endpoint, flip )
>
> ...
>
> the in/out are the in and outpoints in each module.
> the data touches some 8(!) modules with logic inside
> them.. and then proceeds to end in a decoded alu-op flip-flop.
> This path seems utterly strange to me. I can't for the
> world figure out why a signal would touch that much
> in the cpu before it ends somewhere.
>
> Can anybody hint me? No wonder the cpu doesn't do
> 200MHz+ easily.. :)
>
> /Christian
>

--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml