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 46350

Article: 46350
Subject: Re: need cheap and dirty time delay for spartan2e
From: Ray Andraka <ray@andraka.com>
Date: Tue, 27 Aug 2002 00:11:51 GMT
Links: << >>  << T >>  << A >>
Some FPGA designs are getting almost that hot ;-)

Peter Alfke wrote:

>
> XAPP451 describes the various work-arounds in detail. Remember Fahrenheit 451
> ?  :-)
>
> Peter Alfke, Xilinx Applications

--
--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: 46351
Subject: Re: VirtexII: HSWAP_EN
From: "Martin E." <0_0_0_0_@pacbell.net>
Date: Tue, 27 Aug 2002 00:54:53 GMT
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_0031_01C24D2A.58C36200
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

How about the PWRDWN_B pin?  An article in the Answer Database:
http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=3D1&iCount=
ryID=3D1&getPagePath=3D12763

States that this pin should be left unconnected for proper operation.  =
Should I, nevertheless, pull it up to VCCO with 10K or so?

Thanks,

-Martin


  "Austin Lesea" <austin.lesea@xilinx.com> wrote in message =
news:3D6AC346.386C8A@xilinx.com...
  Martin, 
  The key words here in the paragraph is "affects all user ios".... 

  That excludes dedicated ios. 

  We generally refer to ios as either user, or general ios, and as =
dedicated ios. 

  So, DONE, M0, etc. are all dedicated pins. 

  I would not rely on an internal pullup on the mode pins (or done), as =
noise can easily overwhelm the weak pullup and trigger unusual results.  =
Tie the pins high thru a resistor, or to ground, to make sure there is =
no issue with cross talk noise getting into these pins through traces on =
the pcb. 

  DONE can be configured to actively pull high after configuration in =
complete and successful (start up options). 

  Austin 

  "Martin E." wrote: 

    Austin, 
    Thanks for your note.  I did read the configuration section of the =
manual. 
    I guess where I got stuck was in trying to determine the pins =
HSWAP_EN 
    affects.  For example, does it affect "DONE"?  How about M0, M1 and =
M2?  And 
    the other config pins?  If it did I could eliminate some pullup =
resistors. 

    Thanks again, 

    -Martin 

    "Austin Lesea" <austin.lesea@xilinx.com> wrote in message 
    news:3D6A8C76.B8A9EA70@xilinx.com... 
    > page 343 of the Virtex II handbook 
    > 
    >  http://support.xilinx.com/products/virtex/handbook/ug002_ch3.pdf 
    > (chapter 3 on configuration) 
    > 
    > Austin 
    > 
    > Austin Lesea wrote: 
    > 
    > > Martin, 
    > > 
    > > When tied to Vcco, all IOs are tristate until configured. 
    > > 
    > > When grounded, all IOs have the weak pullups enabled until =
configurated. 
    > > 
    > > Austin 
    > > 
    > > "Martin E." wrote: 
    > > 
    > > > Could someone clarify the usage of this pin? 
    > > > 
    > > > As I understand it, when tied to Vcc user I/O is left without =
pullups 
    during 
    > > > configuration.  By "user I/O" I understand all I/O signals on =
all 
    banks. 
    > > > 
    > > > Thank you, 
    > > > 
    > > > -- 
    > > > Martin E. 
    > > > 
    > > > To send private email: 
    > > > 0_0_0_0_@pacbell.net 
    > > > where 
    > > > "0_0_0_0_"  =3D  "martineu" 
    >




Article: 46352
Subject: Re: FPGA speed level
From: Daryl <e-engineer@eastday.com>
Date: 27 Aug 2002 01:09:44 GMT
Links: << >>  << T >>  << A >>
Hi all,
    	thanks for your kind, Neeraj and Muthu.    	
    	the info is useful for me.

neeraj_varma@yahoo.com (Neeraj) wrote in
news:141db5c.0208252116.33ea3517@posting.google.com: 

> In pre-Virtex families of Xilinx, speed grades used to be exact CLB
> delays, which obviously meant a -3 would be faster than -4 (which also
> meant 4ns CLB delay). Later, due to process migrations, even the
> XC4000 family started having CLB delays as low of 0.9ns, wherein the
> speed grade used to be -09, -08 and so on. (I remember an
> XC4085XLA-08).

I think the Altera device is similar to this, at last pre-APEX device which 
I've ever used. Right?

AND, there is another question then, How to definte "CLB delay"?

thanks in advance.

Daryl

Article: 46353
Subject: Re: VirtexII: HSWAP_EN
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 26 Aug 2002 18:14:13 -0700
Links: << >>  << T >>  << A >>

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

Martin,

If you do not connect anything to it (no via or trace whatsoever) then
it is OK to use the internal pullup.

That is what the answer is recommending.

Otherwise, if you have to connect it to a via on your pcb, then I would
pull it high with a 10K, just like I suggested for the mode pins to
prevent any capacitive cross talk to/from the vias from toggling the pin
inadvertently.

Austin



"Martin E." wrote:

> How about the PWRDWN_B pin?  An article in the Answer
> Database:http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=12763 States
> that this pin should be left unconnected for proper operation.  Should
> I, nevertheless, pull it up to VCCO with 10K or so? Thanks, -Martin
>
>      "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
>      news:3D6AC346.386C8A@xilinx.com...Martin,
>
>      The key words here in the paragraph is "affects all user
>      ios"....
>
>      That excludes dedicated ios.
>
>      We generally refer to ios as either user, or general ios,
>      and as dedicated ios.
>
>      So, DONE, M0, etc. are all dedicated pins.
>
>      I would not rely on an internal pullup on the mode pins (or
>      done), as noise can easily overwhelm the weak pullup and
>      trigger unusual results.  Tie the pins high thru a resistor,
>      or to ground, to make sure there is no issue with cross talk
>      noise getting into these pins through traces on the pcb.
>
>      DONE can be configured to actively pull high after
>      configuration in complete and successful (start up options).
>
>      Austin
>
>      "Martin E." wrote:
>
>     > Austin,
>     >
>     > Thanks for your note.  I did read the configuration
>     > section of the manual.
>     > I guess where I got stuck was in trying to determine the
>     > pins HSWAP_EN
>     > affects.  For example, does it affect "DONE"?  How about
>     > M0, M1 and M2?  And
>     > the other config pins?  If it did I could eliminate some
>     > pullup resistors.
>     >
>     > Thanks again,
>     >
>     > -Martin
>     >
>     > "Austin Lesea" <austin.lesea@xilinx.com> wrote in message
>     > news:3D6A8C76.B8A9EA70@xilinx.com...
>     > > page 343 of the Virtex II handbook
>     > >
>     > >
>     > http://support.xilinx.com/products/virtex/handbook/ug002_ch3.pdf
>     >
>     > > (chapter 3 on configuration)
>     > >
>     > > Austin
>     > >
>     > > Austin Lesea wrote:
>     > >
>     > > > Martin,
>     > > >
>     > > > When tied to Vcco, all IOs are tristate until
>     > configured.
>     > > >
>     > > > When grounded, all IOs have the weak pullups enabled
>     > until configurated.
>     > > >
>     > > > Austin
>     > > >
>     > > > "Martin E." wrote:
>     > > >
>     > > > > Could someone clarify the usage of this pin?
>     > > > >
>     > > > > As I understand it, when tied to Vcc user I/O is
>     > left without pullups
>     > during
>     > > > > configuration.  By "user I/O" I understand all I/O
>     > signals on all
>     > banks.
>     > > > >
>     > > > > Thank you,
>     > > > >
>     > > > > --
>     > > > > Martin E.
>     > > > >
>     > > > > To send private email:
>     > > > > 0_0_0_0_@pacbell.net
>     > > > > where
>     > > > > "0_0_0_0_"  =  "martineu"
>     > >
>

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

Martin,

If you do not connect anything to it (no via or trace whatsoever) then
it is OK to use the internal pullup.

That is what the answer is recommending.

Otherwise, if you have to connect it to a via on your pcb, then I would
pull it high with a 10K, just like I suggested for the mode pins to prevent
any capacitive cross talk to/from the vias from toggling the pin inadvertently.

Austin
<br>&nbsp;
<br>&nbsp;

"Martin E." wrote:
<blockquote TYPE=CITE><style></style>
<font face="Arial"><font size=-1>How
about the PWRDWN_B pin?&nbsp; An article in the Answer Database:</font></font><font face="Arial"><font size=-1><a href="http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=12763">http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&amp;iCountryID=1&amp;getPagePath=12763</a></font></font>&nbsp;<font face="Arial"><font size=-1>States
that this pin should be left unconnected for proper operation.&nbsp; Should
I, nevertheless, pull it up to VCCO with 10K or so?</font></font>&nbsp;<font face="Arial"><font size=-1>Thanks,</font></font>&nbsp;<font face="Arial"><font size=-1>-Martin</font></font>&nbsp;&nbsp;
<blockquote dir=ltr 
style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Austin
Lesea" &lt;<a href="mailto:austin.lesea@xilinx.com">austin.lesea@xilinx.com</a>>
wrote in message <a href="news:3D6AC346.386C8A@xilinx.com">news:3D6AC346.386C8A@xilinx.com</a>...Martin,

The key words here in the paragraph is "affects all user ios"....

That excludes dedicated ios.

We generally refer to ios as either <b>user</b>, or general ios, and
as <b>dedicated</b> ios.

So, DONE, M0, etc. are all dedicated pins.

I would not rely on an internal pullup on the mode pins (or done), as
noise can easily overwhelm the weak pullup and trigger unusual results.&nbsp;
Tie the pins high thru a resistor, or to ground, to make sure there is
no issue with cross talk noise getting into these pins through traces on
the pcb.

DONE can be configured to actively pull high after configuration in
complete and successful (start up options).

Austin

"Martin E." wrote:
<blockquote TYPE="CITE">Austin,

Thanks for your note.&nbsp; I did read the configuration section of
the manual.
<br>I guess where I got stuck was in trying to determine the pins HSWAP_EN
<br>affects.&nbsp; For example, does it affect "DONE"?&nbsp; How about
M0, M1 and M2?&nbsp; And
<br>the other config pins?&nbsp; If it did I could eliminate some pullup
resistors.

Thanks again,

-Martin

"Austin Lesea" &lt;austin.lesea@xilinx.com> wrote in message
<br><a href="news:3D6A8C76.B8A9EA70@xilinx.com">news:3D6A8C76.B8A9EA70@xilinx.com</a>...
<br>> page 343 of the Virtex II handbook
<br>>
<br>>&nbsp; <a href="http://support.xilinx.com/products/virtex/handbook/ug002_ch3.pdf">http://support.xilinx.com/products/virtex/handbook/ug002_ch3.pdf</a>
<br>> (chapter 3 on configuration)
<br>>
<br>> Austin
<br>>
<br>> Austin Lesea wrote:
<br>>
<br>> > Martin,
<br>> >
<br>> > When tied to Vcco, all IOs are tristate until configured.
<br>> >
<br>> > When grounded, all IOs have the weak pullups enabled until configurated.
<br>> >
<br>> > Austin
<br>> >
<br>> > "Martin E." wrote:
<br>> >
<br>> > > Could someone clarify the usage of this pin?
<br>> > >
<br>> > > As I understand it, when tied to Vcc user I/O is left without
pullups
<br>during
<br>> > > configuration.&nbsp; By "user I/O" I understand all I/O signals
on all
<br>banks.
<br>> > >
<br>> > > Thank you,
<br>> > >
<br>> > > --
<br>> > > Martin E.
<br>> > >
<br>> > > To send private email:
<br>> > > 0_0_0_0_@pacbell.net
<br>> > > where
<br>> > > "0_0_0_0_"&nbsp; =&nbsp; "martineu"
<br>></blockquote>
</blockquote>
</blockquote>

</body>
</html>

--------------9DDA22C1F88D1A45BCA50315--


Article: 46354
Subject: Re: Anyone already on QUARTUS II V2.1 ?
From: Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com>
Date: Mon, 26 Aug 2002 21:03:09 -0500
Links: << >>  << T >>  << A >>


Sven Tejcka wrote:
> 
> Hi there.
> Has anyone already V2.1 of ALTERA´s QUARTUS II ?
> 


        I tried to run Quartus II 2.1 Web Edition on a Windows 98 PC,
but it crashes 100% of the time when I start it . . .
Quartus II 2.0 Web Edition works fine on the same PC.
I was told that the problem will be fixed when Quartus II 2.1 SP1 is
released . . .
Altera never gets the software right . . .



> I hope that with 2.1 my design becomes better (timing problems).....
> 
> Has anyone experiences if 2.1 does a better job with ACEX 1k devices ?
> 
> I have problems with slack times.
> I thought that QUARTUS tries to meet the timings but it seems as if
> QUARTUS uses the first successfull fit and does not try again if timings
> are not met.
> Or is this a thing of settings and I can set an option so that QUARTUS
> tries again ?
> 
> Thanks in advance
> Sven


        I personally think it is not a good idea to count on the new
version of the design software to solve your timing related problems.
When the new version of the design software is released, all
Programmable Logic vendors seem to claim certain performance
improvements to lure existing users to upgrade, since it is in their
best interest to get existing users to pay for the upgrade, but how
often do the existing users see any performance improvements?
In my case, I personally saw virtually no performance improvement when I
upgraded from Quartus II 1.1 Web Edition to Quartus II 2.0 Web Edition
in terms to meeting timings, so why will Quartus II 2.1 fare any better?
If you are trying to meet certain timing requirements, there are some
thing you may want to try.
        First of all, even Quartus II 2.0 comes with a floorplanner, so
using that will likely reduce routing delays.
However, the problem of Quartus II floorplanner is that it is much
harder to use than Xilinx floorplanner in my opinion, and the Quartus II
fitter often ignores the floorplanner location assignment by duplicating
the LUT by adding "~1" to the LUT name (i.e., ix_8183~1), and placing
that duplicated LUT somewhere else since you won't really know when you
floorplan your design that the fitter will change the name of the LUT.
As far as I know, Xilinx's backend tool doesn't change LUT names unless
a rarely used mapping option is used. 
        Secondly, if you can find some parts in your RTL code that you
can improve, that might solve your timing problems, although that's not
always easy. (Try the floorplanner first.)
        Thirdly, if you can, you may want to ditch ACEX1K, and switch to
Xilinx Spartan-II if you can because I have had much better luck meeting
timings with Spartan-II than with FLEX10KE. (ACEX1K is a low cost
derivative of FLEX10KE.)
But I know that's not easy if you are already using vendor specific
features like embedded RAM.
As a matter of disclosure, I don't work for neither companies, or their
distributors.
I don't own their stock, either.


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

Article: 46355
Subject: Re: Anyone already on QUARTUS II V2.1 ?
From: "ds" <nospam@cwix.com>
Date: Tue, 27 Aug 2002 02:16:30 GMT
Links: << >>  << T >>  << A >>
A patch is available from Altera for QII 2.1 Web Edition.
- Subroto

"Kevin Brace" <killspam4kevinbraceusenet@killspam4hotmail.com> wrote in
message news:akemdc$1sc$1@newsreader.mailgate.org...
>
>
> Sven Tejcka wrote:
> >
> > Hi there.
> > Has anyone already V2.1 of ALTERA´s QUARTUS II ?
> >
>
>
>         I tried to run Quartus II 2.1 Web Edition on a Windows 98 PC,
> but it crashes 100% of the time when I start it . . .
> Quartus II 2.0 Web Edition works fine on the same PC.
> I was told that the problem will be fixed when Quartus II 2.1 SP1 is
> released . . .
> Altera never gets the software right . . .
>
>
>
> > I hope that with 2.1 my design becomes better (timing problems).....
> >
> > Has anyone experiences if 2.1 does a better job with ACEX 1k devices ?
> >
> > I have problems with slack times.
> > I thought that QUARTUS tries to meet the timings but it seems as if
> > QUARTUS uses the first successfull fit and does not try again if timings
> > are not met.
> > Or is this a thing of settings and I can set an option so that QUARTUS
> > tries again ?
> >
> > Thanks in advance
> > Sven
>
>
>         I personally think it is not a good idea to count on the new
> version of the design software to solve your timing related problems.
> When the new version of the design software is released, all
> Programmable Logic vendors seem to claim certain performance
> improvements to lure existing users to upgrade, since it is in their
> best interest to get existing users to pay for the upgrade, but how
> often do the existing users see any performance improvements?
> In my case, I personally saw virtually no performance improvement when I
> upgraded from Quartus II 1.1 Web Edition to Quartus II 2.0 Web Edition
> in terms to meeting timings, so why will Quartus II 2.1 fare any better?
> If you are trying to meet certain timing requirements, there are some
> thing you may want to try.
>         First of all, even Quartus II 2.0 comes with a floorplanner, so
> using that will likely reduce routing delays.
> However, the problem of Quartus II floorplanner is that it is much
> harder to use than Xilinx floorplanner in my opinion, and the Quartus II
> fitter often ignores the floorplanner location assignment by duplicating
> the LUT by adding "~1" to the LUT name (i.e., ix_8183~1), and placing
> that duplicated LUT somewhere else since you won't really know when you
> floorplan your design that the fitter will change the name of the LUT.
> As far as I know, Xilinx's backend tool doesn't change LUT names unless
> a rarely used mapping option is used.
>         Secondly, if you can find some parts in your RTL code that you
> can improve, that might solve your timing problems, although that's not
> always easy. (Try the floorplanner first.)
>         Thirdly, if you can, you may want to ditch ACEX1K, and switch to
> Xilinx Spartan-II if you can because I have had much better luck meeting
> timings with Spartan-II than with FLEX10KE. (ACEX1K is a low cost
> derivative of FLEX10KE.)
> But I know that's not easy if you are already using vendor specific
> features like embedded RAM.
> As a matter of disclosure, I don't work for neither companies, or their
> distributors.
> I don't own their stock, either.
>
>
> Kevin Brace (In general, don't respond to me directly, and respond
> within the newsgroup.)



Article: 46356
Subject: Re: Floorplanning 101
From: Kevin Brace <killspam4kevinbraceusenet@killspam4hotmail.com>
Date: Mon, 26 Aug 2002 21:16:35 -0500
Links: << >>  << T >>  << A >>
        I believe I asked a similar question like the one you asked
about 9 months ago, and the answer I got was something like Xilinx
doesn't really provide a tutorial on floorplanning.
The way I got started was I just placed relevant LUTs and FFs close to
each other (It is desirable to keep relevant LUTs and FFs within a CLB,
if possible.), and I got about 20% reduction in overall delay which
means that I cut routing delay by more than 20%.
Since you sound like a floorplanning newbie, you may want to try with
UCF flow, since it is easier to deal with than the regular flow for a
newbie.



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



Big Swede wrote:
> 
>   I'd like to know more about if I should place things
> horizontally/vertically, etc. Maybe it's basically about learning the
> structure of the chip you're working on, i.e. read the *** manual so to
> speak :)? Are there any floorplanning tutorials out there? If possible with
> some example(s) for a real tool, not just the general theory. I tried to
> find a faq or so for this group, as I think these questions aren't that new,
> but I didn't find anything. So I ask them here, hope this is ok and thank
> you for reading this.
> /Regards, Big Swede

Article: 46357
Subject: Re: Anyone already on QUARTUS II V2.1 ?
From: Jim Granville <jim.granville@designtools.co.nz>
Date: Tue, 27 Aug 2002 14:50:42 +1200
Links: << >>  << T >>  << A >>
Kevin Brace wrote:
> 
<snip> 
>   I personally think it is not a good idea to count on the new
> version of the design software to solve your timing related problems.
> When the new version of the design software is released, all
> Programmable Logic vendors seem to claim certain performance
> improvements 

 The key here is the usage of universal escape clause of 'up to XX%'

> to lure existing users to upgrade, since it is in their
> best interest to get existing users to pay for the upgrade, but how
> often do the existing users see any performance improvements?

 Very true - I recall a year or so ago, feeling that the latest Vendor?? 
claims were 'a bit much', and actually asked for the benchmark files.

 The discussion was along the lines of 
Them : 'These are customer designs under NDA'
Us   : 'Oh, OK, how about in-house test files then ?'
Them : 'We don't have any of those '

so, we never did see a single real example that backed their claims.

 For an up-to-date example, this in an email :

" ISE helps you finish faster by: Delivering 15% performance
improvements"

Wow, sounds great... but click the link and their WEB says

"ISE is still the performance leader with up to 30% better
performance and 1.5 - 6X faster compile times than the
nearest competitor" 

and we are left guessing just what exactly the "up to 30%" 
applies to, and even what "better performance" relates to ?

 I'm sorry, but that sounds more like a washing powder advert, 
than anything that should be applied to engineering SW.

- jg

Article: 46358
Subject: Re: FPGA speed level
From: Peter Alfke <palfke@earthlink.net>
Date: Tue, 27 Aug 2002 03:10:30 GMT
Links: << >>  << T >>  << A >>


Daryl wrote:

> AND, there is another question then, How to definte "CLB delay"?
>
> thanks in advance.

Well, we have agreed already that it does not make any sense to name parts
after one single parameteer, especially when it changes from 6 ns to 0.4 ns
and less...

When we talked about CLB delay, we usually meant LUT delay, which Xililinx
calls Tilo.
Our data sheets have always been very specific in calling out various delays.
Some people think too specific, since the speeds files used by the software
are of necessity even more specific, and they are the ultimate arbiter. How
many thousand numbers should be published in the data sheet, when they are
never specific enough, and the ultimate detail is available through the
software...
Just my opinion.
Peter Alfke

Peter Alfke, Xilinx Applications

>
>


Article: 46359
Subject: Re: FPGA speed level
From: nweaver@ribbit.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: Tue, 27 Aug 2002 03:30:27 +0000 (UTC)
Links: << >>  << T >>  << A >>
In article <3D6AED8E.48344E8C@earthlink.net>,
Peter Alfke  <palfke@earthlink.net> wrote:

>Some people think too specific, since the speeds files used by the software
>are of necessity even more specific, and they are the ultimate arbiter. How
>many thousand numbers should be published in the data sheet, when they are
>never specific enough, and the ultimate detail is available through the
>software...

Then again, there are those like me whol would LIKE to have all the
details (especially on the interconnect), because the software already
knows them.  :)

The big thing IMO, missing in the data sheet, is some rule of
thumb/close approximations for the manhattan delay along various
routing/interconnect path types (local, hex, longline, tristate).

I think a timing frontier graph/image would be highly useful for those
luddites (like me) who like to think in placement.  It doesn't have to
be exact, but a near approximation would be useful.

Either that, or are the timing files documented so I could write a
program to create these?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Article: 46360
(removed)


Article: 46361
Subject: Xilinx Virtex-II : ICAP?
From: stein.kjolstad@visitech.no (=?ISO-8859-1?Q?Stein_Kj=F8lstad?=)
Date: 26 Aug 2002 22:45:06 -0700
Links: << >>  << T >>  << A >>
Hello,

can someone help me use the ICAP component for Virtex II??

Thanks
Stein

Article: 46362
Subject: Re: Anyone already on QUARTUS II V2.1 ?
From: Kevin Brace <kevinbraceusenet.killspam@killspam.hotmail.com>
Date: Tue, 27 Aug 2002 01:20:40 -0500
Links: << >>  << T >>  << A >>


ds wrote:
> 
> A patch is available from Altera for QII 2.1 Web Edition.
> - Subroto
> 


        I checked Altera website, but all I found was the Service Pack
for QII 1.1 and 2.0.
The QII 2.1 Service Pack doesn't seem to be available yet.



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

Article: 46363
Subject: Spartan-II inrush and other power suppy isues (was Re: need cheap and dirty time delay for spartan2e)
From: Eric Smith <eric-no-spam-for-me@brouhaha.com>
Date: 26 Aug 2002 23:51:19 -0700
Links: << >>  << T >>  << A >>
Peter Alfke <peter@xilinx.com> writes:
> Virtex and Spartan-II devices (prior to Virtex-II, where this problem
> is thoroughly licked) have an inrush current spike that starts the
> moment you apply Vcc. There is no way to delay this current by holding
> off configuration, since the configuration process itself has nothing
> to do with this. The excessive temporary current is there prior to the
> clearing of all configuration memory cells which always starts as soon
> as Vcc is above a certain threshold value.
> 
> XAPP451 describes the various work-arounds in detail.

Why is there not a big difference in the inrush spec between the smallest
and largest parts?  For instance, the Spartan-II data sheet gives a
maximum of 400 mA (0C<Tj<100C) for the entire line.  Wouldn't an XC2S15
have less inrush than an XC2S200?  If not, why?

XAPP451 describes designs for use with linear regulators.  Are there any
special issues I should be concerned about when using switching regulators
to derive 2.5V Vccint and 3.3V Vcco from a 5V supply?

I have an XC2S150 and separate a microcontroller on my board.  The
microcontroller and the XC2S150 both need +2.5V core voltage and +3.3V
Vcco.  Is it reasonable to have the microcontroller turn on the Vccint
to the XC2S150 after a fixed delay (using a pFET), rather than based on
a voltage threshold?

XAPP450 says that Vccint and Vcco should be applied simultaneously to the
Spartan-IIE devices, but does not mention the Spartan-II.  Will bad things
happen with the Spartan II if Vcco is available earlier than Vccint?

Thanks for any insights!
Eric

[If you want to reply by private email, please rmeove the obvious
spam-proofing from my email address.]

Article: 46364
Subject: Re: FPGA speed level
From: hmurray@suespammers.org (Hal Murray)
Date: Tue, 27 Aug 2002 07:02:42 -0000
Links: << >>  << T >>  << A >>
>I think a timing frontier graph/image would be highly useful for those
>luddites (like me) who like to think in placement.  It doesn't have to
>be exact, but a near approximation would be useful.

Good suggestion.  Thanks.


When I'm trying to understand the timings for a new/unfamiliar part,
I sometimes wish I had a list of timings for interesting basic chunks.
Things like:
  8, 16, 32 bit counters
      qualified vs free running ??
      loadable, resettable...
  register to register transfers
      direct and via tri-state bus
  adders
  RAM cycle times
    How heavily pipelined?
  Multipliers (again, how pipelined)
  ...


I wonder if it would make sense to have something like a reasonably
simple CPU and publish timings when implemented on various chips.
Perhaps with notes about how fast various paths/instructions are.

It would probably take several levels.  One would be "pure", "clean"
HDL.  Another would be the same idea hacked to take advantages of
hardware/archeticute of the target chip and/or to dance around software
quirks.  Maybe a chain of faster designs with more device specific
code and/or floorplanning.

Maybe a barrel shifter would provide most of the timing info
you were looking for.

-- 
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: 46365
Subject: Altera Quartus II problems
From: edaudio2000@yahoo.co.uk (ted)
Date: 27 Aug 2002 01:28:59 -0700
Links: << >>  << T >>  << A >>
I have recently installed Quartus II, but I cannot get it to finish a
compilation. I get the same message "Full compilation was not
succesful", no matter what I try.

THe compilation Report has as its last line "? Results for test
compiler settings". If I double click on it (or anywhere) produces no
further information.  I would have expected some error message, or
pointer to as the cause of the error to appear, but nothing!
#I get exactly the same error whether I try to compile the supplied
examples
or when trying to compile a simple file consisting ofan and gate. 

I've trying going through all the setting menus, to no avail...

help....What am I doing wrong????

I am migrating from MAX-II, which I have used succesfully, so I don't
thing I am doing something blindingly stupid, or missing some obvious
step!!

Any ideas anybody??

Thanks all!!

Article: 46366
Subject: Re: Altera Quartus II problems
From: Horst Trattnig <9714trho@edu.fh-kaernten.ac.at>
Date: Tue, 27 Aug 2002 11:50:48 +0200
Links: << >>  << T >>  << A >>
Hi Ted,

Well, I use Quartus II since about 8 month and it works fine. If you use
Quartus II, do'nt use it to compile your VHDL or Verilog File. Use 
Alteras Leonardo OEM , it's free to get at www.altera.com

Your Problem could be based on the Pin Assignment. If you have not done, 
Quartus could not finish your compilation.

If this does'nt works send me a test design and I'll compile it and send 
you the result.

regards,
Horst

ted wrote:

> I have recently installed Quartus II, but I cannot get it to finish a
> compilation. I get the same message "Full compilation was not
> succesful", no matter what I try.
> 
> THe compilation Report has as its last line "? Results for test
> compiler settings". If I double click on it (or anywhere) produces no
> further information.  I would have expected some error message, or
> pointer to as the cause of the error to appear, but nothing!
> #I get exactly the same error whether I try to compile the supplied
> examples
> or when trying to compile a simple file consisting ofan and gate. 
> 
> I've trying going through all the setting menus, to no avail...
> 
> help....What am I doing wrong????
> 
> I am migrating from MAX-II, which I have used succesfully, so I don't
> thing I am doing something blindingly stupid, or missing some obvious
> step!!
> 
> Any ideas anybody??
> 
> Thanks all!!
> 


Article: 46367
(removed)


Article: 46368
Subject: Re: Can I directly connect XTAL to SpartanXL ?
From: BasePointer <mfide@softhome.net>
Date: Tue, 27 Aug 2002 03:22:35 -0700
Links: << >>  << T >>  << A >>
Thanks for your reply.

______________________________
solaris-box# ping god
god is alive

Article: 46369
Subject: Virtex-IIpro Demo-Boards
From: Udo Weik <weik@imtek.de>
Date: Tue, 27 Aug 2002 13:05:34 +0200
Links: << >>  << T >>  << A >>
To whom it may concern,

I'm looking for Virtex-IIpro Demo-Boards.
Any hints would be highly appreciated.


Kind regards from Germany
Udo Weik


Article: 46370
Subject: Re: Export from ModelSim to Excel?
From: Utku Ozcan <utku.ozcan@netas.com.tr>
Date: Tue, 27 Aug 2002 14:20:06 +0300
Links: << >>  << T >>  << A >>
Davis Moore wrote:
> 
> You may want to consider putting together an Excel macro
> that will read the file and populate cells and plot charts.
> It may or may not be worth the time, depending on how
> much time you are going to spend debugging your filter
> in this manner. It can save a lot of tedious and repetitive
> cut/paste/import/plot operations.

  All visulation softwares have text file processing capability,
  like MATLAB (http://www.mathworks.com, works on PC and UNIX),
  Gnuplot (http://www.gnuplot.info, free, works on all UNIX variants,
  like HP, Sun, Cygwin http://www.cygwin.com and Linux) and
  Excel of Microsoft. The point is, as Davis pointed very clearly,
  if it is worth wasting time to design text processing interfaces.
  Trade-off between interface design and verification frequency.

  Utku

Article: 46371
Subject: Re: FPGA speed level
From: Ray Andraka <ray@andraka.com>
Date: Tue, 27 Aug 2002 13:02:15 GMT
Links: << >>  << T >>  << A >>
Hmm, this sounds an awful lot like the MCNC suite.  There are several problems
with benchmarks done this way:

1)  Subtle changes in the RTL coding can make a big difference in how well a
design maps to a particular family.  Case in point: an adder tree with a clock
enable.  If done in altera 10K, this forces each level of the tree to be done in
two levels of logic, where it would be one level of logic in Xilinx because of
the structure of the LE/CLB.  Butyou can get essentially the same function by
just clock enabling the input to the tree and then letting the data flow through
on every clock, and then recapturing it with clock enable properly timed at the
output and now your tree is half the size.  Very subtle change in the RTL, very
big change in the result.

2) performance of a given part is usually very dependent on place and route.  You
may very well be comparing the results of a poor placement in the superior part
for a design to an fortuitous placement in the inferior part (seen that more than
once in papers using MCNC benchmarks).

3) performance and density is affected by use of architecture specific features.
Use of the features usually means some changes in the high levels of the design
to favor use of those features.  Even though you do an RTL level design that can
be ported to other architectures, you should be doing some design tailoring to
make the best use of the architecture available to you.  For example, an FIR
filter done with Xilinx is faster if it is designed so that part of the delay is
absorbed in the adders so that you can connect the adders in a linear chain
rather than a tree.  If the filter has to work on clock enabled samples, you can
do that with the linear adder chain by clock enabling the entire filter.   For an
Altera 10K, you are better off using a tree structure for the adders in this case
because of the issues cited in 1.

4)  What is a representative design?  You suggest a barrel shift, but that
doesn't do anything with the carry chains, for example (FWIW, a design without
carry chains makes the VirtexII look a lot faster.  Put carry chains in it, it
becomes slower than a VirtexE).

Unfortunately, there are no easy answers.  Perhaps the better question is: will
this part meet the requirements for my application.  If so, I need to consider
all the other things like familiarity with the tools and architecture, aquisition
of tools and talent to do the project,  comfort with the vendor/disti etc.

I think the only way to really compare the devices head to head is to give a
detailed specification for a design to experts on each part and have them come up
with the optimium design (based on what parameters?) for that part.  That, of
course only compares that application, and may compare the skill of the designers
more than the capability of the part..




Hal Murray wrote:

> >I think a timing frontier graph/image would be highly useful for those
> >luddites (like me) who like to think in placement.  It doesn't have to
> >be exact, but a near approximation would be useful.
>
> Good suggestion.  Thanks.
>
> When I'm trying to understand the timings for a new/unfamiliar part,
> I sometimes wish I had a list of timings for interesting basic chunks.
> Things like:
>   8, 16, 32 bit counters
>       qualified vs free running ??
>       loadable, resettable...
>   register to register transfers
>       direct and via tri-state bus
>   adders
>   RAM cycle times
>     How heavily pipelined?
>   Multipliers (again, how pipelined)
>   ...
>
> I wonder if it would make sense to have something like a reasonably
> simple CPU and publish timings when implemented on various chips.
> Perhaps with notes about how fast various paths/instructions are.
>
> It would probably take several levels.  One would be "pure", "clean"
> HDL.  Another would be the same idea hacked to take advantages of
> hardware/archeticute of the target chip and/or to dance around software
> quirks.  Maybe a chain of faster designs with more device specific
> code and/or floorplanning.
>
> Maybe a barrel shifter would provide most of the timing info
> you were looking for.
>
> --
> 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.

--
--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: 46372
Subject: Re: Spartan-II inrush and other power suppy isues (was Re: need cheap
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Tue, 27 Aug 2002 08:02:10 -0700
Links: << >>  << T >>  << A >>

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

Eric,

See below,

Austin

Eric Smith wrote:

> Peter Alfke <peter@xilinx.com> writes:
> > Virtex and Spartan-II devices (prior to Virtex-II, where this problem
> > is thoroughly licked) have an inrush current spike that starts the
> > moment you apply Vcc. There is no way to delay this current by holding
> > off configuration, since the configuration process itself has nothing
> > to do with this. The excessive temporary current is there prior to the
> > clearing of all configuration memory cells which always starts as soon
> > as Vcc is above a certain threshold value.
> >
> > XAPP451 describes the various work-arounds in detail.
>
> Why is there not a big difference in the inrush spec between the smallest
> and largest parts?

Because we did not measure a big difference.

>  For instance, the Spartan-II data sheet gives a
> maximum of 400 mA (0C<Tj<100C) for the entire line.  Wouldn't an XC2S15
> have less inrush than an XC2S200?  If not, why?

The current is based on a number of transistors in the CLBs being in
contention.  In a small device there are fewer of them, but in a large device,
the part is resolving the contention in a wave-like fashion across the die as
power is applied.  The two effects (resolution, and contention) somewhat
balance out in larger devices.  So the current does not vary as much as
expected.

>
>
> XAPP451 describes designs for use with linear regulators.  Are there any
> special issues I should be concerned about when using switching regulators
> to derive 2.5V Vccint and 3.3V Vcco from a 5V supply?

No.  Just be sure that the switcher can deliver the minimum specified current
while the part is powering up, and does not shut off, trip or foldback until
at least 20 ms has elapsed (all switchers have some sort of safety mode, to
protect them from damage, and to prevent destruction of the power supply).

>
>
> I have an XC2S150 and separate a microcontroller on my board.  The
> microcontroller and the XC2S150 both need +2.5V core voltage and +3.3V
> Vcco.  Is it reasonable to have the microcontroller turn on the Vccint
> to the XC2S150 after a fixed delay (using a pFET), rather than based on
> a voltage threshold?

Sure.

>
>
> XAPP450 says that Vccint and Vcco should be applied simultaneously to the
> Spartan-IIE devices, but does not mention the Spartan-II.  Will bad things
> happen with the Spartan II if Vcco is available earlier than Vccint?

Nope.  Spartan II does not care if Vcco is applied before, or after (or with)
Vccint.





Article: 46373
Subject: Re: VirtexII: HSWAP_EN
From: "Martin E." <0_0_0_0_@pacbell.net>
Date: Tue, 27 Aug 2002 15:30:45 GMT
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.

------=_NextPart_000_004F_01C24DA4.B42D7B10
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Got it.  Thank you.

-Martin


  "Austin Lesea" <austin.lesea@xilinx.com> wrote in message =
news:3D6AD265.D40301CC@xilinx.com...
  Martin, 
  If you do not connect anything to it (no via or trace whatsoever) then =
it is OK to use the internal pullup. 

  That is what the answer is recommending. 

  Otherwise, if you have to connect it to a via on your pcb, then I =
would pull it high with a 10K, just like I suggested for the mode pins =
to prevent any capacitive cross talk to/from the vias from toggling the =
pin inadvertently. 

  Austin 
    
    

  "Martin E." wrote: 

    How about the PWRDWN_B pin?  An article in the Answer =
Database:http://support.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=3D=
1&iCountryID=3D1&getPagePath=3D12763 States that this pin should be left =
unconnected for proper operation.  Should I, nevertheless, pull it up to =
VCCO with 10K or so? Thanks, -Martin   
      "Austin Lesea" <austin.lesea@xilinx.com> wrote in message =
news:3D6AC346.386C8A@xilinx.com...Martin, 
      The key words here in the paragraph is "affects all user ios".... 

      That excludes dedicated ios. 

      We generally refer to ios as either user, or general ios, and as =
dedicated ios. 

      So, DONE, M0, etc. are all dedicated pins. 

      I would not rely on an internal pullup on the mode pins (or done), =
as noise can easily overwhelm the weak pullup and trigger unusual =
results.  Tie the pins high thru a resistor, or to ground, to make sure =
there is no issue with cross talk noise getting into these pins through =
traces on the pcb. 

      DONE can be configured to actively pull high after configuration =
in complete and successful (start up options). 

      Austin 

      "Martin E." wrote: 

        Austin, 
        Thanks for your note.  I did read the configuration section of =
the manual. 
        I guess where I got stuck was in trying to determine the pins =
HSWAP_EN 
        affects.  For example, does it affect "DONE"?  How about M0, M1 =
and M2?  And 
        the other config pins?  If it did I could eliminate some pullup =
resistors. 

        Thanks again, 

        -Martin 

        "Austin Lesea" <austin.lesea@xilinx.com> wrote in message 
        news:3D6A8C76.B8A9EA70@xilinx.com... 
        > page 343 of the Virtex II handbook 
        > 
        >  =
http://support.xilinx.com/products/virtex/handbook/ug002_ch3.pdf 
        > (chapter 3 on configuration) 
        > 
        > Austin 
        > 
        > Austin Lesea wrote: 
        > 
        > > Martin, 
        > > 
        > > When tied to Vcco, all IOs are tristate until configured. 
        > > 
        > > When grounded, all IOs have the weak pullups enabled until =
configurated. 
        > > 
        > > Austin 
        > > 
        > > "Martin E." wrote: 
        > > 
        > > > Could someone clarify the usage of this pin? 
        > > > 
        > > > As I understand it, when tied to Vcc user I/O is left =
without pullups 
        during 
        > > > configuration.  By "user I/O" I understand all I/O signals =
on all 
        banks. 
        > > > 
        > > > Thank you, 
        > > > 
        > > > -- 
        > > > Martin E. 
        > > > 
        > > > To send private email: 
        > > > 0_0_0_0_@pacbell.net 
        > > > where 
        > > > "0_0_0_0_"  =3D  "martineu" 
        >





Article: 46374
(removed)




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