Re: [f-cpu] "Tree"

[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.

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.
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.

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.

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.

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 !

So, my advise, is simply to 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 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.
Synopsys is quite expensive but some universities get 'educational
licenses', if there are student amongst you ...

Best Regards
Bruno






The


> hello,
>
> Juergen Goeritz wrote:
> > 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?
>
> this was my point #2.
>
> Even better : when the compilation script recognizes the synthesizer,
> it sets an environment variable. Then, during the file selection,
> it's a simple (ba)sh line which can select whether to use
> the "manual" version or not. ok ?
>
> > JG
> 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/