Re: [f-cpu] "Tree"

[nicO <nicolas.boulay@ifrance.com>]

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/
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/