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
Although I've never tried this myself, I suspect the easiest route will be to produce an EDIF file (an industry standard design format) from whichever synthesis tool you prefer to use, and then convert that to BLIF. A quick google lead me to this tool: http://www.eecg.toronto.edu/~jayar/software/edif2blif/edif2blif.html junaid wrote: > 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 advanceArticle: 87501
I think that the problem is in multiply settings, as the minimum value of M is 2. But did not you get a warning in the synthesis about this? Vladislav "im.de" <im.de@gmx.de> wrote in message 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 >Article: 87502
So, Andre... What's up? How are things going? Are you successful so far? V <ALuPin@web.de> wrote in message news:1122288612.740510.231080@g14g2000cwa.googlegroups.com... But 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éArticle: 87503
Fred Marshall wrote: > "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). Most large structures have expansion joints or are carefully designed not to need them. I considered the lack of them in the aerator supports do be a design oversight and our consulting engineers agreed. > 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. Not every design flaw jumps up and bites. Carelessness doesn't always exact a price. (If it did, most of us would be sorely beaten.) Recall that we used a turnkey design. Our engineers adapted it to the soil conditions and supervised construction, but they didn't design it. The California plants were the responsibility of other owners. The design owner modified the plans that applied to new installations. Where we slipped pipe over the bolts (kept in place by a nut on the bit of thread that protruded) and enlarged the bolt holes, new installations used smooth instead of threaded anchor rods. I do not know the weather conditions before the California crack, but I was told that the damage saw not from an earthquake. > 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. Removing the nuts allows the steel to contract. One must remove the pad between the steel and the concrete to allow the steel to expand. That's difficult without disassembling the aerator. ... > I'm pretty sure we agree on most of this.... Yes. > At the core this is more about decision making. Your folks decided to not > make changes in California. See above. They weren't my folks. I don't know what the patent holder recommended, nor the process use for deciding by the several California owners. > 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? "Freeze" is a bad word in the sewerage business. Requirements change as effluent limits are changed by government and communities grow. Our plant's sludge incineration system was designed when oil was cheap. The presses that separate sludge from water were inefficient but rugged and simple. The high water content of the "dried" sludge made continuous oil or natural-gas firing necessary to get the poor bugs to burn. (Have you ever held a handful of live bacteria? That's what sludge is.) Oil was expensive by the time the plant when into operation. Within a few years, we replaced the belt presses with more effective vacuum presses at no small cost. (An energy-conservation grant helped.) The sludge now burns on its own once the incinerators are up to temperature, but the presses stank up the whole operations building. So we rebuilt the air handling system, including scrubbers for the exhaust air so as not to gross out the neighbors. Then we ... It never ends. Although I'm no longer a commissioner, I'm still officially involved, mostly with odor control. The plant seems to be as much alive as the bacteria that make it work. > 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. Jerry -- Engineering is the art of making what you want from things you can get. ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻArticle: 87504
SantaBarbara350Z@gmail.com writes: > 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. > What exactly is the problem - you haven;t givn us much to go on! Martin -- martin.j.thompson@trw.com TRW Conekt, Solihull, UK http://www.trw.com/conektArticle: 87505
All good advice: Use the CLKDV output with DV=2 (divide by 2) That is using the DLL part of the DCM, and it will have less jitter than using the CLKFX output with M=2, D=4 (M=1 is not a valid choice). If you use the CLKFX to do this, be aware that the min frequency now applies to the output (CLKFX must be greater than 24 MHz, or whatever the min freq spec is for the part). AustinArticle: 87506
Hello everybody, I use FPGA Advantage 6.2 and ISE Xilinx 7.1. Is there some tool that allows for the verification of the content of a block RAM (RAMB4_x_y) at simulation time, but without having to increase step by step the address and monitoring the output DOA? That is some graphical interface that give a view of a selected RAM cell Thanks GioArticle: 87507
The Design can (and shoule) also tell you things that the code doesn't - like the relationship between functions, the flow of data, etc. -- --------------------------------------------------------------------- DataGet & PocketLog www.dataget.com Data Collectors www.baxcode.com -------------------------------------------------------------------- "Jerry Avins" <jya@ieee.org> wrote in message news:8OOdnYevi6v6_3nfRVn-jw@rcn.net... > Matt Timmermans wrote: > > > > > > 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. > > 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. >Article: 87508
I see the Design as a "paper prototype". It's to test the design and see if the design is coherent. Looking for bugs comes at the code level. -- --------------------------------------------------------------------- DataGet & PocketLog www.dataget.com Data Collectors www.baxcode.com -------------------------------------------------------------------- "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:76u8e1t7eunkn4ml5ckoo0timribme9tgh@4ax.com... > 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. >Article: 87509
On Mon, 25 Jul 2005 13:16:34 GMT, Bob Perlman <bobsrefusebin@hotmail.com> wrote: >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. > And to get rich off of selling failure. Few of us have that option. JohnArticle: 87510
Know the design priorities. This means understanding the most critical requirements. Understand that all designs are trade-offs between conflicting requirements and all but one solution are sub-optimal given the solution space. No matter what design technique you use, including all diagramming and emergent design processes, this is true. You are not likely to find the optimal solution. Depending on the end purpose, and if it truly is highly complex, multiple design teams are a good idea. They'll have landed upon differing sub-optimal solutions. Comparing and reconciling the competing designs can lead to a better sub-optimal solution. Make sure you fully understand the problem. Break down the problem into sub problems. This is easiest for me to do in a hierarchical fashion, but is not the only way. There are many good, non-software engineering books that talk about problems solving and present diagraming techniques. If you are serious about design, you should read a few of these and even play with other diagramming techniques (though don't necessarily try to impose these non-SE diagrams on the corporation!). The design does not have to be hierachical, and the implementation probably should not be. Prototype the difficult problems. Support the design with tests (test before code!). Walk through designs. Absolutely! Know that requirements change.Article: 87511
Hi Vladislav, I am waiting for the new board release. When I can test it I will give account. Rgds Andr=E9Article: 87512
Are you using Modelsim ? Rgds Andr=E9Article: 87513
Antti Lukats wrote: >Excalibur is DEAD. >dont use it. I recently had a discussion with a manager at a large company that wanted to build a system based on an ARM. This manager was thinking about Excalibur until finding out it was not recommended for new designs, and that there wasn't a replacement. He had one question I couldn't answer: Why? ARM seems to be very popular. An ARM in an ram-based FPGA with enough gates to make the interfaces required would have made a nice product. Not worth rewriting a bunch of software to fit it into a V4 with a PPC. Why did Excalibur die? -- Phil Hays Phil-hays at comcast.moc (remove moc and add net) should work for emailArticle: 87514
>... For some >reason, managers and customers seem to think that software can be >changed much more easily than mechanical systems... so they do. Do you think that software is as hard to change as mechanical systems? or is it possible that, even though software is easier to change than a mechnical system, it still requires some work and many managers/customers assume easier change = free change?Article: 87515
"Phil Hays" <Spampostmaster@comcast.net> schrieb im Newsbeitrag news:lb2ae1l5i3gj9nnbhg00cfr9eikfd3shr2@4ax.com... > Antti Lukats wrote: > > >Excalibur is DEAD. > >dont use it. > > I recently had a discussion with a manager at a large company that > wanted to build a system based on an ARM. This manager was thinking > about Excalibur until finding out it was not recommended for new > designs, and that there wasn't a replacement. > > He had one question I couldn't answer: > > Why? > > ARM seems to be very popular. An ARM in an ram-based FPGA with enough > gates to make the interfaces required would have made a nice product. > Not worth rewriting a bunch of software to fit it into a V4 with a > PPC. > > Why did Excalibur die? > > > -- > Phil Hays > Phil-hays at comcast.moc (remove moc and add net) should work for > email > you possible need to ask the lawers of ARM, and you possible do not get an answer. Actel is promising soft-core ARM licensing for their PA3 family. But there is no PA3 silicon shipping as of today. the chinese nnARM softcore nnARM core, it does synthesise ok, but its very huge :(, well at least the register array is done badly as it alone occupies 50% of Virtex-4 LX25, I havent looked if the rest of the nnARM is useable if the register bank would be optimized Antti PS the nnARM source code should be easy to locate with google if anyone has interest in it.Article: 87516
Hi All, I was wondering if somebody knows where to find exact time-to-failure data for FPGA devices. I checked the reliability data available in both Xilinx and Actel Reliability reports and they both report failure rates in FITs, from which one can calculate the MTBF. What I'm looking for is accelerated life testing data and specifically High Temeperature Operating Life (HTOL) test data expressed in exact-time-failure not in FITs as given in the reliability reports mentioned above. Well, I'm not sure if this kind of data exists in the first place, but no harm from asking:)) Thanks, AmrArticle: 87517
Amr, there is no exact time, only a statistical probability. ICs do not suffer from a clearly defined wear-out mechanism that would allow us to predict the end-of-life. There is a wide variety of factors that affect reliability, and there is the Arrhenius model that describes the dependence on temperature, but all predictions are statistical. And at "normal" temperatures, ICs live a very long life, 20 to 100 years or more. Most failures are the result of overstress, mostly in the I/O. Peter Alfke, XilinxArticle: 87518
> That is an oversimplification. > 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. Yes, you are correct. My definition of "silicon area per logic function" is for the full LAB -- this includes the LE itself, all the routing-related area, and the secondary signal (clock/enable/clear etc) goo that is shared between a group of LEs. This of course complicates the architectural experiments since you must optimize the LAB size, secondary signals, and routing fabric for each LE under evaluation. This is what we try to do. > Academic results also suggest that it is better to have starved routing, > e.g. not have all LUTs routable for most designs. Yes, but academics don't have to deal with angry customers who find out six months into their design that it won't route. In practice, we aim for something like 99% routability in a 99% full device. Even if this is (academically) wasteful, there is a cost associated with having an unroutable part. And part of the allure of FPGAs is low-risk and rapid development -- high routability is a necessary attribute to meeting these expectations. > Now they instead have devices that cost 25% more but can be copmletely > utilized. Those are easier to sell. I can assure you that 25% overstates the cost overhead for near-guarenteed routability :-) > 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. Time will tell. Yes, more things you can point at are easier to sell... especially when you inflate the count by a further 12.5%. But the ALM also got us a big speed boost relative to Virtex-4, which we're finding is pretty easy to sell too :-) Regards, Paul Leventis Altera Corp.Article: 87519
"Paul Leventis" <paul.leventis@utoronto.ca> schrieb im Newsbeitrag news:1122308095.602710.84700@g14g2000cwa.googlegroups.com... > > That is an oversimplification. > > 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. > > Yes, you are correct. My definition of "silicon area per logic > function" is for the full LAB -- this includes the LE itself, all the > routing-related area, and the secondary signal (clock/enable/clear etc) > goo that is shared between a group of LEs. This of course complicates > the architectural experiments since you must optimize the LAB size, > secondary signals, and routing fabric for each LE under evaluation. > This is what we try to do. > > > Academic results also suggest that it is better to have starved routing, > > e.g. not have all LUTs routable for most designs. > > Yes, but academics don't have to deal with angry customers who find out > six months into their design that it won't route. In practice, we aim > for something like 99% routability in a 99% full device. Even if this > is (academically) wasteful, there is a cost associated with having an > unroutable part. And part of the allure of FPGAs is low-risk and rapid > development -- high routability is a necessary attribute to meeting > these expectations. > > > Now they instead have devices that cost 25% more but can be copmletely > > utilized. Those are easier to sell. > > I can assure you that 25% overstates the cost overhead for > near-guarenteed routability :-) > > > 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. > > Time will tell. Yes, more things you can point at are easier to > sell... especially when you inflate the count by a further 12.5%. But > the ALM also got us a big speed boost relative to Virtex-4, which we're > finding is pretty easy to sell too :-) > > Regards, > > Paul Leventis > Altera Corp. > Hi Paul, do have performance data for S-II in fabric speed? I cant unfortunatly measure it myself as I dont have S-IIs around but I have measured actual in fabric clock speeds of 950MHz in lowest speed grade V4 - what would be the case in S-II lowest speed grade? Are 1GHz+ internal signals possible in the fabric? AnttiArticle: 87520
"Antti Lukats" wrote: >"Phil Hays" wrote: >> I recently had a discussion with a manager at a large company that >> wanted to build a system based on an ARM. >> Why did Excalibur die? >PS the nnARM source code should be easy to locate with google if anyone has >interest in it. Right. But large companies are not interested in attracting sharks... I mean lawyers. Also the clock rate would need to be higher than I think that a softcore processor written as a student project is likely to achieve. -- Phil Hays Phil-hays at comcast.moc (remove moc and add net) should work for emailArticle: 87521
"Phil Hays" <Spampostmaster@comcast.net> schrieb im Newsbeitrag news:gk6ae19lkccq0c5prrse7b7kqg34etu025@4ax.com... > "Antti Lukats" wrote: > > >"Phil Hays" wrote: > > >> I recently had a discussion with a manager at a large company that > >> wanted to build a system based on an ARM. > > >> Why did Excalibur die? > > >PS the nnARM source code should be easy to locate with google if anyone has > >interest in it. > > Right. But large companies are not interested in attracting sharks... > I mean lawyers. > > Also the clock rate would need to be higher than I think that a > softcore processor written as a student project is likely to achieve. > > > -- > Phil Hays > Phil-hays at comcast.moc (remove moc and add net) should work for > email yes you are right, the core would possible run at 10..20MHz I am still wondering ARM sharks did run off at those students, its not a real useable core, well the reason was possible that the core was not 100% as ARM had license some source code to china universities and those students had access to that code AnttiArticle: 87522
The simulation models for block RAMs use an array to store memory content. You can view the content of the array like you view any other variables. JimArticle: 87523
Hi Xilinx FPGA's are nice but all of them (after XC4K?) do not have any more access to the OnChipOscillator - it is not usually required also, but in some rare cases it may be useful to have some OnChip Clock available in case all external clock sources fail, or do have emergency Watchdog timer to monitor some events also in the case of external clock circuitry failures. For this purpose we are developing OnChip Oscillator IP Cores. http://gforge.openchip.org/frs/?group_id=32 Simple Spartan-3 version is available, it delivers stable 1:1 duty ratio clock what is in the range of 205-220MHz for S3 -4 speedgrade. Special versions for other Xilinx families are coming shortly. Antti PS to my surprise Lattice EC/XP and also MachXO all have access to their OnChip Oscillator, so at least in thing Xilinx FPGAs have less features available to the user.Article: 87524
Hello Everyone I am a final year student pursuing my undergraduate research project on the topic of "Evolvable Hardware". Till date I have a good amount of information on the topic. Now I want to finish up my project with an implementation of a evolvable algorithm for the design of a simple combinational circuit. I am completely clueless about where to start. It would be really great help if someone could show me the right direction. Thank you Ankit Parikh Manukau Institute of Technology Auckland,New Zealand.
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