I'd rather switch than fight!

On Apr 12, 7:44=A0pm, Paul <pault...@googlemail.com> wrote:

> Are you using Python to test VHDL or Verilog HDL? Which simulator are
> you using? I know of MyHDL, but if I could use Python to test my VHDL
> that would be interesting :-), particularly if I can use it to build
> my FPGA design too. For the later I'm currently use Tcl.

To test VHDL. We simulate in Riviera-PRO using VHPI to interface to
the simulation (embedding the python interpreter into Riviera), but
something similar could be done for Modelsim. The entity under test is
directly instantiated (no testframe wrapper) and all inputs/outputs
are driven/read directly from python. You can navigate through the
hierarchy as though each entity/signal were an attribute of the root
unit under test object. Tests are written using the python yield
statement (similar to myHDL). A test yields an event which returns
control back to the simulator, resuming the python execution when the
event happens. A simple but pointless example (the "<=3D" operator is
overloaded for convenience):

def clock(clk, period):
    clk <=3D 0
    while True:
        yield EventTimer(period)
        clk <=3D not clk.val

def test(tb):
    clkthr =3D tb.thread(clock(tb.uut.clk, 3.2))
    yield tb.uut.pkt.valid.edge(1)                       # Wait for a
rising edge on output valid
    print "pkt =3D %08X" % (tb.uut.pkt.data.val)
    tb.kill(clkthr)

The nicest part is the intuitive ease with which layers of abstraction
can be combined. I tend to write a class to handle queuing and
receiving data for each bus which calls a callback when a transfer is
complete.

We use makefiles to drive the test/regression suite and synthesis
tools from the command line. Would there be any advantage to combining
or linking the two?

On 12/04/2010 17:00, cfelton wrote:
> e.
>>
>> MyHDL, on the other hand, has been around for many years, and has a
>> reasonable-sized community.  It is definitely worth looking at if you
>> are not happy with Verilog or VHDL.
>>
>>
>
> I don't believe there is any risk in trying/using MyHDL for the following
> reasons.
>
>     1.  It is stable and has been used for many FPGA and an ASIC project.
>     2.  It is open-source.
>     3.  The output is Verilog/VHDL, you can go back to an old flow if
> desired.
>
> The 3rd might not seem reasonable to some because it is computer generated
> HDL but it is not computer generated HDL like most think.  It is simply a
> translation from one RTL language to another RTL language (MyHDL ->
> Verilog/VHDL).  The structure will be the same just some minor name
> adjustments.
>

Point 1 is, I think, more important.  The reason I think MyHDL is a 
valid choice is that the software itself is pretty stable, and more 
importantly the community and developers are stable.  Point 3 (as you 
expanded on it) is more for damage limitation rather than risk 
mitigation.  It means that if MyHDL should suddenly go away or for some 
other reason be unusable, then your generated output is still useful. 
But having been bitten by using a useful but half-finished tool 
(confluence) whose developer went away (again, I don't blame him at all, 
but thank him for what he gave out), I think it is important to consider 
the risks involved in choosing tools like this.

MyHDL is open source, but that is not in itself a guarantee that the 
tool, its development, and its community will continue.  It's a 
guarantee that it always /can/ continue (if you are willing to put in 
the necessary resources) - but not that it /will/ continue.

With a project like this, you have to consider what would happen if the 
main developer went away (hit by a bus, hired by the competition, or 
just gets bored with it).  I think in the case of MyHDL, the community 
is strong enough to continue - with confluence, it was not (confluence 
was also open source).

I haven't done much FPGA work for a while, but if and when I get back to 
it, I will be using MyHDL.  All I am saying here is that these are 
issues that you need to think about before choosing a tool - just like 
you do before choosing a hardware vendor.

>To test VHDL. We simulate in Riviera-PRO using VHPI to interface to
>the simulation (embedding the python interpreter into Riviera), but
>something similar could be done for Modelsim. The entity under test is
>directly instantiated (no testframe wrapper) and all inputs/outputs
>are driven/read directly from python. You can navigate through the
>hierarchy as though each entity/signal were an attribute of the root
>unit under test object. Tests are written using the python yield
>statement (similar to myHDL). A test yields an event which returns
>control back to the simulator, resuming the python execution when the
>event happens. A simple but pointless example (the "<=3D" operator is
>overloaded for convenience):
>
>def clock(clk, period):
>    clk <=3D 0
>    while True:
>        yield EventTimer(period)
>        clk <=3D not clk.val
>
>def test(tb):
>    clkthr =3D tb.thread(clock(tb.uut.clk, 3.2))
>    yield tb.uut.pkt.valid.edge(1)                       # Wait for a
>rising edge on output valid
>    print "pkt =3D %08X" % (tb.uut.pkt.data.val)
>    tb.kill(clkthr)
>

I imagine what you posted works very well and accomplishes what you intend.
 I think for a new users adopting Python testbenches MyHDL would be a much
better choice.  I is documented, has a nice manual, there are examples
available, and a community to support questions.  The user doesn't need to
worry about HDL conversion if they do not want.  Here is a basic example of
a testbench in MyHDL.  

    @instance
    def stimulus():
        rbuf = [0]
        wbuf = [0]
        
        TracePrint('Start Testbench')
        test_data1 = [0xAA, 0x55, 0x0B, 0x0C, 0x0D]
       
        TracePrint('Write Wishbone LEDs')
        yield fx2Model.WriteAddress(0x0101, 1)
        yield fx2Model.WriteAddress(0x0103, 0xAA)
        
        TracePrint('Read Wishbone LEDs')
        yield fx2Model.ReadAddress(0x0103, rbuf)
        
        # Setup for RAMP Test input
        yield fx2Model.WriteAddress(0x0800, 0x01)

        TracePrint('  Check Ramp Data')
        rmpData = 0
        r1 = []; r2=[]
        for jj in range(100):
            yield fx2Model.WaitData(fx2Model.EP8, 512)
            yield delay(128 * fx2Model.IFCLK_TICK)
            
            for ii in range(512):
                rdata = fx2Model.Read(fx2Model.EP8)
                r1.append(rdata); r2.append(rmpData)
                if rdata != rmpData:
                    pass # Add some an assert or error exception
                rmpData = (rmpData + 1) % 256

        print " "    
        yield delay(20*fx2Model.IFCLK_TICK)

        TracePrint('  Disable Ramp')
        yield fx2Model.WriteAddress(0x0800, 0x00)


chris	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On 13 Apr, 13:45, "cfelton" <cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
wrote:
> I imagine what you posted works very well and accomplishes what you inten=
d.
> =A0I think for a new users adopting Python testbenches MyHDL would be a m=
uch
> better choice. =A0I is documented, has a nice manual, there are examples
> available, and a community to support questions. =A0The user doesn't need=
 to
> worry about HDL conversion if they do not want. =A0Here is a basic exampl=
e of
> a testbench in MyHDL.
<snip>

Agreed, I think MyHDL has a lot of potential and there is significant
functionality overlap and similarities to the environment our company
uses. What I'm lamenting is the reluctance of 'hardware engineers" to
adopt advances made in the software field, in terms of regression and
unit testing frameworks. More people should be using MyHDL or
homegrown alternatives to provide rapid simulation verification and
object oriented abstraction models. As a community we are very slow
moving when compared to other related fields.

I believe MyHDL would do well to emphasise more strongly the pure
testbench environment functionality. Many engineers do not want the
VHDL/verilog generation features but could make good use of the
simulation parts of MyHDL. Expanding the cosimulation interface
options to support ModelSim FLI and VHPI would help move it forward.

Thanks,

Chris

On 13 Apr, 14:15, Chris Higgs <chiggs...@googlemail.com> wrote:

> Agreed, I think MyHDL has a lot of potential and there is significant
> functionality overlap and similarities to the environment our company
> uses. What I'm lamenting is the reluctance of 'hardware engineers" to
> adopt advances made in the software field, in terms of regression and
> unit testing frameworks. More people should be using MyHDL or
> homegrown alternatives to provide rapid simulation verification and
> object oriented abstraction models. As a community we are very slow
> moving when compared to other related fields.

It possibly isn't reluctance - there isn't too much in the way of
resources to show how to get started, to investigate alternative
approaches, is there? (with the exception of MyHDL).

> I believe MyHDL would do well to emphasise more strongly the pure
> testbench environment functionality. Many engineers do not want the
> VHDL/verilog generation features but could make good use of the
> simulation parts of MyHDL. Expanding the cosimulation interface
> options to support ModelSim FLI and VHPI would help move it forward.

Agreed. Although, what's the approximate cost of a sim with FLI/VHPI?
Possibly out of the reach for experimenting. (again, + for MyHDL)

It might be considered better to use just the one language for sim +
RTL because then you're using just the one language. Although
currently I use two languages, one scripting language for various
hardware test scripts + fpga build, and then VHDL for testbenches and
RTL. If I'm able to script testbenches, then I'm still using two
languages. With MyHDL for example, then possibly it's one more step to
*really* only using one language.

My experiences with the Xilinx sim hasn't been the best in terms of
support for behavioural VHDL when I've used it in the past. Hmmmm...
if Xilinx sim supported Python...

Although Tcl is the scripting language I use mostly of late. I have
been investigating the possible use of scripting test benches with
Tcl, and I _think_ it should be possible to do things like the
following in Tcl (not with 8.4 though!)

bench UartTx {} {
  test sub UartTx_test {} {
    run * c
    run * bc
    reset
    run {set data $DATA; set wr 1; wait @clk; set wr 0}
    assert [getSerial] {0 $DATA 1}
  }

  sub getSerial {} {
      set t 8681 ; # 115200 baud
      wait @clk {!$ready}
      waitFor {$t / 2}; set start $serialOut
      set data 0
      repeat $BITS {
          waitFor $t
          set data [expr {($data << 1) | $serialOut}]
      }
      waitFor $t; set stop $serialOut
      return [list $start $data $stop]
    }

  sub c {} {set clk 0; wait 25; set clk 0; wait 25}
  sub bc {} {set baudClk 1; wait @clk; set baudClk 0; wait 173 @clk}
  sub reset {} {set rst 1; waitFor 100; wait @clk; set rst 0}
}

Then run the testbench a couple of times, something like:

foreach BITS {7 8} DATA {0x5a 0xa5} {
  verify -config {BITS $BITS} -const {DATA $DATA} UartTx
}

Tcl is pretty malleable, includes incrTcl OO in 8.6, but has the $,
expr, [] and # weirdness. I have _some_ of the above working but not
all. What I really need is a sim with Tcl 8.6. Or maybe a sim with
VHPI? I'll have to see if I beg, borrow or steal one. (;-) about the
last one, or two!).

Whatever the scripting language, I think it's good to at least have
the option of a reasonably succinct and expressive option for
scripting test benches.

On 13/04/2010 15:15, Chris Higgs wrote:
> On 13 Apr, 13:45, "cfelton"<cfelton@n_o_s_p_a_m.n_o_s_p_a_m.ieee.org>
> wrote:
>> I imagine what you posted works very well and accomplishes what you intend.
>>   I think for a new users adopting Python testbenches MyHDL would be a much
>> better choice.  I is documented, has a nice manual, there are examples
>> available, and a community to support questions.  The user doesn't need to
>> worry about HDL conversion if they do not want.  Here is a basic example of
>> a testbench in MyHDL.
> <snip>
>
> Agreed, I think MyHDL has a lot of potential and there is significant
> functionality overlap and similarities to the environment our company
> uses. What I'm lamenting is the reluctance of 'hardware engineers" to
> adopt advances made in the software field, in terms of regression and
> unit testing frameworks. More people should be using MyHDL or
> homegrown alternatives to provide rapid simulation verification and
> object oriented abstraction models. As a community we are very slow
> moving when compared to other related fields.
>
> I believe MyHDL would do well to emphasise more strongly the pure
> testbench environment functionality. Many engineers do not want the
> VHDL/verilog generation features but could make good use of the
> simulation parts of MyHDL. Expanding the cosimulation interface
> options to support ModelSim FLI and VHPI would help move it forward.
>

I disagree with that.

I haven't done much programmable logic design, and what I have done was 
a few years ago now, so I don't have anything like the experience of 
most people in this group (I work mainly with embedded software in C, 
and some PC software in Python).  However, I have made small systems 
with both VHDL and Verilog.

What I can say is that both Verilog and VHDL are very verbose, they both 
have a lot of features that are confusing and lead easily to wrong code 
or extra effort (for example, the difference between the different 
assignments in Verilog, or the different logic, bit, and numeric types 
in VHDL).  There also seems to be a very unclear boundary between 
synthesisable and non-synthesisable parts of the languages, and there 
can be inconsistencies between simulation and working synthesised behaviour.

When I used confluence, my results were far better.  It was simpler and 
clearer, and it handles the low-level Verilog or VHDL details 
automatically.  You can't accidentally end up with a latch or 
asynchronous logic in your state machines - in fact, it won't let you 
generate latches at all.  You don't have registers that are reset in 
simulation and preset in synthesis, because all the Verilog/VHDL 
registers are generated with explicit resets (or presets).  You don't 
have problems when mixing signed and unsigned values, because these are 
handled correctly.

I haven't used MyHDL for more than brief tests, but it appears to give a 
similar isolation from the messy low-level details of Verilog and VHDL, 
while (even more than confluence) it gives you higher level features. 
People often compare Verilog to "C", and VHDL to "Ada" - I think they 
both share a lot with assembly language.

I am also unconvinced of the value of Verilog or VHDL functional 
simulation (timing simulation is another matter, of course), if the code 
you have written is not in Verilog or VHDL in the first place.  If your 
code is written in MyHDL, and the MyHDL conversion to Verilog/VHDL is 
accurate, then you can do all your functional testing entirely within 
Python and MyHDL.  cosimulation is only relevant when you have parts 
that are not written in MyHDL (and cannot easily be modelled in MyHDL).

confluence "died" because the author was more interested in formal 
verification systems than synthesis (or testbenches).  While 
testbenching and integration with Verilog and VHDL simulators is 
important, I believe it is more important to have good tools that help 
you write correct code in the first place, rather than just to find the 
mistakes you've made.

As I say, I don't have the experience in programmable logic design of 
most people here.  That may mean my opinions here are pretty worthless - 
perhaps I'd be happy with Verilog and VHDL if I spend longer getting 
used to them.  But it may also mean that I can think about this without 
the bias of long established practice.

On Apr 14, 8:45=A0am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

> I am also unconvinced of the value of Verilog or VHDL functional
> simulation (timing simulation is another matter, of course), if the code
> you have written is not in Verilog or VHDL in the first place. =A0If your
> code is written in MyHDL, and the MyHDL conversion to Verilog/VHDL is
> accurate, then you can do all your functional testing entirely within
> Python and MyHDL. =A0cosimulation is only relevant when you have parts
> that are not written in MyHDL (and cannot easily be modelled in MyHDL).

In my experience (which again is limited), there are many engineers
who are happy writing synthesisable code in VHDL. They may find MyHDL
useful for to generate type/conversion packages (it would be nice to
have a union function to convert a record type to a vector and vica-
versa) but want to continue doing the majority of coding in raw VHDL.
I personally believe this comprises the majority of VHDL engineers
(otherwise takeup of tools like MyHDL would be far higher). For this
group having an easy way to interface to the simulator using a
language other than VHDL is the sweetspot which might persuade them to
try a different design flow. MyHDL is almost ready to fill that
space...

MyHDL is a promising language, but at this point, it is just that:
promising.

I can't go to my director and tell him I'm going to use a non-
commercially-supported language/toolset (VHDL/Verilog RTL converter at
this point) that is at version 0.6 for his next project, and expect to
still have respect, or even a job afterwards. I suspect the vast
majority of non-academic HDL professionals are in exactly the same
boat.

Call me back when it does synthesizable fixed/floating point and has
direct support from at least one major synthesis vendor. Sorry,
converting to VHDL/Verilog RTL to use with anyone's tool does not cut
it, unless the vendor supports the conversion process too.

Andy

>MyHDL is a promising language, but at this point, it is just that:
>promising.
>
>I can't go to my director and tell him I'm going to use a non-
>commercially-supported language/toolset (VHDL/Verilog RTL converter at
>this point) that is at version 0.6 for his next project, and expect to
>still have respect, or even a job afterwards. I suspect the vast
>majority of non-academic HDL professionals are in exactly the same
>boat.
>
>Call me back when it does synthesizable fixed/floating point and has
>direct support from at least one major synthesis vendor. Sorry,
>converting to VHDL/Verilog RTL to use with anyone's tool does not cut
>it, unless the vendor supports the conversion process too.
>
>Andy
>

Well, you will never get that call because that isn't the point/goal of
MyHDL.  But given this argument you would not be interested in using Python
in your flow (or any script language except TCL), whether it be for build
scripts, testbenches, generation of constants, etc.

I think the goal of MyHDL is to replace a bunch of tools in the developers
toobox with a unified tool, in this case a programming language.  Many
developers find themselves doing many tasks in a scripting languages, be it
Python, TCL, etc.  With Python and MyHDL all this can be done in a single
language, hopefully improving efficiency.

MyHDL adds *RTL* to Python.  The Python-RTL (MyHDL) is converted to
Verilog/VHDL.  There is no need or desire for direct support by a synthesis
vendor.  And MyHDL doesn't try to do higher level synthesis.  Higher
level-synthesis tools can be developed on top of MyHDL if desired.  MyHDL
has a focused goal which is to add *RTL* to Python, IMO makes it more
attactive.

I agree, any tool and/or method is easier to adopt if it has a track
record.  But I think the track record you are looking for might be a little
misdirected (ie some large EDA company adopting).  The goal of a company
should be to increase efficiency and ROI.  Tools like Python/MyHDL (and
other languages) provide this.  We outlined some of the possible risks and
risk mitigation methods.
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

On Apr 14, 6:43=A0pm, Andy <jonesa...@comcast.net> wrote:

>
> I can't go to my director and tell him I'm going to use a non-
> commercially-supported language/toolset (VHDL/Verilog RTL converter at
> this point) that is at version 0.6 for his next project, and expect to
> still have respect, or even a job afterwards. I suspect the vast
> majority of non-academic HDL professionals are in exactly the same
> boat.

MyHDL has good support for subversive behavior :-)

Seriously, that's why conversion to VHDL/Verilog gets so much
attention. It allows you to view MyHDL simply as a more effective
or fun way to create your trusted VHDL/Verilog design.

Therefore, no need to ask nor tell anyone. If you're intrigued,
just do it, and do it as a good engineer: start with a simple
but relevant module, not with a whole design. After conversion,
few will be able to tell (you may even get praise for the
code quality :-)).

Along the way, you may discover unique features that you want to
share with others, even with directors. You'll know when it's time
to come out.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
   Python as a HDL: http://www.myhdl.org
   VHDL development, the modern way: http://www.sigasi.com
   Analog design automation: http://www.mephisto-da.com
   World-class digital design: http://www.easics.com