Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search

Messages from 46750

Article: 46750
Subject: Re: Synthesis problem, my inputs are never used?
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sat, 07 Sep 2002 09:34:13 +0100
Links: << >>  << T >>  << A >>


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
Subject: Re: why the need for HIGH speed design?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 7 Sep 2002 11:17:02 +0200
Links: << >>  << T >>  << A >>
"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
Falk




Article: 46752
Subject: Re: XCR3384XL availability
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Sat, 7 Sep 2002 11:25:42 +0200
Links: << >>  << T >>  << A >>
"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
Falk




Article: 46753
Subject: symplicity conv_integer problem
From: "Nikhil Bhatia" <rite2nikhil@ieee.org>
Date: Sat, 7 Sep 2002 05:18:06 -0700
Links: << >>  << T >>  << A >>
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: 46754
(removed)


Article: 46755
Subject: PCI bus problems
From: v_ralev@yahoo.com (Vladimir Ralev)
Date: 7 Sep 2002 06:21:43 -0700
Links: << >>  << T >>  << A >>
Hi 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
Subject: Re: why the need for HIGH speed design?
From: hristostev@yahoo.com (hristo)
Date: 7 Sep 2002 07:20:27 -0700
Links: << >>  << T >>  << A >>
sorry john-h if my reply seemed rude. i am still struggling to improve
my english skills....

Article: 46757
Subject: scan insertion is easily feasible
From: hristostev@yahoo.com (hristo)
Date: 7 Sep 2002 08:12:50 -0700
Links: << >>  << T >>  << A >>
<<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

thanks

Article: 46758
Subject: Fault tolerant FPGA design
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 7 Sep 2002 12:13:44 -0700
Links: << >>  << T >>  << A >>
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

Article: 46759
Subject: Re: Metastability numbers
From: Phil Hays <SpamPostmaster@attbi.com>
Date: Sat, 07 Sep 2002 21:01:06 GMT
Links: << >>  << T >>  << A >>

Thank you, Peter.  This information is valuable.


-- 
Phil Hays

Article: 46760
Subject: Re: Fault tolerant FPGA design
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 07 Sep 2002 21:13:19 GMT
Links: << >>  << T >>  << A >>
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 Naderi


Article: 46761
Subject: Re: Metastability numbers, even better!
From: Peter Alfke <palfke@earthlink.net>
Date: Sat, 07 Sep 2002 21:55:15 GMT
Links: << >>  << T >>  << A >>

--------------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 Applications



Article: 46762
Subject: Re: Fault tolerant FPGA design
From: Ray Andraka <ray@andraka.com>
Date: Sat, 07 Sep 2002 23:29:22 GMT
Links: << >>  << T >>  << A >>
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: 46763
Subject: Re: Neural hardware containing many neurons but very simple computation
From: nnadal@terra.es (=?ISO-8859-1?Q?Narc=EDs_Nadal?=)
Date: 7 Sep 2002 16:38:41 -0700
Links: << >>  << T >>  << A >>
It'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
Subject: Re: Fault tolerant FPGA design
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Sun, 08 Sep 2002 00:03:24 GMT
Links: << >>  << T >>  << A >>
(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
Subject: Re: Metastability numbers
From: rk <stellare@NOSPAMPLEASE.erols.com>
Date: 8 Sep 2002 04:12:34 GMT
Links: << >>  << T >>  << A >>
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: 46766
Subject: OrCAD 9.2 Capture Part Library For SpartanXL&18VXX
From: BasePointer <mfide@softhome.net>
Date: Sat, 7 Sep 2002 21:15:02 -0700
Links: << >>  << T >>  << A >>
Hi,
I look for Orcad 9.2 Capture(Schematic) Library for XCS10XL-PC84(SpartanXL) and XC18V256PC20 PROM.

Thanks

Article: 46767
Subject: Re: Metastability numbers, even better!
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Sun, 08 Sep 2002 11:01:32 +0100
Links: << >>  << T >>  << A >>


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
Subject: Re: Fault tolerant FPGA design
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 8 Sep 2002 06:25:19 -0700
Links: << >>  << T >>  << A >>
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 Naderi

Article: 46769
Subject: Re: Fault tolerant FPGA design
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 8 Sep 2002 06:45:49 -0700
Links: << >>  << T >>  << A >>
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, 1759

Article: 46770
Subject: Re: Fault tolerant FPGA design
From: naderimisc@yahoo.com (Masoud Naderi)
Date: 8 Sep 2002 06:52:44 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: I2C BUS
From: Thomas Wambera <thomas@wambera.de>
Date: Sun, 08 Sep 2002 16:07:04 +0200
Links: << >>  << T >>  << A >>

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.com

Article: 46772
Subject: Re: Fault tolerant FPGA design
From: "Frank Andreas de Groot" <nospam@nospam.com>
Date: Sun, 08 Sep 2002 14:10:03 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Metastability numbers, even better!
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 08 Sep 2002 15:51:27 GMT
Links: << >>  << T >>  << A >>


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 Applications



Article: 46774
Subject: Re: Viewing Xilinx netlist
From: Kevin Brace <kevinbraceusenet.4killspam@killspam4.hotmail.com>
Date: Sun, 08 Sep 2002 12:57:14 -0500
Links: << >>  << T >>  << A >>


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:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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

Custom Search