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

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

Hi again Chris,

more replies to some of your advice below.

On Fri, Sep 28, 2012 at 3:23 PM, Christopher Felton <chr...@gm...>
wrote:
> <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.

Some of the IP cores that we use are quite complex (e.g. turbo-decoders).
We could stub them out as you suggest but it makes using MyHDL a little
less convenient.

Also, most Xilinx' cores use std_logic_vector for their interfaces. Would
that be a problem? How do you convert the native MyHDL intbv types into the
std_logic_vector required by the external IP cores?

BTW, it would be super-nice if you could somehow import a regular VHDL file
into MyHDL (e.g. calling some MyHDL function with the VHDL filename) and
that made MyHDL automatically aware of the corresponding entity (i.e. its
name, interface, etc). I don't know how realistic is that though :-)

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

Probably not hard but it complicates things further compared to our
existing workflow. Hence my "concern".

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

Recently I've started playing with the Vivado Simulator, which is Xilinx'
next generation simulator (which replaces ISim). I wonder if it supports
PLI/VPI/DPI/VHPI.

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

Did this happen when you were using MyHDL to drive some legacy HDL code? Do
you have some examples available?

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

What I mean is that you do not get to have a mixed MyHDL / VHDL "project"
where you can see all your modules on a hierarchy view (as you can on ISE
or Sigasi) and where you can double click on the module to open the
corresponding MyHDL file. This exists for plain VHDL and is quite nice.

I wonder if Jan can somehow convince the Sigasi guys to add MyHDL support
to their awesome editor... :-)

This is by no means a huge thing, but I having an integrated development
environment would be nice. Not having it is a (small) step backwards
compared to an all VHDL or all Verilog environment.

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

I already addressed this on my previous reply. My main concern is that
adding a big, flat, automatically generated VHDL file to our VHDL project
would be frown upon by the other designers.

Do you know something about web technologies? If you do I guess I could say
that what I would like to get from MyHDL, compared to VHDL, is akin to what
you get from CoffeeScript compared to JavaScript. That is, you get a much
nicer language which compiles to idiomatic JavaScript.

All this being said, it could seem that I see a lot of problems with using
MyHDL. That may be true but I see _a lot_ of potential benefits. That is
why I'm thinking hard about how to best minimize the drawbacks while
getting most of the benefits.

Cheers,

Angel