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

Re: [f-cpu] register set



On Tue, 12 Feb 2002, Bruno Bougard wrote:
> Juergen Goeritz wrote:
> 
> > On Tue, 12 Feb 2002, Bruno Bougard wrote:
> > > Juergen Goeritz wrote:
> > > > On Tue, 12 Feb 2002, Bruno Bougard wrote:
> > > > > Generally, optimized register-bank is provided by the technology vendor.
> > > > > I work currently with UMC and I have a RAM/register-bank compiler. This
> > > > > one generate behavioral description for the simulation and a 'blackbox'
> > > > > for the final layout.
> > > > > If you want to see how to implement such a structure efficiently, check
> > > > > e.g WESTE, ESHRAGHAN, Principles of CMOS VLSI design, Addison Wesley.
> > > > > This is also a good book to learn design.
> > > >
> > > > I can remember that they want to stay independent of technology
> > > > vendor libraries and structure compilers that are not freely
> > > > available.
> > >
> > > In that case, the best is to write a common interface in which you will
> > > encapsule the module provided by the technology vendor when you will process
> > > the chip. Meanwhile, you can work with a behavioral model that you can write
> > > easily looking at the spec of a 'typical' register bank.
> >
> > Here we are again. Do we use pre-made modules in our design
> > or do we use a behavioural description? It reminds me a lot
> > of the 74xx ttl devices which were formerly used heavily on
> > PCBs and a lot of hardware guys never quit thinking this way.
> 
> That's archeology for me ...

I worked with it and with real behavioural description later.

> > I would rather prefer a tool that automatically detects regular
> > structures in a behavioural model and replaces them during
> > compilation by vendor type things. But why force the designer
> > to use this stuff or take care of this stuff by wrappers
> > already in the design process??? Those tools suck!
> 
> I agree with you but, unfortunatelly, those tools does not work so
> good, they are affected by the coding style. Trial with the xilinx
> FPGA tools for instance which support both approach. 

They may not have a good intermediate representation to find
them their macros? Or is it that they don't find the parts of
their macros spreaded over the designers behavioural modules?
But for Xilinx it may be also due to the different possible
use of their cells, logic vs. ram.

> And on the philosophical point of view I agree with you but on the
> practical point of view, do you really want to redesign basics blocs
> such RAM, filebuffer ??? Do you really want to redesign the whole
> library ? 

God beware! No, that wasn't the point. The point is to extract
basic macro functions out of the behavioural design to save
both space and layout cost (and delay time of course). And to
give backannotation hints to the designer which specialities of
his design prevent from using them. This would give more freedom
to the designers.

But on the other hand this may also be an indication that a lot
of the design already gets lost when you write it down in VHDL,
i.e. translation from mind to VHDL to compiler to gates/cells.
The designer knows what he wants, the VHDL implementation does
not because you can't implement the different possibilities of
views and dependencies. The compiler only extracts parts from the
implementation and converts or optimizes it for real gates/cells.

Most of the time I can imagine more than one way to implement
a design. BUT there is no tool on the market which makes it
possible to describe these ways alltogether easily and checks
for plausibility between them and the final behaviour seen
from outside of the unit (expected behaviour). Something like
a multi-parallel path design description.

Sometimes it's a pity that one is forced to an implementation
already in the early stages of a design.

> And after all, your design is finally based on so-called  'standard cell'. Is
> this so far from the 74xx approach, ? ;)

Ha, ha, ha - that one really got to me! Oh, and they are all based
on transistors. Welcome back to the old days in new clothes. ;-)

JG

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