| ??? 11/13/06 00:29 Read: times |
#127838 - Static Timing Analysis and those "young engineers" Responding to: ???'s previous message |
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! They don't care whether their design works well over the long haul, since they've then collected their bonus bonus? where? 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. 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. 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 |
