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
Besides reiterating that our devices are tested thoroughly through our own internal test programs, I should point out that it takes a large team of engineers working for ~1 year before a chip is released to come up with the suite of tests we throw at our chips to make sure that they function. I believe this includes tests of all varieties that you mention. Even if you had the resources to develop a good suite of tests to achieve 99+% coverage of the parts of our chip your design uses, there are a huge number of configurations required to achieve this coverage. We employ special test pins and test modes to improve the throughput and reduce the data requirements for these configurations, but it still would take a hefty amount of ROM to store the configs. My guess would be that it would be cheaper to build redundant hardware (for example, use triple modular redundancy) for your design than it would be to develop and deploy a self-testing capability. The chances that you've got a fault that we didn't detect that isn't covered by your TMR circuitry would be very very small. Not that I'd have a problem with you finding a way to re-test EasyPath parts yourself ;-) Regards, Paul Leventis Altera Corp.Article: 65203
Patrick, The solution I proposed would address changes to all occurances in the FIFO. See, the FIFO only stores the address of an entry in the CAM/RAM. If the value changes, the address remains the same, just the value in the CAM/RAM gets changed. Unfortunately, Altera's CAM Megafunctions don't allow direct reading of the CAM entries by address thus necessitating the RAM. The CAM is simply used to determine whether a value has been submitted before or not. The RAM stores the same value as the CAM except you can read it out by indexing into the RAM using the FIFO output. Blake "Patrick Klacka" <pklacka@trexenterprises.com> wrote in message news:501364cc437d0c00562c49ae102caf01@news.teranews.com... > Thank you everyone for your suggestions thus far. It's clear that more > details are needed in order to better explore this problem. Please see > http://www.trexenterprises.com/~pklacka/fifo.html for implementations in C > code. > > It seems that all the solutions favor one change to a particular value, but > do not consider the case of the changed value being changed. For example, > the value of 5 is changed to 6. Now a 5 is retrieved from the fifo. We know > through the Blake's CAM implementation and Jim's SyncRAM implementation that > the value of 5 will be transformed to a 6. Now the 6 is changed to a 7. When > we retrieve a 6 from the fifo, we get a 7 as intented. But should a 5 come > off the fifo, we still get a 6, unless some sort of recursion is used. The > recursion is what I am attempting to avoid. If all the 5's in the fifo could > be changed to 6's before the 6's get changed to 7's, then I have a working > solution. > > Here is another idea that may be impossible to implement, but it might shed > some more light on what I am trying to achieve. Consider a full fifo that > expects a value to be inserted every time you remove a value. So there is a > constant flow from one side to the other. (I think this was correctly > likened to a vector shift-register) Could there be another fifo of the exact > same length that flowed in the opposite direction which contains the compare > and the change values. Each time a new value is inserted/removed from the > primary fifo, the secondary fifo compares register values at the same > location in the primary fifo, makes the appropriate change if necessary, > then shifts itself with a new value. Using this idea, all of the 5's will be > changed to 6's before the 6's get changed to 7's, but I think it uses the > same amount of resources as my original solution. > >Article: 65204
Hello Ray, Nice seeing your post. Tell me, 1) what's involved in getting the P.E. moniker and 2) do you carry product liability? Blake "Ray Andraka" <ray@andraka.com> wrote in message news:400ECC6F.CF29C15D@andraka.com... > $500/yr sounds like Commercial General Liability, which basically protects > you if a customer hurts himself on your premises. It doesn't generally > provide any coverage for your product, in other words O&E. My O&E runs > about $6000/year, and is through a different insurer than my CGL. There are > relatively few carriers that offer O&E, and you'll likely be locked out of > it for certain products like medical instruments and nuclear controls. > > Robert Sefton wrote: > > > I'm a consultant/contractor. A new customer is requiring me to carry > > commercial general liability coverage, including contractual liability > > (errors and omissions). I carried a $1M policy from Hartford for several > > years, but let it lapse in '02 after customers quit insisting on it. I > > paid $500/yr back then. Any recommendations, and what should I expect to > > pay? I'm in California. > > > > Thanks, > > > > Robert > > (real email: rsefton@nextstate.com) > > -- > --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: 65205
vbetz@altera.com (Vaughn Betz) wrote in message news:<48761f7f.0401202037.79907801@posting.google.com>... > Mike Treseler <mike.treseler@flukenetworks.com> wrote in message news:<400D7312.1090304@flukenetworks.com>... > > g. giachella wrote: > > > I have launched the place & route of the same project on two different > > > machines, a PC 2.6 GHz (WIN 2000) and a COMPAQ XEON 700 MHz > > > Workstation (WIN NT 4). Same project means same .vhd, .edf, .csf, > > > .psf, .ssf, .esf, .quartus files. > > > The QUARTUS release is the same (same build, same SP). > > > I obtained two different placements and two different compile times > > > (PC = 1h 40 min, Workstation = 5h 22 min): the file ..fit.rpt > > > evidences that the options "Use Local Routing Input" and "Use Local > > > Routing Output" were set differently between them during the > > > compilation. > > > As the project are the same and the seed is also the same, I would > > > expect identical place and route. > > > > > > Any comment ? Am I missing somenthing ? > > > > Your win2k box is faster than your nt box. > > > > Lets assume that place & route is mostly compute bound. > > In that case, if I didn't know the answer, I would > > estimate the NT test time as: > > > > (100 min) (2.6/.7) = 371 min = 6 hours > > > > > > So you are doing better than I would expect. > > > > > > -- Mike Treseler > > > The different compile time is just CPU speed differences, as Mike > explained. For the different placement and routing, I can only think > of two things: > > 1. You changed some option without realizing it between the two > compiles. Are "Use Local Routing Input" and "Use Local Routing > Output" options you set for the compiler, and you're saying they have > different values in the two fit.rpt files? If so, that indicates you > have unintentionally changed a setting between the two compiles, which > would explain the different place and route. > > 2. We have occasionally gotten different fits on different versions of > Windows due to things like qsort breaking ties differently in > different windows versions. A slight difference at one point in the > compile leads to a different fit on the two platforms. Both are valid > fits; they are just different. As we find these cases, we get rid of > them by doing things like writing our own qsort that breaks ties in a > deterministic way. > > So it's rare, but we do find these cases. > > Regards, > > Vaughn > Altera Thank you for your interest. I have launched a new compilation on a pc only and, again, the result is different from the previous launched on the same pc. I don't understand why ...Article: 65206
"Blake Henry" wrote: > what's involved in getting the P.E. moniker In the interest of accuracy (not criticism), "P.E." is not a moniker, which means "nickname". "PE" stands for "Professional Engineer". A Google search using that phrase reveals a world of information on the subject. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"Article: 65207
Hello, Peter Alfke <peter@xilinx.com> wrote: > Thomas Stanka wrote: > > Anyway, you can't do tests before selling a fpga, that replaces Bist > > for dynamic faults in the way I understood dynamic faults. Dynamic > > faults will occure sometime during lifetime of the fpga due to > > material aging or (especially in SRam based Fpgas) due to single event > > effects. [..] > Single-event upsets are soft failures, mostly caused by various > radiation types. They can only be described in statistical terms, and > they disappear once data is re-written. > This is a totally different subject... SEU are critical if they change the configuration of your device, but uncritical in static devices with proper protection (eg. ASIC with TMR). I thought more about single event effects with permanent impact on the device like wire degrading due to ESD or critical failures in your power supply (or heavy ion in radiation environment). Just the kind of error that's a bit to weak to instantly kill your device but strong enough to have an permanent influence. These failures might be very seldom, but maybe just because they are so hard to detect? bye ThomasArticle: 65208
Thank you Peter, "Peter Alfke" <peter@xilinx.com> escribió en el mensaje news:400F2439.EC57ADB0@xilinx.com... > The XC9536XL is a Flash-based CPLD. Different from an SRAM-based FPGA, > you do not reconfigure it just by cycling Vcc. The CPLD would need a > fresh in-system programming operation, which is not automatic nor > happens by accident. Yes. That part I understand. > So, what might have happened is that your design got into an illegal > state, out of which it cannot excape, but which did not affect the configuration. > This was my first thought, I double checked the state machine, and I don´t think there is a problem there. > A more far-fetched explanation is based on the fact that a small part of > the Flash-based configuration actually gets transferred into internal > latches (like in an FPGA), which of course might get upset, and that > would be fixed by cycling Vcc. This is the part I am actually concerned. Could a noisy or poorly decoupled Vcc be the source of the problems. How far-fetched explanation is this ? Is it really possible ? If I read the configuration through the JTAG port, do I get the internal-actual-RAM configuration, or the Flash configuration ? Or should I be looking for a bad solder point or other more mechanical explanation ? Josep DuranArticle: 65209
> 2. Do we have to buy a license to PCI core in order to use the board? > I mean we are not going to modify any of the PCI interface functions. > For all we care, PCI could have been implemented in a dedicated chip > on our dev boards... > > Thanks all in advance for your responses! > OK I know %$&$ all about the black arts but www.opencores .com looks like a good place for free IP cores. Back to lurking..... MikeArticle: 65210
Hi, Tarari (an Intel spin-off) has released a new FPGA-based PCI board that they feature on their site at: http://www.tarari.com/products-highperformance.html We are thinking of using it in our project and would be very interested to hear any feedback. Thanks, Valery.Article: 65211
Hi all, I am actually trying to switch a virtex2 project to spartan3. While implementing the design I got several timing errors. One reason is that the timing parameter "CLK to valid Data on Pad" (Tiockon). The data sheet of virtex2 gives a value of 3.51ns. The value for spartan3 is 5.865ns - which is much higher!!! . I got this value for spartan3 from Timing Analyzer (Vers. 6.1.03i). In the newest datasheet of the spartan3 the chapter "switching characteristics" is still quite empty. So I really wonder what the XILINX guys do. Selling a chip without timing specs? Is the spartan3 really much slower than the Virtex2? Any comments? Any Spartan3 Users?Article: 65212
"Paul Leventis \(at home\)" <paul.leventis@utoronto.ca> wrote in message news:<7gKPb.46671$lGr.8430@twister01.bloor.is.net.cable.rogers.com>... > I don't know whether 70% is the correct number or not, as it depends on many > things and on how sophisticated the timing model was for the "maximum" > numbers in the first place. But here are a few other phenomena to add to > the laundry list: [...] Interesting! Thanks for your input. This 70% figure was for Xilinx CPLDs. What would be a good estimation for Altera devices? Does Altera document tracking properties for their devices? (either 'officially' in datasheets, or in application notes). Just curious. > > But this is why FPGA companies have timing modeling and characterization > groups, and part of why FPGAs are slowly taking over the world (or so I hope > :-) -- imagine having to worry about all this stuff when doing your ASIC? I can imagine :) Guillermo RodriguezArticle: 65214
Hi, I have to modify an hold XC3042 project, developed in 1993 using XACT 4.12. Actually I have only the LCA design files, the Orcad schematics and the MCS programming file. I am searching a copy of the old tool XACT 4.12 and a way to transport this project to the XC3042A component. Anyone can help me on this? Regards Claudio TavoniArticle: 65215
Dear Mr, Why is it better to avoid the unsigned library? Is there a special reason ? Is the use compiler dependant "bad" ? Let's assume the following assignment: i := conv_integer(l_vector); ... When I do not include the unsigned library I get the error message: "Object cannot be indexed because it has integer type rather than array type". So how can I make the same assignment when only using the 1164 and arith library? Rgds Eva > > One minor point: > > > library ieee; > > > > use ieee.std_logic_1164.all; > > use ieee.std_logic_arith.all; > > use ieee.std_logic_unsigned.all; > > Best to avoid this. std_logic_unsigned is not pretty. > std_logic_arith or numeric_std will do a better and > clearer job for anything you are likely to need. >Article: 65216
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:<aYKPb.14422$si4.11688@newssvr25.news.prodigy.com>... > "Blake Henry" wrote: > > > what's involved in getting the P.E. moniker > > In the interest of accuracy (not criticism), "P.E." is not a moniker, which > means "nickname". > > "PE" stands for "Professional Engineer". A Google search using that phrase > reveals a world of information on the subject. Gee, and here I was thinking Ray is a Private Eye on the side ! ;*) Cheers, rudi ======================================================== ASICS.ws ::: Solutions for your ASIC/FPGA needs ::: ..............::: FPGAs * Full Custom ICs * IP Cores ::: FREE IP Cores -> http://www.asics.ws/ <- FREE EDA ToolsArticle: 65217
I have used a lot of the synthesisers out there and I have had errors with all of them at one time or another. I have usually tackled them in the way you describe. Usually I have found particular constructs to be the issue and generally avoid the ones that cause problems. Generally the best way to find the bugs is in a post synthesis simulation. Do this ideally with a self checking testbench that you can run on a spare machine in the background. It can be a long process on a big design. To reduce the long synthesis/simulation times consider using modular synthesis and simulation. Some tools will do this automatically for you. Using this approach you can virtually ignore "good" modules and look for problems in the modules you have actually changed either by design or synthesis. I hope to have a article on the cheap and cheerful approach to this in our TechiTips page either this month or next. John Adair Enterpoint Ltd. This message is the personal opinion of the sender and not that necessarily that of Enterpoint Ltd.. Readers should make their own evaluation of the facts. No responsibility for error or inaccuracy is accepted. "Ken Morrow" <junk@not_morro.co.uk> wrote in message news:wmDPb.26583$qx2.3022656@stones.force9.net... > Hi, > > I have recently had lots of incorrectly synthesised logic with the > synthesiser I am using. > My latest design occupied approx 20% of a "6 million gate" FPGA, and had a > total of 5 > incorrectly synthesised parts (which took some finding). > > Can anyone recommend any synthesisers which do not suffer from this sort of > problem? > > The synth takes approx 1 hour to synth this (much quicker than most of my > "large" designs), and timing far > exceeds the requirements as the clock frequency is low. > > If anyone is interested, the sort of errors I was getting were:- > > A connection between 2 components was simply not made. An input to the > second component was hardwired to '0'. > Tried the very latest version of the same synth and the problem went away. > > The following problems were seen in the latest version:- > > OUT_DATA <= IN_DATA & "0"; > synthesised to > OUT_DATA <= "0" & IN_DATA; > put this in a clocked process and it synthesised correctly. > > OUT_DATA <= 2**IN_DATA; > had OUT_DATA(0) hardwired to '1'. > replaced with a case statement and it synthesised correctly > > if X = -1 then > OUT_DATA <= IN_DATA; > elsif X= 1 then > OUT_DATA <= 0 - IN_DATA; > elsif X=0 then > OUT_DATA <= 0; > else > OUT_DATA <= 0 - IN_DATA; > end if; > had OUT_DATA=0 when X=-1 > put calculation of 0 - IN_DATA in a separate clocked process, and it > synthesised correctly. > > > An inferred ROM which synthesised correctly in an earlier version of the > synthesiser, now infers a ROM filled with zeros. > I worked around this by adding a reset to cause the ROM function to be built > from logic. This greatly increased > the size, but this is not a problem for the particular design. > > I tried synthing the rogue pieces of code standalone, and they were synthed > correctly (apart from the ROM). > > Thanks, > > Ken, > Morrow Electronics Limited, > Milton Keynes, > UK. > > kenm@morro.co.uk without the m after my name otherwise it will not be > delivered. > > >Article: 65218
Hi,
Does anyone know if XST 6.1.3 supports the "indexed part select"
feature of Verilog 2001? (It's in section 4.2.1 of the LRM.)
The Xilinx documentation states explicitly that it does support this
feature, yet when I try to use it, I get this error message:
ERROR:Xst:850 - foo.v line 134: Unsupported .
Example code:
reg [7:0] bar;
wire [31:0] foo;
genvar j;
generate
for (j=0; j<8; j=j+1) begin : label
always @(posedge clk)
// error on next line:
bar[j] <= &foo[4*j +: 4];
end
endgenerate
Is there something special I have to do to enable 2001 support?
Thanks,
Allan.
Article: 65219Hi, Is there anybody ou there who tried to run the real time OS ucOSII on a virtex II platform ? Have you tried different OS ? I know that some Virtex II Pro kits comes with Linux as embedded OS but I'm wondering if it's not too heavy for fast real time systems with dedicated hardware parts (such as image processing, etc ...). What kind of experience do you have with Virtex II Pro and different OS ? How do you manage the use of hardware peripherals (IO, computing ressources, etc ...) Thanks a lot for your help StephaneArticle: 65220
> What version of EDK and ChipScope are you using? EDK 6.1 SP1 ChipScope Pro 6.1 Regards, Arkaitz.Article: 65221
Hi all,
I have a design where MicroBlaze isn't the top level of it.
I have simulated the behavioral model with ModelSim SE 5.6f and it
works fine but when I implement and download to the FGPA it doesn't
work, so now I want to simulate the Post-Place & Route model too see
if there's any timing wrong.
Due to my MicroBlaze desing isn't the top level, XPS doesn't allow me
generate the behavioral model, so I have to do it manually. That's the
way I have done the behavioral model simulation.
So I have a Project Navigator design with various components which one
of them is the MicroBlaze designed in XPS. In the testbench I use a
configuration block where I assign the code that needs to be inside
the blockram of MicroBlaze.
Since MicroBlaze isn't my top level this configuration block has the
next aspect:
configuration testbench_conf of system_tb_system_vhd_tb is
for behavior
for uut1 : top_level
for structure
for uut2: mb_blaze
for structure
for all: instr_mem_wrapper use configuration
work.instr_mem_conf;
end for;
end for;
end for;
end for;
end for;
end for;
end testbench_conf;
The problem comes here. When I ask ISE to simulate the P&R model it
generates a file called "top_level_timing.vhd" which hasn't got any
hierarchy, so obvioulsy the configuration block generates some
compilation errors.
Is there any other way to assign the contents of the instruction set
to the blockram of MicroBlaze?
Any other idea to avoid this error?
I am not used to working with configuration blocks, so the solution
might be obvious.
Thanks in advance,
Arkaitz.
Article: 65222Peter Alfke wrote: > > Ralph Malph wrote: > > > > I have seen several startup FPGA > > companies look good and then fail. This even includes large companies > > like Motorola. > > Here is a partial list of major companies that introduced FPGAs, and > then gave up: > > Motorola (never got out of the starting gate, relied on external software...) I don't know that it was the software that killed this product. They were using NeoCad which was pretty successful (at least technically) for the other vendors they supported. > Intel (sold it to Altera, who then canned it quietly) This line was second sourced by Cypress. I can only assume that Altera did not want to cooperate with Cypress and did not feel the need for second sources. > NSC (disappeared quietly) > AMD (sold it to Lattice) PLDs only AFAIK. Still being made. It was sold off not because it was failling, but because it was successful and AMD needed cash to keep the CPU business running. > ATT (sold it to Lattice) ATT never wanted to be a significant player. They developed the ORCA line to get telecoms to migrate to their ASICs. Can't say how well that worked. > T.I. ( stopped being second source to Actel) I don't remember then selling FPGAs or similar, they did CPLDs. TI did a complete makeover and decided that they were all about DSP in telecoms. They sold off everything that was not a key technology and bought a lot of stuff that was. > Toshiba (never really made it) I never even heard of them. > Cypress (?) Still there. I can't say how much market share they have, but they are selling product still. > The moral of the story is that you survive as an FPGA manufacturer only > when you are totally dedicated to that product line, which is true for > Xilinx, Altera, Lattice, Actel, Quicklogic and some small start-ups. > The Big Guys usually find it easier to make their money on other products. You forgot Philips who's product line you bought (or at least part of it). But being solely a PLD vendor does not guaranty success. There are any number of PLD makers that have gone by the wayside, several of which were bought by Xilinx, some by Altera and others got swallowed up by the remaining players. Heck, even the FPGA software companies are not immune to being swallowed up. The current Xilinx tools are just the latest version of NeoCad software I belive. I think there is something else that is required to make it in the FPGA/PLD world. But I think the biggest factor is just that it is a limited market and unless you are getting 10%+ market share, it is not worth the commitment. So a shakeout to four or five players was inevitable.Article: 65223
<Bochumfrau@gmx.de> wrote in message news:17b83bf3.0401220306.3bfbe0ed@posting.google.com... > Why is it better to avoid the unsigned library? std_logic_vector is simply a collection of std_logic bits. The std_logic_unsigned package gives std_logic_vector a new meaning (unsigned binary) that can be confusing, and if you want to use signed numbers in the same design it will become very difficult. On the other hand, std_logic_arith defines two new data types SIGNED and UNSIGNED, with the *same definition* as std_logic_vector. Using this, you can be very clear about what you are trying to do. numeric_std is even better, because it is properly standardised by IEEE and it has a more complete set of functions and operators. > Let's assume the following assignment: > > i := conv_integer(l_vector); > > ... > > When I do not include the unsigned library I get the error message: > "Object cannot be indexed because it has integer type rather than > array type". i := conv_integer( unsigned(l_vector) ); std_logic_vector and unsigned have the same definition, so they are "closely related" and you can convert from one to the other by using the type name as if it were a conversion function. The vector<->integer conversions work between integer and SIGNED or UNSIGNED data. -- Jonathan BromleyArticle: 65224
Josep Duran wrote: > > Thank you Peter, > > "Peter Alfke" <peter@xilinx.com> escribió en el mensaje > news:400F2439.EC57ADB0@xilinx.com... > > The XC9536XL is a Flash-based CPLD. Different from an SRAM-based FPGA, > > you do not reconfigure it just by cycling Vcc. The CPLD would need a > > fresh in-system programming operation, which is not automatic nor > > happens by accident. > > Yes. That part I understand. > > > So, what might have happened is that your design got into an illegal > > state, out of which it cannot excape, but which did not affect the > configuration. > > > > This was my first thought, I double checked the state machine, and I don´t > think there is a problem there. Illegal states have to do with combinations of your state FFs that are not accounted for in your machine. Or if you have more than one machine and have not accounted for all the state combinations you can get into trouble. Sometimes two machines interact in a way that they need to be considered one machine. Make sure you have a bubble in your state diagram that cooresponds to every possible state encoding, then there are no "illegal" states. Also account for all combinations of inputs at every state. > > A more far-fetched explanation is based on the fact that a small part of > > the Flash-based configuration actually gets transferred into internal > > latches (like in an FPGA), which of course might get upset, and that > > would be fixed by cycling Vcc. > > This is the part I am actually concerned. Could a noisy or poorly decoupled > Vcc be the source of the problems. How far-fetched explanation is this ? Is > it really possible ? Yes, noise on the Vcc can cause trouble for any design that has volital storage, state machine or not. Your state FFs can be corrupted by noise on Vcc. > If I read the configuration through the JTAG port, do I get the > internal-actual-RAM configuration, or the Flash configuration ? > > Or should I be looking for a bad solder point or other more mechanical > explanation ?
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