Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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
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
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--------------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> <br> "Martin E." wrote: <blockquote TYPE=CITE><style></style> <font face="Arial"><font size=-1>How about the PWRDWN_B pin? 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&iCountryID=1&getPagePath=12763</a></font></font> <font face="Arial"><font size=-1>States that this pin should be left unconnected for proper operation. Should I, nevertheless, pull it up to VCCO with 10K or so?</font></font> <font face="Arial"><font size=-1>Thanks,</font></font> <font face="Arial"><font size=-1>-Martin</font></font> <blockquote dir=ltr style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">"Austin Lesea" <<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. 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. 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. For example, does it affect "DONE"? How about M0, M1 and M2? And <br>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 <br><a href="news:3D6A8C76.B8A9EA70@xilinx.com">news:3D6A8C76.B8A9EA70@xilinx.com</a>... <br>> page 343 of the Virtex II handbook <br>> <br>> <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. 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_" = "martineu" <br>></blockquote> </blockquote> </blockquote> </body> </html> --------------9DDA22C1F88D1A45BCA50315--Article: 46354
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: 46355A 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
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: 46357Kevin 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. - jgArticle: 46358
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
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.eduArticle: 46360
Hello, can someone help me use the ICAP component for Virtex II?? Thanks SteinArticle: 46362
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: 46363Peter 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
>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: 46365I 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
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
Thanks for your reply. ______________________________ solaris-box# ping god god is aliveArticle: 46369
To whom it may concern, I'm looking for Virtex-IIpro Demo-Boards. Any hints would be highly appreciated. Kind regards from Germany Udo WeikArticle: 46370
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. UtkuArticle: 46371
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--------------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
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: 46374Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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