ANNOUNCE: MyHDL 0.2 
Author Message
 ANNOUNCE: MyHDL 0.2

"Write your HDL test benches in Python!"

I am happy to announce the release of MyHDL 0.2, a python package for
using Python as a hardware description & verification language.

You can find it at http://www.*-*-*.com/

MyHDL 0.2
---------

MyHDL is a Python package for using Python as a hardware description
language. Popular hardware description languages, like Verilog and
VHDL, are compiled languages. Python with MyHDL can be viewed as a
"scripting language" counterpart of such languages. However, Python is
more accurately described as a very high level language (VHLL). MyHDL
users have access to the amazing power and elegance of Python for
their modeling work.

The key idea behind MyHDL is to use Python generators to model the
concurrency required in hardware descriptions. As generators are a
recent Python feature, MyHDL requires Python 2.2.2 or higher.

MyHDL can be used to experiment with high level modeling, and with
verification techniques such as unit testing. The most important
practical application however, is to use it as a hardware verification
language by co-simulation with Verilog and VHDL.

The present release, MyHDL 0.2, enables MyHDL for co-simulation. The
MyHDL side is designed to work with any simulator that has a PLI. For
each simulator, an appropriate PLI module in C needs to be
provided. The release contains such a module for the Icarus Verilog
simulator.

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium

http://www.*-*-*.com/



Fri, 04 Nov 2005 16:20:41 GMT  
 ANNOUNCE: MyHDL 0.2
Well, since Jan is not offended, I shall post this...

I had a look at this release (I looked at the first too), and I couldn't
help but think that most of the examples were trying to do the low level
simulation type stuff that Verilog/VHDL do so well already.
Wouldn't Pythons use in the Electronic Design Automation sphere be
better targetted at something like System level simulation, or wrapping
testbuilder with Boost Python/SWIG to give it more of the script feel of
the Specman e language?

I guess this is a criticism, but I don't meen to offend, so I have
emailed you privately.

Thanks,  Paddy.

Hi:

I don't see this as a criticism - in fact I have my reasons
and my doubts and I would love to hear input from others.

Actually I would prefer to discuss this publicly (saving
energy) so if you would like to post it on public forum,
please go ahead. Otherwisze, I will come back to you
on this in private.

Thanks for the interest, Jan

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium

http://jandecaluwe.com



Sun, 06 Nov 2005 14:58:12 GMT  
 ANNOUNCE: MyHDL 0.2

Quote:

> I had a look at this release (I looked at the first too), and I couldn't
> help but think that most of the examples were trying to do the low level
> simulation type stuff that Verilog/VHDL do so well already.

If the manual or examples suggest that the primary goal of MyHDL
is RTL design the traditional way, then that's a real problem
that I have to correct.

On the other hand, it is written for HDL designers and I try
to keep things familiar to get attention. The intended message
of the manual is that they can use the power of Python, which
goes much beyond what Verilog or VHDL will ever be able to
achieve, without losing much.

I may not have succeeded in getting this message across very
well: suggestions are welcome. BTW, the manual is now on-line:

  http://jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html

Some more detailed points:

* Symplicity may be deceiving. For example, take a
sparseMemory model in MyHDL, from the manual:

def sparseMemory(dout, din, addr, we, en clk):
    """ Sparse memory model based on a dictionary."""
    memory = {}
    while 1:
        yield posedge(clk)
        if not en:
            continue
        if we:
            memory[addr] = din.val
        else:
            dout.next = memory[addr]

This example is both simple and relevant in real designs.
However, it is close to impossible to do in Verilog
or VHDL. (Here's a design challenge: the lines are open!)

* Examples may need to be trivial to explain
something else. For example, when describing
unit testing I need an example that people know and
understand readily - the concept of unit text XP style is
complex enough like that.

Quote:
> Wouldn't Pythons use in the Electronic Design Automation sphere be
> better targetted at something like System level simulation, or wrapping
> testbuilder with Boost Python/SWIG to give it more of the script feel of
> the Specman e language?

Of course, or other things that we don't yet think of. But
again, I believe strongly in a bottom-up approach.

System level simulation also requires a good model of
concurrency; MyHDL has it, and can be used for it today.

Testbuilder - perhaps, if I ever understand it.

Finally: I think I can handle the groundworks and the HDL
part myself. Beyond that point however, where things
really get interesting, progress will require and depend
on external input.

Regards, Jan

--
Jan Decaluwe - Resources bvba
Losbergenlaan 16, B-3010 Leuven, Belgium

http://jandecaluwe.com



Sun, 06 Nov 2005 18:38:53 GMT  
 ANNOUNCE: MyHDL 0.2


Quote:

>> I had a look at this release (I looked at the first too), and I couldn't
>> help but think that most of the examples were trying to do the low level
>> simulation type stuff that Verilog/VHDL do so well already.

>If the manual or examples suggest that the primary goal of MyHDL
>is RTL design the traditional way, then that's a real problem
>that I have to correct.

>On the other hand, it is written for HDL designers and I try
>to keep things familiar to get attention. The intended message
>of the manual is that they can use the power of Python, which
>goes much beyond what Verilog or VHDL will ever be able to
>achieve, without losing much.

>I may not have succeeded in getting this message across very
>well: suggestions are welcome. BTW, the manual is now on-line:

>  http://jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html

>Some more detailed points:

>* Symplicity may be deceiving. For example, take a
>sparseMemory model in MyHDL, from the manual:

>def sparseMemory(dout, din, addr, we, en clk):
>    """ Sparse memory model based on a dictionary."""
>    memory = {}
>    while 1:
>        yield posedge(clk)
>        if not en:
>            continue
>        if we:
>            memory[addr] = din.val
>        else:
>            dout.next = memory[addr]

>This example is both simple and relevant in real designs.
>However, it is close to impossible to do in Verilog
>or VHDL. (Here's a design challenge: the lines are open!)

"Close to impossible"

sparseMemory: process(clk)
  type t_array_element is access integer;
  type t_memory is array(ram_depth - 1 downto 0) of t_array_element;
  variable memory : t_memory;
begin
  if rising_edge(clk) and en = '1' then
    -- write
    if we = '1' then
      if memory(addr) /= null then
        memory(addr).all := din;
      elsif (memory(addr)= null) and (din /= 0) then
        memory(addr) := new integer;
        memory(addr).all := din;
      end if;
    end if;
    -- read
    if memory(addr) = null then
      dout <= 0;
    else
      dout <= memory(addr).all;
    end if;
  end if;
end process sparseMemory;

The semantics aren't quite the same as the MyHDL version - I didn't
bother to recreate the bug that doesn't update dout during a write
cycle.

I've no idea how to do this in pure Verilog though.

Regards,
Allan.

- Show quoted text -

Quote:
>* Examples may need to be trivial to explain
>something else. For example, when describing
>unit testing I need an example that people know and
>understand readily - the concept of unit text XP style is
>complex enough like that.

>> Wouldn't Pythons use in the Electronic Design Automation sphere be
>> better targetted at something like System level simulation, or wrapping
>> testbuilder with Boost Python/SWIG to give it more of the script feel of
>> the Specman e language?

>Of course, or other things that we don't yet think of. But
>again, I believe strongly in a bottom-up approach.

>System level simulation also requires a good model of
>concurrency; MyHDL has it, and can be used for it today.

>Testbuilder - perhaps, if I ever understand it.

>Finally: I think I can handle the groundworks and the HDL
>part myself. Beyond that point however, where things
>really get interesting, progress will require and depend
>on external input.

>Regards, Jan



Sun, 06 Nov 2005 22:09:33 GMT  
 ANNOUNCE: MyHDL 0.2
On Thu, 22 May 2003 00:09:33 +1000, Allan Herriman

Quote:




>>> I had a look at this release (I looked at the first too), and I couldn't
>>> help but think that most of the examples were trying to do the low level
>>> simulation type stuff that Verilog/VHDL do so well already.

>>If the manual or examples suggest that the primary goal of MyHDL
>>is RTL design the traditional way, then that's a real problem
>>that I have to correct.

>>On the other hand, it is written for HDL designers and I try
>>to keep things familiar to get attention. The intended message
>>of the manual is that they can use the power of Python, which
>>goes much beyond what Verilog or VHDL will ever be able to
>>achieve, without losing much.

>>I may not have succeeded in getting this message across very
>>well: suggestions are welcome. BTW, the manual is now on-line:

>>  http://jandecaluwe.com/Tools/MyHDL/manual/MyHDL.html

>>Some more detailed points:

>>* Symplicity may be deceiving. For example, take a
>>sparseMemory model in MyHDL, from the manual:

>>def sparseMemory(dout, din, addr, we, en clk):
>>    """ Sparse memory model based on a dictionary."""
>>    memory = {}
>>    while 1:
>>        yield posedge(clk)
>>        if not en:
>>            continue
>>        if we:
>>            memory[addr] = din.val
>>        else:
>>            dout.next = memory[addr]

>>This example is both simple and relevant in real designs.
>>However, it is close to impossible to do in Verilog
>>or VHDL. (Here's a design challenge: the lines are open!)

>"Close to impossible"

>sparseMemory: process(clk)
>  type t_array_element is access integer;
>  type t_memory is array(ram_depth - 1 downto 0) of t_array_element;
>  variable memory : t_memory;
>begin
>  if rising_edge(clk) and en = '1' then
>    -- write
>    if we = '1' then
>      if memory(addr) /= null then
>        memory(addr).all := din;
>      elsif (memory(addr)= null) and (din /= 0) then
>        memory(addr) := new integer;
>        memory(addr).all := din;
>      end if;
>    end if;
>    -- read
>    if memory(addr) = null then
>      dout <= 0;
>    else
>      dout <= memory(addr).all;
>    end if;
>  end if;
>end process sparseMemory;

>The semantics aren't quite the same as the MyHDL version - I didn't
>bother to recreate the bug that doesn't update dout during a write
>cycle.

>I've no idea how to do this in pure Verilog though.

Hmmm.  That VHDL version isn't exactly a sparse array, and wouldn't
save memory unless the memory was meant to store a smallish number of
large items.
Anyway, it shows the idea of dynamic allocation.

I've done SDRAM models that *do* save space by using sparse arrays in
VHDL, but the code isn't anywhere as neat as it would be if
associative arrays (dictionaries in Python) were available.

Allan.



Mon, 07 Nov 2005 02:18:26 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. ANNOUNCE: MyHDL 0.2

2. ANNOUNCE: MyHDL 0.2

3. ANNOUNCE: Grouch 0.2

4. ANNOUNCE: Kawa Version 0.2 Released

5. ANNOUNCE: PikiePikie 0.2 released

6. ANNOUNCE: Linbot 0.2 Site Management Tool for Webmasters

7. ANNOUNCE: mxODBC Version 0.2

8. ANNOUNCE: Python-Gtk Version 0.2

9. ANNOUNCE: Pmw megawidgets 0.2 (for Tkinter)

10. ANNOUNCE: Tile Widget Set version 0.2

11. Announce: TclMagick 0.2 (ImageMagick 5.5.8)

12. ANNOUNCE Tcl Fltk 0.2 - Tcl Bindings for the Fast Light Toolkit

 

 
Powered by phpBB® Forum Software