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
I am looking for documentation for a MACH 5 evaluation/demo board I have. This board was made by AMD. The only printing on the board (beside component reference designators) is the words "Advanced Micro Devices" in the top left corner, and the words "MACH 5, 160 I/Os, DEMO BOARD," on the left side toward the middle. The board contains a socket for a 208 PQFP MACH device. It also has a reset switch, connectors for JTAG IN and JTAG OUT, a reset switch, 4-bit DIP switch, and 4 large 7-segment LEDS. On each of the 4 sides of the 208-pin socket are 42 header posts for I/O connections to the MACH 5 part. Any documentation (or pointers to doc) would be appreciated. I would like to use this board for some prototyping and perhaps as a learning aid for some high school students. I don't want to throw it out. Help! Thanks, Bob Widlicka Lucent Technologies widlicka@lucent.com --Article: 65176
$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: 65177Raivo Nael wrote: > > I too think that FPGA-s in small packages would be great things. I > also think that this secrecy politics that programmable logic > manufacturers use, has made FPGA very imaginationless component. Look > at microcontrollers, how many different packages, architectures and so > on. And hunderds of different manufacturers. That is a good point, that MCUs and FPGAs seem to be handled very differently in the market place. I have seen several startup FPGA companies look good and then fail. This even includes large companies like Motorola. They talked about an FPGA line using the "Pilkington" architecture and came very close to introduction before they shut it down. I never did hear anything about why they turned it off. I expect that there is a bit more NRE and maintenance for FPGA products than there is for an MCU line. I can't really rationalize this other than to say that FPGA software seems to require constant upgrades while most MCU compilers are supported by a smaller team that mostly does minor upgrades and bug fixes. Am I off base on this? I would also say that they seem to make more changes to FPGAs when they introduce a new family than they typically do when they come out with a new MCU family member. Maybe that is it? MCUs normally have a new family member, while FPGAs get entirely new families.Article: 65178
FPGAs offer an unprecedented tool in design verification: reconfiguration. If
done carefully, one can completely isolate the board level testing from the
FPGA guts testing when the FPGA is used as some sort of data processor. For
example, if the FPGA is interfacing memory, you can make a fairly simple FPGA
build to test the memory using your FPGA memory interface a test pattern
generator and a test pattern checker. Such a tester can test the memories much
more completely and under more stringent conditions than any other method of
testing. When there are multiple memories, for example, the FPGA can test all
in parallel using worst case patterns. If the memory passes with tht test, it
will likely not fail in normal use. Likewise, the interface pieces can be
tested without the rest of the FPGA guts, and interfaces exercised much harder
than they might be in normal use. Take advantage of the FPGA's
reconfigurability to check out your board level design and your FPGA interfaces
to that design. Once those are debugged, then getting it all to play together
is not hard if you've simulated the pieces and have done your homework on the
timing. I discuss this approach with considerably more detail in my paper "An
FPGA Based Processor Yields a Real Time High Fidelity Radar Environment
Simulator", which is available for download from my website at no charge.
--
--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: 65179Tobias, let me assume that your microcontroller is outside the FPGA, and has a bidirectional data connection to I/O pins of the FPGA. Inside the FPGA you now have data input lines coming from the input buffer, and data output lines going to the output buffer, and a 3-state control that makes sure you are not driving the outputs while you are receiving data. You see that the external 3-state functionality can never be carried through the I/O into the FPGA. (That is inherently impossible because the input buffer has amplification, and the output buffer, too. ) Inside the FPGA you now have two sets of lines, one set is input and the other one is output. You can then route them to the appropriate pins on the BlockRAM. 3-state drivers are used to send data onto a common output, just by wiring the drivers together. This assumes that only one of them is active at any specific time. But if you know which one is active, you could have ( and you will most of the time) implement this with a multiplexer. TTL circuits existed for almost 10 years, until NSC invented the "Tristate" output in the early seventies. I "invented" it a few months too late :-( Hope this explains it, otherwise you can contact me directly, even in German (I got my degree from your neighboring TU in Hannover) Peter Alfke =================================== Tobias Moeglich wrote: > > I can't see the coherence between a 3-state-buffer for a bus and a > multiplexer. > What I want to design is following: > > The data bus of a microcontroller shall be connected to a true dual port > RAM of the Spartan-IIE. > The dual port RAM (generated by the CoreGenerator) has an input port (dina) > and an output port (douta) > because the data port of the DPRAM is not bidirectional. So I try to put a > 3-state buffer between the > data port lines of the controller and the data output port of the DPRAM > (douta). > The pins of the input port of the DPFRAM (dina) can be connected directly > with the data lines of the controller.(??) > I think this should work. Or? > But how to implement it? How is it expressed in VHDL? > > What has a 3-state-buufer to do with a multiplexer? > A multiplexer always chooses one out of 4,8, 16 (what ever) lines and > directs it with the output of the mux. > Isn't that the way a multiplexer works?? I thought so. > How can I use a mux instead of a 3-state buffer ?? > > Greatings, Tobias.Article: 65180
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...) Intel (sold it to Altera, who then canned it quietly) NSC (disappeared quietly) AMD (sold it to Lattice) ATT (sold it to Lattice) T.I. ( stopped being second source to Actel) Toshiba (never really made it) Cypress (?) 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. Peter AlfkeArticle: 65181
I have a small circuit using the 9536XL CPLD. The complete machine uses 64 of such circuits. I have tested it on the lab and everything works just fine. The problem is the other day, while at the client premises, I saw something wrong with one of the boards. The CPLD stopped responding to the commands sent by the computer. As I had no test equipment available, I just tried to send some reset commands to the board and get no response. I turned power off to change the board, but just before replacing it I gave it another try. To my surprise, everything worked fine this time. I did some intensive testing to the board, and again everything went OK. To me, it looks like the CPLD lost its configuration. Is this at all possible ? If so, what can I do to prevent this from happening ? Anybody seen something like this before ? NB - it is a 2 layer board (no GND plane) about 3 sq inches. Thank you for your time. Josep DuranArticle: 65182
Patrick Birger <bread_pitt@web.de> wrote in message news:4454c7b.0401201545.1341dbc4@posting.google.com... > Rene Tschaggelar <none@none.none> wrote in message news:<22121bd70e95748cc78f4729260a05bb@news.teranews.com>... > > > > have a look at http://www.ebv.com for the Altera parts. > > Thanks for the address. I've called them: same problem as with > "Spoerle" > 1. They only sell to companies, not to private persons. > 2. Their minimum package quantity is in general 30-90. But I don't > want to order some 50 FPGAs, 10$ each. > Is it impossible to buy a single altera FPGA chip without founding a > company?? Patrick, have you tried Arrow? I'm sure I bought components off them on a personal credit card a few years ago (before starting NSD Ltd). Nial Stewart ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone based 'Easy PCI' eval board www.nialstewartdevelopments.co.ukArticle: 65183
"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. > Blake, Ray - Thanks. Obviously I didn't carry the O&E coverage before. I did the minimum that a customer back then required. The new customer is specifically asking for O&E (the contract calls it "Contractual Liability" coverage). Another $6k - sweet. I love spending money on insurance almost as much as paying taxes. RobertArticle: 65184
dinb <= data_DSP when (CS = '0') else (others => 'Z'); You still express MUX logic in VHDL as you do for tri-state inference. The synthesis tool automatically maps the tri-states to muxes in hardware. As peter pointed out, the tri-state hardware capability doesn't exist in the FPGA's CLB fabric. Tri-states can be thought of as a fully-decoded muxes. In other words, the tri-state enable signal selects which of the drivers has control of the bus. Thus, synthesis tools map the tri-state enable lines to the select lines for the muxes. There's a good book, "Essential VHDL - RTL synthesis done right" by Sundar Rajan that talks about writing VHDL for FPGA fabric. The author uses synplify as the example synthesis engine. There's a discussion of hardware creation that talks about the tri-state to mux mapping performed by synthesis tools. > What has a 3-state-buufer to do with a multiplexer? > A multiplexer always chooses one out of 4,8, 16 (what ever) lines and > directs it with the output of the mux. > Isn't that the way a multiplexer works?? I thought so. > How can I use a mux instead of a 3-state buffer ?? > > Greatings, Tobias. > -- / 7\'7 Paulo Dutra (paulo.dutra@xilinx.com) \ \ ` Xilinx hotline@xilinx.com / / 2100 Logic Drive http://www.xilinx.com \_\/.\ San Jose, California 95124-3450 USAArticle: 65185
I get the following error while doing map on my design -------------------------------------------------------------- this is what echoes on the terminal... "Found an unexpected XMODULE_CELLTYPE property on frag" -------------------------------------------------------------- this is what is seen in the mrp file? WARNING:MapLib:328 - Block abcd_inst is not a recognized logical block. The mapper will continue to process the design but there may be design problems if this block does not get trimmed. any help is appreciated. nachiket.Article: 65186
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: 65187
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: 65188
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. 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. 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. All CPLD manufacturers use this convenient mechanism, but hardly anybody talks about it, since it creates the impression of "volatility"... Peter Alfke =================================== Josep Duran wrote: > > I have a small circuit using the 9536XL CPLD. The complete machine uses > 64 of such circuits. I have tested it on the lab and everything works just > fine. > > The problem is the other day, while at the client premises, I saw something > wrong > with one of the boards. The CPLD stopped responding to the commands sent by > the computer. As I had no test equipment available, I just tried to send > some reset > commands to the board and get no response. I turned power off to change the > board, but just before replacing it I gave it another try. To my surprise, > everything worked fine this time. I did some intensive testing to the board, > and again > everything went OK. > > To me, it looks like the CPLD lost its configuration. > Is this at all possible ? If so, what can I do to prevent this from > happening ? > Anybody seen something like this before ? > > NB - it is a 2 layer board (no GND plane) about 3 sq inches. > > Thank you for your time. > > Josep DuranArticle: 65189
Thing about O&E is you more or less have to keep it in force once you have
it too. It usually is issued on a claims made basis, so it only protects
you for claims made while the policy is in effect, if you do work while
under the policy, then drop the policy and then the customer sues you after
the policy coverage is gone, it doesn't cover the work even though it was
done while the policy was in effect. THe coverage is expensive, but I
wouldn't want to be without it if a claim was ever made. It's a cost of
doing business, it's tax deductable, and it is a relatively small cost
compared to the taxes, salary, pension, tools & equipment that go with the
territory if you are serious about this business.
Robert Sefton wrote:
> "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.
> >
>
> Blake, Ray -
>
> Thanks. Obviously I didn't carry the O&E coverage before. I did the
> minimum that a customer back then required. The new customer is
> specifically asking for O&E (the contract calls it "Contractual
> Liability" coverage). Another $6k - sweet. I love spending money on
> insurance almost as much as paying taxes.
>
> Robert
--
--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: 65190
Atmel .. still in it, but I still can't figure out why
Dynachip .. got as far as producing silicon before dying
Gatefield .. sold to was it Actel?
Concurrent Logic .. became the Atmel/NSC architecture
IBM .. got rights from the spoils of concurrent. Toyed with multi-chip module
implementations, but never really made it out of the labs
Not to mention numerous universities with academic architectures
and the list goes on...
The fact of the matter is that development tools for MCUs are a heck of a lot
easier to develop. The problem is much more constrained (limited number of
instructions and linear sequential operation) for an MCU. As I'm sure both
Xilinx and ALtera have found, the tools development is a larger effort than the
silicon architecture and design effort by a large margin. I still maintain that
FPGA companies are really software companies that just happen to have an
expensive dongle that happens to be useful to circuit designers.
Peter 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...)
> Intel (sold it to Altera, who then canned it quietly)
> NSC (disappeared quietly)
> AMD (sold it to Lattice)
> ATT (sold it to Lattice)
> T.I. ( stopped being second source to Actel)
> Toshiba (never really made it)
> Cypress (?)
>
> 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.
>
> Peter Alfke
--
--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: 65191The Quartus II 3.0 Tool from Altera has a good VHDL/Verilog parser and synthesis capability. The output of the synthesiser will work only with the place and route tools from Altera, and you target all of the Altera devices. A free version of the tools is available from: https://www.altera.com/support/software/download/altera_design/quartus_we/dn l-quartus_we.jsp - Subroto Datta Altera Corp. "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: 65192
Ray Andraka wrote: > Atmel .. still in it, but I still can't figure out why > Dynachip .. got as far as producing silicon before dying > Gatefield .. sold to was it Actel? Yes, and might yet hit critical mass - they service a niche with true one chip FPGAs (FLASH included) > Concurrent Logic .. became the Atmel/NSC architecture > IBM .. got rights from the spoils of concurrent. Toyed with multi-chip module > implementations, but never really made it out of the labs > Not to mention numerous universities with academic architectures > and the list goes on... Triscend anyone ? Both the Triscend, and Atmel FPSlic must struggle against the NIOS/MicroBlaze (etc) solutions. > > The fact of the matter is that development tools for MCUs are a heck of a lot > easier to develop. The problem is much more constrained (limited number of > instructions and linear sequential operation) for an MCU. As I'm sure both > Xilinx and ALtera have found, the tools development is a larger effort than the > silicon architecture and design effort by a large margin. I still maintain that > FPGA companies are really software companies that just happen to have an > expensive dongle that happens to be useful to circuit designers. Correct - Some stats were released last year (Altera?) showing they employed more SW engineers than HW designers. -jgArticle: 65193
Peter Alfke wrote: > 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. > 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. Correct - Check if you have any state machines, and what they do from illegal states. > > 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. > All CPLD manufacturers use this convenient mechanism, but hardly anybody > talks about it, since it creates the impression of "volatility"... > > Peter Alfke You can sometimes find this hidden in the fine print, in the appx form of "Vcc must be reduced to < 0.9V before being increased again'. Systems that are prone to brown-out and non monotonic Vcc are more risky in this area. If you have the resource room, you can add read-back or similar 'check-it-actually-happened' to the PLD code, and have your system watch for any out-to-lunch behaviour. -jgArticle: 65194
guille wrote: > Hi there, > > Sorry for another Xilinx-specific question :) > > Peter Alfke mentioned this 70% tracking rule for timing parameters, > which basically says that if a parameter is at its max value, then all > other parameters are between 70% and 100% of their guaranteed maximums. > For Xilinx CPLDs, at least. > > This makes a lot of sense from a physical standpoint, and I've seen > it mentioned in other posts too. > > I have only one question, if somebody can help. How is this 70% figure > calculated, or estimated? Is it based on lab results only, or was it > first derived analytically in some way or another and then verified > experimentally? (I believe the latter). I'm curious about the physics > involved. It will be experimental / empirical. It derives from all gates being on the same wafer (thus largely process track), and at the same Vcc, and similar Temperatures. Normal process tracking these days is very good, and a portion of variance will be physical location dependant, but it's easier to umbrella that under process or min/max timing. -jgArticle: 65195
Did you analyze your design for nominal conditions or worst case operating conditions? I have seen boards fail when the got warm after being closed up (or after a friend sets their engineering notebook on top of the box and it heated up a little). This happened to a board that I was interfacing to. Problem went away after we drilled larger vent holes in the product. I guess that is what you get when you get a product that is still in beta testing. Cheers, Jim Josep Duran wrote: > I have a small circuit using the 9536XL CPLD. The complete machine uses > 64 of such circuits. I have tested it on the lab and everything works just > fine. > > The problem is the other day, while at the client premises, I saw something > wrong > with one of the boards. The CPLD stopped responding to the commands sent by > the computer. As I had no test equipment available, I just tried to send > some reset > commands to the board and get no response. I turned power off to change the > board, but just before replacing it I gave it another try. To my surprise, > everything worked fine this time. I did some intensive testing to the board, > and again > everything went OK. > > To me, it looks like the CPLD lost its configuration. > Is this at all possible ? If so, what can I do to prevent this from > happening ? > Anybody seen something like this before ? > > > NB - it is a 2 layer board (no GND plane) about 3 sq inches. > > > Thank you for your time. > > Josep Duran > > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jim Lewis Director of Training mailto:Jim@SynthWorks.com SynthWorks Design Inc. http://www.SynthWorks.com 1-503-590-4787 Expert VHDL Training for Hardware Design and Verification ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Article: 65196
"Austin Lesea" <austin@xilinx.com> escribió en el mensaje news:bup6dl$8dl2@cliff.xsj.xilinx.com... > The reason for the failure of other parts could be that they are NOT > FPGAs. FPGAs are manufactured in huge volumes, and are all tested in > the qualification for latch up under irradiation. Many SRAM,s and other > products do not have the volume to afford such testing, and in fact > recent shrinks of common parts are known to latch up with a single > event, and destroy themselves. Interesting. Under what conditions and what kind of tests are Xilinx rad-hard FPGAs tested for irradiation? Datasheets usually have too condensed information about rad parameters... Regards.Article: 65197
Souds like you have asynchronous circuit in your design. I saw many times your troubles in the past using CPLD andor FPGA. Every times these troubles became from kinds of asynchronous circuit or conception. When running asynchronous circuit, temperature can be affect your design, sometimes or sometimes not. First, make sure you synchronize all your input signals, before to use it !!! Make sure your design DONT use comb. latch ! Regards, Laurent www.amontec.com Josep Duran wrote: > I have a small circuit using the 9536XL CPLD. The complete machine uses > 64 of such circuits. I have tested it on the lab and everything works just > fine. > > The problem is the other day, while at the client premises, I saw something > wrong > with one of the boards. The CPLD stopped responding to the commands sent by > the computer. As I had no test equipment available, I just tried to send > some reset > commands to the board and get no response. I turned power off to change the > board, but just before replacing it I gave it another try. To my surprise, > everything worked fine this time. I did some intensive testing to the board, > and again > everything went OK. > > To me, it looks like the CPLD lost its configuration. > Is this at all possible ? If so, what can I do to prevent this from > happening ? > Anybody seen something like this before ? > > > NB - it is a 2 layer board (no GND plane) about 3 sq inches. > > > Thank you for your time. > > Josep Duran > >Article: 65198
Ken Morrow wrote: > 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. > > > Every synthesizer will suffer 'cause all of them are SW and SW (as well as HW ;-) has bugs... The only solution to that problem would be to use an equivalence checker to check the generated Netlist against the RTL. They are also not bug free, but if the do not share code, the probability of having the same bug is near to 0. Tools in that area are for example Verplex LEC but there are a lot more. HTH -EyckArticle: 65199
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: - Differences between rising and falling delay (is the max # worst case of two?) - Localized IR drop in power network causes differences in Vdd seen by transistors in different areas of chip - Temperature gradients due to differing power densities - Unmodeled differences in physical structure between similar resources. For example, in a crude timing model all wires of length 4 could be given same delay, but in reality there are differences in what metal they are adjacent to, they could have slightly different lengths, etc. Or trace lengths for two IOs could be slightly different. Of course, whether this need be included in the 70% depends on whether timing model accounts for this stuff or not. - Cross-coupling, which can speed up (or slow down) a signal. Also, some aspects of process track very well across a die (e.g. metal, dielectric thickness), while others do not -- for example, tranistor threshold voltage can vary significantly from one transistor to the next due to the stoicastic nature of implants/dopants, though the average Vt value will be similar across the die. Since timing paths include multiple transistors, you tend to get an averaging effect, but still, it is another thing to worry about. 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? Regards, Paul Leventis Altera Corp. > It will be experimental / empirical. > It derives from all gates being on the same wafer (thus largely process > track), and at the same Vcc, and similar Temperatures. > Normal process tracking these days is very good, and a portion of > variance will be physical location dependant, but it's easier to > umbrella that under process or min/max timing.
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