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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 74650

Article: 74650
Subject: Re: which xilinx CPLD to select?
From: ben@ben.com (Ben Jackson)
Date: Fri, 15 Oct 2004 18:19:33 GMT
Links: << >>  << T >>  << A >>
In article <41700734.669C9E48@yahoo.com>, rickman  <john@bluepal.net> wrote:
>"vax, 9000" wrote:
>> 
>> 1. 3.3V or 5V parts (compatible with TTL/HTCmos)
>> 7. low cost
>
>I can tell you that item 1, 5 and 7 are hard to combine.  The Xilinx
>parts that might do best are the Coolrunner (not Coolrunner II)

If I remember right, I think the best combination of 5V tolerant and
cheap is XC9500XL.  Straight XC9500 has a price premium now, and XV is
not 5V tolerant.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Article: 74651
Subject: Re: spartan 3 on 4 layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 15 Oct 2004 11:32:23 -0700
Links: << >>  << T >>  << A >>
Rick,
I agree. As I said in another post in this thread, point-of-load supplies
are useful, but as long as you keep them on the board where they're used,
their position relative to the FPGA makes bugger all difference. They're low
enough in area/height/power wastage these days to place in the bits of pcb
'tundra' you often get between connectors and the like!
Cheers, Syms.
"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:416F6DB9.9DBF780F@yahoo.com...
> Symon wrote:
>
> I think he was addressing the comments about keeping the PSU near the
> chips.  I have *never* heard anyone recommend that PSU placement would
> affect the need for good PCB design.  The range of frequencies that PSU
> selection or placement would affect is way below the range of freqencies
> that would be affected by PCB layout.



Article: 74652
Subject: Re: spartan 3 on 4 layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 15 Oct 2004 11:33:46 -0700
Links: << >>  << T >>  << A >>
Austin,
PCB ground bounce? But this thread is about not having PCB power planes.
No-one's suggesting doing without a ground plane. That's the main (only!)
weapon against ground bounce. The loop-inductance you're taking about that
carries the return current is then between the FPGA and it's decoupling
capacitors. The ground plane ensures the power supply doesn't bounce
relative to the decoupled supply at the FPGA.
If you're talking about ground bounce on the silicon, then all we PCB
designers can do is firmly bolt down the ground pins to the PCB ground
plane. A power plane, or lack thereof, isn't gonna affect ground bounce
after that.
Also, when you say in a previous post 'If you do not have both a power and a
ground plane for each of these supplies, the SSO numbers must be reduced.',
I'd disagree. You probably must have a ground plane, but throwing separate
layers at supplies for Vcco, Vccint, Vccaux, Rocket I/O supplies is a little
excessive! It's easier to use this methodology, and certainly easier for
Xilinx to support, but you can get as good results by using one or two
layers to share supplies locally at the FPGA. You can also use this layer
for other things away from the FPGA. To do this, your decoupling must be
good at the FPGA, and the connection between the supply and the local plane
must be able to supply the current needed.
You're also, IMHO, better off having multiple ground planes, and routing the
power.
Finally, I'd be interested in how increasing bypass capacitance can make
ground bounce worse in the same system, especially one with a ground plane?
More energy stored? di larger? dt faster? What?
Cheers, Syms.
"Austin Lesea" <austin@xilinx.com> wrote in message
news:ckomo5$s21@cliff.xsj.xilinx.com...
> Tom,
>
> There is no "C" in Ldi/dt.
>
> If you can find out how varying a capacitance in any way changes the
> induced bounce (V=-Ldi/dt), let me know.
>
> Bypass capacitance prevents rail collapse, but it does nothing to
> prevent ground bounce (it can actually make it worse, as there is more
> energy stored which makes di larger and dt faster).
>
> Austin
>




Article: 74653
Subject: Re: WebPACK post-PAR min clock period?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Oct 2004 15:02:46 -0400
Links: << >>  << T >>  << A >>
Eric Smith wrote:
> 
> rickman <spamgoeshere4@yahoo.com> writes:
> > I am not aware that they *don't* report a max clock speed, but it is
> > very unusual to care about clock speed if you don't spec a requirement.
> > If you don't use a speed constraint, the tool assumes you don't care
> > about the speed and just does a route without any optimization.  Isn't
> > that obvious?
> 
> No, it's not obvious.  You could just as easily say that an automaker
> shouldn't include a speedometer in a new car unless you tell the dealer
> how fast you plan to drive.
> 
> If I give an explicit constraint, I want the tools to work harder (if
> necessary) to try to meet it, but that doesn't mean that if I don't give
> a constraint that I don't care about it at all.  By that reasoning it
> would be fine for the tools to produce a design with a minimum clock
> period of a fortnight.

I don't understand your point.  If you don't tell the tool what an
acceptable clock period is, then how is the tool supposed to know the
difference between a nanosecond and a fortnight?  Tools are not people,
they can't reason.  Besides, how would *I* know what you find an
acceptable clock period if you don't tell me?  I still see systems that
are clocked well below 10 MHz.  

-- 

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: 74654
Subject: Re: which xilinx CPLD to select?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Oct 2004 15:07:26 -0400
Links: << >>  << T >>  << A >>
Ben Jackson wrote:
> 
> In article <41700734.669C9E48@yahoo.com>, rickman  <john@bluepal.net> wrote:
> >"vax, 9000" wrote:
> >>
> >> 1. 3.3V or 5V parts (compatible with TTL/HTCmos)
> >> 7. low cost
> >
> >I can tell you that item 1, 5 and 7 are hard to combine.  The Xilinx
> >parts that might do best are the Coolrunner (not Coolrunner II)
> 
> If I remember right, I think the best combination of 5V tolerant and
> cheap is XC9500XL.  Straight XC9500 has a price premium now, and XV is
> not 5V tolerant.

I don't have full pricing in front of me, but the newest CPLD part from
Xilinx that has 5 volt tolerance is the XCR3xxxXL family, so I would
expect these to be the cheapest.  They are 3.3 volt supply and are near
zero power as well.  But like most CPLDs they get very pricey as the
size goes up!  

-- 

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: 74655
Subject: How many Altera LE's to Xilinx Slices????
From: ericjohnholland@hotmail.com (Guitarman)
Date: 15 Oct 2004 12:12:31 -0700
Links: << >>  << T >>  << A >>
Hello All,

I've been designing with Xilinx FPGAs for a while so I'm used to the
"Slice" concept. I'm looking at Altera's Max II as a nice possible
solution for a design.

I took my VHDL code and it synthesized to 40 Slices in a Spartan III.
Then I took the same code and sythesized it for a Max II (using
Quartus II now) and it was 71 LE's.

I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly
dependant on how the code is sysnthesized.

But is a approximate 1 Slice = 2 LE's a pretty close all around
estimate.

Thanks
Eric

Article: 74656
Subject: Re: WebPACK post-PAR min clock period?
From: hmurray@suespammers.org (Hal Murray)
Date: Fri, 15 Oct 2004 14:17:34 -0500
Links: << >>  << T >>  << A >>
>I don't understand your point.  If you don't tell the tool what an
>acceptable clock period is, then how is the tool supposed to know the
>difference between a nanosecond and a fortnight?  Tools are not people,
>they can't reason.  Besides, how would *I* know what you find an
>acceptable clock period if you don't tell me?  I still see systems that
>are clocked well below 10 MHz.  

The tools could at least tell me what the worst case clock-clock
time is for each clock.  That's not rocket science.  And maybe
even give a warning for not specifying the appropriate constraints.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 74657
Subject: What is role of place & route tools in synthesis in vhdl.& HOW THE AREA & time constrain are specifiesd in XIlinx or modelsim software?
From: bansal.dhanraj@gmail.com (BANSAL DHAN RAJ)
Date: 15 Oct 2004 12:44:44 -0700
Links: << >>  << T >>  << A >>
hi all
What is role of place & route tools in synthesis in vhdl.& HOW THE
AREA & time constrain are specifiesd in XIlinx or modelsim software?
Can LabVIEW be used for programming of ALTERA or XILINX boards or
LabVIEW7 is meant for configuring the FPGA h/w of NATIONAL INSTRUMENTS
only
-----BANSALdhan raj

Article: 74658
Subject: Re: Xilinx VirtexE internal oscillator
From: gabor@alacron.com (Gabor Szakacs)
Date: 15 Oct 2004 12:46:27 -0700
Links: << >>  << T >>  << A >>
>From the datasheet:

The CCLK frequency is set using the ConfigRate option in
the bitstream generation software. The maximum CCLK frequency
that can be selected is 60 MHz. When selecting a
CCLK frequency, ensure that the serial PROM and any
daisy-chained FPGAs are fast enough to support the clock
rate.
On power-up, the CCLK frequency is approximately
2.5 MHz. This frequency is used until the ConfigRate bits
have been loaded when the frequency changes to the
selected ConfigRate. Unless a different frequency is specified
in the design, the default ConfigRate is 4 MHz.

It doesn't specify whether the internal oscillator stops running
when config is complete, but the CCLK output certainly does.  Since
Virtex no longer allows user access to the internal CCLK oscillator
I don't see why they would leave it running.

Stefan Tillich <stefanti@gmx.at> wrote in message news:<416e8f73$0$11614$3b214f66@aconews.univie.ac.at>...
> Hi,
> 
> Does anyone know the frequency of the internal oscillator of Xilinx 
> VirtexE FPGAs which is used to generate the CCLK for Master-Serial 
> configuration mode? I'm aware that the datasheet specifies 4 MHz as 
> default CCLK frequency but that isn't necessarily identical to the 
> frequency of the oscillator.
> 
> What's the behavior of this oscillator after configuration? Is it turned 
> off or can it be disabled through some option in the bit file?
> 
> Regards
> 
> Stefan Tillich

Article: 74659
Subject: Re: which xilinx CPLD to select?
From: ben@ben.com (Ben Jackson)
Date: Fri, 15 Oct 2004 19:49:46 GMT
Links: << >>  << T >>  << A >>
In article <41701FEE.E5673855@yahoo.com>, rickman  <john@bluepal.net> wrote:
>Ben Jackson wrote:
>> If I remember right, I think the best combination of 5V tolerant and
>> cheap is XC9500XL.  Straight XC9500 has a price premium now, and XV is
>> not 5V tolerant.
>
>I don't have full pricing in front of me, but the newest CPLD part from
>Xilinx that has 5 volt tolerance is the XCR3xxxXL family,

I guess the original poster wanted "5V TTL compatible".  The XC9500XL
family will take Vccio = 5V and drive 5V out.  The XCR3xxxXL will accept
5V in but Vccio = Vcc = 3.3V.

Thanks for pointing out that family -- I hadn't really considered that
distinction before.

-- 
Ben Jackson
<ben@ben.com>
http://www.ben.com/

Article: 74660
Subject: Re: Introducing MANIK - a 32 bit Soft-Core RISC Processor
From: "Jaime Andrés Aranguren Cardona" <jaac@nospam.sanjaac.com>
Date: Fri, 15 Oct 2004 15:25:50 -0500
Links: << >>  << T >>  << A >>
Hi Sandeep,

I guess it would fit into an Spartan-3 XC3S200, right? I'd like to test it
with this FPGA. How can we do that? (I see that there are synthesized
netlists on Niktech's website).

Regards,

--
Jaime Andrés Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Sandeep Dutta" <webmaster@niktech.com> escribió en el mensaje
news:p4qdnZwCAqt4nu3cRVn-2Q@comcast.com...
> http://www.niktech.com
>
> Hardware Features
>
> · Data Path Width 32 bits
> · Most instructions are 16 bit. PC Relative jump instructions are 32 bit.
> · Four stage pipeline.
> · Von Neumann Architecture (Data and Instruction in the same address
space).
> · Sixteen, 32 bit General Purpose Registers.
> · Four USER defined instructions (with Register File Write back
capability).
> · Parallel execution of independent Load/Store, Multiply/Shift ,
>     User Defined Instructions and  ALU instructions (In order issue;  Out
of
> order completion)
> · Some Conditional Instructions (Reduces branches & increases code
density).
> · Built in 32 bit Timer.
> · Power Down Mode.
> · 32x32 Multiplier (Multi cycle execution).
>
> Software Development Tools
> · GNU Assembler, Linker (binutils)
> · GCC (C  Compiler)
> · GDB (Debugger) and Instruction Set Simulator
> · Standalone C-Library (RedHat newlib)
> · Modified version of DietLibc
>
> Size and Performance.
>
> Netlists for the current implementation is available for XILINX Virtex,
> Spartan-II and Spartan-IIE; it
> utilizes 1375 LUTs (809 slices); the size includes a 32 bit timer and a
> 32x32 bit LUT based multiplier.
>
> The design has been tested to operate at  60MHZ on a Spartan-II (speed
> grade -6).
>
> Netlists, Documentation and Development tools can be downloaded from
> http://www.niktech.com.
>
>



Article: 74661
Subject: How can FPGAs be used for high speed data acquisition????
From: bansal.dhanraj@gmail.com (BANSAL DHAN RAJ)
Date: 15 Oct 2004 13:43:22 -0700
Links: << >>  << T >>  << A >>
hi everybody
 How can the FPGAs (particularly ALTERA) be used for high speed data
acquisition of the order of 10 MSPS(mega samples per second ).Which
one ADSP 21992 or FPGA is better? What is a CAN(CONTROone ADSP 21992
or FPGA is better? What is a CAN(CONTROL AREA NETWORK)? pls reply soon
.thanks in advance

Article: 74662
Subject: Re: spartan 3 on 4 layers
From: Austin Lesea <austin@xilinx.com>
Date: Fri, 15 Oct 2004 13:51:29 -0700
Links: << >>  << T >>  << A >>
Symon,

Answers below,

Austin

Symon wrote:
> Austin,
> PCB ground bounce? But this thread is about not having PCB power planes.

It was about number of layers.  A ground plane is a layer.

> No-one's suggesting doing without a ground plane. That's the main (only!)
> weapon against ground bounce. The loop-inductance you're taking about that
> carries the return current is then between the FPGA and it's decoupling
> capacitors. The ground plane ensures the power supply doesn't bounce
> relative to the decoupled supply at the FPGA.

The ground L is the bounce in the ground plane.  The Vcc plane L is the 
bounce in the Vcc.

> If you're talking about ground bounce on the silicon, then all we PCB
> designers can do is firmly bolt down the ground pins to the PCB ground
> plane. A power plane, or lack thereof, isn't gonna affect ground bounce
> after that.
> Also, when you say in a previous post 'If you do not have both a power and a
> ground plane for each of these supplies, the SSO numbers must be reduced.',
> I'd disagree. You probably must have a ground plane, but throwing separate
> layers at supplies for Vcco, Vccint, Vccaux, Rocket I/O supplies is a little
> excessive!

I said a pair of planes for each high current switching supply, namely a 
Vccint/Gnd pair, and a Vcco/Gnd pair.  That makes four layers.  The dual 
grounds are required to reduce the ground return inductance to something 
that is reasonable.  And the vcc loop inductance.  Both.

  It's easier to use this methodology, and certainly easier for
> Xilinx to support, but you can get as good results by using one or two
> layers to share supplies locally at the FPGA.

I disagree.  Looking at those that succeed, vs. those who have issues, I 
see those that followed our recommendations a much happier bunch.

We take our recommendations very seriously.  We are not out to minimize 
our support, but rather to maximize our customers' successes (and our 
own in the process).  To suggest a marginal power distribution system is 
just not good business!  Why would we suggest that a customer 'play 
around' when we and our disti's have already run all the simulations, 
and built numerous verification, characterization, and demo pcbs to 
prove what works, and what does not work?

Anyone who thinks they know better how to use our chip might get lucky, 
but often is not.  Why would anyone think that they know more than we do 
about something they did not design?  Surprisingly, many do think that 
they know more, and as a consequence are sometimes terribly disappointed.

For the introduction of V4, we had a 1Gb/s LVDS networking pcb ready to 
demo, and a memory interfaces pcb ready to demo.  Those are two of the 
largest applications problems our customers face today - fast IOs and 
fast memories.  If we don't know how to make it work, how would that 
make a customer feel?

I always read how a vendor suggests using their device.

The use of the POL supplies is an experiment to validate a concept.  I 
wouldn't go to product until I had proven it works (if it was my job).

The same goes for using only four layers, or traces to Vcco, etc.

  You can also use this layer
> for other things away from the FPGA. To do this, your decoupling must be
> good at the FPGA, and the connection between the supply and the local plane
> must be able to supply the current needed.
> You're also, IMHO, better off having multiple ground planes, and routing the
> power.

Yes, ground is all important (more so than the Vcc's), and Vcc 'planes' 
may sometimes just be routed.  It depends again on the switched currents.

> Finally, I'd be interested in how increasing bypass capacitance can make
> ground bounce worse in the same system, especially one with a ground plane?
> More energy stored?

Yes, the rails don't collapse.

  di larger?

Yes, the source impedance is lower.

  dt faster?

Yes, lower source impedance also leads to faster transients.

Lastly, we had a case where the vias from the bypass caps where wired 
such that the L from the cap to the plane was the largest element (not 
hard to do, one tiny via each end, at the end of a flag of trace to the 
chip cap).  Adding caps directly across the existing cap did absolutely 
nothing.  One might conclude that the bypassing wasn't doing anything. 
But really, the L to the caps was so bad, that the caps were not doing 
anything.  Little things count.

Had to tell the pcb layout person to get the L out of there! (excuse the 
pun - again)

Article: 74663
Subject: Re: How many Altera LE's to Xilinx Slices????
From: Ben Twijnstra <btwijnstra@chello.nl>
Date: Fri, 15 Oct 2004 21:23:14 GMT
Links: << >>  << T >>  << A >>
Hi Eric,

> But is a approximate 1 Slice = 2 LE's a pretty close all around
> estimate.

Give or take ~10% as a design-dependant margin and you should be OK.

Best regards,


Ben


Article: 74664
Subject: Re: Metastability pipeline causes bad juju
From: Chris <>
Date: Fri, 15 Oct 2004 15:02:13 -0700
Links: << >>  << T >>  << A >>


      >> The "max" lines of code have to do with the simulation speed.





I'll have to look into the free ModelSim version again to see if I would slow down too much.

      >> how do you probe inside the FPGA with a logic analyzer? Do you recompile
      to bring out internal
      points to IO pins?





I have 16 pins dedicated to an unused expansion bus on the Xilinx that I currently have hooked up to a logic analyzer. I can select beween 8 different 16-bit signals internal to the FPGA by hitting 1-8 on the serial port. Any time I add some code I hook up the relevant signals to the mux. I rarely have to recompile to get different signals out.

      >> Chipscope Pro(tm) sure beats using a logic analyzer




Maybe I'll try this out, it looks like it might be worthwhile.

I'm not anti-simulation, I wish I had a good simulation tool but I also wish I had Matlab and a few other software packages, too. I don't, so I end up doing strange things like "simulating" an RS Encoder using bitwise operations in Microsoft Excel.

Article: 74665
Subject: Re: WebPACK post-PAR min clock period?
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Oct 2004 18:41:40 -0400
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> 
> >I don't understand your point.  If you don't tell the tool what an
> >acceptable clock period is, then how is the tool supposed to know the
> >difference between a nanosecond and a fortnight?  Tools are not people,
> >they can't reason.  Besides, how would *I* know what you find an
> >acceptable clock period if you don't tell me?  I still see systems that
> >are clocked well below 10 MHz.
> 
> The tools could at least tell me what the worst case clock-clock
> time is for each clock.  That's not rocket science.  And maybe
> even give a warning for not specifying the appropriate constraints.

Who said the tool does not give you the results?  I belive at least one
post here said that info *was* available.  

-- 

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: 74666
Subject: Re: How many Altera LE's to Xilinx Slices????
From: rickman <spamgoeshere4@yahoo.com>
Date: Fri, 15 Oct 2004 18:46:11 -0400
Links: << >>  << T >>  << A >>
Guitarman wrote:
> 
> Hello All,
> 
> I've been designing with Xilinx FPGAs for a while so I'm used to the
> "Slice" concept. I'm looking at Altera's Max II as a nice possible
> solution for a design.
> 
> I took my VHDL code and it synthesized to 40 Slices in a Spartan III.
> Then I took the same code and sythesized it for a Max II (using
> Quartus II now) and it was 71 LE's.
> 
> I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly
> dependant on how the code is sysnthesized.
> 
> But is a approximate 1 Slice = 2 LE's a pretty close all around
> estimate.

The problem is not a hardware issue, but a granularity issue.  Slices
are not a good measure of how much logic your design is using.  Slices
have two LUTs and two FFs.  If one FF is used, the slice is counted as
used.  You are better off determining how many LUTs and FFs are used in
each design.  They are much more comparable although there will be
family dependant differences in how well the designs can pack into the
larger granules.  Mostly the newer parts will pack logic and FFs more
densely than the older parts.  

-- 

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: 74667
Subject: Re: which xilinx CPLD to select?
From: "M.Randelzhofer" <techseller@gmx.de>
Date: Sat, 16 Oct 2004 01:13:58 +0200
Links: << >>  << T >>  << A >>
Xilinx 9500XL is the best choice for interfacing to 5V logic.
Yet it's not capable of driving levels up to 5V, just 5V input tolerance.
You can't get a single device for < 10$ in small or medium quantities.
9500XL has a maximum of logic ressources compared to coolrunner or even
coolrunner2.
Disadvantages of 9500xl: lot's of power consumption, drives only 8mA low,
4mA high.

Use a mix of 95144xl and 9572xl for cost optimisation.

If you need a quick and flexible solution for about 12-15$, use the smallest
spartan3 device with an XCF01S platform flash and level shifters.

MIKE



Article: 74668
Subject: BCD to bin convertor
From: "JPR" <jpr@nospam.com>
Date: Sat, 16 Oct 2004 01:23:21 +0200
Links: << >>  << T >>  << A >>
Hi everybody,

I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If possible in
VHDL.

Thanks



Article: 74669
Subject: Re: BCD to bin convertor
From: "John_H" <johnhandwork@mail.com>
Date: Sat, 16 Oct 2004 00:04:22 GMT
Links: << >>  << T >>  << A >>
Since BCD to Bin is the easy direction (a bunch of adders), why is it you
don't care to try it yourself?
Are you limited by speed?  Latency?  Resources?  CPLD rather than FPGA
implementation?  How many digits do you need?

"JPR" <jpr@nospam.com> wrote in message
news:41705b34$0$29012$afc38c87@news.easynet.fr...
> Hi everybody,
>
> I'am searching for 4 digits BCD (=16 bits) to BIN convertor. If possible
in
> VHDL.
>
> Thanks



Article: 74670
Subject: Re: Question on Xilinx VirtexPro II FPGA chip... please
From: Peter Ryser <peter.ryser@xilinx.com>
Date: Fri, 15 Oct 2004 17:26:56 -0700
Links: << >>  << T >>  << A >>
> 1. Is it possible to put either Linux or Nucleus RTOS into this chip memory, 
Yes and yes by using the on-board DDR memory. The ML310 board actually 
ships with a pretty extensive demo for Linux. The web page for ML310 at 
http://www.xilinx.com/ml310 has a documentation section that describes 
in much detail on how to build Linux systems for the board. Further, 
XAPP765 is a document to get you started with EDK and MontaVista Linux 
(http://direct.xilinx.com/bvdocs/appnotes/xapp765.pdf)

A (very) minimal Linux kernel takes around 600KB. So, you might be able 
to run it out of BRAM on larger chips. However, in most cases it is not 
the Linux kernel that takes most space but the application that you run 
on top of it.

Nucleus is known to run on Virtex-II Pro. For more information please 
contact Mentor.


>
> 2. If yes, when Linux or Nucleus RTOS is loaded, will we get communications 
> stack and drivers for IEEE 802.11 in ad-hoc mode (this as any EE Engineer 
> knows is a wireless LAN standard)?

While we have not tested the ML310 with a wireless card the Linux kernel 
supports these cards and we have done tests with PCMCIA cards from Cisco 
on the ML300 board.
So, chances are high that a 802.11 PCI card will work out of the box.

>
> 3. If yes, then we'll purchase a standard IEEE 802.11 card, can this card be 
> plugged into your development kit port?
Yes, into one of the four PCI slots (2x 3.3V, 2x 5V).

- Peter


Article: 74671
Subject: Re: BCD to bin convertor
From: Rich Webb <bbew.ar@mapson.nozirev.ten>
Date: Sat, 16 Oct 2004 00:37:03 GMT
Links: << >>  << T >>  << A >>
On Sat, 16 Oct 2004 00:04:22 GMT, "John_H" <johnhandwork@mail.com>
wrote:

>Since BCD to Bin is the easy direction (a bunch of adders), why is it you
>don't care to try it yourself?
>Are you limited by speed?  Latency?  Resources?  CPLD rather than FPGA
>implementation?  How many digits do you need?

(probably just enough to get his homework done)    l;-)

-- 
Rich Webb   Norfolk, VA

Article: 74672
Subject: Re: spartan 3 on 4 layers
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 15 Oct 2004 17:44:28 -0700
Links: << >>  << T >>  << A >>
More comments:-
"Austin Lesea" <austin@xilinx.com> wrote in message
news:ckpd8h$rn2@cliff.xsj.xilinx.com...
> Symon,
>
> Answers below,
>
> Austin
>
> Symon wrote:
> > Austin,
> > PCB ground bounce? But this thread is about not having PCB power planes.
>
> It was about number of layers.  A ground plane is a layer.
>

Go back and read the OP. He had a ground plane, he wanted to know if he
could get away with routing the power separately. Yes he can! Especially
with a PQ208 which has a lead frame made of little inductors on every pin! I
hope you Xilinx boys have encapsulated some bypass caps in there somewhere!

> > No-one's suggesting doing without a ground plane. That's the main
(only!)
> > weapon against ground bounce. The loop-inductance you're taking about
that
> > carries the return current is then between the FPGA and it's decoupling
> > capacitors. The ground plane ensures the power supply doesn't bounce
> > relative to the decoupled supply at the FPGA.
>
> The ground L is the bounce in the ground plane.  The Vcc plane L is the
> bounce in the Vcc.
>

Assuming the ground balls/pins are connected straight to the ground plane
and if the Vcc balls/pins are coupled tightly to the ground plane via
sufficient decoupling capacitors and enough low inductance copper
track/local plane, you don't need a Vcc plane that traverses the whole
board. The current loop is between the ground plane, the FPGA, the bypass
cap. One plane can't bounce without the other if the bypass caps nail them
together!

> > If you're talking about ground bounce on the silicon, then all we PCB
> > designers can do is firmly bolt down the ground pins to the PCB ground
> > plane. A power plane, or lack thereof, isn't gonna affect ground bounce
> > after that.
> > Also, when you say in a previous post 'If you do not have both a power
and a
> > ground plane for each of these supplies, the SSO numbers must be
reduced.',
> > I'd disagree. You probably must have a ground plane, but throwing
separate
> > layers at supplies for Vcco, Vccint, Vccaux, Rocket I/O supplies is a
little
> > excessive!
>
> I said a pair of planes for each high current switching supply, namely a
> Vccint/Gnd pair, and a Vcco/Gnd pair.  That makes four layers.  The dual
> grounds are required to reduce the ground return inductance to something
> that is reasonable.  And the vcc loop inductance.  Both.
>

Not necessary. The ground layer is important, as I said later more ground
planes are good. But big planes for Vcco and Vccint are NOT necessary. Just
low inductance from the bypass caps to the FPGA power pins/balls.

>   It's easier to use this methodology, and certainly easier for
> > Xilinx to support, but you can get as good results by using one or two
> > layers to share supplies locally at the FPGA.
>
> I disagree.  Looking at those that succeed, vs. those who have issues, I
> see those that followed our recommendations a much happier bunch.
>

Maybe you could come up with better recommendations, then your happy bunch
might get happier and richer from the money they save on PCBs!

> We take our recommendations very seriously.  We are not out to minimize
> our support, but rather to maximize our customers' successes (and our
> own in the process).  To suggest a marginal power distribution system is
> just not good business!  Why would we suggest that a customer 'play
> around' when we and our disti's have already run all the simulations,
> and built numerous verification, characterization, and demo pcbs to
> prove what works, and what does not work?

Fair enough. I'm sure this is true.

>
> Anyone who thinks they know better how to use our chip might get lucky,
> but often is not.  Why would anyone think that they know more than we do
> about something they did not design?  Surprisingly, many do think that
> they know more, and as a consequence are sometimes terribly disappointed.
>

Deep breath! I can see why you sometimes rile up Rickman! ;-) Anyway, I
count myself as someone who does know better how to use the chip in this
case, at least better than XAPP623, and I have plenty of boards to back it
up. When you get lucky every time, there's another word for it. I'm not
saying it's easy, but it's possible, and I save my company a lot of money on
PCBs by using fewer layers, fewer bypass caps, and squeezing extra
functionality onto the board. What I'm trying to do with my posts here is
help other folks understand that what Xilinx says is only one way to do it;
other ways work, and work very well. Don't get me wrong, I think Xilinx does
an excellent job, especially at support. Your recommendations enable someone
with little PCB design expertise to get it right first time. Sometimes
though, we non-Xilinx 'gentiles' can do good stuff too!

> For the introduction of V4, we had a 1Gb/s LVDS networking pcb ready to
> demo, and a memory interfaces pcb ready to demo.  Those are two of the
> largest applications problems our customers face today - fast IOs and
> fast memories.  If we don't know how to make it work, how would that
> make a customer feel?
>
> I always read how a vendor suggests using their device.
>

We agree on this!

> The use of the POL supplies is an experiment to validate a concept.  I
> wouldn't go to product until I had proven it works (if it was my job).
>
> The same goes for using only four layers, or traces to Vcco, etc.
>
>   You can also use this layer
> > for other things away from the FPGA. To do this, your decoupling must be
> > good at the FPGA, and the connection between the supply and the local
plane
> > must be able to supply the current needed.
> > You're also, IMHO, better off having multiple ground planes, and routing
the
> > power.
>
> Yes, ground is all important (more so than the Vcc's), and Vcc 'planes'
> may sometimes just be routed.  It depends again on the switched currents.
>

OK, so now we agree that a routed/local planed Vcc works? You seem to
flip-flop more than a Democrat nominee! ;-) Again we agree, local plane/
routed can Vcc work fine.

> > Finally, I'd be interested in how increasing bypass capacitance can make
> > ground bounce worse in the same system, especially one with a ground
plane?
> > More energy stored?
>
> Yes, the rails don't collapse.

But if the rails collapse, ground bounce is the least of your worries. Your
design is already dead.

>
>   di larger?
>
> Yes, the source impedance is lower.
>
>   dt faster?
>
> Yes, lower source impedance also leads to faster transients.
>

At these high frequencies, the capacitor package size (= inductance) is the
thing that dominates the source impedance. Not the capacitance. Look at the
manufacturers data sheets. Download this and look for yourself
http://www.murata.com/designlib/mcsil.html . Above 50MHz an X5R 0402 cap has
the same impedance whether it's 56nF or 470nF. The ground bounce problem is
solely a result of poor coupling between the ground plane and the FPGA.

> Lastly, we had a case where the vias from the bypass caps where wired
> such that the L from the cap to the plane was the largest element (not
> hard to do, one tiny via each end, at the end of a flag of trace to the
> chip cap).  Adding caps directly across the existing cap did absolutely
> nothing.  One might conclude that the bypassing wasn't doing anything.
> But really, the L to the caps was so bad, that the caps were not doing
> anything.  Little things count.
>
> Had to tell the pcb layout person to get the L out of there! (excuse the
> pun - again)

Of course, very good point. It's a constant fight against the PCB routing
tool to prevent it stripping out extra vias I add to decrease impedance.
Ah, Austin, I enjoy these chats. Even when I C your terrible puns!
Write back soon mate,
Syms. ;-)



Article: 74673
Subject: Re: How many Altera LE's to Xilinx Slices????
From: hpa@terminus.zytor.com (H. Peter Anvin)
Date: Sat, 16 Oct 2004 01:06:08 +0000 (UTC)
Links: << >>  << T >>  << A >>
Followup to:  <90282e35.0410151112.77a87654@posting.google.com>
By author:    ericjohnholland@hotmail.com (Guitarman)
In newsgroup: comp.arch.fpga
>
> Hello All,
> 
> I've been designing with Xilinx FPGAs for a while so I'm used to the
> "Slice" concept. I'm looking at Altera's Max II as a nice possible
> solution for a design.
> 
> I took my VHDL code and it synthesized to 40 Slices in a Spartan III.
> Then I took the same code and sythesized it for a Max II (using
> Quartus II now) and it was 71 LE's.
> 
> I realize a blanket statement 71 LE's (approx. =) 40 Slices, is totaly
> dependant on how the code is sysnthesized.
> 
> But is a approximate 1 Slice = 2 LE's a pretty close all around
> estimate.
> 

Well, given that 1 slice = 2 LUTs + 2 FFs + some more logic, and 1 LE
= 1 LUT + 1 FF + some more logic, it would be expected.

	-hpa



Article: 74674
Subject: Re: Interfacing an 1GS ADC
From: "Symon" <symon_brewer@hotmail.com>
Date: Fri, 15 Oct 2004 18:08:38 -0700
Links: << >>  << T >>  << A >>
Marc,
My colleague just came clean; he'd fitted an early V2P7 that didn't have the
LVDS_DT functionality. No wonder he had problems that external resistors
fitted.
Cheers, Syms.
"Marc Randolph" <mrand@my-deja.com> wrote in message
news:4JOdna9_pM_87ffcRVn-tg@comcast.com...
> Symon wrote:
>  >>Just be aware that the internal termination can be
>  >>less than ideal.
>  >
> > Care to relate your experiences of the internal termination? I've had no
> > trouble at 600Mbit/s data and a 600MHz clock. Some of my colleagues have
> > mentioned that they've run into problems, and they've reverted to
fitting
> > external 100R resistors.
>
> Howdy Symon,
>
>     We are using the internal _DT resistors on a V2P7 for receiving a
> LVDS clock that is slightly over 600 MHz, as well as the source
> synchronous data that goes along with it.  It technically works (we
> never have bit errors over all operating conditions), but using a
> differential probe at the vias immediately below the inputs pins show
> that there isn't much margin - the signal quality looks pretty poor.
>
> A more serious problem that we had was with a 600+ MHz GCLK input.  What
> we believe we discovered was that a nearby GCLK input with a single
> ended 3.3V 66 MHz clock was affecting its signal quality enough that
> we'd sometimes miss clocks.  The 66 MHz clock looked good (no excessive
> overshoot or other noise on it).  Lowering the frequency to 311 MHz,
> with no change to routing, fixed the problem.
>
> Have fun,
>
>     Marc





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

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

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search