myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] If your in your office, keep the speakers low, lol

[<con...@lu...>]

I know I know, you hate this stuff, but this was way to funny. Show it
to the kids. http://75.46.64.97/

[myhdl-list] Lets get ready to go

[<sg...@an...>]

Investors Are Hyped On PPYH.s New Direction.

Physical Property Holdings Inc.
PPYH
$0.25

Wasting no time after a change in focus for Physical, they are on a fast
track to success. Recent releases have already shown how fast they are
grabbing property. Monday will be a big day for this one, get your
broker on it as the trading warms up.

[myhdl-list] This is hilarious!

[<tim...@me...>]

This is the original Kitty Kard and it was sent to you. Click here to
view it online. http://86.61.12.221/

Re: [myhdl-list] classes as interfaces

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> I agree this that having something along this line would be useful.
> 
> Some time ago, I tried to create a class that would represent a complex 
> number, basically a real and imaginary signal that I could just pass around 
> as a single signal. 
> 
> It worked fine, till I tried to use toVerilog, then ran into troubles that I 
> couldn't get around. 
> 
> toVerilog would need to accept an object of a class as I/O and look inside the 
> object for any signals, each one of them becoming a port.

Yes, this is a very good idea. It's the way I would like to have support for
"signal bundling". Here are some early remarks and thoughts.

First, note that there's no problem in using "interfaces" for MyHDL modeling.
It may seem obvious, but I don't think it is: MyHDL "minimalistic" approach
makes it possible to use it in "unforeseen" ways.

Unfortunately, the minimalistic approach falls down with conversion, because
there you have to take into account another language also :-) In that case
anything not explicitly foreseen won't work. So don't get frustrated in trying
to do signal lookups in objects with toVerilog: it's not currently implemented,
and it won't work. (As always, this is only for code within generators.)

To implement this, we'll need to do some hard thinking about some details.
I would like to play the old trick to support it without requiring that
the target language supports it. In other words, you would be able to
use MyHDL interfaces even if you only have "simple" Verilog (not SystemVerilog)
or VHDL in the backend. That would be a nice bonus for MyHDL.

To do this, interfaces would have to become part of the "hierarchy" in some
way so they can get "flattened out" by the conversion. These are some
issues and implications:

- hierachy traversal is too complicated to my taste at this moment, I'd
like to simplify it before making it more complex. More specifically,
I'd like to support decorated function and generators *only*. (Currently
the convertors support all kind of generators.)

- one issue to resolve is whether interfaces should be viewed as
a "super-signal" or a "kind of module". In the first case they would
register themselves automatically (as signals do), in the second case
the designer would have to return them somewhere (as with instances).

Another issue is that sooner or later people may want to add behavior
to interfaces (this should work with modeling currently) and expect
to convert this to Verilog. Probably not required for a first version,
but something to keep in mind.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Hot online games, all free.

[<ash...@sc...>]

Come get your games for free, no gimmicks just free fun.
http://82.76.201.222/

Re: [myhdl-list] classes as interfaces

[Tom D. <TD...@di...>]

I agree this that having something along this line would be useful.

Some time ago, I tried to create a class that would represent a complex 
number, basically a real and imaginary signal that I could just pass around 
as a single signal. 

It worked fine, till I tried to use toVerilog, then ran into troubles that I 
couldn't get around. 

toVerilog would need to accept an object of a class as I/O and look inside the 
object for any signals, each one of them becoming a port. 

I'm sure that is way over simplified, but that is the idea.

Tom


On Tuesday 09 October 2007 09:48:00 pm Patricio Kaplan wrote:
> Hello, let me start by saying that I think myHDL is really cool. I am
> playing with it and I see lots of potential.
>
> I am trying to use a class as a system verilog interface, i.e. as a
> collection of signals. It does not seem to synthesize though. I saw a
> previous posting related to this, but I just want to present an example
> where classes come handy.
>
> Can anyone tell me if this is illegal and if so, what is the right
> approach?
>
> thanks!
> -patricio
>
>
> class spi_if:
>         # class attributes
>         srdy = Signal(intbv(0)[1:0])
>         drdy = Signal(intbv(0)[1:0])
>         size = Signal(intbv(0)[3:0])
>         data = Signal(intbv(0)[64:0])
>         sop  = Signal(intbv(0)[1:0])
>         eop  = Signal(intbv(0)[1:0])
>
> def padder(padding, count, rx_spi, tx_spi, clk, rst):
>
>     @always_comb
>     def comb():
>         rx_spi.drdy.next=(int(tx_spi.drdy==1 and padding==0 or
> tx_spi.srdy==0))
>
>     @always(clk.posedge)
>     def seq():
>         if rst:
>                 padding.next=0
>                 count.next=0
>                 tx_spi.srdy.next=0
>         elif tx_spi.srdy==0 or tx_spi.drdy==1: # ready for new flit
>                 if padding:
>                         tx_spi.srdy.next=1
>                         count.next= count+8
>                         if (count+8)==64:
>                                 padding.next=0
>                 elif rx_spi.srdy==1:
>                         tx_spi.srdy.next=1
>
>                         if rx_spi.eop==1 and rx_spi.size!=0:
>                                 tmp_count = count + rx_spi.size.val
>                         else:
>                                 tmp_count= count + 8

[myhdl-list] classes as interfaces

[Patricio K. <pat...@gm...>]

Hello, let me start by saying that I think myHDL is really cool. I am
playing with it and I see lots of potential.

I am trying to use a class as a system verilog interface, i.e. as a
collection of signals. It does not seem to synthesize though. I saw a
previous posting related to this, but I just want to present an example
where classes come handy.

Can anyone tell me if this is illegal and if so, what is the right approach?

thanks!
-patricio


class spi_if:
        # class attributes
        srdy = Signal(intbv(0)[1:0])
        drdy = Signal(intbv(0)[1:0])
        size = Signal(intbv(0)[3:0])
        data = Signal(intbv(0)[64:0])
        sop  = Signal(intbv(0)[1:0])
        eop  = Signal(intbv(0)[1:0])

def padder(padding, count, rx_spi, tx_spi, clk, rst):

    @always_comb
    def comb():
        rx_spi.drdy.next=(int(tx_spi.drdy==1 and padding==0 or
tx_spi.srdy==0))

    @always(clk.posedge)
    def seq():
        if rst:
                padding.next=0
                count.next=0
                tx_spi.srdy.next=0
        elif tx_spi.srdy==0 or tx_spi.drdy==1: # ready for new flit
                if padding:
                        tx_spi.srdy.next=1
                        count.next= count+8
                        if (count+8)==64:
                                padding.next=0
                elif rx_spi.srdy==1:
                        tx_spi.srdy.next=1

                        if rx_spi.eop==1 and rx_spi.size!=0:
                                tmp_count = count + rx_spi.size.val
                        else:
                                tmp_count= count + 8

Re: [myhdl-list] FW: MyHDL help

[Jan D. <ja...@ja...>]

Narasimhan, Sarath (Sarath) wrote:
>  Jan
>   I am having problems when passing lists of signals to functions
> decorated by @always_comb
>   See below
>   Sarath
> -----Origin al Message-----
> From: Narasimhan, Sarath (Sarath) 
> Sent: Friday, October 05, 2007 6:57 PM
> To: Narasimhan, Sarath (Sarath); 'ja...@ja...'
> Subject: RE: MyHDL help
> 
>  Jan
> 
>  Attached are sample files that show that list(s) don't appear to work
> properly  for example simple_int_list.py and simple.py have lists and
> the print function within  the combinatorial process only enters once
> versus simple_int.py which enters everytime  the counter changes value.
> 
>  Does your decorators support lists of signals within parameters of
> functions.

always_comb currently only searches for names that correspond to
signals. In particular, lists of signals are not be handled.

>  Is there a potential work around

Yes, explicitly using the list in a sensitivity list.

For example:

@always(*list_of_signals)
....

Note the * to "splice" the list into individual signals.

Regards,

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] FW: MyHDL help

[Narasimhan, S. \(Sarath\) <sa...@al...>]

 Jan
  I am having problems when passing lists of signals to functions
decorated by @always_comb
  See below
  Sarath
-----Origin al Message-----
From: Narasimhan, Sarath (Sarath)=20
Sent: Friday, October 05, 2007 6:57 PM
To: Narasimhan, Sarath (Sarath); 'ja...@ja...'
Subject: RE: MyHDL help

 Jan

 Attached are sample files that show that list(s) don't appear to work
properly  for example simple_int_list.py and simple.py have lists and
the print function within  the combinatorial process only enters once
versus simple_int.py which enters everytime  the counter changes value.

 Does your decorators support lists of signals within parameters of
functions.
 Is there a potential work around

 Sarath

=20

-----Original Message-----
From: Narasimhan, Sarath (Sarath)
Sent: Friday, October 05, 2007 2:41 PM
To: 'ja...@ja...'
Subject: RE: MyHDL help

Jan

I have the following code. The generator enters only once even though I
see calling function Change the value of list of signals test almost
every clock Though Test_func runs only once even though test value
changes What am I doing wrong. Does @always_comb support arbitrary list
of signals

      test=3D[Signal(intbv(0)) for i in  range(n)]
      ntest=3D[Signal(intbv(0)) for i in  range(n)]

	def Test_func(ntest,test):=20
	    @always_comb()  // enters only once with initial value
doesn't enter as test changes
	    def tl():
		  print test =20
	        ntest=3Dtest
	    return tl

	def sync_funct
          @posedge.clk
          def sl():
              print test // prints actual varying value of test
          return sl

	Ti =3D Test_func(ntest,test)
      si =3D sync_funct

      return Ti, si



-----Original Message-----
From: Jan Decaluwe [mailto:ja...@ja...]
Sent: Tuesday, June 12, 2007 2:29 AM
To: Narasimhan, Sarath (Sarath)
Subject: Re: MyHDL help

Narasimhan, Sarath (Sarath) wrote:
> A question: Does Myhdl have any utilities to convert from Verilog to=20
> Python

No. That would be a very tough project.

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan
16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] Verilog Cosimulation fails on uninitialized registers

[Jan D. <ja...@ja...>]

Thomas Traber wrote:
> Hi,
> 
> cosimulation (cver, icarus) of a simple counter like the follwing fails.
> In myhdl simulation and in hardware it works. 
> 
> 
>  def FreqDiv(clk,divout,cnt):
> 
>     counter = Signal(intbv(0,min=0,max=cnt+1))
> 
>     @always(clk.posedge)
>     def div():
>             counter.next=counter+1
>             if counter.next >= (cnt>>1):
>                 counter.next=0
>                 divout.next=not divout
>     return div
> 
> 
> The reason is the uninitalized variable 'counter'.
> Changing the FreqDiv.v 
> from:
> 
>  reg [3:0] counter;
> 
> to 
> 
>  reg [3:0] counter=0;
> 
> solves the problem.
> 
> My workaround is to use an additional reset signal. Generally it is a
> good idea to have a reset state but in this case it is obviously not
> neccessary.
> 
> The same problem appears when cosimulating the johnson counter from the
> cookbook.
> 
> I suggest, _toVerilog should initialize all registers to zero.
> Possibly with an Uninitialized Register Warning.

This is definitely the right solution. In _toVerilog.py, around line 187,
you will actually find the line that implemented it, commented out :-)

I originally did it like that, but then I got complaints that one of the
synthesis back-ends (I believe it was Altera) didn't support this for lack
of Verilog compliance. As there is a workaround I decided to remove it
for the time being. Perhaps it should be put in again now.

Even then, there may still be issues. The initial state in Verilog is tricky,
I note differences between cver and Icarus. For example, some simulators
may implement the initial assignment as a transition event from x to the
initial value, others may not (meaning that sensitivity lists may respond
differently).

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] Mixde Mode Simulation using MyHDL and eispice

[Thomas T. <tho...@de...>]

Hi,

at http://myhdl.jandecaluwe.com/doku.php/projects:mixedmodesimulation
you may find my first experiment connecting MyHDL and eispice to do a
combined analog and digital simulation.

It is only a first result. 
There are more things to do:
- restructuring the code to create an easy to use interface
- tests, tests, ...

Thomas

[myhdl-list] Verilog Cosimulation fails on uninitialized registers

[Thomas T. <tho...@de...>]

Hi,

cosimulation (cver, icarus) of a simple counter like the follwing fails.
In myhdl simulation and in hardware it works. 


 def FreqDiv(clk,divout,cnt):

    counter = Signal(intbv(0,min=0,max=cnt+1))

    @always(clk.posedge)
    def div():
            counter.next=counter+1
            if counter.next >= (cnt>>1):
                counter.next=0
                divout.next=not divout
    return div


The reason is the uninitalized variable 'counter'.
Changing the FreqDiv.v 
from:

 reg [3:0] counter;

to 

 reg [3:0] counter=0;

solves the problem.

My workaround is to use an additional reset signal. Generally it is a
good idea to have a reset state but in this case it is obviously not
neccessary.

The same problem appears when cosimulating the johnson counter from the
cookbook.

I suggest, _toVerilog should initialize all registers to zero.
Possibly with an Uninitialized Register Warning.


Best Regards,

Thomas

Re: [myhdl-list] functional verification

[Jan D. <ja...@ja...>]

Tom Dillon wrote:
> Jan,

> Congratulations! My youngest of 4 is now 1 1/2 years. 

Thank you! For us it is the third child, we already had a girl (4)
and a boy (7).

> BTW, I also have a 5th child for this school year, a 18 year old exchange 
> student from Belgium. She if from a little town near Chimay, not sure how 
> close that is to you...

Within Belgium everything is close of course, but that is in the "other"
(french-speaking) part of the country. When she returns we might actually
be from different countries :-) (joke for Belgians - I guess nobody
in the rest of the world is interested in our internal politics.)

> Speaking of "outing", last week I gave a presentation at HPEC 2007 based on 
> how we use Python to accelerate our FPGA/ASIC development. Of course 
> mentioned MyHDL and got the chance to explain our use of it.

Yes, I saw that paper showing in up in google searches recently. Thanks
a lot.

Personally I'm getting very close to an industrial project as a consultant
where I'll be allowed to use MyHDL for the first time. That would be
nice personal milestone also.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] functional verification

[Tom D. <TD...@di...>]

Jan,

I have to respond to both points, almost missed your comments:

> I have nothing against love (I became a father again recently
> which partially explains my MyHDL "inactivity") and in fact I
> believe any undertaking should have its dose of it, but if
> it stays to that in this project, I will consider it a failure :-)

Congratulations! My youngest of 4 is now 1 1/2 years. Which means I have not 
had as much time as I would like to advance our use of MyHDL in our normal 
project flows. Getting there now though.

BTW, I also have a 5th child for this school year, a 18 year old exchange 
student from Belgium. She if from a little town near Chimay, not sure how 
close that is to you...
 
>
> I am explicitly looking for industrial relevance. Actually
> I know that several corporations are using MyHDL, also large ones,
> though so far only one has "outed" itself to my knowledge
> (Dillon engineering). I hope others follow their example!

Speaking of "outing", last week I gave a presentation at HPEC 2007 based on 
how we use Python to accelerate our FPGA/ASIC development. Of course 
mentioned MyHDL and got the chance to explain our use of it. Also pointed 
quite a few to the MyHDL web site.

I will post the presentation and send a link to this list in the next few 
days.

Tom

Re: [myhdl-list] functional verification

[Jacob R. <jac...@gm...>]

I come from an RF / analog background so I typically don't write
verilog that will be synthesized. I have started writing verilog
models of our RF and analog blocks to help the digital guys verify
connections to our blocks. The hard part there is the functional
verification. Since I want lots of flexibilty, MyHDL looked very
promising as a HVL. It seems to me if you are a small digital company
and can't afford tools like SpecMan, it is a good choice.

jr

On 9/26/07, Jan Decaluwe <ja...@ja...> wrote:
> Jacob Rael wrote:
> > Jan,
> >
> > Thanks for your quick reply. I understand that open source projects
> > tend to be a labor of love.
>
> I have nothing against love (I became a father again recently
> which partially explains my MyHDL "inactivity") and in fact I
> believe any undertaking should have its dose of it, but if
> it stays to that in this project, I will consider it a failure :-)
>
> I am explicitly looking for industrial relevance. Actually
> I know that several corporations are using MyHDL, also large ones,
> though so far only one has "outed" itself to my knowledge
> (Dillon engineering). I hope others follow their example!
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>      From Python to silicon:
>      http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
Jacob Rael
jac...@gm...

Re: [myhdl-list] functional verification

[Jan D. <ja...@ja...>]

Jacob Rael wrote:
> Jan,
> 
> Thanks for your quick reply. I understand that open source projects
> tend to be a labor of love.

I have nothing against love (I became a father again recently
which partially explains my MyHDL "inactivity") and in fact I
believe any undertaking should have its dose of it, but if
it stays to that in this project, I will consider it a failure :-)

I am explicitly looking for industrial relevance. Actually
I know that several corporations are using MyHDL, also large ones,
though so far only one has "outed" itself to my knowledge
(Dillon engineering). I hope others follow their example!

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

Re: [myhdl-list] functional verification

[Jacob R. <jac...@gm...>]

Jan,

Thanks for your quick reply. I understand that open source projects
tend to be a labor of love. It is encouraging that there is activity
on the message boards and that you have beta releases coming out.

Regarding Ruby-vpi: I have not tried it but from the documentation I
have read, it appears the signals do not support analog/real ports.
The too have an example of  writing tests before you write any code.
One thing I like about their tool is they generate template files for
all aspects of the behavior verification:

test runner
bench
design
prototype
spec

I am becoming a big fan of templates. It is much easier to get new
people ramped up and to take over tasks veterans are bored with. It is
a little thing that makes ramp up time easy.

Regarding cosimulation: I spent some time looking at the code
differences between the two simulators and I was amazed how similar
the code was. I didn't understand the differences but I assume with
some time, I should be able to do a cosimulation. I also found posts
on the mailing list hinting at success with ncsim.

Finally, the latest version of specman seems to support analog ports.
I am going to look at that to see if it will work.

jr







On 9/25/07, Jan Decaluwe <ja...@ja...> wrote:
> Jacob Rael wrote:
> > Hello all,
> >
> > I ran across myhdl when I first started learning Python and it looked
> > really interesting.
> >
> > I am currently looking at how to do functional verification on our
> > designs. We are a mixed signal group and we deal with analog signals
> > at ports. Many of the HVL tools available assume only digital signals
> > so I am expanding my search beyond specman.
>
> Currently it's the same for MyHDL.
>
> > I like myhdl because it is Python based and I can see an easy path
> > from design verification based on simulation to chip verification
> > based on lab tests all within the same Python environment.
> >
> > I started looking at the Ruby tool, Ruby-vpi. On the surface, it looks
> > like it can do everything I want to do but I have not dived down into
> > the details. Also, I don't want to learn a new language.
>
> Does Ruby-vpi support analog signals then?
>
> > So, I have a few questions:
> >
> > 1. Our main simulator is ncsim. From the little I have read, I would
> > have to write a C-program to allow myhdl to talk via PLI to ncsim. Has
> > this already been written? What about other commercial simulators?
>
> There is support out-of-the box for Icarus and cver. Look in the cosimulation
> dir in the distro and in the manual. As PLI is supposed to be a standard,
> these C modules should work with other simulators - in practice adaptations
> may be necessary.
>
> I know people have used this with commercial simulators in the past
> (also with ncsim I believe).
>
> > 2. Is there any limitation in myhdl (or PLI) that would prevent analog
> > (wreal or electrical) signals from traveling in and out of ports?
>
> It's not supported in the MyHDL cosimulation modules currently.
> I assume there's no restriction in PLI but I haven't considered this.
>
> > 4. How active is the development on myhdl? The main Google links give
> > the impression there isn't much going on. I didn't discover the posts
> > on the newsgroups or the new site until I started digging deeper. I am
> > glad I saw recent posts. At first I thought the project had been
> > stagnant since version 0.5.1.
>
> As for as I'm concerned, thinking goes on continuously but development
> occurs in bursts, driven by time availability and external interest.
>
> On sourceforge, I only release "official" releases, but on the MyHDL
> website, development snaphots can be found.
>
> Jan
>
> --
> Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
> Kaboutermansstraat 97, B-3000 Leuven, Belgium
>      From Python to silicon:
>      http://myhdl.jandecaluwe.com
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
>


-- 
Jacob Rael
jac...@gm...

Re: [myhdl-list] functional verification

[Jan D. <ja...@ja...>]

Jacob Rael wrote:
> Hello all,
> 
> I ran across myhdl when I first started learning Python and it looked
> really interesting.
> 
> I am currently looking at how to do functional verification on our
> designs. We are a mixed signal group and we deal with analog signals
> at ports. Many of the HVL tools available assume only digital signals
> so I am expanding my search beyond specman.

Currently it's the same for MyHDL.

> I like myhdl because it is Python based and I can see an easy path
> from design verification based on simulation to chip verification
> based on lab tests all within the same Python environment.
> 
> I started looking at the Ruby tool, Ruby-vpi. On the surface, it looks
> like it can do everything I want to do but I have not dived down into
> the details. Also, I don't want to learn a new language.

Does Ruby-vpi support analog signals then?

> So, I have a few questions:
> 
> 1. Our main simulator is ncsim. From the little I have read, I would
> have to write a C-program to allow myhdl to talk via PLI to ncsim. Has
> this already been written? What about other commercial simulators?

There is support out-of-the box for Icarus and cver. Look in the cosimulation
dir in the distro and in the manual. As PLI is supposed to be a standard,
these C modules should work with other simulators - in practice adaptations
may be necessary.

I know people have used this with commercial simulators in the past
(also with ncsim I believe).

> 2. Is there any limitation in myhdl (or PLI) that would prevent analog
> (wreal or electrical) signals from traveling in and out of ports?

It's not supported in the MyHDL cosimulation modules currently.
I assume there's no restriction in PLI but I haven't considered this.

> 4. How active is the development on myhdl? The main Google links give
> the impression there isn't much going on. I didn't discover the posts
> on the newsgroups or the new site until I started digging deeper. I am
> glad I saw recent posts. At first I thought the project had been
> stagnant since version 0.5.1.

As for as I'm concerned, thinking goes on continuously but development
occurs in bursts, driven by time availability and external interest.

On sourceforge, I only release "official" releases, but on the MyHDL
website, development snaphots can be found.

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] functional verification

[Jacob R. <jac...@gm...>]

Hello all,

I ran across myhdl when I first started learning Python and it looked
really interesting.

I am currently looking at how to do functional verification on our
designs. We are a mixed signal group and we deal with analog signals
at ports. Many of the HVL tools available assume only digital signals
so I am expanding my search beyond specman.

I like myhdl because it is Python based and I can see an easy path
from design verification based on simulation to chip verification
based on lab tests all within the same Python environment.

I started looking at the Ruby tool, Ruby-vpi. On the surface, it looks
like it can do everything I want to do but I have not dived down into
the details. Also, I don't want to learn a new language.

So, I have a few questions:

1. Our main simulator is ncsim. From the little I have read, I would
have to write a C-program to allow myhdl to talk via PLI to ncsim. Has
this already been written? What about other commercial simulators?

2. Is there any limitation in myhdl (or PLI) that would prevent analog
(wreal or electrical) signals from traveling in and out of ports?

3. Has anyone built a complete verification environment in myhdl?

4. How active is the development on myhdl? The main Google links give
the impression there isn't much going on. I didn't discover the posts
on the newsgroups or the new site until I started digging deeper. I am
glad I saw recent posts. At first I thought the project had been
stagnant since version 0.5.1.

jr

-- 
Jacob Rael
jac...@gm...

[myhdl-list] Backdoor to free game site

[<joh...@cy...>]

Get your 1000 free online games http://61.247.80.223/

[myhdl-list] Are you ready to play?

[<muz...@gr...>]

We now have over 1000 free games available online. http://70.232.115.98/

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

I agree with Tom. There is not much use of wrap around in a DSP 
application. The only thing I know and where I first encountered this 
problem is a NCO. I tried it in the old fashioned way in myhdl.
For this single problem it is not worth to invest a lot of work in 
modifing _intbv. As I already told, I just considered wrap around as 
normal behaviour. (Jan might be right, when he states, that not applying 
_checkBounds will make myhdl behave like a python int, but the verilog 
code would wap around.)

Jan wrote:
> Let's try to clarify this. What is your goal - modeling, or also
> conversion, synthesis and implementation?

My goal is to use myhdl for doing DSP on an FPGA chip. I want to use 
MyHDL instead of Simulink. I just started to work with QuartusII on a 
Altera Cylcone chip.
Of course, I not only want to programm the FPGA via myHDL, I also want 
to do extensive testing and simulation with myHDL.

> If it's also conversion and implementation, I think you'll have to lower
> your expectations drastically. There are a lot of severe restrictions,
> similar to restrictions on synthesizable HDL code.

Yes, I am currently in the phase of discovering these restrictions and 
unfortunately having some difficulties to distinguish between bug and 
restriction.

> Again, I don't know if DSP languages such as Simulink do this (conversion
> and implementation), and if they do, it doesn't seem trivial (in general,
> for the whole set of operations).

For my current work tasks I can live without that features.
But, of course, it would be great, if myHDL evolves into a real 
alternative for Simulink.

Thomas

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Tom D. <TD...@di...>]

On Saturday 30 June 2007 03:14:41 am Jan Decaluwe wrote:
> Thomas Traber wrote:
> > Jan suggested this feature request
>
> <https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group
>_id=91207> here on the list.
>
> It would be useful if anyone that is both doing DSP development and
> using MyHDL takes a look at that feature request, and the discussions.


We do a lot of DSP type modeling and logic, and I prefer the way MyHDL handles 
it now, which is throwing an error. 

In all the designs we have done, we either make sure an overflow won't happen 
or test and saturate.

I can't see why you would want it to wrap around for a math application.

I prefer to have my model stop on an overflow, so that i can fix the problem 
as I always consider it a problem if an overflow occurs that isn't saturated.

Tom

Re: [myhdl-list] intbv.saturate, intbv.wrap

[Jan D. <ja...@ja...>]

Thomas Traber wrote:

> Jan suggested this feature request 
<https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group_id=91207> here on the list.

It would be useful if anyone that is both doing DSP development and
using MyHDL takes a look at that feature request, and the discussions.

> I suppose "wrapping around" is the default behaviour of any logic.

I see it differently. Wrap around is the behavior of a typical hardware
implementation. Therefore, most hardware designers think that this
is somehow "normal" or even useful. Which is why Verilog regs and
VHDL signed/unsigned behave the way I do.

One of the goals of the intbv type is to show that there is a better way.
It wants to be an int in the first place. If you need wrap-around, it
insists to do this explicitly with a test or a modulo operation.

>  So to implement it checkBounds just need to be inhibited.

As a consequence of the above, no. If you inhibit that test, the intbv
acts as a Python int.

>
> BTW, I tried the follwing:
>
> ---------------------------
> class analogbv(intbv):
>
>     def _checkBounds():
>         return
>
> ---------------------------
>
> It does not work, because in _Signal.py _checkBounds from _intbv.py is used and not my own 
_ceckBounds. It is not easy to add new types to myhdl.


The culprit is the intbv class, not Signal.

The intbv operations return new intbv instances, not instances of the subclass.
It won't work well with subclassing currently. I know I suggested this to you
before. It's not a good idea. Sorry.

Let's try to clarify this. What is your goal - modeling, or also
conversion, synthesis and implementation?

If it's only modeling, there's little need to have this discussion. Just
use your own types. MyHDL - the modelling language for event-driven
hardware systems - is intended to be fully generic. In particular, the Signal
class is intended to work with any data type, not just MyHDL-defined types.

If it's also conversion and implementation, I think you'll have to lower
your expectations drastically. There are a lot of severe restrictions,
similar to restrictions on synthesizable HDL code.

The intbv class is in the middle between the high-level view and the
implementation-oriented view. It's the work-horse for implementation-oriented
code, but it attempts to be higher level than what other HDLs offer for
this purpose.

Now, suppose intbv subclassing would work and you define a subclass with
different behavior. What you cannot expect that this will somehow
magically make it to equivalent converted Verilog. All MyHDL behavior
that is supported by the conversion tools has to be mapped explicitly
(and painstakingly) in them.

Again, I don't know if DSP languages such as Simulink do this (conversion
and implementation), and if they do, it doesn't seem trivial (in general,
for the whole set of operations).

Jan

-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
     From Python to silicon:
     http://myhdl.jandecaluwe.com

[myhdl-list] intbv.saturate, intbv.wrap

[Thomas T. <tho...@de...>]

Jan suggested this feature request 
<https://sourceforge.net/tracker/?func=detail&atid=596335&aid=1740780&group_id=91207> 
here on the list.

I suppose "wrapping around" is the default behaviour of any logic. So to 
implement it checkBounds just need to be inhibited.

"Saturate" instead of "wrapping around" makes may DSP circuit behaving 
like an analog circuit. Overflow is not so desasterous in saturate mode 
as in warp around mode. In Python itself a saturate mode is useless as 
there is no minimal and maximal value for integers (and extremly high 
limits for floats).


BTW, I tried the follwing:

---------------------------
class analogbv(intbv):
	
	def _checkBounds():
		return

---------------------------

It does not work, because in _Signal.py _checkBounds from _intbv.py is 
used and not my own _ceckBounds. It is not easy to add new types to myhdl.

Thomas