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

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

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.

Our current setup is as follows:

- We use Xilinx FPGAs (Spartan and Virtex 5 and 6 and probably Kintex
or Virtex 7 soon).
- Our firmware code is 100% VHDL.
- We use the latest version of the Xilinx ISE environment (which
unfortunately is pretty weak, specially in the editing and code
exploration departments).
    - Some of us are also using the excellent Sigasi editor (which I
discovered thanks to this list). For now we are using the basic
edition which is nice but we hope to be able to buy a few licenses
soon.
- We use some Xilinx IP cores, which come as an NGC plus a VHDL simulation file.
- We receive a basic firmware "shell" from our hardware team, which,
basically, is the top VHDL file of the design. This "shell" sets up
the system clocks, instantiates the different devices that are used to
connect the FPGA firmware to the outside world (i.e. the different
ports, etc), as well as the memories, and other devices that are
present on the FPGA and on its board.
    - That "shell" also contains an instance of the actual "top
entity" that is the one that we create.
    - They also give us the basic "constraints file" which selects the
pinout, etc.
    - We have no control over what we receive from the HW team. We
must use what they give us "as is".
- We do not use any custom TCL scripts to build our firmware. We just
use the ISE "Generate Programming File" command.
- We use either Modelsim or the builtin ISE ISim simulator to run our
simulations. We are exploring the possibility of using Xilinx' new
Vivado Simulator as well.
- We usually create a "high level" Matlab or python based simulation
models of our system. The model is not necessarily bit accurate to the
actual VHDL implementation, but we try to make it so that it is able
to generate the inputs necessary to drive our VHDL test benches
(including configuration and data), and even our compiled firmware
(mostly configuration)
- We create VHDL test benches for most (although sadly not all) of our
modules. These test benches are usually quite simple. They just read
the inputs from some files (generated with our Matlab or python
simulators) and save the outputs so that they can be compared to some
"golden" outputs (usually generated with our high level simulators).
    - When there are issues we often use the test benches to simulate
the models and we use the (not so good) visualization capabilities of
Modelsim to debug.
   - We also tend to use ChipScope to add "logic analyzer modules" to
our firmware so that we can debug "live" some specially tricky issues.
    - We also use a logic analyzer port to output data that is then
captured by an external logic analizer. This is necessary when the
amount of data to capture is so great that it would not fit on a
ChipScope block.

What we definitely cannot do is introduce huge changes to our
development practices. I am sure that there are plenty of things that
we could do differently and that we should (and probably will)
improve. However I'd like to introduce this new technology gradually,
and once people are more comfortable with it we could do bigger
changes to our work flow.

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).
2. We should come up with a way to automatically generate the VHDL
from the MyHDL when we generate our programming file.
3. There is no integration (AFAIK) between MyHDL and iSIM or Modelsim
(at least on Windows).
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.
5. There is no editor integration (not even with Sigasi).
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".

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