myhdl-list Mailing List for MyHDL (Page 154)
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: Christopher L. F. <cf...@uc...> - 2008-08-26 13:26:45
|
>>> >> >> There had been a discussion about that feature back in June of last >> year >> on this mailing list. Here is a link to the achieve of that: >> >> http://sourceforge.net/mailarchive/forum.php?forum_name=myhdl-list&max_rows=25&style=ultimate&viewmonth=200706 >> >> Jan had written some background information about the intention of >> intbv >> there in connection with the wrap around functionality. >> >> This might be a good question to be answered on the FAQ page. > > Ok, what about this: > > http://myhdl.jandecaluwe.com/doku.php/faq#how_do_i_describe_wrap-around_behaviour > Ok more on the wrap functionality. I know this has come up a couple times and may have been answered. The page referenced above has an example for an unsigned counter. In the case for signed values I don't think the mod works? As previously discussed the 2's complement wrap is often exploited in DSP. The solution thus far has been to design within limits (no wrapping). There are some scenarios that the resources required tends to using the 2's comp wrap. Below is an example that illustrates the mod function to support the wrap in MyHDL. I am missing how this can be applied to a signed value and still be convertible. I haven't been able to think of any elegant solutions other than handling a bunch of different cases to handle negatives. Increment Wrap Start Zero 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 Decrement Wrap Start Positive 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 Increment Wrap Start Negative -8 -8 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 Decrement Wrap Start Negative -1 -1 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 from myhdl import * Q = 3 L = 2**Q x = intbv(0, min=-L, max=L) print '\n\nIncrement Wrap Start Zero' for i in range(1, 11*L): print '%4d ' % x, x[:] = (x + 1) % L if i%15 == 0: print '' print '\n\nDecrement Wrap Start Positive' for i in range(1, 11*L): print '%4d ' % x, x[:] = (x - 1) % L if i%15 == 0: print '' print '\n\nIncrement Wrap Start Negative -%d' % L x[:] = -L for i in range(1, 11*L): print '%4d ' % x, x[:] = (x + 1) % L if i%15 == 0: print '' print '\n\nDecrement Wrap Start Negative -1' x[:] = -1 for i in range(1, 11*L): print '%4d ' % x, x[:] = (x - 1) % L if i%15 == 0: print '' |
From: Christopher L. F. <cf...@uc...> - 2008-08-26 13:13:05
|
I agree the repository works for development snapshots. The only thought would be for new users. Is it as easy to pull from the repository (new users not familiar with hg etc) as downloading a zip. I think there are enough instructions etc on the wiki and hg is python based for easy to install. The cost of entry is slightly more than downloading zip files. On Aug 26, 2008, at 4:29 AM, Günter Dannoritzer wrote: > Jan Decaluwe wrote: > ... >> >> Is it still meaningful to release development snapshots, now that >> there >> is a public mercurial repository? > > I think now that the repository is there, it is just fine to use it > for > following the latest development. > > Guenter > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Günter D. <dan...@we...> - 2008-08-26 09:29:35
|
Jan Decaluwe wrote: ... > > Is it still meaningful to release development snapshots, now that there > is a public mercurial repository? I think now that the repository is there, it is just fine to use it for following the latest development. Guenter |
From: Jan D. <ja...@ja...> - 2008-08-26 08:21:01
|
Andrew Lentvorski wrote: > Jan Decaluwe wrote: > >> For conversion, I can see an issue because during source code >> manipulation the decorator needs to be stripped off, and from the >> code this seems to assume a single-line decorator. It's a MyHDL >> conversion issue. > > Yep, that's exactly what it is. Again, a better error is probably > warranted. A "Python Syntax Error" shouldn't look the same as a "MyHDL > Python Syntax Error". What I meant with "issue" is that it's a bug. I don't have time now to look at it, but the culprit is probably the following regexp substitution in conversion/_analyze.py: s = re.sub(r"@.*", "", s) The intention it that this strips off decorators from a function's source code. This should be changed to work for any multiline decorator, but this doesn't look immediately trivial. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Andrew L. <bs...@al...> - 2008-08-25 20:45:32
|
Jan Decaluwe wrote: > For conversion, I can see an issue because during source code > manipulation the decorator needs to be stripped off, and from the > code this seems to assume a single-line decorator. It's a MyHDL > conversion issue. Yep, that's exactly what it is. Again, a better error is probably warranted. A "Python Syntax Error" shouldn't look the same as a "MyHDL Python Syntax Error". Here was the error I got and the code. Thanks, -a $ python test.py Traceback (most recent call last): File "test.py", line 45, in <module> test() File "test.py", line 42, in test ve = convert_RegisterFile() File "test.py", line 37, in convert_RegisterFile writeData0, writeAddress0, writeEnable0) File "/home/andrewl/local/lib/python/myhdl/_toVerilog/_convert.py", line 113, in __call__ genlist = _analyzeGens(arglist, h.absnames) File "/home/andrewl/local/lib/python/myhdl/_toVerilog/_analyze.py", line 130, in _analyzeGens ast = compiler.parse(s) File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/compiler/transformer.py", line 52, in parse return Transformer().parsesuite(buf) File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/compiler/transformer.py", line 129, in parsesuite return self.transform(parser.suite(text)) File "<string>", line 1 registerData[0x00], registerData[0x01]) ^ SyntaxError: invalid syntax #!/usr/bin/env python from myhdl import Signal, delay, always, instance, StopSimulation, now, traceSignals, \ Simulation, intbv, concat, enum, now, always_comb, toVerilog, instances def RegisterFile(gclk, grst, readPort0, readPort1, readPort2, readAddress0, readAddress1, readAddress2, writeData0, writeAddress0, writeEnable0): registerData = [Signal(intbv(0)[32:]) for ii in range(2)] @always(readAddress0, readAddress1, readAddress2, registerData[0x00], registerData[0x01]) def read(): readPort0.next = registerData[int(readAddress0)] readPort1.next = registerData[int(readAddress1)] readPort2.next = registerData[int(readAddress2)] @always(gclk.posedge) def write(): if writeEnable0: if writeAddress0 != 0: registerData[int(writeAddress0)].next = writeData0 return instances() def convert_RegisterFile(): (gclk, grst) = [Signal(bool(0)) for ii in range(2)] (readPort0, readPort1, readPort2, writeData0) = [Signal(intbv(0)[32:]) for ii in range(4)] (readAddress0, readAddress1, readAddress2, writeAddress0) = [Signal(intbv(0)[5:]) for ii in range(4)] writeEnable0 = Signal(bool(0)) rf = toVerilog(RegisterFile, gclk, grst, readPort0, readPort1, readPort2, readAddress0, readAddress1, readAddress2, writeData0, writeAddress0, writeEnable0) return instances() def test(): ve = convert_RegisterFile() if __name__ == '__main__': test() |
From: Jan D. <ja...@ja...> - 2008-08-25 20:04:52
|
Development version 0.6dev9 is available from here: http://myhdl.jandecaluwe.com/doku.php/dev:snapshots#snapshots This is the first one after the change to mercurial. (I noticed I forgot to tag the 2 previous development versions.) Is it still meaningful to release development snapshots, now that there is a public mercurial repository? Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2008-08-25 08:50:22
|
Andrew Lentvorski wrote: > I think it's been reported before, but placing a list of signals in an > activation list doesn't seem to work. No, but you can always construct a new sensitivity list from other lists and elements and use that. > However, I've got a more interesting issue. Since I can't put the list > into an activation list, I have to explicitly name every signal. > Annoying, but doable. Unfortunately, I can't seem to find a way to > split the line that Python likes. Since everything was inside a () > pair, I assumed that would work, but it doesn't seem to. Then I tried a > \ line extension operator, but that didn't work. > > How do I split an activation list across multiple lines? Are you talking about modeling or conversion? For conversion, I can see an issue because during source code manipulation the decorator needs to be stripped off, and from the code this seems to assume a single-line decorator. It's a MyHDL conversion issue. But for modelling, the methods you describe should work (as in pure Python). Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Steven D. <mo...@ya...> - 2008-08-24 06:48:50
|
Hi, I saw in the archives that someone had successfully performed myHDL/ncsim co-simulation. To avoind re-inventing the wheel, an anyone provide further information on this ? (i.e. any changes to c files, makefile, etc Thanks, Steven Send instant messages to your online friends http://uk.messenger.yahoo.com |
From: Andrew L. <bs...@al...> - 2008-08-23 20:45:05
|
I think it's been reported before, but placing a list of signals in an activation list doesn't seem to work. However, I've got a more interesting issue. Since I can't put the list into an activation list, I have to explicitly name every signal. Annoying, but doable. Unfortunately, I can't seem to find a way to split the line that Python likes. Since everything was inside a () pair, I assumed that would work, but it doesn't seem to. Then I tried a \ line extension operator, but that didn't work. How do I split an activation list across multiple lines? Thanks, -a Here's the code: def RegisterFile(gclk, grst, readPort0, readPort1, readPort2, readAddress0, readAddress1, readAddress2, writeData0, writeAddress0, writeEnable0): registerData = [Signal(intbv(0)[32:]) for ii in range(32)] # How do I split the following line? @always(readAddress0, readAddress1, readAddress2, registerData[0x00], registerData[0x01], registerData[0x02], registerData[0x03]) def read(): readPort0.next = registerData[int(readAddress0)] readPort1.next = registerData[int(readAddress1)] readPort2.next = registerData[int(readAddress2)] @always(gclk.posedge) def write(): if writeEnable0: if writeAddress0 != 0: registerData[int(writeAddress0)].next = writeData0 return instances() |
From: Günter D. <dan...@we...> - 2008-08-22 14:48:52
|
Hi, I am using gtkwave 3.1.10 and noticed that it does not display the enum() states of MyHDL properly. Anthony Bybell, the developer of gtkwave confirmed that there is an issue with the current version and that he will fix that. Meanwhile it is possible to load vcd files containing strings with the -L option. Guenter |
From: Jan D. <ja...@ja...> - 2008-08-21 10:21:04
|
Andrew Lentvorski wrote: > Jan Decaluwe wrote: >> I agree, and such a document isn't there yet. I believe all elements >> are available, but it's all implicit and scattered over the documentation >> and web site. > > Would you have a recommendation for a VHDL book that matches your > thinking (or even qualifies as good)? No, I'm not aware of any truly inspiring book about HDL design, either with Verilog or VHDL. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Vanheesbeke S. <Ste...@va...> - 2008-08-21 06:46:47
|
Jan, >why can't you do the bit processing in a single >generator on the bits of an input intbv? I do some serial adders and multipliers for pipelined calculations. I started some bottom up approach (defining an carry save adder) and then started connecting them together: that's where the list of signals comes in. I used the "from intbv to list of signals" and tried also to implement the other way, but I don't really need it at the moment. >Yes, but I'd like to avoid that if possible, and I still think it is. >A "real memory" is again an implementation concept. But the implementation >details may vary between target technologies, and I prefer synthesis >tools to infer that from a generic description. I don't mean a 'real memory' as an instance of a RAM block. I think the generic instance is a good idea, but only use it when the python source code uses a class that describes a memory. A list of signals can be split in separate signals (for example reg test[3] becomes test_0, test_1 and test[2]). On the other hand, it should be interesting if the converter can detect this automatically, if not, the language drops down towards a simpler HDL like Verilog or VHDL. -----Original Message----- From: myh...@li... [mailto:myh...@li...] On Behalf Of Jan Decaluwe Sent: woensdag 20 augustus 2008 10:23 To: myh...@li... Subject: Re: [myhdl-list] create intbv from list of bits Vanheesbeke Stefaan wrote: > Thanks for the effort. Indeed the proposed functionality can be done in > pure modeling, I needed something to explain the question. > > Maybe I'm thinking too much in hardware when writing something in > python. What else is a BYTE (Signal(intbv(0)[8:])) than a list of BITS > ([Signal(bool(0)) for i in range(8)]) from a hardware point of view. Too much hardware thinking is a general issue, also in VHDL and certainly in Verilog :-) The issue you raised is valid, and I need to solve it. However, now that you mention it, why can't you do the bit processing in a single generator on the bits of an input intbv? > Most of the time defining a list of signals is only a way of describing > connections that are held together in a single variable instead of > defining a real memory (address, data, ...). So maybe a real memory can > be described in a separate class to separate it from the 'list of > signals' behavior. Yes, but I'd like to avoid that if possible, and I still think it is. A "real memory" is again an implementation concept. But the implementation details may vary between target technologies, and I prefer synthesis tools to infer that from a generic description. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list ______________________________________________________________________ This email has been scanned by the Email Security System. ______________________________________________________________________ |
From: Andrew L. <bs...@al...> - 2008-08-20 18:31:50
|
Jan Decaluwe wrote: > I agree, and such a document isn't there yet. I believe all elements > are available, but it's all implicit and scattered over the documentation > and web site. Would you have a recommendation for a VHDL book that matches your thinking (or even qualifies as good)? I can go pull that from one of the local university libraries. I've seen quite a few VHDL books, but most of them kinda suck (to be fair, Verilog has the same issue). Thanks, -a |
From: Jan D. <ja...@ja...> - 2008-08-20 10:56:30
|
I think the introduction of decorators in MyHDL 0.5 has been a success, and by now everybody uses them. For pure modelling, you can construct generators in any way, including directly without decorators, and that will always remain so. However, some more implementation-oriented features, such as hierarchy extraction, signal tracing and conversion also contain support for non-decorator generators. This complicates the code considerably, and in my opinion, unnecessarily. Before adding new features, I would like to remove this support to simplify the code. Again, if you use decorators, everything should continue to work as before. Below I will describe the proposed changes in detail. Please review and give feedback about any objection. * remove 'processes' function This (undocumented) function is obsolete if you use decorators. It was deprecated in 0.5. * change 'instances' function to only return generators from decorators Currently 'instances' returns any kind of generator. Sometimes people may want to use a generator for other purposes than hardware description: currently you can't use 'instances' in that case. By only returning generators from decorators, this would become possible. * remove support for "top-level" generators Consider the degenerated case where the top-level is a generator: def top(): <generator_body> Hierarchy extraction, signal tracing and conversion have some special support for this, which I would like to remove. Note that the above is equivalent to: def top(): @instance def logic(): <generator_body> return logic * in general, assume that for hierarchy extraction, signal tracing and conversion, only generators from decorators need to be considered. There may be some more places in the code where this assumption can help to simplify things. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2008-08-20 09:40:39
|
Andrew Lentvorski wrote: > Jan Decaluwe wrote: > >> I don't think they do anything related to the issue that you >> had. Try something similar with plain Python, and you'll have the >> same issue. > > Actually, I understand the Python scoping rules pretty well. I've been > doing Python for a while. Then you must agree that the unbound local error you had is to be expected, with or without a MyHDL decorator. > The decorator actually causes certain things to be pulled into scope, > somehow (presumably when it works out the activation list). I need to > look at that. I don't think so, but let us know what you find. >> Any resemblance of MyHDL with Verilog is superficial. It's much >> closer to VHDL. This simply reflects my opinion that Verilog >> has some serious design flaws, such as the fact that there >> is no separation between signals and variables. So you are >> correct that you'll have to understand the MyHDL model >> for effective usage. > > Actually getting your thoughts about this would probably be helpful to > those of us coming from a Python/Verilog background. Sort of a "design > philosophy" thing to help make the mental transition smoother. I agree, and such a document isn't there yet. I believe all elements are available, but it's all implicit and scattered over the documentation and web site. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2008-08-20 09:28:18
|
Vanheesbeke Stefaan wrote: > Thanks for the effort. Indeed the proposed functionality can be done in > pure modeling, I needed something to explain the question. > > Maybe I'm thinking too much in hardware when writing something in > python. What else is a BYTE (Signal(intbv(0)[8:])) than a list of BITS > ([Signal(bool(0)) for i in range(8)]) from a hardware point of view. Too much hardware thinking is a general issue, also in VHDL and certainly in Verilog :-) The issue you raised is valid, and I need to solve it. However, now that you mention it, why can't you do the bit processing in a single generator on the bits of an input intbv? > Most of the time defining a list of signals is only a way of describing > connections that are held together in a single variable instead of > defining a real memory (address, data, ...). So maybe a real memory can > be described in a separate class to separate it from the 'list of > signals' behavior. Yes, but I'd like to avoid that if possible, and I still think it is. A "real memory" is again an implementation concept. But the implementation details may vary between target technologies, and I prefer synthesis tools to infer that from a generic description. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Vanheesbeke S. <Ste...@va...> - 2008-08-20 08:13:25
|
Thanks for the effort. Indeed the proposed functionality can be done in pure modeling, I needed something to explain the question. Maybe I'm thinking too much in hardware when writing something in python. What else is a BYTE (Signal(intbv(0)[8:])) than a list of BITS ([Signal(bool(0)) for i in range(8)]) from a hardware point of view. Most of the time defining a list of signals is only a way of describing connections that are held together in a single variable instead of defining a real memory (address, data, ...). So maybe a real memory can be described in a separate class to separate it from the 'list of signals' behavior. Stefaan -----Original Message----- From: myh...@li... [mailto:myh...@li...] On Behalf Of Jan Decaluwe Sent: dinsdag 19 augustus 2008 17:28 To: myh...@li... Subject: Re: [myhdl-list] create intbv from list of bits Ok, list of signal issues again :-) First of all, to be clear: what you want is easy enough to do in pure modeling. The issue, like often, is conversion with all its restrictions. After thinking about it, I don't see a way to do what you want without some kind of better support for lists of signals used inside generators. At some point, you'll need a for loop over all the members of the list in a single generator, to avoid multiple drivers to a signal. (I check on multiple drivers because synthesis wouldn't allow that anyway.) This issue is coming up regularly so I'll try to do something about it. I can't assess feasibility or timing just yet, but I think I have an idea to lift the current restrictions. The background issue is that Verilog memories have all kinds of restrictions, so you don't want to use them unless absolutely necessary. Currently this is enforced by a severe restriction: you can't use list syntax in a generator for a signal which is accessed as a plain signal in some other generator. It may be possible to detect whether a list is actually referenced inside a generator, and only declare it as a Verilog memory in that case. The result would be that everything that works now would continue to work unchanged, but now you would be able to use lists of signals inside generators in general. Jan Vanheesbeke Stefaan wrote: > Hi, > > > > For a bit manipulation functionality, I need to split an intbv into > induvidual bits (a list of signals). > > > > On the bits some configurable operations are done, and after this, I > need to create an intbv again. How can this be done in myhdl? > > > > I have a testcase with a simple inverter for each bit, so you get the > idea : > > > > First I get the induvidual bits with the GetBit() function. > > The bits are processed in Function() > > Then I need to stick the bits toghether again... > > > > Stefaan > > > > > > > > from myhdl import * > > > > def Function(input_, output_): > > @always_comb > > def f(): > > output_.next = not input_ > > return f > > > > def Connect(In, Out): > > @always_comb > > def connect(): > > Out.next = In > > return connect > > > > def GetBit(input_, bit, out): > > @always_comb > > def getbit(): > > out.next = input_[bit] > > return getbit > > > > def SetBit(input_, bit, out): > > @always_comb > > def setbit(): > > out.next[bit] = input_ > > return setbit > > > > > > def test(a, out): > > > > bits = len(a) > > a_list = [Signal(bool(0)) for i in range(bits)] > > result_list = [Signal(bool(0)) for i in range(bits)] > > > > retval = [] > > retval.extend([GetBit(a, i, a_list[i]) for i in > range(bits)]) > > retval.extend([Function(a_list[i], result_list[i]) for i in > range(bits)]) > > > > #need something here to create an intbv out that is a > concatination of the bits in result_list > > > > #setting a bit at a time : > > #retval.extend([SetBit(result_list[i], i, out) for i in > range(bits)]) > > #does not work :"Signal has multiple drivers : out" > > > > #passing a single bit af an intbv : > > #retval.extend([Connect(result_list[i], out[i]) for i in > range(bits)]) > > #does not work : "Port is not used : out" > > #and in the verilog description : "assign 0 = > retval_8_In;" > > > > return retval > > > > if __name__ == "__main__": > > a = Signal(intbv(0)[4:]) > > out = Signal(intbv(0)[4:]) > > toVerilog(test, a, out) > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------ - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com ------------------------------------------------------------------------ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ myhdl-list mailing list myh...@li... https://lists.sourceforge.net/lists/listinfo/myhdl-list ______________________________________________________________________ This email has been scanned by the Email Security System. ______________________________________________________________________ |
From: Andrew L. <bs...@al...> - 2008-08-19 20:15:25
|
Jan Decaluwe wrote: > I don't think they do anything related to the issue that you > had. Try something similar with plain Python, and you'll have the > same issue. Actually, I understand the Python scoping rules pretty well. I've been doing Python for a while. The decorator actually causes certain things to be pulled into scope, somehow (presumably when it works out the activation list). I need to look at that. > Any resemblance of MyHDL with Verilog is superficial. It's much > closer to VHDL. This simply reflects my opinion that Verilog > has some serious design flaws, such as the fact that there > is no separation between signals and variables. So you are > correct that you'll have to understand the MyHDL model > for effective usage. Actually getting your thoughts about this would probably be helpful to those of us coming from a Python/Verilog background. Sort of a "design philosophy" thing to help make the mental transition smoother. -a |
From: Jan D. <ja...@ja...> - 2008-08-19 16:33:51
|
Ok, list of signal issues again :-) First of all, to be clear: what you want is easy enough to do in pure modeling. The issue, like often, is conversion with all its restrictions. After thinking about it, I don't see a way to do what you want without some kind of better support for lists of signals used inside generators. At some point, you'll need a for loop over all the members of the list in a single generator, to avoid multiple drivers to a signal. (I check on multiple drivers because synthesis wouldn't allow that anyway.) This issue is coming up regularly so I'll try to do something about it. I can't assess feasibility or timing just yet, but I think I have an idea to lift the current restrictions. The background issue is that Verilog memories have all kinds of restrictions, so you don't want to use them unless absolutely necessary. Currently this is enforced by a severe restriction: you can't use list syntax in a generator for a signal which is accessed as a plain signal in some other generator. It may be possible to detect whether a list is actually referenced inside a generator, and only declare it as a Verilog memory in that case. The result would be that everything that works now would continue to work unchanged, but now you would be able to use lists of signals inside generators in general. Jan Vanheesbeke Stefaan wrote: > Hi, > > > > For a bit manipulation functionality, I need to split an intbv into > induvidual bits (a list of signals). > > > > On the bits some configurable operations are done, and after this, I > need to create an intbv again. How can this be done in myhdl? > > > > I have a testcase with a simple inverter for each bit, so you get the > idea : > > > > First I get the induvidual bits with the GetBit() function. > > The bits are processed in Function() > > Then I need to stick the bits toghether again... > > > > Stefaan > > > > > > > > from myhdl import * > > > > def Function(input_, output_): > > @always_comb > > def f(): > > output_.next = not input_ > > return f > > > > def Connect(In, Out): > > @always_comb > > def connect(): > > Out.next = In > > return connect > > > > def GetBit(input_, bit, out): > > @always_comb > > def getbit(): > > out.next = input_[bit] > > return getbit > > > > def SetBit(input_, bit, out): > > @always_comb > > def setbit(): > > out.next[bit] = input_ > > return setbit > > > > > > def test(a, out): > > > > bits = len(a) > > a_list = [Signal(bool(0)) for i in range(bits)] > > result_list = [Signal(bool(0)) for i in range(bits)] > > > > retval = [] > > retval.extend([GetBit(a, i, a_list[i]) for i in > range(bits)]) > > retval.extend([Function(a_list[i], result_list[i]) for i in > range(bits)]) > > > > #need something here to create an intbv out that is a > concatination of the bits in result_list > > > > #setting a bit at a time : > > #retval.extend([SetBit(result_list[i], i, out) for i in > range(bits)]) > > #does not work :"Signal has multiple drivers : out" > > > > #passing a single bit af an intbv : > > #retval.extend([Connect(result_list[i], out[i]) for i in > range(bits)]) > > #does not work : "Port is not used : out" > > #and in the verilog description : "assign 0 = > retval_8_In;" > > > > return retval > > > > if __name__ == "__main__": > > a = Signal(intbv(0)[4:]) > > out = Signal(intbv(0)[4:]) > > toVerilog(test, a, out) > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2008-08-19 09:08:40
|
Günter Dannoritzer wrote: > Andrew Lentvorski wrote: >> How do I add two unsigned intbv() objects such that the addition wraps >> around? >> >> Obviously, I can do the addition and then mask it and reassign like so: >> >> new = (old0 + old1) & 0xffff >> >> However, I doubt that is going to translate to verilog properly. > > There had been a discussion about that feature back in June of last year > on this mailing list. Here is a link to the achieve of that: > > http://sourceforge.net/mailarchive/forum.php?forum_name=myhdl-list&max_rows=25&style=ultimate&viewmonth=200706 > > Jan had written some background information about the intention of intbv > there in connection with the wrap around functionality. > > This might be a good question to be answered on the FAQ page. Ok, what about this: http://myhdl.jandecaluwe.com/doku.php/faq#how_do_i_describe_wrap-around_behaviour -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2008-08-19 08:32:06
|
Andrew Lentvorski wrote: > Jan Decaluwe wrote: >> Andrew Lentvorski wrote: >>> Could someone please explain to me what I'm doing wrong? I'm trying to >>> implement what would be a basic PC counter in a microprocessor. The >>> stage has two def's: pc_logic which should basically just be a >>> combinatorial adder and pc_flops which captures the state of the >>> combinatorial logic on an edge. >>> >>> Why doesn't this work? Worse, why does the one commented line throw a >>> UboundLocalError error? >> See Gunter's post for the answer in a MyHDL context. >> >> For clarity, I would like to add that the issue is conceptually not related >> to something MyHDL-specific, but to the semantics of assignment and >> local namespaces in Python. These work differently than in many other >> languages and it is important to understand this clearly. See also: >> >> http://www.network-theory.co.uk/docs/pytut/PythonScopesandNameSpaces.html > > Thanks for the reference. The decorator is clearly doing something > behind the scenes that I need to think about. To understand what the decorators do, see here: http://myhdl.jandecaluwe.com/doku.php/whatsnew:0.5#creating_generators_with_decorators I don't think they do anything related to the issue that you had. Try something similar with plain Python, and you'll have the same issue. It is true however that MyHDL pushes a style in which you define local (generator) functions inside another function (that defines the module). So issues with Python namespaces and scopes may emerge sooner than for other Python users. > There's no question that a lot of my issues are stupid. Both in terms > of being dumb mistakes (assigning to the variable rather than the > attribute) as well as due to having a faulty mental model of how MyHDL > works. Nothing stupid about it, we have all gone through the same issues. I'm convinced the Python learning curve is shorter than for many other languages, but it's still there. Of course MyHDL adds some additional complications, that may make things much harder. (I'm too close to know :-)) Any resemblance of MyHDL with Verilog is superficial. It's much closer to VHDL. This simply reflects my opinion that Verilog has some serious design flaws, such as the fact that there is no separation between signals and variables. So you are correct that you'll have to understand the MyHDL model for effective usage. Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Andrew L. <bs...@al...> - 2008-08-18 18:47:51
|
Jan Decaluwe wrote: > Andrew Lentvorski wrote: >> Could someone please explain to me what I'm doing wrong? I'm trying to >> implement what would be a basic PC counter in a microprocessor. The >> stage has two def's: pc_logic which should basically just be a >> combinatorial adder and pc_flops which captures the state of the >> combinatorial logic on an edge. >> >> Why doesn't this work? Worse, why does the one commented line throw a >> UboundLocalError error? > > See Gunter's post for the answer in a MyHDL context. > > For clarity, I would like to add that the issue is conceptually not related > to something MyHDL-specific, but to the semantics of assignment and > local namespaces in Python. These work differently than in many other > languages and it is important to understand this clearly. See also: > > http://www.network-theory.co.uk/docs/pytut/PythonScopesandNameSpaces.html Thanks for the reference. The decorator is clearly doing something behind the scenes that I need to think about. There's no question that a lot of my issues are stupid. Both in terms of being dumb mistakes (assigning to the variable rather than the attribute) as well as due to having a faulty mental model of how MyHDL works. I'll get there, but I'm definitely losing some productivity relative to my ability to write verilog. Hopefully, I'll see some of that gained back in writing tests. -a |
From: Vanheesbeke S. <Ste...@va...> - 2008-08-18 13:29:03
|
Hi, For a bit manipulation functionality, I need to split an intbv into induvidual bits (a list of signals). On the bits some configurable operations are done, and after this, I need to create an intbv again. How can this be done in myhdl? I have a testcase with a simple inverter for each bit, so you get the idea : First I get the induvidual bits with the GetBit() function. The bits are processed in Function() Then I need to stick the bits toghether again... Stefaan from myhdl import * def Function(input_, output_): @always_comb def f(): output_.next = not input_ return f def Connect(In, Out): @always_comb def connect(): Out.next = In return connect def GetBit(input_, bit, out): @always_comb def getbit(): out.next = input_[bit] return getbit def SetBit(input_, bit, out): @always_comb def setbit(): out.next[bit] = input_ return setbit def test(a, out): bits = len(a) a_list = [Signal(bool(0)) for i in range(bits)] result_list = [Signal(bool(0)) for i in range(bits)] retval = [] retval.extend([GetBit(a, i, a_list[i]) for i in range(bits)]) retval.extend([Function(a_list[i], result_list[i]) for i in range(bits)]) #need something here to create an intbv out that is a concatination of the bits in result_list #setting a bit at a time : #retval.extend([SetBit(result_list[i], i, out) for i in range(bits)]) #does not work :"Signal has multiple drivers : out" #passing a single bit af an intbv : #retval.extend([Connect(result_list[i], out[i]) for i in range(bits)]) #does not work : "Port is not used : out" #and in the verilog description : "assign 0 = retval_8_In;" return retval if __name__ == "__main__": a = Signal(intbv(0)[4:]) out = Signal(intbv(0)[4:]) toVerilog(test, a, out) |
From: Jan D. <ja...@ja...> - 2008-08-18 09:10:11
|
Andrew Lentvorski wrote: > Could someone please explain to me what I'm doing wrong? I'm trying to > implement what would be a basic PC counter in a microprocessor. The > stage has two def's: pc_logic which should basically just be a > combinatorial adder and pc_flops which captures the state of the > combinatorial logic on an edge. > > Why doesn't this work? Worse, why does the one commented line throw a > UboundLocalError error? See Gunter's post for the answer in a MyHDL context. For clarity, I would like to add that the issue is conceptually not related to something MyHDL-specific, but to the semantics of assignment and local namespaces in Python. These work differently than in many other languages and it is important to understand this clearly. See also: http://www.network-theory.co.uk/docs/pytut/PythonScopesandNameSpaces.html Regards, Jan -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |
From: Jan D. <ja...@ja...> - 2008-08-18 08:58:52
|
Excellent, looks like we're getting somewhere here! Günter Dannoritzer wrote: > Jan Decaluwe wrote: > ... > >> Based on previous experience, I'm quite reluctant to make big >> changes. Given that cver works with the method as implemented, >> I'm inclined to think that in principle Icarus should behave the >> same it Icarus vpi is done properly. > > I have filed a bug report (#2048463) for the cbValueChange issue on the > Icarus bug tracker. > > http://sourceforge.net/tracker/index.php?func=detail&aid=2048463&group_id=149850&atid=775997 > > One of the developers already confirmed some issues and also named the > vpiSuppressTime, which is the reason for the necessary change below: > >> I do see a difference that may be significant between the two >> files: >> >> // icarus stops on the following line but shouldn't >> // cb_data_s.value = &value_s; >> cb_data_s.value = NULL; >> > > In the bug report I also mentioned the time 0 issue, which is, that I > see a call back happening at time 0, when no signal assignment happens. > I got a reply that the Icarus developers discussed that before and if I > think that this is a wrong behavior I should file another bug report. > > I compared the Cver behavior with Riviera and both behave the same way. > If no signal assignment happens at time 0, there is no callback. I will > investigate that some more and then also file it as bug report. > > Guenter -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Kaboutermansstraat 97, B-3000 Leuven, Belgium From Python to silicon: http://myhdl.jandecaluwe.com |