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 25350

Article: 25350
Subject: Re: XC3000A Configuration data
From: gah@ugcs.caltech.edu (glen herrmannsfeldt)
Date: 7 Sep 2000 19:30:16 GMT
Links: << >>  << T >>  << A >>
kolja@prowokulta.org writes:

>In article <39B6B196.A9326D1B@xilinx.com>,
>  Phil James-Roxby <phil.james-roxby@xilinx.com> wrote:
>> > Officiall the bitsream is not disclosed to prevent the distruction
>> > of the device by short circuit connections, which is allegedly
>> > checked by JBits.
(snip)
>> Actually, JBits doesn't check short circuit connections, though you
>> could write a DRC checker using the JBits API if you were concerned
>> about it.  Since JBits gives you full access to all the configurable
>> resources within a device, if you want to blow up a Virtex, go ahead.

>So, then I can not the why you should keep the bitstream secret?
>I  would like to do self reconfiguration from the FPGA so I do
>not have Java around in that environment.
>JBits will help a lot with reverse engineering but a disclosed
>bitstream format would be easier.

Personally, I believe that they should, too.  I was once working
on a project like that, but not now.  It is my understanding that
in this case, and with the right NDA, you can get the information.

The project I was working on mostly needed the location of the LUT
data, and they will almost tell you that when they explain readback.
(Pretty much I would have needed to load different data into ROMs
in different places.  I might have needed to change the carry logic,
but no routing changes.  But then I didn't get to do that project.)

-- glen
Article: 25351
Subject: Re: Slow routing of PWR/GND (Virtex)
From: Rajeev Jayaraman <rajeev@xilinx.com>
Date: Thu, 07 Sep 2000 13:44:56 -0700
Links: << >>  << T >>  << A >>
A couple of points on this thread:

1. Xilinx is currently working on a new pwr/gnd routing algorithm and we have
scheduled it to be released in service pack 4.  The new algorithm improves the
runtime for pwr/gnd routing significantly.

2. With respect to putting in constraints that are "impossible" to meet to just see
how fast your design will go I'd like to explain a new feature in 3.1i called
auto-timespec which should considerably enhance this flow for Virtex and related
families (Virtex-E). Here is a snippet from the online documentation about auto
timespecs

"When automatic timespecing is invoked, PAR analyzes the design for clock nets and
attempts to increase the frequency of clocks. If you were to increase the clock
frequency using a timing-driven flow, you would perform multiple runs of PAR with
progressively higher frequencies. Each run would require you to increase the
frequency specifications on clocks in your design. PAR would attempt to meet these
specifications, not improve on them. You might continue to increase the frequency
specifications until PAR can no longer meet them. At this point, your design would
achieve optimal clock frequency. In contrast, automatic timespecing allows you to
achieve good clock frequency results in the shortest possible time."

If you are trying to determine what are the limits of performance for your design,
one possible  methodology would be to run PAR in auto-timespec mode. Run trace (the
static timing analysis tool) to get the clock frequencies of the resulting design.
Use that frequency as a baseline for the clocks and try to put in constraints
approximately 10-15% higher to see how far PAR can really go.

Please look in the documentation for all the details on how to invoke this flow.
Hope that helps.

Rajeev

> 3.1 does seem to fix that problem.  One bugger with 3.1 is if the placement
> isn't going to meet timing, it spends an awful long time trying a little harder
> before it gives up.  That's a bit of a bugger if you are trying to push
> something to see how fast it'll go as opposed to meet timing for a particular
> target.  If your placement makes meeting timing relatively easy, the tool runs
> very quickly...I've got a very full 97%)XCV400 that's placing and routing in
> under 5 minutes, with all the datapahth stuff but not control logic
> floorplanned.
>
> Johan Petersson wrote:
> >
> > Hi Richard,
> >
> > All I can say is that the problem does not remain in
> > 3.1i, which improves par times enormously!
> >
> > Johan,
> > email vhdl_ninja@yahoo.com
> >
> > news@rtrussell.co.uk wrote:
> > >
> > > The problem of very slow routing of PWR/GND nets is
> > > supposed to be fixed in 2.1i Service Pack 6, but I
> > > am still suffering from it (running the Unix tools
> > > on a Sun Ultra 10 workstation).  An XCV600 is taking
> > > about 8 hours to build, of which over 7 hours is the
> > > PWR/GND routing (all signals are successfully routed
> > > in under 40 minutes).  Does the problem remain in SP6,
> > > or is this a specific issue related to the use of the
> > > Unix version ?
> > >
> > > Richard.
> > > http://www.rtrussell.co.uk/
>
> --
> -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  or http://www.fpga-guru.com

Rajeev Jayaraman, Ph.D
Manager, Place/Route/Timing Tools
FPGA Implementation Tools Group
Xilinx Inc.

Article: 25352
Subject: Re: XC3000A Configuration data
From: "Juan-Luis López Rodríguez" <jl.lopez@REMOVETHISieee.org>
Date: Thu, 7 Sep 2000 22:58:08 +0200
Links: << >>  << T >>  << A >>
Dear Anthony;

At least some years ago this information was a closely kept secret. Xilinx
only discovered it to selected customers who signed a NDA. The official
reason was not to protect devices against mis-configuration, was to protect
the intellectual property of the design.

However, it is not difficult to play with the Xilinx tools and reverse
engineer some of the bitstream of the XC3000A devices, and the partial
dynamical reconfiguration capability can be very useful in embedded systems.

With some extra programming effort, it can be even done "at the fly",
keeping the bitstream only in
ROM/FLASH memory segments and not spending extra RAM for buffers.

Here are some hints, based on my past experience on the matter. I did it
many years ago, so I apologize for any mistake caused by my bad memory.

BACKGROUND:

The bitstream overhead format (bit count, headers, etc) is well document in
Xilinx documents. The payload is the undocumented part.

The payload is transferred to the static RAM on the FPGA in the
configuration process. The bits in the static RAM control the state of
different FPGA resources (routing switches and CLB configuration).

To dynamically change the state of routing switches is a difficult problem.
It means to move the place/routing process to run time instead of FPGA
compile time, so I never tried it. However, it is easy to dynamically change
the CLB configuration, especially the lookup table (LUT).

Each CLB has an associated 32-bit LUT. Each bit corresponds to one of the 32
product terms of the single 5-bit input function, or to the two 16 product
terms of the two 4-bit input functions.

I believe (not sure) the logic used was positive, so the null function
(output always zero) had all the 32 bits to zero, the unity function (output
always one) had the 32 bits at one, and the single product term functions
had a single bit at one.

The 32 bits of a given LUT are *not* located in consecutive positions of the
bitstream, but their offsets from LUT base address are the *same* for all
the CLBs, so once discovered the values for one CLB, you have the values for
all of them.

THE PROCESS AT FPGA DESIGN TIME:

Assume you want to reconfigure a 5-bit combinatorial function and that you
use schematics and not VHDL.

Put any dummy or default logic gates into the schematic in substitution of
the real functions (are going to change in run time anyway).

Add to your schematic a CLBMAP symbol for the function.

For reasons explained latter, it is advisable to use a well known and
normalized name for the CLBMAP (something like prefixing it with two
underscores).

THE PROCESS AT RUN TIME:

When you configure the FPGA and find the "reconfigurable" bits in the
bitstream, substitute them by the ones computed at run time.

To locate the position in the bitstream of a given (CLB, product term) pair
you only have to know
a) The base address of the CLB LUT in the bitstream and
b) The offset of the product term from the LUT base address.

So you only need a couple of small tables:
- One for the CLB LUT base address (one position for each CLB)
- One for the product term offsets (32 positions)

THE PROCESS AT REVERSE ENGINEERING TIME:

To fill the values of the tables you can manually edit the FPGA, put well
chosen patterns into the LUTs, generate some bitstreams and check the
differences with some file-compare utility.

For the test, you can configure all the CLBs LUTs with null functions (are
always false, and the LUT bits are zero) and use that bitstream as a
baseline.

Then, to fill the offsets table, take a LUT and configure it. Iterate with
the 32 possible 5 bit functions that have a single product term. The
resulting bitstreams will have changed a single bit when compared with the
baseline.

To fill the base address table, take an input function. Iterate all the LUTs
into a FPGA and configure them with the function. The function with the
minimum offset (0) would be nice.

THE PROCESS AT FPGA COMPILE TIME:

The problem here is that every time the place/route process runs, it can put
your CLBMAP logic at different coordinates and can also swap the input
signals.

The first solution could be to lock the CLB coordinates and the signal
ordering in the FPGA schematic, and then your software will see those values
as constants.

But this can be undesirable restriction, as does not allow the placer/router
to optimize the results. A better (and more elaborate) approach is the
following:
1- To scan (at FPGA compile time) several intermediate text files (the
netlist and the LCA routed ones).
2- Look for the "magical" two underscores to find the names of
reconfigurable CLBs.
3- Look for its input signal names and store them.
4- Look for the signals names and compute the permutations caused by the
router.
5- Create a C/ASM file with the coordinates of the involved CLBs and the
signals ordering. This file can be considered as an "addendum" of the
bitstream, and can also contain it.
6- Compile and link the file as you would do with the normal bitstream.

For steps 1 to 5 we wrote some specific utilities. The process can be fully
automated with a make file, and then does not have to impose any extra
burden to the people involved in the FPGA and software build process.

POSSIBLE ENHANCEMENTS:

- To configure other CLB bits than the LUT ones, as the clock polarity.
- I remember that the table for base address is not really needed, because
there is a regularity that can be exploited. The base address can be
calculated from the coordinates of the CLB in the FPGA. It was something
like multiply one of the coordinates by a constant, and adding to the result
a constant dependent on the other coordinate.

Hope this info helps you. To get more details I would have to dig deep into
very old notes.

Juan-Luis Lopez
Spain

Note: My email domain address has an anti-spam word (REMOVETHIS).



Article: 25353
Subject: Re: floorplanning
From: Ray Andraka <ray@andraka.com>
Date: Thu, 07 Sep 2000 21:33:02 GMT
Links: << >>  << T >>  << A >>
That seems a little convoluted but it's probably just that my coffee ran out
this morning.  Being an ex-schematic weenie, I've been using an approach that
mirrors how I did RLOCs in schematics.  It lets you hierarchically assign
placement just like we did with the schematics.  For example the code below is a
snippet for a placed two's complementer.  itoa is a homegrown an integer to
ascii string conversion that does essentially the same thing as 'image because
synplicity doesn't know what 'image is.  In this case, the instantiation of this
component also needs an RLOC on it with the slice declared because the slices
can only be declared once in the hierarchy. (Who else finds this slice thing a
real PITA!)
I know this works in synplicity, and since it doesn't use anything specific to
synplicity (other than for the inside the fmap_xor2 component that is), it
should mostly work under other tools as long as user attributes are supported.

begin
ax<=resize(signed(a),width);	

--construct from primitives so placement can be included
c(0) <=neg;
L:for i in 0 to width-1 generate   
	constant rloc_str : string := "R" & itoa((width-1)/2-(i/2)) & "C0"; 
	signal l,s: STD_LOGIC;--_VECTOR(width-1 downto 0);
	attribute RLOC   of U1 : label is rloc_str;
	attribute RLOC   of U2 : label is rloc_str;
	attribute RLOC   of U3 : label is rloc_str;
	attribute RLOC   of U4 : label is rloc_str;
	begin		
		U1: fmap_xor2 port map(	  --invert input when neg = '1'
			a=> ax(i),
			b=> neg,
			z=> l);

		U2: MUXCY port map (	  --and add 1
			O  => c(i+1),
			CI => c(i),
			DI => '0',
			S  => l );
		
		U3: XORCY port map (
			O  => s,
			CI => c(i),
			LI => l );
		
 		U4: FDCE port map (
		 	Q  => q(i),
		 	D  => s, 
			CLR=>Global_reset,
			CE => ce,
			C  => clk );
	end generate L;	 

end Virtex_struct;


husby@my-deja.com wrote:
> 
> For VHDL, I find it's useful to do all of the floorplanning via
> a single function of the form: (Please excuse VHDL errors, I'm
> writing this without a VHDL reference)

-- 
-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  or http://www.fpga-guru.com
Article: 25354
Subject: Re: floorplanning
From: husby@my-deja.com
Date: Thu, 07 Sep 2000 22:43:54 GMT
Links: << >>  << T >>  << A >>
RLOCs are OK, but I find a global view of the floorplanning
to be a little more flexible.  For example, if you have a wide
data path that flows through many columns of logic, adders,
memories, etc, you can quickly move the entire path just by
changing a few parameters.  You could, for example, run
the carry chains up instead of down (or if you use Lucent
chips, you could rotate whole blocks and run the carries
left-to-right and run the tristate busses up and down).

Or you can play games like:  What if I insert an empty
row between bits 15 and 16 of the data path?  It might
slow the carry chains down, but the placer could put
some of my tight control logic in there and it might make
better use of some of the half-length metal lines if I can
get bit 16 across that boundary.

  I also adopted my VHDL method from my schematic methodology
where I implemented the same function with an "algorithmic
floorplanning language" for schematics.  Like you, I still
lobby for better schematic support, but have to accept that
VHDL is the current bandwagon.  (Actually, this new company
I'm working at wants to use SystemC!  Even more convoluted
text to describe simple concepts, but at least it knows what
a clock is.)

Ray Andraka <ray@andraka.com> wrote:
> That seems a little convoluted but it's probably just that my coffee
ran out
> this morning.  Being an ex-schematic weenie, I've been using an
approach that
> mirrors how I did RLOCs in schematics.  It lets you hierarchically
assign
> placement just like we did with the schematics.  For example the code
below is a
> snippet for a placed two's complementer.  itoa is a homegrown an
integer to
> ascii string conversion that does essentially the same thing
as 'image because
> synplicity doesn't know what 'image is.  In this case, the
instantiation of this
> component also needs an RLOC on it with the slice declared because
the slices
> can only be declared once in the hierarchy. (Who else finds this
slice thing a
> real PITA!)
> I know this works in synplicity, and since it doesn't use anything
specific to
> synplicity (other than for the inside the fmap_xor2 component that
is), it
> should mostly work under other tools as long as user attributes are
supported.
>
> begin
> ax<=resize(signed(a),width);
>
> --construct from primitives so placement can be included
> c(0) <=neg;
> L:for i in 0 to width-1 generate
> 	constant rloc_str : string := "R" & itoa((width-1)/2-(i/2))
& "C0";
> 	signal l,s: STD_LOGIC;--_VECTOR(width-1 downto 0);
> 	attribute RLOC   of U1 : label is rloc_str;
> 	attribute RLOC   of U2 : label is rloc_str;
> 	attribute RLOC   of U3 : label is rloc_str;
> 	attribute RLOC   of U4 : label is rloc_str;
> 	begin
> 		U1: fmap_xor2 port map(	  --invert input when neg = '1'
> 			a=> ax(i),
> 			b=> neg,
> 			z=> l);
>
> 		U2: MUXCY port map (	  --and add 1
> 			O  => c(i+1),
> 			CI => c(i),
> 			DI => '0',
> 			S  => l );
>
> 		U3: XORCY port map (
> 			O  => s,
> 			CI => c(i),
> 			LI => l );
>
>  		U4: FDCE port map (
> 		 	Q  => q(i),
> 		 	D  => s,
> 			CLR=>Global_reset,
> 			CE => ce,
> 			C  => clk );
> 	end generate L;
>
> end Virtex_struct;
>
> husby@my-deja.com wrote:
> >
> > For VHDL, I find it's useful to do all of the floorplanning via
> > a single function of the form: (Please excuse VHDL errors, I'm
> > writing this without a VHDL reference)
>
> --
> -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  or http://www.fpga-guru.com
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25355
Subject: XC6K still alive ??
From: karenwlead@my-deja.com
Date: Thu, 07 Sep 2000 22:46:10 GMT
Links: << >>  << T >>  << A >>
hi all,

I tried to have such connection (through the edif file)

IPAD-IBUF-BLOCK

I am getting this error,
" try to redefine the connection of a certin port "

whenever  i don't insert the IPAD, the edif file is accepted, even
that  block port is external ?

any clue?

-- Karen W

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Man stays wise as long as he searches for wisdom, As soon as he thinks
he has found it, he becomes a fool.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Sent via Deja.com http://www.deja.com/
Before you buy.
Sender: eric@ruckus.brouhaha.com
Article: 25356
Subject: Re: 3.3/2.5 voltage regulators
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Thu, 07 Sep 2000 17:16:45 -0700
Links: << >>  << T >>  << A >>

--------------7CE468A475D17E5248325F53
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit

Alain,

"High" is a relative term.  Please read the following to see the differentiation
between large high performance FPGAs, and small lower performance FPGAs.

'Luck" is also a relative term, and I can assure you, that luck has nothing to
do with it.  Two years ago we recognized that the larger devices were requiring
significant (greater than 1 ampere) of start up current, and we addressed the
issue, along with all older family members, and devised the Power On Ramp Up
Current Capacity specification for the power supplies, and modified new designs
as appropriate and put in place tests for older family parts.

If you are buying the Commercial part (C), it is not specified below 0 C.

If you are buying the Industrial part (I), the specifications apply down to -40
C.

For many years (at my previous employer), I bought and used commercial parts in
telecom applications for -40 C use, but I tested all systems and boards at -45 C
in the production process before shipping to satisfy the contract with the
telephone companies.  How much money did I save?  Probably none!  By the way, I
spent 20+ years in telecom transmission systems design in fiber, radio, and
metallic systems.

If you notice, some Industrial family parts require more startup current at
lower temperatures.  At very low temperatures, the transistors are very strong,
and very fast.  This leads to larger currents than would otherwise be observed
at 0 degrees centigrade.  Once we identify the sources of these currents, we
tend to remove them from future designs.  We are not usually concerned with
currents less than 1 ampere in the largest devices, as operational currents are
often greater.

Spartan Family parts have their own requirements, and strive for much much lower
currents (see individual member data sheets).  The process is different for
Spartan wafers, and it can be optimized for other parameters.  Additionally
Spartan devices usually have an opportunity to be re-designed for the addition
of the power down feature, and other power saving features.  Spartan is often
the favorite choice in many low power telecom applications due to this extra
design effort.

We do not require our own special power supply ICs like DSPs and uProcessors,
and plan to continue to interface with the widest range of ramp on times and
behavior power supplies possible.

Austin

Alain Cloet wrote:

> "rickman" <spamgoeshere4@yahoo.com> wrote in message
> news:39B7CD44.B9D9F57F@yahoo.com...
> > I must say that I am floored by this information. All the time I have
> > been using Xilinx parts, I have never been aware of the high current
> > required for startup. I guess I was lucky that the systems I worked on
> > had plenty of power for startup.
> >
> I could imagine it either, but when I was told of the startup problems at
> low temperature it was my first guess.  I'm not a designer, so I wasn't
> aware that after boot the FPGAs consumed so less ofter startup - the whole
> 3.3 part of the board (which is mainly just the three XL4013XL-parts and
> some capacitors near the power) consumes after startup approx. 50 mA.  The
> whole boot thing takes from 500µs to 5 ms depending on the temperature, so
> you can't possible notice this if you don't measure this intentionally...
>
> In a test of the startup power with a external power source with a max of 5
> A (!) it's still possible to see that the voltage doesn't go up in a
> regulated way - in other words: the 3 parts & the capacitors (which, of
> course, have their influence as well with fast power-up) would have taken
> more than 5 A if it were possible...(at -40C, and more than half an hour
> unpowered)
>
> Under relative normal condition the former regulator could make it (even
> though the voltage didn't went up in a continuous way) at room temperature,
> but under the maximum stressed specs of the board - at -40C for more than 30
> minutes unpowered (so really cold, even internally) and a supply voltage of
> 4V5 - it didn't...  In the measurements it showed oscillating of the voltage
> even at -20C (due to the current limiting of the regulator), but the core of
> FPGA - my guess again -  got warm enough to start.  Also at -40C a supply
> voltage of 5V2 made it possible to boot...
>
> Thanks for all the reactions,
> Alain

--------------7CE468A475D17E5248325F53
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Alain,
<p>"High" is a relative term.&nbsp; Please read the following to see the
differentiation between large high performance FPGAs, and small lower performance
FPGAs.
<p>'Luck" is also a relative term, and I can assure you, that luck has
nothing to do with it.&nbsp; Two years ago we recognized that the larger
devices were requiring significant (greater than 1 ampere) of start up
current, and we addressed the issue, along with all older family members,
and devised the <i>Power On Ramp Up Current Capacity</i> specification
for the power supplies, and modified new designs as appropriate and put
in place tests for older family parts.
<p>If you are buying the Commercial part (C), it is not specified below
0 C.
<p>If you are buying the Industrial part (I), the specifications apply
down to -40 C.
<p>For many years (at my previous employer), I bought and used commercial
parts in telecom applications for -40 C use, but I tested all systems and
boards at -45 C in the production process before shipping to satisfy the
contract with the telephone companies.&nbsp; How much money did I save?&nbsp;
Probably none!&nbsp; By the way, I spent 20+ years in telecom transmission
systems design in fiber, radio, and metallic systems.
<p>If you notice, some Industrial family parts require more startup current
at lower temperatures.&nbsp; At very low temperatures, the transistors
are very strong, and very fast.&nbsp; This leads to larger currents than
would otherwise be observed at 0 degrees centigrade.&nbsp; Once we identify
the sources of these currents, we tend to remove them from future designs.&nbsp;
We are not usually concerned with currents <b>less than 1 ampere</b> in
the largest devices, as operational currents are often greater.
<p>Spartan Family parts have their own requirements, and strive for much
much lower currents (see individual member data sheets).&nbsp; The process
is different for Spartan wafers, and it can be optimized for other parameters.&nbsp;
Additionally Spartan devices usually have an opportunity to be re-designed
for the addition of the power down feature, and other power saving features.&nbsp;
Spartan is often the favorite choice in many low power telecom applications
due to this extra design effort.
<p>We do not require our own special power supply ICs like DSPs and uProcessors,
and plan to continue to interface with the widest range of ramp on times
and behavior power supplies possible.
<p>Austin
<p>Alain Cloet wrote:
<blockquote TYPE=CITE>"rickman" &lt;spamgoeshere4@yahoo.com> wrote in message
<br><a href="news:39B7CD44.B9D9F57F@yahoo.com">news:39B7CD44.B9D9F57F@yahoo.com</a>...
<br>> I must say that I am floored by this information. All the time I
have
<br>> been using Xilinx parts, I have never been aware of the high current
<br>> required for startup. I guess I was lucky that the systems I worked
on
<br>> had plenty of power for startup.
<br>>
<br>I could imagine it either, but when I was told of the startup problems
at
<br>low temperature it was my first guess.&nbsp; I'm not a designer, so
I wasn't
<br>aware that after boot the FPGAs consumed so less ofter startup - the
whole
<br>3.3 part of the board (which is mainly just the three XL4013XL-parts
and
<br>some capacitors near the power) consumes after startup approx. 50 mA.&nbsp;
The
<br>whole boot thing takes from 500&micro;s to 5 ms depending on the temperature,
so
<br>you can't possible notice this if you don't measure this intentionally...
<p>In a test of the startup power with a external power source with a max
of 5
<br>A (!) it's still possible to see that the voltage doesn't go up in
a
<br>regulated way - in other words: the 3 parts &amp; the capacitors (which,
of
<br>course, have their influence as well with fast power-up) would have
taken
<br>more than 5 A if it were possible...(at -40C, and more than half an
hour
<br>unpowered)
<p>Under relative normal condition the former regulator could make it (even
<br>though the voltage didn't went up in a continuous way) at room temperature,
<br>but under the maximum stressed specs of the board - at -40C for more
than 30
<br>minutes unpowered (so really cold, even internally) and a supply voltage
of
<br>4V5 - it didn't...&nbsp; In the measurements it showed oscillating
of the voltage
<br>even at -20C (due to the current limiting of the regulator), but the
core of
<br>FPGA - my guess again -&nbsp; got warm enough to start.&nbsp; Also
at -40C a supply
<br>voltage of 5V2 made it possible to boot...
<p>Thanks for all the reactions,
<br>Alain</blockquote>
</html>

--------------7CE468A475D17E5248325F53--

Article: 25357
Subject: Re: Permanently programming FPGAs
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 07 Sep 2000 17:25:13 -0700
Links: << >>  << T >>  << A >>
"Elftmann" <elftmann@pacbell.net> writes:
> All good points.  Issues that ASIC designers have faced forever.  When
> companies such as Juniper, RedBack, Nexabit/Lucent, Cisco, etc....
> go to the investment community, they are not highlighting their FPGA
> designs, they are highlighting their ASIC designs.
> Which only proves that complex designs can be done correctly the first time
> and EXACTLY correct the very FIRST time.

Or the second or third time.  When they talk to outsiders, they don't
usually discuss how many spins it took.  (Except for rare cases when
they brag that it only took one.)  Obviously they all try fairly hard to
get it right the first time, but it doesn't always happen.

Article: 25358
Subject: Re: Cypress Delta39K availability
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 07 Sep 2000 17:50:41 -0700
Links: << >>  << T >>  << A >>
"Tim" <topedm@ms11.hinet.net> writes:
> I'm seeking a FPGA/CPLD device for my project. Would anyone let me know if
> the cypress Delta39K chips are available now, and who carry this product ?

I've been told that the 39K100 will sample to "select customers"
in 4Q2000.
Article: 25359
Subject: Re: XC3000A Configuration data
From: "John L. Smith" <jsmith@visicom.com>
Date: Thu, 07 Sep 2000 18:18:07 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------1D863A72AA1FFC0756E671D8
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


 LUT data is simple to reverse engineer, just extremely tedious.
Using the FPGA Editor, put a LUT in a particular location, with
a simple equation in place..say:
 R1C1.F = 0
Save the design, compile the bitstream, use it for reference.
Next change the equation:
R1C1.F = !F1*!F2*!F3*!F4
(uh, I think the 3000 series labelled the inputs A, B, C, D, but
you get the idea)

Compare the two bitstreams, and the difference will tell you
where the bit for the product term !F1*!F2*!F3*!F4 resides.
Next, use:
 R1C1.F = F1*!F2*!F3*!F4
and repeat the comparison to find out where the bit for
 F1*!F2*!F3*!F4 is.
Do this for all 16 bits and you've decoded that LUT.
(Do a few more LUTS and you may detect a pattern.)

But this is a painful process. I did it once for a 3000
series design where I needed to fit a compact yet
programmable video timing generator. Never again!
And not being interested in developing development
tools (I only wanted to make compact/versatile counters)
I never did attack the routing bits.

  The technique of modifying the bitstream to change
the LUTs worked well. Then the 4000 family came along,
and the LUTs were turned into RAM, and as long as you
could waste a LUT and use the Dual port, it no longer
was necessary to modify the bitstream, the LUT could be
programmed in place rather than in the bitstream.

glen herrmannsfeldt wrote:
>
{other stuff snipped] 
> The project I was working on mostly needed the location of the LUT
> data, and they will almost tell you that when they explain readback.
> (Pretty much I would have needed to load different data into ROMs
> in different places.  I might have needed to change the carry logic,
> but no routing changes.  But then I didn't get to do that project.)
> 
> -- glen
--------------1D863A72AA1FFC0756E671D8
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard

--------------1D863A72AA1FFC0756E671D8--

Article: 25360
Subject: Jobs at Xilinx
From: craigm9203@my-deja.com
Date: Fri, 08 Sep 2000 01:19:55 GMT
Links: << >>  << T >>  << A >>
Hi Everyone,

Xilinx is hiring! In addition to being	the leader in the programmable logic
industry, we also have one of the happiest work forces in the Silicon Valley
(stock options, work/life balance, stock options, tuition reimbursement,
stock options...Did I mention stock options?). Please review our current
software related job openings at
http://www.xilinx.com/hr/reqpost.htm#Software Engineering . Feel free to
respond online to any of our openings, or email your resume to
craigm@xilinx.com.

Thanks,
Craig


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25361
Subject: ORCAD Xilin GSR
From: "Stan Ramsden" <sramsden@hoflink.com>
Date: Fri, 08 Sep 2000 01:26:40 GMT
Links: << >>  << T >>  << A >>
Does anyone know how to implement the GSR for virtex using the Orcad
simulator.

I know how to do it using Viewlogic
H gsr
c
L gsr
c

Thanks,


--
Stan Ramsden
Ramsden Designs
631-956-7720
sramsden@hoflink.com


Article: 25362
Subject: Re: XC3000A Configuration data
From: sulimma@my-deja.com
Date: Fri, 08 Sep 2000 09:47:02 GMT
Links: << >>  << T >>  << A >>
In article <39B7E6C9.8395CD2F@xilinx.com>,
> gives you nothing over just copying the bitstream and calling that
> reverse engineering.  Far better would be to determine the owner of
> the IP and go steal their filing cabinet.

I did not mean to reverse engineer IP. That is in many cases more
expensive than developing it yourself. (For examnple, you can not reuse
it for another FPGA)

I was talking about reverse engineering the bitstream format to be able
to replace JBits by my own code.

As Steve Trimberger and others pointed out, this is not very hard
to do for most of the FPGA. And documentation about the LCA format
for example has been around for a long time.

> As for self-reconfiguration from the FPGA, I suggest you look at the
> work-horse of reconfigurable computing,the XC6200 and the work of Adam

You sell XC6200? Make me an offer.
How does the cost per gate compare to spartan-II?

Xilinx is "discussing whether the configuration port will be made
available internally to the FPGA in Virtex-II".
A Bitstream documentation might be usefull in that case.

CU,
	Kolja


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25363
Subject: Re: 3.3/2.5 voltage regulators
From: "Henryk Cieslak" <cieslak@becker.k.pl>
Date: Fri, 8 Sep 2000 11:49:27 +0200
Links: << >>  << T >>  << A >>
So, what is the smart method of delaying Virtex configuration? I need to
keep Virtex non-configured for an arbitrary time. The config mode can vary -
master or slave.
Previous data sheets have specified that PROGRAM can be held low to make a
delay, but the latest data sheet (2.2) does not mention it - I think it
means this method is not recommended.
Now you say that keeping INIT low can make the chip consume plenty of
current = make hot.
What to do? Let it start configuration and wait infinitely for CCLK (slave)
or configure with random data until it stops due to checksum error?

Henryk Cieslak
Becker Elektronic Polska


Austin Lesea wrote in message <39B7BF1E.B24BE76F@xilinx.com>...
>Alain,
>
>We recently (> 1 year ago) implemented a Power On Ramp Up current
specification
>for all parts.  We have not gone all the way back to the original 4K
family, but
>the data sheet now specifies the current capacity of the power supply
required
>for clean out and startup prior to configuration.
>
>I would recommend that 1 amp be allowed for each older part (4K, 4KE).
>
>I know the 4KXL, and all subsequent parts are characterized AND TESTED.
>
>There are also things you can do which make this start up current worse.  A
>generally rising voltage, that rises no faster than 2 milliseconds, and no
>slower than 50 milliseconds, and starts from near 0 Vdc (< 300 mV) is
always the
>best way to go.  Starting from a voltage around 450 mV to 700 mV from a
>previously configured part, or holding INIT to prevent configuration, or
passing
>through the POR trip point and then going below the POR trip point, are
common
>causes of higher currents.
>
>In all cases, check the latest website data sheet.  An example is here:
>
>http://www.support.xilinx.com/partinfo/ds005.pdf
>
>page 2 of 16
>
>For parts that have virtually no current requirement at starup, use the
4KXLA,
>4KXV, SpartanXL, or contact your sales office and FAE for assitance in
>selection.
>
>Austin Lesea
>IC Design, Xilinx
>
>Alain Cloet wrote:
>
>> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
>> news:8p6288$5k7$2@noao.edu...
>> > Alexandr V Shuvalov wrote:
>> >
>> > > Which voltage regulators ICs are commonly used to power supply Xilinx
XL
>> > > and other low voltage (3.3-2.5v) devices?
>> >
>> > I used a National LM3940IS-3.3 to drop a VME 5V supply down to 3.3V @ 1
>> > A.
>> >
>> Can you power-up several Xilinx-FPGA's with this element ; or is there a
>> work-around ?
>>
>> We had this problem recently (not completelly solved), and the most
recent
>> idea is to supply 3 Xilinx FPGA's with one National LM3940 (other version
:
>> WG ?).
>>
>> The element we used before had a fast power-up time which caused the FPGA
>> (4013) to take up to 1 A, and the regulator couldn't give 3A (it went ok
a
>> normal temperature, but in a cold phase at -40C it didn't go).
>>
>> Can the LM3940 do the job ?
>>
>> TIA,
>> Alain
>


Article: 25364
Subject: Re: XC3000A Configuration data
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Sep 2000 13:02:23 GMT
Links: << >>  << T >>  << A >>
And then came virtex with the SRL16E's.  That makes reprogramming the
luts..well...almost too easy!

"John L. Smith" wrote:
>
>   The technique of modifying the bitstream to change
> the LUTs worked well. Then the 4000 family came along,
> and the LUTs were turned into RAM, and as long as you
> could waste a LUT and use the Dual port, it no longer
> was necessary to modify the bitstream, the LUT could be
> programmed in place rather than in the bitstream.
> 
-- 
-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  or http://www.fpga-guru.com
Article: 25365
Subject: Re: DCT implementation using FPGA
From: kolja@prowokulta.org
Date: Fri, 08 Sep 2000 13:06:06 GMT
Links: << >>  << T >>  << A >>
This is from Ray Andraka's web site:
http://www.andraka.com/distribu.htm

Choose the right C's and you got your DCT.

CU,
	Kolja

In article <0d7t5.793$EW.854037@nnrp6.proxad.net>,
  "Seb C" <Seb@stien.bizland.com> wrote:
> Hi,
>
> I'm interested by pictures compressions, especially DCT, and if
someone know
> how to do a DCT into an FPGA, i take all what you have !!


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 25366
Subject: test
From: Ian Miller <imiller@carolina.rr.com>
Date: Fri, 08 Sep 2000 14:07:13 GMT
Links: << >>  << T >>  << A >>
Please Ignore.
Article: 25367
Subject: How do I mix vhdl and verilog source files in Synplify?
From: Thomas Karlsson <thomas.karlsson@emw.ericsson.se>
Date: Fri, 08 Sep 2000 16:30:18 +0200
Links: << >>  << T >>  << A >>
Hi all,

I trying to synthesize an old design written in verilog (which is not my
cup of tea, I use VHDL). This design instantiate some module, but I want
to use a new version of this module, written in VHDL. How do I do this? 
I am using Synplify 6.0, which should support mixed language source
files, but it complains that the referenced module can not be found.
I know that the module name is not declared in any verilog file anymore,
but when the vhdl file with the corresponding entity name is compiled
into the library work, I supposed that Synplify should be able to plug
that compiled entity name into the place where the module name is
referenced, but I can not figure out how to do it. Maybe I trying the
impossible here? 
 
Thanks for any help.

Thomas
Article: 25368
Subject: Re: 3.3/2.5 voltage regulators
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Fri, 08 Sep 2000 07:39:29 -0700
Links: << >>  << T >>  << A >>

--------------729D5D0462F71FF8CA870A85
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Henryk,

The INIT holdoff warning applies to 4K only.  It does not apply to Virtex, and
Virtex architecture derivatives.

I am sorry for the confusion.

In 4K, holding INIT and preventing clean out does not make the device HOT -- it
may be that the 4K device is in contention from the Vcc not going down below a
few hundred millivolts, and then the Vcc returns, and the 4K device is in a
partially configured state, and drawing current.  So the device is already HOT
and getting hotter, and INIT prevents the clean out.

Again, Virtex, Virtex E, Spartan2 do not have this behavior.  The design is such
that the means of contention that were caused by memory contents which occurred
in 4K do not exist in Virtex.

Austin


Henryk Cieslak wrote:

> So, what is the smart method of delaying Virtex configuration? I need to
> keep Virtex non-configured for an arbitrary time. The config mode can vary -
> master or slave.
> Previous data sheets have specified that PROGRAM can be held low to make a
> delay, but the latest data sheet (2.2) does not mention it - I think it
> means this method is not recommended.
> Now you say that keeping INIT low can make the chip consume plenty of
> current = make hot.
> What to do? Let it start configuration and wait infinitely for CCLK (slave)
> or configure with random data until it stops due to checksum error?
>
> Henryk Cieslak
> Becker Elektronic Polska
>
> Austin Lesea wrote in message <39B7BF1E.B24BE76F@xilinx.com>...
> >Alain,
> >
> >We recently (> 1 year ago) implemented a Power On Ramp Up current
> specification
> >for all parts.  We have not gone all the way back to the original 4K
> family, but
> >the data sheet now specifies the current capacity of the power supply
> required
> >for clean out and startup prior to configuration.
> >
> >I would recommend that 1 amp be allowed for each older part (4K, 4KE).
> >
> >I know the 4KXL, and all subsequent parts are characterized AND TESTED.
> >
> >There are also things you can do which make this start up current worse.  A
> >generally rising voltage, that rises no faster than 2 milliseconds, and no
> >slower than 50 milliseconds, and starts from near 0 Vdc (< 300 mV) is
> always the
> >best way to go.  Starting from a voltage around 450 mV to 700 mV from a
> >previously configured part, or holding INIT to prevent configuration, or
> passing
> >through the POR trip point and then going below the POR trip point, are
> common
> >causes of higher currents.
> >
> >In all cases, check the latest website data sheet.  An example is here:
> >
> >http://www.support.xilinx.com/partinfo/ds005.pdf
> >
> >page 2 of 16
> >
> >For parts that have virtually no current requirement at starup, use the
> 4KXLA,
> >4KXV, SpartanXL, or contact your sales office and FAE for assitance in
> >selection.
> >
> >Austin Lesea
> >IC Design, Xilinx
> >
> >Alain Cloet wrote:
> >
> >> "Andy Peters n o a o [.] e d u>" <"apeters <"@> wrote in message
> >> news:8p6288$5k7$2@noao.edu...
> >> > Alexandr V Shuvalov wrote:
> >> >
> >> > > Which voltage regulators ICs are commonly used to power supply Xilinx
> XL
> >> > > and other low voltage (3.3-2.5v) devices?
> >> >
> >> > I used a National LM3940IS-3.3 to drop a VME 5V supply down to 3.3V @ 1
> >> > A.
> >> >
> >> Can you power-up several Xilinx-FPGA's with this element ; or is there a
> >> work-around ?
> >>
> >> We had this problem recently (not completelly solved), and the most
> recent
> >> idea is to supply 3 Xilinx FPGA's with one National LM3940 (other version
> :
> >> WG ?).
> >>
> >> The element we used before had a fast power-up time which caused the FPGA
> >> (4013) to take up to 1 A, and the regulator couldn't give 3A (it went ok
> a
> >> normal temperature, but in a cold phase at -40C it didn't go).
> >>
> >> Can the LM3940 do the job ?
> >>
> >> TIA,
> >> Alain
> >

--------------729D5D0462F71FF8CA870A85
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Henryk,
<p>The INIT holdoff warning applies to 4K only.&nbsp; It does not apply
to Virtex, and Virtex architecture derivatives.
<p>I am sorry for the confusion.
<p>In 4K, holding INIT and preventing clean out <b>does not make the device
HOT</b> -- it may be that the 4K device is in contention from the Vcc not
going down below a few hundred millivolts, and then the Vcc returns, and
the 4K device is in a partially configured state, and drawing current.&nbsp;
So the device is already HOT and getting hotter, and INIT prevents the
clean out.
<p>Again, Virtex, Virtex E, Spartan2 do not have this behavior.&nbsp; The
design is such that the means of contention that were caused by memory
contents which occurred in 4K do not exist in Virtex.
<p>Austin
<br>&nbsp;
<p>Henryk Cieslak wrote:
<blockquote TYPE=CITE>So, what is the smart method of delaying Virtex configuration?
I need to
<br>keep Virtex non-configured for an arbitrary time. The config mode can
vary -
<br>master or slave.
<br>Previous data sheets have specified that PROGRAM can be held low to
make a
<br>delay, but the latest data sheet (2.2) does not mention it - I think
it
<br>means this method is not recommended.
<br>Now you say that keeping INIT low can make the chip consume plenty
of
<br>current = make hot.
<br>What to do? Let it start configuration and wait infinitely for CCLK
(slave)
<br>or configure with random data until it stops due to checksum error?
<p>Henryk Cieslak
<br>Becker Elektronic Polska
<p>Austin Lesea wrote in message &lt;39B7BF1E.B24BE76F@xilinx.com>...
<br>>Alain,
<br>>
<br>>We recently (> 1 year ago) implemented a Power On Ramp Up current
<br>specification
<br>>for all parts.&nbsp; We have not gone all the way back to the original
4K
<br>family, but
<br>>the data sheet now specifies the current capacity of the power supply
<br>required
<br>>for clean out and startup prior to configuration.
<br>>
<br>>I would recommend that 1 amp be allowed for each older part (4K, 4KE).
<br>>
<br>>I know the 4KXL, and all subsequent parts are characterized AND TESTED.
<br>>
<br>>There are also things you can do which make this start up current
worse.&nbsp; A
<br>>generally rising voltage, that rises no faster than 2 milliseconds,
and no
<br>>slower than 50 milliseconds, and starts from near 0 Vdc (&lt; 300
mV) is
<br>always the
<br>>best way to go.&nbsp; Starting from a voltage around 450 mV to 700
mV from a
<br>>previously configured part, or holding INIT to prevent configuration,
or
<br>passing
<br>>through the POR trip point and then going below the POR trip point,
are
<br>common
<br>>causes of higher currents.
<br>>
<br>>In all cases, check the latest website data sheet.&nbsp; An example
is here:
<br>>
<br>><a href="http://www.support.xilinx.com/partinfo/ds005.pdf">http://www.support.xilinx.com/partinfo/ds005.pdf</a>
<br>>
<br>>page 2 of 16
<br>>
<br>>For parts that have virtually no current requirement at starup, use
the
<br>4KXLA,
<br>>4KXV, SpartanXL, or contact your sales office and FAE for assitance
in
<br>>selection.
<br>>
<br>>Austin Lesea
<br>>IC Design, Xilinx
<br>>
<br>>Alain Cloet wrote:
<br>>
<br>>> "Andy Peters n o a o [.] e d u>" &lt;"apeters &lt;"@> wrote in message
<br>>> <a href="news:8p6288$5k7$2@noao.edu">news:8p6288$5k7$2@noao.edu</a>...
<br>>> > Alexandr V Shuvalov wrote:
<br>>> >
<br>>> > > Which voltage regulators ICs are commonly used to power supply
Xilinx
<br>XL
<br>>> > > and other low voltage (3.3-2.5v) devices?
<br>>> >
<br>>> > I used a National LM3940IS-3.3 to drop a VME 5V supply down to
3.3V @ 1
<br>>> > A.
<br>>> >
<br>>> Can you power-up several Xilinx-FPGA's with this element ; or is
there a
<br>>> work-around ?
<br>>>
<br>>> We had this problem recently (not completelly solved), and the most
<br>recent
<br>>> idea is to supply 3 Xilinx FPGA's with one National LM3940 (other
version
<br>:
<br>>> WG ?).
<br>>>
<br>>> The element we used before had a fast power-up time which caused
the FPGA
<br>>> (4013) to take up to 1 A, and the regulator couldn't give 3A (it
went ok
<br>a
<br>>> normal temperature, but in a cold phase at -40C it didn't go).
<br>>>
<br>>> Can the LM3940 do the job ?
<br>>>
<br>>> TIA,
<br>>> Alain
<br>></blockquote>
</html>

--------------729D5D0462F71FF8CA870A85--

Article: 25369
Subject: IEEE 754 Floating point VHDL functions / MATH package
From: "Jaap H. Mol" <jh_mol@wxs.nl>
Date: Fri, 08 Sep 2000 19:02:27 +0200
Links: << >>  << T >>  << A >>

Hi,

I'm looking for VHDL (conversions) functions supporting the IEEE 754
floating point standard. To be more specific, I want to convert
variables 
of type "real" to the IEEE 754 floating point format (single precision,
32-bit), and vice versa.

In addition, I would greatly appreciate anyone who could direct me to
the (lastest version of) the (proposed?) VHDL MATH package.

Best regards,

Jaap Mol

Article: 25370
Subject: Mr Twisterz needs you
From: mrtwisterz@020.co.uk
Date: Fri, 08 Sep 2000 17:21:55 +0000
Links: << >>  << T >>  << A >>
Hi

There is a new free online adult personal ads site at www.twisterz.co.uk <http://www.twisterz.co.uk> ,
please visit and post your details and a photo if you wish.

Regards
Mr Twisterz




bDpDgEqB

Article: 25371
Subject: test
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Fri, 08 Sep 2000 17:30:56 GMT
Links: << >>  << T >>  << A >>
Pls ignore - my server not working
For Email remove "NOSPAM" from the address
Article: 25372
Subject: Re: DCT implementation using FPGA
From: Ray Andraka <ray@andraka.com>
Date: Fri, 08 Sep 2000 18:07:40 GMT
Links: << >>  << T >>  << A >>
Well, not exactly.

DCT is the summation   y[k]= c[k] sum_N(x[k]cos(pi*(2n+1)*k/2N))

You can use distributed arithmetic, but it is a bit more complicated than just
setting the constants because the 'constant' is a function of k and n.

kolja@prowokulta.org wrote:
> 
> This is from Ray Andraka's web site:
> http://www.andraka.com/distribu.htm
> 
> Choose the right C's and you got your DCT.
> 
> CU,
>         Kolja
> 
> In article <0d7t5.793$EW.854037@nnrp6.proxad.net>,
>   "Seb C" <Seb@stien.bizland.com> wrote:
> > Hi,
> >
> > I'm interested by pictures compressions, especially DCT, and if
> someone know
> > how to do a DCT into an FPGA, i take all what you have !!
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

-- 
-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  or http://www.fpga-guru.com
Article: 25373
Subject: VirtexE availability?
From: Andy Peters <"apeters <"@> n o a o [.] e d u>
Date: Fri, 08 Sep 2000 12:43:05 -0700
Links: << >>  << T >>  << A >>
I really hate to ask silly questions like this, but I hate calling the
distros because once you tell them you're thinking about considering
thinking about using a part in a design, they jump all over you because
they think you're gonna be writing a req for 10,000 parts tomorrow ...

I'm looking at doing a VirtexE design.  XCV50E should be big enough. 
Mainly, I want the LVDS I/O.  Are they available now, or will they be
available in the next couple of months?

Of course, I could probably do the design with external LVDS parts, but
this seems like a "neat" solution.

-- andy
----------------------------
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatory
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) n o a o [dot] e d u
Article: 25374
Subject: Numerically-Controlled Crystal Oscillator (NCXO) or Digitally-Controlled Crystal Oscillator (DCXO) Designs
From: nestor@stansync.com (Nestor)
Date: Fri, 08 Sep 2000 20:27:24 GMT
Links: << >>  << T >>  << A >>
Hi.

Does anyone know any manufacturer who fabricates
numerically-controlled crystal oscillators (NCXO), also known as
digitally-controlled crystal oscillators (DCXO) which are suitable for
digital phase-locked loop designs in VHDL and FPGAs?

Although these blocks resemble a numerically-controlled oscillator
(NCO), they differ in that the NCXO is not oversampled to generate the
required output signal (an NCO needs to be oversampled by at least
8-times in order to have an acceptable low jitter output).  Rather, a
digital input word is fed to the NCXO and it synthesizes the required
output frequency using a standard, low-cost crystal oscillator.  The
output is also a square wave, just like the standard crystal.  In
general, the NCXO has a narrow tuning range similar to a
voltage-controlled crystal oscillator (VCXO), e.g. +/-150ppm relative
to a frequency in the MHz range.

The NCXO technology is fairly recent from what I understand, but
allows one to replace a circuit composed of a digital-to-analog
converter (DAC) and a VCXO by one chip that performs the exact same
task will less design hassles.  The DCXO is ideal for custom-made
phase-locked loop (PLL) circuits using digital sections that can be
implemented in VHDL and FPGAs.

Since I haven't been able to find any NCXO manufacturers over the web,
I am now looking to the knowledgeable engineers, designers and friends
that frequent these newsgroups for some potential referrals and/or
links.

Thanks in advance for your help.

Nestor





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