Re: Re: [f-cpu] "Tree"

["Yann Guidon [systeme]" <guidon@messiaen.lip6.fr>]

hello,

and thanks for your constructive comments.
i agree with them but unfortunately our situation
is not this of a normal company :-(

>De: Bruno Bougard <bougardb@imec.be>
>Hi All,
>
>I have some remarks about this 'Tree story':
>
>You give me the feeling that you apply some kind of bottom-up
>methodology. Building your design from the lowest level to the highest.
>Professional IC designers always work top-down, from spec to gate level,
>through different abstraction level.

This all started a long while ago.
On top of that, when people ask "how many gates does that count ?"
we have no means to answer. Simply because we have no synthesiser.
So we have to do it "manually".

The availability of VHDL tools under Linux marks a new milestone
in the F-CPU project, the next one will be to have a synthesiser : no more
naugthy hack and endless discussions... But this is going to be even more
difficult to get it.

>It seems that you are now busy with the RTL description, RTL is your
>'abstraction level'. Your concern about synthesis is a positive think,
>anyway, regarding my experience in this field, I can tell you that you
>go too far ! Fan out tree have nothing to do ar RTL level, that's for
>sure, that's the kind of think that should be abstracted here.
i can't help it, i'm paranoid ;-) but i slowly learn. Though my comments
may seem harsh to some, my position has progressively evolved
during the last 3 years. But i can't resist to make the discussion last :-)
And before i make a point of view mine, i have to verify and experience
and think about it... For example, it took a while before i really became
concerned about wire delays. Now it is one of my design concerns.

And do not worry : if a design criterium is meaningful and jsutified and coherent,
it will be adopted. But there is some entropy and ineria...

>Your concern about synthesis should be translated in your coding style,
>but not in your architecture. You have to write synthezable code, you
>have to 'think hardware', you should know what the synthesizer will do
>with your VHDL code, that's a matter of experience and if you don't have
>it, don't worry, experiment, that's the way to get it.

How could i get experience with the necessary tool ?

the only tool i have is a few VHDL compilers/simulators. We are seeking
synthesis tools for a long long time and if there was a simple and easy
answer, we would have known it.

>Not trusting completely the tools is also a good thing, but that doesn't
>mean that you should do its work manually. Moreover, you can always
>check the results of synthesis, not manually (even if some synthesis
>specialists are able to do it) but by netlist simulation. You replace
>your top entity by the netlist in your testbench and run the simulation
>with the same test patterns, then check if the outputs match with your
>RTL simulation outputs. That validate the synthesis regarding the
>functionality.
sure.

>Regarding timing, because your fan out tree problem is a timing problem.
>You have in a first time your synthesis reports.  Considering a 'wire
>load model' provided by the fab, the synthesizer analyses the fan out
>.... and tell you where are your timing bottleneck. If you detect
>something wrong, you can fix it in your RT code or, if it is too hidden,
>in your netlist. You can also use 'timing analyzer' that are independent
>from the synthesizer.
not only the timing is dependent from the tool, we also need fab parameters.
But we have none ! :-( furthermore we try to keep the design as
portable as possible so design styles will not suit for everything.
It's a really annoying problem !

>After P&R, when you have your back annotations, you can run again the
>annotated netlist simulations (for the functionality) and the timing
>analysis with the wire load model extracted from the lay out.
>
>That's it !

that works if you work for a "big" company (that can afford the licence
costs), with a specific design/application and workflow.

>So, my advise, is simply to do the things in the right order. I think
>you want to develop some kind of 'soft I do the things in the right order. I think
>you want to develop some kind of 'soft IP', the first step is to have a
>clean synthesable VHDL code. Think hardware, yes, but keep the
>abstraction level to RTL (not gate level).

I believe that our coding style will stabilize and get better and cleaner
once we find a suitable toolset. F-CPU is still a big sandbox and we're
not even much playing in it (with closed eyes).

>I agree with Kim about DC, I think it is the only 'professional'
>synthesizer for IC and it is quite reliable.  I think other more or less
>'exotic' tools  such Alliance focus more on FPGA and other toy devices.
AFAIK Alliance is not about FPGA. I don't remember having seen a FPGA
at ASIME, except for a reconfigurable router protocol project, but this
is exceptional... In fact, the FPGA domain is too fragmented for justifying
academic effort for a new tool. 

>Synopsys is quite expensive but some universities get 'educational
>licenses', if there are student amongst you ...

There are both students and professionals here but the point of F-CPU
is to allow anybody (with a linux box) to participate without constraint.
The synthesis problem is one of those we have to solve now.

>Best Regards
read you soon
>Bruno
YG
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu       in the body. http://f-cpu.seul.org/