myhdl-list Mailing List for MyHDL (Page 191)
Brought to you by:
jandecaluwe
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(14) |
Nov
(4) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(1) |
Feb
(10) |
Mar
(19) |
Apr
(14) |
May
(1) |
Jun
(4) |
Jul
(10) |
Aug
|
Sep
(2) |
Oct
(7) |
Nov
(17) |
Dec
(12) |
2005 |
Jan
(6) |
Feb
(10) |
Mar
(17) |
Apr
(10) |
May
(9) |
Jun
(5) |
Jul
(26) |
Aug
(34) |
Sep
(10) |
Oct
(38) |
Nov
(71) |
Dec
(74) |
2006 |
Jan
(20) |
Feb
(20) |
Mar
(7) |
Apr
(2) |
May
(13) |
Jun
|
Jul
|
Aug
(4) |
Sep
(37) |
Oct
(43) |
Nov
(30) |
Dec
(33) |
2007 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(30) |
Jun
(9) |
Jul
(1) |
Aug
|
Sep
(8) |
Oct
(13) |
Nov
|
Dec
(4) |
2008 |
Jan
(13) |
Feb
(46) |
Mar
(25) |
Apr
(7) |
May
(20) |
Jun
(73) |
Jul
(38) |
Aug
(47) |
Sep
(24) |
Oct
(18) |
Nov
(9) |
Dec
(36) |
2009 |
Jan
(31) |
Feb
(24) |
Mar
(73) |
Apr
(13) |
May
(47) |
Jun
(28) |
Jul
(36) |
Aug
(2) |
Sep
(5) |
Oct
(8) |
Nov
(16) |
Dec
(29) |
2010 |
Jan
(34) |
Feb
(18) |
Mar
(18) |
Apr
(5) |
May
|
Jun
(24) |
Jul
(53) |
Aug
(3) |
Sep
(18) |
Oct
(33) |
Nov
(19) |
Dec
(15) |
2011 |
Jan
(9) |
Feb
(4) |
Mar
(39) |
Apr
(213) |
May
(86) |
Jun
(46) |
Jul
(22) |
Aug
(11) |
Sep
(78) |
Oct
(59) |
Nov
(38) |
Dec
(24) |
2012 |
Jan
(9) |
Feb
(22) |
Mar
(89) |
Apr
(55) |
May
(222) |
Jun
(86) |
Jul
(57) |
Aug
(32) |
Sep
(49) |
Oct
(69) |
Nov
(12) |
Dec
(35) |
2013 |
Jan
(67) |
Feb
(39) |
Mar
(18) |
Apr
(42) |
May
(79) |
Jun
(1) |
Jul
(19) |
Aug
(18) |
Sep
(54) |
Oct
(79) |
Nov
(9) |
Dec
(26) |
2014 |
Jan
(30) |
Feb
(44) |
Mar
(26) |
Apr
(11) |
May
(39) |
Jun
(1) |
Jul
(89) |
Aug
(15) |
Sep
(7) |
Oct
(6) |
Nov
(20) |
Dec
(27) |
2015 |
Jan
(107) |
Feb
(106) |
Mar
(130) |
Apr
(90) |
May
(147) |
Jun
(28) |
Jul
(53) |
Aug
(16) |
Sep
(23) |
Oct
(7) |
Nov
|
Dec
(16) |
2016 |
Jan
(86) |
Feb
(41) |
Mar
(38) |
Apr
(31) |
May
(37) |
Jun
(11) |
Jul
(1) |
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
(5) |
Dec
(3) |
2017 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(2) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(2) |
Sep
(1) |
Oct
(2) |
Nov
(1) |
Dec
(1) |
2018 |
Jan
(1) |
Feb
(1) |
Mar
(7) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
(1) |
Feb
|
Mar
(2) |
Apr
(1) |
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
|
2020 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(3) |
2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
(11) |
2022 |
Jan
(7) |
Feb
(2) |
Mar
(1) |
Apr
|
May
|
Jun
(1) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2023 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
2024 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(2) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
2025 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Jan D. <ja...@ja...> - 2004-03-29 09:01:29
|
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 |
From: Guenter D. <dan...@we...> - 2004-03-27 20:30:28
|
Hello Jan, I was wondering whether you plan to add a conversion of MyHDL code to VHDL, similar to the Verilog conversion? Thanks Guenter |
From: Jan D. <ja...@ja...> - 2004-03-27 10:30:42
|
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 |
From: Jan D. <ja...@ja...> - 2004-03-27 10:20:59
|
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 |
From: Terry B. <tt...@ve...> - 2004-03-27 01:08:59
|
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 |
From: Terry B. <tt...@ve...> - 2004-03-21 19:16:02
|
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. |
From: Jan D. <ja...@ja...> - 2004-03-10 22:12:13
|
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 |
From: Terry B. <tt...@ve...> - 2004-03-10 16:39:02
|
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 |
From: Jan D. <ja...@ja...> - 2004-03-03 09:02:24
|
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 |
From: Vijay K. <ec...@ni...> - 2004-03-03 04:50:39
|
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) |
From: bedros <be...@ya...> - 2004-02-16 19:35:22
|
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 === |
From: Jan D. <ja...@ja...> - 2004-02-16 15:22:44
|
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 |
From: bedros <be...@ya...> - 2004-02-13 19:19:25
|
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 |
From: Jan D. <ja...@ja...> - 2004-02-13 10:29:35
|
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 |
From: bedros <be...@ya...> - 2004-02-12 18:35:04
|
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 |
From: Jan D. <ja...@ja...> - 2004-02-12 08:43:17
|
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 |
From: Frank P. <pal...@co...> - 2004-02-11 23:07:26
|
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 |
From: Jan D. <ja...@ja...> - 2004-02-11 22:38:46
|
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 |
From: Frank P. <pal...@co...> - 2004-02-11 12:22:30
|
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 |
From: Jan D. <ja...@ja...> - 2004-02-04 21:57:22
|
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 |
From: Jan D. <ja...@ja...> - 2004-01-27 12:57:30
|
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 |
From: Jan D. <ja...@ja...> - 2003-11-18 15:46:51
|
bedros wrote: > Jan, > > My comments are below. > > --- Jan Decaluwe <ja...@ja...> wrote: > >>bedros wrote: > printing __str__ attribute of a user-defined object > (custom class) should work, but we need to pass the > code generator (_genNameCode()) to the class to > allocate symbol(s) for the object. Because > traceSignals class allocates only one symbol per > object (for VCD format) I guess I need to understand better what you exactly try to do - I'll wait until you have something to show. Regards, Jan -- 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 |
From: bedros <be...@ya...> - 2003-11-17 18:18:40
|
Jan, My comments are below. --- Jan Decaluwe <ja...@ja...> wrote: > bedros wrote: > > Jan, > > > > Thanks a lot for providing myhdl. I used it to > model a > > design and I'm very impressed. > > > > However, it still needs a lot of work. I made some > > changes to files (_Signal.py and _traceSignal.py) > to > > allow printing vcd output of a custom object > (class) > > instead of only int and intbv. > > The fallback behavior for any type should be to > print > the string representation (from str()) as a VCD > string > output. I think this is the best one can do for the > general > case. Could you explain why it does not work for > you? printing __str__ attribute of a user-defined object (custom class) should work, but we need to pass the code generator (_genNameCode()) to the class to allocate symbol(s) for the object. Because traceSignals class allocates only one symbol per object (for VCD format) > > You are more than welcome. An interface to a popular > VHDL > simulator would be a real value. Some remarks: > > - some time ago another engineer offered help to > provide > a cosimulation interface to VHDL. I explained the > needs, > also warning that this kind of development is not > necessarily > fun (from my experience with the Verilog PLI - > though it's > real fun to have it once it works.) I have not heard > from > him since ... > > - last time I checked I believe Aldec's PLI did not > have > the capability to write values to signals (only to > read > them). In that case, we don't have a solution. > > Keep up the good work, and let us know about it! > > Regards, Jan I'll be working on myhdl as a part of my current job. I need a modeling language/platform to make the right design decisions before I start coding in VHDL. and having a library like myhdl will save me a lot of time. All my contribution would be free of charge, because we're not an EDA company and I was going to do it on my own from the scratch anyway. -Bedros |
From: Jan D. <ja...@ja...> - 2003-11-14 21:43:15
|
bedros wrote: > Jan, > > Thanks a lot for providing myhdl. I used it to model a > design and I'm very impressed. > > However, it still needs a lot of work. I made some > changes to files (_Signal.py and _traceSignal.py) to > allow printing vcd output of a custom object (class) > instead of only int and intbv. The fallback behavior for any type should be to print the string representation (from str()) as a VCD string output. I think this is the best one can do for the general case. Could you explain why it does not work for you? There are a few issues with the approach that I'm aware of: - string output is not a VCD standard feature - it is only supported by gtkwave as far as I know. Probably this means that VCD is not the appropriate solution for our purposes (we want to use arbitrary complex types as Signal values), but I used it as a proof of concept because it is so popular. LXT may the solution - it supports string output but then again I think gtkwave doesn't support that feature yet. - some string output doesn't work with gtkwave, I noticed. In particular, I believe you cannot have blanks. Note that you always have the option to specialize __str__() to fix issues for a given type. > I'm still new to python and myhdl; but I'm hoping in > couple weeks to finish testing my changes and be ready > for a release. > > for many years, I wanted to have an easy to use, > event-driven, and efficient modeling tools; Python and > myhdl seem to be the perfect fit. > > Thanks again, and if you need help in developing parts > of myhdl, I'll be happy to provide any assistance. I > have access to a vhdl simulator (active HDL) and they > claim to support PLI but I never used it and not sure > if it's fully compatible with the standards. You are more than welcome. An interface to a popular VHDL simulator would be a real value. Some remarks: - some time ago another engineer offered help to provide a cosimulation interface to VHDL. I explained the needs, also warning that this kind of development is not necessarily fun (from my experience with the Verilog PLI - though it's real fun to have it once it works.) I have not heard from him since ... - last time I checked I believe Aldec's PLI did not have the capability to write values to signals (only to read them). In that case, we don't have a solution. Keep up the good work, and let us know about it! Regards, Jan -- 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 |
From: bedros <be...@ya...> - 2003-11-14 17:31:56
|
Jan, Thanks a lot for providing myhdl. I used it to model a design and I'm very impressed. However, it still needs a lot of work. I made some changes to files (_Signal.py and _traceSignal.py) to allow printing vcd output of a custom object (class) instead of only int and intbv. I'm still new to python and myhdl; but I'm hoping in couple weeks to finish testing my changes and be ready for a release. for many years, I wanted to have an easy to use, event-driven, and efficient modeling tools; Python and myhdl seem to be the perfect fit. Thanks again, and if you need help in developing parts of myhdl, I'll be happy to provide any assistance. I have access to a vhdl simulator (active HDL) and they claim to support PLI but I never used it and not sure if it's fully compatible with the standards. -Bedros |