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

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

<snip>
> The way I see it there are a few barriers that make it hard for us to
> use MyHDL. It is likely that some of these are moot (i.e. perhaps when
> we start using MyHDL I'll realize that they are not important), but
> for now they seem things that we should deal with:
>
> 1. The MyHDL code may need to interface with existing blocks,
> particularly with IP cores. This results in several problems:
>     - It would make it hard to run simulations on the "MyHDL world"
> since we do not have MyHDL models for the Xilinx IP cores.
>     - I got the impression that the MyHDL to VHDL "interface" is not
> that clean and that the process is manual (I have not looked much into
> this, so I may be wrong).

You would still use the VHDL environment interfacing
to IP cores for simulation would be the same.  In your
MyHDL "IP" development you would need to generate a
model (you can stub it out) or cosim.

> 2. We should come up with a way to automatically generate the VHDL
> from the MyHDL when we generate our programming file.

Yes, you can create a python script that drives
everything (Python world domination).

> 3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
> (at least on Windows).

Not possible with iSim, possible with Modelsim but it will
take some work.  There is other cosim VHDL interest.

> 4. For legacy reasons a lot of our code uses the IEEE.STD_LOGIC_ARITH
> and IEEE.STD_LOGIC_UNSIGNED packages, while MyHDL uses NUMERIC_STD
> (and rightly so). There may be issues mixing both sets of libraries.

I don't believe this is an issue, because VHDL is
strongly typed you have to do explicit conversion going
from one type to another.  It can be a pain but shouldn't
be a problem.  I have had this issue in the past where
all my VHDL used numeric_std and I had to add type
conversion at the interfaces to the legacy HDL.

> 5. There is no editor integration (not even with Sigasi).

?? What do you mean by editor integration.  MyHDL is
simply Python, pydev in Eclipse works with other Eclipse
packages.

> 6. I believe that the fact that the VHDL code that MyHDL generates is
> "flat" is a problem, because it makes it harder to introduce MyHDL
> little by little.
>     - This may be just my perception and turn out to be a non issue,
> but I think that if MyHDL generated regular structured code (e.g. if
> you could tell MyHDL "place all these processes on a single entity
> named foo") it would be much easier to start using MyHDL to create
> smaller modules that could be added to our regular VHDL project "as
> is".

I don't see this as an issue?  If you have an existing
HDL design, say the top level looks like this (pseudo code,
err myhdl).

    i1 = block_vhdl(...)
    i2 = block_vhdl(...)
    i3 = block_myhdl_vhdl(...)

The "i3" module is the "flat" myhdl converted to VHDL.
There are some limitations but not many and most are
manageable.  I don't think this should be a concern.

>
> There are probably other issues that I have not thought about, and
> maybe some of these are not a problem at all.
>
> I'd like to get your opinions and your advice on whether you think it
> makes sense to try to fit MyHDL into our workflow. Perhaps it does not
> make sense unless you use MyHDL from start to end, but I hope it is
> possible.
>
> Cheers,
>
> Angel
>