myhdl-list — Mailing list for discussions on MyHDL

[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

[myhdl-list] Conversion to VHDL in plan?

[Guenter D. <dan...@we...>]

Hello Jan,

I was wondering whether you plan to add a conversion of MyHDL code to 
VHDL, similar to the Verilog conversion?

Thanks

Guenter

[myhdl-list] Re: mydhl and cver interactive

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

Terry Brown wrote:
> I have been using myhdl with the cver simulator all running under 
> cygwin.  It would be really cool to be able to access the interactive 
> debugger with cver from python code.
> 
> Briefly, I would like to be able to use sim.run(time) to run the 
> simulator for a time (I can do this now), then poke about within the 
> verilog simulation using cver interactive, then run again from Python.
> 
> Currently, I can drop into cver interactive only when a $stop is 
> executed within the verilog code, and once I am in cver interactive a 
> $finish must be executed before I return to the python code.
> 
> I have built a little interactive monitor for my simulation using the 
> cmd module from Python, and this is nice, but I want to be able to send 
> commands to cver interactive and read the responses from with Python.  I 
> played a bit with using popen2 to run cver, but cver behaves quite 
> differently when connected to a pipe rather than "real" stdin (i.e. 
> tty), and I didn't have a lot of success.
> 
> Anybody have an idea if this is a huge amount of work, or not so big if 
> I only knew what I was doing??

Terry:

Personally, I have no idea on this one - no experience with cver
nor its interactive mode.

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: mydhl and cver interactive

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

Terry Brown wrote:
> I have been using myhdl with the cver simulator all running under 
> cygwin.  It would be really cool to be able to access the interactive 
> debugger with cver from python code.
> 
> Briefly, I would like to be able to use sim.run(time) to run the 
> simulator for a time (I can do this now), then poke about within the 
> verilog simulation using cver interactive, then run again from Python.
> 
> Currently, I can drop into cver interactive only when a $stop is 
> executed within the verilog code, and once I am in cver interactive a 
> $finish must be executed before I return to the python code.
> 
> I have built a little interactive monitor for my simulation using the 
> cmd module from Python, and this is nice, but I want to be able to send 
> commands to cver interactive and read the responses from with Python.  I 
> played a bit with using popen2 to run cver, but cver behaves quite 
> differently when connected to a pipe rather than "real" stdin (i.e. 
> tty), and I didn't have a lot of success.
> 
> Anybody have an idea if this is a huge amount of work, or not so big if 
> I only knew what I was doing??
> 
> Thanks for the help.
> 
> Terry Brown
> Tyzx, Inc.
> 
> 
> 
> -------------------------------------------------------
> 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


-- 
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] inout signals and cosimulation

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

Hello?  I hope someone is listening :)

I am using myhdl to provide stimulus to a verilog design that has a 
bidirectional data bus and I am having trouble understanding why myhdl 
is not seeing variable changes within the verilog simulation.

In the verilog testbench, I have done this:

wire [31:0] pp_db;
reg [31:0] pp_db_tosim;
wire [31:0] pp_db_fromsim;
assign #10 pp_db_fromsim = (pp_oe) ? 32'hbadda000 : pp_db;
reg pp_drv;
assign pp_db = (pp_drv) ? pp_db_tosim : 32'hzzzzzzzz;

initial
begin
     $from_myhdl(pp_bus_clk,pp_reset, pp_adr, pp_db_tosim, pp_cs, pp_rw, 
pp_oe, pp_blast, pp_wbe, pp_we, pp_drv);
     $to_myhdl(pp_db_fromsim, pp_db);
     $dumpvars;
end

There is, additionally, a module in the verilog design that drives the 
pp_db with a value on a read.  So, when a read is active (pp_oe is 0) 
pp_db_fromsim is assigned the pp_db value that is driven from within the 
module responding to the read.

In g2test.py, I do the following:

pp_db = Signal(intbv(0))
pp_db_fromsim = Signal(intbv(0))
pp_db_tosim = Signal(0)
print "read_ppc address: %x; data: %s; time: %d" % 
(address,pp_db_fromsim[15:0],now())
print "read_ppc address: %x; db: %s; time: %d" % (address,hex(pp_db),now())

(line wrap may make the print statements look funny, but they work.)


After simulating using myhdl to provide the stimulus, I get what I 
expect when I view the resulting vcd file with a waveform viewer. 
pp_db_fromsim changes values when the read occurs, delayed by 10 ticks 
from the change to pp_db.

the problem is that the print statements don't show any changes to 
pp_db_fromsim, although they do show the changes to pp_db.  How come?  I 
put in a yield pp_db_fromsim to catch any changes to that variable, but 
it never triggers.  Other yield statements like this do trigger.

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

Terry Brown

[myhdl-list] mydhl and cver interactive

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

I have been using myhdl with the cver simulator all running under 
cygwin.  It would be really cool to be able to access the interactive 
debugger with cver from python code.

Briefly, I would like to be able to use sim.run(time) to run the 
simulator for a time (I can do this now), then poke about within the 
verilog simulation using cver interactive, then run again from Python.

Currently, I can drop into cver interactive only when a $stop is 
executed within the verilog code, and once I am in cver interactive a 
$finish must be executed before I return to the python code.

I have built a little interactive monitor for my simulation using the 
cmd module from Python, and this is nice, but I want to be able to send 
commands to cver interactive and read the responses from with Python.  I 
played a bit with using popen2 to run cver, but cver behaves quite 
differently when connected to a pipe rather than "real" stdin (i.e. 
tty), and I didn't have a lot of success.

Anybody have an idea if this is a huge amount of work, or not so big if 
I only knew what I was doing??

Thanks for the help.

Terry Brown
Tyzx, Inc.

[myhdl-list] Re: Cosimulation signal name definitions

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

Terry Brown wrote:
>  From an email conversation, Jan Decaluwe wrote:
> 
>  >- Often the signal names in myhdl and Verilog will be the same. You
>  >can save some typing by letting the Cosimulation class do the lookup
>  >in some predefined dictionary such as globals() or locals(), e.g.:
>  >
>  >cosim = Cosimulation("cver -q 
> +loadvpi=../myhdl.so:vpi_compat_bootstrap  >tb.v matrix3x3.v", **globals())
>  >
> 
> 
> I don't know Python well enough to understand this.  I built a 
> dictionary globals, but the reference to **globals() doesn't work.  Is 
> globals in this case a function that returns a string which is the 
> contents of the dictionary?

You shouldn't define 'globals' (or 'locals'), it's a predefined
function that returns the global (or local) namespace as a dictionary.
'globals' refers to a module-level namespace, 'locals' to the namespace
inside a function.

Here's the background. An issue with cosimulation is that the signals
at the Verilog side need to mapped to the other side. MyHDL solves this
by using keyword arguments in the Cosimulation constructor. Each keyword
refers to a Verilog signal name, and the argument is the MyHDL signal.
To support arbitrary Verilog names, the constructor parameter list
looks as follows:

class Cosimulation(object):
    def __init__(self, exe="", **kwargs):
        ....

The constructor sets up communication with the Verilog simulator, and
receives the names of the participating Verilog signals (regs) from
the $from_myhdl and $to_myhdl calls. It looks up each name in the
kwargs dictionary to find the matching MyHDL signal.

Conversely, it is possible to *call* the constructor using a dictionary
instead of a number of keyword arguments, using the ** syntax in the
call (this is just a Python feature). Therefore, when you use the same
signal names in MyHDL as in Verilog (which is advisable), then you
can use the predefined globals() or locals() dictionary in the call
and let the Cosimulation constructor find the signals.

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] Cosimulation signal name definitions

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

 From an email conversation, Jan Decaluwe wrote:

 >- Often the signal names in myhdl and Verilog will be the same. You
 >can save some typing by letting the Cosimulation class do the lookup
 >in some predefined dictionary such as globals() or locals(), e.g.:
 >
 >cosim = Cosimulation("cver -q 
+loadvpi=../myhdl.so:vpi_compat_bootstrap  >tb.v matrix3x3.v", **globals())
 >


I don't know Python well enough to understand this.  I built a 
dictionary globals, but the reference to **globals() doesn't work.  Is 
globals in this case a function that returns a string which is the 
contents of the dictionary?

Terry Brown

[myhdl-list] Re: Icarus Verilog and MyHDL

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

Vijay Kumar wrote:
> Hi,
> I would like to use MyHDL for co simulation with Icarus Verilog. But the test 
> programs are not getting simulated. The assertion (verilog_time & 0xFFFF.. == 
> myhdl... * 1000 + delta) (Ok, that is approx what the assertion is. But I guess 
> you can understand which one it is.) is failing.
> 
> I understand what is happening(I read the docs for co simulation with Icarus 
> verilog) but I do not know what to do! Like I said even the test programs that 
> came with MyHDL fail to co-simulate.
> 
> Please help me.

Let's try. I *suspect* that this relates to the issue
mentioned in the cosimulation/icarus/README.txt file,
repeated here:

"""
Between snapshot 20030518 (used in MyHDL 0.3), and 20031009, the
Icarus scheduler has been improved. This requires a small update
of myhdl.c. The current version is supposed to work with recent
snapshots - the older version is available in myhdl.c.20030518.
"""

In other words, make sure you use a version of myhdl.c which is
compatible with your Icarus. I would advise you to use a recent
Icarus snapshot and myhdl 0.4; those should work together
(although I don't check all Icarus snapshots).

In my development I just added cosimulation support for Cver;
this worked with the latest myhdl.c almost unchanged. This
suggests that the scheduling as done in more recent Icarus snapshots
is indeed the better way.

I noticed a flaw of mine: the file myhdl.c.20030518 is not
in the MyHDL 0.4 distribution as promised. My current
distutils setup doesn't pick it up - use myhdl.c from
MyHDL 0.3 if you must have it.

If problems persist, let me know, but please do include
version information of all tools.

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] Icarus Verilog and MyHDL

[Vijay K. <ec...@ni...>]

Hi,
I would like to use MyHDL for co simulation with Icarus Verilog. But the test 
programs are not getting simulated. The assertion (verilog_time & 0xFFFF.. == 
myhdl... * 1000 + delta) (Ok, that is approx what the assertion is. But I guess 
you can understand which one it is.) is failing.

I understand what is happening(I read the docs for co simulation with Icarus 
verilog) but I do not know what to do! Like I said even the test programs that 
came with MyHDL fail to co-simulate.

Please help me.

Vijay


-- 
Free the Code.
Free the User.

-------------------------------------------------
This mail sent through IMP(http://www.nitt.edu)

Re: [myhdl-list] Re: how to create records in MyHDL like those in VHDL

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

Jan,

I'm using version .3. The simulation seems to be
correct; and that's what matter most. I found a work
around for the composite signal types. Whatever
signals I want to see in the waveform, I would bind
them to another variable in top level so traceSignals
can find them.

I'm using a class to pass signals to different modules
and in top level I assgined those signals in the class
to a variable so theu appear in the vcd file


here's my modified code

# test record

from myhdl import *

state_t = enum('idle_st', 'load_st', 'process_st',
'exit_st')

class my_record:
    def __init__(self):
        self.A = Signal(bool(0))
        self.Bvec = Signal(intbv()[32:])
        self.state = Signal(state_t.idle_st)

#clock generator
def clk_gen(CLK, period=10):
    lowTime = int(period / 2)
    highTime = period - lowTime
    while True:
        yield delay(lowTime)
        CLK.next = 1
        yield delay(highTime)
        CLK.next = 0
        
# Reset generator        
def reset_gen(CLK, RST):
    RST.next = 1
    yield negedge(CLK)
    RST.next = 0


            

def module_cls(CLK, RST, my_record, rst_value):
    
    while True:
        yield posedge(CLK), RST
            
        if RST:
            my_record.A.next        = 0
            my_record.Bvec.next     = rst_value
            my_record.state.next    = state_t.idle_st
        else:
            my_record.A.next        = not
my_record.A.val
            my_record.Bvec.next     =
my_record.Bvec.val +1
            my_record.state.next    = state_t.load_st
            
            
def module_s_cls(CLK, RST, my_record1, my_record2):
    
    module1_u = module_cls(CLK, RST, my_record1,
0x100)
    module2_u = module_cls(CLK, RST, my_record2,
0x200)
    
    return module1_u, module2_u
            
def top():
    
    
    # CLK and RST are of boolean type
    # clock and reset signals
    CLK                     = Signal(bool(0))
    RST                     = Signal(bool(0))
    # units to generate the clock and reset
    clk_gen_u               = clk_gen(CLK)
    reset_gen_u             = reset_gen(CLK,RST)
    
    
    
    # class of signals
    my_record1_sig           = my_record()
    my_record2_sig           = my_record()
    
    sig1A               = my_record1_sig.A
    sig1Bvec            = my_record1_sig.Bvec
    sig1State           = my_record1_sig.state
    
    sig2A               = my_record2_sig.A
    sig2Bvec            = my_record2_sig.Bvec
    sig2State           = my_record2_sig.state
    
    mod_cls_u               = module_s_cls(CLK, RST, 
                                           
my_record1_sig, my_record2_sig)
    
    return clk_gen_u, reset_gen_u, mod_cls_u

def main():
    
    top_u = traceSignals(top)
    sim = Simulation(top_u)
    sim.run(100)

if __name__ == '__main__':
    main()



--- Jan Decaluwe <ja...@ja...> wrote:
> bedros wrote:
> > Thanks, Jan for you suggestions.
> > 
> > I tried combining signals using lists and classes
> and
> > and worked for simulation, but only signals
> defined at
> > top level(CLK, RST) appeared in vcd file.
> > 
> > Here's my code, so you can run it by yourself and
> > point to me what I'm doing wrong.
> 
> Nothing wrong, except expectations :-)
> Function traceSignals finds the hierarchical regions
> in a
> design, and inspect their namespaces for things of
> type Signal.
> Those are mapped to a net in the VCD output. So, it
> doesn't
> find composite types like lists of Signals, or class
> instances
> whose members are Signals. Note that VCD doesn't
> support such
> things natively either (far from it), so some kind
> of heuristic
> mapping would be needed otherwise. Given what I
> expect from
> waveforms (low level debugging before actual
> verification
> starts) this wouldn't be worth the trouble in my
> judgement.
> 
> The result is that you will only see Signals with a
> simple
> name in the VCD output. You could of course always
> do things like:
> 
> list_sig = [A, Bvec, state] =
> [Signal(bool(0)),Signal(intbv()[32:]),
> Signal(state_t.idle_st)
> 
> I did find a bug while looking at this. Do you use
> 0.3 or 0.4?
> In 0.4, the idea is that the generators at the
> lowest level
> can also be hierarchical regions in the VCD output -
> provided
> they get a name (this was not the case in 0.3).
> 
> In 0.4, function _getGens in _extractHierarchy.py is
> buggy 
> and should be as follows:
> 
> def _getGens(arg):
>     if type(arg) is GeneratorType:
>         return [arg]
>     elif type(arg) is _AlwaysComb:
>         return [arg.gen]
>     else:
>         l = []
>         for elt in arg:
>             if type(elt) is GeneratorType:
>                 l.append(elt)
>             elif type(elt) is _AlwaysComb:
>                 l.append(elt.gen)
>         return l
> 
> Regards, Jan
> 
> > 
> > 
> > 
> > # test record
> > 
> > from myhdl import *
> > 
> > state_t = enum('idle_st', 'load_st', 'process_st',
> > 'exit_st')
> > 
> > class my_record:
> >     def __init__(self):
> >         self.A = Signal(bool(0))
> >         self.Bvec = Signal(intbv()[32:])
> >         self.state = Signal(state_t.idle_st)
> > 
> > #clock generator
> > def clk_gen(CLK, period=10):
> >     lowTime = int(period / 2)
> >     highTime = period - lowTime
> >     while True:
> >         yield delay(lowTime)
> >         CLK.next = 1
> >         yield delay(highTime)
> >         CLK.next = 0
> >         
> > # Reset generator        
> > def reset_gen(CLK, RST):
> >     RST.next = 1
> >     yield negedge(CLK)
> >     RST.next = 0
> > 
> > def module_list(CLK, RST, list_sig):
> >     
> >     while True:
> >         yield posedge(CLK), RST
> >             
> >         if RST:
> >             list_sig[0].next        = 0
> >             list_sig[1].next        = 0x100
> >             list_sig[2].next        =
> state_t.idle_st
> >         else:
> >             list_sig[0].next        = not
> > list_sig[0].val
> >             list_sig[1].next        =
> list_sig[1].val
> > +1
> >             list_sig[2].next        =
> state_t.load_st
> >             
> > 
> > def module_cls(CLK, RST, my_record):
> >     
> >     while True:
> >         yield posedge(CLK), RST
> >             
> >         if RST:
> >             my_record.A.next        = 0
> >             my_record.Bvec.next     = 0x100
> >             my_record.state.next    =
> state_t.idle_st
> >         else:
> >             my_record.A.next        = not
> > my_record.A.val
> >             my_record.Bvec.next     =
> > my_record.Bvec.val +1
> >             my_record.state.next    =
> state_t.load_st
> > 
> >             
> > def top():
> >     
> >     
> >     # CLK and RST are of boolean type
> >     # clock and reset signals
> >     CLK                     = Signal(bool(0))
> >     RST                     = Signal(bool(0))
> >     # units to generate the clock and reset
> >     clk_gen_u               = clk_gen(CLK)
> >     reset_gen_u             = reset_gen(CLK,RST)
> >     
> >     # list of signals
> >     list_sig                = [Signal(bool(0)),
> > Signal(intbv()[32:]), Signal(state_t.idle_st)]
> >     mod_list_u              = module_list(CLK,
> RST,
> > list_sig)
> >     
> >     # class of signals
> >     my_record_sig           = my_record()
> >     
> >     
> >     mod_cls_u               = module_cls(CLK, RST,
> > my_record_sig)
> >     
> >     return clk_gen_u, reset_gen_u, mod_cls_u,
> > mod_list_u
> > 
> > def main():
> >     
> >     top_u = traceSignals(top)
> >     sim = Simulation(top_u)
> >     sim.run(100)
> > 
> > if __name__ == '__main__':
> >     main()
> > 
> > 
> > --- Jan Decaluwe <ja...@ja...> wrote:
> > 
> >>bedros wrote:
> >>
> >>>Jan,
> >>>
> >>>I got a question for you. I've been playing with
> >>
> >>MyHDL
> >>
> >>>whenever I have extra time. Everything works fine
> >>
> >>for
> >>
> >>>me, but I need a way to combine many signals into
> >>
> >>one
> >>
> >>>record so I can pass it around.
> >>
> >>Some up-front remarks. In VHDL, you can create a
> >>composite
> >>type and then create a signal with it. In MyHDL,
> you
> 
=== message truncated ===

[myhdl-list] Re: how to create records in MyHDL like those in VHDL

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

bedros wrote:
> Thanks, Jan for you suggestions.
> 
> I tried combining signals using lists and classes and
> and worked for simulation, but only signals defined at
> top level(CLK, RST) appeared in vcd file.
> 
> Here's my code, so you can run it by yourself and
> point to me what I'm doing wrong.

Nothing wrong, except expectations :-)
Function traceSignals finds the hierarchical regions in a
design, and inspect their namespaces for things of type Signal.
Those are mapped to a net in the VCD output. So, it doesn't
find composite types like lists of Signals, or class instances
whose members are Signals. Note that VCD doesn't support such
things natively either (far from it), so some kind of heuristic
mapping would be needed otherwise. Given what I expect from
waveforms (low level debugging before actual verification
starts) this wouldn't be worth the trouble in my judgement.

The result is that you will only see Signals with a simple
name in the VCD output. You could of course always do things like:

list_sig = [A, Bvec, state] = [Signal(bool(0)),Signal(intbv()[32:]), Signal(state_t.idle_st)

I did find a bug while looking at this. Do you use 0.3 or 0.4?
In 0.4, the idea is that the generators at the lowest level
can also be hierarchical regions in the VCD output - provided
they get a name (this was not the case in 0.3).

In 0.4, function _getGens in _extractHierarchy.py is buggy 
and should be as follows:

def _getGens(arg):
    if type(arg) is GeneratorType:
        return [arg]
    elif type(arg) is _AlwaysComb:
        return [arg.gen]
    else:
        l = []
        for elt in arg:
            if type(elt) is GeneratorType:
                l.append(elt)
            elif type(elt) is _AlwaysComb:
                l.append(elt.gen)
        return l

Regards, Jan

> 
> 
> 
> # test record
> 
> from myhdl import *
> 
> state_t = enum('idle_st', 'load_st', 'process_st',
> 'exit_st')
> 
> class my_record:
>     def __init__(self):
>         self.A = Signal(bool(0))
>         self.Bvec = Signal(intbv()[32:])
>         self.state = Signal(state_t.idle_st)
> 
> #clock generator
> def clk_gen(CLK, period=10):
>     lowTime = int(period / 2)
>     highTime = period - lowTime
>     while True:
>         yield delay(lowTime)
>         CLK.next = 1
>         yield delay(highTime)
>         CLK.next = 0
>         
> # Reset generator        
> def reset_gen(CLK, RST):
>     RST.next = 1
>     yield negedge(CLK)
>     RST.next = 0
> 
> def module_list(CLK, RST, list_sig):
>     
>     while True:
>         yield posedge(CLK), RST
>             
>         if RST:
>             list_sig[0].next        = 0
>             list_sig[1].next        = 0x100
>             list_sig[2].next        = state_t.idle_st
>         else:
>             list_sig[0].next        = not
> list_sig[0].val
>             list_sig[1].next        = list_sig[1].val
> +1
>             list_sig[2].next        = state_t.load_st
>             
> 
> def module_cls(CLK, RST, my_record):
>     
>     while True:
>         yield posedge(CLK), RST
>             
>         if RST:
>             my_record.A.next        = 0
>             my_record.Bvec.next     = 0x100
>             my_record.state.next    = state_t.idle_st
>         else:
>             my_record.A.next        = not
> my_record.A.val
>             my_record.Bvec.next     =
> my_record.Bvec.val +1
>             my_record.state.next    = state_t.load_st
> 
>             
> def top():
>     
>     
>     # CLK and RST are of boolean type
>     # clock and reset signals
>     CLK                     = Signal(bool(0))
>     RST                     = Signal(bool(0))
>     # units to generate the clock and reset
>     clk_gen_u               = clk_gen(CLK)
>     reset_gen_u             = reset_gen(CLK,RST)
>     
>     # list of signals
>     list_sig                = [Signal(bool(0)),
> Signal(intbv()[32:]), Signal(state_t.idle_st)]
>     mod_list_u              = module_list(CLK, RST,
> list_sig)
>     
>     # class of signals
>     my_record_sig           = my_record()
>     
>     
>     mod_cls_u               = module_cls(CLK, RST,
> my_record_sig)
>     
>     return clk_gen_u, reset_gen_u, mod_cls_u,
> mod_list_u
> 
> def main():
>     
>     top_u = traceSignals(top)
>     sim = Simulation(top_u)
>     sim.run(100)
> 
> if __name__ == '__main__':
>     main()
> 
> 
> --- Jan Decaluwe <ja...@ja...> wrote:
> 
>>bedros wrote:
>>
>>>Jan,
>>>
>>>I got a question for you. I've been playing with
>>
>>MyHDL
>>
>>>whenever I have extra time. Everything works fine
>>
>>for
>>
>>>me, but I need a way to combine many signals into
>>
>>one
>>
>>>record so I can pass it around.
>>
>>Some up-front remarks. In VHDL, you can create a
>>composite
>>type and then create a signal with it. In MyHDL, you
>>could
>>do something similar (using classes), but in
>>addition,
>>you can also create a composite type consisting of
>>signals ...
>>
>>An example why this is relevant, consider:
>>
>>s = Signal(intbv()[8:]
>>
>>then s[i] is not a Signal, but an indexed item from
>>the
>>signal's current value. You could not use it to wait
>>on, or in structure for example. This behavior will
>>probably be the most important MyHDL "gotcha" for
>>HDL
>>users. I found it just too hard and complicated to
>>implement it otherwise.
>>
>>However, it's trivial to create a list of signals:
>>
>>sl = [Signal(bool()) for i in range(8)]
>>
>>Now sl[i] is a signal, you can wait on it, use it
>>ins structure etc. Note that there's no equivalent
>>of this
>>in the common HDLs. I think about this capability
>>as the "workaround" for the "gotcha" above.
>>
>>The point is that you have be careful where
>>to "place" the Signals in a composite type - they
>>should be at the level where you will need
>>signal "services".
>>
>>
>>>I tried to create a new class with all my signals
>>>instantiated and it worked fine, except I needed
>>
>>to
>>
>>>modify your source code to get the VCD waveforms.
>>
>>Even
>>
>>>though I used __str__ attribute; I still feel that
>>>there should be a better way to do it. I'm new to
>>
>>both
>>
>>>MyHDL and Python.
>>
>>Using __str__ to get VCD output from a custom class
>>seems
>>the right way to me. We talked about this before -
>>perhaps
>>you should show me your modifications for me to
>>understand
>>the problem.
>>
>>One problem may be that we are struggling with VCD
>>format
>>limitations. It's a low-level format with not even
>>native
>>support for enums, and certainly not for composite
>>types.
>>
>>
>>>My question is how to make a record of something
>>>roughly like this (in vhdl)
>>>
>>>type pkg_t is (data, address, command);
>>>
>>>type my_record is record
>>>
>>>     package_type   : pkg_t;
>>>     load           : bit_vector(31 downto 0);
>>>     valid          : boolean;
>>>
>>>end record;
>>>
>>>I can use enum for pkg_t statement, but how can I
>>>create the record? should I use a function, list,
>>
>>or a
>>
>>>class?
>>
>>A class would seem the obvious choice.
>>
>>Assuming that you want to package signals (see
>>above),
>>I would expect that something like this should work:
>>
>>pkg_t = enum('data', 'address', 'command')
>>
>>class my_record():
>>    def __init__(self):
>>        self.package_type = Signal(pkg_t.data)
>>        self.load = Signal(intbv()[32:])
>>        self.valid = Signal(bool())
>>
>>interface = my_record()
>>
>>Hope this helps, 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
>>
>>
>>
>>
>>
> 
> -------------------------------------------------------
> 
>>SF.Net is sponsored by: Speed Start Your Linux Apps
>>Now.
>>Build and deploy apps & Web services for Linux with
>>a free DVD software kit from IBM. Click Now!
>>
> 
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> 
>>_______________________________________________
>>myhdl-list mailing list
>>myh...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/myhdl-list
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click


-- 
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: how to create records in MyHDL like those in VHDL

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

Thanks, Jan for you suggestions.

I tried combining signals using lists and classes and
and worked for simulation, but only signals defined at
top level(CLK, RST) appeared in vcd file.

Here's my code, so you can run it by yourself and
point to me what I'm doing wrong.



# test record

from myhdl import *

state_t = enum('idle_st', 'load_st', 'process_st',
'exit_st')

class my_record:
    def __init__(self):
        self.A = Signal(bool(0))
        self.Bvec = Signal(intbv()[32:])
        self.state = Signal(state_t.idle_st)

#clock generator
def clk_gen(CLK, period=10):
    lowTime = int(period / 2)
    highTime = period - lowTime
    while True:
        yield delay(lowTime)
        CLK.next = 1
        yield delay(highTime)
        CLK.next = 0
        
# Reset generator        
def reset_gen(CLK, RST):
    RST.next = 1
    yield negedge(CLK)
    RST.next = 0

def module_list(CLK, RST, list_sig):
    
    while True:
        yield posedge(CLK), RST
            
        if RST:
            list_sig[0].next        = 0
            list_sig[1].next        = 0x100
            list_sig[2].next        = state_t.idle_st
        else:
            list_sig[0].next        = not
list_sig[0].val
            list_sig[1].next        = list_sig[1].val
+1
            list_sig[2].next        = state_t.load_st
            

def module_cls(CLK, RST, my_record):
    
    while True:
        yield posedge(CLK), RST
            
        if RST:
            my_record.A.next        = 0
            my_record.Bvec.next     = 0x100
            my_record.state.next    = state_t.idle_st
        else:
            my_record.A.next        = not
my_record.A.val
            my_record.Bvec.next     =
my_record.Bvec.val +1
            my_record.state.next    = state_t.load_st

            
def top():
    
    
    # CLK and RST are of boolean type
    # clock and reset signals
    CLK                     = Signal(bool(0))
    RST                     = Signal(bool(0))
    # units to generate the clock and reset
    clk_gen_u               = clk_gen(CLK)
    reset_gen_u             = reset_gen(CLK,RST)
    
    # list of signals
    list_sig                = [Signal(bool(0)),
Signal(intbv()[32:]), Signal(state_t.idle_st)]
    mod_list_u              = module_list(CLK, RST,
list_sig)
    
    # class of signals
    my_record_sig           = my_record()
    
    
    mod_cls_u               = module_cls(CLK, RST,
my_record_sig)
    
    return clk_gen_u, reset_gen_u, mod_cls_u,
mod_list_u

def main():
    
    top_u = traceSignals(top)
    sim = Simulation(top_u)
    sim.run(100)

if __name__ == '__main__':
    main()


--- Jan Decaluwe <ja...@ja...> wrote:
> bedros wrote:
> > Jan,
> > 
> > I got a question for you. I've been playing with
> MyHDL
> > whenever I have extra time. Everything works fine
> for
> > me, but I need a way to combine many signals into
> one
> > record so I can pass it around.
> 
> Some up-front remarks. In VHDL, you can create a
> composite
> type and then create a signal with it. In MyHDL, you
> could
> do something similar (using classes), but in
> addition,
> you can also create a composite type consisting of
> signals ...
> 
> An example why this is relevant, consider:
> 
> s = Signal(intbv()[8:]
> 
> then s[i] is not a Signal, but an indexed item from
> the
> signal's current value. You could not use it to wait
> on, or in structure for example. This behavior will
> probably be the most important MyHDL "gotcha" for
> HDL
> users. I found it just too hard and complicated to
> implement it otherwise.
> 
> However, it's trivial to create a list of signals:
> 
> sl = [Signal(bool()) for i in range(8)]
> 
> Now sl[i] is a signal, you can wait on it, use it
> ins structure etc. Note that there's no equivalent
> of this
> in the common HDLs. I think about this capability
> as the "workaround" for the "gotcha" above.
> 
> The point is that you have be careful where
> to "place" the Signals in a composite type - they
> should be at the level where you will need
> signal "services".
> 
> > 
> > I tried to create a new class with all my signals
> > instantiated and it worked fine, except I needed
> to
> > modify your source code to get the VCD waveforms.
> Even
> > though I used __str__ attribute; I still feel that
> > there should be a better way to do it. I'm new to
> both
> > MyHDL and Python.
> 
> Using __str__ to get VCD output from a custom class
> seems
> the right way to me. We talked about this before -
> perhaps
> you should show me your modifications for me to
> understand
> the problem.
> 
> One problem may be that we are struggling with VCD
> format
> limitations. It's a low-level format with not even
> native
> support for enums, and certainly not for composite
> types.
> 
> > 
> > My question is how to make a record of something
> > roughly like this (in vhdl)
> > 
> > type pkg_t is (data, address, command);
> > 
> > type my_record is record
> > 
> >      package_type   : pkg_t;
> >      load           : bit_vector(31 downto 0);
> >      valid          : boolean;
> > 
> > end record;
> > 
> > I can use enum for pkg_t statement, but how can I
> > create the record? should I use a function, list,
> or a
> > class?
> 
> A class would seem the obvious choice.
> 
> Assuming that you want to package signals (see
> above),
> I would expect that something like this should work:
> 
> pkg_t = enum('data', 'address', 'command')
> 
> class my_record():
>     def __init__(self):
>         self.package_type = Signal(pkg_t.data)
>         self.load = Signal(intbv()[32:])
>         self.valid = Signal(bool())
> 
> interface = my_record()
> 
> Hope this helps, 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
> 
> 
> 
> 
>
-------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps
> Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
>
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> myhdl-list mailing list
> myh...@li...
>
https://lists.sourceforge.net/lists/listinfo/myhdl-list

[myhdl-list] Re: how to create records in MyHDL like those in VHDL

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

bedros wrote:
> Jan,
> 
> I got a question for you. I've been playing with MyHDL
> whenever I have extra time. Everything works fine for
> me, but I need a way to combine many signals into one
> record so I can pass it around.

Some up-front remarks. In VHDL, you can create a composite
type and then create a signal with it. In MyHDL, you could
do something similar (using classes), but in addition,
you can also create a composite type consisting of signals ...

An example why this is relevant, consider:

s = Signal(intbv()[8:]

then s[i] is not a Signal, but an indexed item from the
signal's current value. You could not use it to wait
on, or in structure for example. This behavior will
probably be the most important MyHDL "gotcha" for HDL
users. I found it just too hard and complicated to
implement it otherwise.

However, it's trivial to create a list of signals:

sl = [Signal(bool()) for i in range(8)]

Now sl[i] is a signal, you can wait on it, use it
ins structure etc. Note that there's no equivalent of this
in the common HDLs. I think about this capability
as the "workaround" for the "gotcha" above.

The point is that you have be careful where
to "place" the Signals in a composite type - they
should be at the level where you will need
signal "services".

> 
> I tried to create a new class with all my signals
> instantiated and it worked fine, except I needed to
> modify your source code to get the VCD waveforms. Even
> though I used __str__ attribute; I still feel that
> there should be a better way to do it. I'm new to both
> MyHDL and Python.

Using __str__ to get VCD output from a custom class seems
the right way to me. We talked about this before - perhaps
you should show me your modifications for me to understand
the problem.

One problem may be that we are struggling with VCD format
limitations. It's a low-level format with not even native
support for enums, and certainly not for composite types.

> 
> My question is how to make a record of something
> roughly like this (in vhdl)
> 
> type pkg_t is (data, address, command);
> 
> type my_record is record
> 
>      package_type   : pkg_t;
>      load           : bit_vector(31 downto 0);
>      valid          : boolean;
> 
> end record;
> 
> I can use enum for pkg_t statement, but how can I
> create the record? should I use a function, list, or a
> class?

A class would seem the obvious choice.

Assuming that you want to package signals (see above),
I would expect that something like this should work:

pkg_t = enum('data', 'address', 'command')

class my_record():
    def __init__(self):
        self.package_type = Signal(pkg_t.data)
        self.load = Signal(intbv()[32:])
        self.valid = Signal(bool())

interface = my_record()

Hope this helps, 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] how to create records in MyHDL like those in VHDL

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

Jan,

I got a question for you. I've been playing with MyHDL
whenever I have extra time. Everything works fine for
me, but I need a way to combine many signals into one
record so I can pass it around.

I tried to create a new class with all my signals
instantiated and it worked fine, except I needed to
modify your source code to get the VCD waveforms. Even
though I used __str__ attribute; I still feel that
there should be a better way to do it. I'm new to both
MyHDL and Python.

My question is how to make a record of something
roughly like this (in vhdl)

type pkg_t is (data, address, command);

type my_record is record

     package_type   : pkg_t;
     load           : bit_vector(31 downto 0);
     valid          : boolean;

end record;

I can use enum for pkg_t statement, but how can I
create the record? should I use a function, list, or a
class?

Thanks,

-Bedros
  

[myhdl-list] Re: MyHDL question

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

Frank Palazzolo wrote:
> Thanks Jan, this is just what I needed.  I will give this a try and let you
> know how it works out.
> 
> It's kind of silly, but the chip I was modelling was a simple 74LS93 4-bit
> ripple counter which has 2 clock inputs, one for Q0 and one for Q1-Q3.  It
> is possible that both clocks could appear at the same time.

In that case however, I advise you to use separate generators:

Q = Signal(intbv()[4:])

def Counter(Q, clk1, clk2, ...):

    def proc0():
        while 1:
            yield posedge(clk1)
            ...
            Q.next[0] = ....

    def proc1_3():
        while 1:
            yield posedge(clk2)
            ...
            Q.next[3:1] = ....

    return proc0(), proc1_3()

(Note that this should work as you expect in MyHDL, but in VHDL
you would get into trouble with signal resolution etc.)

> 
> My long term plan is to try to do some simulations of some old Black & White
> coin-op arcade games (like Pong, etc.), based on the schematics.  These
> games were built from about 1973-1981 and have no CPU's, only a bunch of
> discrete logic chips.  I'm going to try to enter the structural data from
> the schematics, build a small library of TTL parts, and use MyHDL & PyGame
> to try to generate screenshots.

If there's any "structure" in the structure, recall that you could use Python's
full power, to describe it: lists of instances/signals, for-loops, if's,
recursion ... MyHDL's ultra light-weight approach to structure is something
that I like in particular but haven't explored a lot yet.

> I'm sure that none of the simulations will approach "real-time", but I have
> another idea to achieve that later.
> 
> I've done something like this with structural VHDL, but IMHO Python/MyHDL is
> much nicer :)
> 
> Thanks again!
> -Frank

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 question

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

Thanks Jan, this is just what I needed.  I will give this a try and let =
you
know how it works out.

It's kind of silly, but the chip I was modelling was a simple 74LS93 =
4-bit
ripple counter which has 2 clock inputs, one for Q0 and one for Q1-Q3.  =
It
is possible that both clocks could appear at the same time.

My long term plan is to try to do some simulations of some old Black & =
White
coin-op arcade games (like Pong, etc.), based on the schematics.  These
games were built from about 1973-1981 and have no CPU's, only a bunch of
discrete logic chips.  I'm going to try to enter the structural data =
from
the schematics, build a small library of TTL parts, and use MyHDL & =
PyGame
to try to generate screenshots.

I'm sure that none of the simulations will approach "real-time", but I =
have
another idea to achieve that later.

I've done something like this with structural VHDL, but IMHO =
Python/MyHDL is
much nicer :)

Thanks again!
-Frank

[myhdl-list] Re: MyHDL question

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

Frank Palazzolo wrote:
> Hello Jan,
> 
> I've just discovered MyHDL and I am quite impressed!  I have been 
> fooling around with generators in Python with an eye toward 
> simulation.  I first discovered SimPy, and then those guys introduced 
> me to MyHDL when I mentioned I wanted to do gate-level simulation.

Nice from them.

> I am trying to do some logic simulations of old TTL designs.  So far 
> I've run into one small issue....
> 
> If I want to edge-trigger on either of two edge events, as in
> 	yield posedge(A), posedge(B)
> 
> How can I tell which one has occurred after the yield, or if both 
> have occurred?  Should this be broken into two processes somehow?
> 
> I realize I can check the current value of A and B - but I don't seem 
> to have any information on the previous values of A and B when the 
> yield was called.  Some of your examples have a similar situation 
> (clock and reset) but in those cases you don't care about the actual 
> "edge" of reset, only the resulting level.

Ok. In VHDL, you could do this with the 'event attribute, but I don't
think it is possible in Verilog. In any case I would like to know how
this feature is useful in your modeling. Note that it is perfectly
possible that the two events happen "simultaneously".

I've been thinking on how to accomplish this in MyHDL. You'll need some
help from the "internals" at this point (_Signal.py). Each signal
maintains 3 "waiter" lists, for plain events, posedge events and
negedge events. Those are just lists that can be tested.
When you have:

   yield posedge(A), posedge(B)

it is certain that both A and B had a non-empty posedge waiter list right
before the generator resumes. With the following function:

def posedgeEvent(sig):
    return not sig._posedgeWaiters

you can test whether that event list has become empty, and therefore, whether
that event has triggered the generator. Again, it is possible that both
have become empty in the same delta cycle.

I used the name posedgeEvent to illustrate the point - but it is probably
misleading. It just tests whether the waiter list is empty, not whether
an event has just occured. When you use the function right after a corresponding
event in a yield, the effect is the same though. Testing for

  not hasPosedgeWaiters(sig)
or
  not hasWaiters(posedge(sig))

would be correct names, but less clear I guess.

Hope this helps for now,

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] MyHDL question

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

Hello Jan,

I've just discovered MyHDL and I am quite impressed!  I have been 
fooling around with generators in Python with an eye toward 
simulation.  I first discovered SimPy, and then those guys introduced 
me to MyHDL when I mentioned I wanted to do gate-level simulation.

I am trying to do some logic simulations of old TTL designs.  So far 
I've run into one small issue....

If I want to edge-trigger on either of two edge events, as in
	yield posedge(A), posedge(B)

How can I tell which one has occurred after the yield, or if both 
have occurred?  Should this be broken into two processes somehow?

I realize I can check the current value of A and B - but I don't seem 
to have any information on the previous values of A and B when the 
yield was called.  Some of your examples have a similar situation 
(clock and reset) but in those cases you don't care about the actual 
"edge" of reset, only the resulting level.

FWIW - I am attempting to model a simple 74LS93 chip, which has two 
clock inputs.

Thanks,
Frank Palazzolo

[myhdl-list] ANNOUNCE: MyHDL 0.4

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

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

MyHDL 0.4 supports the automatic conversion of a subset of MyHDL code
to synthesizable Verilog code. This feature provides a direct path
from Python to an FPGA or ASIC implementation.

For the details what's new, go here:

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

For a general overview and starting point, go here:

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

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] MyHDL 0.4 preview

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

Hi:

MyHDL 0.4 preview
-----------------

I'm preparing a new release of MyHDL. With this release, I will have
implemented all functionality on my personal must-have list.
Therefore, this will be an important release for the future of
MyHDL. With the new functionality, I hope that the interest will
increase substantially, including developer interest.

To maximize the release quality, I would like to give a preview
through this channel, and I welcome any feedback, suggestions, or
questions. The implementation is basically ready, so I feel confident
to do this now as I'm working on the documentation. I will try to
explain the new functionality clearly and concisely.

New functionality description and rationale
-------------------------------------------

Basically, MyHDL 0.4 provides a path to automatic implementation
(synthesis) through conversion to Verilog. In the following, I will
refer to the corresponding source code as "synthesizable code".

In a typical design project, the amount of synthesizable code is
only a small fraction all source code: the larger part will consist of
high-level models, project maintenance and automation code, and
verification related code such as test benches.

Still, synthesizable code is of special importance in several
ways. First, the implementation is what counts in the end. Secondly,
synthesizable code has important restrictions and a different concept
of Quality of Results. Finally, synthesizable code is what many
designers like to do most and first (regardless of whether this is a
good idea from a methodology viewpoint).

MyHDL aims to be a complete solution, but at this point a MyHDL user
would have to translate "synthesizable" code manually to Verilog or
VHDL. Needless to say, this is very inconvenient, and probably
unacceptable to most designers.

In summary: even though the true advantages of MyHDL are to be found
in the high-level and verification-related tasks of a design project,
I believe that a path to automated implementation is essential to
convince more designers to give it a try.

Solution description
--------------------

The conversion does not start from source files, but from a design
that has been "elaborated" by the Python interpreter.  This has
important advantages. First, there are no restrictions on how to
describe structure, as all "structural" constructs and parameters are
processed before the conversion starts. Second, the work of the Python
interpreter is "reused". The converter uses the Python profiler to
track the interpreter's operation and to infer the design structure
and name spaces. It then selectively compiles pieces of source code
for additional analysis and for conversion. This is done using the
Python compiler package.

The converter infers the Verilog module interface and bit widths from
the constructors and usage of the Signals.  The design hierarchy can
be arbitrarily deep, but the converted Verilog design will be a flat
"net list of blocks". The converter maps generators to initial or
always blocks. To support function calls with various parameters, it
generates a unique Verilog function or task per call.

Unsurprisingly, not all Python code can be converted into Verilog. In
fact, there are very important restrictions.  As the goal of the
conversion functionality is implementation, this should not be a big
issue: anyone familiar with synthesis is used to similar restrictions
in the "synthesizable subset" of Verilog and VHDL. The implementation
attempts to issue clear error messages when it encounters a construct
that cannot be converted.  Details about the convertible subset follow
further.

The convertible "subset"
------------------------

In practice, the "synthesizable subset" usually refers to RTL
synthesis, which is by far the most popular type of synthesis
today. There are industry standards that define the RTL synthesis
subset.  However, those were not used as a model for the restrictions
of the MyHDL converter, but as a minimal starting point.  On that
basis, whenever it was judged easy or useful to support an additional
feature, this was done. For example, it is actually easier to convert
while loops than for loops even though they are not RTL-synthesizable.
As another example, 'print' is supported because it's so useful for
debugging, even though it's not synthesizable.  In summary, the
convertible subset is a superset of the standard RTL synthesis subset,
and supports synthesis tools with more advanced capabilities, such as
behavioral synthesis.

A natural restriction on convertible code is that it should be
written in MyHDL style: cooperating generators, communicating through
signals, and with yield statements specifying wait points and resume
conditions.  Supported resume conditions are a signal edge, a signal
change, or a tuple of such conditions.

The most important restriction regards object types. Verilog is an
almost typeless language, while Python is strongly (albeit
dynamically) typed. The converter needs to infer the types of
variables and map them to Verilog types. Therefore, it does type
inferencing of object constructors and expressions.  Python int/long's
are mapped to Verilog integers. All other supported types are mapped
to Verilog regs (or wires), and therefore need to have a defined bit
width. The supported types are the Python bool type, the MyHDL intbv
type, and MyHDL enumeration types returned by function enum. The
latter types can also be used as the base value type of a
signal. intbv instances need to be constructed so that a bit width can
be inferred.

Recall that any restrictions only apply to the design post
elaboration.  In practice, this means that they apply only to the code
of the generators, that are the "leaf" functional blocks in a MyHDL
design.

Optimizations
-------------

To make the conversion solution more attractive, some optimizations
were put in.

In Verilog and VHDL, case statements are often used to describe finite
state machines efficiently. Python doesn't have a case statement, but
the converter recognizes particular if-then-else structures and maps
them to case statements. This optimization occurs when a variable
whose type is an enumerated type is sequentially tested against
enumeration items in an if-then-else structure. Also, the appropriate
synthesis pragmas for efficient synthesis are generated in the Verilog
code.

As a further optimization, function enum was enhanced to support
alternative encoding schemes elegantly, using an additional parameter
'encoding'. For example:

    t_State = enum("START", "RUN", "STOP", encoding='one_hot')

The default encoding is binary; other possibilities are one_hot and
one_cold. This parameter only affects the conversion output, not the
behavior of the type. Verilog case statements are optimized for an
efficient implementation according to the encoding. Note that in
contrast, a Verilog designer needs to make nontrivial code changes to
implement a different encoding scheme.

Usage example
-------------

We will illustrate the conversion usage with a small example with no
hierarchy. (As pointed out, the design hierarchy can in fact be
arbitrarily deep).

Consider the following MyHDL model of an incrementer:

    def inc(count, enable, clock, reset, n):
        """ Incrementer with enable.

        count -- output
        enable -- control input, increment when 1
        clock -- clock input
        reset -- asynchronous reset input
        n -- counter max value
        """
        while 1:
            yield posedge(clock), negedge(reset)
            if reset == ACTIVE_LOW:
                count.next = 0
            else:
                if enable:
                    count.next = (count + 1) % n


Normally, to simulate it, we would "elaborate" an instance
as follows:


    m = 8
    n = 2 ** m

    count = Signal(intbv(0)[m:])
    enable, clock, reset = [Signal(bool()) for i in range(3)]

    inc_inst = inc(count, enable, clock, reset, n=n)
    

inc_inst is an elaborated design instance that can be simulated. To
convert it to Verilog, we change the last line as follows:

    
    inc_inst = toVerilog(inc, count, enable, clock, reset, n=n)
 

Again, this creates an instance that can be simulated, but as a side
effect, it also generates a Verilog module that is supposed to have
identical behavior. In addition, a test bench is generated, so that
the MyHDL cosimulation interface can be used to verify the Verilog
model against the MyHDL model. This is, of course, how I have been
verifying the Verilog converter.

For the example, the generated Verilog module is as follows:


    module inc_inst (
        count,
        enable,
        clock,
        reset
    );

    output [7:0] count;
    reg [7:0] count;
    input enable;
    input clock;
    input reset;


    always @(posedge clock or negedge reset) begin: _MYHDL1__BLOCK
        if ((reset == 0)) begin
            count <= 0;
        end
        else begin
            if (enable) begin
                count <= ((count + 1) % 256);
            end
        end
    end

    endmodule


Conclusion
----------

With release 0,4, MyHDL users will have a path to automated
implementation, by code conversion to Verilog.


-- 
Jan Decaluwe - Resources bvba - http://jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
    Bored with EDA the way it is? Check this:
    http://jandecaluwe.com/Tools/MyHDL/Overview.html