[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [f-cpu] register set



> Fortunately, VHDL provides a way to decouple the interface
> from the implementation : the "entity" and the "architectures"
> so when someone targets a specific technology, he adds a new
> architecture and respects the interface that was defined
> in the "entity". If his technology provides a 1-to-1 mapping
> of the desired function : fine :-) otherwise, a certain amount
> of code is necessary to "wrap" the physical entity.

Yes, I also think it is the best. Define a good entity that could be frozen if
everybody agree on it and keep a (dummy)  behaviorial architecture that could be
replaced be a real stuff (two port SRAM, register bank IP or synthetized FF ...) later
on.

About two-port and dual-port RAMs, with UMC techno for instance, you can have two-port
SRAM which have separe read port (RADDR, DOUT, RCLK, REN) and write port (RADDR, DOUT,
RCLK, REN). You can do 1 read and 1 write in the same cycle (eq. to register) but this
is not a dual-port since read/read is not possible. I'm using those memories a lot in
my current design, I have plenty of models for them (but I cannot disclose them,
sorry) and I can tell you that they will beat any other solutions as well for power
than for area ... For instance, a 16x64 two-port module in UMC CMOS .18u as a access
time of 2.2ns, an area of 34 um^2 and consumes max 28 uW/MHz (full load in rd and wr)
...

Bruno

PS: and about the troll about latches, I hope that NicO have more authority than me
and Kim to convice some of you ... Avoiding latches is one of the first rule you learn
when you start doing design !


*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/