| ??? 11/13/06 06:28 Read: times |
#127851 - It's a sign of the times, I suppose Responding to: ???'s previous message |
Andy Peters said: Richard Erlacher said:
But what about your customer?
No question, there are some things that work out in a page of code that would take longer to enter in a schematic. One popular example is a HEX-to-7-segment encoder. Then, of course, a decoder would probably be just as much trouble. I'm not totally in disagreement about what's workable or easier. I just have to work around the question of, "easier for whom?" all the time. It's all about the documentation from where I sit. I have to have documentation that actually represents what the customer agreed to buy. As a consequence, I have to present it in a form that my customer, normally a very senior engineer, now in a management position, can readily see addresses his initial requirements, and can understand, at least to his own satisfaction. He doesn't want to become an expert on my particular implementation, but he was already an expert on what he wanted before my work started, and he wants to be assured, formally, that what he's been sold is what he agreed to buy. OK, so if your customer requires you to provide schematics, then you provide schematics. Fair enough. Your customer is, unfortunately, still living in the stone age. If you don't do post-fit or post-PAR timing simulations, you've no idea whether the circuit will perform as claimed. BULLSHIT. Routing delays can vary considerably. Most of the time spent on making FPGA's work is spent on making the routing work out so that the timing isn't all fouled up by the time it's done. Yes, you can simply say, "The $20 FPGA is too slow, so we have to use the $120 one..." but that won't please anybody, except perhaps the guy who demanded the upgrade. The WHOLE POINT of running static timing analysis on the placed and routed design is so you KNOW that your design meets your timing constraints. If your timing constraints are incomplete, then you need to rethink how you specify them. Routing delays are taken into account. Look at any timing report -- a big part of it is detailing the worst-case routing delay. Also included is clock-to-output delays on output pins, setup and hold times for input pins (w.r.t. the clock). And here's a good question for you. When you run your post-route simulations, what sort of models are you using for your stimulus? It's one thing to simulate the FPGA to see if its internal logic meets timing (and you already know that from the STA), but it's quite another thing to know if your FPGA meets your SDRAM's timing requirements. If you do a post-route simulation that doesn't include the peripheral timing, you're wasting your time. I have a library of models that are functional and including timing information. A simple generic turns off timing checks and delays. This is useful because when doing a functional analysis of a fully synchronous design, you don't have to worry about timing when doing the RTL coding, and if I do, for whatever reason, want to do a post-route timing sim, I can. You do your functional simulations and ensure the logic is correct. Then you let the synthesizer and fitter tools do their work. You run the STA on the fitter results, and if you meet timing (STA tells you), you know that your design will work. If you don't meet timing, there's no point in running a post-route simulation (or worse, programming the chip on a board). The STA tells you what paths don't meet timing, and then you go back to either your synth/fitter configuration constraints (change fan-outs/fan-ins, duplicate registers for speed, etc.; there's a bunch of options). If you still can't get the code to meet timing, you can go back and look at the specific logic that fails and change your code. It may very well turn out that the FPGA doesn't go as fast as you need for particular bits of code and you have to rethink your implementation. The worst case is that you DO have to bite the bullet and get a faster part. And here, too, the STA is helpful: you can tell the tools that you wish to analyze the logic if it was fit into a faster part. No need to re-run all of the tools. The issue with which I'm constantly confronted is that young engineers (the ones under 40) are not really dedicated to doing the job. They're interested in (a) getting the job, (b) keeping the job, and (c) moving on to a "better" job. Perhaps the work isn't challenging or interesting. Young engineers find that rehashing a small part of someone else's older design is useful for learning how a company's system works, but if it turns out that all that person will do is rehashing the same thing over and over, of course that person will leave! In 27 years, I've had only one guy leave of his own volition, and that was because of a family necessity. I've had two partners leave for health reasons, and one retire because he was ready to do that, having worked for over 50 years. I've let a number of guys go, sometimes because they worked for me and I wasn't happy with their work, and, in other cases I've advised my clients to let some guys go (1) because they took time off when they hadn't caught up on their work, or (2) because they were doing things and consuming resources not related to completing their work. Often they were caught up in padding their resume by buying tools solely so they could list them on their resume'. I hope it helped 'em. AFAIK, none of them has ever found work in this region since then. I don't give work left incomplete by one man to another. I handle it myself, generally speaking. If I assign work to someone, it's theirs and theirs alone. I don't like the situation where you have five guys assigned to a job, and one or two of them doing the work and the rest fighting over who takes credit. My staff has never been large, and it varies depending on workload. Both my car and my house are very modest, and seldom as large and fancy as those of my coworkers, though a couple of my former partners outdid me in that respect. None of us have been impressed by visible ostentation. I guess things have changed of late. They don't care whether their design works well over the long haul, since they've then collected their bonus bonus? where? Guys are often given a substantial reward for completing their work within schedule and budget, if and only if their documentation and deliverables are complete and correct. and moved on to another company that wants the technology someone has already paid to have developed. That's why the managers don't like the HDL-only presentation, because they have to hire someone to translate it into terms they can understand and believe. They know they can't rely on those youngsters who were taught HDL and for whom schematics are less interesting. They know they will find omissions in the documenatation, skipped simulation efforts, and slight of hand in the presentation. They know they can't trust 'em. That's why they, the senior engineers and managers, want to get their hands around what's really been done. That works both ways. I don't know how many times I've been handed the work of a "senior person" who left the company and been told "fix this." Schematics that don't make sense, no design notes indicating why something was done, stupid net names, you name it. And yeah, I can read a schematic. I see WHAT it does. I want to know WHY it does it. The point is that a lazy engineer will implement a design in the laziest, least-documented fashion possible, regardless of design entry method. And blaming younger engineers for laziness is missing the point. The younger engineers need to be trained to be diligent in their work, and they really do emulate the methods of the people for whom they work. If they see that all design entry (again, regardless of format) is undocumented and slapdash, their designs will be undocumented and slapdash. If a company has rigorous coding styles and documentation requirements that senior engineers agree with and actually use, the young engineer will conform. My outfit is small enough that we don't focus so much on rigorous styles, but we do focus on requirements and strict adherence to them. I always discourage making any allowance or provision for things not precisely specified in the initial requirements. If a customer comes along later wishing changes before the work is done because he forgot something, I tell him to get out his checkbook. And if they see senior people disparaging a design entry method or work flow or documentation style, then (since they are young and don't know any better), they will adopt that attitude. I'm not in this to train people on the job. I engage people who already know how to do what I want done the way I want it done, and within schedule and budget. I don't get anything for being late, and neither do those with whom I'm working. Maybe I'm the oddball, but as I gained experience, I grasped the utility of functional simulations and formal verification, even when others around me were doing burn-and-crash FPGA design. It was hard being the young guy trying to convince the elders that maybe there was a better way to do things. I'm not so young anymore (40, last I checked), but I seem to still have that problem.
-a I'm not expert in VHDL and I'm completely illiterate in Verilog. I'm not as experienced with FPGA implementation as you either. I can get the job done in VHDL, but that's not what I'm generally asked to do. The issue is one of meeting the customer's requirements. If he wants schematics, we can produce useable schematics that he can understand, but the primary responsibility I feel I have is to provide him the work in which he can have confidence. If that means producing schematics from which the design is generated, then that's what we do. I've not yet had a client fold or sue me because we failed to provide him what he agreed he wanted us to deliver. I've only gotten into trouble in cases where I made the mistake of taking on inadequately specified work for people whose requirements I thought I understood. In cases where I was wrong, I've been bitten in the *ss, but I've yet to be sued or had a client fold under me. I've seen it happen to others, though. I avoid taking on tasks where there's no formal agreement on what I'm to deliver and when. I require agreement on exactly what tests I have to pass on my deliverables in order to get paid. It's only been when I've worked for or with "friends" that I've had problems. Keep in mind that senior engineers went to school before there was 'C' and before there was VHISIC and VHDL. They were working with DTL and RTL if not relays. When I was in college, transistor radios were still new. Yes, we have to struggle to keep up, but the newest isn't always the best. My most successful colleagues have made their fortunes not with bleeding-edge hardware, but with post-war technology applied in applications still working quite successfully with 19th century technology. While I like FPGA and CPLD application, I don't like the way in which vendors present them to the user community. I once lived on "evaluation boards" which I could string together in order to build large and complex functional systems in order to prove concepts, and, afterward, tear them down and put them back on the shelf and use them again later. Todays eval boards are like 10 pounds of sh*t in a 5-pound bag, with the "features" always in the way. If it weren't for the short market life of current-generation programmable logic, I'd just build my own boards. The way this thread started, the O/P was asking about how to get started. Well, I've always believed that a board with just the minimal amount of hardware would suit best. Guys who haven't been doing programmable logic have been drawing schematics with discrete (MSI/SSI) logic and MCU's. For them to abandon what they've been doing and start over, cold, in an unfamiliar HDL is too much "future shock" for them, IMHO, so that's why I've promoted sticking with schematic entry. That allows a person starting in CPLD/FPGA application to use what he knows. Evetually he'll have to learn to do what the big boys do. Let him start small, though. He can provably amuse himself for some time with CPLD's, which are well suited for circuits entered in schematic form, particularly if they already work in schematic form in existing applications. Seeing that translation work will be a big plus in providing confidence in doing what he can't directly observe. It will get him familiarized with simulation, testbenches, and prepare him for the somewhat more murky world of FPGA application. Just as it often happens that the guys jump all over a guy who asks a question about doing something in a way they don't like gets mobbed with "why would you want to do that?" rather than "here's how to do that, though you might better do this ..." Instead of considering why I promote schematics in a case such as this one, I get a lot of, "Why would you want to use schematics..." It doesn't surprise me. There are reasons why I think it appropriate in this context, and there are reasons why I use 'em as much as I do in my work. It's because the meet my needs and satisfy my clients' needs. RE |
