myhdl-list — Mailing list for discussions on MyHDL

[myhdl-list] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

[myhdl-list] Re: Enhanced Simulation and Verilog Generation with the same generators?

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

Frank Palazzolo wrote:

[Sidenote: it seems you start new topics by replying in an existing thread,
which confuses the thread view. Would it be possible to start new topics
by a fresh new post instead - thanks.]

> Ok, on the heels of my success with the first design, I have something more
> ambitious I'd like to try.  However, I've run into the first problem.
> 
> I'd like to be able to take a design in MyHDL, Simulate it, and generate
> Verilog.  However, the simulation I have in mind has some additional
> functionality - I would like to programmatically track the state information
> in the system during the simulation.  Unfortunately, any way I try to
> introduce this code into the generators, I end up introducing a construct
> that breaks the Verilog-generation rules. :(
> 
> Essentially, I'd like to have code in my generators that is marked as "does
> not apply to Verlog generation". 

Before answering the above: note that Python print statements are converted
into Verilog $display functions and can thus be used for debugging purposes.

Excluding code under parameter control is indeed a useful feature, that is
currently not supported by the convertor. It shouldn't be hard to do, as the
convertor has the required info.

The way to do it would be to check test expressions on if statements
in the first step, and not proceeding with analysis or conversion of the
test body if the test happens to be a (global) name with value False.

The easiest would be to just leave the if-then-else structure intact,
so you would get something like this in Verilog:

   if (0) begin
       // code not converted here
   end
   else ...

This should be OK for synthesis tools - perhaps you could confirm
it's OK for yours and then I'll proceed with implementing this.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: inout signals and cosimulation

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

Terry Brown wrote:

> Well, I think that the utility of myhdl as a testbench tool (which is 
> primarily how I am intending to use it) is severely compromised if 
> delays are not allowed at all in the verilog code.  I use many vendor 
> models for things like SSRAM and SDRAM and so on which include delays, 
> and delays are included in most FPGA libraries as well and used in post 
> place and route verilog models produced by Xilinx and other FPGA 
> vendors.  Having to disable these to use myhdl is too much to ask.  And 
> although I don't use post place and route models for timing analysis 
> usually, I do use them for troubleshooting synthesis problems.  To have 
> to maintain a test bench in verilog to do this probably means I should 
> just do the whole thing in verilog.
> 
> Also, I guess I'm not quite clear on which delay might be ok and which 
> not and what you mean by the verilog running faster than myhdl.  Can you 
> clarify?

Yes. In the ideal case, cosimulation should be fully general and both
sides should allow arbitrary delays while staying in sync with each other.
For various reasons, I think this is hard to achieve. A compromise (which
I believe other HVLs use also) is to make one side the "master" of time,
where one simulator decides on when time advances for *both*. In case of
MyHDL, my choice was to make MyHDL the master in a cosimulation.

Now the question is: what restrictions does this imply? The brute-force
approach would be to simply disallow delays in the "slave" simulator.
This is how I currently have it in the documentation.
As you point out, this may be too strong, and in fact, by thinking further
about it, I conclude that it's not necessary to be that restrictive.

Suppose MyHDL is done at time t1 and its next event is at t2. As the
master, it will want to set time to t2 for the slave also before
continuing. But before that, the slave (also at t1) could perfectly
continue to simulate, with delays, if and only if:

1) it doesn't pass time t2 (because MyHDL's event would influence it at that time)
   This is what I meant with "the verilog running faster".
2) the signals that change with a delay don't influence the MyHDL simulation,
   that is, nothing is waiting for them. Note that such signals could
   perfectly be read and used at the MyHDL side - they just shouldn't be in 
   a MyHDL sensitivity list.

So it's not that bad I think. In fact, you could use cosimulation in this
mode with the current version. The only problem is that there is no run-time
check that checks whether you obey the rules - but in the future that should be
perfectly possible.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

RE: [myhdl-list] Enhanced Simulation and Verilog Generation with the same generators?

[Frank P. <pal...@co...>]

One other note...

I did try two other things.  I can use a global variable to hook in
simulation specific code:

Python code is like this in every generator:
--------------------------------------------

if simulating:
	state.next =3D Report(not state)
else:
	state.next =3D not state.

This turns into an "$if 0" in Verilog, but the Report function is still
expanded and required to be synthesizable.

Then, I tried this - which is the best I can do, using a function =
reference
veriable:
-------------------------------------------------------------------------=
---
---------

def NullFunc(state):
	return state

def ReportFunc(state):
	# some non-synthesizable stuff here
	return state

if simulating:
	Report =3D NullFunc
else:
	Report =3D ReportFunc
...
and then in the generator...
...
	state.next =3D Report(not state)

In this case, The Simulation-Specific version of Report is required to =
to
have a synthesizable signature, but the content of the function can be
whatever you want...because when you synthesize, it will be replaced =
with a
null function.  Almost perfect :)

-Frank

[myhdl-list] Enhanced Simulation and Verilog Generation with the same generators?

[Frank P. <pal...@co...>]

Ok, on the heels of my success with the first design, I have something =
more
ambitious I'd like to try.  However, I've run into the first problem.

I'd like to be able to take a design in MyHDL, Simulate it, and generate
Verilog.  However, the simulation I have in mind has some additional
functionality - I would like to programmatically track the state =
information
in the system during the simulation.  Unfortunately, any way I try to
introduce this code into the generators, I end up introducing a =
construct
that breaks the Verilog-generation rules. :(

Essentially, I'd like to have code in my generators that is marked as =
"does
not apply to Verlog generation".  Here are a couple examples:

    def toggle_ff(clk,q,q_n):
        while 1:
            yield posedge(clk)
            q.next =3D not q
            q_n.next =3D q
		# now report the state change to a global func
            Report(q.next)

I can't use this approach, as the toVerilog() chokes on the call to =
Report()

Here's an attempt to use object-oriented modelling:

class T:
    "Toggle Flip Flop"
    def __init__(self):
        self.state =3D Signal(0)
        self.count =3D 0
    def gen(self,clk,q,q_n):
        while 1:
            yield posedge(clk)
            q.next =3D not q
            q_n.next =3D q
		# log the state change
            self.state =3D q.next
            self.count +=3D 1

Again, the last two lines are fine for simulation, but Verilog =
generation
wont work.

I'm starting to think I need to try some kind of variation on =
conditional
instantiation, based on whether I am simulating or generating Verilog.  =
I
doubt I can do that with a single generator though, because the =
signatures
of the generators would be affected.  It would work if I had two =
versions of
each generator - one for this simulation and one for verilog.=20

Anyways... and all hints appreciated...

Thanks,
Frank

[myhdl-list] Tri-State Logic

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

> Hello,
> 
> Is there a way to represent tri-state logic in MyHDL?

There are two parts to this: first, representation of the tri-state
value, and second, how to model resolution of contributing drivers.

For representation, I believe (in good MyHDL tradition) that Python
has all we need, in that 'None' (no value) is perfectly adequate.

A little advertised feature of a Signal is that you can construct it
with a value None - this is even the default value. To such a Signal,
you can subsequently assign anything of any type - there is no
value type checking as in all other cases.

As to modelling resolution, I'm not inclined to built it into the
language as in Verilog or VHDL. In Verilog, the solution is to
introduce a vast number of keywords. In VHDL, it's done with
resolution functions - complicated and implicit. My thinking
is to support such things through a "standard library" that
models specific resultion behaviors explicitly in generators.

As as sidenote, and based on my ASIC design experience, I believe
tri-states should be avoided on-chip as they always cause all
kinds of tricky problems - normally there are better solutions.

For example, a tristate bus model could look as follows:

class ContentionError(Exception):
    pass

def TristateBus(bus, *drivers):
    """Generic tristate bus model."""
    while 1:
        yield drivers
        actives = [a for a in drivers if a != None]
        if len(actives) > 1:
            raise ContentionError("Multiple active bus activedrivers")
        elif len(actives) == 1:
            bus.next = actives[0]
        else:
            bus.next = None

Note that this works for any number of drivers, by using the fact
that sensitivity lists in MyHDL can be true Python lists - a unique and
very useful feature I believe.

> Also, would it carry-over to the generated Verilog?
> (Forgive me, I don't even know if/how this is done in vanilla 
> Verilog, only in VHDL)

Not at this point.

The way to do it would probably to generate an equivalent Verilog model
for each generator of the "standard library" (see above).

One complication is that for Verilog output, bit widths need to be
defined, but a Signal(None) has no defined bit width. Perhaps the
intbv class should accept 'None' values also - it doesn't do this
at this moment and I would need to think about it further to see
whether that's really a good idea.

> and finally...
> 
> If not, is it a reasonable feature request?

Yes :-)

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Tri-State Logic

[Frank P. <pal...@co...>]

Hello,

Is there a way to represent tri-state logic in MyHDL?

Also, would it carry-over to the generated Verilog?
(Forgive me, I don't even know if/how this is done in vanilla 
Verilog, only in VHDL)

and finally...

If not, is it a reasonable feature request?

Thanks,
Frank

Re: [myhdl-list] Re: MyHDL success

[bedros <be...@ya...>]

--- Jan Decaluwe <ja...@ja...> wrote:
> bedros wrote:
> > agree, Jan did a great job on MyHDL. I've been
> using
> > it for several months now to verify my ideas
> before
> > start coding in VHDL.
> 
> Excellent, that's exactly what MyHDL usage should be
> all
> about. Now, the VHDL coding, is that for synthesis?
> If
> it is, would Verilog (and therefore conversion from
> MyHDL
> code to Verilog) be an option instead?

my design would be integrated with other VHDL designs,
so I'll stay with VHDL for now. The design is fairly
complex and would be synthesised into FPGA. 

The reason I decided to build a complete model of the
project in MyHDL is to explore different
architectures. Python makes it easy to build data
structures with very little effort. 

I never tried trace.py. However, coverage.py is very
easy to use and gives a list of statements that are
not got executed. Helps a lot fine tuning my test
cases

-Bedros

> > I also got it to work with code coverage utility
> > (coverage.py)
> 
> Good to hear. Does this work better than trace.py?
> I haven't use any of the two, but I noticed that
> trace.py
> is a standard (though undocumented) unlibrary
> module.
> 
> Regards, Jan
> 
> -- 
> Jan Decaluwe - Resources bvba -
> http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware
> with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

Re: [myhdl-list] Re: MyHDL success

[<ma...@cr...>]

Hello Jan, Frank, and MyHDL frieds,

Comments in Verilog are needed to embed physical design constraints into a
design, such as for FPGA realization with high performance; these are called
metacomments.

I do this now, using Python code to create computer generated designs which have
everything locked down and placed as structural Verilog, essentially "linked" to
a Virtex-II or Virtex-II Pro primitives library.

Now, having said all this, there is also a new standard representation for
constraints and attributes in Verilog, without the metacomment scheme. Icarus
Verilog uses this today now, as does several other synthesis tools. It looks
something like this:
(* RLOC_ORIGIN = X0Y0 *)

I personally do not like this style of compiler hinting for synthesis, but Steve
Williams (who maintains Icarus) assures me this is much better for everyone. My
issue is that I think comments are more useful as they're passively inferred,
without disturbing the semantics of the appertaining Verilog -- only the
implementation is effected for synthesis or possibly simulation. I thoroughly
dislike the introduction of new syntax to an already "large" language like
Verilog. Steve indicates however, that determinating scope and other aspects of
inference is much easier on the compiler with the new-style attributes. These
form of attributes are admitedly much more standard, which dramatically
contrasts with the metacomment scheme, which are all over the map across
different tools. 

In any case, I now use Python to generate very large Verilog designs, via
structural code and other performance-oriented constraints, etc. It would indeed
be rather important for MyHDL to have the ability to embed attributes,
preferrably as both comments and new-style attributes. That way, MyHDL could be
used for generation and verification of physical designs that use Verilog as the
carrier language for access to physical synthesis tools or for co-simulation.

One other question that may arise in this context: Why bundle everything into
the Verilog? Can't a constraints "side-file" be used for synthesis, and just
ignored for simulation? 

This is generally true. For example, for the Xilinx implementation tools, user
contraints are entered with a UCF "side-file." 

However, a reason NOT to do this is if you're trying to create a completely
self-contained or encapsulated design for subsequent use by another designer;
e.g. creating a core. The existence of a "side-file" implies it's continued use
with additional synthesis users, and this gets out of hand quickly, esp. if
numerous instances of the same core are used in a particular implementation.
Having everything self-contained is necessary.

MyHDL would be more valuable IMHO if the power of Python can also be applied to
generation of physical constraints, so that constraint generation can also be
included within the full verification flow that MyHDL otherwise allows.

Best,
Michael

> Frank Palazzolo wrote:
> > Jan,
> > 
> > Just wanted to drop a line and say that MyHDL is working great for me!  I'm
> > doing a CPLD design for a switching power-supply controller, and I just got
> > both the simulation and verilog generation working flawlessly.  I'm
> > targetting the Xilinx XC9536, but testing with a Xilinx SpartanIIE-based
> > FPGA board.
> 
> Good to hear. Looks like you're the first one I know of to finish a complete
> design to implementation with MyHDL. If you would be interested in writing a
> small success story (to put on a website, or post to a newsgroup), let me know.
> 
> > I only ran into one wishlist item.  It might be nice to have a mechanism to
> > put comments into the generated verilog via python.  At first, I thought
> > that could mean simply reading the doc information from the generators and
> > adding that as comments in the verilog.  But, with some of the naming
> > changes that occur, that might be confusing.  You might want to have some
> > kind of dedicated verilog_comment() construct instead.
> 
> Could you comment on exactly what would be the purpose? I see the Verilog
> code merely as a back-end format, not necessarily friendly to human readers.
> Is it just to recognize where the code came from? Rewriting the doc-string
> should be easy.
> 
> Regards, Jan
> 
> -- 
> Jan Decaluwe - Resources bvba - http://jandecaluwe.com
> Losbergenlaan 16, B-3010 Leuven, Belgium
>     Python is fun, and now you can design hardware with it:
>     http://jandecaluwe.com/Tools/MyHDL/Overview.html
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 

[myhdl-list] Re: MyHDL success

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

Frank Palazzolo wrote:

> Oh one other thing...I'm curious where the name MyHDL came from.  It seems
> there are some academic references to something called PyHDL, which I would
> imagine would be the more natural name.  It seems like every Python project
> starts with Py these days...

The 'Py' prefix is too obvious for my taste, to the point where I wasn't even
aware of 'PyHDL' before you mentioned it. PyHDL indeed seems an academic effort,
I didn't find any docs or software to download.

MyHDL originates from my dissatisfaction with current HDL and HVL languages,
that don't provide the ease of use and high abstraction level of a "scripting"
language such as Python. It's my response to the question: "How would my
favourite HDL look like?"

I considered a number of names. One day my attention was caught by a reference
to the MySQL database, and this inspired me: I thought that MyHDL would be
an appriopriate name for my efforts. I hesitated because it sounded egocentric,
but then figured that this was compensated for by going open-source: it can be
YourHDL too, as soon as you decide to use or even change it :-)

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

RE: [myhdl-list] Re: MyHDL success

[Frank P. <pal...@co...>]

>Could you comment on exactly what would be the purpose? I see the =
Verilog
code merely as a back-end format, not necessarily friendly to uman =
readers.
Is it just to recognize where the code came from? Rewriting the =
doc-string
should be easy.

Right, my design was small enough that it was obvious how the MyHDL =
mapped
over to the Verilog.  I just thought that if the design was bigger, it =
would
be useful for tracking/debug purposes.  Also, I can envision a project =
which
uses MyHDL-generated Verilog, along with other Verilog or VHDL code from
other sources.  Documenting the interface to the MyHDL-generated Verilog
would probably be most useful in the actual Verilog in this case.

Hmmm...if rewriting the doc-string would be easy, maybe there should =
just be
an option to do that during verilog generation.  This would be =
sufficient, I
think.

I'll let you know about the success-story writeup as soon as I get the =
full
system working :)

Oh one other thing...I'm curious where the name MyHDL came from.  It =
seems
there are some academic references to something called PyHDL, which I =
would
imagine would be the more natural name.  It seems like every Python =
project
starts with Py these days...

Thanks,
Frank

Re: [myhdl-list] Re: MyHDL success

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

Jan,

As far as VHDL goes, for us conversion would be fine. We would only use 
it for delivery to clients so they could synthesize and simulate the design.

Thanks, Tom


Jan Decaluwe wrote:

> bedros wrote:
>
>> agree, Jan did a great job on MyHDL. I've been using
>> it for several months now to verify my ideas before
>> start coding in VHDL.
>
>
> Excellent, that's exactly what MyHDL usage should be all
> about. Now, the VHDL coding, is that for synthesis? If
> it is, would Verilog (and therefore conversion from MyHDL
> code to Verilog) be an option instead?
>
>> I also got it to work with code coverage utility
>> (coverage.py)
>
>
> Good to hear. Does this work better than trace.py?
> I haven't use any of the two, but I noticed that trace.py
> is a standard (though undocumented) unlibrary module.
>
> Regards, Jan
>

[myhdl-list] Re: MyHDL success

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

bedros wrote:
> agree, Jan did a great job on MyHDL. I've been using
> it for several months now to verify my ideas before
> start coding in VHDL.

Excellent, that's exactly what MyHDL usage should be all
about. Now, the VHDL coding, is that for synthesis? If
it is, would Verilog (and therefore conversion from MyHDL
code to Verilog) be an option instead?

> I also got it to work with code coverage utility
> (coverage.py)

Good to hear. Does this work better than trace.py?
I haven't use any of the two, but I noticed that trace.py
is a standard (though undocumented) unlibrary module.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: MyHDL success

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

Frank Palazzolo wrote:
> Jan,
> 
> Just wanted to drop a line and say that MyHDL is working great for me!  I'm
> doing a CPLD design for a switching power-supply controller, and I just got
> both the simulation and verilog generation working flawlessly.  I'm
> targetting the Xilinx XC9536, but testing with a Xilinx SpartanIIE-based
> FPGA board.

Good to hear. Looks like you're the first one I know of to finish a complete
design to implementation with MyHDL. If you would be interested in writing a
small success story (to put on a website, or post to a newsgroup), let me know.

> I only ran into one wishlist item.  It might be nice to have a mechanism to
> put comments into the generated verilog via python.  At first, I thought
> that could mean simply reading the doc information from the generators and
> adding that as comments in the verilog.  But, with some of the naming
> changes that occur, that might be confusing.  You might want to have some
> kind of dedicated verilog_comment() construct instead.

Could you comment on exactly what would be the purpose? I see the Verilog
code merely as a back-end format, not necessarily friendly to human readers.
Is it just to recognize where the code came from? Rewriting the doc-string
should be easy.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: MyHDL success

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

Frank Palazzolo wrote:
> Jan,
> 
> Just wanted to drop a line and say that MyHDL is working great for me!  I'm
> doing a CPLD design for a switching power-supply controller, and I just got
> both the simulation and verilog generation working flawlessly.  I'm
> targetting the Xilinx XC9536, but testing with a Xilinx SpartanIIE-based
> FPGA board.

Good to hear. Looks like you're the first one I know of to finish a complete
design to implementation with MyHDL. If you would be interested in writing a
small success story (to put on a website, or post to a newsgroup), let me know.

> I only ran into one wishlist item.  It might be nice to have a mechanism to
> put comments into the generated verilog via python.  At first, I thought
> that could mean simply reading the doc information from the generators and
> adding that as comments in the verilog.  But, with some of the naming
> changes that occur, that might be confusing.  You might want to have some
> kind of dedicated verilog_comment() construct instead.

Could you comment on exactly what would be the purpose? I see the Verilog
code merely as a back-end format, not necessarily friendly to human readers.
Is it just to recognize where the code came from? Rewriting the doc-string
should be easy.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] MyHDL success

[bedros <be...@ya...>]

agree, Jan did a great job on MyHDL. I've been using
it for several months now to verify my ideas before
start coding in VHDL.

I also got it to work with code coverage utility
(coverage.py)

if you need wave viewer, try GTKwave. They got
binaries for linux and windows. you can get it from
freshmeat.net or the windows bin here
http://www.geocities.com/SiliconValley/Campus/3216/GTKWave/gtkwave-win32.html



--- Frank Palazzolo <pal...@co...> wrote:
> 
> Jan,
> 
> Just wanted to drop a line and say that MyHDL is
> working great for me!  I'm
> doing a CPLD design for a switching power-supply
> controller, and I just got
> both the simulation and verilog generation working
> flawlessly.  I'm
> targetting the Xilinx XC9536, but testing with a
> Xilinx SpartanIIE-based
> FPGA board.
> 
> I only ran into one wishlist item.  It might be nice
> to have a mechanism to
> put comments into the generated verilog via python. 
> At first, I thought
> that could mean simply reading the doc information
> from the generators and
> adding that as comments in the verilog.  But, with
> some of the naming
> changes that occur, that might be confusing.  You
> might want to have some
> kind of dedicated verilog_comment() construct
> instead.
> 
> At any rate, you really can design and simulate
> hardware with Python!
> Thanks for a fantastic tool! :)
> 
> -Frank
> 
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux
> Tutorials
> Free Linux tutorial presented by Daniel Robbins,
> President and CEO of
> GenToo technologies. Learn everything from
> fundamentals to system
>
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] MyHDL success

[Frank P. <pal...@co...>]

Jan,

Just wanted to drop a line and say that MyHDL is working great for me!  I'm
doing a CPLD design for a switching power-supply controller, and I just got
both the simulation and verilog generation working flawlessly.  I'm
targetting the Xilinx XC9536, but testing with a Xilinx SpartanIIE-based
FPGA board.

I only ran into one wishlist item.  It might be nice to have a mechanism to
put comments into the generated verilog via python.  At first, I thought
that could mean simply reading the doc information from the generators and
adding that as comments in the verilog.  But, with some of the naming
changes that occur, that might be confusing.  You might want to have some
kind of dedicated verilog_comment() construct instead.

At any rate, you really can design and simulate hardware with Python!
Thanks for a fantastic tool! :)

-Frank

[myhdl-list] Re: inout signals and cosimulation

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

Jan Decaluwe wrote:
> Terry Brown wrote:

>> Would you be willing to provide a bug report on Cver?  I can do it, 
>> but since it is myhdl that stimulates the problem, I don't really know 
>> much about it.
> 
> Yes, but in that case I'd prefer to work on it further to narrow the
> problem down and see if I can find more info (in the source for example).

This has been fun. When trying to nail down the issue with a small
example (without myhdl), I couldn't get it to fail. Then I went back to
the original code and tried all kind of changes, but still couldn't get
it to work. My final (desperate) move was to remove the $dumpvars call.
Suddenly the events appeared at the MyHDL side!

So the bug is clearly with cver, in that a $dumpvars call changes
the behavior of value change callbacks on wires. I've reproduced
this in my small example and will file a bug report.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

Re: [myhdl-list] Re: inout signals and cosimulation

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

Terry Brown wrote:

> Fascinating result.  Apparently the problem is in the PLI stuff for 
> cver, since the actual simulation does trigger and shows all expected 
> changes to pp_db_fromsim.

Correct.

> Would you be willing to provide a bug report on Cver?  I can do it, but 
> since it is myhdl that stimulates the problem, I don't really know much 
> about it.

Yes, but in that case I'd prefer to work on it further to narrow the
problem down and see if I can find more info (in the source for example).
Just dumping the database and expecting them to install myhdl for this
is probably not going to be very succesful. So this will take some time.
Is there a good bug tracking system for cver and are they responsive?

In the mean time, I hope you can confirm that the workaround works for
you. (Anyway "explicit is better then implicit" - the Zen of Python :-))

> It's interesting that you get iverilog to work on this.  Could you post 
> the commandline you used for the CoSimulation?  I had been unable to 
> build iverilog for some time under Cygwin, but recently built the 
> verilog-20040220 snapshot.  Although it builds and installs without 
> error, when I run it it either coredumps or complains that it can't find 
> the configuration file, then doesn't accept the -C argument listed in 
> the man page to solve this.  Previous times I have tried Icarus, I have 
> found it unable to compile my designs, primarily because of Xilinx 
> library problems.

As I'm on Linux, I used a different commandline for cver also:

cosim = Cosimulation("cver +loadvpi=./myhdl_vpi:vpi_compat_bootstrap -f manifest ",**globals())

For Icarus (snapshot 20031009), I used:

cmd = "iverilog -o g2board -c manifest"
os.system(cmd)
cosim = Cosimulation("vvp -m ./myhdl.vpi g2board", **globals())

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: inout signals and cosimulation

[Terry B. <tt...@ve...>]

Jan Decaluwe wrote:
> Terry Brown wrote:
> 
>> Well, it does describe the problem, but I don't think the delay you 
>> refer to is the problem.  This delay was added in an attempt to define 
>> and understand the problem.  I wanted to move the position of the 
>> signal around to be sure I was sampling at the right time with the 
>> print statement.  The problem originated with this delay present.  
>> And, although I understand this problem is with myhdl, is there any 
>> difference in behavior with cver as opposed to icarus?  I am using cver.
>>
>> For what it's worth, using that delay does indeed move the signal as 
>> expected but I still don't see it in myhdl.
>>
>> I also had tried sampling the signal within myhdl at the negative edge 
>> of clock and had no luck.
>>
>> I removed the delay and also removed a ram model which contained 
>> delays from the verilog simulation and I still get the same 
>> problem--the signal doesn't make it across the interface
> 
> 
> Terry:
> 
> I used the code you sent me privately and I think I found the culprit, by
> using an alternative Verilog description and also trying it with Icarus.
> In short, Icarus always does what I expect but cver does not.
> 
> Where you had:
> 
> wire [31:0] pp_db_fromsim;
> assign pp_db_fromsim = (pp_oe) ? 32'hbadda000 : pp_db;
> 
> I also tried the supposedly equivalent (but more explicit):
> 
> reg [31:0] pp_db_fromsim;
> always @(pp_oe or pp_db)
>    pp_db_fromsim = (pp_oe) ? 32'hbadda000 : pp_db;
> 
> As you noticed, pp_db_fromsim doesn't trigger in MyHDL with the first case
> and cver. However, with the second case, it does. With Icarus, it triggers
> with the 2 cases, with identical output.
> 
> At this point, I would conclude that the bug is with cver in that it
> gets the first case wrong. I don't know whether it's because of the
> wire (this would be surprizing) or because of the assign (this also).
> But you never know with the PLI, quite literally.
> 
> Regards, Jan
> 

Fascinating result.  Apparently the problem is in the PLI stuff for 
cver, since the actual simulation does trigger and shows all expected 
changes to pp_db_fromsim.

Would you be willing to provide a bug report on Cver?  I can do it, but 
since it is myhdl that stimulates the problem, I don't really know much 
about it.

It's interesting that you get iverilog to work on this.  Could you post 
the commandline you used for the CoSimulation?  I had been unable to 
build iverilog for some time under Cygwin, but recently built the 
verilog-20040220 snapshot.  Although it builds and installs without 
error, when I run it it either coredumps or complains that it can't find 
the configuration file, then doesn't accept the -C argument listed in 
the man page to solve this.  Previous times I have tried Icarus, I have 
found it unable to compile my designs, primarily because of Xilinx 
library problems.

I have yet to find anything Cver doesn't handle (except this :)

Thanks for the help

Terry

[myhdl-list] Re: inout signals and cosimulation

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

Terry Brown wrote:

> Well, it does describe the problem, but I don't think the delay you 
> refer to is the problem.  This delay was added in an attempt to define 
> and understand the problem.  I wanted to move the position of the signal 
> around to be sure I was sampling at the right time with the print 
> statement.  The problem originated with this delay present.  And, 
> although I understand this problem is with myhdl, is there any 
> difference in behavior with cver as opposed to icarus?  I am using cver.
> 
> For what it's worth, using that delay does indeed move the signal as 
> expected but I still don't see it in myhdl.
> 
> I also had tried sampling the signal within myhdl at the negative edge 
> of clock and had no luck.
> 
> I removed the delay and also removed a ram model which contained delays 
> from the verilog simulation and I still get the same problem--the signal 
> doesn't make it across the interface

Terry:

I used the code you sent me privately and I think I found the culprit, by
using an alternative Verilog description and also trying it with Icarus.
In short, Icarus always does what I expect but cver does not.

Where you had:

wire [31:0] pp_db_fromsim;
assign pp_db_fromsim = (pp_oe) ? 32'hbadda000 : pp_db;

I also tried the supposedly equivalent (but more explicit):

reg [31:0] pp_db_fromsim;
always @(pp_oe or pp_db)
    pp_db_fromsim = (pp_oe) ? 32'hbadda000 : pp_db;

As you noticed, pp_db_fromsim doesn't trigger in MyHDL with the first case
and cver. However, with the second case, it does. With Icarus, it triggers
with the 2 cases, with identical output.

At this point, I would conclude that the bug is with cver in that it
gets the first case wrong. I don't know whether it's because of the
wire (this would be surprizing) or because of the assign (this also).
But you never know with the PLI, quite literally.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: inout signals and cosimulation

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

Terry Brown wrote:

> Well, it does describe the problem, but I don't think the delay you 
> refer to is the problem.  This delay was added in an attempt to define 
> and understand the problem.  I wanted to move the position of the signal 
> around to be sure I was sampling at the right time with the print 
> statement.  The problem originated with this delay present.  And, 
> although I understand this problem is with myhdl, is there any 
> difference in behavior with cver as opposed to icarus?  I am using cver.
> 

Terry:

Would it be possible to send me the (relevant part of the) source
code - at this point I would need that to understand the cause of
the problem.

Thanks - Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: inout signals and cosimulation

[Terry B. <tt...@ve...>]

Jan Decaluwe wrote:
> Terry Brown wrote:
> 

> 
> Looking through the code, I think the difference is the delay in the 
> Verilog
> code - probably you have run into a cosimulation restriction.
> 
> Please read the section "Restrictions" in the chapter on cosimulation
> in the manual. It describes some background on the difficulties of PLI
> programming and the resulting compromise. Here is a relevant quote:
> 
> """
> As explained before, co-simulated Verilog should not contain delay
> statements. Ideally, there should be a run-time check to flag
> non-compliant code. However, there is currently no such check in the
> Icarus module.
> 
> The check can be written using the \code{cbNextSimTime} VPI callback
> in Verilog. However, Icarus 0.7 doesn't support this callback. In the
> meantime, support for it has been added to the Icarus development
> branch.  When Icarus 0.8 is released, a check will be added.
> 
> In the mean time, just don't do this. It may appear to ``work'' but it
> really won't as events will be missed over the co-simulation
> interface.
> """
> 
> This seems to describe the problem that you are facing.

Well, it does describe the problem, but I don't think the delay you 
refer to is the problem.  This delay was added in an attempt to define 
and understand the problem.  I wanted to move the position of the signal 
around to be sure I was sampling at the right time with the print 
statement.  The problem originated with this delay present.  And, 
although I understand this problem is with myhdl, is there any 
difference in behavior with cver as opposed to icarus?  I am using cver.

For what it's worth, using that delay does indeed move the signal as 
expected but I still don't see it in myhdl.

I also had tried sampling the signal within myhdl at the negative edge 
of clock and had no luck.

I removed the delay and also removed a ram model which contained delays 
from the verilog simulation and I still get the same problem--the signal 
doesn't make it across the interface

> It's of course disturbing that the run-time check isn't there and I
> will see if I can add it. However, your example got me thinking:
> while it may be reasonable to disallow delays over the cosimulation
> interface, it may be too severe to disallow them at all in the
> Verilog - as long as Verilog doesn't run "faster" than the MyHDL side.
> In that case, you could still have delayed signals internally.
> What do you think?

Well, I think that the utility of myhdl as a testbench tool (which is 
primarily how I am intending to use it) is severely compromised if 
delays are not allowed at all in the verilog code.  I use many vendor 
models for things like SSRAM and SDRAM and so on which include delays, 
and delays are included in most FPGA libraries as well and used in post 
place and route verilog models produced by Xilinx and other FPGA 
vendors.  Having to disable these to use myhdl is too much to ask.  And 
although I don't use post place and route models for timing analysis 
usually, I do use them for troubleshooting synthesis problems.  To have 
to maintain a test bench in verilog to do this probably means I should 
just do the whole thing in verilog.

Also, I guess I'm not quite clear on which delay might be ok and which 
not and what you mean by the verilog running faster than myhdl.  Can you 
clarify?

Thanks,

Terry
> 
> Regards, Jan
> 

[myhdl-list] Re: Conversion to VHDL in plan?

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

Guenter Dannoritzer wrote:
> Hello Jan,
> 
> I was wondering whether you plan to add a conversion of MyHDL code to 
> VHDL, similar to the Verilog conversion?

Short answer: I would like to support VHDL (cosimulation, conversion)
but I have currently no plans to work on it myself.

Sponsored interest might change my priorities. Here are my other
considerations on this issue.

First, there is the practical problem of not having an "Icarus VHDL",
that is, a free or open-source VHDL simulator with PLI support that
runs under Linux. Before doing conversion, we first need cosimulation
for verfication.

Secondly, my main goal with conversion to Verilog is to have a path
to implementation. Verilog is used as a back-end language, that many
other EDA tools understand - even in organizations where front-end
design is done with VHDL. My principal goal with conversion is to lower
the threshold to do complete designs in MyHDL.

Finally, the existing Verilog conversion shows that "it can be done".
For me personally as a challenge, and for MyHDL, I believe I can
better work on other things, such as: "real" design work, more
HVL features, performance. In addition, adding VHDL support would be
an ideal entry point for other open-source developers, as the existing
implementation provides a clear spec and a working example.

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html

[myhdl-list] Re: inout signals and cosimulation

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

Terry Brown wrote:
> Hello?  I hope someone is listening :)

Sure (and thanks for using the mailing list!)

> I don't understand what is different.  Any suggestions?  I can provide 
> complete code if anyone is interested.

Looking through the code, I think the difference is the delay in the Verilog
code - probably you have run into a cosimulation restriction.

Please read the section "Restrictions" in the chapter on cosimulation
in the manual. It describes some background on the difficulties of PLI
programming and the resulting compromise. Here is a relevant quote:

"""
As explained before, co-simulated Verilog should not contain delay
statements. Ideally, there should be a run-time check to flag
non-compliant code. However, there is currently no such check in the
Icarus module.

The check can be written using the \code{cbNextSimTime} VPI callback
in Verilog. However, Icarus 0.7 doesn't support this callback. In the
meantime, support for it has been added to the Icarus development
branch.  When Icarus 0.8 is released, a check will be added.

In the mean time, just don't do this. It may appear to ``work'' but it
really won't as events will be missed over the co-simulation
interface.
"""

This seems to describe the problem that you are facing.
It's of course disturbing that the run-time check isn't there and I
will see if I can add it. However, your example got me thinking:
while it may be reasonable to disallow delays over the cosimulation
interface, it may be too severe to disallow them at all in the
Verilog - as long as Verilog doesn't run "faster" than the MyHDL side.
In that case, you could still have delayed signals internally.
What do you think?

Regards, Jan

-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Python is fun, and now you can design hardware with it:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html