From: krw on 16 Apr 2010 20:14 On Fri, 16 Apr 2010 16:50:45 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:06rhs5pqejo9trp4adu3u1diqrpdbt239u(a)4ax.com... >> I wish I >> kept the book I used (one of the FPGA vendors gave it to me and as soon as I >> moved on to Ashenden it sprouted legs). > >Ever looked at Ben Cohen's books? There's a man who like a VERY orderly >design process! No, but just took a quick look on Amazon. Seems reasonable. The book I used was pretty much VHDL for synthesis only, which greatly reduces the complexity of the language. I picked up the rest as I went along. Ashenden is OK for a reference but you're not going to learn much from it.
From: Joel Koltner on 16 Apr 2010 20:25 <krw(a)att.bizzzzzzzzzzzz> wrote in message news:b5vhs5h4j3vpcp7gcr52atpnlh2kiqvsk6(a)4ax.com... > No, but just took a quick look on Amazon. Seems reasonable. The book I > used > was pretty much VHDL for synthesis only, which greatly reduces the > complexity > of the language. I picked up the rest as I went along. Ashenden is OK for > a > reference but you're not going to learn much from it. My favorite book was "VHDL for Logic Synthesis" by Andrew Rushton. For several years it and Kevin Skahill's "VHDL for Programmable Logic" (OK, but not great -- never even finished reading it) were the only two books I had on VHDL. Ashenden's name started coming up a lot in later years there; seems to be quite popular. ---Joel
From: krw on 16 Apr 2010 20:33 On Fri, 16 Apr 2010 16:48:08 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:l1rhs5dh3uakl9ev2jbqgibistiu1i3r67(a)4ax.com... >> On Fri, 16 Apr 2010 11:05:14 -0700, "Joel Koltner" >>>VHDL especially... talk about overly-wordy... >> Wordy, yes, but for good reason. > >I've received errors from VHDL compilers to the effect of, e.g., "there needs >to be a colon precisely HERE; please insert it and re-compile." -- If a >compiler is smart enough to know EXACTLY what's "missing," let me suggest that >maybe the language doesn't need that bit of syntax or whatever in the first >place... Yes, that's part of it being a very strongly typed language. It's *not* going to fix anything whether it knows how or not. It lets you shoot yourself. BTW, I had the same comments about ForTran compilers (in particular WatFOR and WatFIV). >But in general I prefer concise languages. E.g., simple closing constructs >such as brackets in C/C++ or plain old tabs in Python rather than "end for," >"end loop," "end xxxxx" like VHDL (...and Visual BASIC and...). Ick. You are a sick puppy! I *HATE* C, and everything that it stands for. PL/I was more to my liking. I don't think I've done any programming in anything other than assembler for 20 years, though. >That being said, back when I used to write VHDL (I haven't in... wow... the >better part of a decade now), I slowly built up a bunch of utility functions >and various types/structures and what-not and eventually got to the point >where I didn't feel like I was fighting with the language anymore and could >quickly and reasonably easily express the functionality I was after. (Instead >I got to the point where I discovered constructs like ALIAS were only >*partially* supported for synthesis in Synplicity... and Synplicity was >already heads and shoulders above the piece of junk that was Synopsys's FPGA >Express [aka, Distress]... no wonder Synposys bought them!) A decade ago Synplicity was the only game in town. Now they're all pretty good. I have no clue what drugs Synopsis is on, though. They've sold the "VHDL design == programming" to a *lot* of PHBs, though. >> Fun? You must like dentists, too. ;-) > >The thing I like and enjoy about programming is that, being "all digital," >generally things either work or they don't work, and if they don't work >there's usually little or no cost involved by approaching the problem from an >entirely different angle. Contrast that with, e.g,. RF design, where (1) >you'd better come up with a reasonably good hardware architecture in the first >place, as choosing poorly tends to be much more expensive in that board turns >are required... and (2) while it's no problem making a receiver or whatever >that "generally" works, you can expend a ton of time trying to meet >sensitivity specs or interference specs or whatever, and yet there's often not >a whole lot to show for it: Some shielding here, some layout changes there, >some component value changes over yonder -- not anything the average person >will notice. I don't do RF either. Never had the interest or need. >In other words, I find some programming to be a relaxing thing to do when the >difficult things start to become a little stressful. Of course, getting the >difficult things to work is far more rewarding as well -- I wouldn't want to >be a professional software writer, or at least not for the kind of software I >write that's usually some weird little utility routine or whatnot but >certainly not anything truly difficult/innovative (like a Google-level search >engine, for instance); that'd get boring fast. I don't like programming because it puts me to sleep. I like designing hardware. VHDL is a nice tool to get there (though it too will put me to sleep). >Programmable logic design is kind of inbetween these two extremes -- it stills >works or it doesn't, mistakes are usually cheap (unless you completely >mis-estimate the scope of the problem and need a bigger part), but hopefully >the whole problem is due to having to perform some operation quickly or >otherwise very efficienctly because that's why you picked an FPGA in the first >place. When painting floors, always leave the back door open. I always start with a bigger part than I need (except the design I haven't been working on lately - only one part in the package I need) and use the extra space for debug hardware. Before production just change the BOM to a smaller part with the same footprint. >(Just sweeping up a few random logic gates into a PLD is more of a >chore than "fun.") One of the most interesting FPGA designs I did was a >memory controller that had a bunch of FIFOed interfaces to various data >consumers/generators hooked up to a 32-channel 2D DMA engine all connected to >8 sticks (4GB) of PC133 SDRAM... the fun part was trying to make the thing >reasonably efficienct under the memory access demands of the numerous >different DMA clients, so the core memory controller would usually be working >on two transactions in parallel and would interleave various RAS and CAS >cycles and even re-order memory accesses (then re-re-ordering them back >correctly inside the controller) in order to try to never have to stall >waiting for a page's precharge delay (that was something like 8 cycles). The design I did for LM was a color TV camera. One thing I learned was how a destroyer can cost $3B ($4K for each FPGA, $5K for each CCD, $45K for the prism, who knows how many millions for the mount - because the port hole is too small to meet specs). >Granted, if you were working on superscalar CPUs back at IBM, this probably >isn't that impressive... :-) ...but as I say, it was certainly fun for me at >the time! Memory controllers can be pretty impressive beasts. The above camera used the Xilinx controller but I just swiped the design out of the FLIR camera (the color camera's Siamese twin). Yes, there was a bit of stuff in the G5. ;-)
From: krw on 16 Apr 2010 20:39 On Fri, 16 Apr 2010 17:25:20 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:b5vhs5h4j3vpcp7gcr52atpnlh2kiqvsk6(a)4ax.com... >> No, but just took a quick look on Amazon. Seems reasonable. The book I >> used >> was pretty much VHDL for synthesis only, which greatly reduces the >> complexity >> of the language. I picked up the rest as I went along. Ashenden is OK for >> a >> reference but you're not going to learn much from it. > >My favorite book was "VHDL for Logic Synthesis" by Andrew Rushton. The title sounds right but the author certainly isn't (Indian name, IIRC). >For >several years it and Kevin Skahill's "VHDL for Programmable Logic" (OK, but >not great -- never even finished reading it) were the only two books I had on >VHDL. I bought another a couple years back but it was worthless too. I use it as a shelf filler. >Ashenden's name started coming up a lot in later years there; seems to be >quite popular. Ashenden is very common as a language reference. It's next to unreadable though. I may have to buy another, its binding is falling apart.
From: John Larkin on 16 Apr 2010 21:06
On Fri, 16 Apr 2010 16:48:08 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:l1rhs5dh3uakl9ev2jbqgibistiu1i3r67(a)4ax.com... >> On Fri, 16 Apr 2010 11:05:14 -0700, "Joel Koltner" >>>VHDL especially... talk about overly-wordy... >> Wordy, yes, but for good reason. > >I've received errors from VHDL compilers to the effect of, e.g., "there needs >to be a colon precisely HERE; please insert it and re-compile." -- If a >compiler is smart enough to know EXACTLY what's "missing," let me suggest that >maybe the language doesn't need that bit of syntax or whatever in the first >place... > >But in general I prefer concise languages. E.g., simple closing constructs >such as brackets in C/C++ or plain old tabs in Python rather than "end for," >"end loop," "end xxxxx" like VHDL (...and Visual BASIC and...). > >That being said, back when I used to write VHDL (I haven't in... wow... the >better part of a decade now), I slowly built up a bunch of utility functions >and various types/structures and what-not and eventually got to the point >where I didn't feel like I was fighting with the language anymore and could >quickly and reasonably easily express the functionality I was after. (Instead >I got to the point where I discovered constructs like ALIAS were only >*partially* supported for synthesis in Synplicity... and Synplicity was >already heads and shoulders above the piece of junk that was Synopsys's FPGA >Express [aka, Distress]... no wonder Synposys bought them!) > >> Fun? You must like dentists, too. ;-) > >The thing I like and enjoy about programming is that, being "all digital," >generally things either work or they don't work, and if they don't work >there's usually little or no cost involved by approaching the problem from an >entirely different angle. Contrast that with, e.g,. RF design, where (1) >you'd better come up with a reasonably good hardware architecture in the first >place, as choosing poorly tends to be much more expensive in that board turns >are required... and (2) while it's no problem making a receiver or whatever >that "generally" works, you can expend a ton of time trying to meet >sensitivity specs or interference specs or whatever, and yet there's often not >a whole lot to show for it: Some shielding here, some layout changes there, >some component value changes over yonder -- not anything the average person >will notice. > >In other words, I find some programming to be a relaxing thing to do when the >difficult things start to become a little stressful. Of course, getting the >difficult things to work is far more rewarding as well -- I wouldn't want to >be a professional software writer, or at least not for the kind of software I >write that's usually some weird little utility routine or whatnot but >certainly not anything truly difficult/innovative (like a Google-level search >engine, for instance); that'd get boring fast. There is a closed-system purity to logic design that appeals to some minds. And there's the messy, unstructured fuzziness of analog design that appeals to others (like mine.) If I program for more than a couple of weeks at a time, I get depressed. I can design circuits forever. John |