On Jul 26, 12:50 pm, "Icky Thwacket" <i...@it.it> wrote:> "rickman" <gnu...@gmail.com> wrote in message > > news:f3419e72-2cf2-4a01-8300-c5184afc38f7@34g2000hsh.googlegroups.com... > > > > > On Jul 26, 10:12 am, Frank Buss <f...@frank-buss.de> wrote: > >> rickman wrote: > > > The process based description is not immediately clear to me at first > > glance. I *do* have to think about it since that is not what I > > picture in my mind. I visualize a MUX controlled by GenEn feeding an > > AND gate with BERTSel. The Verilog like assignment maps exactly to > > that visualization. The others require me to mentally convert the > > syntax from and IF statement to the AND gate not to mention the length > > of the code. But like I said, it is not that this is hard to > > understand, it is not what I pictured in my mind and so I had to > > perform a conversion from the logic to the syntax. That takes time > > and is a distraction from making my work accurate. > > > I have no doubt that others may find that verbose code is easier for > > them to read. But I find concise code is best (but not too! > > concise). There are any number of different logic forms to be > > expressed and each is expressed best in different ways. I think the > > selection statement is an operator that has a useful place in VHDL. > > I'm just sorry it wasn't included. I guess it would have been hard to > > provide for overloading since it does not fit the standard uniary or > > binary format. > > > Rick > > So why do you not use schematic capture tools for your designs - or is that > too uncool? > > IckyIs this a serious question? Or are you just playing devil's advocate? Probably the single biggest reason to use an HDL instead of schematics is the portability it provides. Schematics have always locked you into a manufacturer unless you are willing to reenter your design for every company's chips you wish to try. But I was a diehard on schematics. Just like Ray Andraka, I saw a lot of utility in them. He finally switched when he found that he could instantiate primitives and achieve the same degree of control over the design details that he got with schematics. I switched when I found out how handy it was to have text based designs instead of proprietary formatted schematics. But there are any number of other reasons. Do you really not understand what they are? I don't think I ever considered schematics "uncool". In fact, one of the cooler things about being an engineer is having an E sized print of a schematic design hanging on your wall. Rick
Creating new operators
Started by ●July 26, 2008
Reply by ●July 26, 20082008-07-26
Reply by ●July 26, 20082008-07-26
rickman wrote:> The process based description is not immediately clear to me at first > glance. I *do* have to think about it since that is not what I > picture in my mind. I visualize a MUX controlled by GenEn feeding an > AND gate with BERTSel. The Verilog like assignment maps exactly to > that visualization. The others require me to mentally convert the > syntax from and IF statement to the AND gate not to mention the length > of the code.For me it is more like a tree: The process form with the nested if statements forms a tree, which I can see immediatly (maybe because I'm used to program in Java and C), where the two main branches are selected by BERTSel and the second branch is the mux. This is more clear for me than using an AND gate. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Reply by ●July 26, 20082008-07-26
"rickman" <gnuarm@gmail.com> wrote in message news:6aaeaa92-c512-4f6a-b134-483bd7615592@m36g2000hse.googlegroups.com...> On Jul 26, 12:50 pm, "Icky Thwacket" <i...@it.it> wrote: >> "rickman" <gnu...@gmail.com> wrote in message>> >> So why do you not use schematic capture tools for your designs - or is >> that >> too uncool? >> >> Icky > > Is this a serious question? Or are you just playing devil's > advocate? > > Probably the single biggest reason to use an HDL instead of schematics > is the portability it provides. Schematics have always locked you > into a manufacturer unless you are willing to reenter your design for > every company's chips you wish to try. > > But I was a diehard on schematics. Just like Ray Andraka, I saw a lot > of utility in them. He finally switched when he found that he could > instantiate primitives and achieve the same degree of control over the > design details that he got with schematics. I switched when I found > out how handy it was to have text based designs instead of proprietary > formatted schematics. But there are any number of other reasons. Do > you really not understand what they are? I don't think I ever > considered schematics "uncool". In fact, one of the cooler things > about being an engineer is having an E sized print of a schematic > design hanging on your wall. > > RickYep that is a totally serious question. An HDL gives you portability? - Are YOU serious? If you are making the best use of the internal FPGA resources an HDL cannot give you portability, as soon as you instantiate a higher level hardware function integrated into the device (I am specifically talking DSP/SERDES type integration here) you are straight away locked into an vendor. The only way an HDL remains 'portable' is if you work at the primitive level, something that I certainly am not prepared to do! Icky
Reply by ●July 26, 20082008-07-26
Icky Thwacket wrote:> If you are making the best use of the internal FPGA resources an HDL cannot > give you portability, as soon as you instantiate a higher level hardware > function integrated into the device (I am specifically talking DSP/SERDES > type integration here) you are straight away locked into an vendor.You can encapsulate vendor specific hardware functions in different entieties in VHDL. I've seen this e.g. for memory on OpenCores projects, which works for Altera and Xilinx without needing to change the main VHDL entities. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.de
Reply by ●July 26, 20082008-07-26
On Sat, 26 Jul 2008 06:04:01 -0700, rickman wrote:> BERTEn <= BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel; > > This is what I expect a concurrent statement to look like, not to > mention that it represents exactly the image I had in my head and on > the whiteboard, making it much easier to write. > > I am sure there are those who disagree and much prefer the verbose > process. Maybe I'm just not cut out for the regimen of VHDL.I'm not _entirely_ cut out for the regimen of VHDL, which is why I have the imaginary BerryHDL which is considerably more terse than VHDL, eg: http://myweb.tiscali.co.uk/pault/example.html The main thrust of it is to represent schematic type blocks efficiently with text. A general mux is as follows: node muxOutput = [a, b, c, d][sel]; That's a mux with four inputs. Your example would be: node BERTEn = BERTSel & [!GenPOSSel, !SyncPOSSel][GenEn]; Which I think is better than a ternary type operator. Doesn't python allow you to do something like that? You may find that MyHDL will do something similar to the above? And MyHDL isn't imaginary. Regards, Paul.
Reply by ●July 27, 20082008-07-27
rickman wrote:> BERTEn <= BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel); > > Is that more clear?Yes. In any case, I agree with KJ on this one. Take it out of time with a function: function sel (choice : boolean; a, b : std_logic_vector) return std_logic_vector is begin if choice then return a; else return b; end if; end function sel; -- Mike Treseler
Reply by ●July 27, 20082008-07-27
On Jul 27, 1:04 am, rickman <gnu...@gmail.com> wrote:> On Jul 26, 7:56 am, Brian Drummond <brian_drumm...@btconnect.com> > wrote:> BERTEn <= '0' when BERTSel = '0' else > not SyncPOSSel when GenEn = '0' else > not GenPOSSel; > > I don't think that the diagram I drew comes to mind when you see this > code. Maybe a process with an IF statement would be slightly more > clear, but the verbosity presents an obfuscation of its own from the > "clutter" created. > > process ( BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin > if (BERTSel = '0') then > BERTEn <= '0'; > elsif (GenEn = '0') then > BERTEn <= not SyncPOSSel > else > BERTEn <= not GenPOSSel; > end if; > end process; > > The clutter is from the sheer size of the code. The first three line > example is a bit obtuse, the 9 line example is large enough to make it > hard to see the rest of the code and so to see how it fits into the > big picture. Compare the two examples to this code... > > BERTEn <= BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel; > > This is what I expect a concurrent statement to look like, not to > mention that it represents exactly the image I had in my head and on > the whiteboard, making it much easier to write. >There's also combinatoric expression in a concurrent statement: BERTEn <= (BERTSel and not GenEN and not SyncPOSSel) or (BERTSel and GenEN and not GenPOSSel ); This also shows it's a two input multiplexer with a select line and an enable, which you could do as a block statement, component or subprogram and invoke like a component or subprogram. Seriously, you can always write a preprocessor that recognizes your preferred syntax and translates it into correct VHDL for analysis. Some of us are old enough to remember WATFOR and the like, adding things like case statements to Fortran. A preprocessor for the above preferred syntax could recognize a concurrent signal assigment with a right hand side containing '?' and ':' in matching numbers..The associativity precedence can be a right royal pain, requiring lookahead or recursion. For full integration with a tool environment you might need to write an analyzer wrapper that invokes the preprocessor, as is done for cpp. In and environment where you can use make files, you can hide the complexity there. Instant language syntax extensions.
Reply by ●July 27, 20082008-07-27
On Jul 26, 3:16 pm, Frank Buss <f...@frank-buss.de> wrote:> rickman wrote: > > The process based description is not immediately clear to me at first > > glance. I *do* have to think about it since that is not what I > > picture in my mind. I visualize a MUX controlled by GenEn feeding an > > AND gate with BERTSel. The Verilog like assignment maps exactly to > > that visualization. The others require me to mentally convert the > > syntax from and IF statement to the AND gate not to mention the length > > of the code. > > For me it is more like a tree: The process form with the nested if > statements forms a tree, which I can see immediatly (maybe because I'm used > to program in Java and C), where the two main branches are selected by > BERTSel and the second branch is the mux. This is more clear for me than > using an AND gate.You may read the code easily, but that is not what I was doing. I was writing the code. I had the idea of what I wanted to write expressed as a diagram. It should have been a simple matter to write code that directly expressed that simple diagram. Instead, I had to work the logic around to fit the constructs available in the language. This is completely ignoring the difference between some 8 or 10 lines of code in the process vs. a single line of perfectly clear code using the select statement. Rick
Reply by ●July 27, 20082008-07-27
On Sun, 27 Jul 2008, diogratia wrote: |------------------------------------------------------------------------| |"[..] | | | |Seriously, you can always write a preprocessor that recognizes your | |preferred syntax and translates it into correct VHDL for analysis. | |Some of us are old enough to remember WATFOR and the like, adding | |things like case statements to Fortran. | | | |A preprocessor for the above preferred syntax could recognize a | |concurrent signal assigment with a right hand side containing '?' and | |':' in matching numbers..The associativity precedence can be a right | |royal pain, requiring lookahead or recursion. | | | |For full integration with a tool environment you might need to write | |an analyzer wrapper that invokes the preprocessor, as is done for | |cpp. In and environment where you can use make files, you can hide | |the complexity there. | | | |Instant language syntax extensions." | |------------------------------------------------------------------------| I would prefer to use one tool which supports the language I am using instead of a preprocessor which supports some of it by replacing strings by other strings to be given to another tool which tries to cope with another part of the language. Would you suggest that someone who does not want to use such a preprocessor should write an entire extended language frontend (perhaps written by reusing code from a full proper BNF-based VHDL frontend)?
Reply by ●July 27, 20082008-07-27
On Sat, 26 Jul 2008, Brian Drummond wrote: |------------------------------------------------------------------------| |"On Sat, 26 Jul 2008 10:31:32 +0100, Jonathan Bromley | |<jonathan.bromley@MYCOMPANY.com> wrote: | | | |>On Fri, 25 Jul 2008 22:46:26 -0700 (PDT), rickman wrote: | |> | |>>In VHDL an operator can be overloaded. But can a new operator be | |>>created? There is more than once I would like to use the very concise| |>>notation available in Verilog such as the select operator. Is there a| |>>way to create the selection operator in VHDL? Looking at the | |>>structure, I guess it just doesn't fit the mold for VHDL with three | |>>operands. | |> | |>No, you can't create new VHDL operators. Apart from | |>introducing new pseudo-keywords into the language, this would | |>also raise the nasty difficulty that operators have many other | |>hidden properties apart from their function signature. | |>Operators have precedence and associativity. And of course, | |>as you say, VHDL has no notion of 3-ary operators like ?: | |>in any case. | |> | |>Algol-68 tried to make it possible to create arbitrary | |>user-defined operators, and it was VERY complicated... | | | |More dynamic OO languages support arbitrary operator creation; Smalltalk| |would be an example, or the old Linn Lingo. | | | |It's not VERY complicated _in_that_environment_ where static typing is | |almost non-existent (strong typing can be rigorous, but implemented at | |runtime)" | |------------------------------------------------------------------------| Dynamic strong typing instead of static strong typing is not very useful. Smalltalk programs crash. Lisp programs crash. Statically typed programs also crash, but are less prone to having their crashes caused by things which could have been detected during compilation. |------------------------------------------------------------------------| |" BUT ... | |(1) you are limited to the creation of binary operators; so ?: is still | |tricky, to put it mildly, and" | |------------------------------------------------------------------------| I do not remember whether this is true with PROLOG. |------------------------------------------------------------------------| |"(2) operator precedence is usually predetermined and deeply embedded in| |the parser." | |------------------------------------------------------------------------| In Prolog one can choose any precedence and any location (viz. prefix; infix; and postfix) and probably (but I do not remember for sure) any associativity for user-defined operators (and even worse, allows these to be redefined for standard operators). |------------------------------------------------------------------------| |" The above languages solved this problem by allocating | |precisely one precedence level to all operators - in other words, use | |brackets." | |------------------------------------------------------------------------| A good choice. Operators which are otherwise identical have different precedences in different languages so people shall make mistakes according to what they are used to. |------------------------------------------------------------------------| |"[..] | | | |But anyway I suspect you'd have to destroy VHDL to add extensible | |operators... | | | |[..]" | |------------------------------------------------------------------------| I do not approve of user-defined operators. Operators at all are debatable. Functions or conditional statements should be enough. Thank you for the interesting observations. Regards, Colin Paul Gloster
