I'd rather switch than fight!
in [FPGA]
|
From: David Brown on 14 Apr 2010 03:45 On 13/04/2010 15:15, Chris Higgs wrote: > On 13 Apr, 13:45, "cfelton"<cfelton(a)n_o_s_p_a_m.n_o_s_p_a_m.ieee.org> > wrote: >> I imagine what you posted works very well and accomplishes what you intend. >> I think for a new users adopting Python testbenches MyHDL would be a much >> better choice. I is documented, has a nice manual, there are examples >> available, and a community to support questions. The user doesn't need to >> worry about HDL conversion if they do not want. Here is a basic example of >> a testbench in MyHDL. > <snip> > > Agreed, I think MyHDL has a lot of potential and there is significant > functionality overlap and similarities to the environment our company > uses. What I'm lamenting is the reluctance of 'hardware engineers" to > adopt advances made in the software field, in terms of regression and > unit testing frameworks. More people should be using MyHDL or > homegrown alternatives to provide rapid simulation verification and > object oriented abstraction models. As a community we are very slow > moving when compared to other related fields. > > I believe MyHDL would do well to emphasise more strongly the pure > testbench environment functionality. Many engineers do not want the > VHDL/verilog generation features but could make good use of the > simulation parts of MyHDL. Expanding the cosimulation interface > options to support ModelSim FLI and VHPI would help move it forward. > I disagree with that. I haven't done much programmable logic design, and what I have done was a few years ago now, so I don't have anything like the experience of most people in this group (I work mainly with embedded software in C, and some PC software in Python). However, I have made small systems with both VHDL and Verilog. What I can say is that both Verilog and VHDL are very verbose, they both have a lot of features that are confusing and lead easily to wrong code or extra effort (for example, the difference between the different assignments in Verilog, or the different logic, bit, and numeric types in VHDL). There also seems to be a very unclear boundary between synthesisable and non-synthesisable parts of the languages, and there can be inconsistencies between simulation and working synthesised behaviour. When I used confluence, my results were far better. It was simpler and clearer, and it handles the low-level Verilog or VHDL details automatically. You can't accidentally end up with a latch or asynchronous logic in your state machines - in fact, it won't let you generate latches at all. You don't have registers that are reset in simulation and preset in synthesis, because all the Verilog/VHDL registers are generated with explicit resets (or presets). You don't have problems when mixing signed and unsigned values, because these are handled correctly. I haven't used MyHDL for more than brief tests, but it appears to give a similar isolation from the messy low-level details of Verilog and VHDL, while (even more than confluence) it gives you higher level features. People often compare Verilog to "C", and VHDL to "Ada" - I think they both share a lot with assembly language. I am also unconvinced of the value of Verilog or VHDL functional simulation (timing simulation is another matter, of course), if the code you have written is not in Verilog or VHDL in the first place. If your code is written in MyHDL, and the MyHDL conversion to Verilog/VHDL is accurate, then you can do all your functional testing entirely within Python and MyHDL. cosimulation is only relevant when you have parts that are not written in MyHDL (and cannot easily be modelled in MyHDL). confluence "died" because the author was more interested in formal verification systems than synthesis (or testbenches). While testbenching and integration with Verilog and VHDL simulators is important, I believe it is more important to have good tools that help you write correct code in the first place, rather than just to find the mistakes you've made. As I say, I don't have the experience in programmable logic design of most people here. That may mean my opinions here are pretty worthless - perhaps I'd be happy with Verilog and VHDL if I spend longer getting used to them. But it may also mean that I can think about this without the bias of long established practice.
From: Chris Higgs on 14 Apr 2010 08:27 On Apr 14, 8:45 am, David Brown <da...(a)westcontrol.removethisbit.com> wrote: > I am also unconvinced of the value of Verilog or VHDL functional > simulation (timing simulation is another matter, of course), if the code > you have written is not in Verilog or VHDL in the first place. If your > code is written in MyHDL, and the MyHDL conversion to Verilog/VHDL is > accurate, then you can do all your functional testing entirely within > Python and MyHDL. cosimulation is only relevant when you have parts > that are not written in MyHDL (and cannot easily be modelled in MyHDL). In my experience (which again is limited), there are many engineers who are happy writing synthesisable code in VHDL. They may find MyHDL useful for to generate type/conversion packages (it would be nice to have a union function to convert a record type to a vector and vica- versa) but want to continue doing the majority of coding in raw VHDL. I personally believe this comprises the majority of VHDL engineers (otherwise takeup of tools like MyHDL would be far higher). For this group having an easy way to interface to the simulator using a language other than VHDL is the sweetspot which might persuade them to try a different design flow. MyHDL is almost ready to fill that space...
From: Andy on 14 Apr 2010 12:43 MyHDL is a promising language, but at this point, it is just that: promising. I can't go to my director and tell him I'm going to use a non- commercially-supported language/toolset (VHDL/Verilog RTL converter at this point) that is at version 0.6 for his next project, and expect to still have respect, or even a job afterwards. I suspect the vast majority of non-academic HDL professionals are in exactly the same boat. Call me back when it does synthesizable fixed/floating point and has direct support from at least one major synthesis vendor. Sorry, converting to VHDL/Verilog RTL to use with anyone's tool does not cut it, unless the vendor supports the conversion process too. Andy
From: cfelton on 14 Apr 2010 13:18 >MyHDL is a promising language, but at this point, it is just that: >promising. > >I can't go to my director and tell him I'm going to use a non- >commercially-supported language/toolset (VHDL/Verilog RTL converter at >this point) that is at version 0.6 for his next project, and expect to >still have respect, or even a job afterwards. I suspect the vast >majority of non-academic HDL professionals are in exactly the same >boat. > >Call me back when it does synthesizable fixed/floating point and has >direct support from at least one major synthesis vendor. Sorry, >converting to VHDL/Verilog RTL to use with anyone's tool does not cut >it, unless the vendor supports the conversion process too. > >Andy > Well, you will never get that call because that isn't the point/goal of MyHDL. But given this argument you would not be interested in using Python in your flow (or any script language except TCL), whether it be for build scripts, testbenches, generation of constants, etc. I think the goal of MyHDL is to replace a bunch of tools in the developers toobox with a unified tool, in this case a programming language. Many developers find themselves doing many tasks in a scripting languages, be it Python, TCL, etc. With Python and MyHDL all this can be done in a single language, hopefully improving efficiency. MyHDL adds *RTL* to Python. The Python-RTL (MyHDL) is converted to Verilog/VHDL. There is no need or desire for direct support by a synthesis vendor. And MyHDL doesn't try to do higher level synthesis. Higher level-synthesis tools can be developed on top of MyHDL if desired. MyHDL has a focused goal which is to add *RTL* to Python, IMO makes it more attactive. I agree, any tool and/or method is easier to adopt if it has a track record. But I think the track record you are looking for might be a little misdirected (ie some large EDA company adopting). The goal of a company should be to increase efficiency and ROI. Tools like Python/MyHDL (and other languages) provide this. We outlined some of the possible risks and risk mitigation methods. --------------------------------------- Posted through http://www.FPGARelated.com
From: Jan Decaluwe on 14 Apr 2010 16:23
On Apr 14, 6:43 pm, Andy <jonesa...(a)comcast.net> wrote: > > I can't go to my director and tell him I'm going to use a non- > commercially-supported language/toolset (VHDL/Verilog RTL converter at > this point) that is at version 0.6 for his next project, and expect to > still have respect, or even a job afterwards. I suspect the vast > majority of non-academic HDL professionals are in exactly the same > boat. MyHDL has good support for subversive behavior :-) Seriously, that's why conversion to VHDL/Verilog gets so much attention. It allows you to view MyHDL simply as a more effective or fun way to create your trusted VHDL/Verilog design. Therefore, no need to ask nor tell anyone. If you're intrigued, just do it, and do it as a good engineer: start with a simple but relevant module, not with a whole design. After conversion, few will be able to tell (you may even get praise for the code quality :-)). Along the way, you may discover unique features that you want to share with others, even with directors. You'll know when it's time to come out. Jan -- 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 Analog design automation: http://www.mephisto-da.com World-class digital design: http://www.easics.com |