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
2017JanFebMarApr2017

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 23525

Article: 23525
Subject: Re: digital phase lock loop
From: sriley <sueriley@my-deja.com>
Date: Wed, 28 Jun 2000 18:34:22 GMT
Links: << >>  << T >>  << A >>
Thank you.

-Sue


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23526
Subject: Re: digital phase lock loop
From: sriley <sueriley@my-deja.com>
Date: Wed, 28 Jun 2000 18:36:02 GMT
Links: << >>  << T >>  << A >>
Thank you.

-Sue



In article <h4G$vNA8IiW5EwLN@matter200.demon.co.uk>,
  dmac <dmac@cutme.matter200.demon.co.uk> wrote:
>
> <extract>
> The digital Phase/Frequency Comparator is the same one shown in
>   Xilinx Application Note XAPP028 (Dec 2 1996)
>   http://www.xilinx.com/xapp/xapp028.pdf
> <end>
>
> I think this is the one from Nestor's original post - author is Peter
> Alfke - now where have I heard that name before :o)
>
> Dave
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23527
Subject: Re: Virtex power estimation
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Wed, 28 Jun 2000 12:11:13 -0700
Links: << >>  << T >>  << A >>
SteVe, (why the cap V?)

The power estimator was verified against many actual customer designs so
that the estimate was as good as we could get it.  The rules of thumb
approach that had been used was just too coarse, and the exact solution is
unimportant due to the variations in the process, and so on.  I have heard
no complaints about its estimations, and have recommended it to many
customers in order to help them with their power supplies, thermal
management, and bypass capacitor requirements.

Austin

SteVe wrote:

> Hello.
>
> I need a rough estimation of the power consumption of my design (the
> target device is a Xilinx XCV400). I've found a web page
> (http://www.xilinx.com/cgi-bin/powerweb.pl) with the Virtex Power
> Estimator developed by Xilinx. Is there somebody who used it? Is it a
> good choice? Or do you suggest another way to perform this estimation?
>
> Thanks,
> SteVe

Article: 23528
Subject: Re: How to do ...?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Thu, 29 Jun 2000 07:38:21 +1200
Links: << >>  << T >>  << A >>
The current crop of CPLD are not ideal for oscillators - too much
gain/delay
on pin=pin basis - this means it oscillates all right, but you can
unplug the
crystal :-)

 To construct a xtal osc, you need a 74HCU04 type gate, but you can get
these
as single gates in SOT23 region packages.
 Next you find that the sine wave from this needs squaring up, to drive
the CPLD..

 Philips have a 74HC9323A that is Osc+Small divider in SO8.

 Or use a XTAL module, and clock the CPLD from that.

 - jg

-- 
======= 80x51 Tools & IP Specialists  =========
= http://www.DesignTools.co.nz
Article: 23529
Subject: Xilinx Foundation Macro creation problem
From: qianz@my-deja.com
Date: Wed, 28 Jun 2000 19:49:15 GMT
Links: << >>  << T >>  << A >>
Here is my code, however when I used Xilinx Foudation to  synthesis  it is
successful however with one warning  Synthesizing...  Warning  L-1/C0 : #0
Warning: Latch inferred in design  'PWMv2' read with  'hdlin_check_no_latch'.
 (HDL-307)  Warning  L-1/C0 : #0 Warning: The part has fewer I/O ports	(125)
than that required by the design (129)	(FPGA-EXTERNAL-impl-pins-less)	0
error(s) 2 warning(s) found  Synthesis succesful (Warnings found)

                                When trying to create macro, it failed
                                Line 6
                                Wrong number of fields BUS

                                What is wrong thanks

                                --LIBRARY ieee;
                                library IEEE;
                                use IEEE.STD_LOGIC_1164.all;
                                use ieee.std_logic_arith.all;

  ENTITY PWMv2 IS  PORT(  frequency: in std_ulogic_vector(30 downto 0); 
dutyratio: in std_ulogic_vector(30 downto 0);  deadtime:  in
std_ulogic_vector(30 downto 0);  Control:  in std_ulogic_vector(30 downto 0);
 reset:  in std_logic;	clk:  in std_logic;  enable:  in std_logic; 
waveform1,waveform2: OUT std_logic  );	END PWMv2;

                                ARCHITECTURE version2 OF PWMv2 IS

  SIGNAL counter: integer;  signal MaxDutyRatio: integer;  signal
MaxDeadTime: integer;  signal MaxFreq: integer;  signal RealFreq :
std_ulogic_vector(30 downto 0);  signal RealDutyRatio : std_ulogic_vector(30
downto 0);  signal RealDeadtime : std_ulogic_vector(30 downto 0);  signal
RealControl : std_logic;

                                BEGIN

  CONV:process(RealDutyRatio,RealDeadTime,RealFreq)  begin  MaxDutyRatio <=
CONV_INTEGER(UNSIGNED(RealDutyRatio));	MaxDeadTime <=
CONV_INTEGER(UNSIGNED(RealDeadTime));  MaxFreq <=
CONV_INTEGER(UNSIGNED(RealFreq));  end process;

  PWM_Gen: PROCESS (counter,enable,MaxDutyRatio,MaxDeadTime)  BEGIN  if
enable='1' then  if counter < MaxDutyRatio then  waveform1 <='1';  else 
waveform1 <= '0';  end if;  if counter< MaxDutyRatio+MaxDeadTime then 
waveform2 <= '0';  else  waveform2 <= '1';  end if;  end if;  END PROCESS
PWM_Gen;


  Counter_Gen: process (clk,reset,enable,MaxFreq,RealControl)

  variable UpOrDown : std_logic;  -- Go Up or Go Down

  begin  if enable='1' then  if reset= '1' then  counter<= 0;  UpOrDown :=
'0';  elsif  rising_edge(clk)  then  if RealControl='0' then  --Synchronous
waveform  if counter= MaxFreq or counter = 0 then  UpOrDown := not UpOrDown; 
end if;  if UpOrDown='1' then  counter <= counter + 1;	--Waveform  goes up 
else  counter  <= counter - 1;	end if;  else  -- Asynchronous waveform 
counter <= counter + 1;  if counter = MaxFreq  then  counter <= 0;  end if; 
end if;  end if;  end if;  end process Counter_Gen;

  Freq_Gen:process(counter,reset,enable,frequency,dutyratio,de 
adtime,Control,RealControl,RealFreq)  begin  if enable='1' then  if RESET='1'
then  RealFreq <= frequency;  RealDutyRatio <= dutyratio;  RealDeadtime <=
deadtime;  RealControl <= Control(0);  else  if RealControl='1' then  if
counter=0 or  counter=CONV_INTEGER(UNSIGNED(RealFreq)) then  RealFreq <=
frequency;  RealDutyRatio <=  dutyratio;  RealDeadtime <=  deadtime; 
RealControl <= Control(0);  end if;  else  if counter=0 then  RealFreq <=
frequency;  RealDeadtime <=  deadtime;	RealDutyRatio <=  dutyratio; 
RealControl <=	Control(0);  end if;  end if;  end if;	end if;  end process
Freq_Gen;  END version2;



Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23530
Subject: PSN Generator
From: "Xanatos" <deletemeaoe_londonfog@hotmail.com>
Date: Wed, 28 Jun 2000 20:00:52 GMT
Links: << >>  << T >>  << A >>
Hey All,

I'm currently working on a block for this telco chip which will act as a
test generator.

The module can be selected to put out logic 1, logic 0, or Pseudo Random
data (serially for all cases, BTW).

The first 2 are very easy, and thanks to the Xilinx app note, the PRN
Generator seems to be easy as well....

The problem I'm having is that the module will be checking a stream to
compare it to the original at a later point in time. How does one go about
synchronizing the incoming serial stream [receiver] (the PRN case) to its
generator for comparison [I will be keeping an error count, but as stated, I
can't quite think of a way for it to "Hey! Start checking, this is the PSN
stream"]

Any code/links/discussion is appreciated.

Thanks,
Dave


Article: 23531
Subject: Re: PSN Generator
From: "Juan-Luis Ląpez RodrĄguez" <jl.lopez@REMOVETHISieee.org>
Date: Wed, 28 Jun 2000 23:46:14 +0200
Links: << >>  << T >>  << A >>
Hello Dave;

I posted an answer at about 20 march 1999 under thread "Re: Bit Error Rate
Test". If you can not find it in deja.com, let me know and I will mail it to
you or repost again.

Juan-Luis Lopez
Spain



Article: 23532
Subject: Re: PSN Generator
From: fliptron@netcom.com (Philip Freidin)
Date: 28 Jun 2000 22:12:12 GMT
Links: << >>  << T >>  << A >>
Turns out, this is really simple to do, assuming the generator and 
checker of the PRN stream is a serial design. This is true in all cases I 
know of, as it is an LFSR generator.

Your checker is the same as teh generator, and then you just match the 
received stream against the locally generated 'expected' stream. To 
synchronize them, put a mux in front of the local generator's input point 
( the point in the shiftregister where the xor-ed taps feed back in, the 
LSB), and when you want to synchronize to the incoming stream, just feed 
it into the shiftregister for as many clocks as there are bits in the 
shiftregister. Once this is done, flip the mux back to doing LFSR stuff, 
and it should now be in sync with the incomming data.

So for a 16 bit LFSR PRN generator, it will take 16 cycles to sync to the 
incomming test stream.

The only problem is if there is an error in the incomming stream while 
loading the local generator. If there is, then you will get insanely high 
error counts. If there was no error, then you will get the, hopefully 
low, expected error rates.

For extra smartness, you can continue to load the local shiftregister 
while monitoring what the local generator input would be (the output of 
the xor gate that is being ignored), and figure what the reported error 
rate would be if not in sync-ing mode. then switch from sync-ing to 
checking when teh error rate indicates you are in sync.


Philip Freidin

In article <UPs65.7579$W35.138494@news20.bellglobal.com>,
Xanatos <deletemeaoe_londonfog@hotmail.com> wrote:
>The problem I'm having is that the module will be checking a stream to
>compare it to the original at a later point in time. How does one go about
>synchronizing the incoming serial stream [receiver] (the PRN case) to its
>generator for comparison [I will be keeping an error count, but as stated, I
>can't quite think of a way for it to "Hey! Start checking, this is the PSN
>stream"]
>Any code/links/discussion is appreciated.
>Dave

Article: 23533
Subject: Re: PSN Generator
From: "Xanatos" <deletemeaoe_londonfog@hotmail.com>
Date: Wed, 28 Jun 2000 22:21:28 GMT
Links: << >>  << T >>  << A >>

"Juan-Luis Ląpez RodrĄguez" <jl.lopez@REMOVETHISieee.org> wrote in message
news:395a6fd4_2@news.arrakis.es...
> Hello Dave;
>
> I posted an answer at about 20 march 1999 under thread "Re: Bit Error Rate
> Test". If you can not find it in deja.com, let me know and I will mail it
to
> you or repost again.
>
> Juan-Luis Lopez
> Spain

Hi Juan-Luis;

Thanks for the reply. I can't seem to locate it on deja, so if you email it
to me, please do. (Or post it)

Email: aoe_londonfog@hotmail.com

Thanks again,
Dave


Article: 23534
Subject: Re: IDE-Interface for FPGA
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 28 Jun 2000 23:44:49 GMT
Links: << >>  << T >>  << A >>
Bryan Williams <nospamformethanks@nowhere.com> writes:

>On Sun, 25 Jun 2000 17:33:57 +0200, Claas Richter <clri@gmx.de> wrote:

>>Hello!
>>
>>Does anyone have any experience in the use of FPGAs for connecting to
>>the IDE-Bus?
>>
>>Or has anybody implemented an IDE/ATA-Bus-Interface for FPGAs ??
>>I need it to read and write to a harddisk.

The IDE bus is really the AT/ISA data bus extended through the cable,
with the IO address decoded.  It is a little, but just a little, more
than that.  That said, the other posts should supply the details.

-- glen
Article: 23535
Subject: Re: PSN Generator
From: murray@pa.dec.com (Hal Murray)
Date: 29 Jun 2000 02:49:02 GMT
Links: << >>  << T >>  << A >>

> For extra smartness, you can continue to load the local shiftregister 
> while monitoring what the local generator input would be (the output of 
> the xor gate that is being ignored), and figure what the reported error 
> rate would be if not in sync-ing mode. then switch from sync-ing to 
> checking when teh error rate indicates you are in sync.

Check out the term Self Synchronizing Scrambler in the communications
literature or text.  ATM over SONET uses one.

It's one of those "of course" ideas after you see it.  The idea is to
leave your mux in the load position all the time.  The disadvantage
is that a single error bit turns into a multiple bit error.  (I think
you get the CRC generator polynomial out.)

Suppose you setup a system using a Self Synchronizing Scrambler and
send a data pattern of all 0s.  Now the receiver knows what the data
pattern should be but the bit pattern on the link will be the output
of the LFSR.  If the error rate is low, you can count error bits and
divide by the number of 1 bits in the polynomial.

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 23536
Subject: Re: Xilinx XC5200 implementation with F2.1i
From: Jeff Graham <jeff.graham@paradise.net.nz>
Date: Thu, 29 Jun 2000 19:02:20 +1200
Links: << >>  << T >>  << A >>
Hi

We have exactly the same problem. There doesn't appear to be a solution,
and we still run dual boot PCs with NT and 3.11 on them to support our
designs in the XC5200 series. 

I did look at migrating the designs to the Spartan family but I seem to
need a an XCS20 to hold what fits comfortably in an XC5204, so there was
not cost saving to be had.

If you are using Foundation, whatever you do, don't use the Foundation
Project > copy feature in 1.5i to take a copy of your Foundation 6.0
format project. I did this to see how 1.5i would handle an existing
design. While it copies over the top level schematics to a new project
directory, it leaves any custom macros and libraries in the old project
directories but converts them to the 1.5i format =- net result when you
go back to Foundation 6.0 to do some work, all your own user defined 
libraries are unable to be read, though the standard Xilinx libraries
are unaffected. (thank god for back ups.)


Jeff Graham

Rascal wrote:
> 
> Has anyone of you ever tried to implement a XC5202/5206 device with
> Foundation 2.1i ( or 1.5, too) ? The software seems to have BIG problems in
> routing designs based on these devices; the old XACT router, running with
> Windows 3.11, on the other hand, could manage the same design without
> excessive effort.
> Actually, I still have to use that older implementation software (and then
> keep a dedicated PC with Windows 3.11 installed on it) to develop/update my
> XC5200 based projects, and this isn't really that comfortable. F2.1i
> tools,in most cases, can't succeed in the PAR step for simple designs, too.
> I talked to two Xilinx field application engineers about this matter. One of
> them told me that this is a known problem of implementation tools based on
> M1 engine, so I have necessarily to use old XACT for XC5200 devices. The
> other one told me that F2.1 router is actually slightly worse than XACT for
> XC5200 but should work anyway: in my case the problem should reside on
> netlist generation.
> Does anyone has any additional information or, better, a solution ?
> 
> Thanx in advance.
Article: 23537
Subject: Free PCI core
From: Armin Mueller <armin.mueller@stud.uni-karlsruhe.de>
Date: Thu, 29 Jun 2000 09:19:27 +0200
Links: << >>  << T >>  << A >>
Hello,

is there some free PCI 33/32 core available I'm not aware of, besides

* the comp.arch.fpga faq
* Xilinx
* Altera
* Cypress
* opencores.org

Thanks
Armin
Article: 23538
Subject: Re: 500 million transistor FPGA's
From: Emil Blaschek <emil.blaschek@siemens.at>
Date: Thu, 29 Jun 2000 11:49:06 +0200
Links: << >>  << T >>  << A >>
I have made big gate-array designs and do now a design in 
VertexE 1000

I see 3 main-problems.

a) missing timing-closure 
b) no good floor-planner 
   --> unpredictable results at synthese + fitteing, 
   --> Loss of Speed ( design brings only 50-75% of possible speed )
   --> chaotic placing of functions 

c) no incremental synthesis and fitting.
   --> so the synthese takes 80min,
          the fitter   takes 80 h , with incremental
          optimisation and 5 attempts   

and some lower prior problems. 

d) constrainin of multi-cycle paths 
   --> unnecessary Gates 

e) hierarchical floorplanning 
   you typically have about 50 instances to plan

f) time bugeding at bottom- up synthese 

i know a lot of good developers work on these problems, 
but they have to solve them very soon, so you have a 
good chance for a high - speed design in a VertexE 2000.

MfG E.Blaschek
Article: 23539
Subject: RE: PSN Generator
From: "Juan-Luis Lopez" <jl.lopez@REMOVETHIS.ieee.org>
Date: Thu, 29 Jun 2000 13:04:58 +0200
Links: << >>  << T >>  << A >>
Dear Dave;

While I try to find the old posting ;-) you can look at an example of this
within my final thesis at
http://www.arrakis.es/~jl.r/pfc/index.htm

The thesis described a test instrument for E1 (2048kbit/s) telecomm signals,
transmitter and receiver. The design was fully tested and 100% working.

For historical reasons is password protected, but username="user" and
password "1234" will work.

Sorry, the body of the document with all the explanations is in spanish, but
you can look at some of the FPGA schematics at
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__T_PRBS (PSN generator)
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__R_PRBS (PSN receiver)

The PRBS signal was one of the specified in UIT-T recommendation O.152,
length 2^11-1.

D      is the input data
CK     is the input clock
CE     is the input clock enable
D_SYNC is the output that shows the synchronism state of the receiver.
       Low level means synchronised, high means out of synch.
E_BIT  is the output bit error signal (to error counter)
I1S    is the input 1Hz pulse to reset error integration for loss of synch.
       Has to be in high state only one bit time.

Please note that I had lots of free space within the FPGA, so the error
counter for the loss of sync decision (L21) was implemented in the FPGA. A
more usual aproach is to implement it in software, sharing the values readed
at the bit error counter attached externally to E_BIT output. The reason is
that loss of sync needs a long time error integration, and a long counter in
order to avoid overflow.

This circuit is free from error multiplication problem while measuring and
from false synch due to errors while synchronising. It is also immune to
false synch when receiving "all zeros" or "all ones" input signals
(depending on the polarity of the PRBS) thanks to L2. It does not loss synch
in presence of bursts of errors.

You can decrease the probability of false synch in presence of random input
signals by making L22 larger. The probability of the circuit shown were
1/(2^5 -11).

Some of the schematics were commented in english, but the above ones had no
comments at all :-(

Hope this helps in the meantime.

Juan-Luis Lopez
Spain





Article: 23540
Subject: RE: PSN Generator
From: "Juan-Luis Lopez" <jl.lopez@REMOVETHIS.ieee.org>
Date: Thu, 29 Jun 2000 13:14:27 +0200
Links: << >>  << T >>  << A >>
Dear Dave;

While I try to find the old posting ;-) you can look at an example of this
within my final thesis at
http://www.arrakis.es/~jl.r/pfc/index.htm

The thesis described a test instrument for E1 (2048kbit/s) telecomm signals,
transmitter and receiver. The design was fully tested and 100% working.

For historical reasons is password protected, but username="user" and
password "1234" will work.

Sorry, the body of the document with all the explanations is in spanish, but
you can look at some of the FPGA schematics at
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__T_PRBS (PSN generator)
http://www.arrakis.es/~jl.r/pfc/910refer/refer.htm#A__R_PRBS (PSN receiver)

The PRBS signal was one of the specified in UIT-T recommendation O.152,
length 2^11-1.

D      is the input data
CK     is the input clock
CE     is the input clock enable
D_SYNC is the output that shows the synchronism state of the receiver.
       Low level means synchronised, high means out of synch.
E_BIT  is the output bit error signal (to error counter)
I1S    is the input 1Hz pulse to reset error integration for loss of synch.
       Has to be in high state only one bit time.

Please note that I had lots of free space within the FPGA, so the error
counter for the loss of sync decision (L21) was implemented in the FPGA. A
more usual aproach is to implement it in software, sharing the values readed
at the bit error counter attached externally to E_BIT output. The reason is
that loss of sync needs a long time error integration, and a long counter in
order to avoid overflow.

This circuit is free from error multiplication problem while measuring and
from false synch due to bit errors while synchronising. It is also immune to
false synch when receiving "all zeros" or "all ones" input signals
(depending on the polarity of the PRBS) thanks to L2. It does not loss synch
in presence of shorts bursts of errors.

You can decrease the probability of false synch in presence of random input
signals by making L22 larger. The implementation shown has a probability of
1/(2^5 -11) for each 2^5 (32) bits received in sequence.

Some of the schematics were commented in english, but the above ones had no
comments at all :-(

Hope this helps in the meantime.

Juan-Luis Lopez
Spain



Article: 23541
Subject: Re: Free PCI core
From: strez <jeff_streznetckyNOjeSPAM@yahoo.com.invalid>
Date: Thu, 29 Jun 2000 04:29:41 -0700
Links: << >>  << T >>  << A >>
I think Lucent offers a FPGA with an embedded PCI core -- If I
recall correctly it is in the Series 3+ devices.

Hope this helps.

-Jeff


-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Article: 23542
Subject: Maximum Speed on obtainable on FPGAs?
From: "Jimmy" <j_robby@hotmail.com>
Date: Thu, 29 Jun 2000 12:54:52 +0100
Links: << >>  << T >>  << A >>
Hi Folks,

Having a particular FPGA in hand (with a specific speed grade), How can
someone assess the performance of a particular design. In other terms, how
can you know the maximum obtainable speed for a particular design. The
question might seem vague but I will illustrate:
Say you want to do a bit serial convolution on an XC4000 chip. What is the
best speed you can get. I can see that for a heavily pipeline design, you
can assume that the maximum delay is the CLB delay (FF or LUT). How about
the routing? Is it fair to assume that in a good design the routing delay is
equal to the logic delay and so You can say that the best period time (the
minimum) you can get is 2*CLB_delay??

Any input is much appreciated.

Cheers.


Article: 23543
Subject: Re: Xilinx XC5200 implementation with F2.1i
From: "Rascal" <spambuster_ravasioc@tin.it>
Date: Thu, 29 Jun 2000 14:25:17 +0200
Links: << >>  << T >>  << A >>
>We have exactly the same problem. There doesn't appear to be a solution,
>and we still run dual boot PCs with NT and 3.11 on them to support our
>designs in the XC5200 series.

....

>libraries are unable to be read, though the standard Xilinx libraries
>are unaffected. (thank god for back ups.)
>


I've experimented that, too !   Thank god for back ups.
I've also found out that in F1.4 there is the option to archive a project
but ther isn't any to restore it.
Again, thank god for back ups.


Thanks for your reply, anyway.


Article: 23544
Subject: Re: PSN Generator
From: "Xanatos" <deletemeaoe_londonfog@hotmail.com>
Date: Thu, 29 Jun 2000 13:16:02 GMT
Links: << >>  << T >>  << A >>
Thanks Philip, Hal and Juan!

I think I have a good basis of what to do next. Now is just a matter of
implementing it  ;)

Cheers,
Dave


Article: 23545
Subject: PCI with Xilinx controller
From: "Dan" <daniel.deconinck@sympatico.ca>
Date: Thu, 29 Jun 2000 13:20:07 GMT
Links: << >>  << T >>  << A >>
Hello,

When PCI slots are unused, some motherboards disable the PCI CLK to that
particular slot. (I just learned this on the pcisig.com mail reflector)

I understand they use the 'Card Present' signal to determine if the slot is
populated.

Is it possible that some mother boards incorrectly assume that a slot is
empty if it contains a FPGA based contoller which takes some time to
initialize after power up.

Sincerely
Daniel DeConinck



Article: 23546
Subject: Re: Maximum Speed on obtainable on FPGAs?
From: "Pete Dudley" <padudle@sandia.gov>
Date: Thu, 29 Jun 2000 07:21:38 -0600
Links: << >>  << T >>  << A >>
Route delay = CLB setup time would be a good top speed estimate for the
Xilinx parts.

If you have the tools, I would enter a small design and compile it. The
static timing report tool will then tell you the top speed.

"Jimmy" <j_robby@hotmail.com> wrote in message
news:8jfd9d$o58$1@news.qub.ac.uk...
> Hi Folks,
>
> Having a particular FPGA in hand (with a specific speed grade), How can
> someone assess the performance of a particular design. In other terms, how
> can you know the maximum obtainable speed for a particular design. The
> question might seem vague but I will illustrate:
> Say you want to do a bit serial convolution on an XC4000 chip. What is the
> best speed you can get. I can see that for a heavily pipeline design, you
> can assume that the maximum delay is the CLB delay (FF or LUT). How about
> the routing? Is it fair to assume that in a good design the routing delay
is
> equal to the logic delay and so You can say that the best period time (the
> minimum) you can get is 2*CLB_delay??
>
> Any input is much appreciated.
>
> Cheers.
>
>


Article: 23547
Subject: Re: Free PCI core
From: bkk411@hotmail.com
Date: Thu, 29 Jun 2000 15:28:46 GMT
Links: << >>  << T >>  << A >>
In article <395AF87F.D4C44FDB@stud.uni-karlsruhe.de>,
  Armin Mueller <armin.mueller@stud.uni-karlsruhe.de> wrote:
> Hello,
>
> is there some free PCI 33/32 core available I'm not aware of, besides
>
> * the comp.arch.fpga faq
> * Xilinx
> * Altera

I didn't know Xilinx gives away their PCI core. Last time I checked
they wanted $15K + royaltis ...
Same for Altera - don't remember the price ....

Would love to see a *decent* e.g. synthesisable and complient
free core !!!

> * Cypress
> * opencores.org
>
> Thanks
> Armin

bkk


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 23548
Subject: Re: Maximum Speed on obtainable on FPGAs?
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 29 Jun 2000 11:37:04 -0400
Links: << >>  << T >>  << A >>
This may give you an estimate for a "theoretical" speed, I would not use
it for any design that I did not understand fully. Both the "one LUT"
assumption and the "short routing delay" assumption will be invalidated
by specific items in many designs. 

For example, if you are designing a finite state machine (FSM) to
control some circuit, you may have too many inputs to a single state to
be able to define the next state function in a single CLB (two linked
LUTs). This often happens. Then if you have any long nets with high fan
out, such as a clock enable, you may have to allow two or three LUT
delays to distribute this signal. 

Pipelining can help, but it can not be used when you need to have
feedback in the path, such as in a FSM. So it is best to know enough
about your design to be able to at least determine the number of inputs
to every logic function. 


Jimmy wrote:
> 
> Hi Folks,
> 
> Having a particular FPGA in hand (with a specific speed grade), How can
> someone assess the performance of a particular design. In other terms, how
> can you know the maximum obtainable speed for a particular design. The
> question might seem vague but I will illustrate:
> Say you want to do a bit serial convolution on an XC4000 chip. What is the
> best speed you can get. I can see that for a heavily pipeline design, you
> can assume that the maximum delay is the CLB delay (FF or LUT). How about
> the routing? Is it fair to assume that in a good design the routing delay is
> equal to the logic delay and so You can say that the best period time (the
> minimum) you can get is 2*CLB_delay??
> 
> Any input is much appreciated.
> 
> Cheers.

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 23549
Subject: Re: Maximum Speed on obtainable on FPGAs?
From: bkk411@hotmail.com
Date: Thu, 29 Jun 2000 15:42:05 GMT
Links: << >>  << T >>  << A >>


In my oppention, there is now good way to determin how fast
a design might be able to run in a certain FPGA. You can do
a WAG (Wild Ass Guess ;*) by doubling the CLB delay, but it
will be very inaccurate. There are to many factors that will
influence the delay. Even synthesis tools can not accuratley
report the timing (however they are typically over conservative).

If you have a havily pipelined design, it will help, but still
not guarantee that it will run fast. If the routing is congested
or you have large busses going across the chip, you will suffer ...

Best is always trial and error, specially if you want to run
really fast. I usually end up going through my design and replace
as many obvious premitives as I can with coregen parts. That most
of the time helps, specially if you have large databuses, you can
keep the routing somewhat local on certain parts (muxes, adders etc.).

Good Luck,
bkk

In article <8jfd9d$o58$1@news.qub.ac.uk>,
  "Jimmy" <j_robby@hotmail.com> wrote:
> Hi Folks,
>
> Having a particular FPGA in hand (with a specific speed grade), How
can
> someone assess the performance of a particular design. In other
terms, how
> can you know the maximum obtainable speed for a particular design. The
> question might seem vague but I will illustrate:
> Say you want to do a bit serial convolution on an XC4000 chip. What
is the
> best speed you can get. I can see that for a heavily pipeline design,
you
> can assume that the maximum delay is the CLB delay (FF or LUT). How
about
> the routing? Is it fair to assume that in a good design the routing
delay is
> equal to the logic delay and so You can say that the best period time
(the
> minimum) you can get is 2*CLB_delay??
>
> Any input is much appreciated.
>
> Cheers.
>
>


Sent via Deja.com http://www.deja.com/
Before you buy.


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
2017JanFebMarApr2017

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