Re: [myhdl-list] MEP - keep hierarchy in conversion

[Jan D. <ja...@ja...>]

On 10/05/2013 12:07 AM, Angel Ezquerra wrote:

> That makes sense when you put it like that. That being said, do you
> know if your colleagues would consider the Xilinx tools (ISE and/or
> Vivado) "state of the art" in this regard?

Those colleagues have experience with a wide variety of targets
and tools, including lots of ASIC work and both Xilinx and Altera
tool sets.

> Do you have any blog post or some other material where you describe
> what you would consider "solid conservative synchronous design
> practices"? I'd be really interested in what you would have to say on
> that topic.

 From my web site you will find a number of blogs that I believe
clearly represent my line of thinking.

I have not written a blog about this specific topic. If I would,
I think I would present it as an application of sound principles:
separation of concerns (such as functional vs physical and timing),
minimization of dependencies, understand what your compilers
(synthesis and layout tools) can do and what tasks you can
leave to them.

This would lead to concrete methodology guidelines, e.g.
* keep HDL source target independent and plan for that
* don't use clock gating for functional behavior; use logic
instead (you have it anyway)
(clock gating for power management is fine and an increasingly
important requirement)
* register interfaces between blocks systematically (minimize
timing dependencies)

It's unlikely I will write such a blog though as this way
of thinking has become second nature to me, and "not interesting
enough" to blog about. A blog is lots of work and there
is a pile of more interesting and innovative topics.

Let me add that I co-founded a company, Easics, that has been
putting this type of methodology into practice since 1992. Easics
is a like a lean design factory that turns over succesful projects
back-to-back.

The interesting point is that occasionally we (at Easics) get the
opportunity to compare design methodologies, unlike most companies.
And the evidence points all in the same direction: this type of
methodology leads to *better* QoR and *much* smaller compilation
times.

Therefore, when someone says he "needs" floorplanning, and my
evidence says we don't, I'm not questioning his methodology in
vain. Time and time again, we have seen that basic methodology
choices, that are seldom talked about, cause major differences
in QoR and compilation time.

> Also, do you think that making it easy to split the generated code a
> into multiple files has real benefits other than floorplanning?

Yes - as I have reported I do that myself regularly.

Good reasons I can think of: code clarity (certainly), support
incremental synthesis (likely), easy extraction of reusable IP
in VHDL/Verilog format, enable floorplanning support (if you
need it).

I repeat that I support efforts for a clean way to support
hierarchical output from the convertor. Suggested lines of work:

* study top-level convertibility restrictions and how to
relax them if possible
* bring Oscar's changesets over to mercurial and align
with the MyHDL development, so that they can be reviewed
and discussed there (see Keerthan's changesets about
interfaces, I'm quite happy how that works)
* other creative ideas in line with the project's spirit,
which means Verilog is *not* the inspiration or the norm

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
     Python as a HDL: http://www.myhdl.org
     VHDL development, the modern way: http://www.sigasi.com
     World-class digital design: http://www.easics.com