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 78775

Article: 78775
Subject: Re: WARNING:Xst:382 - Why so many?
From: David Dye <david.dye@xilinx.com>
Date: Mon, 07 Feb 2005 14:57:13 -0700
Links: << >>  << T >>  << A >>
Gabor wrote:
> David Dye wrote:
> 
> 
>>Gabor,
>>
>>Hiding specific messages is a feature that exists in XST 6.Xi and will
>>be enhanced in 7.1i.  This feature was added to reduce runtime as well
>>as log file size and clutter.
>>
>>In the 6.Xi tools, use the XIL_XST_HIDEMESSAGES environment variable to
>>filter all messages that fall into two categories.  The set of messages
>>filtered are fixed, but #382 is one of the low level messages.  Consult
>>chapter 9 of the XST User Guide for the lists of messages and details
>>about how to enable this feature.  The message filtering was implemented
>>in this way to be a stepping stone for the functionality planned for 7.1i.
> 
> 
> Thanks for the tip, this really reduces my build time!

Good to hear.  Glad to help.

> 
>>In ISE 7.1i (due out in a few weeks), there is a message manager that
>>will allow the user to filter out not only specific messages by number,
>>but also specific instances of specific messages.  This feature will
>>extend filtering beyond just XST; most of the implementation tools will
>>take advantage of this feature.
>>
> 
> 
> So does this mean I'll be able to "mark" warnings in a report file
> viewer somehow so it doesn't appear on the next build?  i.e. can
> I effectively see only new messages on each successive build?

What you'll see on subsequent runs depends on how you mark the existing 
messages.  For example, if you say "Filter all instances of this 
message", then it will hide all messages with a particular number, even 
new ones.  You can also say "Filter this instance only", and any new 
ones will show up.  Of course if you have over 8000 instances, you won't 
want to set the individual filter for each one.  We will have wildcard 
capabilites later this year.

When 7.1i comes out check out the help pages on the message filter to 
learn about all the new capabilities.

> 
> 
>>As for the messages in the first place, have you tried inferring these
>>registers?  XST will pack output and output enable flops in the IOBs,
>>and will replicate the output enable flops if necessary.
> 
> 
> I didn't try inferring the registers, because I took this part of the
> design from a Xilinx reference design (XAPP 608) so I had this problem
> from the beginning.  Also in this case the warnings were not hard to
> ignore because they were together in one long section of the report
> file.
> Really just the build time was the headache.
> 
> 
>>thanks,
>>David Dye
>>Xilinx Technical Marketing

thanks,
David Dye
Xilinx Technical Marketing


Article: 78776
Subject: MAP problem
From: "John Maher" <john.maher@nuigalway.ie>
Date: Mon, 7 Feb 2005 15:11:09 -0800
Links: << >>  << T >>  << A >>
Hi I am using JBITS to generate an anticore for a virtex device. When I run the MAP process I get the error, below. Could anyone give me some insight as to what exactly it means, or even better how I might fix it?

Thanks -J

"FATAL_ERROR:Ncd:basnccomp.c:3516:1.29 - Cannot find other bel for unconnected pin on bel <0>.WSGEN:CK of comp coreoutbus<0>. Its current programmed state is : YUSED:0 XUSED:0 F:#RAM:D=0x0000 G:#RAM:D=0x0000 RAMCONFIG:2SHIFTS SRMUX:1 GYMUX:G FXMUX:F Process will terminate. To resolve this error, please consult the Answers Database and other online resources at <http://support.xilinx.com>"

Article: 78777
Subject: Re: usb 2.0 micromodule
From: Kolja Sulimma <news@sulimma.de>
Date: Tue, 08 Feb 2005 00:25:12 +0100
Links: << >>  << T >>  << A >>
tesla wrote:
> Hi,
> 
> I will  send 16 bit/pixel video data from PC to a FPGA board
> through USB 2.0 interface. 

> I think Trenz electronic's Micromodule is suitable for this. It has a
> USB physical interface ic GT3200.
> 
> Has anybody used it for this kind of job? 

AFAIK the micromodule has only been used with Rudolf Usselmanns USB1.1 
core so far. But there is no reason why the 2.0 core should not work on 
the board. We have not tried it yet because the interface to the 2.0 
core is more complicated.

Kolja Sulimma

Article: 78778
Subject: Re: See Peter's High-Wire Act next Tuesday
From: austin <austin@xilinx.com>
Date: Mon, 07 Feb 2005 18:28:47 -0800
Links: << >>  << T >>  << A >>
Glen,

" > I do wonder if the optimal LUT size has changed over the years.
> 
> Is there work showing the optimal LUT size as a function of silicon 
> resources needed to implement such LUTs?"

Good point.  Paul has referred to their studies of replacing a 4 LUT 
with a 6 LUT, and then re-running synthesis to see just how much 
improvement one sees.

Assuming one can get enough >4 term, <=6 term logic synthesised, one 
saves logic levels, and improves speed (even if a 6 LUT is slower than a 
4 LUT).

Then comes the other nagging questions:
- are inputs shared?
- how badly does that mess up the results?
- is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra 
logic to almost give you a 6 LUT?  How badly does that work?
- given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
how badly does that increase the delay?

I would claim a properly engineered 6 LUT would improve the overall 
performance.  A compromise would provide some improvement.  A poor 
implementation woukd make no difference.

Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?

Can you use them as SRL?  LUT RAM?

The synthesis tools all have to be retuned, and debugged to take 
advantage, so this is not without risk.

As for area, a 6 LUT is not all that big as technology shrinks, so some 
combinations of variable LUT size, alternate architectures, is in my 
opinion, inevitable.

As for speed, the smaller the technology, the less improvement in speed 
(ITRS roadmap, and anyone who says differently can be confidently 
ignored).  For speed, one now has to use triple oxide to get both speed 
and static power reduction (eg compare us to S2 at 25C and there is no 
difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
static power!).

The wonderful thing about standard CMOS, is just that.  No one has a 
remarkably different or unique process.  But one can use standard CMOS 
with all of the available tricks, and see a 1/2 to 1/3 reduction in 
static power, an improvement in speed, and an improvement in SEU 
resilience.  Like V4.

Also, there is room for improvement with the P&R tools, so software is 
always looking for that QOR improvement that gives us another speed 
grade advantage without any process change.  So far they do that every 
generation (they get credit for part of the improvement in speed with 
each generation, too, including the most recent ones).

Austin

Article: 78779
Subject: Max. Operating Frequency - Timing report
From: tovijayakumar@yahoo.com
Date: 7 Feb 2005 18:32:50 -0800
Links: << >>  << T >>  << A >>
The Xilinx timing report for XPLA3 CPLD shows maximum operating
frequency of 30 MHz for one of our design. But the CPLD is functioning
correctly at 80 MHz. If so what does the Maximum operating frequency
specified in the timing report signify?


Article: 78780
Subject: FPGA Prototyping
From: "=?iso-8859-1?B?6U1L4A==?=" <johanmk@gmail.com>
Date: 7 Feb 2005 18:42:17 -0800
Links: << >>  << T >>  << A >>
Hi,

I am quite new in FPGA, and want to ask something. I hope some of you
can give me a hint of how to do.

I have finished developed an application using the Celoxica RC100
Development Board, and Handel-C.
Currently I am looking for a way on how to do the prototyping on other
boards.

I made all the application using the PAL (Platform Abstraction Layer),
and I also use the Flash memory of the RC100 board.
I am afraid that the Virtex II Prototype Platform
AFX-FF1152-200/XC2V4000 Board that I am going to use, doesn't have
any flash memory with it.

I used flash memory to store the configuration bits, because I divided
the application into several parts. And do FPGA Configuration
in the later part.

So, is there any expert out there who can suggest me on how to do it?


Thanks,
Johan.


Article: 78781
Subject: SATA and RocketIO
From: "sg" <sgodey@gmail.com>
Date: 7 Feb 2005 18:58:10 -0800
Links: << >>  << T >>  << A >>
Has anyone had any sucess in using RocketIO from Virtez 2 or Virtex 4
for Serial ATA applications? From the information collected on various
news groups and web sites, my understanding is SATA OOB cannot be done
using RocketIO in Virtex 2s. Did any one try Virtex 4s?

What is the comment from FPGA gurus out there?

- sg


Article: 78782
Subject: Re: See Peter's High-Wire Act next Tuesday
From: Jim Granville <no.spam@designtools.co.nz>
Date: Tue, 08 Feb 2005 17:12:57 +1300
Links: << >>  << T >>  << A >>
austin wrote:
> Glen,
> 
> " > I do wonder if the optimal LUT size has changed over the years.
> 
>>
>> Is there work showing the optimal LUT size as a function of silicon 
>> resources needed to implement such LUTs?"
> 
> 
> Good point.  Paul has referred to their studies of replacing a 4 LUT 
> with a 6 LUT, and then re-running synthesis to see just how much 
> improvement one sees.
> 
> Assuming one can get enough >4 term, <=6 term logic synthesised, one 
> saves logic levels, and improves speed (even if a 6 LUT is slower than a 
> 4 LUT).
> 
> Then comes the other nagging questions:
> - are inputs shared?
> - how badly does that mess up the results?
> - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra 
> logic to almost give you a 6 LUT?  How badly does that work?
> - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
> how badly does that increase the delay?
> 
> I would claim a properly engineered 6 LUT would improve the overall 
> performance.  A compromise would provide some improvement.  A poor 
> implementation woukd make no difference.
> 
> Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?
> 
> Can you use them as SRL?  LUT RAM?
> 
> The synthesis tools all have to be retuned, and debugged to take 
> advantage, so this is not without risk.
> 
> As for area, a 6 LUT is not all that big as technology shrinks, so some 
> combinations of variable LUT size, alternate architectures, is in my 
> opinion, inevitable.
> 
> As for speed, the smaller the technology, the less improvement in speed 
> (ITRS roadmap, and anyone who says differently can be confidently 
> ignored).  For speed, one now has to use triple oxide to get both speed 
> and static power reduction (eg compare us to S2 at 25C and there is no 
> difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
> static power!).
> 
> The wonderful thing about standard CMOS, is just that.  No one has a 
> remarkably different or unique process.  But one can use standard CMOS 
> with all of the available tricks, and see a 1/2 to 1/3 reduction in 
> static power, an improvement in speed, and an improvement in SEU 
> resilience.  Like V4.

and Intel also varies the Vth over 21 steps, to have CLK, Vdd, Vth
to tune for speed/power trade offs.

http://www.eet.com/semi/news/showArticle.jhtml;jsessionid=TWZH2G3BR2K2OQSNDBCSKHSCJUMEKJVN?articleId=59301578

> 
> Also, there is room for improvement with the P&R tools, so software is 
> always looking for that QOR improvement that gives us another speed 
> grade advantage without any process change.  So far they do that every 
> generation (they get credit for part of the improvement in speed with 
> each generation, too, including the most recent ones).

  A significant difference at the LUT spec level that I DID see ( and I 
presume still applies ? ) is that Altera have differing LUT path delays
( all LUT legs are not created equal ), whilst Xilinx treated them
all equal.
  That means the Altera SW/HW can presumably choose the faster legs, 
where that matters, and so shave 100's of ps off the critical path ?
  => Faster P&R on otherwise similar silicon ?

-jg


Article: 78783
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Mon, 7 Feb 2005 23:39:32 -0500
Links: << >>  << T >>  << A >>
Hi Glen,

> I do wonder if the optimal LUT size has changed over the years.
> Is there work showing the optimal LUT size as a function of silicon 
> resources needed to implement such LUTs?

Elias Ahmed & Jonathan Rose from the Unversity of Toronto published "The 
Effect of LUT and Cluster Size on Deep-Submicron FPGA Performance and 
Density".  See http://www.eecg.toronto.edu/~jayar/pubs/ahmed/fpga00.pdf. 
Elias's M.A.Sc. thesis was on clustering and optimal lut sizes.  This paper 
contains many references to previous work in the area and is probably a good 
starting point.  The paper's conclusion is that a LUT size between 4 and 6 
is and cluster sizes of between 3 and 10 LEs are best from a balanced 
area-delay perspective.  If you want higher speed, larger LUTs are better. 
One suggested area of future research is finding a way to reduce logic 
levels without the area cost of large LUTs -- and this is what we have done 
in Stratix II with the ALM.  Figure 12 is particularly interesting.

I think Guy Lemieux had some work in this area from his PhD -- not sure if 
its published anywhere yet.

At the FPGA 2005 conference in two weeks, the Stratix II logic architecture 
and some experimental results will be presented in a paper by David Lewis et 
al.

Regards,

Paul Leventis
Altera Corp.



Article: 78784
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Tue, 8 Feb 2005 00:15:27 -0500
Links: << >>  << T >>  << A >>
Hi Austin,

No offence, but I don't think you're going to get far with an attack on the 
logic architecture.  I think you should read the paper at FPGA 2005 when you 
get a chance.  It is very informative.

> Then comes the other nagging questions:
> - are inputs shared?
> - how badly does that mess up the results?

Irrelevant to the speed question.  A simple 6-LUT in Stratix II does not 
share inputs.  LUT input sharing is an area optimization that we employ 
intelligently to avoid any penalty on performance while reducing number of 
ALMs required.

I should also point out that all our experiments during architecture 
experimentation are full synthesis + place & route runs on 100+ designs. 
One thing anyone who works on FPGA logic & routing architecture knows is 
that intuition isn't worth too much -- you can argue about "will shared 
inputs hurt things?" until you are blue in the face, but in the end only an 
experiment will tell the truth.

Funny side story:  One time during architecture experimentation someone put 
up a graph of some parameter (I forget what).  We sat their and rationalized 
why the answer would come out that way, and were all content.  Then we 
realized the graph was backwards and the trend was actually the other way 
around.  We could rationalize that answer too...

Bottom line:  Logic & routing architecture development must involve large 
amount of experimentation with real cad tools, otherwise you just don't 
arrive at the right answer.

> - given the smallest LUT is not a 4 LUT, for smaller than 5 logic terms, 
> how badly does that increase the delay?

Wrong again.  The ALM breaks into two independent 4-input LUTs with no delay 
penalty (ok, maybe a couple ps for a gate load or two) relative to a 
Stratix-like 4-LUT.

> I would claim a properly engineered 6 LUT would improve the overall 
> performance.  A compromise would provide some improvement.  A poor 
> implementation woukd make no difference.

Your first claim is correct.  And the ALM gives the speed of a 6-LUT, but 
the extra circuitry added to support fractured modes (2 4-LUTs, shared LUTs, 
etc.) is minimal and adds a tiny amount of delay to the guts of the LUT.

> Should all LUTs be 6 LUTs?  Or a mixture of both?  In what ratio?

Good questions.  The reality is that a real design mapped into 6-LUTs 
doesn't yield all 6-input functions -- it decomposes into a set of functions 
ranging from 1- to 6-inputs.  That is why making a pure 6-LUT architecture 
is not so great for area -- for those functions that don't use 6-inputs, you 
are wasting a lot of routing & logic area.  That is why we added the 
fracturing capabilities of the ALM.  This makes the ALM more expensive than 
a straight 6-LUT for implementing 6-input functions, but overall once the 
distribution of functions is taken into account, the ALM comes out on top.

One alternative could be to make an architecture with a hybrid set of LUT 
sizes.  But then you have to wonder whether you've picked the right mix of 
the two, you have the pain of hetrogeneous floorplanning in layout, you have 
potential issues with placement, more complicated CAD tools, etc.

> Can you use them as SRL?  LUT RAM?

No, the ALM can't do that.  We've argued about that many times in this 
newsgroup -- SRLs and LUT RAM add cost to the Logic Element.  M512 memories 
are more efficient for many circuits, while SRLs/LUT RAM are more efficient 
for others.  Are SRL/LUT RAM a bad idea?  No.  Are they a slam dunk?  No.

> The synthesis tools all have to be retuned, and debugged to take 
> advantage, so this is not without risk.

Yes, that was a risk.  We took that risk because we believed the ALM was a 
large enough win on the performance front to be worth the investment in 
synthesis and the risk to product success.  If the ALM had given us 5% 
performance, there's no way we would have gone for it.  But sometimes you 
need to take a big jump in architecture to get out of a local minimum in the 
space of architecture possibilities.

We worked with our 3rd party synthesis vendors well in advance of the 
release of Stratix II, and our own integrated synthesis was used during 
architecture development and thus was already ready to go.

> As for area, a 6 LUT is not all that big as technology shrinks, so some 
> combinations of variable LUT size, alternate architectures, is in my 
> opinion, inevitable.

Actually, the area of everything (LUTs, routing, RAMs, etc) shrinks as 
technology does, so I don't think the 4-LUT vs. 6-LUT question changes too 
much with process.  The only effect here is that perhaps as the amount of 
delay in routing vs. logic moves around with process, the precise answer as 
to what LUT and Cluster sizes are optimal will shift slightly, but this is 
probably a small effect.  A bigger effect could be evolution in the quality 
of synthesis and CAD tools, the changing nature of user designs, and 
advances in routing architecture.

> As for speed, the smaller the technology, the less improvement in speed 
> (ITRS roadmap, and anyone who says differently can be confidently 
> ignored).  For speed, one now has to use triple oxide to get both speed 
> and static power reduction (eg compare us to S2 at 25C and there is no 
> difference for leakage, but compare us at 85C, and we are 1/2 to 1/3 the 
> static power!).

I haven't seen any worst-case power numbers from you guys Austin.  Typical 
is a marketing number -- how do you define your "typical" silicon?  Let's 
hold off the power conclusions until both companies release final specs.

Besides, total power is what matters and you guys have curiously been shying 
away from dynamic power.  Your own web page claims equivalent dynamic power 
for a Virtex-4 LUT + routing vs. an Stratix II LUT + routing -- but our LUTs 
implement 25% more logic, and hence there are fewer of them in a given 
design.  Our pin capacitance is 1/2 that of V-4 -- you know what this does 
for I/O power?  Imagine 200 I/Os toggling at 200 Mhz with 6 pF instead of 12 
pF loads @ 2.5V (just as an example) -- if I've done my math right that's 
1.5W right there.  Now there's a strong chance I've done my math wrong (give 
me a break, its late) but you get the point!

> The wonderful thing about standard CMOS, is just that.  No one has a 
> remarkably different or unique process.  But one can use standard CMOS 
> with all of the available tricks, and see a 1/2 to 1/3 reduction in static 
> power, an improvement in speed, and an improvement in SEU resilience. 
> Like V4.

Yes, there are tricks to employ.  But they can cost speed.  They can cost 
area.  They can increase wafer costs.  All involve trade-offs.  In the end, 
we each picked the tricks we wanted to use.  Gate oxide is only one variable 
to play with, and not the most effective one on the speed vs. leakage 
trade-off front.

> Also, there is room for improvement with the P&R tools

True.  Both companies have teams beating on this software for lots of 
performance.  But if you're now saying that perhaps future software and a 
future speed grade will help you catch up on performance, I'm feeling pretty 
happy with our position.

Regards,

Paul Leventis
Altera Corp.



Article: 78785
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Tue, 8 Feb 2005 00:17:32 -0500
Links: << >>  << T >>  << A >>
Hi Jim,

>  A significant difference at the LUT spec level that I DID see ( and I 
> presume still applies ? ) is that Altera have differing LUT path delays
> ( all LUT legs are not created equal ), whilst Xilinx treated them
> all equal.

Our LUTs have (significantly) different delays on different inputs.

>  That means the Altera SW/HW can presumably choose the faster legs, where 
> that matters, and so shave 100's of ps off the critical path ?
>  => Faster P&R on otherwise similar silicon ?

Yes, the software does take advantage of the variance in LUT delay to 
optimize the critical path.  This is why using 6-LUTs to implement 4-input 
functions is no worse for speed than using a 4-LUT -- the four fastest 
inputs of a 6-LUT are basically the same speed as the four inputs of a 
4-LUT.

Regards,

Paul Leventis
Altera Corp.



Article: 78786
Subject: Re: MAP problem
From: Bret Wade <bret.wade@xilinx.com>
Date: Mon, 07 Feb 2005 22:23:55 -0700
Links: << >>  << T >>  << A >>
John Maher wrote:
> Hi I am using JBITS to generate an anticore for a virtex device. When I run the MAP process I get the error, below. Could anyone give me some insight as to what exactly it means, or even better how I might fix it?
> 
> Thanks -J
> 
> "FATAL_ERROR:Ncd:basnccomp.c:3516:1.29 - Cannot find other bel for unconnected pin on bel <0>.WSGEN:CK of comp coreoutbus<0>. Its current programmed state is : YUSED:0 XUSED:0 F:#RAM:D=0x0000 G:#RAM:D=0x0000 RAMCONFIG:2SHIFTS SRMUX:1 GYMUX:G FXMUX:F Process will terminate. To resolve this error, please consult the Answers Database and other online resources at <http://support.xilinx.com>"

Hi John,

This error message is reporting an illegal slice configuration in your 
design. It appears that the problem has to do with an unconnected clock 
pin. Everything after "Its current programmed state" is just a dump of 
the slice configuration. You should be able to trace the logic from the 
component name "coreoutbus<0>".

Cheers,
Bret

Article: 78787
Subject: Re: Max. Operating Frequency - Timing report
From: "Symon" <symon_brewer@hotmail.com>
Date: Mon, 7 Feb 2005 21:28:51 -0800
Links: << >>  << T >>  << A >>
Maybe it signifies the speed your design would run at if you took it out of 
the fridge and put it in the oven?
Syms.
<tovijayakumar@yahoo.com> wrote in message 
news:1107829970.374954.26030@f14g2000cwb.googlegroups.com...
> The Xilinx timing report for XPLA3 CPLD shows maximum operating
> frequency of 30 MHz for one of our design. But the CPLD is functioning
> correctly at 80 MHz. If so what does the Maximum operating frequency
> specified in the timing report signify?
> 



Article: 78788
Subject: Re: Max. Operating Frequency - Timing report
From: "jtw" <wrightjt @hotmail.invalid>
Date: Tue, 08 Feb 2005 05:41:28 GMT
Links: << >>  << T >>  << A >>
"Symon" <symon_brewer@hotmail.com> wrote in message 
news:36r100F54rrhtU1@individual.net...
> Maybe it signifies the speed your design would run at if you took it out 
> of the fridge and put it in the oven?
> Syms.
> <tovijayakumar@yahoo.com> wrote in message 
> news:1107829970.374954.26030@f14g2000cwb.googlegroups.com...
>> The Xilinx timing report for XPLA3 CPLD shows maximum operating
>> frequency of 30 MHz for one of our design. But the CPLD is functioning
>> correctly at 80 MHz. If so what does the Maximum operating frequency
>> specified in the timing report signify?
>>

Or more likely, the paths that Xilinx sees as critical are not...

The tools support multi-cycle timing constraints.  Did you give it 
appropriate constraints, or just let it do it's own thing?

Jason 



Article: 78789
Subject: Re: See Peter's High-Wire Act next Tuesday
From: "Paul Leventis \(at home\)" <paulleventis-news@yahoo.ca>
Date: Tue, 8 Feb 2005 00:44:45 -0500
Links: << >>  << T >>  << A >>
Oops, I missed one point (thanks Carolyn!).

> - is it a universal 6 LUT, or 2 5 LUTs with some sharing and some extra 
> logic to almost give you a 6 LUT?  How badly does that work?

Yes, the ALM is a universal 6-LUT.  It can do some functions of 7-inputs, 
and all functions of 6-inputs.

Please refer to http://www.altera.com/literature/hb/stx2/stx2_sii51002.pdf. 
Page 2-8 is the diagram you want to stare at closely.

Paul Leventis
Altera Corp.






Article: 78790
Subject: Re: ISE6.x/iMPACT, JTAG fails after any completed command
From: "AugustoEinsfeldt" <aee@terra.com.br>
Date: 7 Feb 2005 22:08:08 -0800
Links: << >>  << T >>  << A >>
Solution found. The XCF02S was with its GND pin floating....Actually
there was a PCB failure since the trace is almost touching the pad (I
would say 1/10th milimeter apart). Problem found in my last attempt to
find a solution, when I decided to look and verify every connection in
the JTAG chain and on each pin of each device on the board using
magnifying lenses. I did a verification before but not in the power
pins...
So, when something strange happens power pins verification should be
near to the top of the check list....
Thanks for your attention.


Article: 78791
Subject: Re: Impact errors programing V4LX25
From: Rudolf Usselmann <russelmann@hotmail.com>
Date: Tue, 08 Feb 2005 13:15:39 +0700
Links: << >>  << T >>  << A >>


Thanks to the excellent support from Xilinx this problem has
been solved !!!
Turns out the Memec-Insight board had a 100 ohm (yes 100 !)
pull-up on the TDO line. That basically broke everything.

Removing the pullup, got rin of the CRC bit errors and chip-
scope appears to work now as well.

Thanks a lot for going the extra mile, to all the good folks
at Xilinx !

Kind Regards,
rudi
=============================================================
Rudolf Usselmann,  ASICS World Services,  http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

Article: 78792
Subject: Re: problem with xilinx platform studio 6.2i
From: "Ram" <dotexe@gmail.com>
Date: 7 Feb 2005 23:44:31 -0800
Links: << >>  << T >>  << A >>
Thank you Mr.Shalin Sheth.


Article: 78793
Subject: System Generator: does it support high-level programming?
From: "Alan" <alan.c.yeung@gmail.com>
Date: 8 Feb 2005 00:08:29 -0800
Links: << >>  << T >>  << A >>
Hi,

I am wondering if anyone know a way to translate MATLAB code to VHDL
code using System Generator. I know that the MCode block supports a
limited set of MATLAB instructions only (therefore I cannot use it for
complex operations), and Blackbox block requires VHDL codes itself. How
about s-function? Since s-function accepts C codes, is there any way to
have System Generator to generate HDL codes using s-function, therefore
providing support to high-level programming language? Or is there
another method that translates high-level language codes into HDL using
System Generator?

Thanks in advance.


Article: 78794
Subject: Re: Quartus project files
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 08 Feb 2005 08:22:46 GMT
Links: << >>  << T >>  << A >>
So the cleanest way to handle this would be to identify the change of the defaults
that caused my difference and add this assignment to the 'regular' project file and
remove the <project>_assignment_defaults.qpf.

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/

"Subroto Datta" <sdatta@altera.com> schrieb im Newsbeitrag 
news:1107808734.098840.311310@c13g2000cwb.googlegroups.com...
> With QII 4.0, all assignments were consolidated into a single file the
> qsf, instead of being stored in several different files (csf, psf, ssf,
> fsf) etc. Also as part of QII 4.0, default values of assignments were
> no longer stored in the qsf file. In the past all defaults were stored
> in the csf file.
>
> Instead defaults for converted projects were stored in the qdf file in
> the project directory, with the name being
> <project_name>_assignment_defaults.qdf. Therefore projects which have
> been converted from older (i.e before Quartus II 4.0)will have a qdf
> file in their project directory.
>
> When assignments are resolved the default values specified in
> <project_name>_assignment_defaults.qdf have a higher priority than
> those specified in quartus\bin\assignment_defaults.qdf. Therefore when
> you removed the <project_name>_assignment_defaults.qdf file some of the
> values of your default settings would have changed, and this explains
> the change in results. If you look at the file
> quartus\bin\assignment_defaults.qdf you will find a history of the
> default changes between releases from 4.1 onwards. An example of the
> comments in the QII 4.2 assignmnet_defaults.qdf file is:
>
> # Default value changes
> #
> # In 4.2, the default value of assignment DO_MIN_ANALYSIS has changed
> to "OFF"
> # In 4.1, the default value of assignment FITTER_EFFORT has changed to
> "Auto Fit"
>
> Hope this helps,
> Subroto Datta
> Altera Corp.
>
>
> Martin Schoeberl wrote:
>> I have a project which started with MP2 w. Leonardo and was converted
> by
>> several versions of Quartus (including several new file types). With
> Quartus 4.2
>> I thought the project merely consists of proj.qpf and proj.qsf.
> Having all the assignments
>> in the .qsf file.
>> However, when I compiled the project with the other 'old' project
> files removed it resulted
>> in a different solution (fmax was 95MHz instead of 100MHz).
>> Adding the proj_assignment_defaults.qpf back to the project I got the
> original result.
>> So the question is: What's this xxx_as._def.qpf for?
>>
>> Martin
>> ----------------------------------------------
>> JOP - a Java Processor core for FPGAs:
>> http://www.jopdesign.com/
> 



Article: 78795
Subject: SimmStick FPGA module
From: "Martin Schoeberl" <martin.schoeberl@chello.at>
Date: Tue, 08 Feb 2005 09:40:40 GMT
Links: << >>  << T >>  << A >>
Hi all,

I'm thinking about a new board for JOP (or MB, NIOS). The board should be small and
cheap (below the S3 Starter Kit). It should only contain the absolute necessary parts for a
CPU design. Here is the suggested part list:

    FPGA: Cyclone EP1C3 or Spartan XC3S200
    256Kx16 15ns SRAM
    2 MBit serial Flash
    3.3V linear regulation
    switching regulator for the core voltage
    20MHz clock to the PLL input

I've not yet decided about a X or A device.

A remaining question is about the form factor. I still think it makes sense to build
the board as a module that can be integrated in a board with the peripherals (similar
to the ACEX and Cyclone modules I've done). There are two 'standards' available:

1.) SimmStick, where the boards are designed as the 'old' PC SIMMs (see [1]).

2.) The 'Basic Stamp' design is a board in the form of an old 40-pin (or less) DIL IC.
    An example (from a Java processor competitor): [2]

For a Java solution in an FPGA this board should beat the Systronix aJ100 Java processor
modules (JStamp or JStick [3] - they have both form factors) in performance and price.
One nice thing about the SimmStick is that there are plenty of I/O boards already available
(see [4, 5, 6]).
It seems a relative 'old' design, but it's a bus and I can build my first JOP cluster with those
boards ;-)

What do you guys think about this idea? Does it make sense to build a another FPGA board?

[1]  http://www.simmstick.com/
[2]  http://jstamp.systronix.com/jstamp_photos.htm
[3]  http://www.jstik.com/
[4]  http://www.dontronics.com/dt.html
[5]  http://www.hobbyengineering.com/SectionSS.html
[6]  http://www.simmstick.com/simmstic1.htm

Martin
----------------------------------------------
JOP - a Java Processor core for FPGAs:
http://www.jopdesign.com/ 



Article: 78796
Subject: Re: SimmStick FPGA module
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 11:04:04 +0100
Links: << >>  << T >>  << A >>
Hi Martin,

Nice to see that some of my project are still live - I am the "inventor" of
the "SimmStick(tm)" standard :)

Please see my SHORT first comments below..

>"Martin Schoeberl" <martin.schoeberl@chello.at> schrieb im Newsbeitrag
news:sO%Nd.34738$2e4.30046@news.chello.at...
> Hi all,
>
> I'm thinking about a new board for JOP (or MB, NIOS). The board should be
small and
> cheap (below the S3 Starter Kit). It should only contain the absolute
necessary parts for a
> CPU design. Here is the suggested part list:
>
>     FPGA: Cyclone EP1C3 or Spartan XC3S200
>     256Kx16 15ns SRAM
-- here I would like to argue a lot!
I understand that JOP runs ok in that memory, but... all the rest  (if using
XC3S200) is uCLinux ready, except memory is not enough, so I would use 1
16bit SDRAM chip, not SRAM
XC3S200 is large enough to hold ucLinux ready MicroBlaze setup.
>     2 MBit serial Flash
-- again the 2MBit is enough for config, not for OS image, so if there would
be some means of having more, that would be nice, sure thats an price issue
>     3.3V linear regulation
>     switching regulator for the core voltage
for a small FPGA linear regulator is ok, too cheaper sure burns more energy,
Trenz S3-1000 module as example has small linear regulator supplying max
0.9A for core
>     20MHz clock to the PLL input
NEEDED 5V compliance quickswitches !!!
all new FPGAs are not 5V tolerant and for both mech standards simmstick and
stamp 5V compliance is highly recommended to have, its a pain for
manufacturer but a big + for the user
>
> I've not yet decided about a X or A device.

hard decision hugh?
answer is simple. BOTH
it doesnt cost so much more todo both variants, you may supply more support
for either A or X as of your preferences (or customer interest) but from the
hardware build expenses its even cheaper (per board) to order a combined pcb
patch

> A remaining question is about the form factor. I still think it makes
sense to build
> the board as a module that can be integrated in a board with the
peripherals (similar
> to the ACEX and Cyclone modules I've done). There are two 'standards'
available:
>
> 1.) SimmStick, where the boards are designed as the 'old' PC SIMMs (see
[1]).
>
> 2.) The 'Basic Stamp' design is a board in the form of an old 40-pin (or
less) DIL IC.
>     An example (from a Java processor competitor): [2]

You mean Parallax or those other guys? There are actually several stamp like
clones thing.
the stamp form factor is more challenging as the pcb are is very constrained
:(

> For a Java solution in an FPGA this board should beat the Systronix aJ100
Java processor
> modules (JStamp or JStick [3] - they have both form factors) in
performance and price.
> One nice thing about the SimmStick is that there are plenty of I/O boards
already available
> (see [4, 5, 6]).
> It seems a relative 'old' design, but it's a bus and I can build my first
JOP cluster with those
> boards ;-)

hm if you make the simmstick form factor board, here is a deal - I will
donate all my leftover simmStick stuff that includes some connectors and
protoboards etc, you can use all those boards and stuff as promotional bonus
give away for the early customers :)

> What do you guys think about this idea? Does it make sense to build a
another FPGA board?

hm.. I just recently looked at the parallax pricing.. still selling basic
interpreter for $49 (or more!) and still doing business. highend stamp are
in $99 range! So a fpga plugin module in $99 range, sure it might be
business idea still

>
> [1]  http://www.simmstick.com/
> [2]  http://jstamp.systronix.com/jstamp_photos.htm
> [3]  http://www.jstik.com/
> [4]  http://www.dontronics.com/dt.html
> [5]  http://www.hobbyengineering.com/SectionSS.html
> [6]  http://www.simmstick.com/simmstic1.htm
>
> Martin
> ----------------------------------------------
> JOP - a Java Processor core for FPGAs:
> http://www.jopdesign.com/
>
>



Article: 78797
Subject: Re: Xilinx Virtex2p configuration
From: =?ISO-8859-15?Q?Andreas_K=FChn?=
Date: Tue, 08 Feb 2005 11:21:08 +0100
Links: << >>  << T >>  << A >>
Hi John,

I experienced some wired results on IO configurations as well. The reason was a 
bug in the synplify synthesis tool. But it only happened for INOUT signals. It 
resolved the signal connections simply somehow.

akuehn

meg wrote:
> Hi,
> 
> I experience problems with some "normal" IO's(not dual purpose IO's) on 
> a  Xilinx Virtex2p50ff1517. I observe that these IO change value during  
> configuration and after configuration these IO are not high impedance 
> as  intended, but either high or low. These IO's are part of a 
> processor  interface where the other IO on this bus is high impedance. I 
> have checked  in FPGA Editor and find that there the "strange" IO's are 
> implemented  exactly as the "normal" IO's (the same signal is driving 
> the output  buffer).
> 
> Do any of you have any suggestion to what have gone wrong. Is the chip  
> damaged or is there something wrong with the configuration procedure. I  
> tried both slave-serial and JTAG programming but the behaviour is the same.
> 
> John
> 
> 
> 

Article: 78798
Subject: Retaining not used nodes
From: ALuPin@web.de (ALuPin)
Date: 8 Feb 2005 02:43:57 -0800
Links: << >>  << T >>  << A >>
Hi,

I have several nodes in my design (registered nodes) which do not have
a "driving" purpose. But for later use of SignalTap (Altera tool to
make internal FPGA nodes visible) I do want the synthesizer
not to optimize these nodes away. On the other hand I do not want
to route these nodes to output pins because of a limited amount of
available pins.

Is there some possibility to avoid that these registerd not used nodes
are optimized away ?

Thank you for your suggestion.

Rgds
André

Article: 78799
Subject: V4LX25-ES and systemACE
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 8 Feb 2005 12:00:04 +0100
Links: << >>  << T >>  << A >>
Hi

has any one some hints or tips how to get an Virtex4 LX25-ES configured from
SystemACE?
we can configure from iMpact and if we load the uclinux kernel from XMD it
works too.
but now when I try to load the uclinux image from CompactFlash then there
are problems
if the FPGA is configured by impact then there will always be random sector
read errors
when attempting to load the image.bin from CompactFlash. On ML300 I had to
load from
CF in order to access the CF, but with V4LX the FPGA config from
CompactFlash doesnt
seem to work, the status led blinks once and then the error led goes on. I
assume it is the TDO
tristate problem with -ES samples, but...

ML401 has systemACE as well and that works! So whats the trick ??

Antti





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