myhdl-list — Mailing list for discussions on MyHDL

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

[Christopher F. <chr...@gm...>]

On 10/3/2013 3:40 PM, Per Karlsson wrote:
> I considered censoring that last remark, since I suspected it might agitate
> you. I'm sorry I didn't.
> That said, it seems to me he was not cowardly but wise to stay anonymous.
>

It does suck when folks reduce a technical argument to
"if you don't get it you are dumb".  If it is that simple,
can't it be explained simply?  Instead of calling someone
unintelligent just state the simple argument?

It is easier to say outlandish things or be disrespectful
if you don't have to own up to the words.

.chris

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

[Per K. <bas...@gm...>]

Dear Sirs, this is going to be my last post in this topic and I'll try to
be as brief as I can.

Hardware implementation is difficult and tedious shit, and the back-end
engineer often knows a lot less about the block he is implementing than he
would like.

I--contrary to Jan--have always found it a good idea to keep as much of the
information about a block as possible in the source code. The source code
is never out-dated, and you always know where it is. It can never be out of
sync with itself.
That is why I--for instance--generate firmware header files, the register
documentation and programmers guide by parsing the HDL source code.

Now, the functional partitioning of a block is one thing, and the layout
partitioning is another. Davids solution gives the block designer a neat
way to partition the code the way the block design works best (without
having to limit himself to flat signals for the interfaces), and at the
same time lets him provide the implementation engineer with reasonable
building blocks as a starting point for the back-end implementation. How is
that not wonderful?

Exactly how this is achieved can be discussed, but I find the basic premise
difficult to argue against.

Cheers
Per


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

> Let me do one more attempt to state clearly what I am
> actually saying.
>
> I do question the usefulness of floorplanning for FPGAs.
> "Questioning" implies that I am not sure, which is why
> I am asking for evidence.
>
> This is *unrelated* to the issue of hierarchical output,
> expect that I am not sure floorplanning is the best
> argument.
>
> I do *not* question the usefulness of hierarchical
> converted output from MyHDL.
>
> I have nothing against the *concept* of fine-grained
> hierarchy control of the converted output.
>
> I am convinced however that partitioning/physical/placement/
> constraint control has no place in functional source
> code. The technical argument is separation of concerns
> as much as possible - and indeed, I think that should be
> obvious to anyone with complexity management expertise.
>
> I also think the solution should be obvious and vastly
> superior - after all, you will need to write a Xilinx
> or Altera partitioning configuration script *anyway*.
>
> If you do need a nontechnical argument, it is: "Jan says no
> because he finds it stupid and ugly".
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

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

[Per K. <bas...@gm...>]

I considered censoring that last remark, since I suspected it might agitate
you. I'm sorry I didn't.
That said, it seems to me he was not cowardly but wise to stay anonymous.


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

> On 10/03/2013 09:19 PM, Per Karlsson wrote:
>
> > If you don't understand why floorplanning is required for a complex
> > block, you are not qualified to discuss the matter."
>
> What? I ask for evidence for a specific, rational issue,
> and you dare to give me some vague derogatory nonsense
> from an anonymous coward?
>
> Look, with MyHDL I am not asking for money nor "thank you".
> But I do want respect, and I am not getting it.
>
> So *I* will stop this discussion with you right now. And
> I hope you have the decency to get out of here.
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

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

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

On 10/03/2013 09:19 PM, Per Karlsson wrote:

> If you don't understand why floorplanning is required for a complex
> block, you are not qualified to discuss the matter."

What? I ask for evidence for a specific, rational issue,
and you dare to give me some vague derogatory nonsense
from an anonymous coward?

Look, with MyHDL I am not asking for money nor "thank you".
But I do want respect, and I am not getting it.

So *I* will stop this discussion with you right now. And
I hope you have the decency to get out of here.

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

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

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

On 10/03/2013 09:48 PM, David Holl wrote:
:ja...@ja...>> wrote:
>
> <snip>  I also think the solution should be obvious and vastly
> superior - after all, you will need to write a Xilinx or Altera
> partitioning configuration script *anyway*.
>
>
> Yep.
>
> Since this HDL is already in Python, and Python is pretty darn
> flexible...  Could Python fill that higher role, and perhaps be
> capable of doing such end-to-end design control?  (ie, in a
> collection of .py files, some files are just for describing the logic
> design, while others manage the resource assignment but assisted with
> a few [as needed] hierarchical names from the logic design?)

A reasonable suggestion. However, if there is already
a standard, even de facto (I don't know) then reusing it
might be considered. (I seemed to understand that Xilinx
uses an xml input format). Alternatively, generating
all the required files from MyHDL *.py + physical conf *.py
depending on the target might be quite attractive too.

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

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

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

On 10/03/2013 09:25 PM, Christopher Felton wrote:

> This is how our ASICs have been developed as well, with a
> analog top-level view where the digital macros are stitched
> in with the various components.  Floorplanning is definitely
> part of the project, just not part of the HDL flow.

That is right. I am also doing such chips currently.

So I need to make a correction: when I meant "million-gate
ASICs" without floorplanning I meant the pure digital
synthesizable HDL part. (For a long time in my career, that
was basically the type of ASICs I was doing (no mixed-signal).)

Much like fully synthesizable FPGAs today, hence my
scepticism.

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

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

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

On Thu, Oct 3, 2013 at 3:36 PM, Christopher Felton <chr...@gm...>
 wrote:

> <snip>
> The question is the granularity of control needed
> at the functional HDL level. Not if floorplanning
> is useful for complex block.
>
> Or, without fine control at the functional HDL level
> is floorplanning rendered useless, I think not.
>

Yep.  I went waaay off topic.  :)


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

> <snip>  I also think the solution should be obvious and vastly
> superior - after all, you will need to write a Xilinx
> or Altera partitioning configuration script *anyway*.
>

Yep.

Since this HDL is already in Python, and Python is pretty darn flexible...
 Could Python fill that higher role, and perhaps be capable of doing such
end-to-end design control?  (ie, in a collection of .py files, some files
are just for describing the logic design, while others manage the resource
assignment but assisted with a few [as needed] hierarchical names from the
logic design?)


If you do need a nontechnical argument, it is: "Jan says no
> because he finds it stupid and ugly".
>

hahaha!  Awesome  :)  Thanks for the chuckle.

- David

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

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

Let me do one more attempt to state clearly what I am
actually saying.

I do question the usefulness of floorplanning for FPGAs.
"Questioning" implies that I am not sure, which is why
I am asking for evidence.

This is *unrelated* to the issue of hierarchical output,
expect that I am not sure floorplanning is the best
argument.

I do *not* question the usefulness of hierarchical
converted output from MyHDL.

I have nothing against the *concept* of fine-grained
hierarchy control of the converted output.

I am convinced however that partitioning/physical/placement/
constraint control has no place in functional source
code. The technical argument is separation of concerns
as much as possible - and indeed, I think that should be
obvious to anyone with complexity management expertise.

I also think the solution should be obvious and vastly
superior - after all, you will need to write a Xilinx
or Altera partitioning configuration script *anyway*.

If you do need a nontechnical argument, it is: "Jan says no
because he finds it stupid and ugly".

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

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

[Christopher F. <chr...@gm...>]

On 10/3/2013 2:19 PM, Per Karlsson wrote:
> Here is the answer from an experienced (and currently active) back-end
> engineer who has worked at a couple of the major ASIC houses, but who
> wishes to keep his name out of internet flame wars:
>

Flame wars?  Is this not good'ol technical debate?

> "Support for un-floorplanned netlists is actually fairly good in some
> layout tools. With a simple block you can get a decent initial result. If
> the block is simple enough it is actually possible that the block
> converges! So in that sense you can say that in special cases you don't
> need manual floor planning.
>
> If you don't understand why floorplanning is required for a complex block,
> you are not qualified to discuss the matter."
>

The question is the granularity of control needed
at the functional HDL level. Not if floorplanning
is useful for complex block.

Or, without fine control at the functional HDL level
is floorplanning rendered useless, I think not.

Regards,
Chris

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

[Christopher F. <chr...@gm...>]

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

I don't think anyone is saying floorplanning is not
used, but rather debating different flows.  If you look
at one of Jan's ASIC's [1] in which the digital macro
was implemented with MyHDL, you can see obvious floor
planning.  Planning of the IO, SRAM, analog, and digital
(similar to the articles you referenced).

This is how our ASICs have been developed as well, with a
analog top-level view where the digital macros are stitched
in with the various components.  Floorplanning is definitely
part of the project, just not part of the HDL flow.

And if you look at your first reference, the digital macro
in the design - no floorplanning.  Only floorplanning from
the top-level main components (SRAM, XPM, MCU, and IO) [2]
See that lower right hand blob, that is a bunch of their
digital stuff, auto-routed.  And then a second blog used to
connect all the various pieces - auto-routed.

Regards,
Chris

[1] http://www.jandecaluwe.com/hdldesign/digmac.html
[2] 
http://electronicdesign.com/site-files/electronicdesign.com/files/archive/electronicdesign.com/content/content/73618/73618_fig02.jpg

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

[Per K. <bas...@gm...>]

Here is the answer from an experienced (and currently active) back-end
engineer who has worked at a couple of the major ASIC houses, but who
wishes to keep his name out of internet flame wars:

"Support for un-floorplanned netlists is actually fairly good in some
layout tools. With a simple block you can get a decent initial result. If
the block is simple enough it is actually possible that the block
converges! So in that sense you can say that in special cases you don't
need manual floor planning.

If you don't understand why floorplanning is required for a complex block,
you are not qualified to discuss the matter."



On Thu, Oct 3, 2013 at 7:07 PM, Per Karlsson <bas...@gm...>wrote:

> I'll see if I can get a real implementation engineer to weigh in.
>
>
> On Thu, Oct 3, 2013 at 6:57 PM, Jan Decaluwe <ja...@ja...> wrote:
>
>> On 10/02/2013 08:46 AM, Per Karlsson wrote:
>>
>> > Saying "back-end tools need to improve", is like putting off getting
>> > a bike because soon we are all gonna have flying cars. Back end tools
>> > have needed to improve for decades. (And they have, but designs have
>> > grown faster.)
>>
>> You make it sound like it is already proven and clear to anyone
>> that floorplanning is essential. That is exactly what I am
>> questioning here. Absent credible evidence, it is equally
>> possible that you *think* it is essential because you never
>> tried the alternative.
>>
>> Sorry to sound sceptical, but I have seen that so many times
>> in my HDL career. The scientific approach, based on rational
>> argument and experiments seems to be the exception not the
>> rule.
>>
>> --
>> 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
>>
>>
>> ------------------------------------------------------------------------------
>> October Webinars: Code for Performance
>> Free Intel webinars can help you accelerate application performance.
>> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
>> from
>> the latest Intel processors and coprocessors. See abstracts and register >
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
>> _______________________________________________
>> myhdl-list mailing list
>> myh...@li...
>> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>>
>
>

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

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

[Per K. <bas...@gm...>]

I'll see if I can get a real implementation engineer to weigh in.


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

> On 10/02/2013 08:46 AM, Per Karlsson wrote:
>
> > Saying "back-end tools need to improve", is like putting off getting
> > a bike because soon we are all gonna have flying cars. Back end tools
> > have needed to improve for decades. (And they have, but designs have
> > grown faster.)
>
> You make it sound like it is already proven and clear to anyone
> that floorplanning is essential. That is exactly what I am
> questioning here. Absent credible evidence, it is equally
> possible that you *think* it is essential because you never
> tried the alternative.
>
> Sorry to sound sceptical, but I have seen that so many times
> in my HDL career. The scientific approach, based on rational
> argument and experiments seems to be the exception not the
> rule.
>
> --
> 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
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>

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

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

On 10/02/2013 08:46 AM, Per Karlsson wrote:

> Saying "back-end tools need to improve", is like putting off getting
> a bike because soon we are all gonna have flying cars. Back end tools
> have needed to improve for decades. (And they have, but designs have
> grown faster.)

You make it sound like it is already proven and clear to anyone
that floorplanning is essential. That is exactly what I am
questioning here. Absent credible evidence, it is equally
possible that you *think* it is essential because you never
tried the alternative.

Sorry to sound sceptical, but I have seen that so many times
in my HDL career. The scientific approach, based on rational
argument and experiments seems to be the exception not the
rule.

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

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

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

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.

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.

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.

I find that obvious.

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

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

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

On 10/02/2013 10:11 AM, Per Karlsson wrote:
> Enforcing "top-level convertibility" at all levels of the design
> would be a huge step backwards for MyHDL. I have not looked into
> MEP107, it may take away some of that sting, but that will not help a
> pre-MEP107 design (such as mine). Not even my top module is
> "top-level convertible", I have a script to wrap it for conversion.

That sounds messy.

I don't understand what is so hard about top-level convertiblity.
I think it is good practive to enforce it at all levels where
you want entry points in the hierarchy.

Of course, if there are good technical reasons we can consider
to lift some restrictions on top-level convertibility. Note
that some constraints were caused by the limitations of the
target HDLs at a given time. In the mean time, it is well
possible that some of those restrictions have become
obsolete.


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

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

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

On 10/02/2013 08:46 AM, Per Karlsson wrote:
> Floorplanning is essential.

I have asked for credible evidence, not slogans. So far I haven't
heard anything that supports this claim.

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

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

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

On 10/02/2013 12:44 AM, Angel Ezquerra wrote:
> I cannot comment on the ASIC side, but on the FPGA side it is a common
> recommendation to properly organize your code into entities to improve
> the map and/or plan and route results.

I have briefly checked the Xilinx docs and I haven't found
such a recommendation.

In a document about the hierachical design flow, it is described as an
optional flow, with advantages and disadvantages.

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

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

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

Hi Angel,

On Tue, Oct 1, 2013 at 6:44 PM, Angel Ezquerra <ang...@gm...>wrote:

> <snip>
> I also think that being able to control how the generated code is
> split into files and entities would be nice, particularly if you had
> to debug some generation issue. It might also help when adding
> chipscope probes.
>
> <snip> If multiple files were generated,
> only some of those files would usually change, making it easier to
> tell what changed in a given version.
>
> So I think that there are a few sensible reasons for wanting the
> ability to split the generated design into files and entities.
>

Great reasons!

And it turned out to be an easy addition.

To enable separate files, set
    toVerilog.separate_files=True
before calling toVerilog(...)

I just committed the change to https://bitbucket.org/dholl/myhdl-partition
for everyone's feedback.  (under the branch called "partition")


And yes, I also track changes in my single Verilog output file, to an
extent.  :)  In my unit tests, I compare a hash of the Veriog output, but
computed with blank lines removed.  This way, I'm alerted to any unexpected
changes such as from my design changes or when I switch MyHDL versions.


Additional idea:  (I'm suspending any feature creep concerns for the
moment.  This is called "brainstorming".)

What else I think will be very handy for version control is keeping a
predictable output ordering of generators and signals.  Ever noticed how
your output may sometimes be re-ordered, such as when exporting your design
on different computers, but even having the same MyHDL version?  This has
been bugging me, and I have an idea which will fit nicely in this output
code.  I'll get back to you when it's ready.  (The idea: Preserve the order
of signals and generators, according to the order in which you originally
declared them in your code ---- not the order that MyHDL happens to
traverse your netlist.  If there's no "technical" reason why this is bad,
then I'm giving it a try.)

Cheers,
>
> Angel


Thank you for the insight!

- David

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

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

On Wed, Oct 2, 2013 at 2:51 PM, Jan Decaluwe <ja...@ja...> wrote:

> On 10/02/2013 08:12 PM, David Holl wrote:
>
> > And on the topic: in contrast to Jan's clever use of user-supplied
> > code to satiate his needs of hierarchy generation, this partitioning
> > code does not require the IMHO more significant changes that are
> > required to pull off his hierarchy scheme.
> >
> > (What takes more effort?  Injecting an "@partition(...)" / "with
> > partition(...):"?  Or declaring func.verilog_code = """something or
> > other goes here""" with the requisite top-module convertibility?  The
> > ...verilog_code="""...""" syntax is also "a significant,
> > non-functional change to the source code" which also provide ample
> > room for abuse by IP blocks.)
>
> The user-defined code option likely takes more effort. And it
> is indeed also a non-functional code change.
>
> The big difference is this: it is trivial to implement it
> as an optimization *add-on* while keeping the general case intact.
> Just define the func.verilog_code under parameter control.
> If not defined, the general case applies. And of course, you
> can define it differently for different parameters.
>

Ah perfect.  A solid technical point on a limitation of the partition
syntax.

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.)  So a full example usage would be:

def my_special_gizmo(parameters, inputs, outputs, etc...):
# import stuff...
 # ... logic stuff ...

 if some_gizmo_parameter==some_value:
 activate_partition=True
 else:
 activate_partition=False

with partition("some_name", enable=activate_partition) as this_part:
 # Optionally activate any (* *) Verilog as needed by user parameters:
 if some_other_parameter==some_value:
  this_part.attr_add('KEEP_IT_CLEAN', 'TRUE')

 # Or to be completely general, let the caller hand us
 # a dict (or OrderedDict) of key=value pairs:
 for other_attrib in input_parameter_dict_of_attributes:
  this_part.attr_add(other_attrib, input_parameter_dict_of_attributes[
other_attrib])

 # signals... generators... etc... to go inside this partition

# signals... generators... etc... to go outside the partition.


By adding the enable= keyword parameter, this updated syntax may now be
completely controlled via module parameters.  (For the record, the (* *)
attribute assignments have always been optional and under module control.)

So that according to the input parameters to the encompassing module, the
module may set enable=False to make the partition a no-op.  This is in
addition to being able to change the name (a string input) or other
arbitrary Verilog [or VHDL] attributes.  (VHDL attributes and VHDL output
partitioning are not-yet-implemented.)

So far as implemented, partitions contain no vendor or process-specific
features, and are thus generalized for whatever


The vision behind this is the following. Start with the
> general case, e.g. a description of a specific memory
> structure. If required, add an optimization for a
> specific target as an *add-on*, e.g. an implementation
> for xilinx, altera ... but keep the general case e.g.
> for an asic.
>
> Now you have target-independent code with target-specific
> optimizations included all in the same code base.


Perfect.  I agree with the vision, and the need to stay general while
permitting specifics as needed.

So now with the "enable=" parameter, the "with partition(...):" syntax is
just as flexible, and it scales no uglier than the corresponding
.verilog_code would be having similar dependencies on module parameters.  :)

I will apply this update to the repo at
https://bitbucket.org/dholl/myhdl-partition


On Wed, Oct 2, 2013 at 3:10 PM, Jan Decaluwe <ja...@ja...> wrote:

> <snip>
> Moreover:
>
> * user-defined code can be used for *any* optimization, not just
> partitioning for floorplanning or clarity
> * user-defined code is *localized*
> * the parameter checks make it explicit that it is a special
> case or an optimization.
>
>
*  Yep, just like defining a partition is also not restricted to hierarchy
enforcement.  Enabling easy access to the *selective placement*
of attributes to groups of logic opens up a wide variety of optimization
flags/knobs/etc, such as:
 http://www.altera.com/literature/hb/qts/qts_qii51008.pdf
 http://www.xilinx.com/support/documentation/sw_manuals/xilinx14_6/cgd.pdf
 (attribute assignment as either inline (* *) annotations, or via some
external file such as a .ucf...)
(Hey, FPGA's are not the all-encompassing solution to the world's logic
woes, but neither are ASIC's. -- as negotiated by your budget, engineering
time, field-flexibility, and performance requirements)

*  Yep, a "with partition(...):" for "@partition(...)" block is also very
localized.  It is very clear what logic/code is enclosed with either syntax
--- or at least as clear as Python's indentation levels and decorators.

*  And controlling partition declaration via module parameters _can_
clarify the intent behind defining a partition in the first place.
 (However as with any tool including .verilog_code, it may also be used to
obfuscate...  But that's when the pragmatic manager just twists some ears
to keep folks in line...)

Re: [myhdl-list] fixed-point thoughts : part two

[Christopher F. <chr...@gm...>]

<snip>
>
> This conversation reviewed fixed-point operations, how the
> proposed /fixbv/ handles unalignment, and bounds.  Finally, the
> *resize* function was introduced.  The next part will cover the
> implementation details of the *resize* function and implications.
>

Just a note that I haven't forgotten about this, I
will be posting part three relatively soon.  Unexpectedly
been swapped at work.

Spoiler - there is something fishy about the proposed
/resize/ function interface.  Is it reasonable and/or possible?

Regards,
Chris

Re: [myhdl-list] MEP 107 Initial support

[Keerthan jai.c <jck...@gm...>]

toVerilog returns whatever would be returned if you called the function
directly, usually a tuple of generators. So, someone could hypothetically
have been passing the return value of toVerilog to a myhdl.Simulation
object. Returning the portmap alongside the previous return value would
break their code.

toVerilog.portmap seems reasonable.


On Wed, Oct 2, 2013 at 3:33 PM, Christopher Felton
<chr...@gm...>wrote:

> <snip>
> >
> > This seems like a reasonable approach, with a port
> > definition list.  But should it be an attribute or a
> > return of the toV* functions?
>
> Nevermind, it looks like toV* already has a return
> that I forgot/never new.  I am not sure what/how the
> return is used, it appears to return the top-level that
> is passed.  Maybe the return can be:
>
>      return h.top,portmap
>
> I don't know if this breaks any existing code.
>
> Regards,
> Chris
>
>
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>



-- 
have a nice day
-jck

Re: [myhdl-list] MEP 107 Initial support

[Christopher F. <chr...@gm...>]

<snip>
>
> This seems like a reasonable approach, with a port
> definition list.  But should it be an attribute or a
> return of the toV* functions?

Nevermind, it looks like toV* already has a return
that I forgot/never new.  I am not sure what/how the
return is used, it appears to return the top-level that
is passed.  Maybe the return can be:

     return h.top,portmap

I don't know if this breaks any existing code.

Regards,
Chris

Re: [myhdl-list] MEP 107 Initial support

[Christopher F. <chr...@gm...>]

On 10/2/2013 1:16 PM, Keerthan jai.c wrote:
> Name conversion is pretty straight forward (obj.attr -> obj_attr, unless
> obj_attr already exists as a port). Users who don't like this can simply
> not use the feature. I don't think this feature should be disabled. I don't
> think its unreasonable to expect users of advanced features to be aware of
> some of the implementation details.
>
> Making the intf dict available to users as an attribute in the conversion
> object will greatly simplify cosimulations, without resorting to hacks to
> prevent unnecessary repetition.
>

I do agree for cosimulation this would be a needed
feature.  You don't want to force a user to write
a wrapper for each module they might want to test
individually.

In my mind, the main use case is testing embedded
modules in a larger design and not as much for the
top-level simplification (where the user needs to
know the expansion rules and exceptions).  I was
stuck on the second and not considering the first :(

This seems like a reasonable approach, with a port
definition list.  But should it be an attribute or a
return of the toV* functions?  If it is an attribute
I would suggest a different / more verbose name, like
/portmap/ or /interfaces/.

Actually, in general this might be a nice feature to
simplify simulations setup.  You do not need to type
out the port mapping twice :)


Regards,
Chris

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

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

On 10/02/2013 08:51 PM, Jan Decaluwe wrote:
> On 10/02/2013 08:12 PM, David Holl wrote:
>
>> And on the topic: in contrast to Jan's clever use of user-supplied
>> code to satiate his needs of hierarchy generation, this partitioning
>> code does not require the IMHO more significant changes that are
>> required to pull off his hierarchy scheme.
>>
>> (What takes more effort?  Injecting an "@partition(...)" / "with
>> partition(...):"?  Or declaring func.verilog_code = """something or
>> other goes here""" with the requisite top-module convertibility?  The
>> ...verilog_code="""...""" syntax is also "a significant,
>> non-functional change to the source code" which also provide ample
>> room for abuse by IP blocks.)
>
> The user-defined code option likely takes more effort. And it
> is indeed also a non-functional code change.
>
> The big difference is this: it is trivial to implement it
> as an optimization *add-on* while keeping the general case intact.
> Just define the func.verilog_code under parameter control.
> If not defined, the general case applies. And of course, you
> can define it differently for different parameters.

Moreover:

* user-defined code can be used for *any* optimization, not just
partitioning for floorplanning or clarity
* user-defined code is *localized*
* the parameter checks make it explicit that it is a special
case or an optimization.


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