Re: [myhdl-list] Integrating MyHDL into a more "traditional" design work flow

[Angel E. <ang...@gm...>]

Hi again Chris,

thank you for your replies. See my comments below.

On Tue, Oct 9, 2012 at 8:07 PM, Christopher Felton
<chr...@gm...> wrote:
> On 10/4/2012 4:02 PM, Angel Ezquerra wrote:
>> Chris,
>>
>> Sorry it took me so long to get back to you. I've been really busy recently.
>>
>> First of all, thanks _a lot_ for taking the time to go through my concerns
>> so carefully. I really appreciate it.
>>
>> See some replies below...
>>
>> On Fri, Sep 28, 2012 at 3:12 PM, Christopher Felton <chr...@gm...>
>> wrote:
>>> On 9/28/2012 7:31 AM, Angel Ezquerra wrote:
>>>> On Fri, Sep 28, 2012 at 2:16 PM, Christopher Felton
[...]
>>> Why would a large VHDL be an issue? I don't think it
>>> is. If you really need the hierarchy there are options,
>>> just takes a little more work.
>>
>> Could you detail what you mean by it "just takes a little more work"?
>
> Just that, you will need to convert each piece separately
> and merge them together.  Most of this can be automated
> (I believe).
>
> I had a rare case where I wanted to preserve hierarchy
> this is how I did it:
>
>         toVerilog(submodule, sigs, params)
>         # move to a new filename with params in the name

Sorry, maybe I'm a bit thick but I don't know what you mean by "move
to a new filename with params in the name"

>         submodule.verilog_instance = 'SUB1'
>         toVerilog(module, sigs, params)
>
> Where "module" instantiates 'submodule".  This will stub
> out "submodule" in module.  It is a little more work
> but not bad.  I had to add extra to the submodule
>
>         def submodule(...):
>            if hasattr(submodule, "verilog_instance"):
>                out1.driven = 'wire'
>                out2.driven = 'wire'
>                # etc

I don't know what "verilog_instance" does. I guess there is an
equivalent "vhdl_instance"? I looked for it on google but I did not
get any useful results. I also don't know why you need to set the
"driven" attribute.

I feel as if these questions are very basic and I should know them...
Is there some documentation on these features that I missed?

> If you had a design that is more complicated you could
> automate the first part.  You still would need to add
> the output definition in the module (submodule) being
> stubbed.  The nice thing about the above example, every
> thing will be wired up automatically.
>
> Note: I think Jan indicated the verilog_instance might
> need some work, use with caution.  I have used it
> without issue.

As I said I don't really know what these do so I don't think I could
use them, even cautiously :-> It still seems a bit too complicated for
my taste though.

Anyway, since this process seems easy to automate (I can't really
tell, since I don't really understand it), the obvious question is why
not make MyHDL itself automate it for us? That should put to rest the
question of generating hierarchical VHDL or Verilog code which seems
to crop up regularly on this list and on other online discussions
about MyHDL!


>> My ideal workflow would be to be able to add a decorator to some function
>> which would mark a file as describing an entity, which would group all
>> processes defined within it as part of that entity, and which would put
>> that entity on its own file.
>>
>> I think a "large" VHDL is an issue mostly because it would make it much
>> harder to debug using a regular VHDL simulator (e.g. modelsim) and adding
>> debug signals to a chipscope (Xilinx' in FPGA logic analyzer).
>
> This hasn't been my experience, I have an all MyHDL FPGA
> design I use to interface to our mixed-signal ICs (ICs
> also utilize MyHDL).  I use SignalTap frequently and it
> doesn't cause me much heart-ache.

Glad to know that. Maybe my intuition is wrong then... Still I
anticipate that you would still need to look into the generated VHDL
from time to time, possibly using (the terrible) ISE editor. In there
you'd see a single entity on the hierarchy view. I'd definitely prefer
to get a proper hierarchy in there instead.

>> Additionally, some synthesizers (XST for example) give you options to
>> control how optimizations and routing are handling across entity
>> boundaries. I am by no means an expert of this though. This is just advice
>> I've gotten from more experienced designers than I am.
>
> Not sure what the point is or the question you might
> be asking?  If you describe your design with a lot of
> hierarchy it is often beneficial, from a resource /
> performance point of view, to optimize across boundaries.
> But this breaks the structure and tools like ChipScope
> and SignalTap might be more difficult to work with
> (not much different than MyHDL flattening).
>
> An interesting case study would be to record the
> synthesis results between a hierarchical design,
> optimize across,and a MyHDL flattened design.

That could be interesting although given that Xilinx XST will
sometimes give you a different result when you implement the same code
twice I would not put that much faith on the comparison results...
Sometimes I feel that the Xilinx uses the position of the stars and
the phase of the moon to decide how to synthesize their FPGAs :-P

>> I just know that on a somewhat conservative development team it would be
>> way easier to add to a project a few files that have been automatically
>> generated via MyHDL than adding a single, big, flat file. I know that I
>> would face much more resistance with the single flat file than I would
>> otherwise. Given that I am not the most experienced FW developer in our
>> team it is uncertain that I'd be able to convince the most expert designers
>> that this is not a problem.
>>
>> This is probably a matter of perception, but I am quite sure that this
>> would be a big point against MyHDL.
>
> I think I might not be following you between "module"
> and "files".  From my perspective, if you had a new module
> that you needed to add, you could implement it in MyHDL
> and you would have /one/ new file to add to the design.
> Even if the module had many layers of hierarchy, and the
> one new file would be minimal impact to the existing flow.

Now I am not sure that I understand you. By module I mean a VHDL
entity and by file I mean, well, a file :-)

The issue I state is that adding a _single_, big, MyHDL generated VHDL
file to an existing VHDL project would be a problem. The problem is
not technical (or at least not mainly technical) but "social". I think
that when working on a project with multiple designers they would not
easily accept me adding a single file that implemented a significant
part of the design particularly if they knew that the file had been
automatically generated. They would ask me to "modularize" my
contribution. According to what you said above that is something that
can be done but it requires (unnecessary?) extra work with the current
version of MyHDL.

In my experience many FW designers are surprisingly risk averse and
not prone to try new design tools and approaches. That is an
unfortunate barrier to entry that MyHDL must go through.

If MyHDL let me group part of my MyHDL design in entities or packages,
which were saved into separate files when generating the VHDL or
Verilog code, this problem would be gone. IMHO this would make it much
easier ("socially") to introduce VHDL into an existing, VHDL or
Verilog based, project.

It may seem that I am blowing this issue out of proportion, but I know
the people I've worked with and I'm pretty sure these concerns are
real.

Cheers,

Angel