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 38925

Article: 38925
Subject: Re: FPGA or Micro-controller in Lowpower designs?
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 28 Jan 2002 11:45:14 -0500
Links: << >>  << T >>  << A >>
Arash Salarian wrote:
> 
> Hi,
> 
> I'm starting a new design in which I'm using a multi-channel A/D with a low
> sampling-rate and Flash memory for the storage and the system is going to be
> powered by battery. In this stage, I'm not yet sure if using a FPGA would be
> wise, as I'm very concerned with the power consumption. The gate count of
> the circuit will be 3k~4k in my opinion so basically any medium Spartan
> family or even maybe XPLA would do. I've seen a device from ATmel (T87C5111)
> that consumes only 5mA and I guess is a good candidate too. This makes me
> hesitate to choose any FPGA over these types of micro-controller in designs
> were every bit of current matters..
> 
> Does anyone has experience in using FPGAs in low power applications and is
> there any suggestion in selection FPGAs over micros in these types of
> designs?
> 
> Regards
> Arash

I am not familiar with the T87C5111, but it appears to be an MCU. This
is not a bad way to go if you don't mind debugging software. 

Assuming that your application is very simple, you could go either way,
HW or SW. But I expect your power consumption would be better with an
MCU. The Xilinx XCR3128XL is a 3.3 volt device with a static Icc of
nearly 0. The power consumption is a function of frequency at about 0.5
mA/MHz according to the data sheet. If 128 is not enough macro cells,
then the XCR3256XL has 256 macro cells at about a 1 mA/MHz power curve. 

You might be able to do a little better with a low power micro,
expecially if you can use the on chip ADC. The MSP430 from TI has
several members which have a power consumption of well less than 1
mA/MHz including the ADC or get to the single digit uA at low KHz! The
high end chips are about $8 vs. ~$9/$15 for the XCR3128XL/XCR3256XL. The
MSP430F133 price gets below $5 including the 8 input ADC. 

But the MSP430 family is not 5 volt tolerant. So watch out for that.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 38926
Subject: Re: XC2V10000 still on the Xilinx roadmap?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 28 Jan 2002 09:17:09 -0800
Links: << >>  << T >>  << A >>
Markus,

The largest part is the 2V8000.  No real market for the 10K gate part
right now....we'll wait and see how the upturn goes.  Lots of demand for
the 2V6000 (shipments, too!).

Austin


Markus Wannemacher wrote:

> Hi all,
>
> the biggest part of Xilinx' Virtex-II family should be
> the XC2V10000 with 10 Mio. System gates.
> But I can't find anymore any information
> on this part on Xilinx' web.
>
> Only the press release:
> http://www.xilinx.com/prs_rls/silicon_vir/0207_EProd_PoY.html
> from Jan 23th 2002 still talks about 10 Mio. gates devices.
>
> Can anyone comment on this?
>
> Regards,
> Markus


Article: 38927
Subject: Re: Peaks in smaller PLDs
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 28 Jan 2002 18:38:33 +0100
Links: << >>  << T >>  << A >>
"Martin Fischer" <Martin.Fischer@fzi.de> schrieb im Newsbeitrag
news:a33a0k$ve@absalom.fzi.de...

> Yes, I mean glitches.
> Do you mean also the clock for the processes ?
>
> For example  I have a signal Zustandsfehler with glitches and an process
> Ladenabbrechen
> can I than ignore the glitches in my output signal Laden_abbrechen ?
>
> Ladenabbrechen : process (Abbruch, Zustandsfehler)
> Begin
>   if Abbruch='1' or Zustandsfehler='1'
>   then
>      Laden_abbrechen<='1';
>   else Laden_abbrechen<='0';
>   end if;
> end process Ladenabbrechen;

This is NOT a clocked process, its pure combinatorical. A "real" clocked
process is something like

process(clk)
begin
  if clk='1' and clk'event then
 . . . . . . ..
  end if;
end process;

If the rest of your design is a clean synchrounous design, the glitches on
the data signals dont matter.

--
MfG
Falk





Article: 38928
Subject: Re: Xilinx webpack
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 28 Jan 2002 18:56:26 +0100
Links: << >>  << T >>  << A >>
"Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
news:3C55764C.40E1023@earthlink.net...

> Russell, the question wa: How man diffrent functions can a LUT
> implement.
> And the answer is 64K.
> It only taks a few minutes to describe few hundred completely
> different ones, not counting input permutations.

I remember that there was a small file discussing the number of diffent
functions possible with a 4 input LUT, 2^16-permutations of inputs
But I cant find it anymore
www.fpga-faq.com ?? NO.

AFAIR the number was somewhere around 1800.

--
MfG
Falk





Article: 38929
Subject: Re: Problem with Altera programmer
From: Marcin E. Hamerla <mehamerla@pro.onet.pl>
Date: Mon, 28 Jan 2002 19:12:18 +0100
Links: << >>  << T >>  << A >>
Iwo Mergler napisal(a):

>> Sometimes these problems are helped by using an add-on
>> printer port card rather than the port on the motherboard.
>> 
>> "Marcin E. Hamerla" <mehamerla@.........pl> wrote
>> 
>> > According to Altera datasheet I made my own ByteBlaster programmer
>> > board for programming FLEXes and MAXes. Up to now everything worked
>> > with minor problems. There was only a limitation of the programmer
>> > cable lenght. Two weeks ago I have purchused a new fast computer
>> > (Athlon 1600+). Then I have  realized that I can not program any
>> > chips. Cutting the cable down to 20cm helped but it is rather
>> > difficult to work with such a short cable. Changing BIOS parallel port
>> > properties did not help - I tried this. And there is a question: are
>> > there any problems with the original ByteBlaster (LPT) board used with
>> > these new fast computers or I should rather go for USB programmer
>> > cable? Does it work with +5V chips? Is it expensive?
>
>Your new chipset probably uses 3.3V or less on the parport pins. That
>is borderline for driving 5V logic and with a long cable you push it
>over the edge. 
>
>The suggestion to use a add-on port is a good one. Another thing you
>can try is to pull the lines up to 5V (with resistors). This should 
>give a high-level of about 4V and may allow a longer cable.

Thanks a lot. I found different solution. It appears that exchanging
resistor values from 33ohm to 100ohm solves the problem.

-- 
Pozdrowienia, Marcin E. Hamerla

"Nienawidze turystow."

Article: 38930
Subject: Re: Peaks in smaller PLDs
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 28 Jan 2002 10:31:53 -0800
Links: << >>  << T >>  << A >>
Decoding glitches ( do you call them "Spitzen"?) are either innocent or a
disaster.

Innocent on the combinatorial signals in a fully synchronous ( clocked ) design,
as long as the glitches do not overlap the active clock edge ( which is never
the case in a single-clock synchronous design).

Disaster when they occur on a clock line, or on the asynchronous clear or preset
input to flip-flops and latches.

So it all depends.  You really cannot avoid glitches in complex decoding or data
routing structures. But you have to make sure they do not appear on any D-input
during the active clock edge.

Peter Alfke, Xilinx Applications
=======================================
Martin Fischer wrote:

> > What do you mean with peaks?? small pulses (glitches) on data signals.
> This
> > is just normal an ca be ignored in 99% of all cases. But your clock
> signals
> > must be absolutely glitch free.
>
> Yes, I mean glitches.
> Do you mean also the clock for the processes ?
>
> For example  I have a signal Zustandsfehler with glitches and an process
> Ladenabbrechen
> can I than ignore the glitches in my output signal Laden_abbrechen ?
>
> Ladenabbrechen : process (Abbruch, Zustandsfehler)
> Begin
>   if Abbruch='1' or Zustandsfehler='1'
>   then
>      Laden_abbrechen<='1';
>   else Laden_abbrechen<='0';
>   end if;
> end process Ladenabbrechen;
>
> Thanks
>
> Martin


Article: 38931
Subject: Re: Simple shift register not working (update)
From: Kevin Goodsell <goodsell@bridgernet.com>
Date: Mon, 28 Jan 2002 19:04:23 GMT
Links: << >>  << T >>  << A >>
On 27 Jan 2002 18:41:17 -0800, newman5382@aol.com (newman) wrote:

>Kevin Goodsell <goodsell@bridgernet.com> wrote in message news:<k4t55u4lf2n5bnppbagfog8e8jbqcipesj@4ax.com>...
>> Thanks for the additional comments. I've discovered a few things since
>> my last post:
>> 
>> The lines I was using as inputs to the FPGA are at least part of the
>> problem - they seem to be too weak. I added non-inverting buffers and
>> it *almost* works. Strangely, the FPGA seems to be registering
>> positive clock edges where it shouldn't. Sometimes this is on a
>> negative edge, sometimes not. It seems like the clock is too noisy,
>> but it looks pretty clean on the oscilloscope. I tried creating a
>> Schmitt trigger using the trick with two resistors and an extra I/O
>
>If you have a slow clock and look at it on the oscilloscope, it may
>look perfect cause you have the timescale zoomed out.  Measure the
>rise time and the fall time of your clock.  I suspect it is too slow,
>and the cmos inputs are interpreting this as multiple clocks per
>transition.
>
>Newman

Possible. The rise time, IIRC, was around 220 ns. I would guess that
this is fast enough, but I don't know.

-Kevin

Article: 38932
Subject: Re: Simple shift register not working (update)
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Mon, 28 Jan 2002 11:29:42 -0800
Links: << >>  << T >>  << A >>

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



Kevin Goodsell wrote:

>
> Possible. The rise time, IIRC, was around 220 ns. I would guess that
> this is fast enough, but I don't know.
>
> -Kevin

Not fast enough for a clock nowadays.
Can you spare an output and create some input hysteresis?
Better still, terminate the clock line so that it has nochance to ring...
You might also click on the following for some internal remedy.

http://www.xilinx.com/xcell/xl34/xl34_54.pdf

Peter Alfke, Xilinx Applications




Article: 38933
Subject: Re: Books on DSP
From: Ray Andraka <ray@andraka.com>
Date: Mon, 28 Jan 2002 19:31:20 GMT
Links: << >>  << T >>  << A >>
There is a new book out by Uwe Meyer-Baese titled "Digital Signal Processing with
FIeld Programmable Gate Arrays" (
http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/102-6110898-2675311)
that is well written and covers many of the aspects of DSP with FPGAs.  It is
featured on the bookstore page on my website (links to Amazon: if you use the
link above or go through my website I get a kickback which helps to support the
website).  I very highly recommend this book.

For FPGAs we only use floating point where it really is necessary.  Most
applications don't need floating point at all (but you do have to work a little
harder to track your scaling).  Those that do usually need a much smaller range
of exponents than what is provided in typical DSP micros.  Floating point
multiplies aren't much more complicated than a fixed point multiply: just an
adder for the exponents, a 2:1 mux to renormalize the output and an increment to
readjust the exponent if the product needed adjustment.  Floating point adds are
where the cost comes in.  In that case, you need a compare to determine which
exponent is bigger, and exchange network (pair of 2:1 muxes) to steer the smaller
addend through a shifter, a barrel shifter to right shift the smaller addend by
the difference in the exponents, a fixed point adder to sum the equally weighted
mantissas, then a normalizing barrel shift to renormalize the sum, and an adder
to adjust the exponent to reflect the renormalization.  A floating point adder
uses about the same resources as a multiplier with the same width in an FPGA.
Needless to say, we try to avoid the floating point adds.   One trick I often use
is to process a string of operations on a fixed point mantissa and then
renormalize at the end of the series.  You can do floating point arithmetic in
any FPGA that you can do fixed point arithmetic in, it just uses more resources.

FIR filters, in nearly all cases are better done using fixed point arithmetic in
FPGAs.  IIR filters can be done fixed point if you are careful to carry enough
precision, round carefully to eliminate any DC biases, and choose your
coefficients carefully.  These can also be done with distributed arithmetic, as
long as the output is available back at the input within a sample time, which
means you can't use deep pipelining.  The performance is limited by not being
able to deeply pipeline, but you can easily do a biquad that works at sample
rates under 10 MHz using serial distributed arithmetic in current FPGAs.
Generally, IIR filters are not a real good fit to FPGAs, even when done fully
parallel because the first order feedback has to get back to the input within a
sample interval.  That limits the performance no matter what the implementation
is.

Tom wrote:

> Hi,
>
> I am sorry to disappoint you but there really are no books that I am aware of
> which focus on DSP in FPGAs. The reason, in my opinion, is as follows..
>
> DSP is a tough enough topic to engage in when we are in the floating point
> world and FPGAs do not have floating point multipliers. (Please, everybody,
> don't email me that there is a floating point core available somewhere  ;-)
> ). Even the Virtex 2 devices  with multipliers can only implement "Fixed
> Point" aritithmetic. Since, for digital filters, one of the inputs to the
> multiplier is always known (the coefficients) a particularly efficient
> (area-wise) method of doing fixed point math is called "Bit Serial
> Arithmetic". There are some good articles on Bit Serial stuff. One was
> written by Peter Alfke, who now writes Xilinx application notes. It has a
> title something like "The role of distributed arithmetic in FPGA design".
> There are also articles by the late Les Mintzer, which are quite good (I
> would have to dig out in the garage for the title and I am sure that a quick
> internet search would find it quicker). Mintzer also wrote the last chapter
> in the "DSP Applications Handbook" (I hope that the title is close to being
> right), which is a really good book to have except for the fact that it
> usually goes for more that $100 (I am way too cheap, times being what they
> are). Ray Andraka has a web site dedicated to FPGA stuff which has examples
> of arithmetic forms other than Bit Serial.
>
> One other thing that I should mention is that doing IIR filters or any
> filters of a recursive nature, in Distributed Arithmetic, while very
> possible, is really difficult. The fiixed point scaling issue and especially
> the feedback to the first order recursive output (say, Y(n-1) ) can be
> tricky.
>
> I hope that this helps.
>
> Tom Cipollone
>
> Przemyslaw Wegrzyn wrote:
>
> > Hello !
> >
> > I'm looking for some books about implementing DSP algorithms in FPGA. Can
> > someone advise any title ?
> >
> > -=Czaj-nick=-

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38934
Subject: Re: path for Vital component in assert?
From: Brian Philofsky <brian.philofsky@xilinx.com>
Date: Mon, 28 Jan 2002 12:35:26 -0700
Links: << >>  << T >>  << A >>


David,

   Perhaps this has been answered however I have been told to use the
-ext (-extassertmsg) switch when invoking ncsim to get the full path to
the affected instance.  I have not tried it myself but hopefully this
will give you th info you need.


--  Brian



David Rogoff wrote:

> Hi.
>
> I am doing a gate-level/back-annotated simulation of am FGPA. It's a
> Xilinx Virtex E, using the simprims library (ISE 4.1).  I'm using
> Cadence ncvhdl/ncsim.  I've got a few timing violation messages, but
> they don't have the path to the offending component and/or the signal
> names involved.  Here's one example:
>
> ASSERT/WARNING (time 8970249 PS) from procedure
> @ieee.VITAL_Timing:ReportViolation
> */X_FF SETUP  Low VIOLATION ON I WITH RESPECT TO CLK;  Expected :=
> 0.271 NS; Observed := 0.11 NS; At : 8970.249 NS
>
> I'm used to Verilog, and having the full path shown in the timing
> violation.  Is this a problem with the Xilinx library?  Is there some
> switch setting I can change?
>
> Thanks,
>
>  David


Article: 38935
Subject: Re: Simple shift register not working (update)
From: Ray Andraka <ray@andraka.com>
Date: Mon, 28 Jan 2002 19:42:11 GMT
Links: << >>  << T >>  << A >>
That's really really slow.  It should be at least 20 times faster (a couple of ns at most).  With that kind of
switching speed, it lingers in the threshold region for quite a while.  Any noise on the signal or even on the
power supplies wil cause multiple transitions to be detected.  That includes the small shifts due to that input
switching.  Are you sure you did the hysteresis circuit correctly?

Kevin Goodsell wrote:

> On 27 Jan 2002 18:41:17 -0800, newman5382@aol.com (newman) wrote:
>
> >Kevin Goodsell <goodsell@bridgernet.com> wrote in message news:<k4t55u4lf2n5bnppbagfog8e8jbqcipesj@4ax.com>...
> >> Thanks for the additional comments. I've discovered a few things since
> >> my last post:
> >>
> >> The lines I was using as inputs to the FPGA are at least part of the
> >> problem - they seem to be too weak. I added non-inverting buffers and
> >> it *almost* works. Strangely, the FPGA seems to be registering
> >> positive clock edges where it shouldn't. Sometimes this is on a
> >> negative edge, sometimes not. It seems like the clock is too noisy,
> >> but it looks pretty clean on the oscilloscope. I tried creating a
> >> Schmitt trigger using the trick with two resistors and an extra I/O
> >
> >If you have a slow clock and look at it on the oscilloscope, it may
> >look perfect cause you have the timescale zoomed out.  Measure the
> >rise time and the fall time of your clock.  I suspect it is too slow,
> >and the cmos inputs are interpreting this as multiple clocks per
> >transition.
> >
> >Newman
>
> Possible. The rise time, IIRC, was around 220 ns. I would guess that
> this is fast enough, but I don't know.
>
> -Kevin

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38936
Subject: Re: Simple shift register not working (update)
From: Bob Perlman <no-spam@sonic.net>
Date: Mon, 28 Jan 2002 19:48:34 GMT
Links: << >>  << T >>  << A >>
Hi - 

On Mon, 28 Jan 2002 19:04:23 GMT, Kevin Goodsell
<goodsell@bridgernet.com> wrote:

>On 27 Jan 2002 18:41:17 -0800, newman5382@aol.com (newman) wrote:
>
>>Kevin Goodsell <goodsell@bridgernet.com> wrote in message news:<k4t55u4lf2n5bnppbagfog8e8jbqcipesj@4ax.com>...
>>> Thanks for the additional comments. I've discovered a few things since
>>> my last post:
>>> 
>>> The lines I was using as inputs to the FPGA are at least part of the
>>> problem - they seem to be too weak. I added non-inverting buffers and
>>> it *almost* works. Strangely, the FPGA seems to be registering
>>> positive clock edges where it shouldn't. Sometimes this is on a
>>> negative edge, sometimes not. It seems like the clock is too noisy,
>>> but it looks pretty clean on the oscilloscope. I tried creating a
>>> Schmitt trigger using the trick with two resistors and an extra I/O
>>
>>If you have a slow clock and look at it on the oscilloscope, it may
>>look perfect cause you have the timescale zoomed out.  Measure the
>>rise time and the fall time of your clock.  I suspect it is too slow,
>>and the cmos inputs are interpreting this as multiple clocks per
>>transition.
>>
>>Newman
>
>Possible. The rise time, IIRC, was around 220 ns. I would guess that
>this is fast enough, but I don't know.

That's nowhere near fast enough.  Your clock signal is spending so
much time making it through the transition region that small amounts
of noise can make the FPGA see multiple clock pulses.  Try for a
risetime under 5ns.

Just out of curiousity: what are you driving the clock with (i.e.,
chip type, net topology) that gives you a risetime of 220ns?

Bob Perlman
--
Cambrian Design Works
digital design, signal integrity
http://www.cambriandesign.com
e-mail: respond to bob at the domain above.

Article: 38937
Subject: Re: Books on DSP
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Mon, 28 Jan 2002 19:57:41 -0000
Links: << >>  << T >>  << A >>
And it is popular - Amazon.com Sales Rank: 539,591 :)

"Ray Andraka" <ray@........com> wrote

> There is a new book out by Uwe Meyer-Baese titled "Digital Signal Processing
with
> FIeld Programmable Gate Arrays" (
> http://www.amazon.com/exec/obidos/ASIN/3540413413/andraka/102-6110898-2675311)
> that is well written and covers many of the aspects of DSP with FPGAs.





Article: 38938
Subject: Spartan-2E data sheet (ds077_x.pdf)
From: atali@cygrp.com (Aare Tali)
Date: 28 Jan 2002 12:10:42 -0800
Links: << >>  << T >>  << A >>
Hi!

I'm looking at this data sheet and wondering... It seems to be
copy-paste-search-and-replace of Spartan 2 data sheet. However, this
doesn't seem to be consistent.

           BlockRAM   JTAG  ID   Bitstream    DLL
XC2S200      56K       ???????     1335840     4
XC2S200E     56K       ???????     1442016     4
XCV200E     112K      v0A1C093h    1442016     8

When I connect Impact to XC2S200E the chip is identified as XCV200E
(ID 10A1C093), so I assume JTAG ID is same as for Virtex-E device.
Bitstream is said to be same size. But almost everything else in the
data sheet is copy-paste from Spartan-2 data sheet and doesn't match
Virtex-E.

Which data sheet is correct for the Spartan-2E? For now I would assume
that I have to use Virtex-E data sheet for internal structure and hope
that nothing was changed in PQ208 package from XC2S200 to XC2S200E
device.

Article: 38939
Subject: Re: Dynamic Reconfiguration of single Xilinx FPGA
From: "Alex Carreira" <aycarrei@shaw.ca>
Date: Mon, 28 Jan 2002 13:43:56 -0700
Links: << >>  << T >>  << A >>
I think I must have misinterpreted your original mail as I thought you
wanted to do reconfigurations with just the XC4000 and nothing more (ie no
PAL, ROM, SRAM etc.)

Hope things work out for you Fong.  (I would have replied sooner, but I was
stuck on a mountain with no cell towers.)

Alex :)





Article: 38940
Subject: Re: Simple shift register not working (update)
From: Kevin Goodsell <goodsell@bridgernet.com>
Date: Mon, 28 Jan 2002 20:58:27 GMT
Links: << >>  << T >>  << A >>
On Mon, 28 Jan 2002 19:48:34 GMT, Bob Perlman <no-spam@sonic.net>
wrote:

>
>Just out of curiousity: what are you driving the clock with (i.e.,
>chip type, net topology) that gives you a risetime of 220ns?
>
>Bob Perlman


Well, I may not be remembering the time correctly. I can't test it
again at the moment because I'm snowed in at home today.

Anyway, the clock is being driven from the I/O lines of a
microprocessor called an AIC (Advanced Instrument Controller). I don't
think it is very widely used, but it is basically a modified Intel
8051 built to tolerate more extreme conditions (originally designed
for use is space, I think). Also, I think it is designed to be
extremely low power, which might be part of the problem (?).

The I/O lines are different from a standard 8051. The directions are
controlled by a set of internal registers. That's about all I know
about it. (I'm a software guy, which probably goes a long way to
explain all the problems I'm having. ;) )

Actually, coming directly off the AIC, the rise time was much slower -
around 20 times slower, I think. We are going through a buffer to
strengthen the signal, and the rise time of the signal from that
buffer is the one I'm claiming was about 220 ns.

-Kevin

Article: 38941
Subject: Re: Simple shift register not working (update)
From: Kevin Goodsell <goodsell@bridgernet.com>
Date: Mon, 28 Jan 2002 20:59:49 GMT
Links: << >>  << T >>  << A >>
On Mon, 28 Jan 2002 04:18:57 GMT, Bob Perlman <no-spam@sonic.net>
wrote:

>Hi - 
>
>What's the bandwidth of your 'scope?  You're going to need something
>on the order of at least 700MHz bandwidth for the probe and scope
>combined (and I'm talking bandwidth, not sampling rate) to see a
>1ns-wide glitch on a clock edge.
>
>Those 100MHz-bandwidth scopes can make a glitchy signal look mighty
>fine.  Sometimes it's a good idea to keep one in the lab just to boost
>morale.
>
>Bob Perlman

LOL :)

I think that's exactly what I've been using. I can't say that I've
seen the morale-boosting effects yet, though.

-Kevin

Article: 38942
Subject: Re: Pin assignment on ACEX1K
From: Kevin Brace <ihatespamkevinbraceusenet@ihatespamhotmail.com>
Date: Mon, 28 Jan 2002 15:01:23 -0600
Links: << >>  << T >>  << A >>
heyho wrote:
> 
> Hi,
> 
> 
> BTW, Kevin, why should he use Spartan IIs? ACEX devices are great! This should be a newsgroup which discusses technical questions and not stupid stuff what device is a few cents cheaper than another one. This kind of information hich cannot be proven anyway!!



        The reasons why I think the original poster should try out
Spartan-IIs are because, 

1) Roughly speaking, Spartan-II speed grade -5 and ACEX 1K speed grade
-1 should provide similar performance in random logic (state machine),
but Spartan-II has a faster speed grade -6 part, and that part should be
faster than ACEX 1K speed grade -1. 


2) Regardless of what you say about saving money, for similar
performance, I will rather pay less for something similar. Again,
comparing Arrow's pricing for buying one ACEX 1K and Insight
Electronics' pricing for buying one Spartan-II, Spartan-II is much
cheaper ($30 to $40 for Spartan-II -5 or -6 vs. over $90 for ACEX 1K-1)
The prices here are what I saw on their websites a few months ago.



3) Altera doesn't offer a starter version of ModelSim like Xilinx does
(ModelSim XE-Starter). Sure, Xilinx says that ModelSim XE-Starter has a
500-line code limitation, but the simulation only gets pretty slow after
that, and the simulation will be done at some point. The simulator
Altera offers with MAX+PLUS II-BASELINE and Quartus II 1.1 Web Edition
is not an HDL-based simulator, and only a waveform can be entered.
Frankly, I find writing test code for HDL-based simulation much faster
than entering test waveforms into a waveform editor.


4) Very few vendors that I know offers ACEX 1K-based development board
versus several (Insight Electronics, Avnet, etc.) for Spartan-II.



        One thing to note is that here I am comparing Xilinx's free
tools versus Altera's free tools because I think the original poster who
is thinking of using ACEX 1K should at least try it out and see how
Spartan-II fares.
Yes, if the original poster already owns the paid version of MAX+PLUS
II, Quartus II, or ModelSim-AE,  doesn't want to learn another vendor's
tools, or the original poster's design already heavily uses vendor
specific features like LPM or EAB, those are legitimate reasons to keep
using Altera tools/devices, but that will still make the original
poster's product less competitive in the market, or will make less
profit.
I will rather use Spartan-II over ACEX 1K, and make more profit per
board or sell more boards for less, unless ACEX 1K is so much better
than Spartan-II in something.




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

Article: 38943
Subject: Re: Simple shift register not working (update)
From: Kevin Goodsell <goodsell@bridgernet.com>
Date: Mon, 28 Jan 2002 21:06:36 GMT
Links: << >>  << T >>  << A >>
On Mon, 28 Jan 2002 05:18:01 GMT, Ray Andraka <ray@andraka.com> wrote:

>What is your board like?

The FPGA is on a Spartan 2 Demo Board from Insight Electronics. The
clock and data lines are coming from a completely separate board
(described a little in my other post).

> Is the FPGA properly decoupled, and does it have
>good low impedance paths from the power plane? 

Er...

<Kevin scratches his head>

>HOw about your signal
>integrity, especially on the clock.  Are the edges really clean (keep in
>mind the chip is fast enough to react to a sub-nanosecond pulse on the
>clock)?

As far as I can tell they are clean, but from what I'm hearing that
doesn't mean much.

>Are the clock levels correct?

Pretty sure.

>Do you see any evidence of ground
>bounce on the output signals?

No, but again that probably doesn't mean much.

>Are your edge rates fast enough (if being
>driven by some of the older CMOS families, they may not be)?

Probably not.

-Kevin

Article: 38944
Subject: Re: Spartan-2E data sheet (ds077_x.pdf)
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 28 Jan 2002 13:12:54 -0800
Links: << >>  << T >>  << A >>
Aare,

Spartan IIE has its own test program, so its data sheet applies, no
others.

As for the silicon JTAG IDCODE, that will change as masks and revisions
change, so never use that to "guess" which device you have, you have what
the device is marked as.

Austin

Aare Tali wrote:

> Hi!
>
> I'm looking at this data sheet and wondering... It seems to be
> copy-paste-search-and-replace of Spartan 2 data sheet. However, this
> doesn't seem to be consistent.
>
>            BlockRAM   JTAG  ID   Bitstream    DLL
> XC2S200      56K       ???????     1335840     4
> XC2S200E     56K       ???????     1442016     4
> XCV200E     112K      v0A1C093h    1442016     8
>
> When I connect Impact to XC2S200E the chip is identified as XCV200E
> (ID 10A1C093), so I assume JTAG ID is same as for Virtex-E device.
> Bitstream is said to be same size. But almost everything else in the
> data sheet is copy-paste from Spartan-2 data sheet and doesn't match
> Virtex-E.
>
> Which data sheet is correct for the Spartan-2E? For now I would assume
> that I have to use Virtex-E data sheet for internal structure and hope
> that nothing was changed in PQ208 package from XC2S200 to XC2S200E
> device.


Article: 38945
Subject: glitchless clock enable/disable in spartanII
From: "Theron Hicks" <hicksthe@egr.msu.edu>
Date: Mon, 28 Jan 2002 16:17:26 -0500
Links: << >>  << T >>  << A >>
I am looking for some code to define a glitch less clock enable/disable
circuit.  The clock frequency is 100MHz.  What I am trying to say is that I
have a counter with a 100MHz clock and I want to avoid runt pulses on the
clock.  This could either be a clock mux switching between 0 and clock on
the output or a "safe" clock enable that would eliminate (or at least
minimize) the possibility of metastability.  The counter could be
asynchronous if that simplifies things.  Any ideas, suggestions, sources,
etc.

Thanks,
Theron



Article: 38946
Subject: Re: Peaks in smaller PLDs
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 28 Jan 2002 22:24:27 +0100
Links: << >>  << T >>  << A >>
"Peter Alfke" <peter.alfke@xilinx.com> schrieb im Newsbeitrag
news:3C559919.A017798E@xilinx.com...

> Disaster when they occur on a clock line, or on the asynchronous clear or
preset
> input to flip-flops and latches.

Also disasterous when glitches happen on the D input of a " should be"
latch. What does this mean? We once did a VHDL design in a XC95xx and wanted
some latches. The compiler said, blabla . .latches inferred. Hmm, but this
was a D-FlipFlop whit the cler/set inputs wired weird to "emulate" a latch.
:-((

> So it all depends.  You really cannot avoid glitches in complex decoding
or data
> routing structures. But you have to make sure they do not appear on any
D-input

Hmm, Iam curious how much these glitching contributes to power consumption?.
Just recently we had a presentation from our FAE about the new
Coolrunner-II, where everything was tried to save the last uA (disabeling
inputs to prevent internel nets from toggeling etc.)

--
MfG
Falk





Article: 38947
Subject: Re: Xilinx webpack
From: Ray Andraka <ray@andraka.com>
Date: Mon, 28 Jan 2002 21:55:25 GMT
Links: << >>  << T >>  << A >>
I remember that too, and I'm pretty sure it was Phil Freidin that posted
the number.  I couldn't find it in the FAQ or the archive either.

Falk Brunner wrote:

> "Peter Alfke" <palfke@earthlink.net> schrieb im Newsbeitrag
> news:3C55764C.40E1023@earthlink.net...
>
> > Russell, the question wa: How man diffrent functions can a LUT
> > implement.
> > And the answer is 64K.
> > It only taks a few minutes to describe few hundred completely
> > different ones, not counting input permutations.
>
> I remember that there was a small file discussing the number of diffent
> functions possible with a 4 input LUT, 2^16-permutations of inputs
> But I cant find it anymore
> www.fpga-faq.com ?? NO.
>
> AFAIR the number was somewhere around 1800.
>
> --
> MfG
> Falk

--
--Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 38948
Subject: Spartan II power-up current - again
From: "Tim" <tim@rockylogic.com.nooospam.com>
Date: Mon, 28 Jan 2002 22:06:49 -0000
Links: << >>  << T >>  << A >>
Sorry to return to this topic yet again...

XAPP450/451 show the SpartanII power-up current requirement as
500mA for _all_ parts, provided the temperature requirements
are met.

However, I have a distant recollection that someone (Austin?)
has at one time posted that the smaller parts need less than
this?  Any ideas on the slope of the curve from the 2S15
to the 2S200?

I am particularly interested in the 2S30.





Article: 38949
Subject: QuartusII Timing Analysis
From: "Jaap H. Mol" <jaap.mol@planet.nl>
Date: Mon, 28 Jan 2002 23:08:51 +0100
Links: << >>  << T >>  << A >>
Hi,

Does anyone know how to perform (Static) Timing Analysis within QuartusII
without only comparing against explicitly defined timing constraints, but
just an interactive post-processing kind of job?

It is my impression that other FPGA vendors (like Xilinx or Actel) have
better solutions in this area, since they also offer seperate timing
analysis tools (TRACE and DT ANALYSE, respectively). In addition, they also
support min/max values, whereas Altera seems to be thinking that only max
values are sufficient (for setup-time), not keeping in mind that min timing
values can give you indications of potential hold-time problems.

Does anyone have similar experiences, opinions, etc.???


Best regards,


Jaap Mol





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