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 85775

Article: 85775
Subject: Re: Memec S3-1500 board + P160 comms 2
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Thu, 16 Jun 2005 12:22:05 +1000
Links: << >>  << T >>  << A >>

I wrote:

> I wrote:
> 
>> However, when placed in this slot the P160 MAC phy_rx_d<3> pin, defined
>> as 3.3V LVCMOS, connects to FPGA pin AD13 which is on the same IO bank
>> as most of the main board's DDR signals (2.5V SSTL)  e.g.:

> Any ideas on how I might get past this?  I could fudge the IOSTD 
> constraints to force it to map, but intermixing 2.5V FPGA pins with 3.3V 
> signals seems like a bad idea.

Hmm, perhaps I should stop talking to myself so much.

Anyway, a very helpful Insight engineer has helped to resolve this one. 
  It's just a case of changing the IOSTD constraint to LVCMOS25, and 
trusting the source termination resistors on the P160 module to 
sufficiently reduce the 3.3V driving voltages down to the IO's 
clamping/protection thresholds.  This Xilinx answer says more:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?BV_UseBVCookie=yes&getPagePath=20492

Cheers,

John



Article: 85776
Subject: Re: Availability of Spartan3
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 15 Jun 2005 20:06:31 -0700
Links: << >>  << T >>  << A >>


sean wrote:
> > Is this from UMC or Toshiba? Or Both?
>
> Will the current specifications be maintained? Or is there a new
> specification to deal with the change in process/FAB?

Whether the parts are made by UMC or Toshiba (Spartan3 is not), and
whether they were born on a 200 mm or a 300 mm wafer is of no concern (
or should be of no concern) to the average user. All these parts have
to meet (and do meet) the data sheet specification.
But since there are (albeit minute) process differences and different
mask sets involved, we have to do new qualification tests ( like static
discharge) on all pins and on all internal functions. And that takes
time.
Having multiple fabs is common these days, not only for ICs, also for
raw materials, food stuff, machinery, automobiles, household goods,
books and magazines, etc. Whether a particular car is assembled in
Michigan, Canada, or Ohio should not be a major concern for the buyer.
But when you buy a whole fleet of them, you may be interested, perhaps
for reasons of consistency and tracability.

IC  mask sets and wafer sizes went through many rapid changes over the
previous decades, and few buyers were concerned, as long as the specs
were met. And the IC supplier had a lot of latitude. Now we have far
less freedom, since a smaller-geometry process automatically means a
lower supply voltage, and thus a completely new part number. In the 5-V
era, we all used to make lots of changes without telling you, unless
you were a big corporate customer. Guess how many fabs and mask
revisions Intel has on their Pentiums?  (Pentia?)

In other words, no user should be concerned about the wafer diameter.
We just try to abide by self-imposed rules. (And they, unfortunately,
led to the artificial scarcity).
Peter Alfke, from home.


Article: 85777
Subject: convert vhdl to edif
From: "Narayan" <narayan.subramanian@gmail.com>
Date: 15 Jun 2005 20:39:10 -0700
Links: << >>  << T >>  << A >>
hi all,

 I am trying to find some means of converting a design described as a
vhdl code to edif file. I am using xilinx tool set (from entry to
device programming). Are there any other tools that can do the same
job.

Thanks!
Narayan


Article: 85778
Subject: Re: Availability of Spartan3
From: rickystickyrick@hotmail.com
Date: 15 Jun 2005 21:30:50 -0700
Links: << >>  << T >>  << A >>


Whether the long leads time have been artificially created by Xilinx or
not I would strongly suggest anyone using Spartan3s to check with their
distributor.

It isn't pretty.

Ricky

> In other words, no user should be concerned about the wafer diameter.
> We just try to abide by self-imposed rules. (And they, unfortunately,
>led to the artificial scarcity).


Article: 85779
Subject: Re: convert vhdl to edif
From: Jeremy Stringer <jeremy@_NO_MORE_SPAM_endace.com>
Date: Thu, 16 Jun 2005 16:45:16 +1200
Links: << >>  << T >>  << A >>
Narayan wrote:
>  I am trying to find some means of converting a design described as a
> vhdl code to edif file. I am using xilinx tool set (from entry to
> device programming). Are there any other tools that can do the same
> job.

Synplify will also do it...  I don't think that's the answer to your 
ultimate question though.  What are you trying to do?

Jeremy

Article: 85780
Subject: Re: EDK 7.1 installation error: Missing libPortability.dll file
From: Sean Durkin <smd@despammed.com>
Date: Thu, 16 Jun 2005 07:14:29 +0200
Links: << >>  << T >>  << A >>
Nju Njoroge wrote:
> I found out what the issue was:
> [...snip...]
> Fix: Make sure PATH variable has %XILINX%\bin\nt in it.
OK, good to know. I *KNEW* it was something with the path :)=

cu,
Sean

Article: 85781
Subject: Re: Availability of Spartan3
From: "User" <tech3@cavelle.com>
Date: 15 Jun 2005 22:16:03 -0700
Links: << >>  << T >>  << A >>
Dear (current) Xilinx user,

We design boards that are manufactured in quantity elsewhere, and we
depend on easy and quick availability of prototype and pre-production
quantities.  Particularly for FPGAs, where there are multiple parts in
identical packages, we often need to try one size up (for capacity) or
one size down (for cost) quickly.  We also build small runs of boards
for customer approval, always on short turn-around.

The message from Xilinx seems to be that they don't want to bother with
anyone that is not also directly responsible for the manufacture (i.e.
have the distribution relationships).  Spartan 3 parts were formerly
available even in pre-production quantities through the web store, and
it offered excellent service (so good it was definitely a plus factor
in designing in Xilinx parts).

Without the web store, there are today exactly zero distributors that
currently have, or can obtain in any reasonable time, the Spartan 3
parts we are using.  This is true whether it is from a 200mm fab or
300mm fab.  I'm sure with a good distribution relationship there are
strings that could be pulled to get something more quickly. However,
I'm not sure why we would want to spend time and use up favors for
something that should be readily available overnight in small
quantities.

It is a week since Xilinx's own representative said he would try and
find out if/when the product would be available, and no news looks like
very bad news.  To cut off supply with no notice, and fail to make any
reasonable arrangements with alternative distribution, makes us nervous
about continuing to incorporate Xilinx parts even if they do sort this
situation out. Our customers expect us to select components from
reliable suppliers that won't change the rules in the middle of the
game.

Despite their persistent enthusiasm, we have always declined to meet
with our local Altera rep because, despite the odd hiccup, we were
pretty satisfied with the Xilinx solution.  My understanding is that
Altera are more committed to multiple distribution channels and
generally superior product availability (any satisfied / dissatisfied
Altera purchasers out there to comment?).

While hoping that the Xilinx situation will improve quickly and
dramatically, past experience with semiconductor suppliers that take
their eye off the ball is that one bad decision is quickly followed by
others, and it is wise to start looking at alternatives.


Article: 85782
Subject: MINI PCI card for testing FPGA MINIPCI core
From: stud_lang_jap@yahoo.com
Date: 15 Jun 2005 22:45:14 -0700
Links: << >>  << T >>  << A >>
Hello Guys,
I am integrating an MiniPCI core on virtex 2 pro fpga. In order for me
to test the core i need an MINI card. Can i use any Mini card for
testing or is any special mini card for testing.

If not can anyone plz suggest how can i test the miniPCI core.

Thanks and Regards
Williams


Article: 85783
Subject: Re: Availability of Spartan3
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 15 Jun 2005 23:04:00 -0700
Links: << >>  << T >>  << A >>
We have admitted our sins, we have suggested a relatively simple
work-around (the 0974 suffix to the order code), and I can assure you
that there are strong efforts underway to correct this untenable
situation, as fast as we can. The ugly comments in this newsgroup have
been relayed to the highest (and also the lower) levels of management,
and there will be action. You have been heard, and you were right. I
have used pretty strong language internally, and I expect things to
change. 
It just takes more than a few days...
Peter Alfke, from home.


Article: 85784
Subject: Deisgn partitioning issues
From: "Neo" <zingafriend@yahoo.com>
Date: 15 Jun 2005 23:11:58 -0700
Links: << >>  << T >>  << A >>
Hi comrades,
I am into hardware design and eventhough I have designed for many
components and modules one question always bugs me. How do we go about
determining the partition of a design, say some device controller. In
case of interfaces like control blocks to memories or fifos the
interface and fucntionality is quite clear. But what about the
interfaces when we partition a design in to sub-blocks. Is there an
optimum way to partition the design and also minimize the interface
details between them.


Article: 85785
Subject: Re: Pissed off with Xilinx - Spartan 3 [The Rest of the Story]
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 15 Jun 2005 23:12:15 -0700
Links: << >>  << T >>  << A >>
Steve Knapp explained: Append 0974 to the order code, and every
distributor should be able to quote  short leadtimes. If not, contact a
better distributor. They are not Xilinx employees, but rather
independent businessmen. Xilinx has lots and lots of parts, especially
of the 3S200. This is just a logistical snafu, not a real availability
problem.
Sorry for the confusion.
Peter Alfke


Article: 85786
Subject: Re: Help with USB cable, Xilinx XUP board, Linux FC3 and EDK
From: "Kris Heyrman" <kh@club.innet.be>
Date: 15 Jun 2005 23:24:28 -0700
Links: << >>  << T >>  << A >>
Hi,

The problem is solved. The last problem was due to the SELinux policy
that Fedora Core 3 enforces. It shows up in /var/log/messages as:
Jun 16 07:50:40 localhost kernel: audit(1118901040.916:0): avc:  denied
 { execmod } for  pid=5234 comm=impact
path=/home/krish/binaries/Xilinx/bin/lin/libSTL.so dev=hda2 ino=4394222
scontext=user_u:system_r:unconfined_t
tcontext=root:object_r:user_home_t tclass=file

To temporarily evade this, you can

# sudo setenforce 0

and later,

#sudo setenforce 1

The problem is (probably) caused by the fact that the ``offending''
library libSTL.o should have been compiled with -fPIC
(position-independent code). It is described for similar cases - but
not impact - in the Red Hat bug database and can be solved permanently
by reading the
Fedora Core 3 SELinux FAQ and working around the enforcing.

Much tx for everybody who helped,

Kris Heyrman


Article: 85787
Subject: Re: Availability of Spartan3
From: "Antti Lukats" <antti@openchip.org>
Date: Thu, 16 Jun 2005 08:46:24 +0200
Links: << >>  << T >>  << A >>
"Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag
news:1118901840.407859.104810@z14g2000cwz.googlegroups.com...
> We have admitted our sins, we have suggested a relatively simple
> work-around (the 0974 suffix to the order code), and I can assure you
> that there are strong efforts underway to correct this untenable
> situation, as fast as we can. The ugly comments in this newsgroup have
> been relayed to the highest (and also the lower) levels of management,
> and there will be action. You have been heard, and you were right. I
> have used pretty strong language internally, and I expect things to
> change.
> It just takes more than a few days...
> Peter Alfke, from home.
>

I am sure this is will be good news.
There are many ways and reasons, but I can say one thing:

".. 'taking the S3 OFF from the web store' - this is the one thing one
should never do .."

REALLY, I mean it.

If it was possible to sell the S3 from Xilinx webstore then there can be no
reasons
explainable to the customer why it is not possible any more. The only thing
the people will
belive is that the store is not carrying them any more because there is no
silicon to sell.
Doesnt matter what the real cause is.

If the decision to put S3 to Xilinx webstore is now considered as bad
decision internally
in Xilinx, then Xilinx should still 'stick' with it that decision and keep
carrying the S3, even
if it is making too much problems.

The Digikey - thats another issue to deal with, I used to checkout Digikey
to get price
indicators and warnings on component leadtimes. The fact that there is no S3
on Digikey
at all, is alarming itself, it means either there are no requests, no
interest in S3 or there
is no silicon, or that somewhere is a major problem of some sort.

The Memec-Avnet, due to the pending purchasing of Memec by Avnet (what is
pending
the US anti-trust court approval) I would not count that Avnet or Memec is
very interested
in anything, Memec has lots of losses, and Avnet is about to pay for those,
so both of those
have internal things to solve.

And with NuHorizon as Xilinx supplier would I not count at all. So all that
together -
it is quite understandable that customers have BIG concernes on the
availability and
about the overall situation with S3 (and other Xilinx silicon)

Antti's
5 cents to the story...



Article: 85788
Subject: LUT, how to?
From: "Giox" <giovanniparodi79@yahoo.it>
Date: 16 Jun 2005 00:25:31 -0700
Links: << >>  << T >>  << A >>
Hello everybody, I'm a newbye in FPGA so I need some help in a simple
problem.
I would like to implement a 256 byte LUT on a Virtex 300 E FPGA.
Can you suggest me some on line resource that explains how to implement
this LUT, how to select the memory resources that I want use for this
task etc?
Thanks a lot for any help, Giovanni


Article: 85789
Subject: Re: Auto pipeline logic??
From: "Ben Jones" <ben.jones@xilinx.com>
Date: Thu, 16 Jun 2005 09:05:12 +0100
Links: << >>  << T >>  << A >>
> : Well, inserting registers changes your design in a fundamental way.
> : Most circuits I can think of would just stop working if you added
> : registers to them at random. Only you, the designer, know exactly
> : how much pipelining it is legal to apply to a given part of your
> : circuit. So I don't believe such a tool exists - certainly not in the
> : general case.
> This is very true, but there's no reason a designer couldn't specify a
> bunch of signals (e.g. the data signal from a combinatorial multiply and
> associated control signals) and some tool would add aribtrary (to a user
> specified limit) stages of pipelining to all signals to meet timing, with
> logic/register shuffling.  This would only work the control and data flows
> can be aribtrarily pipelined, but many ops can be described this way/

True, although I don't see much merit in doing it that way. In FPGAs, the
pipeline registers are essentially free (because they're there after every
LUT, even if you don't use them). So you don't get much advantage from
"just" meeting timing - if you have four clock cycles do do something in,
then you might as well take all four - who cares? You'll get better results
out of the tools that way, too.

Of course, if you *do* care about the latency of your operations and you
want to minimize it, then you're already thinking in enough depth about your
design that an automated tool would be unnecessary.

Cheers,

        -Ben-

P.S. Whenever someone says "automated tool" I immediately envisage a smug
paperclip: "I see you're trying to close timing - would you like some help
with that?" This of course means that all my subsequent utterances on the
subject can be safely disregarded. :-)



Article: 85790
Subject: Re: VHDL Synthesis tutorial
From: Mike Harrison <mike@whitewing.co.uk>
Date: Thu, 16 Jun 2005 08:32:21 GMT
Links: << >>  << T >>  << A >>
On 15 Jun 2005 02:46:53 -0700, "himassk" <himassk@gmail.com> wrote:

>
>  Hi,
>     Can any body help me by giving website address or info
>  about VHDL synthesis coding techniques.
>
>  Thank u.
>
>   Hima.

http://toolbox.xilinx.com/docsan/xilinx4/data/docs/sim/preface.html

Article: 85791
Subject: Re: LUT, how to?
From: "Neo" <zingafriend@yahoo.com>
Date: 16 Jun 2005 01:52:11 -0700
Links: << >>  << T >>  << A >>
the tool will automatically infer distributed ram if you can do without
a reset.


Article: 85792
Subject: Re: LUT, how to?
From: "Giox" <giovanniparodi79@yahoo.it>
Date: 16 Jun 2005 03:27:52 -0700
Links: << >>  << T >>  << A >>
can you provide me some reference to the documentation that documents
that?
Moreover a LUT of 256 byte has an acceptable size or is too big?
I know this is a stupid question, but I'm a newbye
Thanks a lot


Article: 85793
Subject: Idea exploration - Image stabilization by means of software.
From: "Kris Neot" <Kris.Neot@hotmail.com>
Date: Thu, 16 Jun 2005 18:40:37 +0800
Links: << >>  << T >>  << A >>
Basically let the camera take it's picture though user's hand is shaky, and
use a
mechanism to record down the angle of user's handshake in steps of 1us, now
I get V = [v0, v1, ...v(n-1)]; With this vector, I calculate displacement
vector
the image has moved in terms of number of pixels P.

Assume the image sensor's voltage rises linearly w.r.t exposure time (or any
charactized waveform).

I slice the image into n slices by dividing each pixel's RGB data into RGB/n
(depending on the waveform of the sensor's characters), and use a technique
similar to the motion compensation, move the slices according to
displacement
vector P and add them together to reconstruct final image.

How does my idea work?




Article: 85794
Subject: Re: Idea exploration - Image stabilization by means of software.
From: Jan Panteltje <pNaonStpealmtje@yahoo.com>
Date: Thu, 16 Jun 2005 11:18:27 GMT
Links: << >>  << T >>  << A >>
On a sunny day (Thu, 16 Jun 2005 18:40:37 +0800) it happened "Kris Neot"
<Kris.Neot@hotmail.com> wrote in <42b15483$1@news.starhub.net.sg>:
These systems (software stabilization) are already in many consumer video
cameras.
There are also stand alone (MS windows) programs that will stabilize an
existing shaking recording.


>Basically let the camera take it's picture though user's hand is shaky, and
>use a
>mechanism to record down the angle of user's handshake in steps of 1us, now
You will at best get a set of motion vectors per frame, so 1us makes no sense?
Think 40mS (@25fps).

>I get V = [v0, v1, ...v(n-1)]; With this vector, I calculate displacement
>vector
>the image has moved in terms of number of pixels P.
And of cause mpeg2 encoding already gives us these vectors for free.

>Assume the image sensor's voltage rises linearly w.r.t exposure time (or any
>charactized waveform).
I do not see what motion in one direction or an other has to do with exposure
time.
Exposure time has to do with how much sensitivity you have to light.
Of cause when your exposure time get freaky long, you get motion blur.


>I slice the image into n slices by dividing each pixel's RGB data into RGB/n
>(depending on the waveform of the sensor's characters), and use a technique
>similar to the motion compensation, move the slices according to
>displacement
>vector P and add them together to reconstruct final image.
I have lost you here.


>How does my idea work?
What idea?


Article: 85795
Subject: Re: Synplify vs XST...
From: "Adarsh Kumar Jain" <adarsh.jain@cern.ch>
Date: Thu, 16 Jun 2005 14:24:30 +0200
Links: << >>  << T >>  << A >>
I was recently evaluating Synplify Pro as i was getting pushed to the corner
in terms of area usage on the XC2VP7.
This is what i found:

The comparison is not EXACT since there are probably some differences in the
design constraints, but it certainly gives a fair idea. The designs are
constrained for 40 MHz System Clock. (but the comparison is also valid for
80 MHz, as in my opinion, either frequency is on the low end of what these
devices can handle).

Also, not ALL the error checking is implemented.

Resource                                     ISE6.3sp3             Synplify
8.0

Flip Flops                                     4170
3945

4 Input LUTs (Logic)                 5503                           3923

4 Input LUTs(Route-thru)            814                            309

4 Input LUTs(Total)                  6318                          4232

Occupied Slices                           4075                          3330
4928(Total)   (Overall 15 % Savings !!!)



The comparison is not EXACT since there are probably some differences in the
design constraints, but it certainly gives a fair idea. The designs are
constrained for 40 MHz System Clock.

i agree its not a "fair" comparison as i was using ise6.2sp3 vs Synplify
8.1.

cheers,

adarsh







"B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com> wrote in message
news:pan.2005.06.13.21.58.40.8091@PleaseDontSpamMEpolybus.com...
> On Mon, 13 Jun 2005 20:51:55 +0000, Joseph H Allen wrote:
>
> > In article <3h3o19Ff6phbU1@individual.net>,
> > Falk Brunner <Falk.Brunner@gmx.de> wrote:
> >>"Austin Franklin" <austin@dark99room.com> schrieb im Newsbeitrag
> >>news:911re.4452$Ub4.3176@fe06.lga...
> >
> >>> > I used Synplify for many years but I haven't used it recently. I
> >>> > switched to XST about a year ago when it got to the good enough
level.
> >>> > XST improves with each release, my gut says that it's pretty close
to
> >>> > Synplify's level at this point.
> >
> >>Recently, I had a design, not really a big deal. Running at 36 and 72
MHz.
> >>XST was not able to squeeze it into a XC2S50E, but Synplify was. (~1600
LUTs
> >>to ~ 1200 LUTs). Speed was not the problem, both implementation where
fast
> >>enough. But Synplify was more area efficient.
> >>We are using XST only, this was just a test with a real case.
> >
> > I'm having the same experience: Synplify_pro 8.1 uses 97% (map with -tx
on)
> > of an XC2V6000 (which "map" with "-tx on -timing" actually can close
timing
> > on), whereas XST 5.2 uses 102% (no -tx on).  I think Synplify's CSE (or
> > "resource sharing") is better.  The difference in price between an
XC2V8000
> > and an XC2V6000 more than covers Synplicity's fee.  On the other hand,
XST
> > and Synplicity seem to be on par as far as the resulting design's speed.
> >
> > One big annoyance: attributes use a completely different concept between
the
> > two tools: Synplicity, following verilog tradition, associates
attributes by
> > position within a comment before the ; of an instantiation.  XST follow
VHDL
> > and associates them by name: the comment can be anywhere in the file.
But
> > now that I have my conversion script, this is no big deal.  XST uses
> > data_bus<1> and Synplicity uses data_bus[1].  XST flattens the
hierarchy,
> > Synplicity doesn't (earlier versions used to).  All of this makes the
.ucf
> > file fun.
> >
> > We are not using later versions of XST due to answer record #16808
(casex
> > doesn't always make correct code)- I'd like to try 7.1i, but it wont
work on
> > RedHat 7.3.  Synplify 8.1 (their latest) does work in RedHat 7.3. Also
code
> > errors which XST 5.2 allows cause XST 6.1 - 6.3 to core dump- which
makes it
> > difficult to find the error.  Note that we have to run XST 5.2i in wine
(but
> > we then run place & route with 6.2isp3).
> >
> > Other issues: synplicity runs about 33% faster, but sometimes for larger
> > designs it is much faster.  I think we are hitting some exponential time
> > algorithm in XST.
> >
> > The error reporting from Synplify is much better than XST:
> >
> > // XST gives no error
> > output [5:0] foo;
> > reg [4:0] foo;
> >
> > // XST gives no error: two always blocks writing to the same signal when
the
> > // signal gets optimized out because nobody is readying it.
> > reg x;
> >
> > always @(posedge clk or negedge reset_l)
> >   if (!reset_l)
> >     x <= 0;
> >
> > always @(posedge clk or negedge reset_l)
> >   if (!reset_l)
> >     x <= 0;
> >   else
> >     x <= y;
>
> There are switches in the XST script for controlling things like hierarchy
> flattening and bus delimiters. There is an issue with case statements
> doing something unexpected if you don't have a default, the solution is to
> always have a default: in every case statement, this is the correct thing
> to do anyway.
>
> I played around with XST's switches until I was happy with the results.
> XST's switches can make a big difference in the size and speed of the
> final results. Here are the switches from one of my scripts,
>
>
> run
> -ifn loopback_m325_sma.xprj
> -ifmt Verilog
> -ofn loopback_m325_sma.ngc
> -top loopback_m325_sma
> -ofmt NGC
> -p xc2vp70-6-ff1704
> -opt_mode SPEED
> -opt_level 1
> -max_fanout 32
> -keep_hierarchy no
> -register_duplication YES
> -equivalent_register_removal no
> -hierarchy_separator /
> -bus_delimiter <>
> -mux_extract YES
> -mux_style MUXF
> -ram_extract YES
> -ram_style Auto
> -rom_extract YES
> -rom_style Distributed
> -verilog2001 NO
> -vlgcase Full-Parallel
> -decoder_extract YES
> -priority_extract YES
> -shreg_extract YES
> -shift_extract YES
> -xor_collapse YES
> -resource_sharing YES
> -iobuf NO
> -register_balancing no
> -slice_packing Yes
> -glob_opt max_delay
> -fsm_encoding Compact
>
>



Article: 85796
Subject: Re: Idea exploration - Image stabilization by means of software.
From: Hans-Bernhard Broeker <broeker@physik.rwth-aachen.de>
Date: 16 Jun 2005 12:50:35 GMT
Links: << >>  << T >>  << A >>
[X-post, F'up2 cut down by me, should have been done by you!]

In comp.arch.embedded Kris Neot <Kris.Neot@hotmail.com> wrote:

> Basically let the camera take it's picture though user's hand is
> shaky, and use a mechanism to record down the angle of user's
> handshake in steps of 1us, 

1 microsecond won't do you any good.  No human can move anything at a
frequency of 1 MHz.  

Anyway, what happens during the exposition for a single frame will be
completely impossible to correct for after the fact.  That's why some
current consumer cameras do this in a different way: they use movable
parts in the optical system to compensate shaking *before* any light
hits the sensors.  That's the only way it becomes possible to do
in-frame shake compensation.

> now I get V = [v0, v1, ...v(n-1)]; With this vector, I calculate
> displacement vector the image has moved in terms of number of pixels
> P.

Displacement alone is also useless.  You also have to take care of
rotation --- that's actually more important than displacement.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Article: 85797
Subject: Re: Availability of Spartan3
From: "MK" <nospam.please@here.ever>
Date: Thu, 16 Jun 2005 14:05:11 +0100
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> wrote in message
news:d8r7c0$eop$03$1@news.t-online.com...
> "Peter Alfke" <alfke@sbcglobal.net> schrieb im Newsbeitrag
> news:1118901840.407859.104810@z14g2000cwz.googlegroups.com...
> > We have admitted our sins, we have suggested a relatively simple
> > work-around (the 0974 suffix to the order code), and I can assure you
> > that there are strong efforts underway to correct this untenable
> > situation, as fast as we can. The ugly comments in this newsgroup have
> > been relayed to the highest (and also the lower) levels of management,
> > and there will be action. You have been heard, and you were right. I
> > have used pretty strong language internally, and I expect things to
> > change.
> > It just takes more than a few days...
> > Peter Alfke, from home.
> >
>
> I am sure this is will be good news.
> There are many ways and reasons, but I can say one thing:
>
> ".. 'taking the S3 OFF from the web store' - this is the one thing one
> should never do .."
>
> REALLY, I mean it.
>
> If it was possible to sell the S3 from Xilinx webstore then there can be
no
> reasons
> explainable to the customer why it is not possible any more. The only
thing
> the people will
> belive is that the store is not carrying them any more because there is no
> silicon to sell.
> Doesnt matter what the real cause is.
>
> If the decision to put S3 to Xilinx webstore is now considered as bad
> decision internally
> in Xilinx, then Xilinx should still 'stick' with it that decision and keep
> carrying the S3, even
> if it is making too much problems.
>
> The Digikey - thats another issue to deal with, I used to checkout Digikey
> to get price
> indicators and warnings on component leadtimes. The fact that there is no
S3
> on Digikey
> at all, is alarming itself, it means either there are no requests, no
> interest in S3 or there
> is no silicon, or that somewhere is a major problem of some sort.
>
> The Memec-Avnet, due to the pending purchasing of Memec by Avnet (what is
> pending
> the US anti-trust court approval) I would not count that Avnet or Memec is
> very interested
> in anything, Memec has lots of losses, and Avnet is about to pay for
those,
> so both of those
> have internal things to solve.
>
> And with NuHorizon as Xilinx supplier would I not count at all. So all
that
> together -
> it is quite understandable that customers have BIG concernes on the
> availability and
> about the overall situation with S3 (and other Xilinx silicon)
>
> Antti's
> 5 cents to the story...
>
>

While Xilinx are listening can I re-enforce some of Atti's comments. I'm a
freelance designer and I never buy many parts but some of my customers buy
in the 10k+ per annum range. When I get a design contract availability of
parts for prototyping is absolutely key to the design in decision.
My experience of the large distributors (other than the catalogue guys like
Farnell and Digikey) is that they just get in the way.
Suppliers with good sample/web sales systems usually win.
For examples of how to do it right check out Microchip, Linear Technology
and TI.

Michael Kellett




Article: 85798
Subject: Re: Synplify vs XST...
From: "B. Joshua Rosen" <bjrosen@PleaseDontSpamMEpolybus.com>
Date: Thu, 16 Jun 2005 09:05:48 -0400
Links: << >>  << T >>  << A >>
On Thu, 16 Jun 2005 14:24:30 +0200, Adarsh Kumar Jain wrote:

> I was recently evaluating Synplify Pro as i was getting pushed to the corner
> in terms of area usage on the XC2VP7.
> This is what i found:
> 
> The comparison is not EXACT since there are probably some differences in the
> design constraints, but it certainly gives a fair idea. The designs are
> constrained for 40 MHz System Clock. (but the comparison is also valid for
> 80 MHz, as in my opinion, either frequency is on the low end of what these
> devices can handle).
> 
> Also, not ALL the error checking is implemented.
> 
> Resource                                     ISE6.3sp3             Synplify
> 8.0
> 
> Flip Flops                                     4170
> 3945
> 
> 4 Input LUTs (Logic)                 5503                           3923
> 
> 4 Input LUTs(Route-thru)            814                            309
> 
> 4 Input LUTs(Total)                  6318                          4232
> 
> Occupied Slices                           4075                          3330
> 4928(Total)   (Overall 15 % Savings !!!)
> 
> 
> 
> The comparison is not EXACT since there are probably some differences in the
> design constraints, but it certainly gives a fair idea. The designs are
> constrained for 40 MHz System Clock.
> 
> i agree its not a "fair" comparison as i was using ise6.2sp3 vs Synplify
> 8.1.
> 
> cheers,
> 
> adarsh
>

Which switch did you use for hierarchy in XST? I've found that it does
much better if you tell it to flatten the hierarchy.


Article: 85799
Subject: Re: Idea exploration - Image stabilization by means of software.
From: Chuck Dillon <spam@nimblegen.com>
Date: Thu, 16 Jun 2005 08:58:16 -0500
Links: << >>  << T >>  << A >>
Jan Panteltje wrote:
> <snip>
> 
>>Assume the image sensor's voltage rises linearly w.r.t exposure time (or any
>>charactized waveform).
> 
> I do not see what motion in one direction or an other has to do with exposure
> time.
> Exposure time has to do with how much sensitivity you have to light.
> Of cause when your exposure time get freaky long, you get motion blur.
> 
> <snip>
> 
>>How does my idea work?
> 
> What idea?
> 

I believe he's talking about a single frame exposure not video.  He's 
talking about motion during the exposure and I assume a problem of 
varying affects of the motion on the different sensors (e.g. R,G and B) 
that combine to give the final image.

I don't have any feedback for him other than to suggest he try to state 
his problem better next time especially when cross-posting so broadly.

-- ced



-- 
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.



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