myhdl-list Mailing List for MyHDL (Page 176)
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...> - 2005-12-27 14:46:24
|
George Pantazopoulos wrote: >> > Thanks, you're the best :-) Could I get the changed file(s)? A few files were changed. I suggest to try release candidate 0.5c1, available from the snapshot area :-) Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: George P. <ge...@ga...> - 2005-12-26 01:58:23
|
>> >> When I used the state enum in the code below, the Verilog output >> caused an XST Error (pasted below too). It seems that the case >> statement refers to the nonexistent name (in the verilog code) >> 'state', when it should have been the 'fully qualified' name >> '_synthInst_SID_INST_envGen0_state'. When I fixed the Verilog code by >> hand, it compiled, synthesized and worked correctly. I saw this in >> both myhdl 0.5a1 and 0.5b1. >> >> Hope this helps squish a bug before the big 0.5 release :) > > > Of course, a customer with a problem always gets priority :-) > > I have solved the bug in the code. Thanks for the report. > Thanks, you're the best :-) Could I get the changed file(s)? Happy Christmahanuquanzica :) George |
From: Jan D. <ja...@ja...> - 2005-12-25 12:53:14
|
George Pantazopoulos wrote: > Hi Jan, > > When I used the state enum in the code below, the Verilog output > caused an XST Error (pasted below too). It seems that the case statement > refers to the nonexistent name (in the verilog code) 'state', when it > should have been the 'fully qualified' name > '_synthInst_SID_INST_envGen0_state'. When I fixed the Verilog code by > hand, it compiled, synthesized and worked correctly. I saw this in both > myhdl 0.5a1 and 0.5b1. > > Hope this helps squish a bug before the big 0.5 release :) Of course, a customer with a problem always gets priority :-) I have solved the bug in the code. Thanks for the report. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: George P. <ge...@ga...> - 2005-12-24 19:27:24
|
Hi Jan, When I used the state enum in the code below, the Verilog output caused an XST Error (pasted below too). It seems that the case statement refers to the nonexistent name (in the verilog code) 'state', when it should have been the 'fully qualified' name '_synthInst_SID_INST_envGen0_state'. When I fixed the Verilog code by hand, it compiled, synthesized and worked correctly. I saw this in both myhdl 0.5a1 and 0.5b1. Hope this helps squish a bug before the big 0.5 release :) Thanks, George // Excerpt of myHDL code // def EnvelopeGen(clk, gate, attack_rate, decay_rate, sustain_level, release_rate, reset_n, env_out, accum_width=24): accum = Signal(intbv(0)[accum_width:]) t_State = enum('Idle', 'Attack', 'Decay', 'Sustain', 'Release') state = Signal(t_State.Idle) @always(clk.posedge) def EnvGenProcess(): env_out.next = accum[accum_width:accum_width-len(env_out)] if state == t_State.Idle: accum.next = 0 if gate: state.next = t_State.Attack elif state == t_State.Attack: accum.next = (accum + 8) % 2**accum_width if gate == False: state.next = t_State.Idle else: state.next = t_State.Idle return instances() ===== Excerpt of resulting Verilog code ========== // ... reg [2:0] _synthInst_SID_INST_envGen0_state; // ... // ... Much more stuff in between // ... always @(posedge clk) begin: _top_synthInst_SID_INST_envGen0_EnvGenProcess _synthInst_SID_INST_env0_out <= _synthInst_SID_INST_envGen0_accum[24-1:(24 - 12)]; // synthesis parallel_case full_case casez (state) 3'b000: begin _synthInst_SID_INST_envGen0_accum <= 0; if (_synthInst_SID_INST_wave0_gate) begin _synthInst_SID_INST_envGen0_state <= 3'b001; end end 3'b001: begin _synthInst_SID_INST_envGen0_accum <= ((_synthInst_SID_INST_envGen0_accum + 8) % (2 ** 24)); if ((_synthInst_SID_INST_wave0_gate == 0)) begin _synthInst_SID_INST_envGen0_state <= 3'b000; end end default: begin _synthInst_SID_INST_envGen0_state <= 3'b000; end endcase end === Xilinx XST Error ======= Started process "Synthesize". ========================================================================= * HDL Compilation * ========================================================================= Compiling verilog file "../../phoenixSID.v" ERROR:HDLCompilers:28 - "../../phoenixSID.v" line 114 'state' has not been declared Module <phoenixSID> compiled Analysis of file <"phoenixSID.prj"> failed. --> Total memory usage is 88628 kilobytes Number of errors : 1 ( 0 filtered) Number of warnings : 0 ( 0 filtered) Number of infos : 0 ( 0 filtered) ERROR: XST failed Process "Synthesize" did not complete. |
From: Jan D. <ja...@ja...> - 2005-12-23 09:50:39
|
George Pantazopoulos wrote: > Hi Jan, > > I thought the overview was a bit too much all at once, like drinking > from a fire hose for a newbie :). However, I also thought it was > well-composed and showed a strong grasp of the English language. > > A native speaker, I re-organized the content to make it catchier and > easier to read. I also added a catchy one-sentence description up top. > > http://myhdl.jandecaluwe.com/doku.php/newoverview > > Thanks for your hard work. Feedback welcome! Definitely much better, thanks. I'll be making further improvements :-) -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2005-12-23 09:40:35
|
George Pantazopoulos wrote: >>I don't plan to make further changes to the 0.5b1 code >>(except for the name attribute issues - done already). >>Unless someone of you complains on something in the meantime, I >>therefore plan to skip a release candidate, and release >>0.5 final on december 27. >> > > Hey Jan, I'm defintiely glad to see 0.5 is coming right along. I don't > know about the other guys, but I haven't tried 0.5b1 yet, and with the > holidays fast approaching, I likely wont until next week. So 0.5b1 won't > be tested as thoroughly as you want. > I don't know if that makes a big difference because I don't know what > changed between a1 and b1. Some changes to hierarchy extraction and hierarchical naming (again). There were no "hard" errors, the fix was only to make things more consistent in corner cases. All existing test continued to run unmodified. The resulting code is simpler (again) so I'm optimistic that all is well. But you never know. It would be good if someone could just run his existing simulation/ waveform trace/conversion. I only need to know that 0.5b1 version is not worse than the 0.5a1 :-) Of course it's a holiday season, so I can wait until 29 december for a release, but I want to get it out still this year. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: George P. <ge...@ga...> - 2005-12-22 22:24:52
|
Hi Jan, I thought the overview was a bit too much all at once, like drinking from a fire hose for a newbie :). However, I also thought it was well-composed and showed a strong grasp of the English language. A native speaker, I re-organized the content to make it catchier and easier to read. I also added a catchy one-sentence description up top. http://myhdl.jandecaluwe.com/doku.php/newoverview Thanks for your hard work. Feedback welcome! George |
From: George P. <ge...@ga...> - 2005-12-22 22:20:55
|
Hi Jan, I thought the original overview was a bit like drinking from a fire hose (for a newbie), though I also thought it was well-composed and showed an excellent grasp of the English language. A native speaker, I re-organized it to break up the content, make it a bi= t catchier, and also added a concise and catchy one-sentence description up top. http://myhdl.jandecaluwe.com/doku.php/newoverview Feedback welcome! George --=20 George Pantazopoulos http://www.gammaburst.net |
From: George P. <ge...@ga...> - 2005-12-22 15:41:05
|
> I don't plan to make further changes to the 0.5b1 code > (except for the name attribute issues - done already). > Unless someone of you complains on something in the meantime, I > therefore plan to skip a release candidate, and release > 0.5 final on december 27. > Hey Jan, I'm defintiely glad to see 0.5 is coming right along. I don't know about the other guys, but I haven't tried 0.5b1 yet, and with the holidays fast approaching, I likely wont until next week. So 0.5b1 won't be tested as thoroughly as you want. I don't know if that makes a big difference because I don't know what changed between a1 and b1. Next week would be a good time for a release, though, because people have time off work and that holiday stress would b= e over. > One thing I > want is a more appealing version of the Overview - as it's > the first thing new users will read. > > I have put a working version on the wiki here: > > http://myhdl.jandecaluwe.com/doku.php/newoverview > I take this to mean we, the great unwashed, can now edit it :) George Pantazopoulos http://www.gammaburst.net |
From: Jan D. <ja...@ja...> - 2005-12-22 14:43:15
|
Hi all: I don't plan to make further changes to the 0.5b1 code (except for the name attribute issues - done already). Unless someone of you complains on something in the meantime, I therefore plan to skip a release candidate, and release 0.5 final on december 27. I will only try to improve the documentation. One thing I want is a more appealing version of the Overview - as it's the first thing new users will read. I have put a working version on the wiki here: http://myhdl.jandecaluwe.com/doku.php/newoverview You can compare it to the old version to see differences. Feedback welcome. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2005-12-21 14:49:11
|
George Pantazopoulos wrote: >>>1) only be used for the output filename ("my_name.v") >>>2) also for the name of the actual toplevel Verilog module >>> >>>Prior to 0.5b1, option 2) was implemented. The problem is that >>>you may set it to a name which is already used elsewhere in the code, >>>creating a problem in the output. This is not checked by MyHDL. >>>So for 0.5b1, I though I needed to fix that and changed >>>it to option 1). > > > I prefer option 2, for consistency. Ok, option 2) it will be for 0.5 final. > Is there a fundamental reason that > myHDL can't check for a name clash? :) No, but thinking about it the problem is larger. It would be fairly easy to use Verilog keywords in MyHDL code, and create a problem in converted output. Currently, there are no checks. However, the symptoms would be clear (compilation error) and the workaround trivial. So I will defer a solution (if required) to later. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: George P. <ge...@ga...> - 2005-12-20 16:48:09
|
>> 1) only be used for the output filename ("my_name.v") >> 2) also for the name of the actual toplevel Verilog module >> >> Prior to 0.5b1, option 2) was implemented. The problem is that >> you may set it to a name which is already used elsewhere in the code, >> creating a problem in the output. This is not checked by MyHDL. >> So for 0.5b1, I though I needed to fix that and changed >> it to option 1). I prefer option 2, for consistency. Is there a fundamental reason that myHDL can't check for a name clash? :) --=20 George Pantazopoulos http://www.gammaburst.net |
From: Tom D. <td...@di...> - 2005-12-20 16:40:15
|
Jan Decaluwe wrote: > > 1) only be used for the output filename ("my_name.v") > 2) also for the name of the actual toplevel Verilog module > > Prior to 0.5b1, option 2) was implemented. The problem is that > you may set it to a name which is already used elsewhere in the code, > creating a problem in the output. This is not checked by MyHDL. > So for 0.5b1, I though I needed to fix that and changed > it to option 1). > > Now I'm confused and I think it's really 2) that designers > want, despite the potential name clash. I like option 2 better, but either way is OK. I think normally you expect the file name and module name to be the same. Tom |
From: Jan D. <ja...@ja...> - 2005-12-20 16:26:27
|
Hi: In beta release 0.5b1, I may have introduced a problem while trying to "fix" the behavior of toVerilog.name (and traceSignals.name). With toVerilog.name, you can set a name other than the default for the toplevel name. For example: toVerilog.name = "my_name" The question is: should that name be used 1) only be used for the output filename ("my_name.v") 2) also for the name of the actual toplevel Verilog module Prior to 0.5b1, option 2) was implemented. The problem is that you may set it to a name which is already used elsewhere in the code, creating a problem in the output. This is not checked by MyHDL. So for 0.5b1, I though I needed to fix that and changed it to option 1). Now I'm confused and I think it's really 2) that designers want, despite the potential name clash. Same issue for traceSignals.name, and the output VCD file. Feedback welcome, Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2005-12-20 08:19:52
|
George Pantazopoulos wrote: >>I have released beta release 0.5b1 (see development snapshots). >> > > > I'm looking forward to trying it out. Currently I'm having success with > synthesizing my myHDL code to FPGA with 0.5a1. > > What I'd really like to see is a changelog of important things changed > between each development snapshot. I noticed that the development snapshot > contains a CHANGES.txt, but the update history stops after 0.4.1. The > whatsnew0.5 page on the wiki is detailed and valuable, but I miss seeing > the chronological progression found in CHANGES.txt Since 0.5a1 (the alpha release), we are in feature freeze and bugfix mode - the intention is now just to make it work as advertised, and to get the docs correct. So there are no significant changes nor will there be until the 0.5 final release. For 0.5, the CHANGES.txt document will just contain a link to whatsnew0.5 that documents the changes extensively. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: George P. <ge...@ga...> - 2005-12-20 04:53:01
|
Hi all, I'm thrilled to report that I've been making great progress on my music synthesizer. I'd like to thank all of you who have been helping me, as well as Jan for making it possible! I updated my 65X81 synth project details in the wiki's Users & Projects. Link: http://myhdl.jandecaluwe.com/doku.php/projects Thanks! George |
From: George P. <ge...@ga...> - 2005-12-19 18:34:09
|
> I have released beta release 0.5b1 (see development snapshots). > I'm looking forward to trying it out. Currently I'm having success with synthesizing my myHDL code to FPGA with 0.5a1. What I'd really like to see is a changelog of important things changed between each development snapshot. I noticed that the development snapsho= t contains a CHANGES.txt, but the update history stops after 0.4.1. The whatsnew0.5 page on the wiki is detailed and valuable, but I miss seeing the chronological progression found in CHANGES.txt Thanks for the new release! George |
From: Jan D. <ja...@ja...> - 2005-12-19 14:22:16
|
Jan Decaluwe wrote: > Actually, you don't even need me for that - you can create new > wiki pages and you have the tex sources to start from if desirable. I just realize that my statement above is not true - I don't include the tex sources in a release. Sorry about that. The reason is just that the whole setup is not that simple and involves quite some directories and files - just overhead and potential confusion for the regular user. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2005-12-19 14:07:25
|
Hi: I have released beta release 0.5b1 (see development snapshots). I have adapted the manual. I had hoped to have a release candidate by now, but I found and fixed several issues while updating the manual, so I do a beta release first. Thanks for installing and trying the code if you have time. The snapshot now contains the manual (html and pdf), but no longer the whatsnew docs. As whatsnew0.5 now lives on the wiki, I thought it would be confusing to include old whatsnew docs in a release. I plan to do the same for the final release. I decided to simplify the first chapter and leave at that for a "tutorial" document. Many changes were made to the manual, and I still have to proofread it again. You can do so also from the snapshot, or on-line (see link in the development zone). All comments welcome. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Losbergenlaan 16, B-3010 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: George P. <ge...@ga...> - 2005-12-16 17:25:25
|
Hi all, I need to interface my FPGA with a device that has a tri-state data bus. (a FT245BM USB<->FIFO adapter). Do I still need to make a wrapper in Verilog, or is there a better approach now? Has anyone any examples/tips to share? Thanks, George |
From: <dan...@we...> - 2005-12-16 15:01:25
|
George Pantazopoulos wrote: > How do you automate it so the same file performs steps 1 and 2 in the > same run? Currently I have a unit test file that takes command-line > arguments. If I run "python module_ut.py -v" it does a myHDL-only > unittest. If I add the -cosim option, as in "python module_ut.py -v > -cosim" then it does a unit test w/cosimulation. So I need two seperate > runs w/different arguments. I use a Makefile to have it automatically > run steps 1 and 2 in sequence (as well as step #3). I'm interested in > eliminating the need for a pesky Makefile :) Let unittest do the job for you. What you can do is have different test cases that perform what your makefile is doing. A split might be here appropriate. So you have, I call it testbench code, that performs the test with your logic. In the first step this is the myhdl logic. This code will be the same whether you test myhdl for now or the verilog generated code later. Put this testbench code in a test case and run it. If that works, add a second unittest test case. This one will generate the verilog code and then run your testbench code again, this time with cosimulation. Here comes the beauty of myhdl, as you have one testbench that tests both myhdl and verilog code. To run the test, you just call your unittest file. If the project becomes more complex you can group them. At the end you only have one file that you call which will run all the tests. Have a look at the examples that come along with myhdl. I believe you just ran some to test you cosimulation. They show this grouping of test cases very nice. You can call them individual or all together, just depends on which file you start. Guenter |
From: <dan...@we...> - 2005-12-16 14:36:08
|
George Pantazopoulos wrote: > > Thanks Jan, I can try that. However, I'd rather not have to set any > environment variables. Are there other ways to accomplish this, as well? You could move the component library to the site-package folder of you python installation. Then it would be accessible from everywhere. If you don't like that, how about specifying a .pth file in the site-package folder, that points to the component library? Guenter |
From: George P. <ge...@ga...> - 2005-12-16 14:32:11
|
I'm sorry that the spacing and structure of my code got mangled during the posting process. Would you prefer another way to present the code? (put it in the wiki, for example?) Thanks, George |
From: George P. <ge...@ga...> - 2005-12-16 14:25:23
|
Tom Dillon wrote: > > It can't be stressed enough that the proper flow for logic design with > MyHDL is the following: > > 1. MyHDL logic unittest, used here and in steps 2 and 4. > 2. Apply unittest to toVerilog logic via cosimulation. > 3. toVerilog logic synthesis with your favorite synthesis tool. > 4. post synthesis unittest. > > If logic changes are required after step 4, all steps should be > repeated. Note, these can all be automated from the MyHDL unittest. > How do you automate it so the same file performs steps 1 and 2 in the same run? Currently I have a unit test file that takes command-line arguments. If I run "python module_ut.py -v" it does a myHDL-only unittest. If I add the -cosim option, as in "python module_ut.py -v -cosim" then it does a unit test w/cosimulation. So I need two seperate runs w/different arguments. I use a Makefile to have it automatically run steps 1 and 2 in sequence (as well as step #3). I'm interested in eliminating the need for a pesky Makefile :) Also, please critique the way I'm approaching unit tests currently. I've pasted all three of my test files below. I broke my unit test late last night, trying to consolidate the dut and the signals as class objects instead of per-test-case objects, and I decided to paste it as-is. I am in the process of making the bp2ram_ut.py and bp2ram_cosium.py generic so they can be used with any module. That means specifying the component name once somewhere and using some kind of macro substitution. However, I'm not sure how to do "macro substitution" with python. I'd like to be able to do something like what's seen in Makefiles: # generic_ut.py - not legal python - can something similar to this be done? COMPONENT = bp2ram from $(COMPONENT) import $(COMPONENT) import $(COMPONENT)_cosim $(COMPONENT) = $(COMPONENT)_cosim.$(COMPONENT) I would really appreciate any feeback, since I am new to python (and myHDL). Don't hold back :) Thanks, George /// Makefile pasted below //////// # George Pantazopoulos # python/myHDL + co-simulation Makefile # 15 Dec 2005 MODULE = bp2ram all: ut ut_cosim synth ut: $(MODULE).py $(MODULE)_ut.py python $(MODULE)_ut.py -v ut_cosim: $(MODULE).py $(MODULE)_ut.py $(MODULE)_cosim.py python $(MODULE)_ut.py -v -cosim synth: $(MODULE).py $(MODULE)_synthesis_test.py python $(MODULE)_synthesis_test.py -v clean: rm -f *.v //// End paste //////////////////////////// //// Excerpt of bp2ram_ut.py pasted below /// # George Pantazopoulos import os import sys import unittest from myhdl import Signal, intbv, Simulation, StopSimulation, delay from bp2ram import bp2ram import bp2ram_cosim as MODULE_cosim # ----------------------------------------------------------------------------- # Logic to select between running the unit test as myHDL-only or # with co-simulation # Options # ------- # use cosimulation? useCosim = False # search the list of command-line arguments for -cosim option for i in sys.argv: if i == "-cosim": useCosim = True break else: useCosim = False # ------- if useCosim == True: print "Running unit test with co-simulation." MODULE_cosim.makeHDLTestBench() # Import the alternate (co-simulation) definition of bp2ram # This overrides the "real" object import bp2ram_cosim bp2ram = bp2ram_cosim.bp2ram else: print "Running unit test as myHDL-only (no co-simulation)." # ----------------------------------------------------------------------------- # Unit test code # -------------- # Broken due to late night consolidation attempt :( class TestBp2ram(unittest.TestCase): def ClkGen(clk): while 1: clk.next = 0 yield delay(1) clk.next = 1 yield delay(1) clk = Signal(bool(0)) byteIn = Signal(intbv(0)[8:]) byteInRdy = Signal(bool(0)) dIn = Signal(intbv(0)[8:]) byteOut = Signal(intbv(0)[8:]) byteOutRdy = Signal(bool(0)) addrOut = Signal(intbv(0)[8:]) dOut = Signal(intbv(0)[8:]) we = Signal(bool(0)) state_out = Signal(intbv(0)[2:]) clkGen = ClkGen(clk=clk) dut = bp2ram(clk=clk, byteIn=byteIn, byteInRdy=byteInRdy, dIn=dIn, byteOut=byteOut, byteOutRdy=byteOutRdy, addrOut=addrOut, dOut=dOut, we=we, state_out=state_out) def setUp(self): # self.clk = Signal(bool(0)) # self.byteIn = Signal(intbv(0)[8:]) # self.byteInRdy = Signal(bool(0)) # self.dIn = Signal(intbv(0)[8:]) # self.byteOut = Signal(intbv(0)[8:]) # self.byteOutRdy = Signal(bool(0)) # self.addrOut = Signal(intbv(0)[8:]) # self.dOut = Signal(intbv(0)[8:]) # self.we = Signal(bool(0)) # self.state_out = Signal(intbv(0)[2:]) self.clk.next = 0 self.byteIn.next = 0 self.byteInRdy.next = 0 self.dIn.next = 0 self.byteOut.next = 0 self.byteOutRdy.next = 0 self.addrOut.next = 0 self.dOut.next = 0 self.we.next = 0 self.state_out.next = 0 # self.dut = bp2ram(clk=self.clk, byteIn=self.byteIn, byteInRdy=self.byteInRdy, dIn=self.dIn, # byteOut=self.byteOut, byteOutRdy=self.byteOutRdy, addrOut=self.addrOut, # dOut=self.dOut, we=self.we, state_out=self.state_out) def tearDown(self): self.dut = None self.clkGen = None # ----------------------------------------------------------------------------- def testCaseW1(self): """ W1: Check that control byte (MSB=1) followed by address byte sets addrOut """ yield delay(10) def test(clk, byteIn, byteInRdy, addrOut): inputBytes = [0xFF, 0x69, 0xA5] # Input the first two bytes in the input stream for i in range(2): byteIn.next = inputBytes[i] byteInRdy.next = 1 yield clk.posedge byteInRdy.next = 0 yield clk.posedge yield clk.posedge # Check this assertion self.assertEqual(addrOut, inputBytes[1]) yield delay(10) # Stop the simulation raise StopSimulation check = test(self.clk, self.byteIn, self.byteInRdy, self.addrOut) sim = Simulation(self.clkGen, self.dut, check) sim.run(quiet=1) # ----------------------------------------------------------------------------- def testCaseW2(self): """ W2: Check that the sequence of ctrlbyte (MSB=1), addrbyte, databyte sets dataOut when databyte is received """ yield delay(10) def test(clk, byteIn, byteInRdy, dOut): inputBytes = [0xFF, 0x69, 0xA5] # Input all the sample bytes for i in range(len(inputBytes)): byteIn.next = inputBytes[i] byteInRdy.next = 1 yield clk.posedge byteInRdy.next = 0 yield clk.posedge yield clk.posedge # Check this assertion self.assertEqual(dOut, inputBytes[2]) yield delay(10) # Stop the simulation raise StopSimulation check = test(self.clk, self.byteIn, self.byteInRdy, self.dOut) sim = Simulation(self.clkGen, self.dut, check) sim.run(quiet=1) # ----------------------------------------------------------------------------- def testCaseW3(self): yield delay(10) """ W3: Check that we is strobed after data to write is received """ def test(clk, byteIn, byteInRdy, dOut): inputBytes = [0xFF, 0x69, 0xA5] # "we" should be low at this point. self.assertEqual(we,False) # Input all the sample bytes for i in range(len(inputBytes)): byteIn.next = inputBytes[i] byteInRdy.next = 1 yield clk.posedge byteInRdy.next = 0 yield clk.posedge # "We" should be high on the next clock # Check this assertion self.assertEqual(we, True) yield clk.posedge # "we" should go low again next actual = we expected = False self.assertEqual(actual, expected) # Stop the simulation raise StopSimulation check = test(self.clk, self.byteIn, self.byteInRdy, self.dOut) sim = Simulation(self.clkGen, self.dut, check) sim.run(quiet=1) # ----------------------------------------------------------------------------- # def testCaseW4(self): # """ W4: Check that two back-to-back writes happen properly """ # # def test(clk, byteIn, byteInRdy, dOut, addrOut, we): # yield delay(10) # inputBytes = [0xFF, 0x69, 0xA5, 0x80, 0xF5, 0xAE] # # # "we" should be low at this point. # self.assertEqual(we,False) # # # Input all the sample bytes # for i in range(len(inputBytes)): # byteIn.next = inputBytes[i] # byteInRdy.next = 1 # yield clk.posedge # byteInRdy.next = 0 # yield clk.posedge # # # "We" should be high on the next clock # # # Check this assertion # self.assertEqual(we, True) # # # Check that dOut is the right value # self.assertEqual(dOut, inputBytes[5]) # # # Check that addrOut is correct # self.assertEqual(addrOut, inputBytes[4]) # # yield clk.posedge # # # "we" should go low again next # actual = we # expected = False # # self.assertEqual(actual, expected) # # # Stop the simulation # raise StopSimulation # # check = test(self.clk, self.byteIn, self.byteInRdy, self.dOut, self.addrOut, self.we) # # sim = Simulation(self.clkGen, self.dut, check) # sim.run(quiet=1) # ## ----------------------------------------------------------------------------- # # def testCaseR1(self): # """ R1: Check that control byte (MSB=0) followed by address byte # sets addrOut """ # # def test(clk, byteIn, byteInRdy, addrOut): # yield delay(10) # inputBytes = [0x7F, 0x69] # self.failUnless(inputBytes[0] < 0x80, 'ctrl byte MSB must = 0') # # Input the first two bytes in the input stream # for i in range(2): # byteIn.next = inputBytes[i] # byteInRdy.next = 1 # yield clk.posedge # byteInRdy.next = 0 # yield clk.posedge # # yield clk.posedge # # # Check this assertion # self.assertEqual(addrOut, inputBytes[1]) # # # Stop the simulation # raise StopSimulation # # check = test(self.clk, self.byteIn, self.byteInRdy, self.addrOut) # # sim = Simulation(self.clkGen, self.dut, check) # sim.run(quiet=1) # ## ----------------------------------------------------------------------------- # # def testCaseR2(self): # """ R2: Read from RAM side and set byteOut """ # # def test(clk, byteIn, byteInRdy, addrOut, byteOut, byteOutRdy, dIn): # yield delay(10) # # address = 0x01 # # # Pretend that a RAM is already outputting data # # at the target address # dIn.next = 0x69 # # # Read command # inputBytes = [0x7F, address] # self.failUnless(inputBytes[0] < 0x80, 'ctrl byte MSB must = 0') # # Input the first two bytes in the input stream # for i in range(2): # yield clk.posedge # byteIn.next = inputBytes[i] # byteInRdy.next = 1 # yield clk.posedge # byteInRdy.next = 0 # # # byteOutRdy should be false here # self.assertEqual(byteOutRdy, False) # # yield clk.posedge # # self.assertEqual(byteOutRdy, True) # # yield clk.posedge # # self.assertEqual(byteOutRdy, False) # # # Check this assertion # self.assertEqual(addrOut, inputBytes[1]) # # # RAM should be outputting data into our dIn, and that # # data should be passed to the UART side, as byteOut # # print "dIn = 0x%x" % dIn # self.assertEqual(byteOut, dIn) # # raise StopSimulation # # check = test(self.clk, self.byteIn, self.byteInRdy, self.addrOut, self.byteOut, self.byteOutRdy, self.dIn) # # sim = Simulation(self.clkGen, self.dut, check) # sim.run(quiet=1) # ## ----------------------------------------------------------------------------- # # def testCaseR3(self): # """ R3: Two back-to-back reads """ # # # def test(clk, byteIn, byteInRdy, addrOut, byteOut, byteOutRdy, dIn): # yield delay(10) # # address = 0x01 # # Pretend that a RAM is already outputting data # # at the target address # dIn.next = 0x69 # # # Read command # inputBytes = [0x7F, address] # self.failUnless(inputBytes[0] < 0x80, 'ctrl byte MSB must = 0') # # Input the first two bytes in the input stream # for i in range(2): # yield clk.posedge # byteIn.next = inputBytes[i] # byteInRdy.next = 1 # yield clk.posedge # byteInRdy.next = 0 # # # byteOutRdy should be false here # self.assertEqual(byteOutRdy, False) # # yield clk.posedge # # self.assertEqual(byteOutRdy, True) # # yield clk.posedge # # self.assertEqual(byteOutRdy, False) # # # Check this assertion # self.assertEqual(addrOut, inputBytes[1]) # # # RAM should be outputting data into our dIn, and that # # data should be passed to the UART side, as byteOut # # print "dIn = 0x%x" % dIn # self.assertEqual(byteOut, dIn) # ## --- Read #2 ---------------------------------------------------- # # address = 0x02 # # Pretend that a RAM is already outputting data # # at the target address # dIn.next = 0x71 # # # Read command # inputBytes = [0x50, address] # self.failUnless(inputBytes[0] < 0x80, 'ctrl byte MSB must = 0') # # Input the first two bytes in the input stream # for i in range(2): # yield clk.posedge # byteIn.next = inputBytes[i] # byteInRdy.next = 1 # yield clk.posedge # byteInRdy.next = 0 # # # byteOutRdy should be false here # self.assertEqual(byteOutRdy, False) # # yield clk.posedge # # self.assertEqual(byteOutRdy, True) # # yield clk.posedge # # self.assertEqual(byteOutRdy, False) # # # Check this assertion # self.assertEqual(addrOut, inputBytes[1]) # # # RAM should be outputting data into our dIn, and that # # data should be passed to the UART side, as byteOut # # print "dIn = 0x%x" % dIn # self.assertEqual(byteOut, dIn) # # raise StopSimulation # # check = test(self.clk, self.byteIn, self.byteInRdy, self.addrOut, self.byteOut, self.byteOutRdy, self.dIn) # # sim = Simulation(self.clkGen, self.dut, check) # sim.run(quiet=1) # # Don't do unittest.main() here, # it interferes with our command-line argument passing. Do this instead: suite = unittest.makeSuite(TestBp2ram) unittest.TextTestRunner(verbosity=2).run(suite) ////// End paste ////////////////////////////////////////////////////// /// bp2ram_cosim.py pasted below //// # George Pantazopoulos # myHDL Co-simulation support from myhdl import Cosimulation, Signal, intbv, toVerilog import os # For cosimulation, provide an alternate definition for device under test. def bp2ram(clk, byteIn, byteInRdy, dIn, byteOut, byteOutRdy, addrOut, dOut, we, state_out): cmd = "iverilog -o bp2ram bp2ram.v tb_bp2ram.v" os.system(cmd) return Cosimulation("vvp -m ./myhdl.vpi bp2ram", clk=clk, byteIn=byteIn, byteInRdy=byteInRdy, dIn=dIn, byteOut=byteOut, byteOutRdy=byteOutRdy, addrOut=addrOut, dOut=dOut, we=we, state_out=state_out) # ----------------------------------------------------------------------------- def makeHDLTestBench(): from bp2ram import bp2ram print "Generating Verilog testbench for co-simulation." clk = Signal(bool(0)) byteIn = Signal(intbv(0)[8:]) byteInRdy = Signal(bool(0)) dIn = Signal(intbv(0)[8:]) byteOut = Signal(intbv(0)[8:]) byteOutRdy = Signal(bool(0)) addrOut = Signal(intbv(0)[8:]) dOut = Signal(intbv(0)[8:]) we = Signal(bool(0)) state_out = Signal(intbv(0)[2:]) toVerilog.name = "bp2ram" toVerilog(bp2ram, clk=clk, byteIn=byteIn, byteInRdy=byteInRdy, dIn=dIn, byteOut=byteOut, byteOutRdy=byteOutRdy, addrOut=addrOut, dOut=dOut, we=we, state_out=state_out) print "Done generating Verilog testbench." /// End Paste /////////////////////////////////////////////////////////// |
From: George P. <ge...@ga...> - 2005-12-16 13:35:22
|
Thanks Jan, I can try that. However, I'd rather not have to set any environment variables. Are there other ways to accomplish this, as well? George > George Pantazopoulos wrote: > >> Hi all, >> >> I'd like to have a directory structure similar to the diagram below. >> I'd like to build a component library where each component and its >> unit test reside in its own directory. From outside the library >> directory I'd like to be able to import components into projects that >> integrate the various library components. (eg. computer.py would use >> the fifo, ram, and uart primitives). >> >> Can this be done with python? If so, what is a good, clean, and >> flexible way to accomplish this? I'd like to avoid specifying any >> kind of path name in the .py files, if possible. > > > You can use the library as a hierarchical Python package structure, > by adding __init__.py files to the (sub)directories, and adding the > top directory path to the PYTHONPATH environment variable. > > Jan > |