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

Re: Rep:Re: Re: [f-cpu] No latches, please !



hello again,

Kim Enkovaara wrote:
> > first, it's a bit smaller. Depending on the amount of control logic,
> > the gain varies. The memory cell (4 transistors) requires decoding
> > and clock buffering, IIRC the sxlib FF uses around 20 transistors.
> 
> Is the logic size anymore a problem?
it remains and always will be !
IIRC most of the problems arise in the wires.
If your cells require X times more transistors, the overall
wire length will roughly increase by X. Since
most of the power is consumed when loading/unloading the wires,
and wire resistance is roughly proportional L^2,
your power dissipation will increase for less functionality.

> At 0.13u you can get about
> 200kgates/mm^2, and minimum size silicon for reasonable packages is
> around 100mm^2. Usually the logic in current generation chips is small
> grain in some corner of the chip and rest is memory. And memory is done
> quite differently layoutwise depeding on memory technology and speed
> (about 300-1600kbit/mm^2).
nice. It's the promise of a nice and wide L2 cache.

but let's not think like Microsoft ("let's consume whatever new ressource
appears"). The end user might want to use the remaining surface for
including peripherals, coprocessors, other CPUs... and everything must be testable ;-)

> Optimizing few transistors/gates is not worth the job anymore.
i don't agree here. Though we all (?) know it's difficult and heavy,
it's worth some attention ! just remember that, according to a first
approximation, one half of the circuit (surface and time)
will be used by pipeline FF. If you make a smaller FF cell, the circuit
will be directly impacted in speed and power consumption.
just by optimising _one_ gate.

> The problem is becoming power usage, yield, design sizes etc.
considering that FF might use 1/2 of the surface, yield will
be impacted as the surface will be reduced, which also reduces the
size of the clock tree (fanout, power, speed etc...)

> And to attack power use
> usually gate counts rise quite dramatically (sounds odd but this is the
> truth). For example some power saving cells have twice the amount of
> transistors to fight with power leakage in the cell.
FC0 was not designed for ultra-low power, rather for getting the best
performance for a given technology. This implies a good MIPS/Watt ratio
but in a higher Watt range. and higher MIPS too :-)

> Efficient signaling between blocks also adds more logic,
> block level clock management also is quite complex thing.
For the FC0 i don't see where it can be modified.

> > in another mail Bruno spoke about a 16*64 cell that can work at 2.2ns,
> > this puts the maximum operating frequency (.18u) at around 300 or 400MHz.
> 
> You have to remember that there are also different cell libraries for
> commercial processes. Some libraries are geared for maximum performance
> and consume more power and the yield might be lower. Then there are
> lopower cells that are slower. These things are very difficult to predict
> without real data and libraries. And those who have access to the data
> have  NDAs so we have to be very careful what we speak (no excact numbers
> only ballpark figures, no manufacturer names etc.).

NDAs hurt :-(
However, it would be cool if a lot of people asked their foundry rep. for
public-domain generic interfaces to their meory array cores.

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