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

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

On 10/10/12 1:59 AM, Angel Ezquerra wrote:
> 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"

When converting a module it has a "default" filename.  In
this case I wanted a filename that represented the parameters
used to generated the module.

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

The "*_instance" isn't currently documented in the
manual.  It is something that has been discussed on
the mailing list.  This is a discussion of methods
that might be possible.  It is not intended to be
cookbook solution to a specific problem.

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

That is a haste judgement.  If you don't know what
it is how can you objectively comment that it is too
complicated?

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

The obvious question is why someone interested in a
feature doesn't propose a MEP and a patch?

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

No, you should get consistent results from synthesis,
you might get varying timing from PaR but functionally
it should not change.  I have not noticed resource
changes from synthesis run to synthesis run.

>
>>> 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
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
>