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 Underwood wrote: > 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." :-) Hey there! I said a consensus is easy to reach, not that every decision is easy. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87476
GMM50 wrote:
>Also check out CORDIC algorithms.
>
>Goerge
>
>
>
Actually, CORDIC is not as efficient as other iterative algorithms for
log, although it is a good start and does provide the benefit of
arbitrary precision.
--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930 Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com
"They that give up essential liberty to obtain a little
temporary safety deserve neither liberty nor safety."
-Benjamin Franklin, 1759
Article: 87477If you use EDK then I would suggest updating as a lot of improvements in the cores, software debugging, GCC and OS support have been introduced among other things. If it is just ISE, then I think what the other respondents said matches my position. Robin Martin wrote: > Thanks all for your replies on this subject. > > -MartinArticle: 87478
On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com> wrote: >a prototype can quickly confirm the robustness of a design Does this imply that the best way to find bugs is to test a prototype? That's the Bill Gates methodology. JohnArticle: 87479
Can anybody help me to run full strip simualtion on my excalibur epxa4-1020(embeded arm 9 device) ? . i followed the instructions on altera manuals, but i still can't see correct disassembly log. Note that Altera support is not responding on excalibur related issues. Regards, ArieArticle: 87480
"im.de" <im.de@gmx.de> schrieb im Newsbeitrag news:1122255963.249305.307550@o13g2000cwo.googlegroups.com... > 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? > thanks > I dont think multiply = 1 is valid, the smallest is 2 so you need to use M=2 D=4 otherwise what you did looks correct, we do it same way and it works (but we use valid M and D params of course) AnttiArticle: 87481
im.de napisa³(a): > 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. Is that any special needs to use DCM? If I were You I would use just flip-flop. It'll be faster for lock - instant, and 50%-50% low-high. If you must use DCM, make it like Antti Lukats wrote. Best regards Jerzy GburArticle: 87482
On 24 Jul 2005 15:46:55 -0700, "Peter Alfke" <peter@xilinx.com> wrote: >Kees, you have a point, but how should we respond in kind, ie. run your own public web-seminar and rebut their claims in a professional way instead of acting like 6 year olds saying "you're stupid; no, you're stupid" > when our competitor >runs a public web-seminar that obfuscates the issue with irrelevant >hair-splitting ? that's called marketing and at times xilinx is pretty good at it too :-) > Some people might even believe them... that's the cost of living in a democracy :-) people believe all kinds of things. some even believe that iraq was behind 9/11 and wmd were found there.Article: 87483
> >As opposed to, say, thinking it through carefully and getting it right > >the first time? > > > >John > > > > > If you can think something through carefully and get it right first > time, without experimentation, you are either: > > a) a genius who would make Newton look like a moron, or > > b) doing something pretty trivial. > > Regards, > Steve If you design a complex 10s Mgates system-on-chips where each of the 10s masks costs 100k$ and where each design iteration is many months long, you'll be killed if you come w/ your experimentation approach. I don't think it's trivial ; so I'll try to compete w/ Newton w/ my small capabilities. Why not carefully think about your implementation of the requested features? Select the appropriate architecture from the very beginning (and regarding the penalty if you didn't choose the right architecture from the beginning, you should better carefully look at the features you're looking for and in which direction they can develop), identify the main technical risks and concentrate on a way to be sure that the architectural choices + the main functions will be validated during the first iteration and that all the debug functions are in place to identify most of the bugs. W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL productivity has only slightly improved while in the mean time the FPGA/ASIC density has drastically increased. HW is not SW. Any design/experiment/update approach only leads to loss of time (and therefore $).Article: 87484
Paul Leventis schrieb: >>Anyway, the truth is something that will not be talked about on here. >>[snip - discussion on area of ALM vs. alternatives] > > > This is a good observation and is the heart of the logic architect's > design problem. In designing Stratix II, we experimented with numerous > Logic Element designs; each was evaluated on the "silicon area per > logic function" metric. We are claiming that you need 1.3 Slices to > implement the same functionality as an ALM (on average). Provided the > ALM is no more than 1.3X bigger than a Slice, then the "silicon area > per logic function" is better off for the ALM. That is an oversimplification. You can hardly beat the silicon area per logic function of nand gates (for combinational logic). Motorola had an FPGA family based on that approach but it failed. Most transistor area in an FPGA is used for routing switches so it is more important how the logic block influences the routing requirements than what the area of the logic block is. Therefore if in doubt one should opt for the larger LUTs. Acadmic results of the nineties suggest LUTs should have between 3 and 4 inputs. So most vendors went for 4-luts for above reasos. Academic results also suggest that it is better to have starved routing, e.g. not have all LUTs routable for most designs. But that is the academic truth. Then there comes marketing. For example Intel decided to build an architecture that optimizes MHz instead of performance because they sold CPUs with "True MHz". First Xilinx and later Altera decided to build FPGAs with less than optimal cost effectiveness that are 100% routable in most cases because customers kept complaining that they could use only 80% of the devices. Now they instead have devices that cost 25% more but can be copmletely utilized. Those are easier to sell. No matter what the true benefit of the new architecture is, my guess is that "more LUTs" is easier to sell than "better LUTs", so Xilinx made the better marketing choice in this case. Kolja SulimmaArticle: 87485
Eric DELAGE wrote: >>>As opposed to, say, thinking it through carefully and getting it right >>>the first time? >>> >>>John >>> >>> >>> >>> >>If you can think something through carefully and get it right first >>time, without experimentation, you are either: >> >>a) a genius who would make Newton look like a moron, or >> >>b) doing something pretty trivial. >> >>Regards, >>Steve >> >> > >If you design a complex 10s Mgates system-on-chips where each of the >10s masks costs 100k$ and where each design iteration is many months >long, you'll be killed if you come w/ your experimentation approach. I >don't think it's trivial ; so I'll try to compete w/ Newton w/ my >small capabilities. > >Why not carefully think about your implementation of the requested >features? Select the appropriate architecture from the very beginning >(and regarding the penalty if you didn't choose the right architecture >from the beginning, you should better carefully look at the features >you're looking for and in which direction they can develop), identify >the main technical risks and concentrate on a way to be sure that the >architectural choices + the main functions will be validated during >the first iteration and that all the debug functions are in place to >identify most of the bugs. > >W/ Mgates FPGA and ASIC, HW stuff is no longer trivial. The HDL >productivity has only slightly improved while in the mean time the >FPGA/ASIC density has drastically increased. HW is not SW. Any >design/experiment/update approach only leads to loss of time (and >therefore $). > > So, you don't produce any models of the modules in your chips? You don't use any simulators to debug each modelled element of the design? You don't try to simulate the entire thing to the extent the available tools will permit? I think perhaps you do. Clue: those models are prototypes, and those simulators are where you experiment with them. I really really doubt you'll get a big design right without using them effectively. Even if you can get the logic right at the first attempt, your timing constraints must be pretty loose if you don't need to try some experiments with simulators to check the critical paths are going to play nicely. Chips tend to have clearer requirements than complete systems. Few complete systems of any complexity are implemented without changes in the requirements along the way. Attempts to resist such changes just increase the likelihood of the system being already obsolete, or just inappropriate, on completion. Experimental systems (either physical or simulations) available early are a powerful way to get the end users to really figure out what they want. Specification by simulation is the only way I've ever seen a spec produced that survived the implementation phase intact. It is still a strategy too rarely used, even though it was producing excellent results 20 years ago. You write like you have a chip on your shoulder (pun partially intended) about software vs hardware work. You seem to assume I was writing from a software developer's point of view. If so, you were wrong. Most software developers generally don't have to worry too much about this stuff. With so many embedded systems now using flash, most software is fairly fluid even after the ship date. :-) Regards, SteveArticle: 87486
On a sunny day (Mon, 25 Jul 2005 10:23:45 +0800) it happened Steve Underwood <steveu@dis.org> wrote in <dc1ifi$cs2$1@home.itg.ti.com>: >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 You mean THIS philosopher: ftp://panteltje.com/Bush_a_man_without_vision.jpg ?Article: 87487
I think we should point out that Xilinx-marketing started this whole "mine
is bigger"-competition:
http://www.xilinx.com/prs_rls/silicon_vir/0551_lx200.htm
This is all somehow similar to the PC-CPU-market: Pentium 4s needs much
higher clock-rates to achieve the same performance as an Athlon64. When
advertising clock-rates this looked bad for AMD. So they introduced
model-numbers ("Pentium rating") to show the real speed-relation-ship. This
leaded to a lot of discussions ("real MHz") in the beginning, until it
turned out that the Pentium-rating was pretty fair.
Things are similar here: Altera has a logic-cell that allows for more logic
to be implemented per ALUT then in a LUT of Xilinx. To make things
comparable, Altera had to make a "Xilinx-rating" (of +30%, which looks a lot
to me...). However, Xilinx-marketing was more clever then Intel, they had
already their own "Xilinx-rating", which is +12.5% for very questionable
reasons. So there were already discussions that you should compare
real-numbers with real-numbers or marketing-numbers with marketing-numbers.
In both cases, of course, Altera will look worse then they are.
Please note that in above press-release Xilinx talkes of 200.448
logic-elements (for me this is a LUT + FF), while the device has only
178.176. I think THIS is really misleading. Altera is talking of "equivalent
LEs" in similar realeases
(http://www.altera.com/corporate/news_room/releases/products/nr-ep2s180_shipping.html)
which is much more correct.
BTW, I think LEs are counting in the first place in a FPGA. Memories,
DSP-blocks, etc. are also important, but what does their 500MHz help you,
when the logic-array can not (or only with huge effort) match their
performance?
Thomas
"Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag
news:1122175935.026219.269290@o13g2000cwo.googlegroups.com...
> Austin gave an interesting analogy:
>
> I can visualize Altera Marketing trying to put a ring in designers'
> noses, and (mis)leading them so that they can see nothing else but
> LUTs, oblivious to all the more exciting aspects of FPGAs.
>
> We could then call them LUTites, in memory of the Luddites in 1812
> Nottingham, who also did not appreciate the technological progress
> coming at them, destined to really change their lives. Many suspected
> Luddites were convicted, imprisoned, or hanged. Those were the days...
>
> But don't get us wrong:
> We love LUTs. Xilinx invented the concept of LUT-based FPGAs. LUTs are
> great and flexible, whether they have 4, 5, or 6 inputs. But LUTs are
> not everything anymore, and the really exciting progress in FPGA
> performance and density happens outside the LUTs.
>
> Don't let anybody put a ring in your nose...
> Peter Alfke, Xilinx Applications (from home)
>
Article: 87488But if I use a two stage FF synchronizer for NXT_raw and my answer byte to NXT_Q is also synchronous that is registered I would be one 120MHz clock cycle too late (?) Rgds Andr=E9Article: 87489
Jedi wrote: > Moro > > Back from a successful trip in .ch I have to change > my contact details at Altera and they provide > an email address for doing this: > > csecom@altera.com > > which just leads into nirvana and bounces back > with "user unknown"... > > Any other address to use? Or why is it not allowed to > change address online? I guess nobody at Altera discovered this or don't care? rickArticle: 87490
"Jedi" <me@aol.com> schrieb im Newsbeitrag news:i74Fe.125$Sg3.58@read3.inet.fi... > Jedi wrote: > > Moro > > > > Back from a successful trip in .ch I have to change > > my contact details at Altera and they provide > > an email address for doing this: > > > > csecom@altera.com > > > > which just leads into nirvana and bounces back > > with "user unknown"... > > > > Any other address to use? Or why is it not allowed to > > change address online? > > I guess nobody at Altera discovered this or don't care? > > > rick they dont careArticle: 87491
Matt Timmermans skrev: > 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. OK. No problems here. > 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. I know what you mean, although I don't have enough experience to actually fill in. My experience are with projects taking one or to people to code (the "one" being me) where somebody have some expectations to the program. I don't know how you think of it, but I prefer to spend a lot of the time talking with the customer so I know what he expects, and prehaps reaches an agreement on how to do things. When I know the "big picture", I may be able to prepare an extension later on, in a follow-up project, even if we are talking merely basic stuff at the first delivery. > 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's usually why projects blow up, in my experience... the first, "naive" thoughts may have some essnce of usefulness in them, but usually I have to start over from scratch pretty soon, if I start out that way. > 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.) What is wrong with having the programmers chime in when discussing the overall project? Not necessarily with the customers, but at least in-house? With a bit of luck, they come up with some good ideas, and it might perhaps even generate a bit of interest with them. > > "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. I mean that once you sit down to actually write the code, you should be very clear about what that code is supposed to do. I did not say that somebody *else* than yourself/the coder should come up with the plan, but the plan ought to be clear beforehand. > 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. I haven't seen metropolis, but I get the general idea. I don't have much sympathy for that kind of places. > 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 am not sure we disagree, but I think we have slightly different experiences and because of that, different ways of working. > 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. Sure. I still like to spend as much time as possible in the early phases, to try and get as much as "the big picture" as possible. Seeing the likely post-project extensions is an advantage, it may pay off to provide certain hooks and labels early on, that would otherwise require an extensive re-working. > - 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. Agreed. However, in my book that's R&D-type projects that must be treated somewhat differently. At least, the "real" project should pe preceeded by some sort of feasability study, or a termination clause should be included in the contract if such questions are known beforehand. > - 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. I have been involved in projects where that actually happened. True, not software projects, but data analysis pojects. The customer had an idea about how to make a measurement, but they did not know how to actually go through with it. From the customer's point of view, this was an R&D project. As far as I was concerned, there was no R&D involved, only using tried and tested techniques in a new setting. As we went through the project, there were frequent dicussions about "can we replicate the analysis results from the lab in a real-life setting? Can we get the equipment to survive a real-life setting? Can we train production staff to handle the equipment? Can we train analysts to include the data in their analysis?" If the answer to any of these questions was "no", the project was a "waste" of time and money, the equipment would not reach its intended production stage. But we didn't know the answers until we tried. The customer knew all the constraints, I knew what the equipment needed to do. Sometimes we could sacrifice some "convenient" gadget in the analysis, others had to stay or the measuring device would not work. Sometimes we we could change or adjust the existing operation process, other times what we contemplated was a threat to the equpment we tried to make more reliable and efficient. It was a really interesting project. > 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? If you understand me such that I split "design" and "implementation" into very separate phases, in time and perhaps even people, I have expressed myself poorly. I am thinking of "design" in terms of selecting algorithms, organization the activity/program and, well, think the task through before taking any actions. It's the antithesis to the "make code now!" approach I have very poor experiences with. There are usually several ways to get something done, one is usually more favourable than others. This may depend on the actual circumstances of the project. "Design" is about analysing the problem and selecting how to do things. It could be all those talks with the customer before the project actually takes place, or it could be the coder deciding whether to implement some function as a recursive call or some nested loop. Either one might get the job done right now, but "the big picture" might suggest that some task or extension becomes easier in the future, should particular method be chosen over the other. RuneArticle: 87492
On Thu, 21 Jul 2005 21:32:24 +0000, Martin wrote: > Using 6.1.03i. Pondering whether or not to spend the money to update to > latest revision. The devices we are using are fully supported by what we > currently have. No real issues at all. > > That being the case, what would be the most significant reasons that would > justify an upgrade today? > > Thanks, > > -Martin Unless you are using a device that isn't supported by the 6.2SP3 you should wait for the 8.1 series which hopefully will be better then 7.1. The 7.1 series has been much buggier then usual. The latest service pack seems to have cleared up a lot of the bugs but the performance of 7.1SP3 is still worse then 6.2SP3. Map takes forever on 7.1 and the ultimate results are generally worse then for 6.2SP3.Article: 87493
"arie" <aries@wisair.com> schrieb im Newsbeitrag news:1122271766.745637.98620@g14g2000cwa.googlegroups.com... > > Can anybody help me to run full strip simualtion on my excalibur > epxa4-1020(embeded arm 9 device) ? . > i followed the instructions on altera manuals, but i still can't see > correct disassembly log. > > Note that Altera support is not responding on excalibur related issues. > > > Regards, > Arie > Excalibur is DEAD. dont use it. AnttiArticle: 87494
Jerry Avins wrote: > 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. Ya. That's the truth. > 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. That's great if you have the freedom to do it. I've never had that amount of freedom. There's nearly always been someone breathing down my neck wanting to me to communicate what's happening now, why it's happening, when the next thing is happening. For me, the big up-front approach has never given me the ammunition to resolve those issues... it takes to long to "show" anything... and then, when you do have something to show, it comes all at once, so the neck-breathers ask "Why didn't you do that six months ago?!?!?!". The "trickle" approaches have allowed me time to set expectations (things happen, early on, but not necessarily at a blinding pace, but they keep happening). > 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. :-) Definitely good advice. I just like arguing. :-) Ciao, Peter K.Article: 87495
Jerry Avins wrote: > 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. You should! Great story, Jerry. :-) Ciao, Peter K.Article: 87496
On Sun, 24 Jul 2005 22:31:38 -0700, John Larkin <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote: >On 22 Jul 2005 06:01:19 -0700, "steve" <bungalow_steve@yahoo.com> >wrote: > > >>a prototype can quickly confirm the robustness of a design > >Does this imply that the best way to find bugs is to test a prototype? > >That's the Bill Gates methodology. The Bill Gates methodology is to get someone else to pay you for the privilege of testing your prototype. Bob Perlman Cambrian Design WorksArticle: 87497
Or you can use just DLL part of DCM that will give you a fixed divided output clock @ 1/2 ofinput clock. -JamesArticle: 87498
"Vladislav Muravin" <muravinv@advantech.ca> schrieb im Newsbeitrag news:bccEe.10218$je2.1076206@news20.bellglobal.com... > What is blif format? > You are probably talking about synthesis tool, aren't you? > > Vladislav > > > "junaid" <k.najeeb@gmail.com> wrote in message > news:1122026304.657790.4750@g14g2000cwa.googlegroups.com... > > Hi All, > > > > Can anyone suggest a method to convert verilog file into blif (LUT) > > format. Does altera or xilinx support this file conversion ?. Kindly > > help me in this regard > > > > Thanking you in advance > > BLIF - Berkeley Logic Interchange File some Lattice tools produce and use BLIF as example there is blif to vhdl tool within lattice toolchain AnttiArticle: 87499
Rune Allnor wrote:
...
> through before taking any actions. It's the antithesis to the "make
> code now!" approach I have very poor experiences with.
>
> There are usually several ways to get something done, one is usually
> more favourable than others. This may depend on the actual
> circumstances
> of the project. "Design" is about analysing the problem and selecting
> how to do things. It could be all those talks with the customer before
> the project actually takes place, or it could be the coder deciding
> whether to implement some function as a recursive call or some nested
> loop.
> Either one might get the job done right now, but "the big picture"
> might
> suggest that some task or extension becomes easier in the future,
> should particular method be chosen over the other.
I've thrown out a lot of early code because it led to unfortunate data
structures or module interfaces. I'm not prescient enough to get those
right most of the time on unfamiliar ground, and I know it. My approach
is to write a quickie that covers most of the ground, try to use it, and
learn a better way from it. It would be a waste to give it more features
that what's needed for a shakedown, then I chuck it and start over. Many
programmers I admire work that way.*
Sometimes, I just do that in my head. I've actually debugged assembly
code by single-stepping it in my head as I drove home from work. I
suppose I should have been elated at finding my bug, but it made me feel
pretty stupid.
Throwing code away can be depressing if it was originally intended to be
kept, but making it part of the planning process takes the sting out.
Has there ever been a completed project that couldn't be improved by
another go-round? A quickie prototype can capture most of the benefit of
a second chance.
Jerry
_________________________________
* If the boss will insist that you flesh it out and keep it, do it in
secret. At home on your own time if need be.
--
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