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 38075

Article: 38075
Subject: Re: Problem/Question about the timing report on Xilinx ISE 4.1
From: Kenneth <small__lee@hotmail.com>
Date: Fri, 04 Jan 2002 15:59:42 +0800
Links: << >>  << T >>  << A >>
Hi Hamish,

hamish@cloud.net.au wrote:
> 
> Kenneth <kenneth.lee@terapower.com.hk> wrote:
> > Within the design, it is supposed the the timing constraint for
> > the logic using the clk_4x should be 5ns.  However, from the
> > timing report it showed a strange result.  It shows that the
> > requirement is 2.5ns rather than the 5ns, and the timing of
> > the rising edge of the clk_4x signal is very strange too.
> 
> > Do anyone have idea about this problem?  Thanks in advance.
> 
> Could you post your UCF and possibly also your code?

In UCF, I set the timing constraint for the 50MHz input clock
(bclk_in) which is 

NET "bclk_in" TNM_NET = "bclk_in";
TIMESPEC "TS_bclk_in" = PERIOD "bclk_in" 20 ns HIGH 50 %;

But I feel stange that why for the clock signal clk_4x,
the timing report shows that 

Source Clock:         clk_4x rising at 7.500ns
Destination Clock:    clk_4x rising at 10.000ns

while it should be 5ns between 2 rising edges.
 
> By the way you might encounter a lot of clock jitter with
> this arrangement. Especially with two DCMs in series. The
> best approach would be to have a 200MHz clock input pin
> and to create 50 and 100MHz clocks from that. If you have
> Virtex-II you could use the CLKFX (synthesized output)
> and the CLK2X on a single DCM instead of two in series.

Actaully I am using Virtex-II 1000 decive.  However, due to
the limitions of the Engineering Sample(I am using it....),
it is not recommanded to use the CLKFX to produce the 4X clock
from the 50MHz clock input directly.  As a result, I need to use
2 DCMs to achieve the 4X clock signal.

> regards
> Hamish
> --
> Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Thanks.

Regards,
Kenneth

Article: 38076
Subject: Re: PCI Solution: LogiCore?
From: Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com>
Date: Fri, 04 Jan 2002 02:58:27 -0600
Links: << >>  << T >>  << A >>
A few months ago, there was a guy who claimed that he figured out how to
synthesize (technically synthesizing is not the correct word, processing
a netlist should be correct) Xilinx's PCI LogiCORE with XST.
To retrieve the past posting I am talking about, try doing a Google
Groups search (http://groups.google.com/groups?group=comp.arch.fpga) for
comp.arch.fpga "only" with the following titles.

Xilinx PCI core and XST

Xilinx XST vs FPGA Express? 



The guy said he will tell you how to do it if you sent him an E-mail (I
suppose it would have been better if he posted more information about it
to the newsgroup).
        Before you get Xilinx's PCI LogiCORE licensed, you may want to
play around with a free evaluation version of PCI LogiCORE.
To do so, do a search of their website with keywords, "IP Evaluation".
The evaluation version should come with a VHDL netlist, so you can throw
this into XST and see what happens.
Although I am not sure, I believe the evaluation version doesn't come
with a UCF file to constrain the LUT locations, so even if you can
synthesize it correctly with XST, it will likely not meet 33MHz PCI's
setup time (Tsu < 7ns) requirement.
I guess that's how Xilinx get people to license it after the evaluation.
If you know how to use Floorplanner to force a LUT to a certain location
of the chip, you may be able to floorplan it to meet 33MHz PCI's setup
time requirement.




Kevin Brace (don't respond to me directly, respond within the newsgroup)




Peter van Beek wrote:
> 
> Hello everybody,
> 
> Currently I am doing some investigation for an appropriate PCI
> solution. We want to implement an application that is able to send 32
> bits data (with a rate of 25 Mhz) to the PCI bus. This will be done by
> means of an FPGA, using the VHDL design flow. We're doing some
> evaluation with a Xilinx Spartan II PCI demo board. The VHDL design
> flow is supported by WebPACK ISE.
> 
> The most common way turns out to be using LogiCore. Unfortunaly
> synthesizing LogiCore is not supported by ISE. I don't have much
> insight in this process, can somebody tell me what exactly happens
> during synthesizing. Also suggestions about which compiler to use are
> welcome.
> 
> Are there any other options except using LogiCore? Maybe an off the
> shelf solution that already contains a stand alone PCI interface
> (maybe at other companies).
> 
> Best regards,
> 
> Peter van Beek
> design engineer
> Zevenaar Elektronica en Sensoren
> Arnhem, The Netherlands
> (31)263653393

Article: 38077
Subject: Re: asic vs. fpga
From: thomas.stanka@tesat.de (Thomas Stanka)
Date: 4 Jan 2002 09:40:53 GMT
Links: << >>  << T >>  << A >>
HI,

Peter Alfke <palfke@earthlink.net> wrote:
> Matthias Weber wrote:
>>> i am searching for a link, book, university lessons explaining the
>> architecture of asic and fpga and their differences. 
>
> Matthias, the differences are not so much in the architecture as in the
> economics. 

ASIC means IC for a specific purpose. FPGA is a posibility to do so.
Normaly you mean cellbased designs when talking about ASIC, but FPGA are 
also ASIC. Peter Alfke means cellbased (I guess *g*). 
The architecture of FPGA is major devided in two Families RAM based like 
Xilinx and antifusebased like Actel. See their homepages for architectural 
details.
 
> That's why more and more designers prefer the FPGA solution that does
> not have these high up-front costs and long waiting time, and can be
> bought in any quantity at any time, and be modified ad infinitum. 
> State-of-the-art ASICs have very high NRE costs, while old-fashioned
> ASICs are cheaper, but offer no real performance advantage over FPGAs.
> I admit to being biased, but the trend is clearly in favor of FPGAs. 

Another point is the size of your design. First there is a limit to maximum 
size available for FPGA, than you come very cheap using really small FPGA.
So a rule of thump says the more gates you need, the more your like to use 
cellbased. 
The number of identical ASICs is also very important, Depending on who you 
talk with, and what ASICs they need, you get something between 50 and a few 
thousand ACSICs as the border to switch from ASIC to FPGA.

bye Thomas

-- 
Thomas Stanka BC/EMD4
Space Communications Systems
Tesat Spacecom GmbH & Co KG
thomas.stanka@de.bosch.com

Article: 38078
Subject: Re: PCI Solution: LogiCore?
From: p.van.beek@zes.nl (Peter van Beek)
Date: 4 Jan 2002 02:00:34 -0800
Links: << >>  << T >>  << A >>
Thanks for replying,

We want to stick to the 32 bit, 33 Mhz bus. Our data is not sustained
but consist of bursts that can vary between 16 Kbyte and 64 KByte. We
consider using extern memory to avoid time critical situations. Any
suggestions regarding this matter?

Regards,
Peter

Article: 38079
Subject: Re: Problem/Question about the timing report on Xilinx ISE 4.1
From: hamish@cloud.net.au
Date: 04 Jan 2002 10:43:54 GMT
Links: << >>  << T >>  << A >>
Kenneth <small__lee@hotmail.com> wrote:
> In UCF, I set the timing constraint for the 50MHz input clock
> (bclk_in) which is 

> NET "bclk_in" TNM_NET = "bclk_in";
> TIMESPEC "TS_bclk_in" = PERIOD "bclk_in" 20 ns HIGH 50 %;

Kenneth, possibly PAR and or TRCE is making a mistake when propagating
your PERIOD specific through the two DCMs. You could put a PERIOD
constraint on the clk_4x signal directly. Hopefully that will override
the automatically generated constraint.

> But I feel stange that why for the clock signal clk_4x,
> the timing report shows that 

> Source Clock:         clk_4x rising at 7.500ns
> Destination Clock:    clk_4x rising at 10.000ns

> while it should be 5ns between 2 rising edges.

Unfortunately I don't understand why it shows you clk_4x rising
at 7.5 and 10ns. TRCE's behaviour is sometimes very mysterious!


regards

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

Article: 38080
Subject: Re: Spartan-IIE interfacing issues
From: Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com>
Date: Fri, 04 Jan 2002 04:55:01 -0600
Links: << >>  << T >>  << A >>
Why not use an older Spartan-II instead?
It supports 5V tolerant I/Os.



Kevin Brace (don't respond to me directly, respond within the newsgroup)

Article: 38081
Subject: Re: Spartan-IIE interfacing issues
From: Rick Filipkiewicz <rick@algor.co.uk>
Date: Fri, 04 Jan 2002 12:09:15 +0000
Links: << >>  << T >>  << A >>


Doug wrote:

> I need to interface some old-fashioned 5V logic to a Spartan-IIE FPGA,
> which has 3.3V I/O.
>
> I know I could use something like a 74LVX3245, but apparently it can
> be safely done with resistors as well.  In the appnote "Spartan-IIE
> Family:  Frequently Asked Questions" (Xilinx document #FAQ100), it
> says:
>
> "The Spartan-IIE is 3.3V I/O compatible and will only support 5.0V
> I/Os when an external pull-up resistor is used."
>
> ...and that's all the info I've been able to find so far.
>

and it is, in fact, slightly misleading. There are 2 parts to getting 5V
compatibility with 3V3 devices:

o Output: The devices receiving signals from the FPGA have to have a
Vih(min) <= the FPGA's Voh(min). For most modern TTL-compatible devices
this is o.k. but you'll have to be careful if there are any true CMOS 5V
parts. This is sort of where the ``pull-up'' comes in but there are
better/cleaner ways of doing this.

o Input: Here the problem is that no Virtex class devices except for the
original Virtex familiy are 5V tolerant. There are 2 approaches you can
take to this:

- Xilinx state that a 100R between the 5V source and the FPGA pin is
sufficient.

- Use QuickSwitch type buffers between the 5V domain and the FPGA.

For something like 5V PCI the QS approach is much less electrically
intrusive although it costs more in PCB real estate. These magic devices
are really a bunch of FET switches whose impedance is about 5-10R (with a
max Tpd of 250ps) until the driving side gets to about 0V7 below VCC. From
then on the impedance increases very steeply. For the 5V QS parts the
trick is/was to power them from a supply in the 3V3-3V9 range. There are
now 3V3 versions of these parts but BE WARNED: They come in 2 flavours -
clamping and non-clamping.



Article: 38082
Subject: Re: ACTEL SX-A serie and ROM implementation ...
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 4 Jan 2002 13:19:21 +0100
Links: << >>  << T >>  << A >>
"Markus Meng" <meng.engineering@bluewin.ch> schrieb im Newsbeitrag
news:aaaee51b.0201032258.66a971cd@posting.google.com...
> Hi all,
>
> By the way actel has some nice FPGA's in the FBGA package. The 256FBGA is
> really small and well suited for PCMCIA cards. Does Xilinx or Altera

If you mean a 256 balls package with 1 mm pitch, then yes, there are lots of
different FPGAs available from Xilinx.

--
MfG
Falk





Article: 38083
Subject: Re: A Fast counter in VHDL?
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 4 Jan 2002 13:28:32 +0100
Links: << >>  << T >>  << A >>
"Jason Berringer" <jberringer@trace-logic.com> schrieb im Newsbeitrag
news:IJ5Z7.12027$A67.3131096@news20.bellglobal.com...

>
> library ieee;
> use ieee.std_logic_1164.all;
> use ieee.std_logic_unsigned.all;
>
> entity counter is
>  generic(width : integer := 32);
>  port(
>   clk   : in  std_logic;
>   cnt_clr  : in  std_logic;
>   cnt_enable : in  std_logic;
>   reset  : in  std_logic;
>   cnt_out  :   out std_logic_vector(width-1 downto 0)
>   );
> end counter;
>
> architecture RTL_counter of counter is
>
> signal countL : std_logic_vector(cnt_out'range);
>
> begin
>
> P1: process (reset, cnt_clr, clk, cnt_enable) begin
>  if (reset = '1' or cnt_clr = '0') then
>   countL <= (others => '0');
>  elsif (rising_edge(clk)) then
>   if (cnt_enable = '1') then
>    countL <= countL + 1;
>   end if;
>  end if;
> end process;
>
> cnt_out <= countL;
>
> end RTL_counter;

As far as I can see, this simple  ce'ed counter should run @100 Mhz, even in
a Spartan-II-5. Just compile the counter alone and look at the timing
report. It should clearly say tha clk can be faster than 10ns. Often, the
timing analyzer is doing wiered things (not at all, false paths are more the
problem here) and it looks like the circuit is too slow.

--
MfG
Falk





Article: 38084
Subject: Re: PCI Solution: LogiCore?
From: "Austin Franklin" <austin@da87rkroom.com>
Date: Fri, 4 Jan 2002 09:22:50 -0500
Links: << >>  << T >>  << A >>
> We want to stick to the 32 bit, 33 Mhz bus. Our data is not sustained
> but consist of bursts that can vary between 16 Kbyte and 64 KByte. We
> consider using extern memory to avoid time critical situations. Any
> suggestions regarding this matter?

Is your data rate really 100M bytes/sec...  If so, I do not believe you will
be able to sustain this rate.  As you suggest, putting buffer memory on the
board, so you reduce your PCI bus requirement, may be your only solution if
you want to be on a 32/33 PCI bus.

Are you transfering to system memory?  Are you the only activity that will
be going on?  Is this a dedicated system, or a standard Windows based PC?




Article: 38085
Subject: Re: A Fast counter in VHDL?
From: brad@tinyboot.com (Brad Eckert)
Date: 4 Jan 2002 06:40:03 -0800
Links: << >>  << T >>  << A >>
Andreas Schweizer <mail@andreas-schweizer.de> wrote in message news:<3C33D64A.5D38B5C2@andreas-schweizer.de>...
> Jason Berringer wrote:
> 
> > The tools report that the maximum
> > frequency is about 67 MHz. Does this mean that this counter will not work
> > correctly,
> 
> A 32-bit counter is quite long, so you should consider implementing it in
> severals stages as look-ahead counters.
> 
Even using a divide by two prescaler would work. In your 100 MHz
counter, the LSB changes state at 100 MHz. The other bits change state
at 50 MHz, 25 MHz and so on. You just have to treat the lowest bits as
a special case.

Article: 38086
Subject: multiplexing a clock
From: "Chuck Woodring" <c.woodring@worldnet.att.net>
Date: Fri, 04 Jan 2002 14:51:08 GMT
Links: << >>  << T >>  << A >>
Is it bad design practice to use a multiplexor to switch clocks. I have a
design which seems to work ok where I select a 30 MHz clock at on time and
then switch to a 16 MHz clock later. The maximum speed of the D/A I am
feeding is 17MHz when fed serial data but I can load my parallel to serial
converter at the higher frequency and then shift the data at the slower
rate.

Thanks in advance.
CW



Article: 38087
Subject: Configuration Times of FPGAs
From: "Claus Ritter" <ritter@fzi.de>
Date: Fri, 4 Jan 2002 16:30:29 +0100
Links: << >>  << T >>  << A >>
Hi all,

I would like to know how much time is necessary after finishing, compiling
etc. the design to actually load it into the device.
Maybe someone can tell me a value like ms/CLB or something.
An actual value of a specific FPGA would be also helpful.

I'm not a FPGA designer, but currently I'm working with a reconfigurable
hardware architecture, where a new configuration just needs a few clock
cycles to be loaded. I would like to know the value for FPGAs just for
comparison. Therefore even a raw estimation would be good.


Thanks in advance,
Claus Ritter



Article: 38088
Subject: Re: Spartan-IIE interfacing issues
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 04 Jan 2002 07:37:00 -0800
Links: << >>  << T >>  << A >>
Doug,

The recommendation is to use a 100 ohm resistor in series with the 5V
driver output to the 3.3V powered IO bank on the Spartan IIE.  This way,
if the driver can pull all the way to 5V, the forward clamping of the
input diode to Vcco limits the voltage at the input pin to Vcco+0.5V (the
diodes are intrinsic to the pmos output fets which are present in the IOB,
so they are ~ 0.5V drop).

If you first simulate the connection in IBIS, you may find that the 5V
outputs are classic TTL (not CMOS), and can not pull above Voh(max) of a
voltage that does not exceed Vcco+0.5V (i.e. less than 3.8 V).  If this is
the case, no resistor is needed to limit the input current into the
Spartan IIE.

Many TTL parts that are CMOS used nmos pull-up transistors in the output
stage, so the Voh(max) was always ~ 0.7 V below the Vcc of 5V, or lower.

If placing a 100 ohm resistor in series slows down the signal too much,
one can also simulate it in IBIS with a resistor to ground.  A 75 ohm
resistor, for example, will load down the driver without slowing down the
signal, resulting in a lower Voh(max).

Remember to simulate the fast/strong corner in IBIS, as that is the
cold/strong transistor/high vcc case that will be the worst case.  Also
then simulate the slow/weak corner to be sure the voltages are still
within spec for the input to see 0's and 1's.

Innoveda's Hyperlynx has a free download version that can be used for
these kinds of what if's.  The demo version can not import new IBIS files,
and has other restrictions, but I highly recommend trying it out.  Once
you get using it, you will be hooked, and just buy the real version.  The
cost will save board respins due to bad SI, so you will end up saving
money the first time you use it.

For those of you with the Cadence, or Mentor IBIS simulator tools, those
are also excellent, and I highly recommend them.  Avant! Hspice also
imports IBIS as a subcircuit model, so it can be used for those who like
spice.

Austin Lesea
ICDES
Xilinx

Doug wrote:

> I need to interface some old-fashioned 5V logic to a Spartan-IIE FPGA,
> which has 3.3V I/O.
>
> I know I could use something like a 74LVX3245, but apparently it can
> be safely done with resistors as well.  In the appnote "Spartan-IIE
> Family:  Frequently Asked Questions" (Xilinx document #FAQ100), it
> says:
>
> "The Spartan-IIE is 3.3V I/O compatible and will only support 5.0V
> I/Os when an external pull-up resistor is used."
>
> ...and that's all the info I've been able to find so far.
>
> Before I proceed, I would like to see more specific recommendations
> (preferably from Xilinx!) about how best to do this.  Is anyone out
> there aware of any other documents detailing Xilinx' recommended
> method, specifically for the Spartan-IIE family?
>
> Thanks in advance,
>
> Doug Jones


Article: 38089
Subject: Re: Configuration Times of FPGAs
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 4 Jan 2002 17:32:29 +0100
Links: << >>  << T >>  << A >>
"Claus Ritter" <ritter@fzi.de> schrieb im Newsbeitrag
news:a14hph$i2i@absalom.fzi.de...
> Hi all,
>
> I would like to know how much time is necessary after finishing, compiling
> etc. the design to actually load it into the device.
> Maybe someone can tell me a value like ms/CLB or something.
> An actual value of a specific FPGA would be also helpful.

This times can be easyly calculated using the datasheets. For the newer
Xilinx parts (Spartan-II and better) , in parallel configuration mode (8
bit) the maximum clock frequency is 50 MHz (without handshaking). The
configuration files range from 100kbits (smallest Spartan-II, 15k gates) to
33Mbits (biggest Virtex-II, 10M gates). The reset should be primary school
math. ;-) The numbers are not 100% correct since I dont have the datasheets
at my fingertips now.

--
MfG
Falk




Article: 38090
Subject: Re: multiplexing a clock
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Fri, 4 Jan 2002 17:35:46 +0100
Links: << >>  << T >>  << A >>
"Chuck Woodring" <c.woodring@worldnet.att.net> schrieb im Newsbeitrag
news:wjjZ7.324393$W8.12424509@bgtnsc04-news.ops.worldnet.att.net...
> Is it bad design practice to use a multiplexor to switch clocks. I have a
> design which seems to work ok where I select a 30 MHz clock at on time and
> then switch to a 16 MHz clock later. The maximum speed of the D/A I am
> feeding is 17MHz when fed serial data but I can load my parallel to serial
> converter at the higher frequency and then shift the data at the slower
> rate.

So I would use just 30 MHz and generate a 15 Mhz clock enable signal (just a
toggle FF) for the A/D converter section. Makes the design simpler and more
reliable.

--
MfG
Falk





Article: 38091
Subject: Re: Configuration Times of FPGAs
From: "Ulf Samuelsson" <ulf@atmel.REMOVE.com>
Date: Fri, 4 Jan 2002 17:43:40 +0100
Links: << >>  << T >>  << A >>
> Hi all,
>
> I would like to know how much time is necessary after finishing, compiling
> etc. the design to actually load it into the device.
> Maybe someone can tell me a value like ms/CLB or something.
> An actual value of a specific FPGA would be also helpful.
>
> I'm not a FPGA designer, but currently I'm working with a reconfigurable
> hardware architecture, where a new configuration just needs a few clock
> cycles to be loaded. I would like to know the value for FPGAs just for
> comparison. Therefore even a raw estimation would be good.
>
>
> Thanks in advance,
> Claus Ritter
>
>

Typically look at the size of the configuration area,
and then how many can be loaded in parallell at what speed.

Using a serial configurator running at 33 MHz and 521 kbit configuration
info
(Atmel AT40K40) it should totally reconfigure in 16 milliseconds.
Of course you can do partial reconfiguration and reconfigure a single CLB
in a few microseconds.
If you run in parallell mode, it will be a lot faster.

The hard  part about partial reconfiguration is how to do good
place & route tools for it.

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.




Article: 38092
Subject: Re: multiplexing a clock
From: steve (Steve Rencontre)
Date: Fri, 4 Jan 2002 16:50 +0000 (GMT Standard Time)
Links: << >>  << T >>  << A >>
In article <wjjZ7.324393$W8.12424509@bgtnsc04-news.ops.worldnet.att.net>, 
c.woodring@worldnet.att.net (Chuck Woodring) wrote:

> Is it bad design practice to use a multiplexor to switch clocks.

Depends on how important it is that the circuit works, I suppose :-)

> I have  a
> design which seems to work ok where I select a 30 MHz clock at on time 
> and then switch to a 16 MHz clock later.

If you could make it 32 and 16, and switch synchronously, your life would 
be a lot easier. If you could use just one clock and a synchronous 
clock-enable, it would be easier still.  As it is, you have to decide what 
you want to do when both clocks are transitioning at 'about' the same 
time. If it doesn't matter that the circuit will see runt pulses that 
could trigger metastability and cause invalid outputs, then don't worry 
(but don't go boasting about it!) Otherwise, your best bet is probably to 
resync the slower clock to the faster with the standard pair of registers 
in series. This will screw up the clock's duty cycle, of course, so I hope 
that's not important.

--
Steve Rencontre		http://www.rsn-tech.co.uk
//#include <disclaimer.h>


Article: 38093
Subject: Re: multiplexing a clock
From: Bob Perlman <no-spam@sonic.net>
Date: Fri, 04 Jan 2002 16:58:47 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Fri, 04 Jan 2002 14:51:08 GMT, "Chuck Woodring"
<c.woodring@worldnet.att.net> wrote:

>Is it bad design practice to use a multiplexor to switch clocks. I have a
>design which seems to work ok where I select a 30 MHz clock at on time and
>then switch to a 16 MHz clock later. The maximum speed of the D/A I am
>feeding is 17MHz when fed serial data but I can load my parallel to serial
>converter at the higher frequency and then shift the data at the slower
>rate.

Yes, it's a bad idea.  Unless the implementation is absolutely
impeccable, a clock multiplexer circuit can produce glitches that will
drive you crazy.  

From your description above, it's not clear to me why using two clocks
is helping you.  If the problem is that you have a large block of
circuitry running at 30 MHz and a small shifter running at 16MHz, and
you want to transfer parallel load data from the 30MHz domain to the
16MHz domain, you're better off building a synchronizer.
Metastability and synchronization haves been discussed extensively in
past threads.  Or, if you can afford the speed hit, run the shifter at
15MHz by feeding it the 30MHz clock and enabling it every other cycle,
and dispense with the synchronizer for the parallel load.

Some of the newer Xilinx parts have clock multiplexers with glitchless
switchover.  I don't use them (the muxes, not the parts).

>
>Thanks in advance.
>CW
>

Bob Perlman
--
Cambrian Design Works
digital design, signal integrity
http://www.cambriandesign.com

Article: 38094
Subject: help with older xilinx fpga's
From: philtulju@hushmail.com (dev)
Date: 4 Jan 2002 10:47:11 -0800
Links: << >>  << T >>  << A >>
Hello.

I am trying to reverse-engineer an old supercomputer front-panel
display.

It contains many xilinx FPGA's.

The part number is Xilinx:
  XC3042(tm) -100
   PQ100C
   date codes, etc.

it is in a many-pinned gull-wing PQFP

on the xilinx web site, the XC3000 series seems to be discontinued.

I am looking for old datasheets, etc.

Does anyone know if the XC3000A series is pin, bitfile, etc.
compatible? In other words, if I compile a design for the XC3042A,
will it work with these devices?

Thanks!

dev

Article: 38095
Subject: Re: asic vs. fpga
From: Richard Iachetta <iachetta@us.ibm.com>
Date: Fri, 4 Jan 2002 13:02:05 -0600
Links: << >>  << T >>  << A >>
In article <3C353149.1A7CDD1A@earthlink.net>, palfke@earthlink.net says...
> If you have infinite amounts of money and time, and never make a mistake
> and never intend to change your design, then ASICs are great ( Low price
> per chip, high performance, low power).  But this comes at a high price
> in non-recurring engineering charges ( $1 000 000 for a state-of-the art
> big circuit ) and it takes months to get the first chip.  And you must
> always order and pay for a specific quantity, and never make a mistake
> or a change.
> 
> That's why more and more designers prefer the FPGA solution that does
> not have these high up-front costs and long waiting time, and can be
> bought in any quantity at any time, and be modified ad infinitum.

All of this seems a bit overstated.  Here's another perspective perhaps 
overstated in the other direction.  You don't need infinite time and money to do 
an ASIC (I'll address mistakes in a minute).  ASICs generally cost less per part 
but have an upfront NRE cost and longer lead time.  So if your volume is large 
and you can afford the lead time, it often makes economic sense to go with an 
ASIC.  There is typically a volume crossover point where on one side an FPGA is 
cheaper and on the other side an ASIC is cheaper.

As you mentioned, state of the art ASICs perform better than state of the art 
FPGAs and can be much lower power so performance or power may require you to use 
an ASIC.  ASICs offer much more flexability with regard to what you can do; 
while FPGAs have gotten very flexible, they are no where near as flexible as an 
ASIC with respect to different kinds of I/O drivers, pin placement, multiple 
PLLs, DLLs and clock domains, varieties of internal memories, etc.  Custom ASICs 
offer even more flexibility and performance than standard ASICs allowing you 
construct your circuits at the transistor level.  Even standard ASICs allow you 
map to just about any set of gates that you want for your circuit whereas 
designs in FPGAs must be mapped into whichever lookup tables, cells and math-
assist resources are available in the target FPGA.  Floorplanning is important 
for both ASICs and FPGAs but there can be more floorplanning headaches in FPGAs 
which pay a higher penalty if logic feeds other logic that is not close by ("off 
row" or whatever).  In ASICs a slightly longer wire is just slightly more delay 
-- it scales much better.

I would also argue that design source written for ASICs is much more portable 
and reusable than design source written for FPGAs.  This is because FPGA designs 
(especially math functions) must be structured to map well to the particular 
FPGA architecture it is targeted for or a performance penalty (sometimes severe) 
will be paid.  When porting the design to a different FPGA, the design may have 
to be rearchitected.  Targeting an ASIC design to another ASIC technology is 
often just a case of resynthesis to the new library.  Sometimes the netlist can 
be ported avoiding even the resynthesis.

With regard to not being able to make a mistake when designing an ASIC and 
FPGA's being able to "be modified ad infinitum":  Being able to modify an FPGA 
is great during product development but doesn't do as much good after a product 
has shipped.  If people buy a video card with an FPGA on it and that FPGA has a 
bug, those people are usually in the same boat that they would be in if the card 
had used an ASIC instead.  They are (usually) not going to be able to reprogram 
that FPGA at home so both the FPGA designer and the ASIC designer need to get 
the design right by ship time.  During development time, mistakes are worse for 
ASICs but they are not as bad as some FPGA proponents would have you believe.  
ASICs commonly go through two or three passes and each pass is not a full respin 
of all the work, time and money needed to make the first part.  In fact many 
second passes are ECs to the existing mask which preserve all of the design, 
synthesis, floorplanning, layout, wiring and timing work that has already been 
done.

-- 
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.

Article: 38096
Subject: Re: Configuration Times of FPGAs
From: Chris Stinson <Chris.Stinson@xilinx.com>
Date: Fri, 04 Jan 2002 11:33:34 -0800
Links: << >>  << T >>  << A >>
I think this is the formula:

Time to configure = [(number of config bits)/((configuration
frequency)*(bits/clock))] + Tpor

Number of config bits can be found in the datsheets

Configuration frequency and number of bits per clock (parallel vs. serial) is
dependent upon your configuration method.

Tpor is the time for power on reset, also spec'ed in the datasheet.  If you
are reconfiguring after a pulse of the PROG pin then use Tpl instead

Chris


Claus Ritter wrote:

> Hi all,
>
> I would like to know how much time is necessary after finishing, compiling
> etc. the design to actually load it into the device.
> Maybe someone can tell me a value like ms/CLB or something.
> An actual value of a specific FPGA would be also helpful.
>
> I'm not a FPGA designer, but currently I'm working with a reconfigurable
> hardware architecture, where a new configuration just needs a few clock
> cycles to be loaded. I would like to know the value for FPGAs just for
> comparison. Therefore even a raw estimation would be good.
>
> Thanks in advance,
> Claus Ritter


Article: 38097
Subject: Re: PCI Solution: LogiCore?
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 04 Jan 2002 12:11:27 -0800
Links: << >>  << T >>  << A >>
Kevin Brace <nospamtomekevinbraceusenet@nospamtomehotmail.com> writes:
> A few months ago, there was a guy who claimed that he figured out how to
> synthesize (technically synthesizing is not the correct word, processing
> a netlist should be correct) Xilinx's PCI LogiCORE with XST.
> To retrieve the past posting I am talking about, try doing a Google
> Groups search (http://groups.google.com/groups?group=comp.arch.fpga) for
> comp.arch.fpga "only" with the following titles.
> 
> Xilinx PCI core and XST
> 
> Xilinx XST vs FPGA Express? 
>
> The guy said he will tell you how to do it if you sent him an E-mail (I
> suppose it would have been better if he posted more information about it
> to the newsgroup).

The specific messages can be found at the URLs:

http://groups.google.com/groups?selm=9r8vkh%24pp1%241%40proxy2.fe.internet.bosch.com

and
http://groups.google.com/groups?selm=9rb28l%24mbt%241%40proxy2.fe.internet.bosch.com 

Article: 38098
Subject: Re: help with older xilinx fpga's
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Fri, 04 Jan 2002 12:19:09 -0800
Links: << >>  << T >>  << A >>

--------------A80D1CD33C21574980A87D7C
Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353"
Content-Transfer-Encoding: 7bit



dev wrote:

> I am looking for old datasheets, etc.
>
> Does anyone know if the XC3000A series is pin, bitfile, etc.
> compatible? In other words, if I compile a design for the XC3042A,
> will it work with these devices?

No, see below.

For the data sheets, click on:

http://www.xilinx.com/partinfo/3000.pdf

The Xilinx data book states ( and I wrote it ):
"XC3000A is an enhanced version of the basic XC3000 family., featuring
additional interconnect resources and other user-friendly enhancements."

You can pour an XC3000 bitstream into an XC3000A device, and it will work
perfectly. The reverse is obviously not true. The additional features in XC3000A
use "spare" configuration bits that were not used in the XC3000, but any XC3000
would not know what to do with the extra bits in the spare location.

Peter Alfke, Xilinx Applications



Article: 38099
Subject: Re: asic vs. fpga
From: "S. Ramirez" <sramirez@cfl.rr.com>
Date: Fri, 04 Jan 2002 20:20:19 GMT
Links: << >>  << T >>  << A >>
"Richard Iachetta" <iachetta@us.ibm.com> wrote in message > With regard to
not being able to make a mistake when designing an ASIC and
> FPGA's being able to "be modified ad infinitum":  Being able to modify an
FPGA
> is great during product development but doesn't do as much good after a
product
> has shipped.  If people buy a video card with an FPGA on it and that FPGA
has a
> bug, those people are usually in the same boat that they would be in if
the card
> had used an ASIC instead.  They are (usually) not going to be able to
reprogram
> that FPGA at home so both the FPGA designer and the ASIC designer need to
get
> the design right by ship time.  During development time, mistakes are
worse for
> ASICs but they are not as bad as some FPGA proponents would have you
believe.
> ASICs commonly go through two or three passes and each pass is not a full
respin
> of all the work, time and money needed to make the first part.  In fact
many
> second passes are ECs to the existing mask which preserve all of the
design,
> synthesis, floorplanning, layout, wiring and timing work that has already
been
> done.

Richard,
     I hear what you are saying, but I thought I would clarify one point.
In the product that I am presently developing, which is an enhanced version
of something out in the field, the FPGAs are configured by microprocessor.
This allows us to update the FPGA programming quite easily.  Whenever the
client company wants to do a software update, which is shipped to the field
via Internet or CD, the FPGA programming is included.  Therefore, FPGAs can
be easily updated out in the field if the hardware to allow this is planned
in advance.
Simon Ramirez, Consultant
Synchronous Design, Inc.
Oviedo, FL  USA





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