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

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

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

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.

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.

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