Thread: [myhdl-list] Migen logic design toolbox - now with simulator
Brought to you by:
jandecaluwe
From: Sébastien B. <seb...@mi...> - 2012-03-12 13:25:59
|
Hi, A recurring (and well founded) comment on my Migen work was that some sort of simulator integration would be important. It's there now, and I would like to thank the people behind the RHINO project (http://www.rhinoplatform.org/) for sponsoring this feature. You can read about it and see some examples in the last section of the manual: http://milkymist.org/Migen.pdf Send technical questions and comments to the Milkymist mailing list at devel [AT] lists.milkymist.org and we will entertain them. Happy designing, Sébastien |
From: Christopher F. <chr...@gm...> - 2012-03-12 13:59:08
|
On 3/12/2012 8:19 AM, Sébastien Bourdeauducq wrote: > Hi, > > A recurring (and well founded) comment on my Migen work was that some > sort of simulator integration would be important. It's there now, and I > would like to thank the people behind the RHINO project > (http://www.rhinoplatform.org/) for sponsoring this feature. > > You can read about it and see some examples in the last section of the > manual: > http://milkymist.org/Migen.pdf > > Send technical questions and comments to the Milkymist mailing list at > devel [AT] lists.milkymist.org and we will entertain them. > > Happy designing, > Sébastien > Sebastien, Why do you spam this mailing list? .chris |
From: Sébastien B. <seb...@mi...> - 2012-03-12 14:12:37
|
On 03/12/2012 02:58 PM, Christopher Felton wrote: > Why do you spam this mailing list? I believe the topic is closely related (isn't it?), so this is not spam. |
From: Christopher F. <chr...@gm...> - 2012-03-12 14:43:04
|
On 3/12/2012 9:05 AM, Sébastien Bourdeauducq wrote: > On 03/12/2012 02:58 PM, Christopher Felton wrote: >> Why do you spam this mailing list? > > I believe the topic is closely related (isn't it?), so this is not spam. > Sure, there are many things "closely" related. If Mentor or Cadence were advertising their latest offerings here, I don't think anyone would object to calling it spam. So yes, it is spam it has nothing to do with MyHDL. It is different if projects that MyHDL interfaces/uses (Icarus, Python, pypy, etc) or projects that build off MyHDL post releases. This is not the case, you are simply exploiting this group for your own self interest. Regards, Chris |
From: Sébastien B. <seb...@mi...> - 2012-03-12 14:50:47
|
On 03/12/2012 03:42 PM, Christopher Felton wrote: > Sure, there are many things "closely" related. If Mentor or Cadence > were advertising their latest offerings here, I don't think anyone would > object to calling it spam. This software is just commercial and proprietary offerings about which you have no way to discuss. Migen is an open source project. This makes a lot of difference to me. > So yes, it is spam it has nothing to do with MyHDL. It is different if > projects that MyHDL interfaces/uses (Icarus, Python, pypy, etc) or > projects that build off MyHDL post releases. This is not the case, you > are simply exploiting this group for your own self interest. ...which is, in this case, discussing and building the best open source Python-based hardware description language and tools. I won't go after you if you "spam" our communication channels about the latest MyHDL features; in fact, if this brings about fruitful technical discussion, it would be welcome. I'd also be welcoming a Migen/MyHDL merger (no need to duplicate efforts) - but you rejected even the most simple patches from me - not my problem. Sébastien |
From: David G. <dsg...@gm...> - 2012-03-12 15:10:55
|
I like hearing about progress in the Python HDL front, whomever is doing it. I don't think it makes sense to fracture these already tiny communities. On Mon, Mar 12, 2012 at 10:44 AM, Sébastien Bourdeauducq <seb...@mi...> wrote: > On 03/12/2012 03:42 PM, Christopher Felton wrote: >> Sure, there are many things "closely" related. If Mentor or Cadence >> were advertising their latest offerings here, I don't think anyone would >> object to calling it spam. > > This software is just commercial and proprietary offerings about which > you have no way to discuss. Migen is an open source project. This makes > a lot of difference to me. > >> So yes, it is spam it has nothing to do with MyHDL. It is different if >> projects that MyHDL interfaces/uses (Icarus, Python, pypy, etc) or >> projects that build off MyHDL post releases. This is not the case, you >> are simply exploiting this group for your own self interest. > > ...which is, in this case, discussing and building the best open source > Python-based hardware description language and tools. I won't go after > you if you "spam" our communication channels about the latest MyHDL > features; in fact, if this brings about fruitful technical discussion, > it would be welcome. I'd also be welcoming a Migen/MyHDL merger (no need > to duplicate efforts) - but you rejected even the most simple patches > from me - not my problem. > > Sébastien > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Thomas H. <th...@ct...> - 2012-03-12 21:24:07
|
Am 12.03.2012 16:10, schrieb David Greenberg: > I like hearing about progress in the Python HDL front, whomever is > doing it. I don't think it makes sense to fracture these already tiny > communities. +1 from me too. Thomas |
From: Jan D. <ja...@ja...> - 2012-03-12 21:57:29
|
On 03/12/2012 10:23 PM, Thomas Heller wrote: > Am 12.03.2012 16:10, schrieb David Greenberg: >> I like hearing about progress in the Python HDL front, whomever is >> doing it. I don't think it makes sense to fracture these already tiny >> communities. > > +1 from me too. > > Thomas > What do you both mean? Obviously Migen "fractures" the community. Also, obviously they think they are making progress. Do you want to hear about it or not? -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: David G. <dsg...@gm...> - 2012-03-12 22:08:00
|
My meaning is that I'd prefer to be see announcements all over the Python/HDL landscape everywhere, rather than requiring me to sign up to each low-traffic mailing list separately. Even if now is not the time to merge MyHDL and Migen, perhaps next year (or the year after) is, and it's a good thing to keep discussion and ideas flowing between these 2 communities. On Mon, Mar 12, 2012 at 5:53 PM, Jan Decaluwe <ja...@ja...> wrote: > On 03/12/2012 10:23 PM, Thomas Heller wrote: >> Am 12.03.2012 16:10, schrieb David Greenberg: >>> I like hearing about progress in the Python HDL front, whomever is >>> doing it. I don't think it makes sense to fracture these already tiny >>> communities. >> >> +1 from me too. >> >> Thomas >> > > What do you both mean? Obviously Migen "fractures" > the community. Also, obviously they think they are making > progress. Do you want to hear about it or not? > > -- > Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com > Python as a HDL: http://www.myhdl.org > VHDL development, the modern way: http://www.sigasi.com > World-class digital design: http://www.easics.com > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
From: Bob C. <fl...@gm...> - 2012-03-13 01:07:52
|
On 03/12/2012 02:53 PM, Jan Decaluwe wrote: > On 03/12/2012 10:23 PM, Thomas Heller wrote: >> Am 12.03.2012 16:10, schrieb David Greenberg: >>> I like hearing about progress in the Python HDL front, whomever is >>> doing it. I don't think it makes sense to fracture these already tiny >>> communities. >> +1 from me too. >> >> Thomas >> > What do you both mean? Obviously Migen "fractures" > the community. Also, obviously they think they are making > progress. Do you want to hear about it or not? From my perspective as an HDL newbie (but a 30+ year engineering veteran otherwise), major feature development in MyHDL appears to have stalled, and Migen provides important capabilities MyHDL either lacks or can implement only with cumbersome and fragile kluges or work-arounds. (At least, that's what they look like to me, with my newbie eyes and brain.) MyHDL is more powerful overall, but Migen has attacked some specific problems is was designed to solve. Problems, IIRC, that were prompted by perceived weaknesses in MyHDL. As I understand it, Migen started as a rejected patch to MyHDL that was forced to find a life of its own. I believe Sébastien continues to post here not to diminish MyHDL or its use in any way, but instead to show at least one way to more easily do things that are difficult in MyHDL. If you look at his many non-Migen posts, you will see Sébastien has proven himself to be a very capable contributor to this list. My personal hope is that MyHDL and Migen will evolve toward one another, and eventually find ways to inter-operate, share features, or even merge capabilities. I fully expect MyHDL may one day make Migen obsolete, but that day does not seem to be coming any time soon. Until the parties involved agree to work together toward shared goals, it may be best for Migen to start its own list. When Sébastien gets his list going, he should be permitted to post sign-up instructions here. However, I hope a separate list won't be necessary: When Sébastien has referred to his own Migen posts in other forums (such as MilkyMist), he has referred people to *this* *list*. If anything, he has actively worked to increase MyHDL awareness, not to diminish it, or compete with it, or fracture it. To clear the air, perhaps we could have a Migen-MyHDL shoot-out, where Sébastien posts some of what Migen does best, and the MyHDL pros can show us how best to do it in MyHDL. The posts should be in the form of modules that can be integrated into other projects (MyHDL or Verilog or VHDL) for testing and comparison. I know it would prove to be extremely educational for me, and may serve us all to better understand the underlying issues. Sébastien/Migen has to be doing something right: It got Jan back on this list! Yay!!! -BobC |
From: Jan D. <ja...@ja...> - 2012-03-13 09:20:04
|
On 03/13/2012 02:07 AM, Bob Cunningham wrote: > From my perspective as an HDL newbie (but a 30+ year engineering > veteran otherwise), major feature development in MyHDL appears to > have stalled, and Migen provides important capabilities MyHDL either > lacks or can implement only with cumbersome and fragile kluges or > work-arounds. (At least, that's what they look like to me, with my > newbie eyes and brain.) Could you please provide a list of those important capabilities that MyHDL lacks in your opinion? -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Bob C. <fl...@gm...> - 2012-03-14 04:08:02
|
On 03/13/2012 02:19 AM, Jan Decaluwe wrote: > On 03/13/2012 02:07 AM, Bob Cunningham wrote: > >> From my perspective as an HDL newbie (but a 30+ year engineering >> veteran otherwise), major feature development in MyHDL appears to >> have stalled, and Migen provides important capabilities MyHDL either >> lacks or can implement only with cumbersome and fragile kluges or >> work-arounds. (At least, that's what they look like to me, with my >> newbie eyes and brain.) > Could you please provide a list of those important capabilities > that MyHDL lacks in your opinion? I must admit I set MyHDL aside a few months ago after having daunting problems getting my 'simple' systems to work (mainly trying to glue together components from Open Cores). I had trouble writing useful MyHDL, and I found that one of my 'glue' problems, a Wishbone interface, had a simpler solution (from my perspective) in Migen. It could have been a unique or special case, I don't know enough yet to tell: I haven't solved all my other problems with this project. Another project idea, a dataflow signal processor for a 'flying pixel' camera, had me spending all my initial design time working on the interface between the dataflow stages (simple in software, harder in hardware) rather than on the content of each stage. Though I haven't implemented anything yet, it seems to me that Migen may make such interfaces easier. However, the sum of my difficulties showed me that I lacked the perspective and depth needed to make proper use of MyHDL, so I'm taking some time to extend my hardware skills, to design some circuits and boards. Back to schematic capture, device specs, board layout, and using an o'scope and logic analyzer. I understand using gates (bits), and I understand using chips (interfaces). It's the stuff in between that I'm having problems with. From my limited perspective, it seems to me that Migen does particularly well with interfaces, and the distinct separation between sequential and combinatorial logic seems to fit my current thought processes. I have no idea how far I can go with Migen compared to MyHDL. But the initial learning curve, with the goal of making my Spartan 3E board do fun and useful things, for the moment seems to favor Migen over MyHDL. But I am well aware that situation may not persist as my knowledge and experience grow. I have no intention of abandoning MyHDL: I closely monitor this list, and I periodically review the MyHDL documentation (especially the examples) to see if my comprehension has grown. Perhaps Migen makes FPGA development feel more like building with Legos: It makes it easy(er) to create parts and click them together. I suspect MyHDL may more like a machine shop: More skill is required to make use of it, but there may be no limit to what can be built, such as a Lego factory. Migen feels more newbie-friendly, while MyHDL may be more attractive to battle-weary V*HDL veterans. Migen is FPGA-centric, while MyHDL is fully ASIC-capable. Migen sometimes implements features inelegantly, while MyHDL excludes inelegant features. Practicality vs purity. High-level abstractions vs low-level power. Bottom line, I suspect both tools have their place, and share enough common premises that it is a mistake to view one as competing with or detracting from the other: Both agree the V*HDLs have limitations, both agree Python is a great tool for implementing HDLs. Each chooses a different approach, provides differing capabilities, targets a slightly different domain, and may attract different groups of users, all of which appears to me to be more complimentary than competitive. I don't see how there can be any need to push Migen and MyHDL apart: I think they should stand back-to-back and show the V*HDLs better ways to fill FPGAs. More like siblings who occasionally argue, than any kind of enemy. -BobC |
From: Jan D. <ja...@ja...> - 2012-03-16 21:03:50
|
My conclusion is that Migen found an easy target in you, as a newbie, to confuse you. It made you think it can be used for serious design work. But it cannot - unless all you need is a sophisticated generator of concurrent statements and a single clock. That is all Migen really is (and then it added some horrible design choices despite having a good example). For serious design work, procedural support alongside concurrent semantics is essential. Not just for test benches and high level modeling (of course) but also for synthesizable code. When Migen claims that the "event-driven" paradigm is too general, what it really dumps is procedural support in your HDL descriptions - the interesting stuff. What you (and many Verilog/VHDL designers, and Migen's designers) miss is the role of RTL/logic synthesis. It is much more than technology mapping. It can handle procedural descriptions quite well, including features such as register inferencing from procedural variables. It enables you to move the abstraction level a little higher by thinking about (admittedly low-level) *code* instead of gates. Unfortunately, I cannot direct you to a good introductory text explaining all this in a decent way, even though those techniques are more than 20 years old. I will eventually get to this in my blog, in which I already discussed some background. http://www.sigasi.com/janhdl On 03/14/2012 05:07 AM, Bob Cunningham wrote: > On 03/13/2012 02:19 AM, Jan Decaluwe wrote: >> On 03/13/2012 02:07 AM, Bob Cunningham wrote: >> >>> From my perspective as an HDL newbie (but a 30+ year engineering >>> veteran otherwise), major feature development in MyHDL appears >>> to have stalled, and Migen provides important capabilities MyHDL >>> either lacks or can implement only with cumbersome and fragile >>> kluges or work-arounds. (At least, that's what they look like to >>> me, with my newbie eyes and brain.) >> Could you please provide a list of those important capabilities >> that MyHDL lacks in your opinion? > > I must admit I set MyHDL aside a few months ago after having daunting > problems getting my 'simple' systems to work (mainly trying to glue > together components from Open Cores). I had trouble writing useful > MyHDL, and I found that one of my 'glue' problems, a Wishbone > interface, had a simpler solution (from my perspective) in Migen. It > could have been a unique or special case, I don't know enough yet to > tell: I haven't solved all my other problems with this project. > > Another project idea, a dataflow signal processor for a 'flying > pixel' camera, had me spending all my initial design time working on > the interface between the dataflow stages (simple in software, harder > in hardware) rather than on the content of each stage. Though I > haven't implemented anything yet, it seems to me that Migen may make > such interfaces easier. > > However, the sum of my difficulties showed me that I lacked the > perspective and depth needed to make proper use of MyHDL, so I'm > taking some time to extend my hardware skills, to design some > circuits and boards. Back to schematic capture, device specs, board > layout, and using an o'scope and logic analyzer. > > I understand using gates (bits), and I understand using chips > (interfaces). It's the stuff in between that I'm having problems > with. From my limited perspective, it seems to me that Migen does > particularly well with interfaces, and the distinct separation > between sequential and combinatorial logic seems to fit my current > thought processes. > > I have no idea how far I can go with Migen compared to MyHDL. But > the initial learning curve, with the goal of making my Spartan 3E > board do fun and useful things, for the moment seems to favor Migen > over MyHDL. > > But I am well aware that situation may not persist as my knowledge > and experience grow. I have no intention of abandoning MyHDL: I > closely monitor this list, and I periodically review the MyHDL > documentation (especially the examples) to see if my comprehension > has grown. > > Perhaps Migen makes FPGA development feel more like building with > Legos: It makes it easy(er) to create parts and click them together. > I suspect MyHDL may more like a machine shop: More skill is required > to make use of it, but there may be no limit to what can be built, > such as a Lego factory. > > Migen feels more newbie-friendly, while MyHDL may be more attractive > to battle-weary V*HDL veterans. Migen is FPGA-centric, while MyHDL > is fully ASIC-capable. Migen sometimes implements features > inelegantly, while MyHDL excludes inelegant features. Practicality > vs purity. High-level abstractions vs low-level power. > > Bottom line, I suspect both tools have their place, and share enough > common premises that it is a mistake to view one as competing with or > detracting from the other: Both agree the V*HDLs have limitations, > both agree Python is a great tool for implementing HDLs. Each > chooses a different approach, provides differing capabilities, > targets a slightly different domain, and may attract different groups > of users, all of which appears to me to be more complimentary than > competitive. > > I don't see how there can be any need to push Migen and MyHDL apart: > I think they should stand back-to-back and show the V*HDLs better > ways to fill FPGAs. More like siblings who occasionally argue, than > any kind of enemy. > > > -BobC > > > ------------------------------------------------------------------------------ > > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Sébastien B. <seb...@mi...> - 2012-03-17 01:22:13
|
On 03/16/2012 10:03 PM, Jan Decaluwe wrote: > When Migen claims that the "event-driven" paradigm is > too general, what it really dumps is procedural support > in your HDL descriptions - the interesting stuff. This isn't entirely fair (I will not even mention the impolite bits above). First, procedures in V*HDL can often be easily converted to bits of Python code that manipulate the lower layer bits - admittedly in a less elegant way (though perhaps easier to understand), but it can be done. Second, for synthesis those procedures always need to "execute" in one clock cycle, which seriously limits their real usefulness. Also, this while thing has little to do with event-driven vs. cycle-based. S. |
From: Jan D. <ja...@ja...> - 2012-03-18 22:11:15
|
On 03/17/2012 02:15 AM, Sébastien Bourdeauducq wrote: > On 03/16/2012 10:03 PM, Jan Decaluwe wrote: >> When Migen claims that the "event-driven" paradigm is >> too general, what it really dumps is procedural support >> in your HDL descriptions - the interesting stuff. > > This isn't entirely fair (I will not even mention the impolite bits > above). First, procedures in V*HDL can often be easily converted to bits > of Python code that manipulate the lower layer bits - admittedly in a > less elegant way (though perhaps easier to understand), but it can be > done. Second, for synthesis those procedures always need to "execute" in > one clock cycle, which seriously limits their real usefulness. With "procedural support" I am not referring to procedures. Rather, I am using the word "procedural" to refer to statements whose order matters, as opposed to "concurrent" statements. The VHDL terminology is "sequential" but this word can be confusing also (as it also used to refer to clocked behavior.) > Also, > this while thing has little to do with event-driven vs. cycle-based. The relevant feature is whether events are explicit (VHDL, Verilog, MyHDL) or implicit (Migen et al). In practice, all HDLs with explicit events that I know of support procedural semantics, and none of the HDLs with implicit events that I know of do so. In particular, Migen has concurrent semantics only. The lack of procedural semantics is a showstopper. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Christopher L. <loz...@fr...> - 2012-03-18 22:43:34
|
On 3/18/12 5:10 PM, Jan Decaluwe wrote: > The relevant feature is whether events are explicit (VHDL, Verilog, MyHDL) > or implicit (Migen et al). In practice, all HDLs with explicit events > that I know of support procedural semantics, and none of the HDLs > with implicit events that I know of do so. > > In particular, Migen has concurrent semantics only. The lack of > procedural semantics is a showstopper. > Thank you so much Jan. This is what I was looking for. A very high level view of what the difference is between the two approaches. Let us see if the Migen people agree with your characterization. Actually in my case, I think I am only interested in the concurrent semantics, not the procedural ones so I will now go and take a closer look at the Migen documents. I could be wrong. As I get into detailed designs, perhaps I will also need the procedural approach. Maybe I will even switch back and forth a few times. In any case I would like to thank you for allowing the Migen people to speak on this list. I certainly learned a lot from the back and forth debate. From the global perspective, the guys trying to design chips with python are a single group of people. And I understand that if you are a hardcore Migen or MyHDL person, they appear to be two different communities. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
From: Sébastien B. <seb...@mi...> - 2012-03-19 09:13:20
|
On 03/18/2012 11:10 PM, Jan Decaluwe wrote: > With "procedural support" I am not referring to procedures. > Rather, I am using the word "procedural" to refer to statements whose > order matters, as opposed to "concurrent" statements. The VHDL > terminology is "sequential" but this word can be confusing also > (as it also used to refer to clocked behavior.) If you are talking about VHDL variables / blocking Verilog assignments that can be used to synthesize sequential code that "executes" in one cycle, then they are supported too (with the "variable" property of the Signal object). For sequential test bench code, you can use e.g. Python generators as in the Wishbone example from the doc. Anything else that I missed? Sébastien |
From: Jan D. <ja...@ja...> - 2012-03-19 13:27:39
|
On 03/19/2012 10:06 AM, Sébastien Bourdeauducq wrote: > For sequential test bench code, you can use e.g. Python generators as in > the Wishbone example from the doc. Sure, one can argue that Migen is for synthesizable code only, and for the rest we have Python, so that's OK, isn't it? Well, no. Look at the test bench code versus Migen code and note that the modeling paradigm is entirely different. But in practice, today's high-level model that is part of the verification environment becomes tomorrow's synthesizable model and vice versa. Very often, this even happens within the same project. Refinements may be necessary, but always within the same modeling paradigm. Having to switch between modeling paradigms depending on the particular view is unnatural and leads no needless modeling effort duplication. The great advantage of the event-driven paradigm is that it is general enough to provide a single modeling paradigm for any type of logic. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Sébastien B. <seb...@mi...> - 2012-03-21 09:57:58
|
On 03/21/2012 10:43 AM, Sébastien Bourdeauducq wrote: > comb += [If(a[i], pos.eq(i)) for i in downrange(a.bv.width)] Of course, it should be "range" here, not "downrange". S. |
From: Jan D. <ja...@ja...> - 2012-03-21 16:54:06
|
On 03/21/2012 10:51 AM, Sébastien Bourdeauducq wrote: > On 03/21/2012 10:43 AM, Sébastien Bourdeauducq wrote: >> comb += [If(a[i], pos.eq(i)) for i in downrange(a.bv.width)] > > Of course, it should be "range" here, not "downrange". Apart from my other, more fundamental objections: no, not OK. In a circuit that checks the MSB position I want to check the MSB first, and set the position once by stopping as soon as it is found. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Jan D. <ja...@ja...> - 2012-03-21 11:24:01
|
On 03/21/2012 10:43 AM, Sébastien Bourdeauducq wrote: > Hi, > > On 03/19/2012 01:30 PM, Jan Decaluwe wrote: >>> If you are talking about VHDL variables / blocking Verilog assignments >>> that can be used to synthesize sequential code that "executes" in one >>> cycle, then they are supported too (with the "variable" property of the >>> Signal object). >> >> That is what I call "horrible". These things are confusing enough, >> even in VHDL that makes a clear distinction between signals >> and variables. MyHDL improves further on this by using a >> dedicated, distinctive attribute assignment for Signal >> assignment. > > Well, it's just a small detail, no need to break such a fuss about it. Only someone with too much Verilog exposure could say that. The confusion about this small detail (because of the way Verilog handles it) is the single most important cause of why HDL-based design doesn't live up to its potential. As you know, in Verilog, procedural techniques are virtually banned from clocked processes, for no good reason except the confusion about this "detail". > What would you propose then? replace the "variable" property simply with > the use of a different assignment? or enforce that another assignment > method is used when the "variable" property is set? If it's such a small detail, I don't see why you want to take HDL design lessons from me. >> def MsbDetector(pos, a): >> """Return the bit position of the msb.""" >> >> @always_comb >> def logic(): >> pos.next = 0 >> for i in downrange(len(a)): >> if a[i] == 1: >> pos.next = i >> break >> >> return logic > > (...) > >> How would this look like in Migen? > > comb += [If(a[i], pos.eq(i)) for i in downrange(a.bv.width)] Did you simulate this? Because I think you missed the break, didn't you? Of course, I can't tell for sure because who knows how you handle the statement order in that list. I will give a free language (*any* language) design tip then: when the statement order matters, it should visually stand out. Of course it should. > Notes: > 1. the default 0 is implicit (reset value of a combinatorial signal) > 2. you can build the pos signal with the right size using bits_for: > pos = Signal(BV(bits_for(a.bv.width-1))) > 3. we should add len() support for signals, thanks for the reminder :) > 4. you can either assume the synthesizer will automagically build an > optimized structure (it doesn't always), or use a bit more control, as in: > http://www.ohwr.org/projects/tdc-core/repository/revisions/master/entry/core/tdc_lbc.vhd > It's VHDL, but you could do the same with Migen too. > >> So far for elegance > > One line :) Execpt it doesn't work I think. And since when are one-liners synonymous to elegance? Often they are the opposite: obfuscation that leads to hard-to-catch errors, as in this case. >> and parametrizability. > > In this example, it's just as parametrizable as yours. In general, Migen > is more parametrizable than MyHDL. That must be true, for those who like to break up their design into concurrent statements themselves. I prefer to leave that work to a synthesis tool. > Let's have another simple example: > how would you parametrize the number of wait states (removing them > entirely when the parameter is 0) at different points of a FSM? A wait state and a wait state counter with a variable end count. >> Well, no. Look at the test bench code versus Migen code and >> note that the modeling paradigm is entirely different. >> But in practice, today's high-level model that is part >> of the verification environment becomes tomorrow's >> synthesizable model and vice versa. > > Following the same logic, you could say that all hardware and software > designs should be written using high level languages such as Python, > Ruby or Lisp normally, and hope that one day some magical synthesizer > will make them fast and optimized on FPGA, ASIC and CPU. Given that Lisp > is still slow more than 50 years after its invention, let me have doubts > about this position. I am not talking about the uncertain future either. I am talking about models that are not initially intended for synthesis, and evolve to that requirement later. > Or you can be pragmatic and do things like Migen. > >> Very often, this even happens within the same project. > > Can you give some examples? Virtually any telecom chip where the TX side is verified by looping back the RX side and vice versa. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Sébastien B. <seb...@mi...> - 2012-03-21 11:27:15
|
On 03/21/2012 12:23 PM, Jan Decaluwe wrote: > Because I think you missed the break, didn't you? Yes I did, see my next email. > Of course, > I can't tell for sure because who knows how you handle the > statement order in that list. Just like Verilog/VHDL - last statement sets the value. Sébastien |
From: Bob C. <fl...@gm...> - 2012-03-17 20:21:08
|
On 03/16/2012 02:03 PM, Jan Decaluwe wrote: > My conclusion is that Migen found an easy target in > you, as a newbie, to confuse you. It made you think it > can be used for serious design work. Sorry, Jan. If I have to be "confused" to play with my FPGA, then so be it. I'm very "serious" about being able to play with my FPGA! Your statement has an obvious implicit context: To me, you are shouting, "MyHDL is for Serious Designers Only! Newbies and Pragmatists should Go Away!" If that's what you are saying, then please be direct: Don't attack Migen for being what it was intentionally created to be, or for being something MyHDL is not intended to be. Are you upset about Migen existing, or that there is an audience MyHDL can't help as well as Migen may be able to? If you'd rather beginners like myself go elsewhere, just say so. Remember, Migen wasn't created to be useful to beginners: It was created by an experienced FPGA designer concerned about practicality and productivity for a specific Open Source hardware project. It simply happened that some things became a bit clearer to me after looking at Migen and the problems it was created to address. Whatever Migen leaves out may have been what was getting in my way! I'm actually quite lazy: What is the *least* I need to know to make useful digital designs *now*? I'm a beginner: Though I'd love to someday be able to design circuits like Shakespeare wrote sonnets, I'd be more than happy today if I were able to work at the level of "Green Eggs and Ham", a true masterpiece written with an absolute minimum of linguistic complexity. > When Migen claims that the "event-driven" paradigm is > too general, what it really dumps is procedural support > in your HDL descriptions - the interesting stuff. What's "interesting" to you can be a frustrating block for a newbie. I hope to one day also be very interested in those aspects of MyHDL, but it seems to have little to do with what I want to get done today, which is to find the simplest path to get basic circuits out of my mind and in to my FPGA. Then use them as building-blocks in my hobby projects. > Unfortunately, I cannot direct you to a good introductory > text explaining all this in a decent way, even though those > techniques are more than 20 years old. I will eventually > get to this in my blog, in which I already discussed some > background. > > http://www.sigasi.com/janhdl I *love* the way you write! I've read every word of yours I could find, and I will very gladly read every new thing you share. If you provide a new example, I will faithfully follow it. If you direct me to a helpful reference, I will study it. Most importantly, if you ever write an introductory digital design text that uses MyHDL both as an instructional language and as an implementation language, then I promise to be first in line to buy a copy. I will volunteer in any way I can to help create that book, from proofreading (for grammar and flow, not technical content) to working the examples and attempting the exercises. I am *totally* behind MyHDL! You may recall that I was first to post here about using the updated PyPy to pass 100% of the MyHDL test suite. It was a simple thing, but I do try to help where I can. I also greatly respect every bit of the work you're doing: When I wanted to talk to other EEs about MyHDL, I first asked you about the correct pronunciation of your name. I believe you have made an important contribution by creating MyHDL, and I want others to know about it. I am a MyHDL fan. Unfortunately, I simply remain unable to use MyHDL to accomplish my own immediate hobby needs. That does not indicate any flaw in MyHDL, merely the extent my own limitations. Do not be surprised that I am interested in any tool that helps me circumvent those limitations! I actually *like* how Migen slices and dices the process of FPGA design: The parts that are left out are ones I doubt newbies like me would notice, much less care about, until confronted with unusually challenging designs. I suspect Sebastien would agree with much of your analysis, the proper response being: "So What?" It's not about theoretical power or completeness: It's about barriers to entry. It's not about what I can do in 5 years, but about what I can do in 5 weeks. Migen is primarily about pragmatism and productivity, making powerful circuits quickly and easily, and far less about expert capabilities, theoretical purity or even consistency. I seek tools that will help me do what I want to get done today, and so far Migen seems like it will be most useful. Tomorrow will likely require additional tools, and I *absolutely* expect (and want) MyHDL to the first of those tools. It is not an either-or proposition: I want Migen *and* MyHDL. I realize MyHDL will take more time to master, and I'm willing to commit that time. But I also want to create something sooner, rather than later. And I believe that 100% of what I learn using Migen will later prove useful with MyHDL. I believe using Migen will keep me motivated toward learning MyHDL. Right next to me I have a Spartan 3E-500 that contains nothing of my own design. That must change! -BobC > On 03/14/2012 05:07 AM, Bob Cunningham wrote: >> On 03/13/2012 02:19 AM, Jan Decaluwe wrote: >>> On 03/13/2012 02:07 AM, Bob Cunningham wrote: >>> >>>> From my perspective as an HDL newbie (but a 30+ year engineering >>>> veteran otherwise), major feature development in MyHDL appears >>>> to have stalled, and Migen provides important capabilities MyHDL >>>> either lacks or can implement only with cumbersome and fragile >>>> kluges or work-arounds. (At least, that's what they look like to >>>> me, with my newbie eyes and brain.) >>> Could you please provide a list of those important capabilities >>> that MyHDL lacks in your opinion? >> I must admit I set MyHDL aside a few months ago after having daunting >> problems getting my 'simple' systems to work (mainly trying to glue >> together components from Open Cores). I had trouble writing useful >> MyHDL, and I found that one of my 'glue' problems, a Wishbone >> interface, had a simpler solution (from my perspective) in Migen. It >> could have been a unique or special case, I don't know enough yet to >> tell: I haven't solved all my other problems with this project. >> >> Another project idea, a dataflow signal processor for a 'flying >> pixel' camera, had me spending all my initial design time working on >> the interface between the dataflow stages (simple in software, harder >> in hardware) rather than on the content of each stage. Though I >> haven't implemented anything yet, it seems to me that Migen may make >> such interfaces easier. >> >> However, the sum of my difficulties showed me that I lacked the >> perspective and depth needed to make proper use of MyHDL, so I'm >> taking some time to extend my hardware skills, to design some >> circuits and boards. Back to schematic capture, device specs, board >> layout, and using an o'scope and logic analyzer. >> >> I understand using gates (bits), and I understand using chips >> (interfaces). It's the stuff in between that I'm having problems >> with. From my limited perspective, it seems to me that Migen does >> particularly well with interfaces, and the distinct separation >> between sequential and combinatorial logic seems to fit my current >> thought processes. >> >> I have no idea how far I can go with Migen compared to MyHDL. But >> the initial learning curve, with the goal of making my Spartan 3E >> board do fun and useful things, for the moment seems to favor Migen >> over MyHDL. >> >> But I am well aware that situation may not persist as my knowledge >> and experience grow. I have no intention of abandoning MyHDL: I >> closely monitor this list, and I periodically review the MyHDL >> documentation (especially the examples) to see if my comprehension >> has grown. >> >> Perhaps Migen makes FPGA development feel more like building with >> Legos: It makes it easy(er) to create parts and click them together. >> I suspect MyHDL may more like a machine shop: More skill is required >> to make use of it, but there may be no limit to what can be built, >> such as a Lego factory. >> >> Migen feels more newbie-friendly, while MyHDL may be more attractive >> to battle-weary V*HDL veterans. Migen is FPGA-centric, while MyHDL >> is fully ASIC-capable. Migen sometimes implements features >> inelegantly, while MyHDL excludes inelegant features. Practicality >> vs purity. High-level abstractions vs low-level power. >> >> Bottom line, I suspect both tools have their place, and share enough >> common premises that it is a mistake to view one as competing with or >> detracting from the other: Both agree the V*HDLs have limitations, >> both agree Python is a great tool for implementing HDLs. Each >> chooses a different approach, provides differing capabilities, >> targets a slightly different domain, and may attract different groups >> of users, all of which appears to me to be more complimentary than >> competitive. >> >> I don't see how there can be any need to push Migen and MyHDL apart: >> I think they should stand back-to-back and show the V*HDLs better >> ways to fill FPGAs. More like siblings who occasionally argue, than >> any kind of enemy. >> >> >> -BobC >> |
From: Jan D. <ja...@ja...> - 2012-03-18 22:18:47
|
On 03/17/2012 09:20 PM, Bob Cunningham wrote: > On 03/16/2012 02:03 PM, Jan Decaluwe wrote: >> My conclusion is that Migen found an easy target in you, as a >> newbie, to confuse you. It made you think it can be used for >> serious design work. > > Sorry, Jan. If I have to be "confused" to play with my FPGA, then so > be it. I'm very "serious" about being able to play with my FPGA! > > Your statement has an obvious implicit context: To me, you are > shouting, "MyHDL is for Serious Designers Only! Newbies and > Pragmatists should Go Away!" No, the "obvious implicit context" is "obviously" entirely different: I assume you want to do serious design work and I find it a pity that Migen managed to make you think it is a valid alternative for that purpose. I hate to see people wasting their time. And I was not shouting. -- Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com Python as a HDL: http://www.myhdl.org VHDL development, the modern way: http://www.sigasi.com World-class digital design: http://www.easics.com |
From: Bob C. <fl...@gm...> - 2012-03-19 00:20:08
|
On 03/18/2012 03:18 PM, Jan Decaluwe wrote: > On 03/17/2012 09:20 PM, Bob Cunningham wrote: >> On 03/16/2012 02:03 PM, Jan Decaluwe wrote: >>> My conclusion is that Migen found an easy target in you, as a >>> newbie, to confuse you. It made you think it can be used for >>> serious design work. >> Sorry, Jan. If I have to be "confused" to play with my FPGA, then so >> be it. I'm very "serious" about being able to play with my FPGA! >> >> Your statement has an obvious implicit context: To me, you are >> shouting, "MyHDL is for Serious Designers Only! Newbies and >> Pragmatists should Go Away!" > No, the "obvious implicit context" is "obviously" entirely > different: I assume you want to do serious design work and > I find it a pity that Migen managed to make you think it is > a valid alternative for that purpose. I hate to see people > wasting their time. > > And I was not shouting. Would you please define what you mean when you repeatedly use the phrases "serious digital design" and "serious design" in your posts? Please be clear and concise. State what is and is not "serious digital design" according to your definition of the phrase. Try to make your point without using that phrase. You are throwing those phrases around as if they were self-obvious and self-justifying. They most certainly are not! What do they mean to you? What do you believe those phrases should mean to me? -- Your use of those phrases reminds me of my own past, back in the day when we had stickers on our terminals that said things like "Real Programmers Use Assembler" and "Coders Use Assembler: Real Hackers Write Machine Language". I am of that generation where I wrote several programs in binary, octal and hexadecimal machine language, manually strobing words into memory locations to build programs and data in-place. This was not because assemblers and higher-level language compilers didn't exist, but because they weren't freely available to me at the time. Or sometimes because I was working with machines so broken that they had no functional peripherals for storage or I/O beyond rows of lights and switches on the front panel. We took great joy in our knowledge of the fundamentals and particulars of a given machine's instruction set and its idiosyncratic behaviors. We became a clique that considered those who did not match our interests and expertise as not being interested in "serious program development". Then we noticed some folks were getting just as much work done in the "real world" as we were, with 10% of our technical knowledge, using tools such as BASIC and even (*gasp*) spreadsheets. Sure, their programs weren't fast, nor were they elegant, but they got the job done. I feel no need to repeat that path with digital design. I have a powerful computer (well, several of them) that should be able to do most of the heavy-lifting for me as I design and implement my first circuits. I want to start with a spreadsheet-like tool that will let me design and implement useful things with my FPGA. Today! Unfortunately, that tool does not yet seem to exist. But Migen is clearly a step in that direction when compared to the available HDLs. Sure, you probably shouldn't use a spreadsheet to implement a real-time aircraft control system. There are some things that any given tool won't be ideal for accomplishing. I'm not looking for a be-all end-all do-it-all tool or approach. I just want to do "fun stuff" with my FPGA! I want an enabling approach, maximum yield for the initial effort. When I outgrow my initial tools, I will know it. That will be when I'll need to get more "serious". But not today, and perhaps not ever. You chose Python as your tool for implementing MyHDL, when you could have been a "more serious" programmer and chosen assembler instead (not machine language, because no computer has front panel switches any more). Or even C. Why didn't you? Clearly, you valued pragmatic productivity over any abstract notion of software "seriousness". I seek the same in the arena of digital design. So, what does the phrase "serious digital design" mean to you? Perhaps you yourself are not really serious enough when it comes to digital design: Doesn't everyone know that "Real Digital Designers Use Rubylith!"? When was the last time you used a switch to toggle the ones and zeros to manually feed a bitstream into an FPGA? Clearly you aren't against using higher-level hardware and software tools to abstract away low-level details that are irrelevant to the work at hand. I desire the same, and Migen is clearly a step in that direction. Again, I ask, what do you mean when you say "serious digital design"? Do some contexts permit "serious digital design", and other contexts somehow magically exclude it? Please clarify your terminology. -BobC |