Thread: [myhdl-list] What MyHDL is not
Brought to you by:
jandecaluwe
Menu
▾
▴
myhdl-list
|
From: Jan D. <ja...@ja...> - 2012-04-23 10:24:19
|
I have written a page describing what MyHDL is not: http://www.myhdl.org/doku.php/whatitisnot -- 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-04-23 15:36:49
|
On 4/23/12 5:23 AM, Jan Decaluwe wrote: > I have written a page describing what MyHDL is not: > > http://www.myhdl.org/doku.php/whatitisnot > And I wrote a different version of the page at: wiki.MyHDLClass.com:8080/WhatMyHDLisNot The difference is about audience. There are two different audiences. The experienced python developer and the experienced chip designer. The mental models of the two groups are different, their issues are different. Jan's page did not resonate with me. I hope that python developers connect better with the page I just wrote. Comments and edits are most appreciated. The other point is to finish off the page and each point on it on an upbeat note, so that we do not scare new users away. Hope that helps. It would be great if someone would edit the myhdl wiki page with the same ideas in mind. And I have added the creative commons licensing agreement to the bottom of the page I just wrote. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
|
From: Christopher F. <chr...@gm...> - 2012-04-24 02:15:10
|
On 4/23/12 5:23 AM, Jan Decaluwe wrote: > I have written a page describing what MyHDL is not: > > http://www.myhdl.org/doku.php/whatitisnot > I believe this will help inform new users. We often get new users, I believe, with unrealistic expectations of MyHDL. Some comments, cross linking to the "Why MyHDL" page (and vise-versa) could be useful. We want to be useful setting expectations but also want to *highlight* the benefits :) In the _It is not well suited for gate level simulation_ section. You might want to mention co-simulation. A potential user might come away with the wrong impression that they will need to redo a fair amount of verification implementation in Verilog/VHDL. Rather, they should use a Verilog/VHDL simulator in conjunction to verify structural-physical correctness. Regards, Chris |
|
From: Jan D. <ja...@ja...> - 2012-04-25 12:28:28
|
On 04/24/2012 04:11 AM, Christopher Felton wrote: > On 4/23/12 5:23 AM, Jan Decaluwe wrote: >> I have written a page describing what MyHDL is not: >> >> http://www.myhdl.org/doku.php/whatitisnot >> > I believe this will help inform new users. We often get new users, I > believe, with unrealistic expectations of MyHDL. > > Some comments, cross linking to the "Why MyHDL" page (and vise-versa) > could be useful. We want to be useful setting expectations but also > want to *highlight* the benefits :) I added that in the beginning. Also used some less negative wordings here and there. > > In the _It is not well suited for gate level simulation_ section. You > might want to mention co-simulation. A potential user might come away > with the wrong impression that they will need to redo a fair amount of > verification implementation in Verilog/VHDL. Rather, they should use a > Verilog/VHDL simulator in conjunction to verify structural-physical > correctness. I agree completely. I have rewritten this without reference to gate level simulation in the title - "timing simulations" instead. And I have included a short description of co-simulation. Thanks, 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 World-class digital design: http://www.easics.com |
|
From: Christopher F. <chr...@gm...> - 2012-05-02 20:58:40
|
On 5/2/2012 1:52 PM, Uri Nix wrote: > IMHO it /is/ confusing, since the previous topics in the chapter are > synthesis oriented. The manual under "Modeling techniques" currently progresses; structural, RTL, High-level. Do you think a top-down versus bottom-up order would be better? Someone *without* a HW design background may find; High-level, RTL, structural order less confusing? Or, in your opinion, do you think it needs to be a completely separate chapter? Regards, Chris > > I have had very good experience with MyHDL for system modelling, which uses > a different mindset than the FPGA direction. It is amazingly powerful, > follows similar idioms as in SystemC with the ease of Python, and might use > some more mention. > > Cheers, > Uri > > > On 2 May 2012 18:55, Tom Dillon<td...@di...> wrote: > >> I think the manual is clear and it makes pretty good sense what can be >> converted. >> >> One of the great things about MyHDL/Python is that as long as your code at >> the lowest level is RTL, then it will convert. >> >> You can use all the power of Python of top of that to make very high level >> structures. >> >> >> >> On 05/02/2012 10:30 AM, Jan Decaluwe wrote: >> >> On 04/27/2012 02:52 AM, Christopher Lozinski wrote: >> >> >> The higher level approach is to model things as objects. There is a >> queue example in the docs. This stuff blows my mind. How that can be >> synthesized, what it means in terms of hardware functions, I really do >> not yet understand. Sure the queue example is easily understandable to >> a software engineer, but what does that look like when converted? >> >> I went back to the manual, to understand where so much confusion can >> come from. >> >> But really, I don't see it. I think the manual is crystal clear. In the >> chapter you refer to, it describes a number of modeling options that >> MyHDL supports. When it talks about RTL, it explicitly makes the connection >> with synthesis. Then it moves on to high-level modeling - I think >> it's obvious that there is no direct link with synthesis. >> >> To understand the link between conversion and synthesis, move to the >> chapter about conversion. It explicitly states that the first goal >> of conversion is synthesis, but also that the convertible subset >> is more general than the synthesizable subset. And it describes >> the convertible *subset*. >> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> >> > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher L. <loz...@fr...> - 2012-05-02 23:31:00
|
On 5/2/12 3:58 PM, Christopher Felton wrote: > On 5/2/2012 1:52 PM, Uri Nix wrote: >> IMHO it /is/ confusing, since the previous topics in the chapter are >> synthesis oriented. > The manual under "Modeling techniques" currently progresses; structural, > RTL, High-level. Do you think a top-down versus bottom-up order would > be better? Someone *without* a HW design background may find; > High-level, RTL, structural order less confusing? Or, in your opinion, > do you think it needs to be a completely separate chapter? It is still all not clear to me. I am not sure about top down or bottom up. There are two different target markets, the experienced hardware designers, and the experienced software developers. I can only speak for the later. I would love to see it structured more as a tutorial on hardware design than as a class on MyHDL. Start with a flip flop, maybe that is a structural example progress to a more complex digital circuit, say a clock, maybe that is RTL, and then onto High Level. In particular I would love to see a hardware example of when you use @always, @instance and @always_comb. Why are there only 3 decorators???? I think I understand it, but I keep getting it wrong. And then at a certain point, say okay here is more stuff you can model, but that you cannot synthesize. Better yet, say this is more stuff you can model, but cannot use to create an FPGA. And I would love to add my section on what you cannot synthesize to the docs. In fact I would love to move all or part of my wiki onto MyDHL.org I guess words like structural, RTL, and High level make sense to the chip designers, but for me I am not quite sure of the differences. Specific examples would be much more helpful. The point is, if you are targeting python developers, then the documentation needs to be written in ways that are mindful of their mindset. They understand python, but not chip design, so explain the later to them. In contrast, the hardware guys are probably quite happy with the current manual structure, although I cannot speak for them. I hope that helps. |
|
From: Tom D. <td...@di...> - 2012-05-02 23:49:12
|
On 05/02/2012 06:30 PM, Christopher Lozinski wrote: > On 5/2/12 3:58 PM, Christopher Felton wrote: >> On 5/2/2012 1:52 PM, Uri Nix wrote: >>> IMHO it /is/ confusing, since the previous topics in the chapter are >>> synthesis oriented. >> The manual under "Modeling techniques" currently progresses; structural, >> RTL, High-level. Do you think a top-down versus bottom-up order would >> be better? Someone *without* a HW design background may find; >> High-level, RTL, structural order less confusing? Or, in your opinion, >> do you think it needs to be a completely separate chapter? > It is still all not clear to me. I am not sure about top down or bottom > up. There are two different target markets, the experienced hardware > designers, and the experienced software developers. I can only speak > for the later. > > I would love to see it structured more as a tutorial on hardware design > than as a class on MyHDL. Start with a flip flop, maybe that is a > structural example progress to a more complex digital circuit, say a > clock, maybe that is RTL, and then onto High Level. In particular I > would love to see a hardware example of when you use @always, @instance > and @always_comb. Why are there only 3 decorators???? I think I > understand it, but I keep getting it wrong. And then at a certain > point, say okay here is more stuff you can model, but that you cannot > synthesize. Better yet, say this is more stuff you can model, but > cannot use to create an FPGA. And I would love to add my section on > what you cannot synthesize to the docs. In fact I would love to move > all or part of my wiki onto MyDHL.org Am I missing something here, why would the MyHDL documentation be expected to teach hardware design? Last week I used a Python package to allow me to read/write an Excel spreadsheet. I did not expect the documentation for that package to teach me how to use Excel. Why would it? |
|
From: Christopher L. <loz...@fr...> - 2012-05-03 00:34:39
|
> Am I missing something here, why would the MyHDL documentation be > expected to teach hardware design? > > Last week I used a Python package to allow me to read/write an Excel > spreadsheet. I did not expect the documentation for that package to > teach me how to use Excel. Why would it? Great question. The problem with MyHDL is that you have two computational models, Python and Digital Circuit Design. Unlike a spreadsheet, which is not part of Python, Digital Circuit Design is part of MyHDL. The documentation needs to highlight both or it gets very confusing to people who are not already Digital Circuit Designers. Currently the documentation does a good job describing the python, but not such a good job describing digital circuit design. My proposal was a way to make the Digital Circuit Models part more explicit. Push them forward, as the python part is already taken care of. IMHO that would make things much clearer. Then there is the argument about MyHDL being a tiny community, and how important it is for us to reach out to the larger python community. But in an open source world, where developers do things for their own benefit, that does not carry much weight. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
|
From: Tom D. <td...@di...> - 2012-05-03 03:13:33
|
Why is would anyone not familiar with "Digital Circuit Design" be using MyHDL? On 05/02/2012 07:34 PM, Christopher Lozinski wrote: >> Am I missing something here, why would the MyHDL documentation be >> expected to teach hardware design? >> >> Last week I used a Python package to allow me to read/write an Excel >> spreadsheet. I did not expect the documentation for that package to >> teach me how to use Excel. Why would it? > Great question. The problem with MyHDL is that you have two > computational models, Python and Digital Circuit Design. Unlike a > spreadsheet, which is not part of Python, Digital Circuit Design is > part of MyHDL. The documentation needs to highlight both or it gets > very confusing to people who are not already Digital Circuit Designers. > Currently the documentation does a good job describing the python, but > not such a good job describing digital circuit design. My proposal was > a way to make the Digital Circuit Models part more explicit. Push them > forward, as the python part is already taken care of. IMHO that would > make things much clearer. > > Then there is the argument about MyHDL being a tiny community, and how > important it is for us to reach out to the larger python community. But > in an open source world, where developers do things for their own > benefit, that does not carry much weight. > |
|
From: David A. <da...@po...> - 2012-05-03 03:22:33
|
If you already know Python, and want to learn digital design, MyHDL is attractive. Plus, there are assertions that it's actually better than VHDL or Verilog anyway. d On 02/05/2012, at 22:03, Tom Dillon <td...@di...> wrote: > Why is would anyone not familiar with "Digital Circuit Design" be using MyHDL? > > > On 05/02/2012 07:34 PM, Christopher Lozinski wrote: >> >>> Am I missing something here, why would the MyHDL documentation be >>> expected to teach hardware design? >>> >>> Last week I used a Python package to allow me to read/write an Excel >>> spreadsheet. I did not expect the documentation for that package to >>> teach me how to use Excel. Why would it? >> Great question. The problem with MyHDL is that you have two >> computational models, Python and Digital Circuit Design. Unlike a >> spreadsheet, which is not part of Python, Digital Circuit Design is >> part of MyHDL. The documentation needs to highlight both or it gets >> very confusing to people who are not already Digital Circuit Designers. >> Currently the documentation does a good job describing the python, but >> not such a good job describing digital circuit design. My proposal was >> a way to make the Digital Circuit Models part more explicit. Push them >> forward, as the python part is already taken care of. IMHO that would >> make things much clearer. >> >> Then there is the argument about MyHDL being a tiny community, and how >> important it is for us to reach out to the larger python community. But >> in an open source world, where developers do things for their own >> benefit, that does not carry much weight. >> > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Tom D. <td...@di...> - 2012-05-03 03:28:36
|
OK, but do you expect the MyHDL documentation to teach you basics of digital design? On 05/02/2012 10:22 PM, David Arnold wrote: > If you already know Python, and want to learn digital design, MyHDL is > attractive. Plus, there are assertions that it's actually better than > VHDL or Verilog anyway. > > > > > d > > > On 02/05/2012, at 22:03, Tom Dillon <td...@di... > <mailto:td...@di...>> wrote: > >> Why is would anyone not familiar with "Digital Circuit Design" be >> using MyHDL? >> >> >> On 05/02/2012 07:34 PM, Christopher Lozinski wrote: >>>> Am I missing something here, why would the MyHDL documentation be >>>> expected to teach hardware design? >>>> >>>> Last week I used a Python package to allow me to read/write an Excel >>>> spreadsheet. I did not expect the documentation for that package to >>>> teach me how to use Excel. Why would it? >>> Great question. The problem with MyHDL is that you have two >>> computational models, Python and Digital Circuit Design. Unlike a >>> spreadsheet, which is not part of Python, Digital Circuit Design is >>> part of MyHDL. The documentation needs to highlight both or it gets >>> very confusing to people who are not already Digital Circuit Designers. >>> Currently the documentation does a good job describing the python, but >>> not such a good job describing digital circuit design. My proposal was >>> a way to make the Digital Circuit Models part more explicit. Push them >>> forward, as the python part is already taken care of. IMHO that would >>> make things much clearer. >>> >>> Then there is the argument about MyHDL being a tiny community, and how >>> important it is for us to reach out to the larger python community. But >>> in an open source world, where developers do things for their own >>> benefit, that does not carry much weight. >>> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. >> Discussions >> will include endpoint security, mobile security and the latest in >> malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> <mailto:myh...@li...> >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher L. <loz...@fr...> - 2012-05-03 05:16:42
|
On 5/2/12 9:18 PM, Tom Dillon wrote:
> OK, but do you expect the MyHDL documentation to teach you basics of
> digital design?
No not really. But I do want a clear set of digital designs, presented
one at a time in the docs. Each one describing a new MyHDL concept.
Here is the index for the section on modelling.
* Modeling techniques
<http://www.myhdl.org/doc/current/manual/modeling.html#>
o Structural modeling
<http://www.myhdl.org/doc/current/manual/modeling.html#structural-modeling>
+ Conditional instantiation
<http://www.myhdl.org/doc/current/manual/modeling.html#conditional-instantiation>
+ Lists of instances and signals
<http://www.myhdl.org/doc/current/manual/modeling.html#lists-of-instances-and-signals>
+ Converting between lists of signals and bit vectors
<http://www.myhdl.org/doc/current/manual/modeling.html#converting-between-lists-of-signals-and-bit-vectors>
+ Inferring the list of instances
<http://www.myhdl.org/doc/current/manual/modeling.html#inferring-the-list-of-instances>
o RTL modeling
<http://www.myhdl.org/doc/current/manual/modeling.html#rtl-modeling>
+ Combinatorial logic
<http://www.myhdl.org/doc/current/manual/modeling.html#combinatorial-logic>
# Template
<http://www.myhdl.org/doc/current/manual/modeling.html#template>
# Example
<http://www.myhdl.org/doc/current/manual/modeling.html#example>
+ Sequential logic
<http://www.myhdl.org/doc/current/manual/modeling.html#sequential-logic>
# Template
<http://www.myhdl.org/doc/current/manual/modeling.html#model-seq-templ>
# Example
<http://www.myhdl.org/doc/current/manual/modeling.html#model-seq-ex>
+ Finite State Machine modeling
<http://www.myhdl.org/doc/current/manual/modeling.html#finite-state-machine-modeling>
o High level modeling
<http://www.myhdl.org/doc/current/manual/modeling.html#high-level-modeling>
+ Modeling with bus-functional procedures
<http://www.myhdl.org/doc/current/manual/modeling.html#modeling-with-bus-functional-procedures>
+ Modeling memories with built-in types
<http://www.myhdl.org/doc/current/manual/modeling.html#modeling-memories-with-built-in-types>
+ Modeling errors using exceptions
<http://www.myhdl.org/doc/current/manual/modeling.html#modeling-errors-using-exceptions>
+ Object oriented modeling
<http://www.myhdl.org/doc/current/manual/modeling.html#object-oriented-modeling>
This is all really about Python and MyHDL. Nothing about chips. Not
that much about computational models of circuits. And in particular,
not at all clear where chip modeling ends and other modeling begins.
Nor what kind of chips use @always, @instance and @always_comb. The
focus is not on the models of digital circuits, it is on the features of
MyHDL.
How about structuring it like:
Flip Flop
Signal
Clock
Wires
Ram Model
Rom Model
Fixed Point
Sequential Logic
Finite State Machine
Bus.
Etc.
Then each chip section could describe one of the features of MyHDL. I
am sure the hardware guys can think of a hardware example that
illustrates each of the above concepts.
Actually this approach has the real nice property, that you are
effectively documenting the existing components. Right now things are
scattered, it took me a while to find the memory models and the fixed
point models. I did not realize they existed. And more importantly
you are publishing a series of digital circuit models. The software
developers can figure out the MyHDL commands. The digital circuit
models is where they need the help.
--
Regards
Christopher Lozinski
Check out my iPhone apps TextFaster and EmailFaster
http://textfaster.com
Expect a paradigm shift.
http://MyHDL.org
|
|
From: Jan D. <ja...@ja...> - 2012-05-03 08:38:47
|
On 05/03/2012 06:55 AM, Christopher Lozinski wrote: > This is all really about Python and MyHDL. Nothing about chips. Not > that much about computational models of circuits. And in particular, > not at all clear where chip modeling ends and other modeling begins. > Nor what kind of chips use @always, @instance and @always_comb. That is clearly not true. The section on RTL modeling starts as follows: "The present section describes how MyHDL supports RTL style modeling as is typically used for synthesizable models." Then it moves on to describe templates for "computational models" for combinatorial logic and for sequential logic. Just two, and with those two you can do everything :-) And then it shows how to describe an FSM, which is what you will be using all the time. > The focus is not on the models of digital circuits, it is on the features > of MyHDL. This is the MyHDL manual. In the RTL section, it shows you how you can use MyHDL to write models that a synthesis tool will turn into digital circuits. In the next section, it shows you can do all kinds of other interesting things at a higher level. Let me try again: I think your confusion comes from the mindset. It is wrong to look at any MyHDL construct, like Signals or decorators, and immediately worry about what the corresponding hardware implementation is. That is just not how it works. For example: the 3 decorators exist because they let you easily describe useful event-driven behaviors, *not* because they correspond uniquely to some hardware implementation. -- 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-05-03 13:51:40
|
So here is an example of the what I think python developers would like to see. http://wiki.myhdlclass.com:8080/Documentation The embedded Decorator link is an excellent resource. I make the clock cycle on Delay(1) not 20. I try to describe the digital design issues for consumption by a python developer. As for the other discussions, I am not quite sure why I generate so much negative response. I really liked David's comment. On 5/3/12 6:16 AM, David Arnold wrote: > My view of gratis software is that I'm grateful for what's given and the creator(s) are under no obligation to do anything. My mistake. It is easy to think of MyHDL as a shared project with people having shared direction. And then we get to discuss the shared direction. The reality is that each person does whatever they want. Thank you for clearing up my understanding of open source projects. Nor am I asking for the senior MyHDL developers to be writing this. Writing up documentation is a great way to learn the systems. But if they would be so kind as to proofread it that would be a huge help. Obviously no one is under any obligation to do so. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
|
From: David A. <da...@po...> - 2012-05-03 11:16:26
|
My view of gratis software is that I'm grateful for what's given and the creator(s) are under no obligation to do anything. If you phrase the question differently though: would Python programmers seeking to learn digital design with MyHDL find some basic digital design tutorials using MyHDL useful, then I think the answer is yes. In other words, I think there's a large audience for "Introduction to Digital Design with MyHDL", but that's an opportunity not an obligation. d On 02/05/2012, at 22:18, Tom Dillon <td...@di...> wrote: > OK, but do you expect the MyHDL documentation to teach you basics of digital design? > > On 05/02/2012 10:22 PM, David Arnold wrote: >> >> If you already know Python, and want to learn digital design, MyHDL is attractive. Plus, there are assertions that it's actually better than VHDL or Verilog anyway. >> >> >> >> >> d >> >> >> On 02/05/2012, at 22:03, Tom Dillon <td...@di...> wrote: >> >>> Why is would anyone not familiar with "Digital Circuit Design" be using MyHDL? >>> >>> >>> On 05/02/2012 07:34 PM, Christopher Lozinski wrote: >>>> >>>>> Am I missing something here, why would the MyHDL documentation be >>>>> expected to teach hardware design? >>>>> >>>>> Last week I used a Python package to allow me to read/write an Excel >>>>> spreadsheet. I did not expect the documentation for that package to >>>>> teach me how to use Excel. Why would it? >>>> Great question. The problem with MyHDL is that you have two >>>> computational models, Python and Digital Circuit Design. Unlike a >>>> spreadsheet, which is not part of Python, Digital Circuit Design is >>>> part of MyHDL. The documentation needs to highlight both or it gets >>>> very confusing to people who are not already Digital Circuit Designers. >>>> Currently the documentation does a good job describing the python, but >>>> not such a good job describing digital circuit design. My proposal was >>>> a way to make the Digital Circuit Models part more explicit. Push them >>>> forward, as the python part is already taken care of. IMHO that would >>>> make things much clearer. >>>> >>>> Then there is the argument about MyHDL being a tiny community, and how >>>> important it is for us to reach out to the larger python community. But >>>> in an open source world, where developers do things for their own >>>> benefit, that does not carry much weight. >>>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> myhdl-list mailing list >>> myh...@li... >>> https://lists.sourceforge.net/lists/listinfo/myhdl-list >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> >> >> _______________________________________________ >> myhdl-list mailing list >> myh...@li... >> https://lists.sourceforge.net/lists/listinfo/myhdl-list > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list |
|
From: Christopher F. <chr...@gm...> - 2012-05-03 02:05:23
|
On 5/2/12 6:48 PM, Tom Dillon wrote: > On 05/02/2012 06:30 PM, Christopher Lozinski wrote: >> On 5/2/12 3:58 PM, Christopher Felton wrote: >>> On 5/2/2012 1:52 PM, Uri Nix wrote: >>>> IMHO it /is/ confusing, since the previous topics in the chapter are >>>> synthesis oriented. >>> The manual under "Modeling techniques" currently progresses; structural, >>> RTL, High-level. Do you think a top-down versus bottom-up order would >>> be better? Someone *without* a HW design background may find; >>> High-level, RTL, structural order less confusing? Or, in your opinion, >>> do you think it needs to be a completely separate chapter? >> It is still all not clear to me. I am not sure about top down or bottom >> up. There are two different target markets, the experienced hardware >> designers, and the experienced software developers. I can only speak >> for the later. >> >> I would love to see it structured more as a tutorial on hardware design >> than as a class on MyHDL. Start with a flip flop, maybe that is a >> structural example progress to a more complex digital circuit, say a >> clock, maybe that is RTL, and then onto High Level. In particular I >> would love to see a hardware example of when you use @always, @instance >> and @always_comb. Why are there only 3 decorators???? I think I >> understand it, but I keep getting it wrong. And then at a certain >> point, say okay here is more stuff you can model, but that you cannot >> synthesize. Better yet, say this is more stuff you can model, but >> cannot use to create an FPGA. And I would love to add my section on >> what you cannot synthesize to the docs. In fact I would love to move >> all or part of my wiki onto MyDHL.org > > Am I missing something here, why would the MyHDL documentation be > expected to teach hardware design? > > Last week I used a Python package to allow me to read/write an Excel > spreadsheet. I did not expect the documentation for that package to > teach me how to use Excel. Why would it? > You are absolutely correct! The MyHDL manual should not be expected to teach hardware design, hardware verification, system modeling, hardware modeling etc. Or what an FPGA or IC's are or how to design them. Regards, Chris |
|
From: G. A. S. <g.a...@gm...> - 2012-05-03 15:03:49
|
I taught myself RTL using myHDL a long time ago and then learned Verilog by looking at what it output and modifying it. I'm still a beginner with it though... I mean its not my job so I haven't done much more then what people would do in college courses -- small stuff like PWM LEDs, drive stepper motors, etc. But folks, I think that Christopher has a few good points. It was HARD to learn it (but easier then learning straight Verilog). The biggest issue was figuring out what can be synthesized or not. I mean, from a SW developer's perspective, I know perfectly well how to write a simulation at multiple abstraction levels. In fact the whole "yield" thing forces the simulation into a certain "style" which can be limiting. In essence, as a software professional, I don't need myHDL to help me write them at multiple abstraction levels EXCEPT for the lowest -- i.e. a synthesizable simulation. But -- no offense intended -- judging by the TCL (and C) code I've seen I can certain see how hardware guys might really need it!!! :-) In this example: http://www.myhdl.org/doc/current/manual/modeling.html#object-oriented-modelingits still unclear whether the "queue" class was synthesizable or not (just by reading the docs, I mean you could try it!). But it would be really nice if the document clearly marked what is expected to be synthesizable. Frankly it would be awesome if unsynthesizable stuff was magically highlighted in red in my emacs editor but I don't think that will happen soon :-). In fact, what I thought myHDL was going to let me do is create classes that define blocks of logic at the RTL level (synthesizable), perhaps with inputs and output "Signals" as variables passed in the constructor and then by instantiating those classes I'd be in effect plunking down copies of that logic in the FPGA (or within larger logic blocks by instantiating these within the constructor of another class). 4 years ago I did not ever figure out how to do this... I don't think anything wrapped in a class was synthesizable back then. But maybe that has changed now; I haven't tried using classes since. Some comments inline: On Thu, May 3, 2012 at 9:35 AM, Christopher Lozinski < loz...@fr...> wrote: > So here is an example of the what I think python developers would like > to see. > > http://wiki.myhdlclass.com:8080/Documentation > > The embedded Decorator link is an excellent resource. I make the clock > cycle on Delay(1) not 20. I try to describe the digital design issues > for consumption by a python developer. > > As for the other discussions, I am not quite sure why I generate so much > negative response. I really liked David's comment. > > On 5/3/12 6:16 AM, David Arnold wrote: > > My view of gratis software is that I'm grateful for what's given and the > creator(s) are under no obligation to do anything. > My mistake. It is easy to think of MyHDL as a shared project with > people having shared direction. And then we get to discuss the shared > direction. The reality is that each person does whatever they want. > Thank you for clearing up my understanding of open source projects. > > Christopher, it sounds like you are being sarcastic here but if so in fact you really are mistaken about what happens in open source projects with no paid engineers. The purpose of discussion is only to give a person ideas. That person will then go off and do whatever they want. And whether that gets back into the main tree is entirely up to the owners of the project, who will do whatever they want with the submission :-). If they don't take it you may get a fork... The fact of the matter is that Jan seems to have written myHDL to solve issues in complex hardware design and hardware simulation that only experts in the field can understand (either that or they are such totally obvious mistakes in doing a simulation that any software person would think OMG!! so we think that that CAN'T be the real issue :-) ) and a lot of us are trying to twist the project to: 1. make it really easy to do quick and dirty FPGA hackups 2. learn how to program these "seas of gates". Nor am I asking for the senior MyHDL developers to be writing this. > Writing up documentation is a great way to learn the systems. But if > they would be so kind as to proofread it that would be a huge help. > Then write it... but honestly WRT proofreading I have one comment. From reading this list it seems like you keep claiming the X does not exist and then Jan has to go off and point to the spot in the docs. So the law clerk is having the lawyer run around and look stuff up... don't be a help vampire: http://slash7.com/2006/12/22/vampires/ Cheers! Andrew |
|
From: Jan D. <ja...@ja...> - 2012-05-03 17:55:58
|
On 05/03/2012 05:03 PM, G. Andrew Stone wrote: > I taught myself RTL using myHDL a long time ago and then learned > Verilog by looking at what it output and modifying it. I'm still a > beginner with it though... I mean its not my job so I haven't done > much more then what people would do in college courses -- small stuff > like PWM LEDs, drive stepper motors, etc. > > But folks, I think that Christopher has a few good points. It was > HARD to learn it (but easier then learning straight Verilog). Thanks for that comment - it means that I reached my goal your case: it is hard work, yes (see "Why MyHDL"), but as long as it's easier than straight Verilog (and free),one gains. > The biggest issue was figuring out what can be synthesized or not. I > mean, from a SW developer's perspective, I know perfectly well how to > write a simulation at multiple abstraction levels. In fact the whole > "yield" thing forces the simulation into a certain "style" which can > be limiting. In essence, as a software professional, I don't need > myHDL to help me write them at multiple abstraction levels EXCEPT for > the lowest -- i.e. a synthesizable simulation. I don't understand that. If I want to verify a synthesizable RTL description, which is a special kind of an event-driven model, I need event-driven models and test benches as a verification environment. So I really need event-driven and high-level modeling combined - something MyHDL gives me and stock Python does not. Note also that your comment is the opposite of what Uri Nix just said in another post. -- 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-05-03 20:01:50
|
On 05/03/2012 05:03 PM, G. Andrew Stone wrote: > I taught myself RTL using myHDL a long time ago and then learned Verilog by looking at what it output and modifying it. I'm still a beginner with it though... I mean its not my job so I haven't done much more then what people would do in college courses -- small stuff like PWM LEDs, drive stepper motors, etc. > > But folks, I think that Christopher has a few good points. It was HARD to learn it (but easier then learning straight Verilog). The biggest issue was figuring out what can be synthesized or not. I mean, from a SW developer's perspective, I know perfectly well how to write a simulation at multiple abstraction levels. In fact the whole "yield" thing forces the simulation into a certain "style" which can be limiting. In essence, as a software professional, I don't need myHDL to help me write them at multiple abstraction levels EXCEPT for the lowest -- i.e. a synthesizable simulation. But -- no offense intended -- judging by the TCL (and C) code I've seen I can certain see how hardware guys might really need it!!! :-) > > In this example: http://www.myhdl.org/doc/current/manual/modeling.html#object-oriented-modeling its still unclear whether the "queue" class was synthesizable or not (just by reading the docs, I mean you could try it!). But it would be really nice if the document clearly marked what is expected to be synthesizable. Frankly it would be awesome if unsynthesizable stuff was magically highlighted in red in my emacs editor but I don't think that will happen soon :-). > > In fact, what I thought myHDL was going to let me do is create classes that define blocks of logic at the RTL level (synthesizable), perhaps with inputs and output "Signals" as variables passed in the constructor and then by instantiating those classes I'd be in effect plunking down copies of that logic in the FPGA (or within larger logic blocks by instantiating these within the constructor of another class). 4 years ago I did not ever figure out how to do this... I don't think anything wrapped in a class was synthesizable back then. But maybe that has changed now; I haven't tried using classes since. > > Some comments inline: > > > On Thu, May 3, 2012 at 9:35 AM, Christopher Lozinski <loz...@fr... <mailto:loz...@fr...>> wrote: > > So here is an example of the what I think python developers would like > to see. > > http://wiki.myhdlclass.com:8080/Documentation > > The embedded Decorator link is an excellent resource. I make the clock > cycle on Delay(1) not 20. I try to describe the digital design issues > for consumption by a python developer. > > As for the other discussions, I am not quite sure why I generate so much > negative response. I really liked David's comment. > > On 5/3/12 6:16 AM, David Arnold wrote: > > My view of gratis software is that I'm grateful for what's given and the creator(s) are under no obligation to do anything. > My mistake. It is easy to think of MyHDL as a shared project with > people having shared direction. And then we get to discuss the shared > direction. The reality is that each person does whatever they want. > Thank you for clearing up my understanding of open source projects. > > > Christopher, it sounds like you are being sarcastic here but if so in fact you really are mistaken about what happens in open source projects with no paid engineers. The purpose of discussion is only to give a person ideas. That person will then go off and do whatever they want. And whether that gets back into the main tree is entirely up to the owners of the project, who will do whatever they want with the submission :-). If they don't take it you may get a fork... > > The fact of the matter is that Jan seems to have written myHDL to solve issues in complex hardware design and hardware simulation that only experts in the field can understand (either that or they are such totally obvious mistakes in doing a simulation that any software person would think OMG!! so we think that that CAN'T be the real issue :-) ) and a lot of us are trying to twist the project to: 1. make it really easy to do quick and dirty FPGA hackups 2. learn how to program these "seas of gates". > > > Nor am I asking for the senior MyHDL developers to be writing this. > Writing up documentation is a great way to learn the systems. But if > they would be so kind as to proofread it that would be a huge help. > > > Then write it... but honestly WRT proofreading I have one comment. From reading this list it seems like you keep claiming the X does not exist and then Jan has to go off and point to the spot in the docs. So the law clerk is having the lawyer run around and look stuff up... don't be a help vampire: http://slash7.com/2006/12/22/vampires/ > > Cheers! > Andrew > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > > > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list -- 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 F. <chr...@gm...> - 2012-05-11 22:01:00
|
On 5/3/2012 10:03 AM, G. Andrew Stone wrote: > Then write it... but honestly WRT proofreading I have one comment. From > reading this list it seems like you keep claiming the X does not exist and > then Jan has to go off and point to the spot in the docs. So the law clerk > is having the lawyer run around and look stuff up... don't be a help > vampire:http://slash7.com/2006/12/22/vampires/ > > Cheers! > Andrew Some how I missed this when reading this thread the first time. Nicely stated, the link is awesome. Regards, Chris |
|
From: G. A. S. <g.a...@gm...> - 2012-05-03 20:23:34
|
Hi Jan, Let me try to say it in another way. Please forgive any inaccuracies; its been a few years! :-) If my synthesizable hardware description was put in a simulation black box (call it "hdl") with some simple API that could be used like: hdl.start() for time in range(1,whatever): output_signals = hdl.next(list_of_input_signals) then as a software engineer I'd completely understand how to write a complex simulation and testbench around it. For example, if my "hdl" object defined a PCI bus card I could pretty easily write Python code that jams in a bunch of fake PCI requests and make sure the right stuff comes out. I could easily make up code that runs a bunch of these black boxes simultaneously and use unsynthesizable python to "glue" them together to make a larger system -- thereby simulating a subset of some larger system. I could even have each black box "running" at different clock speeds. Or I could even hook the simulation black box up to the actual code that will run on a CPU and talk to my FPGA. So I (as a software professional) don't need myHDL to help me do that. What I need is it to help me with is what's inside that black box. But the docs (but please remember my heavy use was several years ago) keep trying to teach me how to do the testbench part. This confused me because I kept thinking I was writing synthesizable code. And I think that the somewhat monolithic combination of both simulation and synthesizable code actually limits what can be done. In particular, in software there has ALWAYS been a tension between two software architectures, essentially the "external" or "inline" model. In XML parsing, its the difference between DOM and SAX. In DOM you see the entire tree and grab what you need (since the tree is parsed first). In SAX you wait for a callback that occurs when the parser lands on a particular tag. Its the difference between Windows 3.1 (solely event driven) and Win 95 (threaded). In the DOM model, the parser is done by the time the user code accesses the XML. They are separate. In SAX, the user code is called during parsing; the code is entangled and has restrictions (like you can't access data that comes later in the XML doc). My API example above is sort of the "DOM" style -- I'm in control of each tick and inject all my simulation signals at the top. I can choose to stop the simulation at any time. I can even fork it, save it, save the exact internal state for every clock. etc. And I can even do those things based on an internal examination of "hdl". My testbench code is clearly separated from what is under test. myHDL is more like "create a bunch of generators that give me the next values & I'll grab them when I need them." Then just say "go". The testbench is not as clearly separate. But I'm not advocating one style; is limiting to force the user to adopt one architecture or the other... modern software techniques allow both, which is why we have both "threads" and "generators" in Python. Cheers! Andrew On Thu, May 3, 2012 at 1:41 PM, Jan Decaluwe <ja...@ja...> wrote: > On 05/03/2012 05:03 PM, G. Andrew Stone wrote: > > I taught myself RTL using myHDL a long time ago and then learned > > Verilog by looking at what it output and modifying it. I'm still a > > beginner with it though... I mean its not my job so I haven't done > > much more then what people would do in college courses -- small stuff > > like PWM LEDs, drive stepper motors, etc. > > > > But folks, I think that Christopher has a few good points. It was > > HARD to learn it (but easier then learning straight Verilog). > > Thanks for that comment - it means that I reached my goal your case: > it is hard work, yes (see "Why MyHDL"), but as long as it's easier > than straight Verilog (and free),one gains. > > > The biggest issue was figuring out what can be synthesized or not. I > > mean, from a SW developer's perspective, I know perfectly well how to > > write a simulation at multiple abstraction levels. In fact the whole > > "yield" thing forces the simulation into a certain "style" which can > > be limiting. In essence, as a software professional, I don't need > > myHDL to help me write them at multiple abstraction levels EXCEPT for > > the lowest -- i.e. a synthesizable simulation. > > I don't understand that. If I want to verify a synthesizable RTL > description, which is a special kind of an event-driven model, I > need event-driven models and test benches as a verification > environment. So I really need event-driven and high-level modeling > combined - something MyHDL gives me and stock Python does not. > > Note also that your comment is the opposite of what Uri Nix just > said in another post. > > -- > 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 > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > myhdl-list mailing list > myh...@li... > https://lists.sourceforge.net/lists/listinfo/myhdl-list > |
|
From: Christopher L. <loz...@fr...> - 2012-05-03 23:45:11
|
Thanks enormously to Andy Stone for pointing out that MyHDL, while in Python is not object-oriented. There is no hardware module class, just a generator, and decorator which are functional approaches. No wonder I was not able to 'get' MyHDL. I very much think in object-oriented terms. Many years ago I wrote object-oriented manufacturing simulations of NCR's ASIC manufacturing plant. It was a roaring success. The difference in mind-set is just enormous between a functional model, and an object-oriented model. But I certainly do not want to get into a fight over it. So here is my proposal for what I need to do. http://wiki.myhdlclass.com:8080/OOHDL For those who were not able to access the wiki, please let me know. One person reported a problem, mostly he figured out it is because he is behind a corporate firewall. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
|
From: Tom D. <td...@di...> - 2012-05-04 01:10:30
|
I use classes for all the modules I plan on re-using. Very useful. The beauty of Python classes are even a hardware guy can understand how to use them. On 05/03/2012 06:45 PM, Christopher Lozinski wrote: > Thanks enormously to Andy Stone for pointing out that MyHDL, while in > Python is not object-oriented. There is no hardware module class, just > a generator, and decorator which are functional approaches. > > No wonder I was not able to 'get' MyHDL. I very much think in > object-oriented terms. Many years ago I wrote object-oriented > manufacturing simulations of NCR's ASIC manufacturing plant. It was a > roaring success. > > The difference in mind-set is just enormous between a functional model, > and an object-oriented model. But I certainly do not want to get into a > fight over it. > > So here is my proposal for what I need to do. > > http://wiki.myhdlclass.com:8080/OOHDL > > For those who were not able to access the wiki, please let me know. One > person reported a problem, mostly he figured out it is because he is > behind a corporate firewall. > |
|
From: Jan D. <ja...@ja...> - 2012-05-04 10:05:26
|
On 05/04/2012 01:45 AM, Christopher Lozinski wrote: > Thanks enormously to Andy Stone for pointing out that MyHDL, while in > Python is not object-oriented. There is no hardware module class, just > a generator, and decorator which are functional approaches. How can you even say this, when the manual has a section about object-oriented modeling, which has a Queue class, which you have just been struggling with? Perhaps this stuff really is too hard for the "general python developer", though I still don't understand why. One more attempt: MyHDL, the modeling language, is very general: as long as you feed it a number of generators communicating through signals, it is happy. It doesn't matter whether these are created by functions, classes, subclasses, mixin classes, multiple inheritance, whatever. MyHDL is therefore what you want it to be - functional, applicative, procedural, object-oriented, aspect oriented, whatever. It is only when you need conversion that restrictions drop in, but identifying MyHDL with conversion or synthesis restrictions is a sign of basic misunderstanding. I understand that this may not have been clear enough in the past: but this should be fixed now with the What MyHDL is not page, and when I separate synthesizable/non-synthesizable chapters in the manual. > No wonder I was not able to 'get' MyHDL. I very much think in > object-oriented terms. Many years ago I wrote object-oriented > manufacturing simulations of NCR's ASIC manufacturing plant. It was a > roaring success. > > The difference in mind-set is just enormous between a functional model, > and an object-oriented model. But I certainly do not want to get into a > fight over it. > > So here is my proposal for what I need to do. > > http://wiki.myhdlclass.com:8080/OOHDL Coupling a sensitivity list to a module makes no sense. -- 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-05-04 12:18:48
|
On 5/4/12 5:04 AM, Jan Decaluwe wrote: > On 05/04/2012 01:45 AM, Christopher Lozinski wrote: >> Thanks enormously to Andy Stone for pointing out that MyHDL, while in >> Python is not object-oriented. There is no hardware module class, just >> a generator, and decorator which are functional approaches. > How can you even say this, Actually the wiki says it. http://www.myhdl.org/doc/0.6/manual/intro.html In MyHDL, classic functions are used to model hardware modules. In particular, the parameter list is used to define the interface. I would rather see objects being used to model hardware modules. In particular the instance variables should be used to model the interface. (and internal signals). Here is another one. http://www.myhdl.org/doc/current/manual/modeling.html In MyHDL, an instance is recursively defined as being either a sequence of instances, or a generator. Hierarchy is modeled by defining instances in a higher-level function, and returning them. That does sound to me like a functional approach. I would rather see hardware modules defined "in a higher level object" a module with parent and child nodes. I would expect a hierarchy of chip modules, each of which points to its children and parents. Then let me quote others: Andrew Stone said this is what he expected: In fact, what I thought myHDL was going to let me do is create classes that define blocks of logic at the RTL level (synthesizable), perhaps with inputs and output "Signals" as variables passed in the constructor and then by instantiating those classes I'd be in effect plunking down copies of that logic in the FPGA (or within larger logic blocks by instantiating these within the constructor of another class). 4 years ago I did not ever figure out how to do this... I don't think anything wrapped in a class was synthesizable back then. But maybe that has changed now; I haven't tried using classes since. And yes, Dillon wrote that he does this, but I think we will find the details of how he does it are different than at least what I would expect. In particular MyHDL does not pass variables into the object constructor, it passes them into the generator. There are no parent or child links. > when the manual has a section about > object-oriented modeling, which has a Queue class, which you have > just been struggling with? If I recall correctly, the Queue class is not inside a @always, @instance, or @always_comb, so it is not synthesizable. While MyHDL is quite general, it is only the synthesizable stuff I am interested in. Jan Decaluwe wrote: >Perhaps this stuff really is too hard for the "general python developer", though I >still don't understand why. Because it does not fit the way we see the world. Different people have different world views. I am doing my best to explain my world view. In particular one of my concepts is that every real world thing should be represented by a class. So flip flops, adders, multipliers should each be represented by a class. And then I mostly want the documentation to be a listing of the classes, representing physical objects, available to me to work with. And yes the existing MyHDL documentation would also be useful. I now understand it is a hugely different view from the prevailing view on this mailing list. And that is why we keep clashing. It is why I am just not able to 'get' MyHDL. Because we are operating under two different world views. -- Regards Christopher Lozinski Check out my iPhone apps TextFaster and EmailFaster http://textfaster.com Expect a paradigm shift. http://MyHDL.org |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X