Re: [f-cpu] "Tree"

[Juergen Goeritz <goeritz@oekomm.de>]

Hi,

me think the thought behind this is a completely good one.

I don't quite understand the uproar - in software programming
it's in wide use to use define switches for certain compilers,
operating systems and hardware and nobody would throw away a
part of the code just because some compiler could build/handle
it better by its own.

How about a simple switch that enables/disables that balancing?

JG

On Tue, 8 Jan 2002, nicO wrote:

> Yann Guidon a écrit :
> > 
> > hello,
> > 
> > nicO wrote:
> > > I have just read the package from Whygee and i have found an horror :
> > > specific entities for trees.
> > a binary balanced tree for buffering signals, yes.
> > 
> > > We don't need that.
> > it is indeed useful in certain circumstances.
> > 
> > > Synthetiser could recognise the loop and transforme
> > > it using a tree. It's automatic and balanced depending of the time used
> > > for the signal to come. I know that synopsys write a whipe paper on it.
> > > But it's old ! I have verified it.
> > 
> > 1) never trust a compiler/synthesiser, unles you can look at the output
> 
> You could always look at the output but try to analyse design with 100
> 000 gates ! You're "credo" became a little bit boring ! 99,9% of the
> time, synthetiser handel this very well (fanin, fanout, setup&hold
> timing...)!
> 
> This kind of coding uglify the code and make it so heavy ! This kind of
> "bibouilles" must be used AFTER the functionnal part are ready.
> 
> > 2) if you don't like it, you are not forced to use it :
> > don't compile it and the default architecture will be fine.
> 
> I'm afraid of code bloat.
> 
> > 3) Synopsys is not the only compiler on earth. We try to be as open
> > as possible to other EDA toolchains which may not contain smart
> > optimisations. If we design code only for Synopsys then it could be
> > useless with other tools. On top of that, it is not even monetarily
> > free... which explains why few people have ever accessed it.
> 
> No there is the one from Synplifigy but i beleive that is frontend are
> much better than those from Synopsys. Fanout problem are very basic
> problem !
> 
> > 4) if the compiler is smart enough to understand what the fanout
> > tree does, then it is able to do a better work. Otherwise, we have
> > a minimal failsafe. I am thinking of the "extreme case" if we have
> > to use Alliance as a last resort...
> 
> Yep, but it slow down compile time and synthetise time. You can't
> negligeagle this (20 min test are really annoying when we try to debug
> things!).
> 
> > 5) Evaluating the fanout's "cost" is necessary, otherwise our
> > "time budget" will not hold. When writing in RTL/HDL,
> > one does not necessarily "see" that an operation requires a large
> > fanout and this counts in the design budget. A "hidden" fanout
> > tree can slow the clock frequency down if it is not identified.
> > At least we can hint the synthesiser to balance the fanout before
> > or after a pipeline stage bareer.
> >
> 
> It so basic things! It's the base of the base of the work of compiler !
> You couldn't imagine how it sound "amateurs" to read that ! At least,
> write that Alliance couldn't do it properly !
>  
> > I know that "advanced" tools can do they work nicely but
> > we have almost no chance to use one. If i can skip the "pseudo-VHDL"
> > part of Alliance, a lot of thing will remain to do manually, such
> > as place/route through C files... It's probably the ugliest thing
> > ever, but Alliance has (only) 2 good sides : it works and it's free.
> > The rest is horrible but at least i can use Alliance.
> > Does anyone know another solution ?
> >
> 
> I prefer that. But start to code compact and clear and then ported thing
> for Alliance ! Not the opposite.
>  nicO
> 
> > > nicO
> > WHYGEE

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