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 44875

Article: 44875
(removed)


Article: 44876
Subject: Jtag extest
From: "Radoslaw Mitura" <mitek@ue.eti.pg.gda.pl>
Date: Wed, 3 Jul 2002 18:51:15 +0200
Links: << >>  << T >>  << A >>
I have two chips in JTAG scan chain: XC95144xl and XCV50e.
On some nets between those chips i have pullup.
I tried to extest both of the chips.
When I driving net without pullup it is ok, but when i trying
to driving net with pullup something goes wrong:
I can drive from XC95144xl and receive on XCV50e but
I can't do that in reverse direction (drive from XCV50e and receive on
XC95144xl).
Cell when I tried to receive is in third state.

Where is the problem?

Regards
    Mitek



Article: 44877
Subject: Xilinix Webpack ChipViewer very slow
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: Wed, 3 Jul 2002 16:52:20 +0000 (UTC)
Links: << >>  << T >>  << A >>
Is it only me that I feel the ChipViewer from Xilinix Webpack is very slow?
I must admit, I run webpack under vmware, but even after 10 minutes of
crunching CPU time on a 366 MHz PC,  chipviewer isn't ready with the view of
a xc2c256tq144.

Bye

-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Article: 44878
Subject: Re: Bitstream Verification (JBITS)
From: Weifeng Xu <wxu@ecs.umass.edu>
Date: Wed, 03 Jul 2002 13:21:34 -0400
Links: << >>  << T >>  << A >>
Actually, I wanna use JBITS to generate the bitstream based on output of some
academic CAD tools. Those academic tools do have some design check. But I am
afraid it's not enough. So I am wonderring whether there're some tools I can
generate ncd from the bitstream.

Nicholas Weaver wrote:

> In article <3D231D2C.9E97BD3E@ecs.umass.edu>,
> Weifeng Xu  <wxu@ecs.umass.edu> wrote:
>
> >    Unfortunately, I have to use some low level JBITS.set to make PIP
> >connections.  But I am wondering whether it's enough to apply some
> >mechanism such as lookup table to check whether one routing wire has
> >been drived before.I am not sure what's in Xilinx's checking process.
>
> What are you trying to accomplish?  An upstream-independant toolflow,
> or slightly higher level work?
>
> IF the later, you might consider outputting xdl instead, converting it
> to ncd, and pushing it throuh the xilinx router/static timing
> analysis/ and bitfile generator.
>
> I was going down the Jbits route myself for a while, and am now much
> happier using XDL.
> --
> Nicholas C. Weaver                                 nweaver@cs.berkeley.edu


Article: 44879
Subject: Re: Power consumtion simulation for FPGA?
From: Ray Andraka <ray@andraka.com>
Date: Wed, 03 Jul 2002 18:15:40 GMT
Links: << >>  << T >>  << A >>
It also increases the number of data transitions considerably, thereby increasing
power as well.  Typical arithmetic stuff will have between 10 and 25% toggling.  By
scrambling the data you increase that to pretty close to 50%, which increases the
dynamic power by 2x or more.  If you want to keep a more or less constant thermal
environment, you might do better adding a good sized shift register which you toggle
the input on every clock, then clock enable it to throttle back when the real
circuit is drawing more power.  To control it, you could either sense device current
or use the thermal diode.  The current sense would give less delay in the loop. That
approach would give a constant power at near the peak power of the real circuit,
where a scrambling approach would increase the peak power to achieve something
constant.

Austin Lesea wrote:

> Arash,
>
> I would simulate each functional block alone, with the best vectors I can.
>
> I would then modify the vectors to see how sensitive the power is to data in the
> vectors.
>
> If I see a 40% change with data I would then know that my results may vary quite
> a bit.
>
> If I see a smaller change, I would have more confidence.
>
> You may try using scrambling techniques to make the data have a nominal 50%
> density of transitions in order to smooth out your thermal behaviour.  Scramble
> data before flowing through multiplexers or switch matrices, and unscramble it
> upon leaving. (This also increases power dissipation by adding more logic).
>
> This sounds like the satellite work I have done, where heat balance is very
> delicate, and you would almost rather have a constant heat source, than one that
> can vary by a large amount.
>
> Austin
>
> Arash Salarian wrote:
>
> > <Martin> wrote in message news:ee77a64.1@WebX.sUN8CHnE...
> > > Hello Arash,
> > >
> > > the tool which functionality you describe is available. It's called XPower
> > and takes in the implemented design and if you want a *.vcs-file (I think
> > that's the extension) with simulation data from e.g. Modelsim. With that
> > tool you can very accurately predict how much power your design is going to
> > use.
> > >
> > > The tool comes as part of ISE and WebPack and you'll find it in the P&R
> > section of the 'Implement Design' Part in the Project Navigator.
> > >
> >
> > Thanks all for your answers. Well, VCD and Xpower.... I don't know exactly
> > how Xpower works as I've never used it before, but  I "guess" it takes the
> > output of the simulation through VCD files, and then gives you an average
> > power consumption over the simulation time; rigth?
> >
> > Well, this approach is certainly enough for many cases... Yet in my
> > application I have a complex design that consists of multiple functional
> > units inside the FPGA, each get active at certain times and after a while
> > get disactivated (clock enable goes to 0) to decrease power consumtion. The
> > problem is that the power consumption is high and the system will be used in
> > a closed box, with no air flow. I'm made a simple estimation of the power
> > consumtion and have found that the temprature of the chip can go up, near
> > the maximum recommended value. Now, as the nature of the processing is very
> > dynamic, I need a way to calculate dynamic power consumtion and even
> > consider effects of heat transfer from die to case of the FPGA and then to
> > PCB and ... to see how hot the device actually gets.
> >
> > I think it's a very difficult task and finally I may reach a point that I
> > conclude the only way is going to lab and see all this in action. Yet, with
> > such a long delay in feed-back loop, the design optimization process would
> > take eons....
> >
> > Regards
> > Arash

--
--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: 44880
Subject: Re: Bitstream Verification (JBITS)
From: Neil Franklin <neil@franklin.ch.remove>
Date: 03 Jul 2002 20:54:38 +0200
Links: << >>  << T >>  << A >>
Weifeng Xu <wxu@ecs.umass.edu> writes:

[text reordered, newer response after older text, in proper chronological
order, please post in proper order]

> Neil Franklin wrote:
>
> > Weifeng Xu <wxu@ecs.umass.edu> writes:
> >
> > > whether there's some kind of tools can help check whether this bitstream
> > > can actually work on FPGA instead of burnning it.
> >
> > The generation process of JBits should ensure that, as long as you use
> > the automatic routing. If you set individual PIPs, all bets are off.

>     Unfortunately, I have to use some low level JBITS.set to make PIP
> connections.

Oh, then you have no JBits safeguards.


> But I am wondering whether it's enough to apply some mechanism such as lookup
> table

Lookup table is no use, as it does not know about routing or PIPs.


> to check whether one routing wire has been drived before.I am not sure what's
> in Xilinx's
> checking process.

Experiment. Make an bitfile which deliberately has an double driven
line. Loead it into BoardScope and see if it complains.


--
Neil Franklin, neil@franklin.ch.remove http://neil.franklin.ch/
Hacker, Unix Guru, El Eng HTL/BSc, Programmer, Archer, Roleplayer
- Make your code truely free: put it into the public domain

Article: 44881
Subject: Re: Bitstream Verification (JBITS)
From: nweaver@CSUA.Berkeley.EDU (Nicholas Weaver)
Date: Wed, 3 Jul 2002 19:58:10 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D23329E.FC9A2D6@ecs.umass.edu>,
Weifeng Xu  <wxu@ecs.umass.edu> wrote:
>Actually, I wanna use JBITS to generate the bitstream based on output of some
>academic CAD tools. Those academic tools do have some design check. But I am
>afraid it's not enough. So I am wonderring whether there're some tools I can
>generate ncd from the bitstream.

Why not generate .xdl files with placement but no routing, and let the
xilinx router (slow but pretty good) handle it?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 44882
Subject: Who are making BGA and gasket ?
From: tang_king@hotmail.com (Tang King)
Date: 3 Jul 2002 13:04:55 -0700
Links: << >>  << T >>  << A >>
Hi, there.

One of my friend wants to know who are the big manufacturers for BGA
and gasket (for telecommunication, CDMA RBS) in the States. He told me
that Chomerics (Park) is making the gasket. Is that right? Is that
ususal that one company makes BGA and gasket together?

(Actually, I have no idea what the BGA and gasket are. :-p I just
learned a little bit from the web surfing: Ball Grid Array, EMI, EMC.
Is there anyone who can explain it in plain English to a newbie?
Thanks.)

Thanks.

Article: 44883
Subject: Re: Converting to Altera Quartus
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 03 Jul 2002 14:17:40 -0700
Links: << >>  << T >>  << A >>

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

What a tempest in a tea-pot!
Kevin just got carried away and did not remember the original question:

" ...I would try converting a design using free Xilinx web tools to one using free
Altera web tools...."

That's why I referred to Xilinx as the "original". Kind of interesting that somebody
instinctively associates "original" with Xilinx...

More fundamentally:
Xilinx and Altera are arch-competitors, and as such, there is no love lost between
us. The user community should rejoyce, for this competition brings them faster
innovation and probably more competitive prices.
It is marketing's job to orchestrate the selling, and to give the sales force
appropriate technical and commercial information to win any design ( if at all
possible ). Nobody should criticize that marketing puts its best foot forward, and
that marketing and sales are eager to point out the weak spots and flaws of the
competition. You as a user need that information, and who else would provide it?

Honesty is a separate issue. Marketing should never deliberately spread erroneous
information about the competition. That is unethical, stupid, and will inevitably
backfire sooner or later. Just like any statement that the new 3.125 gigabit
transceivers in Virtex-IIPro "don't work" is a completely wrong fabrication. They
work 100%, have always worked from the day we received first silicon, and we have
many sophisticated and experienced customers who have evaluated them, and can testify
to the robustness of the design, driving signals 50 cm through two connectors while
maintaining an acceptable eye pattern.

End of soapbox, and thanks for all the kind support.
And Kevin, you are once more forgiven for your hasty conclusions.

Y'all have a happy and safe Fourth of July !

Peter Alfke






Article: 44884
Subject: Virtex II - IO TILE, IOB PAD #4
From: "Bill" <not@home.com>
Date: 4 Jul 2002 05:50:22 +0100
Links: << >>  << T >>  << A >>
Hi,

XAPP 266 describes inputting a DQS (data strobe) to an IOB pin which
occupies PAD 4 of the IO Tile.   This allows the strobe (clock) signal to
utilize the local HEX clock line which connects five rows (pins) above and
six rows (pins) below the DQS pin.  Data pins can then occupy the 11 (5+6)
pins and use the DQS clock in their respective IOB's.

I have looked at all of the current Virtex II datasheets, user guides, app
notes, and can not find any documentation which illustrates what pins
correspond to this grouping of pins for a certain device package.   For
example, for a 1000 series device in the FG456 package, all io pins are
utilized, whereas in the 500 series, certain io pins are removed, and in the
250 device even more pins are removed.

Does anyone know where to obtain this info?

Bill





______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
      <><><><><><><>   The Worlds Uncensored News Source   <><><><><><><><>
  

Article: 44885
Subject: Re: Modelsim 5.6a for Linux execution problem
From: Kai Harrekilde-Petersen <khp@vitesse.com>
Date: 04 Jul 2002 08:32:20 +0200
Links: << >>  << T >>  << A >>
"Josan Moreno" <jmorenoz@terra.es> writes:

> Hi all,
> When I try to execute Modelsim 5.6a (vsim) under Linux (I have Suse
> 7.3) I always receive the same error message: Error in startup script:
> > unknown encoding "iso8859-1"unknown encoding "iso8859-1"
> > while executing

Sounds like your LOCALE or LANG enviroment is confusing vsim.
On my (RedHat 7.2) platform LOCALE is unset, and LANG=en_US.

HTH,


Kai
-- 
Kai Harrekilde-Petersen  <khp@vitesse.com>  Opinions are mine...

Article: 44886
Subject: glitches in back annotation
From: jasdejajasdeja@yahoo.co.uk (jas)
Date: 4 Jul 2002 00:28:00 -0700
Links: << >>  << T >>  << A >>
When performing back annotation on an altera flex 10K the following
message is reported:

Time: 2442 ns  Iteration: 1  Instance: /tb_bb/u1/u1/inv_22703
# ** Warning: VitalGlitch: GLITCH Detected on port Y ; Preempted
Future Value := 0 @ 2444 ns;
Newly Scheduled Value := 1 @ 2448 ns;
#    Time: 2442 ns  Iteration: 1  Instance: /tb_bb/u1/u1/inv_22716

Is this a problem since the glitch is reported on an internal signal
which is clocked?

Are all signals checked for glitches and what is classed as a glitch? 



jon

Article: 44887
Subject: Fixed point arithmetic
From: John Williams <j2.williams@qut.edu.au>
Date: Thu, 04 Jul 2002 17:56:16 +1000
Links: << >>  << T >>  << A >>
Hi folks,

Does anybody know of a synthesisable VHDL package/library for
generalised fixed point arithmetic?  

I'm picturing a scheme whereby you specify the number of fractional and
integer bits in the operands and result, and it handles the shifts and
bit padding etc seamlessly.  Supported ops would be addition,
subtraction, multiplication, with signed and unsigned options, that sort
of thing  (basically an extension to the existing signed/unsigned
support).

Of course in any single case it's easy to work out, for example, which
bits to keep and which to throw out when adding two numbers with
different numbers of fractional and integer bits, but it would be great
to have wrapped nicely in a single package.

Any suggestions?  

Thanks,

John

Article: 44888
Subject: Maximum frequency in Virtex and Virtex-E Devices
From: Heiko Kalte <kalte@hni.upb.de>
Date: Thu, 04 Jul 2002 09:57:15 +0200
Links: << >>  << T >>  << A >>
Dear Community,
I would like to compare the maximum frequency of the Virtex and Virtex-E
family, the databook says 200MHz for the Virtex family and 133MHz (4 LUT
levels) for the Virtex-E family. There are obviously different bases for
the calculation. Because Virtex-E should be faster. Is there a common
basis (e.g. 4 LUT levels) to compare the two series?
Heiko


-- 
---------------------------------------------------------------
Dipl. Ing. H. Kalte               |
HEINZ NIXDORF INSTITUTE           | Office: F1.213
System and Circuit Technology     | Fon: +49 (0)5251 60-6459
Fürstenallee 11                   | Fax: +49 (0)5251 60-6351
33102 Paderborn, Germany          |
---------------------------------------------------------------
mailto:kalte@hni.uni-paderborn.de
http://wwwhni.uni-paderborn.de/sct/
---------------------------------------------------------------

Home of the RAPTOR Rapid Prototyping Systems
http://www.RAPTOR2000.de/

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

Article: 44889
Subject: Re: Virtex II - IO TILE, IOB PAD #4
From: Philip Freidin <philip@fliptronics.com>
Date: Thu, 04 Jul 2002 09:47:08 GMT
Links: << >>  << T >>  << A >>
On 4 Jul 2002 05:50:22 +0100, "Bill" <not@home.com> wrote:
>Hi,
>
>XAPP 266 describes inputting a DQS (data strobe) to an IOB pin which
>occupies PAD 4 of the IO Tile.   This allows the strobe (clock) signal to
>utilize the local HEX clock line which connects five rows (pins) above and
>six rows (pins) below the DQS pin.  Data pins can then occupy the 11 (5+6)
>pins and use the DQS clock in their respective IOB's.
>
>I have looked at all of the current Virtex II datasheets, user guides, app
>notes, and can not find any documentation which illustrates what pins
>correspond to this grouping of pins for a certain device package.   For
>example, for a 1000 series device in the FG456 package, all io pins are
>utilized, whereas in the 500 series, certain io pins are removed, and in the
>250 device even more pins are removed.
>
>Does anyone know where to obtain this info?
>
>Bill


Probably the only way is with the FPGA Editor.



Philip Freidin
Fliptronics

Article: 44890
Subject: Routing Virtex-II 256 pin BGA on 4 layers
From: "Steve Joures" <sjoures@saiman.co.uk>
Date: Thu, 4 Jul 2002 03:22:23 -0700
Links: << >>  << T >>  << A >>
Is it possible to layout a Virtex-II 256 pin FPBGA on 4 PCB Layers ? 

By reading Xilinx application note XAPP157 you would think that it was. I am trying to use the 2 outer layers for routing, and two inner layers as power planes. The problems I am having (which are not mentioned in XAPP157) are to do with VCC_INT and decoupling capacitors. 

If you use all the decoupling capacitors recommened in XAPP158, then they completely surround the device. (I've used 0603 capaictors on upper layer only) So the upper layer routing, once out of the FPGA area is restricted by these. 

It is difficult to use one power plane to route VCCO and VCC_INT, because you are forced to split VCC_INT into 4 areas under the BGA. Each of these areas could be brought out from under each corner of the FBGA, but then it is impossible to connect then with out cutting right across the VCCO plane. If I bring the VCC_INT areas to the surface to connect them, then I cut across the routing layers. One option I have thought of is to bring each of the VCC_INT area of the power plane diagonally out from each corner of the BGA to the edge of the (small) PCB. Then I connect them with a section of power plane that runs right round the PCB perimeter. Is the a good idea ? 

Has anyone come across the same problems, and if so what solution did they come up with ?

Article: 44891
Subject: Spartan II configuration ...
From: =?iso-8859-1?Q?Pawe=B3?= J. Rajda <pjrajda@uci.agh.edu.pl>
Date: Thu, 04 Jul 2002 12:49:46 +0200
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------A3175C67C4285A79E51D6A87
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Does anybody know if the /PROGRAM input in Spartan II device is
5V-tolerant?
I know that JTAG signals are, but nothing about other configuration
signals.
As far as they are connected usualy to Serial PROM (XC17S00A), which is
not 5V-tolerant, they are pracitally not 5V-tolerant. But the /PROGRAM
input
is driven by external logic, so I can deduce nothing...

--
Regards,
Pawel J. Rajda




Article: 44892
Subject: Re: Maximum frequency in Virtex and Virtex-E Devices
From: "enterpoint" <enterpoint@businessunmetered.com>
Date: Thu, 4 Jul 2002 15:37:47 +0100
Links: << >>  << T >>  << A >>
The simple answer to the question is the system performance figure of 240
MHz for the Virtex-E. Beware these figures are only a very rough guide to
performance. I have not seen a system figure for Virtex II but significantly
faster than both these families is my practical experience.

Performance will vary due to a number of factors including coding style of
HDL, your synthesiser, the placement table used, routing density, device
packing density, pinout and many many more factors. A designer who knows the
tools and architecture and uses them effectively can typically achieve up to
double the performance over a push button approach of writing HDL and
running through the tools. To give an extreme example we have designed a
CRC32 generator checker with 3 levels of LUTs which will run at 380 MHz in a
Virtex II. This performance however is only obtained by many hours of hand
crafting. The same basic design before hand crafting was typically reaching
200 MHz.

John Adair
Enterpoint Ltd.




"Heiko Kalte" <kalte@hni.upb.de> wrote in message
news:3D23FFDB.AB133B84@hni.upb.de...
> Dear Community,
> I would like to compare the maximum frequency of the Virtex and Virtex-E
> family, the databook says 200MHz for the Virtex family and 133MHz (4 LUT
> levels) for the Virtex-E family. There are obviously different bases for
> the calculation. Because Virtex-E should be faster. Is there a common
> basis (e.g. 4 LUT levels) to compare the two series?
> Heiko
>
>
> --
> ---------------------------------------------------------------
> Dipl. Ing. H. Kalte               |
> HEINZ NIXDORF INSTITUTE           | Office: F1.213
> System and Circuit Technology     | Fon: +49 (0)5251 60-6459
> Fürstenallee 11                   | Fax: +49 (0)5251 60-6351
> 33102 Paderborn, Germany          |
> ---------------------------------------------------------------
> mailto:kalte@hni.uni-paderborn.de
> http://wwwhni.uni-paderborn.de/sct/
> ---------------------------------------------------------------
>
> Home of the RAPTOR Rapid Prototyping Systems
> http://www.RAPTOR2000.de/
>
> ---------------------------------------------------------------



Article: 44893
Subject: Re: Maximum frequency in Virtex and Virtex-E Devices
From: Ray Andraka <ray@andraka.com>
Date: Thu, 04 Jul 2002 15:38:42 GMT
Links: << >>  << T >>  << A >>
I think 240 MHz is optimistic for VirtexE, especially considering that the
minimum pulse width for the SRL16 is about 238 MHz for a VirtexE-7.  It takes an
extraordinary designer to get 240 MHz out of VIrtexE in designs containing
arithmetic or block memory.   Practical top end for VirtexE-6 is around 195 MHz,
VirtexE-8 around 240 MHz for very careful design.  For 2.5v Virtex, a -4 is
about 130 Mhz, a -6 about 160 MHz.

Frankly, I've been finding that the VirtexII-4 is about the same performance as
a VirtexE-6 as far as arithmetic is concerned for carefully handplaced designs.
Stuff that doesn't use the carry chain does appear to be faster in the VirtexII.

enterpoint wrote:

> The simple answer to the question is the system performance figure of 240
> MHz for the Virtex-E. Beware these figures are only a very rough guide to
> performance. I have not seen a system figure for Virtex II but significantly
> faster than both these families is my practical experience.
>
> Performance will vary due to a number of factors including coding style of
> HDL, your synthesiser, the placement table used, routing density, device
> packing density, pinout and many many more factors. A designer who knows the
> tools and architecture and uses them effectively can typically achieve up to
> double the performance over a push button approach of writing HDL and
> running through the tools. To give an extreme example we have designed a
> CRC32 generator checker with 3 levels of LUTs which will run at 380 MHz in a
> Virtex II. This performance however is only obtained by many hours of hand
> crafting. The same basic design before hand crafting was typically reaching
> 200 MHz.
>
> John Adair
> Enterpoint Ltd.
>
> "Heiko Kalte" <kalte@hni.upb.de> wrote in message
> news:3D23FFDB.AB133B84@hni.upb.de...
> > Dear Community,
> > I would like to compare the maximum frequency of the Virtex and Virtex-E
> > family, the databook says 200MHz for the Virtex family and 133MHz (4 LUT
> > levels) for the Virtex-E family. There are obviously different bases for
> > the calculation. Because Virtex-E should be faster. Is there a common
> > basis (e.g. 4 LUT levels) to compare the two series?
> > Heiko
> >
> >
> > --
> > ---------------------------------------------------------------
> > Dipl. Ing. H. Kalte               |
> > HEINZ NIXDORF INSTITUTE           | Office: F1.213
> > System and Circuit Technology     | Fon: +49 (0)5251 60-6459
> > Fürstenallee 11                   | Fax: +49 (0)5251 60-6351
> > 33102 Paderborn, Germany          |
> > ---------------------------------------------------------------
> > mailto:kalte@hni.uni-paderborn.de
> > http://wwwhni.uni-paderborn.de/sct/
> > ---------------------------------------------------------------
> >
> > Home of the RAPTOR Rapid Prototyping Systems
> > http://www.RAPTOR2000.de/
> >
> > ---------------------------------------------------------------

--
--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: 44894
Subject: 3.3 volt tolerance in Virtex-II Pro?
From: "Guerre" <deton8@aol.com>
Date: Thu, 4 Jul 2002 16:17:37 +0000 (UTC)
Links: << >>  << T >>  << A >>
Am I reading the data sheet correctly?  Is it true that most of the pins are
not 3.3 volt tolerant on the Pro parts??!?  Arrrgh!

--
--00--
Guerre



Article: 44895
Subject: Re: Fixed point arithmetic
From: Addie Tang <"addietang<PLEASE_REMOVE_ME>"@netscape.net>
Date: Fri, 05 Jul 2002 01:08:37 +0800
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------030603000801030005070900
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

    You can try using package "std_logic_arith" in library IEEE.
Please see the example in the attachment.



John Williams wrote:

>Hi folks,
>
>Does anybody know of a synthesisable VHDL package/library for
>generalised fixed point arithmetic?  
>
>I'm picturing a scheme whereby you specify the number of fractional and
>integer bits in the operands and result, and it handles the shifts and
>bit padding etc seamlessly.  Supported ops would be addition,
>subtraction, multiplication, with signed and unsigned options, that sort
>of thing  (basically an extension to the existing signed/unsigned
>support).
>
>Of course in any single case it's easy to work out, for example, which
>bits to keep and which to throw out when adding two numbers with
>different numbers of fractional and integer bits, but it would be great
>to have wrapped nicely in a single package.
>
>Any suggestions?  
>
>Thanks,
>
>John
>
Regards,
Addie Tang

--------------030603000801030005070900
Content-Type: text/plain;
 name="arith_test.vhd"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="arith_test.vhd"

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_arith.all;



entity test_arith is
   port(a_in     : in std_logic_vector(7 downto 0);
        b_in     : in std_logic_vector(7 downto 0);
   
        uadd_out : out std_logic_vector(9 downto 0);
        sadd_out : out std_logic_vector(9 downto 0)
        );
end test_arith;

architecture behavioral of test_arith is
begin

   uadd_out <= UNSIGNED(EXT(a_in, 10)) + UNSIGNED(EXT(b_in, 10));
   sadd_out <= SIGNED(SXT(a_in, 10)) + SIGNED(SXT(b_in, 10));

end behavioral;

--------------030603000801030005070900--


Article: 44896
Subject: Re: Virtex II - IO TILE, IOB PAD #4
From: mrand@my-deja.com (Marc Randolph)
Date: 4 Jul 2002 10:43:16 -0700
Links: << >>  << T >>  << A >>
Philip Freidin <philip@fliptronics.com> wrote in message news:<4c68iu8oqnild2v82hm34pkvldeimh8n9o@4ax.com>...
> On 4 Jul 2002 05:50:22 +0100, "Bill" <not@home.com> wrote:
> >Hi,
> >
> >XAPP 266 describes inputting a DQS (data strobe) to an IOB pin which
> >occupies PAD 4 of the IO Tile.   This allows the strobe (clock) signal to
> >utilize the local HEX clock line which connects five rows (pins) above and
> >six rows (pins) below the DQS pin.  Data pins can then occupy the 11 (5+6)
> >pins and use the DQS clock in their respective IOB's.
> >
> >I have looked at all of the current Virtex II datasheets, user guides, app
> >notes, and can not find any documentation which illustrates what pins
> >correspond to this grouping of pins for a certain device package.   For
> >example, for a 1000 series device in the FG456 package, all io pins are
> >utilized, whereas in the 500 series, certain io pins are removed, and in the
> >250 device even more pins are removed.
> >
> >Does anyone know where to obtain this info?
> >
> >Bill
> 
> 
> Probably the only way is with the FPGA Editor.


I sure wouldn't want to do it that way!

The Xilinx web site seems to be following the general trend of other
vendors - making useful stuff like this increasingly difficult to
find.

Perhaps what Bill was looking for is:

http://www.xilinx.com/products/virtex/v2packages.htm

There is also a link to pinout information on this page, but it
appears to be very incomplete (ie, only for the 256 pin package):

http://www.xilinx.com/products/virtex/v2packages.htm

They used to have a text listing of the pinout, in pad order, but I
can't find it anymore.

Lastly, there is a pinout compability tool here, which is probably
what Bill really needs:

http://www.xilinx.com/applications/web_ds_v2/

   Marc

Article: 44897
Subject: Re: How can I preserve FFs in LeonardoSpectrum?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Jul 2002 13:51:17 -0500
Links: << >>  << T >>  << A >>
        In my case, I am using Verilog, and following your suggestions,
I tried using preserve_signal, preserve_driver, noopt, and dont_touch,
but for some reason, none of them worked.
Here is how the code looks like.


reg    My_FF;
//exemplar attribute My_FF preserve_driver TRUE


When LeonardoSpectrum synthesizes my design, the synthesis report does
mention that it is merging (removing) certain parallel (equivalent) FFs
into one FF, but the FFs I have attached the aforementioned attributes
to prevent merging still get merged, and the synthesis report never
mentions about it.
Looking at the EDIF netlist generated, LeonardoSpectrum does attach
aforementioned attributes, so it is somehow recognizing them, but it
attaches such attributes to a net (wire) coming from a FF which is not
what I want because I want the FF name and the FF itself preserved.
I am afraid what I will end up having to do will be to manually
duplicate FFs myself by editing the EDIF netlist since I cannot seem to
prevent LeonardoSpectrum from removing equivalent FFs.
        Reading other people's suggestions, it sounds like
preserve_signal or preserve_driver works fine with VHDL, but from my
experience, I feel like it doesn't work at all with Verilog.
I don't believe the above code is wrong, so this problem really puzzles
me.
Can the problem I am experiencing be some kind of known bug of
LeonardoSpectrum?
The version of LeonardoSpectrum I tried were 2002a_049_Altera and
2001a_028_Altera.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Roberta Crescentini wrote:
> 
> I had to put these commands in my vhdl source (it 's working) :
> 
> attribute preserve_signal : boolean;
> attribute preserve_signal of SIGNAL_NAME : signal is true;
> 
> I don't know the equivalent for verilog.
> 
> bye
>

Article: 44898
Subject: Re: How can I preserve FFs in LeonardoSpectrum?
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Thu, 04 Jul 2002 13:54:26 -0500
Links: << >>  << T >>  << A >>
        I also tried not flattening the hierarchy of the design, but
didn't help . . .
In addition to not flattening the hierarchy of the design, I also tried
using preserve_signal, preserve_driver, noopt, and dont_touch, but none
of them helped.



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)



Laurent Gauch wrote:
> 
> Hi,
> 
> Before try to keep the hierarchie of your design.
> If you are working flatten with a big design, Leo can simplify complex
> feedback.
> (you can isolate a part of you design using the 'ungroup' tcl function)
> 
> Laurent
> www.amontec.com
>

Article: 44899
Subject: Lessons Learned -- Need your inputs
From: vhdlcohen@aol.com (ben cohen)
Date: 4 Jul 2002 17:09:06 -0700
Links: << >>  << T >>  << A >>
Am working on a paper for 2002 MAPLD conference, and would like to
hear your feedback from your experiences on "lessons learned" in you
use of HDL, tools, management(?), EDA vendors, chips, synthesis, TBs,
code reviews, etc.
I will share the results into a PPT presentation.
Thanks,
Ben
----------------------------------------------------------------------------
Ben Cohen     Publisher, Trainer, Consultant    (310) 721-4830  
http://www.vhdlcohen.com/                 vhdlcohen@aol.com  
Author of following textbooks: 
* Real Chip Design and Verification Using Verilog and VHDL, 2002 isbn
0-9705394-2-8
* Component Design by Example ",  2001 isbn  0-9705394-0-1
* VHDL Coding Styles and Methodologies, 2nd Edition, 1999 isbn
0-7923-8474-1
* VHDL Answers to Frequently Asked Questions, 2nd Edition, isbn
0-7923-8115
------------------------------------------------------------------------------



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