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

[David H. <da...@ad...>]

On Thu, Oct 3, 2013 at 12:37 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 10/03/2013 03:29 AM, David Holl wrote:
>
> > So to address this limitation, I'll add a keyword parameter to the
> > syntax called "enable" to permit a module to selectively enable or
> > disable the partitioning.  (A partition with enable=False will still
> > output the encompassed logic, but it will not put the logic into a
> > separate Verilog module.)
>
> I don't see how this addresses my concerns.
>

I'm sorry you cannot see that.  But the "enable" flag is in the code now.
 Thank you for the technical input.


The partitions that *you* define, with the name that *you* give,
> will still be present in the funcitional source code as the only
> alternative, whether enabled or not.
>

Someone that uses your functional code and wants a different partition,
> or already used the partition name in his own code, will
> have to go in and change your functional code.
>

Yes, that might be a very annoying IP block to work with if it hard coded a
partition name AND assigned fixed resource attributes.  By the same logic,
the abuse of the .verilog_code hacks may induce the same headaches.  I
cannot resist: Your argument reminds me of Edison's pro-DC / anti-AC
campaign where he claimed AC could kill animals --- when DC is just as
capable:
http://en.wikipedia.org/wiki/War_of_Currents#Edison.27s_publicity_campaign
(In short, AC and DC both have their uses.)

However, even if you have the misfortune of dealing with such a rogue IP
block, your hope is not lost because *if* you are using partitions, your
own higher level partitions always get first naming rights on partitions
before nested partition names are assigned.  And if you really are forced
to edit someone else's poorly written code, what's so hard about setting
enabled=False on their offending assignments?  I'd have to apply a similar
fix if a rogue block were abusing .verilog_code as well.

Right now in hierarchical design flows, the names come from the module &
instance names already defined in the code (Verilog, VHDL...), so if you're
reusing someone else's IP block, you're already pulling in *their* names
into *your* hierarchy.  But we do not care what names an IP block might use
for its *internal* instances/modules.  (concept of encapsulation)  And *if*
there were some accidental naming conflict, this is precisely why I
give precedence to higher level names such as the partitions you might
assign in your top-level, so that final output name assignment is always
under your control.


Now, on this recurring theme of ASIC's...

You cannot say that the mega-chip-ASIC corporations (Intel...) do not do
any floor planning either.  This happens very early in the design process,
especially when dealing with the expensive silicon real estate.  A company
must always ask: How much extra silicon will it take to implement this
major feature?  What will the silicon cost for the desired process?  Can we
charge enough so that we're profitable?

The smart players do not permit themselves to be at the sole mercy of some
auto-layout logic.  (But then again, they also do not let their internal
IP-authors run unchecked and assigning arbitrary layout-impacting
attributes without some significant discussion, or ear twisting if
necessary.)  Any practical implementation will utilize a blend of tools to
achieve their goal.

Here are a couple articles for your consideration:
http://electronicdesign.com/products/fundamentals-floor-planning-complex-soc
http://en.wikipedia.org/wiki/Floorplan_(microelectronics)

Right now, I see the lack of easy access to _any_ partitioning or attribute
assignment [such as Verilog (* *) ] a major deficiency in MyHDL, which if
addressed.



Someone that uses your functional code and wants a different partition,
> or already used the partition name in his own code, will
> have to go in and change your functional code.
>

This is already addressed.  Your higher-level names take precedence and
will not be renamed due to conflicts with sub-partitions.  However, if
*you* assign conflicting names at the same level in *your* hierarchy, those
names will be renamed (suffixed #), but this is in your control since it is
*your* design.


The fundamental problem remains: this type of information should
> not be in the design source code. It *couples* concerns that
> should be separate. Any partitioning/physical/placement/constraint
> definitions should not go in functional code.
>

Sure, then don't use attributes on the partitions; they're not required.
 However, keeping the partition names at least permits an engineer to
assign the required contraints through external means.

There are pro's and con's to keeping attributes in-the-code vs
outside-the-code.  But I leave that to the design engineer and chip
architects who are on the hook for product delivery.

If an engineer decides to use top-level partitions *with* in-design
attributes to assist high-level silicon resource management, then that is
their choice.  A good tool should not limit an engineer's options (within
reason).   (Yeah, .verilog_code offers a lot of flexibility...  perhaps too
much IMHO?  Either way, I do not enjoy the prospect of hand-coding
.verilog_code="""...""" blocks, and I was pretty excited when the
partitioned-output code was able to auto-assign module i/o ports for me.)


In the glamorous ASIC industry, the big-boys already have their own highly
specialized internal tools that most of us only dream of.  I had a lot of
fun interning with an Intel architecture group working on cryptography and
compression IP cores.  Yes, they use floor planning, but their tools are
specialized.  Don't take my word for it.  I was only an intern, and that
was a decade ago.  But even 10 years ago, they already had tools that
auto-generated RTL simultaneously with cycle-accurate C modules for logic
testing prior to first tape-out.

I had a lot of fun working with the folks on this processor:  IXP2850
http://int.xscale-freak.com/XSDoc/IXP2xxx/27853715.pdf

Per, I look forward to hearing from any real implementation engineers with
current experience.  I've been out of the Si industry too long.  :)

I dislike soapboxing and happily relinquish the floor, for the moment.
http://en.wikipedia.org/wiki/Soapbox


I'm fine if this is never accepted into mainline MyHDL.  However, if that
is the case, I'd prefer it be clear that it is not due to any technical
limitation.  A short answer of "Jan says no." is acceptable, and sends the
appropriate message.  But I do not appreciate the opinionated atmosphere of
FUD.  http://en.wikipedia.org/wiki/Fear,_uncertainty_and_doubt

Would anyone else have any *technical* inputs on this particular
implementation for enabling hierarchical output?  I actually thought Oscar
Diaz's solution in MEP 110 was pretty elegant, except for the top-level
convertibility requirement.

- David

. o O ( Might as well be debating Emacs vs vi... )