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 36750

Article: 36750
Subject: Re: FPGA synthesis
From: khtsoi@cse.cuhk.edu.hk
Date: 19 Nov 2001 11:00:18 GMT
Links: << >>  << T >>  << A >>
Madhura <madhura@controlnet.co.in> wrote:
> The design is being targetted to VirtexE family. For the gate level simulation, I require VHDL netlist. If I generate that through dc_shell, the INIT generic for the LUT's are not being associated with the LUT's. So it gives warning during the compilation. So the netlist has to be given to FC2 to have these INIT parameters. Now those parameters are associated with the LUT's. But now the warning is given for the RAM's..RAMB4_S*.. The xnf files for these can not be opened for analyze.
> can u suggest some solution for this?
Hi,
you must use the "--synopsys dc_script_begin/end" and "--set_attribute" to
generate INIT and RLOC in *.sedif from *.vhd.
The "attribute INIT of xyz: label is "ABC";" never work again in dc_shell
---- Brittle

Article: 36751
Subject: Re: Prototyping Board
From: "John Adair" <newsanswer@removethisenterpoint.co.uk>
Date: Mon, 19 Nov 2001 11:22:24 -0000
Links: << >>  << T >>  << A >>
We have a product under development that will suit. Contact me for more
details.


John Adair
Enterpoint Ltd.
Unit 4
Malvern Hills Science Park
Geraldine Road
Malvern
Worcestershire
United Kingdom
www.enterpoint.co.uk

The views expressed in this message are those of the writer and not
necessarily those of Enterpoint Ltd.. The use of information in this message
is without warranty and persons using the information are advised to make
their own checks as to it's validity. No responsibility will be accepted for
any incorrect, inaccurate or missleading information supplied.


John Jakson <johnjakson@earthlink.net> wrote in message
news:38111bbc.0111161334.5a8349bf@posting.google.com...
> "Maf" <maf.gg@wanadoo.fr> wrote in message
news:<9t010h$1gu$1@wanadoo.fr>...
> > Check out www.datacube.com for their MaxRevolution product.
> >
> >
> > David Eadie <david.eadie@cs.tcd.ie> a écrit dans le message :
> > a0ce2abd.0111140648.1f92ae6b@posting.google.com...
> > > Hi,
> > >
> > > I'm interested in exploring the image processing potential of using
> > > FPGAs within high-speed video cameras.  Initially I would like to get
> > > an FPGA prototyping/development/evaluation kit working within the PC
> > > itself.
> > >
> > > Features I would like:
> > >
> > > -PCI-card-based, to allow easy I/O to/from PC memory.
> > > -on-card memory to store image data and results. At least 8 MB,
> > > preferably more.
> > > -Virtex II device (2 million gates, or more).
> > > -Some FPGA I/O pins accessible through a header/connector on the
> > > PCI-card.
> > >
> > > Does anyone know if such a card, or similar, exists?
> > > Are there any other important features I should look for?
> > >
> > > Thanks
> > >
> > > David Eadie,
> > > Computer Vision and Robotics Research Group,
> > > Dept. of Computer Science,
> > > Trinity College Dublin.
>
> Datacube looks like an interesting solution to video, never heard of
> them before. Also right across the Irish sea in Glasgow is Nallatech,
> they have a range of high end boards with many PCI fpga video apps off
> the shelf. Nots so far away is Alpha Data with similar products in
> Edinburgh. Also Sundance in Chesham. There are a couple of other
> companies in UK, Germany as well. Search google for "pci fpga boards".
>
> Also try http://www.optimagic.com/
> & XIlinx 3rd party PCI board lists.
>
http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=protoboards_protobo
ards_page
>
> Regards
>
> John Jakson



Article: 36752
Subject: Ann: Low cost Spartan2 FPGA board
From: "Tony Burch" <tony@BurchED.com.au>
Date: Tue, 20 Nov 2001 01:23:43 +1100
Links: << >>  << T >>  << A >>
Burch Electronic Designs announces the new
B5-SPARTAN2+ board.

A low cost, high performance, easy-to-use board,
for prototyping and education.

Introductory price:  US$149,  available now
http://www.burched.com.au/bedspartan2.html

Features:
* 200,000 gates (XC2S200 device)
* Works with the free Xilinx WebPACK (tm) software
* Header programmable PLL oscillator - select any frequency between 1 -
100MHz
* JTAG and serial mode configuration download pod cable, with schmitt
buffering
* Pod has "lock configuration" switch - your FPGA will not "de-configure" by
accident
* Array of high and mid frequency decoupling capacitors on underside of
board
* Multilayer board
* Test LED and pushbutton switch
* Uses a Plug-On Module concept for system expansion
* Low cost
* Easy to use
* Great for education, or some serious prototyping !
* Ideal for University and Technical College FPGA design courses

In stock now.
Order form available.
10-pack deals for volume purchases.

International orders are very welcome.

Best regards
Tony Burch
http://www.BurchED.com
Low cost FPGA boards, for seriously
powerful prototyping and education !






Article: 36753
Subject: Re: Decoupling capacitors on Virtex II
From: ian.dedic@acg.fujitsu-fme.com (Ian Dedic)
Date: 19 Nov 2001 06:31:56 -0800
Links: << >>  << T >>  << A >>
It's a common misconception that smaller value decouplers are "better"
at high frequencies, in fact it's the inductance that matters. This is
indirectly linked to value by physical size, but if you compare 100nF
and 10nF in 0805 packages they have the same inductance (HF decoupling
performance), and the 100nF will be 10x better at lower frequencies.

Yes the self-resonant frequency will be lower, but once inductance
takes over the impedance (which is what matters) is the same. It all
depends over what frequency range you want to keep the supply
impedance low; if you need a wide range things get difficult. And the
more different capacitor sizes and values you use, the more the chance
of getting nasty resonances between the inductance of one and the
capacitance of another.

In RF and microwave they don't care about performance below 100's of
MHz, so the smallest value capacitor will perform just as well as a
larger one and may be better because it's available in a smaller case
size. With high-speed digital circuits the lower frequency of the
noise can be kHz depending on what processing is going on (for
example, at the frame rate in some systems).

Adding a small number of lower-value capacitors has little effect,
because the most important factor is the total equivalent series
inductance. Inter-plane capacitance has negligible inductance, but
also pretty small capacitace -- fine at RF frequencies, but less
useful in the 10's to 100's of MHz region.

We work on design of (among other things) high-speed CMOS DACs, and
have to get low supply impedance over a frequency range of kHz to GHz.
In the region from a few MHz upwards, the best approach is a large
number of physically small high-value surface-mount ceramics (eg. 0805
or smaller, 1uF or greater) which provide charge for both high-speed
edges and lower frequencies without any resonances. Plus of course a
large value low ESR elctrolytic (eg. 330uF OSCON) to provide the
charge below a few MHz.

Ian Dedic

Chief Engineer
Mixed Signal Division
Fujitsu Microelectronics Europe

"Falk Brunner" <Falk.Brunner@gmx.de> wrote in message news:<9sh63h$1249vl$1@ID-84877.news.dfncis.de>...
> "Philippe Robert" <PhilippeR@sundance.com> schrieb im Newsbeitrag
> news:3bebb7ef$1@peer1.news.newnet.co.uk...
> > Hi there,
> >
> > I found an application note on the Xilinx website (xapp158) about
>  decoupling
> > capacitors. It is explained that high frequency and mid-frequency
>  capacitors
> > are required.
> >
> > For the high frequency capacitor, I will use 100nF. It says in that app to
> > fit 1 100nF cap per Vcc. (I have counted as Vcc pins  Vccio, Vccaux and
> 
> 100nF  isnt that good at HIGH frequencys. Remember, the higher the
> capacitance, the higher the (parasitic) inductance of a cap.
> And since the Virtex-II are damm fast devices, I would use 10nF caps. Not
> 10x10nF, but lets say at least 4 10nF caps to decouple the core. Also
> remember, the higher the value of a decoupling cap, you can place them more
> far away from the VCC pins. Usually, you have a cascade of caps, 10nF,
> 100nF, 10uF 1000uF.
> 
> > Vccint pins). I end up with 64 cpas for a XC2V1000-FG456 !!
> 
> Hmm, try redestributiing the capacitance into less caps, but dont forget to
> use small ones (10nF or lower) for the "really" high frequencys. In
> microwave engineering they use sometimes even 100pF instead of 1nF because
> of the lower inductance.
> And dont forget a good ground-VCC planes. In your layer stacking, the
> GND-VCC planes should be close together, forming a superb high frequncy
> capacitor.

Article: 36754
Subject: Re: Decoupling capacitors on Virtex II
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 19 Nov 2001 10:20:30 -0500
Links: << >>  << T >>  << A >>
Ian,

You are a man after my own heart. You seem to actually understand what
is going on rather than just having learned a few "rules of thumb". So
many people who design power distibution never actually read the
capacitor data sheets and have no true understanding of how they work at
high frequencies. 

I agree 100% with everything you said, expecially the part about using a
single large value, low ESR device on the board. I have read several
people here say that you need multiple tantalums per chip which is
nonsense. The only reason (that I know) of placing caps near the load is
to minimize the effects of inductance in the power distibution. But
since the large, bulk caps have very high inductance relative to the
power distribution, there is no need to keep them close to the load. So
you can use one large device anywhere on the board. 

Another point that often escapes designers is that it does not matter if
your noise frequecies are above the self resonant point of the cap. At
those frequencies the cap is actually an inductor. But as long as the
impedance is low, it still acts to decouple the noise. So for high
freqs, the only relevant factor is the total impedance to ground. By
keeping this impedance low at the frequencies of the noise, you will get
good decoupling and a quiet power plane. So lots of MLCC caps are good
and more are better. As you say, the value is not so important, moreso
the physical size. Ceramic 100 nF, 0603 caps work great and don't
clutter up the board with bulk. 



Ian Dedic wrote:
> 
> It's a common misconception that smaller value decouplers are "better"
> at high frequencies, in fact it's the inductance that matters. This is
> indirectly linked to value by physical size, but if you compare 100nF
> and 10nF in 0805 packages they have the same inductance (HF decoupling
> performance), and the 100nF will be 10x better at lower frequencies.
> 
> Yes the self-resonant frequency will be lower, but once inductance
> takes over the impedance (which is what matters) is the same. It all
> depends over what frequency range you want to keep the supply
> impedance low; if you need a wide range things get difficult. And the
> more different capacitor sizes and values you use, the more the chance
> of getting nasty resonances between the inductance of one and the
> capacitance of another.
> 
> In RF and microwave they don't care about performance below 100's of
> MHz, so the smallest value capacitor will perform just as well as a
> larger one and may be better because it's available in a smaller case
> size. With high-speed digital circuits the lower frequency of the
> noise can be kHz depending on what processing is going on (for
> example, at the frame rate in some systems).
> 
> Adding a small number of lower-value capacitors has little effect,
> because the most important factor is the total equivalent series
> inductance. Inter-plane capacitance has negligible inductance, but
> also pretty small capacitace -- fine at RF frequencies, but less
> useful in the 10's to 100's of MHz region.
> 
> We work on design of (among other things) high-speed CMOS DACs, and
> have to get low supply impedance over a frequency range of kHz to GHz.
> In the region from a few MHz upwards, the best approach is a large
> number of physically small high-value surface-mount ceramics (eg. 0805
> or smaller, 1uF or greater) which provide charge for both high-speed
> edges and lower frequencies without any resonances. Plus of course a
> large value low ESR elctrolytic (eg. 330uF OSCON) to provide the
> charge below a few MHz.
> 
> Ian Dedic
> 
> Chief Engineer
> Mixed Signal Division
> Fujitsu Microelectronics Europe

-- 

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: 36755
Subject: Re: Xilinx and Multirate clock ??
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 19 Nov 2001 10:23:20 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> Lasse Langwadt Christensen wrote:
> 
> > The DLL can correct the duty cycle, so it's a nice 50-50 for the uneven
> > dividers, it can also be used to divide a clock or multiply it by two
> >
> > So I guess you could take a 54MHz use two DLLs to get it to 216MHz and
> > then divide that to get all you other frequencies
> >
> >
> 
> That statment is true for Virtex and Spartan-II.
> In the newer Virtex-II the DLL can do more,
> it can also, on its frequency synthesis output,
> provide any frequency that is M/D time the input frequency.
> 
> M is the multiplier and can be any integer up to 32,
> D is the divider and can also be any integer up to 32.
> So you can multiply and divide simultaneously.
> 
> You can drive the DLL with 90 MHz, pick M=31 and D=9, and get 310 MHz out. (
> just to illustrate that the output is valid although the multiplication
> itself seems to create an excessively high frequency)
> And the Virtex-II Digital Clock Manager also has fine-grain phase
> adjustment. Clever circuit!
> 
> Peter Alfke

Are the DCM on the Virtex II chips fully functional? I have heard
through the grapevine that there are problems. I have not heard anything
specific, just that I should check with Xilinx before planning to use
the DCM.


-- 

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: 36756
Subject: Re: Virtex-II Pin-Incompatibility
From: rickman <spamgoeshere4@yahoo.com>
Date: Mon, 19 Nov 2001 10:41:54 -0500
Links: << >>  << T >>  << A >>
This is a very significant issue. I know that Altera boasts of this
feature with several of their products. Not only are they pin compatible
in the same package, but you can design for a larger FG package and use
a smaller one as a subset. So you can build your boards with a wide
range of chips which will fit the socket. But if pins are swapped
between the different pinouts, it makes it MUCH harder to keep up with
the design changes as you use different chips. 

Is this a problem with other Xilinx families as well?



Jonas Weiss wrote:
> 
> I'm working on a design using either two XC2V1000 (FG456 package) or
> XC2V3000 (FG676 package). As the board is part of a prototype system we
> wanted to start with the small devices and if necessary up grade to the
> 3000s later. First we discovered that roughly half of the LVDS channels
> can not be used because the differential pairs on one package do not
> correspond to the pairs on the other package (what an inconvenience).
> Running a place and route yielded that of the pins I thought would
> match, there are still pairs with inversed polarity between the
> packages...which was confirmed by a look at the data sheet. :-(
> Namely:
> 3000                    1000
> 
> M22->N                K20->P
> M21->P                K19->N
> 
> N21->P                L19->N
> N22->N                L20->P
> 
> L21->P                 J19->N
> L22->N                 J20->P
> 
> I remember having seen a nice Xilinx brochure with a transparent print
> of one package which fits perfectly over the drawing of the next bigger
> package...how misleading.
> 
> If anybody knows of any other hidden obstacles I might struggle over,
> any comments will be appreciated very much.
> 
> Thanks
> 
> Jonas

-- 

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: 36757
Subject: Re: how to limit the fanout in APEX20K400E
From: daniel <doesn´tmatter@who_talks_to_you.com>
Date: Mon, 19 Nov 2001 07:43:19 -0800
Links: << >>  << T >>  << A >>
Hi,

Synplicity´s SynplifyPro does allow you to limit the fan-out by using the "syn_maxfan" attribute. The attribute can be applied to either the complete device (which doesn´t make a lot of sense because you would limit the fan-out for all of the flops) or specific sequential elements which are critical in timing. You could add the attribute to your VHDL or Verilog sources or take advantage of the "drag and drop" capability provided by SynplifyPro. When using this possibility you could "drag and drop" specific registers from SynplifyPro´s graphical editor to the SCOPE constraint editor.

Article: 36758
Subject: Re: Decoupling capacitors on Virtex II
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 19 Nov 2001 07:48:54 -0800
Links: << >>  << T >>  << A >>
Microfarads = uF ....

Will go fix it.

There are some shareware programs for evaluating bypass caps. (For those without
spice, but hey, Berkeley Spice is free ....).

I'll see if I can find the reference...

Austin

Rick Filipkiewicz wrote:

> Austin Lesea wrote:
>
> > More to consider than just bypassing....
> >
> >  http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=si_pcbcheck
> >
> > Austin
> >
>
> Nice checklist although the "simulation" rqeuirements presuppose access to a SPICE
> engine. Is there a freeware/opensource/public-domain implemetation ?
>
> Only one quibble on TI (= TextIntegrity): Are you really recommending milliFarad
> (e.g. 4.7mF) caps ? Perhaps its a misprint for 4.7MF :-).


Article: 36759
Subject: Re: FPGA synthesis
From: Madhura <madhura@controlnet.co.in>
Date: Mon, 19 Nov 2001 08:09:50 -0800
Links: << >>  << T >>  << A >>
Hello,
	Thanks for your reply. But can you just elaborate the solution. I will tell you my problem in more detail.
	I am generating the vhdl netlist for gate level simulation from dc_shell. The target library is VirtexE2000-6. But in the vhdl netlist the combinational logic is being inferred by LUT's but the INIT attributes are not associated with them. So the LUT's don't get initilised and the output of the combinational logic is not proper. 
	Can you elaborate on the solution which you are suggesting?
Do I need to set the attributes in the vhdl RTL or I have to set them during dc_shell flow?
	Thanks in advance.
Madhura

Article: 36760
Subject: Re: FPGA synthesis
From: khtsoi@cse.cuhk.edu.hk
Date: 19 Nov 2001 17:22:28 GMT
Links: << >>  << T >>  << A >>
Madhura <madhura@controlnet.co.in> wrote:
> Hello,
> 	Thanks for your reply. But can you just elaborate the solution. I will tell you my problem in more detail.
> 	I am generating the vhdl netlist for gate level simulation from dc_shell. The target library is VirtexE2000-6. But in the vhdl netlist the combinational logic is being inferred by LUT's but the INIT attributes are not associated with them. So the LUT's don't get initilised and the output of the combinational logic is not proper. 
> 	Can you elaborate on the solution which you are suggesting?
> Do I need to set the attributes in the vhdl RTL or I have to set them during dc_shell flow?
> 	Thanks in advance.
> Madhura

Hi,

I am not sure if this is what you want:

<---test.vhd begin--->
architecture syn of test is
...
--synopsys dc_script_begin
--set_attribute MY_LUT INIT "CACA" -type string
--synopsys dc_script_end
...
begin
...
MY_LUT: LUT4
--synopsys translate_off
generic map (INIT => X"CACA")
--synopsys translate_on
port map (...)
...
end syn;
<---test.vhd end--->

<---test.sedif begin--->
...
(instance MY_LUT
 (viewRef Netlist_representation
  (cellRef LUT4 (libraryRef xdc_virtexe_6))
 )
 (property INIT (string "CACA")))
)
...
<---test.sedif end--->

---- Brittle

Article: 36761
Subject: modelsim: free, evaluation or full !?
From: "Seb" <someone@microsoft.com>
Date: Mon, 19 Nov 2001 18:27:32 +0100
Links: << >>  << T >>  << A >>
Hello all.

With our ISE tools, we got Modelsim Xilinx edition, but no license.
We installed the free version, it runs fine, also with the Xilinx
components.

My question: what is the difference (what are the nags) between the three
Modelsim versions on the cd:
- full version
- evaluation version
- free version

thanx
cheers,
    Seb



Article: 36762
Subject: Modelsim
From: "Andrew Gray" <andrewgray@iafrica.com>
Date: Mon, 19 Nov 2001 19:43:54 +0200
Links: << >>  << T >>  << A >>
Hi

Does anyone know where I can get hold of a full-version licence for
Modelsim? I only need it for 2 or 3 days.

Is there any alternative VHDL simulator like modelsim that is freely
available?

Thanks

Andrew



Article: 36763
Subject: DLL cycle-to-cycle jitter
From: nurit eliram <nospam@newsranger.com>
Date: Mon, 19 Nov 2001 17:59:24 GMT
Links: << >>  << T >>  << A >>
Hi.
I have seen that the period jitter of DLL of virtex-II device is 150 ps.

Can I have any figures about it's cycle-to-cycle jitter ?

ThanKX



Article: 36764
Subject: Re: DLL cycle-to-cycle jitter
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 19 Nov 2001 10:21:49 -0800
Links: << >>  << T >>  << A >>
Nurit,

From any cycle, to the next cycle, the period out of the Virtex II DCM
(using the DLL feature) can not change by more than a tap value, plus
whatever input jitter may also be present.

For Virtex II that is ~ 55ps.

The period jitter is measured by accumulating a histogram of > 200,000
periods, and fitting  a gaussian curve (left and right tail fitting) to get
the peak to peak value.

Spectral analysis of the histogram shows that the jitter is random, and has
no deterministic component.

Thus the input jitter going into the DLL may be added to the internal jitter
quadratically to get the output jitter.

Clock forwarded interfaces have larger margin as a result, as the cycle to
cycle jitter is important as to the sampling of input data by the IOB's.
Worst case, the input data sampling instant error is not the peak to peak
value, but the cycle to cycle value.

This behavior is completely different than than of a PLL, where the PLL
usually provides some filtering of high frequency jitter components, and
where there is no fixed relationship from an input clock to an output clock
as there is in the DLL (PLL cycle to cycle jitter is bounded only by the
peak to peak jitter, whereas the DLL cycle to cycle jitter is bounded the
delay line tap change).

Austin

nurit eliram wrote:

> Hi.
> I have seen that the period jitter of DLL of virtex-II device is 150 ps.
>
> Can I have any figures about it's cycle-to-cycle jitter ?
>
> ThanKX


Article: 36765
Subject: Re: Incrementing counter from state-machine
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 19 Nov 2001 18:43:27 GMT
Links: << >>  << T >>  << A >>
Russell Shaw wrote:

> I traced from the clock input pin to the clock divider, and looked at
> the fanout from the last flip-flop. I found there were a few counters
> implemented as scattered logic, not being recognized as counter
> templates. I found just one or two extra lines in a process can prevent
> recognition by the compiler as a counter. 

I noticed that about Leonardo -- it's VERY picky about what it considers
a counter.

What's bizarre is that I ran Leonardo on two different machines (one a
Sparc running Solaris 7, the other running Solaris 2.5) and I got
different results (the 2.5 machine did the right thing for a counter;
the S7 machine didn't!) for identical code with identical scripts.  I
haven't gotten to the bottom of that one yet. 

Moral: pay attention to the report and log files.

-a

Article: 36766
Subject: Re: Decoupling capacitors on Virtex II
From: John_H <johnhandwork@mail.com>
Date: Mon, 19 Nov 2001 19:27:24 GMT
Links: << >>  << T >>  << A >>
The best comment in this thread so far IMHO.  Thanks, Rick.

Smaller valued caps can give lower impedances at higher frequencies but if
one looks at the datasheets from Kemet or AVX or Vishay, you'll find that
lower capacitance values don't necessarily give you (much) better high
frequency impedence.  A good look at the Z vs F curves will shed some light
on how good a cap can be at high frequencies.  And just as the bulk, low ESR
tantalum caps go, higher value (1uF for instance) capacitors may not have a
good enough impedance near 1GHz to deal with those <1nS switching
transients.  The impedance versus frequency information is sometimes tough
to find but it's out there.  The LICA array from AVX is one example where
the attempt to provide best-of-class high frequency performance is made;
the practicality might be limited, though.

rickman wrote:

> Another point that often escapes designers is that it does not matter if
> your noise frequecies are above the self resonant point of the cap. At
> those frequencies the cap is actually an inductor. But as long as the
> impedance is low, it still acts to decouple the noise. So for high
> freqs, the only relevant factor is the total impedance to ground. By
> keeping this impedance low at the frequencies of the noise, you will get
> good decoupling and a quiet power plane. So lots of MLCC caps are good
> and more are better. As you say, the value is not so important, moreso
> the physical size. Ceramic 100 nF, 0603 caps work great and don't
> clutter up the board with bulk.


Article: 36767
Subject: Re: Synopsys+Xilinx vs Synplicity
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 19 Nov 2001 20:15:06 GMT
Links: << >>  << T >>  << A >>
khtsoi@cse.cuhk.edu.hk wrote:
> 
> Hi,
> 
> Someone told me that tools from Synplicity is better than the Synopsys
> Xilinx combination in FPGA place and route process. 

Neither Synplify nor Synopsys do place-and-route for Xilinx.

> I am sick with the
> bad routing design in Alliance3.1i. Also, it takes me more than 1 day
> to par a design using only 45% slices of a XCV1000E (on a Sun E4500).

Perhaps it's a design issue?

-a

Article: 36768
Subject: Re: 'Timing' simulation in ModelSIM
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 19 Nov 2001 20:18:38 GMT
Links: << >>  << T >>  << A >>
Kris Nichols wrote:
> 
> Brian,
> 
> It turns out that when implementing my design in Xilinx environment, the XST
> synthesizer would attempt to reduce logic for optimization purposes.  The
> synthesizer thought that some of my pins were never used, and indirectly
> removed all logic related to my 'input_value' port (without explicitly
> stating it had done this).  The SDF file produced by Xilinx wouldn't have
> any reference to the 'input_value' port pins, so a 'timing' simulation in
> ModelSIM would think that this port doesn't exist.  So is it safe to say
> that the following messages indicate which pins are not implemented:
> WARNING : (HDL__0002). Input <name_of_pin> is never used.
> WARNING : (HDL__0005). Signal <name_of_pin> is assigned but never used.
> Is there any way (workarounds, etc.) I can use prevent the XST synthesizer
> from doing this?  Thanks.

If the synth tool tells me that it's optimized a net away (esp. pins)
that I feel I'll need later, I simply AND all of these "unused" inputs
together, and drive the AND out an unused pin.

Quick and dirty but it works.

-a

Article: 36769
Subject: Re: Xilinx and Multirate clock ??
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 19 Nov 2001 20:23:22 GMT
Links: << >>  << T >>  << A >>
Lasse Langwadt Christensen wrote:

> -Lasse
> -- Lasse Langwadt Christensen,
> -- A Dane in Phoenix, Arizona

Wow...summer must've been, um, "interesting" for ya!

-andy
-- A Jersey boy in Tucson, Arizona

Article: 36770
Subject: Re: Synopsys+Xilinx vs Synplicity
From: Ray Andraka <ray@andraka.com>
Date: Mon, 19 Nov 2001 20:31:02 GMT
Links: << >>  << T >>  << A >>
If it is taking more than a day to PAR >50% of the slices in an XCV1000E,
you are probably setting the timing constraints too aggressively for your
design (or looking at it the way I would, your design is not a good
implementation for the clock constraints you are using).  At that kind of
turn around time, it is highly unlikely that you are doing any floorplanning
either.

Worst case PAR times I'm currently seeing on 92% full 2000E's being clocked
at 160 MHz is on the order of about 2.5 hrs, granted they are floorplanned.

Andy Peters wrote:

> khtsoi@cse.cuhk.edu.hk wrote:
> >
> > Hi,
> >
> > Someone told me that tools from Synplicity is better than the Synopsys
> > Xilinx combination in FPGA place and route process.
>
> Neither Synplify nor Synopsys do place-and-route for Xilinx.
>
> > I am sick with the
> > bad routing design in Alliance3.1i. Also, it takes me more than 1 day
> > to par a design using only 45% slices of a XCV1000E (on a Sun E4500).
>
> Perhaps it's a design issue?
>
> -a

--
--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: 36771
Subject: Re: DLL cycle-to-cycle jitter
From: Ray Andraka <ray@andraka.com>
Date: Mon, 19 Nov 2001 20:34:41 GMT
Links: << >>  << T >>  << A >>
The jitter you are seeing is most likely due to jitter on your input.  Note
that even with a very clean input, you can induce jitter if you have lots of
single ended I/O activity on the same bank as your clock input.  I've seen a
case where I got almost 400ps jitter, which it turned out was largely due to
outputs switching on the same bank as the clock input.  Apparently the delta
currents can shift around the clock input thresholds a little bit.

nurit eliram wrote:

> Hi.
> I have seen that the period jitter of DLL of virtex-II device is 150 ps.
>
> Can I have any figures about it's cycle-to-cycle jitter ?
>
> ThanKX

--
--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: 36772
Subject: Re: Virtex2 gate-level simulation: SDF and timing errors
From: Andy Peters <andy@exponentmedia.deletethis.com>
Date: Mon, 19 Nov 2001 20:38:03 GMT
Links: << >>  << T >>  << A >>
Assaf Sarfati wrote:
> 
> Hi everyone,
> 
> I am trying to simulate the gate-level VHDL file generated by Xilinx
> P&R tools. My test design is a bunch of counters connected to an
> inferred distributed-RAM. The target device is a Virtex-2 chip.
> 
> When I simulate the gate-level VHDL by itself, I get timing violation
> warnings (sometimes) when writing to the distributed-RAM; watching the
> simulator waveforms, it appears that the clock to the RAM has a 100-pS
> phase difference to the counters' clock (the clock is routed as a
> global clock net).

That sounds like one of Xilinx' bad models.  I've looked through the
Xilinx functional models, and there's all sorts of things like:

	foo_i <= foo after 1 ps;

and such.  I've ranted before: there should be NO timing information in
a FUNCTIONAL model.  Check the archives of comp.lang.vhdl for more on
that subject.  Summary: the Xilinx people oughta learn how to write
proper models.
 
> When I add the gate-level SDF file to the simulation, all the timing
> violation warnings disappear (for all cases: min, max and typ).

Right, because the post-route delay information is "real."
 
> Trying to trace the generated VHDL code, I see that signals are routed
> through buffer entities, with built-in delays; apparently the VHDL
> design itself contains all required delays.

Again: why does a functional model have timing info?
 
--a

Article: 36773
Subject: AHDL to VHDL
From: "Jas" <spammeanddie_coach.ent@xtra.co.nz>
Date: Tue, 20 Nov 2001 10:59:37 +1300
Links: << >>  << T >>  << A >>
Does anyone know of software to convert AHDL to VHDL ?

Cheers



Article: 36774
Subject: Re: Modelsim
From: "Arthur Sharp" <arthur@nospam.com>
Date: Tue, 20 Nov 2001 09:01:11 +1100
Links: << >>  << T >>  << A >>

"Andrew Gray" <andrewgray@iafrica.com> wrote in message
news:3bf946c4.0@news1.mweb.co.za...
> Hi
>
> Does anyone know where I can get hold of a full-version licence for
> Modelsim? I only need it for 2 or 3 days.

You should be able to get an evaluation license for Modelsim for 20-30 days
from their site.

>
> Is there any alternative VHDL simulator like modelsim that is freely
> available?

As good as Modelsim, for free, not really.

>
> Thanks
>
> Andrew

A.S.





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