Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
steve wrote: > "A good designer should > avoid tying excessive investments of time or money to decisions which > are > likely to be undone later. " > > In other words designers have to be fortune tellers. Not all forecasting is prognostication. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87451
Marc Battyani schrieb: > It must be faster than a 3.6GHz Xeon > which can do that in 18.5 clock cycles on average on a 1000 float vector > (using SSE3) >[...] I've looked > at cordic at a glance, but it looks slower or bigger if totally unrolled. Why would you want to unroll it? Kolja SulimmaArticle: 87452
"Ray Andraka" <ray@andraka.com> wrote: > Marc Battyani wrote: > > >I'm looking at the fastest way to compute floating point (32bit) log and exp > >on an FPGA (Stratix II or Virtex 4). It must be faster than a 3.6GHz Xeon > >which can do that in 18.5 clock cycles on average on a 1000 float vector > >(using SSE3) > > > >So far I've found that with a few tables and floating point MUL and ADD > >blocks I should be able to do that at 160MHz on a Stratix II (not tested > >yet). It's still slower than the Xeon but at least it's close. I've looked > >at cordic at a glance, but it looks slower or bigger if totally unrolled. > > > You didn't mention how much precision you need, nor for that matter what > the log base is to be. Log > is actually easier to compute for a floating point argument, since the > significand is already presumably > normalized, which reduces the complexity of computing the log since the > range is limited. for fixed point, > the usual approach is to normalize it first, essentially converting to > floating point. Log base 2 is a little > bit easier than other bases because the floating point exponent is the > integer portion of the log. The fraction > portion can be computed with a small (4 input) look-up to get you to 1/2 > dB or so. If you need more > precision, there are iterative techniques that can get you to whatever > precision you need. Exponent is the > reverse: you use a look-up to exponentiate the fractional portion and > then use the integer portion to control > how much the exponentiated fraction is shifted. This can be pipelined, > and run at over 200 MS/sec in a single > thread in Spartan3 FPGAs, faster in premium devices. > > Do you need the log in floating point too, or is it fixed point log > notation? Most importantly, what is the precision requirement? I need the log as an IEEE754 32 bit floating point with full precision from an input also in IEEE754 32 bit floating point format. (Maybe this will be changed to extended floating point (40 bits) So far I take the mantissa, use the first bits to select the coeffs of a small polynomial in a LUT, apply the polynomial to the mantissa, and add the exponent multiplied by a coeff. The kind of log is not very imporant as it is used in a more general computation which can be modified if needed. So using log2 is probably a good idea (no coeff for the exponent) MarcArticle: 87453
"Philip Freidin" <philip@fliptronics.com> wrote: > On Sat, 23 Jul 2005 19:39:13 +0200, "Marc Battyani" <Marc.Battyani@fractalconcept.com> wrote: > >I'm looking at the fastest way to compute floating point (32bit) log and exp > >on an FPGA (Stratix II or Virtex 4). It must be faster than a 3.6GHz Xeon > >which can do that in 18.5 clock cycles on average on a 1000 float vector > >(using SSE3) > > > >So far I've found that with a few tables and floating point MUL and ADD > >blocks I should be able to do that at 160MHz on a Stratix II (not tested > >yet). It's still slower than the Xeon but at least it's close. I've looked > >at cordic at a glance, but it looks slower or bigger if totally unrolled. > > > >Any ideas or pointers on a better way to do that? > > > Some time back, a company called LogPoint was offering an > alternative to floating point arithmetic, based on logarithms, > and depended on a fairly efficient float to log conversion. > (I had discussions with them, at least 8 years ago) > I seem to remember that the LOG wizard was a guy by the name > of Lester Pickett. > > > http://www.mjourney.com/news/News_from_Greece/632.Log_Point.shtml > > unfortunately, this seems to be dead: www.logpoint.com > (as in, a place holder) > > Have a look at patent 5197024 at www.uspto.gov for all the details. Thanks, that's interesting but here I need to process IEEE754 32 bits floating points. MarcArticle: 87454
We didn't appear to agree at first, but it seems we do. I don't subscribe to "If it ain't broke, don't fix it", but to a related maxim: "If you can see trouble coming, head it off." Another sewerage example: The upstream plants, the ones where failure turns miles of scenic brook into a sewage ditch, use a then-novel treatment scheme to make super-clean effluent. The process uses partly submerged rotating disks to achieve aeration and be a substrate for active bacteria. The supports for these disks were to be bolted to both sides of the concrete trough in which the sewage flows. I saw it going in, and questioned the wisdom of bolting steel to concrete that way. Differential expansion might tend to crack the concrete. Our consulting engineers had bought the patented design and used it "out of the box". When I questioned its longevity, I was reminded that prototypes had already been operating some four years with no problem. I remembered something else, and asked, "Where are they?" They were all in southern California, where the weather is quite different from here, central New Jersey. The bolts were already set into the concrete; what to do? The original plan was bolting each end with a half-inch pad under it. We bolted one end with its pad, and left a half-inch gap with no nut on the other end. That end is supported by the bolt, but not longitudinally constrained by it. Despite out harsher winters, there has been no cracking yet. But the California installations weren't "broke", so despite all subsequent installations using my floating hangers, the old ones weren't fixed. At least one original southern California trough is now patched. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87455
Peter K. wrote: > Randy Yates wrote: > > >>6. Be patient. >> >>Waiting for a system to be properly designed will almost always be >>more efficient (time-wise) than "waterfall development," i.e., the >>type of development for impatient managers that want to see something >>almost immediately. > > > I disagree. A better model (than either big up-front design or > waterfall), in software development, is the spiral / agile model of > development. I've found this model to be excellent, especially when > the requirements change or are not fully elicited --- as they usually > are in the sorts of software I've developed (greenfield ones). > > Big up-front design can be a killer when requirements change. For some > reason, managers and customers seem to think that software can be > changed much more easily than mechanical systems... so they do. The > trick is to figure out when they're really expressing a new > requirement, or just jumping on the latest Big Thing. > > I wholeheartedly agree with your previous point of keeping this as > abstract as possible for as long as possible. This really helps the > whole design and elicitation process.... without investing huge amounts > of effort in implementing something that is not critical to success. I disagree with both of you. So there! (Disagreeing seems to be an activity that I do very well.) I could have written that you're both right. There are lots of models, and some people do better with one than with another. When the planning is up to you, but your boss picks the model, it's time to circulate your resume. I have never found a model that works for me that I can explain. My most productive mode is sitting with my feet on the desk and my eyes closed for a long time, consult a data sheet on occasion, and after a day or so of seeming inactivity, write down a plan. At meetings, I can't be that thorough, so I would usually listen at least half way through, longer if politics allowed (the thought just happens), and the opine, "I would go about it this way ....") I used to get called to participate in planning meetings for projects we all knew I would have no further association with. My advice was often followed, and sometimes backed up to. That's not to brag (but I acknowledge the form!), but to illustrate that my amorphous approach worked for at least one person -- me. I think it's good to know several planning paradigms, and to choose one that fits one's own style, and perhaps the project. As usual, the best way is acknowledging that there is no best way. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87456
Jerry Avins skrev: > There are lots of models, and some people do better with one than > with another. When the planning is up to you, but your boss picks the > model, it's time to circulate your resume. Most certainly agreed. > I have never found a model that works for me that I can explain. My most > productive mode is sitting with my feet on the desk and my eyes closed > for a long time, consult a data sheet on occasion, and after a day or so > of seeming inactivity, write down a plan. Whoa, you are fast! I used to spend weeks in that mode. I am sure I would be the worst employer any "ambitious" boss could have, drinking coffe, reading papers and chatting with co-workers for days on end. No apparent activity, but if left alone (no bosses wanted to see "progress"), I always delivered on time and according to spec. > At meetings, I can't be that > thorough, so I would usually listen at least half way through, longer if > politics allowed (the thought just happens), and the opine, "I would go > about it this way ....") I used to get called to participate in planning > meetings for projects we all knew I would have no further association > with. My advice was often followed, and sometimes backed up to. That's > not to brag (but I acknowledge the form!), but to illustrate that my > amorphous approach worked for at least one person -- me. >From my experience, the truly amazing aspect in your story is that you were allowed to go on in this way, and that others acted constructively on you suggestions. This is the stage where the "fast trackers" usually find they need to make their mark on a project, and then do. > I think it's good to know several planning paradigms, and to choose one > that fits one's own style, and perhaps the project. As usual, the best > way is acknowledging that there is no best way. RuneArticle: 87457
Rune Allnor skrev: > Jerry Avins skrev: > > There are lots of models, and some people do better with one than > > with another. When the planning is up to you, but your boss picks the > > model, it's time to circulate your resume. > > Most certainly agreed. > > > I have never found a model that works for me that I can explain. My most > > productive mode is sitting with my feet on the desk and my eyes closed > > for a long time, consult a data sheet on occasion, and after a day or so > > of seeming inactivity, write down a plan. > > Whoa, you are fast! I used to spend weeks in that mode. I am sure I > would be the worst employer Make that "emplyee" Rune > any "ambitious" boss could have, drinking > coffe, reading papers and chatting with co-workers for days on end. > > No apparent activity, but if left alone (no bosses wanted to see > "progress"), I always delivered on time and according to spec.Article: 87458
Rune Allnor skrev: > Rune Allnor skrev: > > Jerry Avins skrev: > > > There are lots of models, and some people do better with one than > > > with another. When the planning is up to you, but your boss picks the > > > model, it's time to circulate your resume. > > > > Most certainly agreed. > > > > > I have never found a model that works for me that I can explain. My most > > > productive mode is sitting with my feet on the desk and my eyes closed > > > for a long time, consult a data sheet on occasion, and after a day or so > > > of seeming inactivity, write down a plan. > > > > Whoa, you are fast! I used to spend weeks in that mode. I am sure I > > would be the worst employer > > Make that "emplyee" Or better still, "employee"... Rune > > any "ambitious" boss could have, drinking > > coffe, reading papers and chatting with co-workers for days on end. > > > > No apparent activity, but if left alone (no bosses wanted to see > > "progress"), I always delivered on time and according to spec.Article: 87459
I run into a problem when I 'make;make install' the linuxdrivers.tgz file from Xilinx. Any solutions? I've read about 2.6.x updates and such, but I have a 2.4.x kernel.Article: 87460
Rune Allnor wrote: ... > From my experience, the truly amazing aspect in your story is that > you were allowed to go on in this way, and that others acted > constructively on you suggestions. This is the stage where the > "fast trackers" usually find they need to make their mark on a > project, and then do. RCA Labs was a truly amazing place to work. In the midst of a research lab, I was a "consultant" whose contribution was making things work. My reputation was better than I deserved, but it (and three Outstanding Achievement Awards) gave me the freedom to act rationally. One of my suggestions, on controlling a machine vital to a high-priority project was turned town to my dismay. I wanted to use existing hardware (of my design, based on a Z-80) programmed in Forth. The project leader "knew" that success required a much faster machine (12 MHz 8086) programmed in C. He used Intel boards. I couldn't let personality issues sink the project, and I had the freedom to do it my way on my own. He had a team of three programmers who worked on the code for 5 weeks while the electrical interface was being built to the various sensors, switches, air valves, and transport motors. I had the drawings for that and the specs for some of what the controller had to do. (I had, on request, designed some of the algorithms. That's another funny story.) I wrote the code to do the job. The drivers for digital I/O were part of my design for the controller, completed long since. After a time, the design specs were changed (a flaw had been found) and I updated my code. Even after the update, I had only about ten days invested in programming AND TESTING. What happened when they first married computer to room-sized machine was a loud BANG as every relay and air cylinder was simultaneously actuated. Mercifully, a motor tried to run both clockwise and counterclockwise and blew the breaker. Still, some pushrods bent, and a few other pieces needed to be replaced. You see, the system had been designed by programmers, who naturally assumed that high must mean ON, and low must mean OFF. Hardware engineers design circuits to be active low, because I/O pins default to inputs on reset and remain high until programmed as outputs and then set low. Back to the drawing board! They changed the code, but I didn't have to. I had written it properly from the start and had a tech build a bank of inverters to match their wiring. Now I could discard the inverter board. After two more weeks of testing and recompiling after the repairs, it became clear that they wouldn't meet the deadline. I was asked to pitch in and assist. I unplugged their controller and plugged in mine. It worked right off, proving once again that a 4-MHz Z-80 is fast enough for almost anything that moves, and that knowing every bit of the code, including the compiler and the monitor ROM is a great help in avoiding mistakes and finding them when they happen. Three programmers working seven weeks didn't manage what I had done on my own in less than two. I'm not a fast programmer; I never was. I had several advantages, though. First, I had no one to argue with me about how to do it. (It's easy to reach a consensus alone. :-)) Second, I had experience writing software to do I/O to control hardware. I had even built an effective system to do that, and I used it for the project. The device drivers for it were bug free long before the project began. Third, I wrote in Forth, which let me test each code function -- rarely more than two lines -- as it was written, so that only correct functions were incorporated into subsequent code. Anyhow, my point is that the Labs gave me the freedom to do things like that, and succeeding at them earned me the freedom to do even more. Very few engineers ever enjoy the luck that I had. I feel especially blessed. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87461
Rune Allnor wrote: ... > Make that "emplyee" My boss once said that I was useless most of the time, but that once a month or so, I earned double a month's pay. I could never figure out why my raises weren't bigger. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87462
Jerry Avins skrev: [... great story snipped ...] > Three programmers working seven weeks didn't manage what I had done on > my own in less than two. I'm not a fast programmer; I never was. I had > several advantages, though. First, I had no one to argue with me about > how to do it. (It's easy to reach a consensus alone. :-)) Second, I had > experience writing software to do I/O to control hardware. I had even > built an effective system to do that, and I used it for the project. The > device drivers for it were bug free long before the project began. > Third, I wrote in Forth, which let me test each code function -- rarely > more than two lines -- as it was written, so that only correct functions > were incorporated into subsequent code. You forgot your forth, and probably decisive, advantage: You knew all aspects of the task. I commented on it in my first post (and I think Fred hinted along the same lines in one of his early posts), that one person must be able to grasp the whole problem. You saw the potential trouble spots beforehand and avoided them. The most efficient way to recover from a problem is to avoid the problem in the first place. You knew the hardware/software high/low conventions and so on. The other team had to discover all that. Of course, you had even more advantages in that you had designed the rest of the system, so let's say you saved a week or so of finding, reading and understanding the system spec. RuneArticle: 87463
Thanks all for your replies on this subject. -MartinArticle: 87464
Kees, you have a point, but how should we respond when our competitor runs a public web-seminar that obfuscates the issue with irrelevant hair-splitting ? Some people might even believe them... Peter AlfkeArticle: 87465
Jerry Avins <jya@ieee.org> writes: > It's easy to reach a consensus alone. Oh, man, Jerry - you can say that again! -- % Randy Yates % "The dreamer, the unwoken fool - %% Fuquay-Varina, NC % in dreams, no pain will kiss the brow..." %%% 919-577-9882 % %%%% <yates@ieee.org> % 'Eldorado Overture', *Eldorado*, ELO http://home.earthlink.net/~yatescrArticle: 87466
Peter Alfke wrote:
> Kees, you have a point, but how should we respond when our competitor
> runs a public web-seminar that obfuscates the issue with irrelevant
> hair-splitting ? Some people might even believe them...
Perhaps you should give your customers more credit for
being able to think for themselves.
-- Mike Treseler
Article: 87467Mike, We do, we do (give our customer credit to think for themselves, but we worry about those who are not our customers...). We made our point. No need to go on about it. Thanks for listening, and taking the time to reply. AustinArticle: 87468
"Jerry Avins" <jya@ieee.org> wrote in message news:2qqdnZsKM7QXUn7fRVn-tg@rcn.net... > Fred Marshall wrote: ..................... > > The bolts were already set into the concrete; what to do? The original > plan was bolting each end with a half-inch pad under it. We bolted one end > with its pad, and left a half-inch gap with no nut on the other end. That > end is supported by the bolt, but not longitudinally constrained by it. > Despite out harsher winters, there has been no cracking yet. But the > California installations weren't "broke", so despite all subsequent > installations using my floating hangers, the old ones weren't fixed. At > least one original southern California trough is now patched. > > Jerry > -- Jerry, Well, you didn't have a working model in the context of your application. But you also didn't *prove* that cracking would occur did you? (If you did then OK - bear with me; I'm not suggesting that you didn't have a valid concern). What if it had been built for NJ and no failure occurred? And subsequently the worry came up? Should you change the implementation or not? Your example re: California is perfect! The worry was apparently sufficiently justified that taking the nuts off in California would have been the smart thing to do. A lot depends on the change that's contemplated. I once had a job solving problems on a system that was in production. The idea was to solve the problem without introducing any additional parts. It was a great challenge and fun to solve the problems with that constraint. Very much like removing the nuts. Mind you, the solutions were changes - but ones that had been asked for. So, if all you had to do was remove some redundant nuts in order to make the design "better" then by all means. These notions are more guidelines than hard and fast rules. When the notions are stated in "shorthand" then maybe they sound stricter. If you *must* make a change then who could argue? We have not (thank goodness?) talked about change control - which is often more about configuration management but can also be about making the decision to change or not to change in a formalized manner. The idea about design freeze is to enable getting into production without ruining all the testing that has already been done. It's also about getting rid of the crazy "new ideas" that some folks *never* stop coming up with, and curtailing those participants who can never make a decision, so that there can be a reasonable degree of stability. It's also about not paying for the changes (risk, time and money) unless it's necessary. If you have always worked with sensible people who always made the right decisions and caused things to happen really well without a hitch then you might think others are a little crazy to suggest some structure. But, if you've worked with people who are always wanting to try the latest and greatest stuff because having fun is more important than getting out the product or if you've worked with people who can't make a decision or if you're working with people who would make an unnecessary change (because they had not weighed the cost and risk vs. the benefit - or because their assessment is different than yours) then you would see the value in some structure along those lines. Sometimes "design freeze" is used to simply get people to make up their minds, finish their work, etc. Software is *so* easy to change. How many times has someone broken the system with some little change? The software books are full of examples. Of course, many of those examples are to make a technical point. But the examples sure beg the question: "What if the change had not been made at all? Would it have mattered - i.e. would the system still have performed just fine?" That's more to the point. How many times did the change come up because the programmer thought: "Well, I just figured it might be easier to read the code if ...... " I'm pretty sure we agree on most of this.... At the core this is more about decision making. Your folks decided to not make changes in California. Were they driven to that decision because they didn't want to spend the money? Or, were they driven to that decision by blind allegiance to a "freeze" kind of rule? I'll bet it's the former and, on a comparative basis, I agree with that being the driver even if we might disagree in hindsight (or in foresight) with the decision they made. FredArticle: 87469
Hi, there I am creating a project with Spartan 3 board. and wanna add DCM into the XPS 6.2 project under menu "project- add/edit cores(dialog)" What I want is to get the clock down to clock/2. There are 3 moduls in the DCM, I am using the digital frenquency synthesizer (DFS). I added 3 ports: "clkin", "rst" as input, "clkfx" as output in the internal ports connections, didnot add anything into the external ports connections. connected the "clkin" to "sys_clk"=50mMHz of the external ports, reconnected the clock input ports of other components who HAD "sys_clk" as input to the output port "clkfx" the parameters I have c_clkfx_multiply = 1 c_clkfx_divide = 2 c_clkin_period = 40.000000 <----- which i am not sure the use of this parameters. But it did not work out. Anyone has some idea? thanksArticle: 87470
Rune, I'd rather argue about practical matters instead of definitions, so let me try it this way: > Again, "design" is about choosing what > algorithms to use, how to organize the program, getting a block > diagram representation etc. It's the intellectual effort invested > in making a program or system. In my shop, unless I have to pass an audit, the products of all these activities are mostly code. At the level you're describing, most of this code is just interfaces, comments, and glue, but it is real code that becomes part of the project. After all, it is code that really defines the algorithms that get used, and the program organization, etc. The code will be documented with block diagrams, overviews, various bits of UML, etc., in order to communicate its gestalt more clearly, but most of the work here is code. I know that a lot of process-oriented folks think that there should be a separate design phase that produces something other than code, but which is actually a lot like code. In my experience, this is a bad idea. Rather than turning much of the programming job into mere transcription, it's more efficient to write your original ideas directly in the target language. That way, your programmers can work on something more interesting, and you don't need to rely on their secretarial skills to transcribe your thoughts accurately. (Pssst. They don't *read* what you write. They just skim through it.) > "Implementation" is about getting > a software function or piece of machinery to perform a pre-determined > action. I have a bit of trouble understanding what you mean by this. If you really mean "a pre-determined action", then I know there are places where programmers actually have jobs like this, but I swear that my shop will never be one of them. Have you seen "Metropolis?" If you just mean "fulfill some defined purpose", then you can see why I think that this is the same task as above, but on a smaller scale. The product of this activity is also code. It's just more isolated code that isn't reflected throughout the system like the overall architectural components are. The processes used for creating all this code, and the purpose of all this code, is essentially the same. In all cases, the coder is defining the structure and operation of software. I know you may not agree with my way of thinking about this, so to see who is more practically correct, perhaps we should see if we can find some sort of phase transition near the middle of the software development process that would justify your assignment of different labels to the pre-transition and post-transition phases: - Is there a point near the middle of development where schedules suddenly become firm? In my experience, no, there usually isn't. Certainty increases gradually and continually during development. - Is there a point near the middle of development where feasibility suddenly becomes proven? I have found that doubts about feasibility can only be quelled by real implementations. It is a good idea to implement these questionable parts of a project early, but because these aren't usually isolated or architectural parts of the project, you can't just do them all first. - Is there a point near the middle of development when you can validate all of your preceding assumptions with the customer? Again, in my experience, there is not. If customers could look at a project in progress and really determine whether or not it meets their needs, they wouldn't need you or me. So, if you still think that there is a real, practical, division of development into design and implementation phases, then when, oh when, does it occur, and what are the practical consequences of reaching it? -- MattArticle: 87471
"steve" <bungalow_steve@yahoo.com> wrote in message news:1122179959.459049.317700@o13g2000cwo.googlegroups.com... > "A good designer should > avoid tying excessive investments of time or money to decisions which > are > likely to be undone later. " > > In other words designers have to be fortune tellers. Oh, yes, and they have to do it the same way real fortune tellers do -- by understanding their customers. -- MattArticle: 87472
Randy Yates wrote: >Jerry Avins <jya@ieee.org> writes: > > > >>It's easy to reach a consensus alone. >> >> > >Oh, man, Jerry - you can say that again! > > Oh what bliss. A man who's free of inner conflicts. I often vigorously disagree with myself - especially when my tongue is saying "eat that" while my brain is saying "now, just how many kilos did the bathroom scales show the other day?" :-) As America's great philsopher G.W. Bush so wisely said "I have opinions of my own, strong opinions, but I don't always agree with them." :-) Regards, SteveArticle: 87473
Matt Timmermans wrote: > "steve" <bungalow_steve@yahoo.com> wrote in message > news:1122179959.459049.317700@o13g2000cwo.googlegroups.com... > >>"A good designer should >>avoid tying excessive investments of time or money to decisions which >>are >>likely to be undone later. " >> >>In other words designers have to be fortune tellers. > > > Oh, yes, and they have to do it the same way real fortune tellers do -- by > understanding their customers. Yeah man! Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87474
Matt Timmermans wrote: > Rune, I'd rather argue about practical matters instead of definitions, so > let me try it this way: > > >>Again, "design" is about choosing what >>algorithms to use, how to organize the program, getting a block >>diagram representation etc. It's the intellectual effort invested >>in making a program or system. > > > In my shop, unless I have to pass an audit, the products of all these > activities are mostly code. At the level you're describing, most of this > code is just interfaces, comments, and glue, but it is real code that > becomes part of the project. After all, it is code that really defines the > algorithms that get used, and the program organization, etc. The code will > be documented with block diagrams, overviews, various bits of UML, etc., in > order to communicate its gestalt more clearly, but most of the work here is > code. > > I know that a lot of process-oriented folks think that there should be a > separate design phase that produces something other than code, but which is > actually a lot like code. In my experience, this is a bad idea. Rather > than turning much of the programming job into mere transcription, it's more > efficient to write your original ideas directly in the target language. > That way, your programmers can work on something more interesting, and you > don't need to rely on their secretarial skills to transcribe your thoughts > accurately. (Pssst. They don't *read* what you write. They just skim > through it.) > > >>"Implementation" is about getting >>a software function or piece of machinery to perform a pre-determined >>action. > > > I have a bit of trouble understanding what you mean by this. If you really > mean "a pre-determined action", then I know there are places where > programmers actually have jobs like this, but I swear that my shop will > never be one of them. Have you seen "Metropolis?" If you just mean > "fulfill some defined purpose", then you can see why I think that this is > the same task as above, but on a smaller scale. The product of this > activity is also code. It's just more isolated code that isn't reflected > throughout the system like the overall architectural components are. The > processes used for creating all this code, and the purpose of all this code, > is essentially the same. In all cases, the coder is defining the structure > and operation of software. > > I know you may not agree with my way of thinking about this, so to see who > is more practically correct, perhaps we should see if we can find some sort > of phase transition near the middle of the software development process that > would justify your assignment of different labels to the pre-transition and > post-transition phases: > > - Is there a point near the middle of development where schedules suddenly > become firm? In my experience, no, there usually isn't. Certainty > increases gradually and continually during development. > > - Is there a point near the middle of development where feasibility suddenly > becomes proven? I have found that doubts about feasibility can only be > quelled by real implementations. It is a good idea to implement these > questionable parts of a project early, but because these aren't usually > isolated or architectural parts of the project, you can't just do them all > first. > > - Is there a point near the middle of development when you can validate all > of your preceding assumptions with the customer? Again, in my experience, > there is not. If customers could look at a project in progress and really > determine whether or not it meets their needs, they wouldn't need you or me. > > So, if you still think that there is a real, practical, division of > development into design and implementation phases, then when, oh when, does > it occur, and what are the practical consequences of reaching it? Matt, Before I write code, I want to know what it's supposed to do. When it's for a client, I want to be very sure that the client knows it's supposed to do. I did programming for hire for a time, sometimes moonlighting, and for a while as part of my only professional activity. I learned from other's bad experiences before I started to insist on a set of specifications that would allow the client to prove that I didn't finish the job, and allow me to prove that I did. Some clients didn't like to be pinned down, and if I liked the job I would help to write the document. I excepted as a requirements specification a users manual that explained how to use every feature and described everything that a user would see. If it was loose, I reserved (in writing) the right to fill in the details as I thought reasonable, and to charge extra for changes. It was a good policy, allowing me to keep friendships that I would otherwise have lost. Once, it sort of backfired. A friend of a friend asked me to code a personality profile program he could use in his business. He had the algorithms and a general outline, but no details. I asked for a spec to work to, saying that a user manual would do. He said he'd get back to me when he was ready, we shook hands, and I didn't hear from him until I got a check in the mail, about a day's fee, a few months later. I phoned his office about the mistake and asked if I should return the check or tear it up. He phoned back about an hour later and told me that I had more than earned it. He confessed that he had been frightened to put specs on paper because they might not be reasonable to meet. So every time he wrote a coherent subsection of the manual he coded it in BASIC to see if it was workable. Most of the time it was, and when it wasn't -- GWBASIC is not a good language for graphics -- he changed the manual. By the time he had the specification, he had a working program. The check was for teaching him how to get it right. I cashed it happily despite knowing that I had talked myself out of a job. The design part consists of deciding what the used will see and what he must to. Coding comes after. Design can be a chapter at a time, or the whole manual, but at every point along the way, you need a direction. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z