Re: [openrisc] generic flip-flop based memories.

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

Christian,

I don't think it makes sense to have them flop (or latch) based (except of
you don't have them as hard macros and can't generate them) since they will
be slower and bigger. What I'd do if I wouldn't have memory compilers, I'd
design a latch based hard macro and use it instead of any currently
supported hard macro memories.

Yes you are right, the second stage is to have it balanced by synthesis
tool.

MAC in two stages. Yes probably, it depends what kind of libraries and
process you use. In some cases critical path can be the multiplier stage of
the MAC.

regards,
Damjan

----- Original Message -----
From: Christian Melki <christian.melki@axis.com>
To: <openrisc@opencores.org>
Sent: Wednesday, March 26, 2003 2:22 AM
Subject: [openrisc] generic flip-flop based memories.


> Hi ppl.
>
> Would there be any purpose in implementing just the
> spram_64xXX memories as generic type mems? would they be slower?
> spram_64x14-2x is on the right side of the limit?
> I guess you always can get faster memories than generic flip-flops.. or?
>
> A few questions about the generic multiplier..
> Is the second empty stage supposed to model a two-cycle multiplier?
> When inferred by a synth-util ( such as DC or BG. ) will the
> the program infer a 2-stage pipelined mutiplier?.. im
> really not sure about the behaviour.. i understand that
> this probably differs quite a lot from util to util.. and
> what "models" you have bought with them..
> Also. When doing MAC. Wouldn't there be room in the second
> stage for the add? Instead of doing (3-cycle? if i got it right? )
> the current way..?
>
> best regards.
> /Christian M
>
>
> --
> To unsubscribe from openrisc mailing list please visit
http://www.opencores.org/mailinglists.shtml
>

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