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
Goran Bilski wrote: > Hi, > > You only assign the signal Result with "0000". > The result of the synthesis is a module where the outputs Result is assign to > ground. > No input values will change that and therefore is removed from the netlist. > > Göran Bilski > To follow on a bit from that. If all those inputs will eventually be used but you're doing trial synthesis as you build up the design then the usual trick is to combine them all together (e.g. `and' them) and assign the result to a dummy output. BTW Do I detect signs here of that legendary example from Logic Design 101 - the traffic light controller ?Article: 46751
"hristo" <hristostev@yahoo.com> schrieb im Newsbeitrag news:b0ab35d4.0209061316.25255168@posting.google.com... > these are the type of answers that i dislike John_H :-(... > > what i want to tell is that usually the user will be restricted with > off chip interface performances and so there is no need to tighten a > lot the design. as i said ~33 Mhz is enough for 512*512 image > processing, behavioral VHDL will be more than enough for me Have you ever done signal processing in the real world? It's simply NOT enough to sample the picture and calculate the data-rate. You want to to PROCESSING, not just transportation. So if you have a complex function, lets say the good (old?) FFT, you need MANY operations per pixel. And in most cases, you want to to it fast, even real-time. So the demand for horse power will increase constantly. -- MfG FalkArticle: 46752
"Peter Alfke" <peter@xilinx.com> schrieb im Newsbeitrag news:3D79259B.3BDF9CFA@xilinx.com... > The original question was: > Why four times the price for 50% more macrocells? > > Here is an attempt at a rational explanation. > There are five factors that contribute to disproportionate pricing: > > 1. More chip area. CPLDs don't grow linearily, their interconnect grows > faster.(Different from FPGAs) > 2. Lower yield due to defect density on the wafer. That increases the cost for > any die faster than the growth of the die area. (Semiconductor Physics 101) > 3. Lower production volume. High volume drives cost down. The reverse is also > true. > 4. Fancier package. > 5. And finally: Less competitive pressure. Everybody will understand this. > > These are the five factors that make the '384 overproportionally more expensive > than the '256. > You might argue about each individual factor, but you cannot overcome their > composite effect. > But CoolRunner-II uses smaller geometries and will be less expensive... I think this is a comprehensive answer. Thank you, Peter. -- MfG FalkArticle: 46753
Hi,
In the following code, synplicity removes the "sk_wroffset_ctr_en " i.e optimises away.
I have kept the syn_keep attribute on it but to no effect. I have found out that the conv_integer function is the problem. Caue When I dont use the conv_integer function then this optimising problem isnt there.
Can someone suggest how synplicity can be made to take this function.
cheers
nikhil
########################################################################
skwoc_p : process (clk20, rst)
begin
if rst = '1' then
sk_wroffset_ctr_en <= (others => '0');
elsif clk20'event and clk20 = '1' then
for i in 0 to 83 loop
if ((buffer_en(i) = '1') and ((conv_integer(sk_timeslot_ctr_val(i))) = i)) then
sk_wroffset_ctr_en(i) <= '1';
else
sk_wroffset_ctr_en(i) <= '0';
end if;
end loop;
end if;
end process skwoc_p;
####################################
Article: 46754Hi all, i have few questions about the pci bus, no good answers in the specs and i hope you have some extra info.. Could any1 explain me how exactly the pci bus handles the relected signals of the non-terminated lines? I can't understand what all that diode clamps stand for. A document for example says "clamp diodes protect inputs from momentary short circuit current caused by tri-stating delays". What about that tri-stating delay, i mean how could a signal delay cause a short circuit? example: i have schematics of a clamped input, a clamp to the 5V rail (from input to the rail diode orientation) and a clamp to ground (from GND to input diode orientation), bth diodes meet at a certain "vertex" and appear to be in paralell with respect to the power rails. How des this prevent a short? Are the clamp diodes some kind of special diodes? Can u tell me a brand name & model for diodes that would work as clamps(in 5V signalling environment)? Thanks for your time!Article: 46756
sorry john-h if my reply seemed rude. i am still struggling to improve my english skills....Article: 46757
<<The design is strictly synchronous with positive edge clocking and no internal tri-state buffers; therefore scan insertion is easily feasible.>> i took that fron xilinx code data sheet can someone explain me what it means by scan insertion is easily feasible? and how this is linked with the TBUF use thanksArticle: 46758
Hi, I am looking for PRACTICAL fault-tolerant fpga design methodes. Can you help me in this regards? I am familiar with traditional fault-tolerant design methodes, but specificly I am looking for fpga fault tolerant design methodes. Best Regards. Masoud NaderiArticle: 46759
Thank you, Peter. This information is valuable. -- Phil HaysArticle: 46760
I think the very first step must be to identify the "faults" you want to protect against. Internal shorts and opens, single-event upsets, etc. Peter Alfke, Xilinx Applications Masoud Naderi wrote: > Hi, > I am looking for PRACTICAL fault-tolerant fpga design methodes. Can > you help me in this regards? > I am familiar with traditional fault-tolerant design methodes, but > specificly I am looking for fpga fault tolerant design methodes. > > Best Regards. > Masoud NaderiArticle: 46761
--------------F4B1AC24AB158F3B66864746 Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Let me point out a misleading sentence in my previous posting: "For lower clock rates and less frequent asynchronous events, MTBF increases with the inverse of the product of the two frequencies..." This is not correct, it is the frequency of any specific metastable delay that increases with the product of clock and input frequency. For the more practical case, where you are concerned about (not) exceeding a full clock period, things are much better, since you get the benefit of the longer clock period. In my example, a 350 MHz clock synchronizing a 50 MHz input, the data connection between the input flip-flop and a following flip-flop clocked by the same clock will result in an error statistically once every 12 million years. If you lower the clock frequency to 250 MHz, you gain more than 1 ns in clock period, which means five multiplications by 200. That makes the MTBF 320 billion times larger, i.e. roughly 4 billion billion years ( 4 exp18 ). That is roughly 200 million times the highest estimate for the life of the Universe (20 billion years) or about a billion times the age of our dear old planet (4 billion years). Most people would call that a very low probability. Brave souls might even dare to call it zero. Metastability is real, but its impact on modern CMOS logic has been highly exaggerated. It's nice to finally have hard data to prove that. Peter Alfke, Xilinx Applications for the age of the universe, click on http://www.astro.ucla.edu/~wright/age.html ================================================================ Peter Alfke wrote: > We finally got around to measuring metastabity. > We used the CLB flip-flops in our newest Virtex-IIPro device (130 nm > technolgy, 1.5 Vcc) and clocked them at around 350 MHz with an > asynchronous input of roughly 50 MHz. This should represent agressive > modern operating conditions. > We then measured the number of metastable events per minute as a > function of the time between clocking the flip-flop under test, and a > variable clock delay at the observation flip-flop that checks for > metastable events. This method is described in detail in XAPP094, and I > first used and documented it in 1988 (!). The concept seems to have > passed the test of time. > > Here are the measured results: > Metastable events for a clock-to-clock delay of > 1300 ps: ~ 30,000 errors per minute > 1400 ps: ~ 2,000 errors per minute > 1500 ps: ~ 100 errors per minute > 1600 ps: = 10 errors per minute > > These are short-time measurements of a statistical event, but I am > willing to estimate that the time between metastable events increases by > a factor of roughly 200 for every 200 picoseconds of extra delay between > the two clocks. > > That leads to the following extrapolation: > If you synchronize a 50 MHz asynchronous event with a roughly 350 MHz > clock, > and you allow only 1.2 ns for clock-to-out plus set-up time plus routing > to the flip-flop in the adjacent CLB, your design will go metastable > very often; the Mean Time Between Failure will be about 0.1 ms. > But watch what happens when the timing gets more relaxed: > Changing the total delay of 1.2ns to > 1.4 ns leads to MTBF=30 ms > 1.6 ns leads to MTBF= 6 sec > 1.8 ns leads to MTBF= 20 min > 2.0 ns leads to MTBF= 4000 min = 66 hrs > 2.2 ns leads to MTBF= 13,000 hrs = 18 months > 2.4 ns leads to MTBF= 3,600 months = 300 years > 2.6 ns leads to MTBF= 60,000 years > 2.8 ns leads to MTBF= 12 million years > > In other words, you can synchronize ~50 MHz with a 350 MHz clock, take > advantage of the difference between the inherent 1.2 ns and the 350 MHz > clock period of 2.8 ns, and your design will exceed the allowed > propagation delay of one clock period only once every 12 million years. > > For lower clock rates and less frequent asynchronous events, MTBF > increases with the inverse of the product of the two frequencies, i.e. > for a 100 MHz clock synchronizing a ~ 10 MHz asynchronous event, > multiply the MTBF by a factor 3.5 x 5 = 17.5 > More details will be published soon. > > The lack of modern quantative data has been a thorn in my side, and I > want to let you know these encouraging results immediately. > I think we can say that modern CMOS flip-flops recover extremely fast > from any metastable event. :-) > I want to thank Yiding Wu for his enthusiastic help and patience doing > these measurements. > Peter Alfke, Xilinx ApplicationsArticle: 46762
I highly recommend attending the MAPLD (Military Applications of
Programmable Logic Devices) conference in Laurel Maryland next week for
fault tolerance with FPGAs. Probably the first thing you need to do is
identify what faults are to be detected and what measures are to be
taken when a fault is detected. There are a number of fault mechanisms
that need to be considered, and a lot depends on your environment, the
device and the application.
Masoud Naderi wrote:
> Hi,
> I am looking for PRACTICAL fault-tolerant fpga design methodes. Can
> you help me in this regards?
> I am familiar with traditional fault-tolerant design methodes, but
> specificly I am looking for fpga fault tolerant design methodes.
>
> Best Regards.
> Masoud Naderi
--
--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: 46763It's a very interesting project. One thing I can say is you need a massively paralel architecture therefore the simulation is not very important because the repetitive design is very simple. Also is not important the languaje because you can implement a module in VHDL or schematic and replicate it by copy-pasting. XILINX has free software in www.xilinx.com clicking on *PRODUCTS*. You can choose a low cost FPGA like SPARTAN where the minimum structure is the CLB, SPARTAN II begins with 384 CLBs and ends with 1536 CLBs and you will need more than one CLB per neurone therefore forget to implement more than 1k neurone per SPARTAN. I thing it will be better implemented in a gross grained device like a VIRTEX. Do you like Madonna?. "Like a virtex.... :-) Narcís Nadal "Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<alam94$1nomja$3@ID-84877.news.dfncis.de>... > "Havatcha" <nospam@nospam.com> schrieb im Newsbeitrag > news:3D787371.20404@nospam.com... > > > If you are serious about using VHDL, I can also recommend ModelSim > > (http://www.model.com/products/release.asp) as a development tool. I am > > not sure if you can get a free version though..... > > Xilinx supplies a free version of Modelsim along with Webpack. Its limited > in simulation speed depending on VHDL code lines > > <500 lines 100% speed > 500...2000? lines 1% > >2000? 0.1 % ??Article: 46764
(As a newbie) I would say, The easiest approach would be 3 or more identical designs in one FPGA, of which the outputs converge, and every output signal should go through a circuit on that same FPGA that outputs the 'majority' output level. This is very easy to accomplish and thus, every circuit can have 1 different subsystem failing without loss of function. Important aironautical systems are similarly designed. They are in triple or more, in separate hardware designed and manufactured by separate companies. The same goes for the software. But there are different approaches to this. When you want to have a gamma-radiation tolerant design for example, you need a different kind of redundancy, I guess, more like a brain, massively redundant. (I am speaking for my own brain ;o) Frank "Ray Andraka" <ray@andraka.com> wrote in message news:3D7A8CE7.BAFA7BEB@andraka.com... > There are a number of fault mechanisms > that need to be considered, and a lot depends on your environment, the > device and the application.Article: 46765
Peter Alfke wrote:
> We finally got around to measuring metastabity.
[ snip good data set ]
Peter, thanks!
[rk climbs on soapbox]
All manufacturers should publish metastability information for their
flip-flops, so designers can do the computations. And over worst-case
voltage and temperature, too. ;-)
--
rk, Just an OldEngineer
The ability to improve a design occurs primarily at the interfaces. This
is also the prime location for screwing it up.
-- from Akin's Laws of Spacecraft Design
Article: 46766Hi, I look for Orcad 9.2 Capture(Schematic) Library for XCS10XL-PC84(SpartanXL) and XC18V256PC20 PROM. ThanksArticle: 46767
Peter Alfke wrote: > Let me point out a misleading sentence in my previous posting: > > "For lower clock rates and less frequent asynchronous events, MTBF > increases with the inverse of the product of the two frequencies..." > > This is not correct, it is the frequency of any specific metastable > delay that increases with the product of clock and input frequency. > For the more practical case, where you are concerned about (not) > exceeding a full clock period, things are much better, since you get > the benefit of the longer clock period. > > In my example, a 350 MHz clock synchronizing a 50 MHz input, the data > connection between the input flip-flop and a following flip-flop > clocked by the same clock will result in an error statistically once > every 12 million years. > > If you lower the clock frequency to 250 MHz, you gain more than 1 ns > in clock period, which means five multiplications by 200. That makes > the MTBF 320 billion times larger, i.e. roughly 4 billion billion > years ( 4 exp18 ). > That is roughly 200 million times the highest estimate for the life of > the Universe (20 billion years) or about a billion times the age of > our dear old planet (4 billion years). > > Most people would call that a very low probability. Brave souls might > even dare to call it zero. > > Metastability is real, but its impact on modern CMOS logic has been > highly exaggerated. > It's nice to finally have hard data to prove that. > > Peter Alfke, Xilinx Applications > for the age of the universe, click on > http://www.astro.ucla.edu/~wright/age.html > ================================================================ > This means, roughly, that if your critical path, the one that just squeaks past STA, is from a synchroniser then you're in trouble - otherwise not. On another note: (1) We now have a number of Xilinx metastab data points - XC3K, XC4K, V2Pro. (2) I believe its been said before that the metastab resolution time (the x200/200ps figure above) depends on the "speed of the master latch"; which in turn depends on both the FF design and the process geometry. Is it not possible to combine these to get an estimate for Virtex-E ?Article: 46768
Dear Mr. Alfke, What is the second step, Do you know any online documents or so on the second and other steps? Best Regards. Naderi Peter Alfke <palfke@earthlink.net> wrote in message news:<3D7A6C08.E699BEE1@earthlink.net>... > I think the very first step must be to identify the "faults" you want > to protect against. > Internal shorts and opens, single-event upsets, etc. > > Peter Alfke, Xilinx Applications > > Masoud Naderi wrote: > > > Hi, > > I am looking for PRACTICAL fault-tolerant fpga design methodes. Can > > you help me in this regards? > > I am familiar with traditional fault-tolerant design methodes, but > > specificly I am looking for fpga fault tolerant design methodes. > > > > Best Regards. > > Masoud NaderiArticle: 46769
Dear sir, I study paper abstracts at MAPLD conference, but nothing on fault-tolerant desing in NORMAL enviroment. can you give me other online resources? Best Regards. Masoud Naderi Ray Andraka <ray@andraka.com> wrote in message news:<3D7A8CE7.BAFA7BEB@andraka.com>... > I highly recommend attending the MAPLD (Military Applications of > Programmable Logic Devices) conference in Laurel Maryland next week for > fault tolerance with FPGAs. Probably the first thing you need to do is > identify what faults are to be detected and what measures are to be > taken when a fault is detected. There are a number of fault mechanisms > that need to be considered, and a lot depends on your environment, the > device and the application. > > Masoud Naderi wrote: > > > Hi, > > I am looking for PRACTICAL fault-tolerant fpga design methodes. Can > > you help me in this regards? > > I am familiar with traditional fault-tolerant design methodes, but > > specificly I am looking for fpga fault tolerant design methodes. > > > > Best Regards. > > Masoud Naderi > > -- > --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, 1759Article: 46770
Dear sir, Majority method is of use when "majority unit" is HIGH reliable and roboust to faults that make other system parts faulty, But this assumption is not correct in FPGAs.Suppose majority unit fails, what happen? By the way this method has very high overhead that is not so good in FPGAs. Do you know other method? Best Regards Masoud Naderi "Frank Andreas de Groot" <nospam@nospam.com> wrote in message news:<gtwe9.15246$0p1.256900@news2.ulv.nextra.no>... > (As a newbie) I would say, The easiest approach would be 3 or more identical > designs in one FPGA, > of which the outputs converge, and every output signal should go through a > circuit on that same FPGA that outputs the 'majority' output level. This is > very easy to accomplish and thus, every circuit can have 1 different > subsystem failing without loss of function. > > Important aironautical systems are similarly designed. They are in triple or > more, in separate hardware designed and manufactured by separate companies. > The same goes for the software. > > But there are different approaches to this. When you want to have a > gamma-radiation tolerant design for example, you need a different kind of > redundancy, I guess, more like a brain, massively redundant. (I am speaking > for my own brain ;o) > > Frank > > > "Ray Andraka" <ray@andraka.com> wrote in message > news:3D7A8CE7.BAFA7BEB@andraka.com... > > There are a number of fault mechanisms > > that need to be considered, and a lot depends on your environment, the > > device and the application.Article: 46771
SUDIP SAHA schrieb: > Do you know whether any FPGA/CPLD supports I2C bus configuration or not? Means Can I connect any I2C device like a microcontroller to the FPGA via I2C bus and The FPGA will act as a master/slave I2C device? Hi! Yes, it is possible. Here you may find some useful informations: www.opencores.org/projects/i2c HTH -- T |-| ( ) |\/| /-\ S thomas@wambera.de www.wambera.comArticle: 46772
I see what you mean... You should somehow get a similar redundancy in the majority unit, but how... If you were to have say 4 majority units in parallel of which the output signals were averaged and buffered? Frank "Masoud Naderi" <naderimisc@yahoo.com> wrote in message news:2ba3bbea.0209080552.26192b4@posting.google.com... > Dear sir, > Majority method is of use when "majority unit" is HIGH reliable and > roboust to faults that make other system parts faulty, But this > assumption is not correct in FPGAs.Suppose majority unit fails, what > happen? By the way this method has very high overhead that is not so > good in FPGAs. Do you know other method?Article: 46773
Rick Filipkiewicz wrote: > This means, roughly, that if your critical path, the one that just > squeaks past STA, is from a synchroniser then you're in trouble - > otherwise not. Yes, "don't do that". BTW, we will also measure the input flip-flop in the IOB. > On another note: > > (1) We now have a number of Xilinx metastab data points - XC3K, XC4K, > V2Pro. > > (2) I believe its been said before that the metastab resolution time > (the x200/200ps figure above) depends on the "speed of the master > latch"; which in turn depends on both the FF design and the process > geometry. Yes > Is it not possible to combine these to get an estimate for Virtex-E ? I will much rather do the measurements on Virtex-II, VirtexE and Spartan-II, now that we have a working set-up. Virtex-II, the biggest subject of new designs, is especially important. It has been a fun week, actually only three days... Peter Alfke, Xilinx ApplicationsArticle: 46774
Steven Elzinga wrote:
>
> Kevin,
>
>
> I do not recall anyone at Xilinx stating that you can not generate an
> EDIF file from XST in 4.x software.
What about this posting made by a Xilinx employee?
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=3C2CDBDA.5060102%40xilinx.com
What about this Answer Database entry?
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=11641
> We have never promoted EDIF as an
> output from XST for the fact that it is not supported. The fact that
> 4.x XST can generate an EDIF file was actually a poorly kept secret
> (sorry if this might dispell some consipracy theories...)
I don't believe it was a poorly kept secret.
Almost all Xilinx Answers Database entries that discussed about ISE 4.x
XST's output format said ISE 4.x's XST now can only generate an NGC
file.
Maybe the Answers Database entries never said, "XST of ISE 4.x can can
"never" generate an EDIF netlist," but if that's your argument, I feel
like that's pretty weak.
The only Answers Database entry I found that indirectly admitted that
ISE 4.x's XST can indeed generate an EDIF netlist is the following.
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=12747
It does admit that -ofmt option can be EDIF or NGC (ISE 4.x's XST manual
doesn't say that. It only says NGC is the only valid option.), but by
the time I saw this Answer Database entry, I already knew that ISE 4.x's
XST can generate an EDIF netlist, so it didn't help me at all.
If ISE 4.x's XST can generate an EDIF netlist was indeed a poorly kept
secret, why didn't anyone at Xilinx kindly told people of this newsgroup
that XST can do so, with the disclaimer that it is not supported?
> About half
> way through the development process of 4.1i the decision was made to
> move away from EDIF and to generate an NGC file. Because the decision
> was made halfway through the development of 4.1i any work that was
> needed to be done to add constraints (specifically for the Virtex-II
> parts) was not done in the EDIF generation but only in the NGC
> generation. As such, you will get an EDIF file that is logically
> correct but could be missing attributes/cosntraints that you might
> expect.
>
> As our chips are getting larger we find it necessary to couple our
> tools together more tightly. By writing directly to NGC we are
> skipping a portion of the "translate" process. We are only treating
> XST as a Xilinx tool and not a 3rd party tool.
>
To me, the argument you are using is a huge inconvenience to me,
and other users who have complained about XST not being able to generate
an EDIF netlist in this newsgroup.
Regardless of whether or not synthesis tool has to be more closely
integrated with the backend flow, it always doesn't hurt from the user's
perspective to be able to see an EDIF netlist output from the synthesis
tool because XST isn't always perfect, and it does from time to time
incorrectly synthesize a design.
In the past, I have had to waste several days trying to figure out
synthesis related problems because ISE 4.x's XST did not generate an
EDIF netlist.
In retrospect, had I known that ISE 4.x's XST can actually generate an
EDIF netlist, I probably wouldn't have had to waste several days trying
to figure out what was going on.
In one of the case, I ended up having to reinstall WebPACK ISE 3.3, and
see the EDIF generated by that version's XST.
> Starting with 5.1i software the EDIF output has been removed from
> XST. There, I said it, 5.1i XST can not generate EDIF files.
> However, an RTL/technology viewer will be in place to view the results
> that XST generates. There also will be an ngc2edif executable that
> will produce an EDIF file without an typ of INIT programming
> information. This is for CORE Generator cores that might be producing
> NGC files and synthesis tools that will want to read in EDIF cores for
> timing analysis.
>
>
> Steve Elzinga
>
>
Being able to see the schematic equivalent of the contents of an
NGC file is a definite improvement over not being able to see what's
inside the NGC file in ISE 4.x.
But that being said, will I be able to edit the NGC file somehow
(Doesn't sound like I can do that.), and will the promised ngc2edif
utility generate a clean EDIF file that can be converted to an NGO
netlist without problems?
Or will the ngc2edif generate an EDIF netlist only intended for
simulation purposes?
Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)
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