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

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

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
>>> <chr...@gm...> wrote:
>>>> On 9/28/2012 2:26 AM, Angel Ezquerra wrote:
>>>>> Hi,
>>>>>
>>>>> For the past couple of years I've been following the MyHDL project
>>>>> with a lot of interest. I've been subscribed to the mailing list and
>>>>> followed many of the interesting discussions in here. I've done a few
>>>>> of the examples on my spare time and I have read the documentation a
>>>>> couple of times.
>>>>>
>>>>> I really like the language. I find it very clear and simply way nicer
>>>>> than VHDL, which is what we use in our projects where I work. I have
>>>>> quite a lot of experience with Python, and at work I sometimes use it
>>>>> with some of its great scientific packages, such as simpy, scipy,
>>>>> matplotlib, etc, mainly for simulation purposes although most of my
>>>>> colleagues use Matlab for this.
>>>>>
>>>>> That being said, I have trouble coming up with a good way to integrate
>>>>> MyHDL into our existing workflows. I'm looking for advice here to see
>>>>> if there is a way that we could use MyHDL to improve our productivity.
>>>>>
>>>> <snip>
>>>>
>>>> My quick two cents is that you adopt the "IP" developed
>>>> with MyHDL approach. You start using the tool this way.
>>>> Your co-workers might never know you are using MyHDL.
>>>
>>> I'm not sure I understand what you mean. Do you mean that I would
>>> write my code on MyHDL, generate the VHDL and publish the generated
>>> VHDL as an "IP"?
>>
>> Essentially, but I don't mean that you have to create a
>> netlist and integrate. Simply take the generated VHDL
>> and use in the design.
>>
>>>
>>> If that is the case I fear that the fact that the automatically
>>> generated code is flat may be a problem. Depending on how big are the
>>> modules that I work on it the resulting VHDL could be pretty big,
>>> couldn't it? I guess my colleagues would find that odd :-P
>>
>> 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
        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

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.

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

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

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


>
>>>> As you indicate, there are some short comings to this
>>>> approach. One of the items you suggested is using MyHDL
>>>> for top-level simulation/verification (cosimulation with
>>>> VHDL). What VHDL simulator are you using?
>>>
>>> We currently use Modelsim and ISim, on Windows.
>>
>> Isim doesn't support PLI/VPI/DPI/VHPI you won't be able
>> to do cosim with Isim. There's other interest with mti
>> VHDL cosim, this has a decent change of being developed.
>> If that occurs, you can start developing a top-level
>> verification environment and blow the socks off your
>> co-workers! They will be utterly amazed.
>
> Again, would you mind detailing (or linking to some wiki or post) some
> examples of what could be achieved? I believe I can imagine what we could
> do, mostly mixing some cool python modules such as matplotlib with our test
> benches, but some concrete examples would be nice.
>
> Cheers,
>
> Angel
>