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 109800

Article: 109800
Subject: Re: Just a matter of time
From: "jacko" <jackokring@gmail.com>
Date: 5 Oct 2006 11:31:25 -0700
Links: << >>  << T >>  << A >>

Mike Treseler wrote:
<snip>
> note to vendors:
>
> When I need something from you, I check your
> web site, not my old emails. Drop the
> email spew, and use the money to get new
> information to your websites quickly,
> where I can find it easily, and without filling
> out more forms.

right on.

i have recieved no junk from altera, but somehow i'm getting junk from
xilinix, even though the web download of the fpga tool failed. do they
think i am that impressed that they need to promote me to use their
stuff?

http://indi.joox.net

altera all the way.

cheers

p.s. even lattice are better on the speil side with no excess shite.


Article: 109801
Subject: Re: nicer code => slower code??
From: burn.sir@gmail.com
Date: 5 Oct 2006 11:39:22 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:
> burn.sir@gmail.com wrote:
>
> > Would this go away if I somehow "flattened" my design?
>
> I would back out the changes one at a time
> to find the culprit. Maybe adding the entities
> created a pipeline stage somehow.
> Also check the rtl viewer.
>
>    -- Mike Treseler


Actually, both designs are _indentical_. I know that because we have
some
really tough tests for them. In addition, I spent 3-4 hours manually
inspecting the code, the tests and all the simulation logs..



What happened is that the synthesis tool stopped optimising after
a certain depth. At least, that is my theory...


burns


Article: 109802
Subject: Re: SMPTE310 interface
From: "jacko" <jackokring@gmail.com>
Date: 5 Oct 2006 11:47:56 -0700
Links: << >>  << T >>  << A >>

cbr_929rr wrote:
> I am looking for ideas on how to implement SMPTE310 Tx and Rx
> interface.
>
> Algorithm/VHDL/Verilog examples would be helpful.
> Thanks.

is this the MIDI variant?


Article: 109803
Subject: Re: SMPTE310 interface
From: "cbr_929rr" <cbr_929rr@hotmail.com>
Date: 5 Oct 2006 11:51:54 -0700
Links: << >>  << T >>  << A >>
It is a Sync. serial interface to transport MPEG2. DVB-ASI (async.
serial interface)  is the other popular standard.

jacko wrote:
> cbr_929rr wrote:
> > I am looking for ideas on how to implement SMPTE310 Tx and Rx
> > interface.
> >
> > Algorithm/VHDL/Verilog examples would be helpful.
> > Thanks.
> 
> is this the MIDI variant?


Article: 109804
Subject: Re: Just a matter of time
From: PeteS <peter.smith8380@ntlworld.com>
Date: Thu, 05 Oct 2006 18:53:24 GMT
Links: << >>  << T >>  << A >>
Antti wrote:
> Kolja Sulimma schrieb:
> 
> 
>>rickman schrieb:
>>
>>>Over the years I have gotten a lot of junk email from Xilinx to email
>>>addresses that I have given out only to support and never to any
>>>marketing channel.  I have always been disappointed that Xilinx has
>>>done this.  But now they have sunk to a new low, they are giving or
>>>selling my email address to third party junk emailers.
>>
>>I see that too.
>>I think it is bad business practice. It does not make me feel that I can
>>share sensitive information with them in a webcase or similar.
>>
>>And who knows whom Foundation ISE sends your source codes to.
>>If a company sees cloak and dagger methods as part of their business
>>model you can not trust them anymore.
>>
>>Kolja Sulimma
> 
> 
> and did you notice that in ISE 8.2 there is now also a WEB-TALKBACK
> feature that ask you to submit your design statistics to Xilinx !?
> (similar to Altera software)
> 
> however if in Altera enabling the talkback enables the free use of jtag
> logic analyzer features then the talkback in Xilinx is simple
> additional burden for you and you get nothing in return !
> 
> Antti
> 

Because ISE uses the IE ActiveX control (on Windoze), it is source 
blocked from any internet access on this system. They don't feel the 
need on Linux, (obviously, because it doesn't exist) so why use it on 
Windoze?

Hint: ActiveX _is_ the problem. Any process that uses the IE activeX 
controls is blocked from access in both directions, so it's not just 
Xilinx, but it does seem silly. Why not just invoke web requests through 
$BROWSER?

So - no, Xilinx gets no statistics from me, even though I might actually 
be willing to share.

Cheers

PeteS

Article: 109805
Subject: Re: unexpected Xilinx TNM constraint behaviour
From: "JustJohn" <john.l.smith@l-3com.com>
Date: 5 Oct 2006 12:02:11 -0700
Links: << >>  << T >>  << A >>


On Oct 3, 11:16 am, "johnp" <johnp3+nos...@probo.com> wrote:
> I'm seeing some unexpected behavior when using the Xilinx TNM
> constraint in a ucf file.
> [...]
> I then tried:
> NET "u_os_if/rd_burst"                  TNM = x_rio_tx;
> NET "u_fx2if/reg_brst_rd"               TNM = x_rio_tx;
> TIMESPEC "ts_os_x3"     = FROM x_rio_tx to
> FFS(upo_joey_if/xmit_data<*>)  = 12;
>
> and I was VERY surprised at the result.  Instead of applying the
> constraint
> from the rd_burst and reg_brst_rd signals to the xmit_data<*> signals,
> it
> instead constrained a path from xmit_data<8> to xmit_data<15>.
>
> Is this yet another Xilinx bug or am I mis-using the TNM constraint?
>
> Thanks!
>
> John Providenza

The TNM grouping constraint, when applied to a net, collects all
instances that fan _forward_ from the net, but does not collect the
source that drives the net. To put the sources of nets
"u_os_if/rd_burst" and "u_fx2if/reg_brst_rd" into group "x_rio_tx", you
might most easily use TNM applied to the primitive instances directly:

INST "u_os_if/rd_burst" TNM x_rio_tx;
INST "u_fx2if/reg_brst_rd" TNM x_rio_tx;

(assuming that _net_ u_os_if/rd_burst is sourced by a _FF_ with the
same name, and similarly for the other FF output).

But be careful if you are using this in a UCF file. FFs may be
duplicated during synthesis: you may have both a FF named
"u_os_if/rd_burst" and a FF named "u_os_if/rd_burst_1", where the first
FF controls some of your data bits, and the second controls others. In
this case, you might want to collect your sources using wildcards:
INST "u_os_if/rd_burst*" TNM x_rio_tx;
INST "u_fx2if/reg_brst_rd*" TNM x_rio_tx;
If your synthesis tool names duplicate FFs in a rational manner (and
you've named your signals so the wildcard expressions don't include
unwanted devices), this would collect all the ones you want into
timegroup x_rio_tx.

Suppose the net rd_burst is not a FF output, but a combinatorial? Then
you'd have to find all FFs that source the combinatorial, and collect
them into x_rio_tx. As far as I know, you have to do this manually; to
my knowledge, there is no _backward_ propagating group collector that
does this. (It is not a simple proposition given the way synthesis
tools can mangle a design from how you would like/expect it to be
elaborated.)

HTH,
Just John


Article: 109806
Subject: Re: An implementation of a clean reset signal
From: "jens" <roden@rochester.rr.com>
Date: 5 Oct 2006 12:05:18 -0700
Links: << >>  << T >>  << A >>
> It lacks nothing.  In fact any design that does NOT generate a synchronously
> timed trailing edge reset is 'lacking' and will eventually fail because at
> some point that trailing edge of reset will come along at a time relative to
> the clock that violates setup/hold timing requirements and cause a flip flop
> or two to go to the wrong state.  This is all assuming that the clock is
> free running (or at least running at the trailing edge of reset).

I can think of a couple of exceptions where a completely asynchronous
reset won't cause any problems:

1. A free-running counter that has no unrecoverable illegal states
(i.e. a bad state that doesn't eventually turn into a good state) and
no requirement to be immediately operational after reset.

2. An FPGA that is waiting for an external event (like a discrete input
or CPU register write) to start doing something, and the external event
happens after the reset.

I can't think of an FPGA design that I've worked on where one of those
options didn't apply.  There's also a little bit of assumption with #1
and an HDL- that the compiler doesn't do anything funny, like recognize
that a simple up or down counter in the code can be replaced by an
LFSR, in which case there can be illegal states.

So for designs that meet those options, there's no need to panic and do
a massive product recall.  Yet for current & future designs,
synchronizing the trailing edge of a reset signal is a great idea.


Article: 109807
Subject: a clueless bloke tells Xilinx to get a move on
From: "Brannon" <brannonking@yahoo.com>
Date: 5 Oct 2006 12:23:03 -0700
Links: << >>  << T >>  << A >>
The following is an informal letter to Xilinx requesting their
continued efforts to increase the speed of their software tools. If
there are incorrect or missing statements, please correct me!

Dear Xilinx:

As many of us spend numerous hours of our life waiting for
Map/Par/Bitgen to finish, I hereby petition Xilinx, Inc., to consider
this issue (of their tool speed) to be of the highest priority. I am
now scared to purchase newer chips because I fear that their increased
size and complexity will only further delay my company's development
times. Please, please, please invest the time and money to make the
tools execute faster.

Have you considered the following ideas for speeding up the process?

1.	The largest benefit to speed would be obtained through making the
tools multithreaded. Upcoming multi-core processors will soon be
available on all workstation systems. What is it that is causing Xilinx
years on end to make their tools multithreaded? There is no excuse for
this. I assume the tools are written in C/C++. Cross platform C/C++
threading libraries make thread management and synchronization easy
(see boost.org).
2.	Use a different algorithm. I understand that the tools currently
rely on simulated Annealing algorithms for placement and routing. This
is probably a fine method historically, but we are arriving at the
point where all paths are constrained and the paths are complex (not
just vast in number). If there is no value in approximation, then the
algorithm loses its value.  Perhaps it is time to consider a Branch and
Bound algorithm instead. This has the advantage of being easily
threadable.
3.	SIMD instructions are available on most modern processors. Are we
taking full advantage of them? MMX, SSE1/2/3/4, etc.
4.	Modern compilers have much improved memory management and
compilation over those of previous years. Also, the underlying
libraries for memory management and file IO can have a huge impact on
speed. Which compiler are you using? Which libraries are you using?
Have you tried the latest PathScale or Intel compilers?
5.	In recent discussions about the speed of the map tool, I learned
that it took an unearthly five minutes to simply load and parse a 40MB
binary file on what is considered a fairly fast machine. It is
obviously doing a number of sanity checks on the file that are likely
unnecessary. It is also loading the chip description files at the same
time. Even still, that seems slow to me. Can we expand the file format
to include information about its own integrity? Can we increase the
file caches? Are we using good, modern parser technology? Can we add
command line parameters that will cause higher speed at the cost of
more memory usage and visa-versa? Speaking of command line parameters,
the software takes almost three seconds to show them. Why does it take
that long to simply initialize?
6.	Xilinx's chips are supposedly useful for acceleration. If so, make
a PCIe x4 board that accelerates the tools using some S3 chips and
SRAM. I'd pay $1000 for a board that gave a 5x improvement. (okay, so
that is way less than decent simulation tools, I confess I'm not
willing to pay big dolla....)
7.	Is Xilinx making its money on software or hardware? If it is not
making money on software, then consider making it open source. More
eyes on the code mean more speed. 

Sincerely,
An HDL peon


Article: 109808
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: "johnp" <johnp3+nospam@probo.com>
Date: 5 Oct 2006 12:41:56 -0700
Links: << >>  << T >>  << A >>
Brannon -

Although I'd like the tools to run faster, I think it is *far* more
important for Xilinx to fix the numerous bugs and crashes.

Yet again I've had to completely re-build a project because Navigator
corrupted the .ise file and the backup version.

Make the tools work, then speed them up.

John Providenza


Brannon wrote:
> The following is an informal letter to Xilinx requesting their
> continued efforts to increase the speed of their software tools. If
> there are incorrect or missing statements, please correct me!
>
> Dear Xilinx:
>
> As many of us spend numerous hours of our life waiting for
> Map/Par/Bitgen to finish, I hereby petition Xilinx, Inc., to consider
> this issue (of their tool speed) to be of the highest priority. I am
> now scared to purchase newer chips because I fear that their increased
> size and complexity will only further delay my company's development
> times. Please, please, please invest the time and money to make the
> tools execute faster.
>
> Have you considered the following ideas for speeding up the process?
>
> 1.	The largest benefit to speed would be obtained through making the
> tools multithreaded. Upcoming multi-core processors will soon be
> available on all workstation systems. What is it that is causing Xilinx
> years on end to make their tools multithreaded? There is no excuse for
> this. I assume the tools are written in C/C++. Cross platform C/C++
> threading libraries make thread management and synchronization easy
> (see boost.org).
> 2.	Use a different algorithm. I understand that the tools currently
> rely on simulated Annealing algorithms for placement and routing. This
> is probably a fine method historically, but we are arriving at the
> point where all paths are constrained and the paths are complex (not
> just vast in number). If there is no value in approximation, then the
> algorithm loses its value.  Perhaps it is time to consider a Branch and
> Bound algorithm instead. This has the advantage of being easily
> threadable.
> 3.	SIMD instructions are available on most modern processors. Are we
> taking full advantage of them? MMX, SSE1/2/3/4, etc.
> 4.	Modern compilers have much improved memory management and
> compilation over those of previous years. Also, the underlying
> libraries for memory management and file IO can have a huge impact on
> speed. Which compiler are you using? Which libraries are you using?
> Have you tried the latest PathScale or Intel compilers?
> 5.	In recent discussions about the speed of the map tool, I learned
> that it took an unearthly five minutes to simply load and parse a 40MB
> binary file on what is considered a fairly fast machine. It is
> obviously doing a number of sanity checks on the file that are likely
> unnecessary. It is also loading the chip description files at the same
> time. Even still, that seems slow to me. Can we expand the file format
> to include information about its own integrity? Can we increase the
> file caches? Are we using good, modern parser technology? Can we add
> command line parameters that will cause higher speed at the cost of
> more memory usage and visa-versa? Speaking of command line parameters,
> the software takes almost three seconds to show them. Why does it take
> that long to simply initialize?
> 6.	Xilinx's chips are supposedly useful for acceleration. If so, make
> a PCIe x4 board that accelerates the tools using some S3 chips and
> SRAM. I'd pay $1000 for a board that gave a 5x improvement. (okay, so
> that is way less than decent simulation tools, I confess I'm not
> willing to pay big dolla....)
> 7.	Is Xilinx making its money on software or hardware? If it is not
> making money on software, then consider making it open source. More
> eyes on the code mean more speed. 
> 
> Sincerely,
> An HDL peon


Article: 109809
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: Ray Andraka <ray@andraka.com>
Date: Thu, 05 Oct 2006 16:01:34 -0400
Links: << >>  << T >>  << A >>
Brannon wrote:
> The following is an informal letter to Xilinx requesting their
> continued efforts to increase the speed of their software tools. If
> there are incorrect or missing statements, please correct me!
> 
> Dear Xilinx:
> 
> As many of us spend numerous hours of our life waiting for
> Map/Par/Bitgen to finish, I hereby petition Xilinx, Inc., to consider
> this issue (of their tool speed) to be of the highest priority. I am
> now scared to purchase newer chips because I fear that their increased
> size and complexity will only further delay my company's development
> times. Please, please, please invest the time and money to make the
> tools execute faster.
> 
> Have you considered the following ideas for speeding up the process?
> 
> 1.	The largest benefit to speed would be obtained through making the
> tools multithreaded. Upcoming multi-core processors will soon be
> available on all workstation systems. What is it that is causing Xilinx
> years on end to make their tools multithreaded? There is no excuse for
> this. I assume the tools are written in C/C++. Cross platform C/C++
> threading libraries make thread management and synchronization easy
> (see boost.org).
> 2.	Use a different algorithm. I understand that the tools currently
> rely on simulated Annealing algorithms for placement and routing. This
> is probably a fine method historically, but we are arriving at the
> point where all paths are constrained and the paths are complex (not
> just vast in number). If there is no value in approximation, then the
> algorithm loses its value.  Perhaps it is time to consider a Branch and
> Bound algorithm instead. This has the advantage of being easily
> threadable.
> 3.	SIMD instructions are available on most modern processors. Are we
> taking full advantage of them? MMX, SSE1/2/3/4, etc.
> 4.	Modern compilers have much improved memory management and
> compilation over those of previous years. Also, the underlying
> libraries for memory management and file IO can have a huge impact on
> speed. Which compiler are you using? Which libraries are you using?
> Have you tried the latest PathScale or Intel compilers?
> 5.	In recent discussions about the speed of the map tool, I learned
> that it took an unearthly five minutes to simply load and parse a 40MB
> binary file on what is considered a fairly fast machine. It is
> obviously doing a number of sanity checks on the file that are likely
> unnecessary. It is also loading the chip description files at the same
> time. Even still, that seems slow to me. Can we expand the file format
> to include information about its own integrity? Can we increase the
> file caches? Are we using good, modern parser technology? Can we add
> command line parameters that will cause higher speed at the cost of
> more memory usage and visa-versa? Speaking of command line parameters,
> the software takes almost three seconds to show them. Why does it take
> that long to simply initialize?
> 6.	Xilinx's chips are supposedly useful for acceleration. If so, make
> a PCIe x4 board that accelerates the tools using some S3 chips and
> SRAM. I'd pay $1000 for a board that gave a 5x improvement. (okay, so
> that is way less than decent simulation tools, I confess I'm not
> willing to pay big dolla....)
> 7.	Is Xilinx making its money on software or hardware? If it is not
> making money on software, then consider making it open source. More
> eyes on the code mean more speed. 
> 
> Sincerely,
> An HDL peon
> 

Xilinx has already sped up time to completion at the cost of poorer end 
performance on some high performance designs.  I'll take PAR that takes 
longer to complete but gets closer to the timing previous versions got 
on hand-placed designs over having to run a faster PAR numerous times in 
order to get a routing solution that meets timing.

I have to wonder whether the writer of this letter looked at his own 
design for the reasons PAR was taking too long.  Did he keep the levels 
of logic to a reasonable number for his desired timing target?  Did he 
duplicate logic to reduce high fanout nets?  Did he try any 
floorplanning for critical parts of the design?  Somehow I doubt it, yet 
those things can make a several orders of magnitude difference in the 
time to run PAR.

Article: 109810
Subject: Re: An implementation of a clean reset signal
From: mk <kal*@dspia.*comdelete>
Date: Thu, 05 Oct 2006 20:07:43 GMT
Links: << >>  << T >>  << A >>
On Thu, 05 Oct 2006 10:34:22 GMT, "KJ" <kkjennings@sbcglobal.net>
wrote:
>The next question to ponder is, given that the reset must be synchronized 
>anyway, why use an asynchronous reset anywhere in your design (with the 
>exception of course of the above mentioned synchronizer)?  People will 
>pontificate on the subject but have yet to produce any coherent reason to 
>prefer async or sync.  Or they will claim some logic resource advantage that 
>when you test the claim is found to be baseless (in almost every case, the 
>logic and performance is darn near identical).

How about this: In an FPGA all the flops are already async (unlike
ASICs) so you're getting hit by the potential slow setup, clk->q issue
already so you might as well take advantage of it because going to
sync reset will need a mux at the input. In an ASIC, depending on the
library, adding the reset condition mux at the input of non-reset
flops may give you an advantage or not.

Article: 109811
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: PeteS <peter.smith8380@ntlworld.com>
Date: Thu, 05 Oct 2006 20:08:45 GMT
Links: << >>  << T >>  << A >>
johnp wrote:
> Brannon -
> 
> Although I'd like the tools to run faster, I think it is *far* more
> important for Xilinx to fix the numerous bugs and crashes.
> 
> Yet again I've had to completely re-build a project because Navigator
> corrupted the .ise file and the backup version.
> 
> Make the tools work, then speed them up.
> 
> John Providenza
> 
> 
> Brannon wrote:
> 
>>The following is an informal letter to Xilinx requesting their
>>continued efforts to increase the speed of their software tools. If
>>there are incorrect or missing statements, please correct me!
>>
>>Dear Xilinx:
>>
>>As many of us spend numerous hours of our life waiting for
>>Map/Par/Bitgen to finish, I hereby petition Xilinx, Inc., to consider
>>this issue (of their tool speed) to be of the highest priority. I am
>>now scared to purchase newer chips because I fear that their increased
>>size and complexity will only further delay my company's development
>>times. Please, please, please invest the time and money to make the
>>tools execute faster.
>>
>>Have you considered the following ideas for speeding up the process?
>>
>>1.	The largest benefit to speed would be obtained through making the
>>tools multithreaded. Upcoming multi-core processors will soon be
>>available on all workstation systems. What is it that is causing Xilinx
>>years on end to make their tools multithreaded? There is no excuse for
>>this. I assume the tools are written in C/C++. Cross platform C/C++
>>threading libraries make thread management and synchronization easy
>>(see boost.org).
>>2.	Use a different algorithm. I understand that the tools currently
>>rely on simulated Annealing algorithms for placement and routing. This
>>is probably a fine method historically, but we are arriving at the
>>point where all paths are constrained and the paths are complex (not
>>just vast in number). If there is no value in approximation, then the
>>algorithm loses its value.  Perhaps it is time to consider a Branch and
>>Bound algorithm instead. This has the advantage of being easily
>>threadable.
>>3.	SIMD instructions are available on most modern processors. Are we
>>taking full advantage of them? MMX, SSE1/2/3/4, etc.
>>4.	Modern compilers have much improved memory management and
>>compilation over those of previous years. Also, the underlying
>>libraries for memory management and file IO can have a huge impact on
>>speed. Which compiler are you using? Which libraries are you using?
>>Have you tried the latest PathScale or Intel compilers?
>>5.	In recent discussions about the speed of the map tool, I learned
>>that it took an unearthly five minutes to simply load and parse a 40MB
>>binary file on what is considered a fairly fast machine. It is
>>obviously doing a number of sanity checks on the file that are likely
>>unnecessary. It is also loading the chip description files at the same
>>time. Even still, that seems slow to me. Can we expand the file format
>>to include information about its own integrity? Can we increase the
>>file caches? Are we using good, modern parser technology? Can we add
>>command line parameters that will cause higher speed at the cost of
>>more memory usage and visa-versa? Speaking of command line parameters,
>>the software takes almost three seconds to show them. Why does it take
>>that long to simply initialize?
>>6.	Xilinx's chips are supposedly useful for acceleration. If so, make
>>a PCIe x4 board that accelerates the tools using some S3 chips and
>>SRAM. I'd pay $1000 for a board that gave a 5x improvement. (okay, so
>>that is way less than decent simulation tools, I confess I'm not
>>willing to pay big dolla....)
>>7.	Is Xilinx making its money on software or hardware? If it is not
>>making money on software, then consider making it open source. More
>>eyes on the code mean more speed. 
>>
>>Sincerely,
>>An HDL peon
> 
> 
The crashes are, no doubt, because of the increasing complexity of each 
part of the process required to be evaluated by the tools. The *nix way 
was always 'do one thing and do it well' which used to exemplify the 
Xilinx tools. As they have got more complex, they have added things to 
each tool, such that they are now doing more than one thing. Adding such 
complexity adds exponential sources of problems.

I suggest each tool be completely re-evaluated - and if it's doing more 
than one thing, separate those things back out - to 'Do one thing and do 
it well'.

That would very probably deal with a lot of the crashes, and ultimately 
speed.

Cheers

PeteS

Article: 109812
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: "Thomas Entner" <aon.912710880@aon.at>
Date: Thu, 5 Oct 2006 22:16:28 +0200
Links: << >>  << T >>  << A >>
I back up both requests:

Xilinx and Altera should make there tools faster, especially make usage of 
multi-cores. I hope that there is something coming soon, as this trend as 
clear since over a year. E.g. I wrote on 1st March 2005 to this newsgroup:
> I think we should all encourage the FPGA- and EDA-tool-vendors to adapt
> there software for parallel algorithms (especially place and route), as 
> the
> dual-cores are really coming soon and most of us will buy the fastest
> machine they can get for reasonable money. In fact, a parallel algorithm
> would already help a little bit today for P4s with hyper-threading.

Also Xilinx should improve their software quality, with every new ISE you 
get new errors into your designs that worked fine with previous releases. 
It's frustrating... In doubt I would also recommend to concentrate on the 
old bugs first before introducing new ones with multithreading... (my 
Xilinx-designs are not that large ;-)

Thomas

"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
news:1160077316.480007.91410@m7g2000cwm.googlegroups.com...
> Brannon -
>
> Although I'd like the tools to run faster, I think it is *far* more
> important for Xilinx to fix the numerous bugs and crashes.
>
> Yet again I've had to completely re-build a project because Navigator
> corrupted the .ise file and the backup version.
>
> Make the tools work, then speed them up.
>
> John Providenza
>
>
> Brannon wrote:
>> The following is an informal letter to Xilinx requesting their
>> continued efforts to increase the speed of their software tools. If
>> there are incorrect or missing statements, please correct me!
>>
>> Dear Xilinx:
>>
>> As many of us spend numerous hours of our life waiting for
>> Map/Par/Bitgen to finish, I hereby petition Xilinx, Inc., to consider
>> this issue (of their tool speed) to be of the highest priority. I am
>> now scared to purchase newer chips because I fear that their increased
>> size and complexity will only further delay my company's development
>> times. Please, please, please invest the time and money to make the
>> tools execute faster.
>>
>> Have you considered the following ideas for speeding up the process?
>>
>> 1. The largest benefit to speed would be obtained through making the
>> tools multithreaded. Upcoming multi-core processors will soon be
>> available on all workstation systems. What is it that is causing Xilinx
>> years on end to make their tools multithreaded? There is no excuse for
>> this. I assume the tools are written in C/C++. Cross platform C/C++
>> threading libraries make thread management and synchronization easy
>> (see boost.org).
>> 2. Use a different algorithm. I understand that the tools currently
>> rely on simulated Annealing algorithms for placement and routing. This
>> is probably a fine method historically, but we are arriving at the
>> point where all paths are constrained and the paths are complex (not
>> just vast in number). If there is no value in approximation, then the
>> algorithm loses its value.  Perhaps it is time to consider a Branch and
>> Bound algorithm instead. This has the advantage of being easily
>> threadable.
>> 3. SIMD instructions are available on most modern processors. Are we
>> taking full advantage of them? MMX, SSE1/2/3/4, etc.
>> 4. Modern compilers have much improved memory management and
>> compilation over those of previous years. Also, the underlying
>> libraries for memory management and file IO can have a huge impact on
>> speed. Which compiler are you using? Which libraries are you using?
>> Have you tried the latest PathScale or Intel compilers?
>> 5. In recent discussions about the speed of the map tool, I learned
>> that it took an unearthly five minutes to simply load and parse a 40MB
>> binary file on what is considered a fairly fast machine. It is
>> obviously doing a number of sanity checks on the file that are likely
>> unnecessary. It is also loading the chip description files at the same
>> time. Even still, that seems slow to me. Can we expand the file format
>> to include information about its own integrity? Can we increase the
>> file caches? Are we using good, modern parser technology? Can we add
>> command line parameters that will cause higher speed at the cost of
>> more memory usage and visa-versa? Speaking of command line parameters,
>> the software takes almost three seconds to show them. Why does it take
>> that long to simply initialize?
>> 6. Xilinx's chips are supposedly useful for acceleration. If so, make
>> a PCIe x4 board that accelerates the tools using some S3 chips and
>> SRAM. I'd pay $1000 for a board that gave a 5x improvement. (okay, so
>> that is way less than decent simulation tools, I confess I'm not
>> willing to pay big dolla....)
>> 7. Is Xilinx making its money on software or hardware? If it is not
>> making money on software, then consider making it open source. More
>> eyes on the code mean more speed.
>>
>> Sincerely,
>> An HDL peon
> 



Article: 109813
Subject: Re: nicer code => slower code??
From: "Marlboro" <ccon67@netscape.net>
Date: 5 Oct 2006 13:16:29 -0700
Links: << >>  << T >>  << A >>

burn.sir@gmail.com wrote:
> Mike Treseler wrote:
> > burn.sir@gmail.com wrote:
> >
> > > Would this go away if I somehow "flattened" my design?
> >
> > I would back out the changes one at a time
> > to find the culprit. Maybe adding the entities
> > created a pipeline stage somehow.
> > Also check the rtl viewer.
> >
> >    -- Mike Treseler
>
>
> Actually, both designs are _indentical_. I know that because we have
> some
> really tough tests for them. In addition, I spent 3-4 hours manually
> inspecting the code, the tests and all the simulation logs..
>
>
>
> What happened is that the synthesis tool stopped optimising after
> a certain depth. At least, that is my theory...
>
>
> burns

Just curiosity, have you been able to re-route the old design and got
the same result as before?


Article: 109814
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: ghelbig@lycos.com
Date: 5 Oct 2006 13:27:28 -0700
Links: << >>  << T >>  << A >>
Just wondering here...

What platform are you running the tools on?

I benchmarked several chip design tools on 'doze and 'nix.

If the tool stayed inside physical memory, they ran at about even
speeds.

I found that once physical memory was exhausted, the 'nix variant would
run at least 10x faster.  An hour-plus simulation would finish in under
5 minutes.

I traced the difference to the memory manager.  In the 'doze variant,
less than 10% of the processor was left for the application to use
while the swapper was running.

This may have changed in the last couple of years, but I doubt it.

GH


Article: 109815
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: "Brannon" <brannonking@yahoo.com>
Date: 5 Oct 2006 13:28:47 -0700
Links: << >>  << T >>  << A >>
> I have to wonder whether the writer of this letter looked at his own
> design for the reasons PAR was taking too long.  Did he keep the levels
> of logic to a reasonable number for his desired timing target?  Did he
> duplicate logic to reduce high fanout nets?  Did he try any
> floorplanning for critical parts of the design?  Somehow I doubt it, yet
> those things can make a several orders of magnitude difference in the
> time to run PAR.

My logic and fannouts are fine. I confess, though, that I have never
done floorplanning. I wouldn't even know where to start with it. I
don't even know what level floorplanning is done at. I rarely use XST;
I use my own EDIF generation tools. The tools I use tile out vast
amounts of logic recursively; attaching location constraints to them is
quite difficult (their names change each compile, the flattened logic
does not always look the same, etc.). My impression was that
floorplanning required constraints at some level and that it is
difficult using XST as well. Is that not true? I don't doubt that my
top-level tool choice is hindering my ability to take full advantage of
the Xilinx tools. How much time would it take to do a floorplan on a
four million gate project? At what stage during the development process
do you do it? I'm trying to increase my development time, not my
retargetability time.


Article: 109816
Subject: Re: logic analyzer signal tap 2 - writing data
From: "Subroto Datta" <sdatta@altera.com>
Date: 5 Oct 2006 13:45:03 -0700
Links: << >>  << T >>  << A >>
Hello David,

You can use the TCL interface to automate the memory update.  Use
quartus_sh --qhelp to get the help on the "insystem_memory_edit" TCL
package.  This package is only available in the shell provided by
quartus_stp.exe.

If you are using an external logic analyzer, you can install the free
small standalone programmer
(https://www.altera.com/support/software/download/programming/quartus2/dnl-=
quartus2_programmer.jsp)
with SignalTap II on the logic analyzer.  This package includes the
quartus_stp.exe executable.  If you are using SignalTap II Logic
Analyzer, the acquisition can be started in quartus_stp.exe as well
using the TCL command from the "stp" package.

Hope this helps,
Subroto Datta
Altera Corp.


On Oct 5, 1:54=C2=A0am, "david" <1024.da...@gmail.com> wrote:
> hello
> thank you for your replay
>
> we allready tried this option before, but we have a problam, because we
> need to modify the data in the memory while the system is runing ( the
> in system memory size is to small for ower application), every 512
> clock cycles.
> can we update the memory automaticly with new data from predefine files
> (hex files) while the system is runing? (it's not practiclly to rewrite
> manually every 512 clocks cycles, we need the system to run at least
> for 32768 clock cycles continusly, we can spend clock cycles as need to
> rewrite the content of the memory)
>
> thanks
> david
>
> Subroto Datta =D7=9B=D7=AA=D7=91:
>
>
>
> > It is definitely possible to update the memory and constants in a progr=
ammed
> > device from Quartus using the In System Memory Content Editor. Details =
can
> > be found at:
>
> >http://www.altera.com/literature/hb/qts/qts_qii53012.pdf
>
> > You can use this in conjunction wiith SignalTap II Embedded logic analy=
zer
> > to debug your work.
>
> > Hope this helps,
> > Subroto Datta
> > Altera Corp.
>
> > "david" <1024.da...@gmail.com> wrote in message
> >news:1159976602.300018.42380@e3g2000cwe.googlegroups.com...
> > > hello
> > > i am a student, working on development kit nios 2 cyclone edition.
> > > i want to use the logic analyzer to import data to the fpga from the
> > > logic analyzer, can i do it?- Hide quoted text -- Show quoted text -


Article: 109817
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: "Symon" <symon_brewer@hotmail.com>
Date: 5 Oct 2006 22:56:10 +0200
Links: << >>  << T >>  << A >>
Hi Brannon,
So, I guess we'd all like the tools to run faster, and you make some good 
suggestions.
However, I wonder how often you _need_ to do a PAR cycle? Please excuse me 
if I'm teaching you to suck eggs, but I just want to check you've considered 
a development process where you simulate things before PAR. This way, your 
logic errors are found in the simulator, not the real hardware. If you like 
to try stuff out as you go, maybe you could run the PAR each evening before 
heading out to the pub, that's what I sometimes do. :-)
HTH, Syms. 



Article: 109818
Subject: Open protocol USB JTAG cable
From: "goss" <goss@kaptalantoti.hu>
Date: 5 Oct 2006 13:58:14 -0700
Links: << >>  << T >>  << A >>
Hi everybody,

I'm going to build a USB JTAG cable and I don't know what protocol
should I use for communication. The only cable I can fully implement
this time is the Digilent USB cable... (according to the code of Zoltan
Csizmadia's cable server project)
I was trying to reverse engineer Xilinx's USB Platform cable protocol,
but after a point I gave up. (Mostly becouse the firmware of the cable
is shipped with the PC software, so they can easily modify the protocol
in the new version of ISE)

So, some questions:
Is Digilent's protocol free to implement in my device?

Is there any cable with open protocol? (with a GPL like license)
If exists an open protocol cable, is this well supported by
applications?

Thanks,
 goss


Article: 109819
Subject: Re: BSD indi processor IP compiles at 386 LEs (MAX II)
From: "jacko" <jackokring@gmail.com>
Date: 5 Oct 2006 14:06:23 -0700
Links: << >>  << T >>  << A >>

jacko wrote:
> hi
>
> 283 LEs
> 6% Cyclone II EP2C5T144C6
> 44 Warnings
> Still unverified.

just retargeted to MAX II to see how it went. looks good.
386LEs
17% MAX II EPM2210F256C3

> yes got it to compile at last after discovering a bit more about buses
> and naming of them.
>
> TEST16 toplevel object schematic encapsulates the indi16 with reset
> logic and tristate databus, to connect with external pins on the chip.
>
> Hopefully not a lot more editing needs to be done for the basic design,
> and i am now in a position to start puting together more architecture
> documentation.
>
> cheers
>
> p.s. the cpu is suitable for having a C compilier written for it and
> will not be limited to forth.
>
> http://indi.joox.net
> http://indi.microfpga.com
> http://indi.hpsdr.com
> 
> all three url work but some do not have directory listing yet.


Article: 109820
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: "Brannon" <brannonking@yahoo.com>
Date: 5 Oct 2006 14:15:09 -0700
Links: << >>  << T >>  << A >>
When I was using VCS to simulate complicated stuff before, it took
several hours per run. I agree that the output was infinitely more
useful. However, have you seen the prices on such EDIF tools? You can
run a lot of 10 minute comiples before you pay for a $10k piece of
software. And that's a cheap one.

Symon wrote:
> Hi Brannon,
> So, I guess we'd all like the tools to run faster, and you make some good
> suggestions.
> However, I wonder how often you _need_ to do a PAR cycle? Please excuse me
> if I'm teaching you to suck eggs, but I just want to check you've considered
> a development process where you simulate things before PAR. This way, your
> logic errors are found in the simulator, not the real hardware. If you like
> to try stuff out as you go, maybe you could run the PAR each evening before
> heading out to the pub, that's what I sometimes do. :-)
> HTH, Syms.


Article: 109821
Subject: Re: Virtex-5 FX when ?
From: "Jon Beniston" <jon@beniston.com>
Date: 5 Oct 2006 15:11:50 -0700
Links: << >>  << T >>  << A >>

Antti wrote:
> to my surprise I just heard comments about Xilinx giving up hard
> processor cores - well I think its not so, and that V5-FX has PPC440
> cores in it, but isnt it about time that there would be some
> information update when V5FX is actually coming?

Hang on... I'm still waiting for the V4 FX line to be fully rolled
out..

Cheers,
Jon


Article: 109822
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: "Anonymous" <someone@microsoft.com>
Date: Thu, 05 Oct 2006 22:26:14 GMT
Links: << >>  << T >>  << A >>
I would settle for an incremental compile that worked without me spending
more time screwing with that then it takes to just do a fresh compile each
time. There's no reason that changing one pin assignment or one DCM
parameter should cost 10 minutes time.

You can talk about simulation ahead of time but (a) that doesn't work too
well when you're doing signal processing, it would take me a month to build
a testbench that would tell me what five minutes of a live system tells me
and (b) when it comes to integration time there are always nits and nats
that have to be tweaked (wrong pin assignment, CE to a chip is wrong
polarity, etc.) .

-Clark



Article: 109823
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: Ray Andraka <ray@andraka.com>
Date: Thu, 05 Oct 2006 18:36:17 -0400
Links: << >>  << T >>  << A >>
Brannon wrote:

>>I have to wonder whether the writer of this letter looked at his own
>>design for the reasons PAR was taking too long.  Did he keep the levels
>>of logic to a reasonable number for his desired timing target?  Did he
>>duplicate logic to reduce high fanout nets?  Did he try any
>>floorplanning for critical parts of the design?  Somehow I doubt it, yet
>>those things can make a several orders of magnitude difference in the
>>time to run PAR.
> 
> 
> My logic and fannouts are fine. I confess, though, that I have never
> done floorplanning. I wouldn't even know where to start with it. I
> don't even know what level floorplanning is done at. I rarely use XST;
> I use my own EDIF generation tools. The tools I use tile out vast
> amounts of logic recursively; attaching location constraints to them is
> quite difficult (their names change each compile, the flattened logic
> does not always look the same, etc.). My impression was that
> floorplanning required constraints at some level and that it is
> difficult using XST as well. Is that not true? I don't doubt that my
> top-level tool choice is hindering my ability to take full advantage of
> the Xilinx tools. How much time would it take to do a floorplan on a
> four million gate project? At what stage during the development process
> do you do it? I'm trying to increase my development time, not my
> retargetability time.
> 

The time spent doing floorplanning depends on how hierarchical your 
design is and whether you take advantage of the hierarchy while doing 
your floorplanning.  In your case, it sounds like you are building a 
design out of nearly identical (?) tiles, each comprised of xilinx 
primitives.  If that is the case, yours is an ideal candidate for 
floorplanning, as it is fairly easy to add the placement constraints to 
the edif netlist at the time of compilation.  Most of my floorplanning 
is done in the source where I floorplan the elements at that 
hierarchical level.  When I get to the top level design, the 
floorplanning amounts to placing a relatively small number of pre-placed 
tiles.

The levels of logic and fanouts comment is relative to your projected 
speed.  The more slack you have there, the faster the tool will 
complete.  If the timing is tight, then it takes the tool much longer. 
Also, the automaticplacer is notoriously bad at a few things: 1) 
placement of multiplier and BRAM blocks, 2) placement of data width 
elements (ie it doesn't line up the bits horizontally in a chain of 
adders), and 3) placing LUTs that don't have registers between 
them...i.e. if you have two levels of logic between flip-flops, the 
second lut (the closest to the next flip-flop) is placed well, but the 
LUT feeding a LUT is often placed far away.  This absolutely kills 
timing, and it takes the tool a very long time to anneal the LUTs back 
to a reasonable location.  Keeping logic to one level between flip-flops 
or hand placing the LUTs solves that.  Unfortunately, the LUT names and 
logic distribution over a LUT tree is the stuff that changes the most 
from synthesis run to synthesis run, so floorplanning LUT locations in 
multi-level logic is probably the hardest part of floorplanning.

Article: 109824
Subject: Re: a clueless bloke tells Xilinx to get a move on
From: Ray Andraka <ray@andraka.com>
Date: Thu, 05 Oct 2006 18:39:05 -0400
Links: << >>  << T >>  << A >>
Brannon wrote:

> When I was using VCS to simulate complicated stuff before, it took
> several hours per run. I agree that the output was infinitely more
> useful. However, have you seen the prices on such EDIF tools? You can
> run a lot of 10 minute comiples before you pay for a $10k piece of
> software. And that's a cheap one.
> 
> Symon wrote:

  You might look at the Aldec simulator.  The version I use does mixed 
language simulation including edif netlists.  I don't know the current 
price, but I believe it is still well under $10K.



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