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
2017JanFebMarApr2017

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 13450

Article: 13450
Subject: Re: Xilinx FPGA configuration problems... Help!
From: peterc <peterc@hmgcc.gov.uk>
Date: Thu, 03 Dec 1998 14:39:32 +0000
Links: << >>  << T >>  << A >>
Olivier Hebert wrote:
> 
> Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
> having problems configuring the device. I'm using a master serial
> configuration (I'm trying to use the XChecker cable now, and a serial
> PROM later).
> 
> When I first power up the board, if I probe the CCLK pin with a scope, I
> get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.
> When I try to configure the device using an XChecker cable, the
> frequency of the CCLK signal goes up to something like 7 MHz, even
> though I'm using slow configuration. When I hit the PROG button on the
> board, the frequency goes back to it's normal rate (900 kHz). Of course,
> the hardware debugger says something is wrong when I try to program the
> device!
> 
> Is there something I'm doing wrong? Could the device be bad? I really
> need help on this one!
> 

You need to use SLAVE serial when using the Xchecker and MASTER serial
when using a PROM. Then it should work.
-- 
Peter Crighton

Article: 13451
Subject: Re: Will XILINX survive?
From: Richard Schwarz <aps@associatedpro.com>
Date: Thu, 03 Dec 1998 10:23:08 -0500
Links: << >>  << T >>  << A >>
I totally disagree with anyone who thinks that denser is not better. It's
like
someone asking who needs a Cray on their desk. With the advent of cores, IO
and
HDL, the future of FPGAs and programming will be one of huge resources which
can
tolerate some level of efficiency loss for the trade off of quick
development. To
the point where FPGA programming becomes more of a Software Issue, and less
of a
hardware issue. You can see the evolution already taking place. Xilinx is one

leader in that market. So is Altera, and Lucent etc.. I am glad to see the
diversity in some of the approaches and think there will be alot of growth
potential in this market. Smaller, denser devices will continue to be sought
after. Xilinx's biggest mistake (IMO) was delaying any size migration at all.
It
seems that about a year ago they were hesitating in the move downward. I
would
also look into buying Triscend if I were Xilinx. I wouldn't make it the main
focus of their business, but I think it would be a good hedge against the
other
FPGA's doing embedded cores. I think they certainly have merrit for certain
apps.



Wade D. Peterson wrote:

> Froilan P Montenegro <froilan+@andrew.cmu.edu> wrote:
>
> >  What about reconfigurable computing and systems-on-a-chip with
> >programmable logic on the same die?  Something like a processor core and
> >an FPGA on the same chip with some an interface for the two to
> >communicate with each other.  That way if you need basic general
> >processing abilities along with some custom logic, this might allow you
> >to build a smaller, cheaper, faster implementation than current
> >processor/FPGA combinations.  I'm no expert but these are two
> >possibilities I've heard.
> >
> > - Froilan
>
> I think you're right...the reconfigurable logic field is going to be
> quite exciting in the future.  From what I've seen, though, it's too
> small right now to predict what's going to happen.
>
> If I really polish my crystal ball (it's a bit rusty sometimes) I can
> see entire systems made from reconfigurable logic.  The hardware would
> be booted in much the same way as operating systems are now.  This is
> a shear fantasy at this point, but it isn't beyond the realm of
> possibilities.
>
> Wade Peterson
> Silicore Corporation



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 13452
Subject: Re: Will XILINX survive?
From: Richard Schwarz <aps@associatedpro.com>
Date: Thu, 03 Dec 1998 10:25:53 -0500
Links: << >>  << T >>  << A >>
I don't think that Marshall was the one who made the choice.



Anonymous wrote:

> This thought should be worrying not only XILINX shareholders,
> but also, - XILINX users, who have invested a lot of efforts
> and money into mastering XILINX tools.
>
> Why should we expect XILINX shutdown in the foreseeable future?
>
> 1) XILINX has started as successful innovative company and won
> essential part of the market. But that's in the past ...
> Recent history of XILINX is a sequence of disastrous failures
> to deliver satisfactory quality at reasonable price.
> Remind heart-breaking stories with 8000, 6200, 5200 series!
> Lacking new ideas, XILINX is trying to sell their old 4000
> series wrapped into Spartan envelope. And now Virtex becomes
> too late answer on Altera designs.
>
> 2) XILINX applies tremendous efforts to reduce the price and ...
> the quality of its development tools.
> It was reported by many customers in this particular newsgroup
> that XILINX Foundation is worse than XACT, and each subsequent
> version of Foundation is worse than previous.
> Currently the quality of development tools is so bad that XILINX
> almost gave up any attempts to fix endless stream of bugs.
> The bugs are just stored until next version of Foundation :
>
> 3) XILINX support service became some sort of psychoanalyst to
> keep users calm and to avoid bodily damage (and chip damage)
> caused by desperate customers. XILINX is afraid to reveal
> an obvious thing: there is no support for ALDEC software
> that constitutes the principal part of Foundation (design flow,
> schematics and simulation).
>
> 4) And now the last news:
> MARSHALL does not sell XILINX chips any more.
> Obviously, they are feeling where the things go.
>
> Good bye XILINX ...
>
> *************



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 13453
Subject: Re: Will XILINX survive?
From: Richard Schwarz <aps@associatedpro.com>
Date: Thu, 03 Dec 1998 10:33:14 -0500
Links: << >>  << T >>  << A >>
I agree with this!!!

Peter Alfke wrote:

> Wade D. Peterson wrote:
>
> > My Christmas wish list this year includes an ANSI/IEEE standard for
> > standard FPGA arcitectures.  That way all of the application and tool
> > developers could get some of their sanity back.  That would also
> > really push FPGAs into the commodity realm.  Imagine 5-10 vendors of
> > FPGAs all with a similar architecture!
> >
>
> Don't hold your breath. It worked for DRAMs because they really  have a
> simple, narrowly defined function, ( at least until recently ). And
> their business has turned into a disaster.
> FPGAs must stay more diverse, and we need competitive innovation to
> advance the state of the art. If that leads to some confusion and even
> chaos, so be it.
>
> Just look at the battle between Altera and Xilinx. It has been the
> driving force that brought you better, bigger and faster devices at an
> incredibly fast pace.
>
> Americans like competition, and everybody wants to win.
>
> Standardization would kill innovation and turn these FPGA houses into
> drab commodity factories that compete on nothing but price.
>
> Not my idea of fun.
>
> Peter Alfke



--
__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/

    Richard Schwarz, President
    Associated Professional Systems Inc. (APS)
    email: richard@associatedpro.com
    web site: http://www.associatedpro.com
    Phone: 410-569-5897
    Fax:   410-661-2760

__/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/ __/


Article: 13454
Subject: Re: Will XILINX survive?
From: z80@ds2.com (Peter)
Date: Thu, 03 Dec 1998 15:55:36 GMT
Links: << >>  << T >>  << A >>

My concern, however, would be whether these better, bigger and faster
devices introduced at an incredibly fast pace are going to have the
lifetime of the older devices such as the 3k and 4k family. This is
quite relevant to industrial products which tend to have long
lifetimes. I realise you people like to have "fun" but there is
clearly a tradeoff there.

Xilinx have a good record for maintaining production of "old" parts
and I wonder if this will continue.

>Just look at the battle between Altera and Xilinx. It has been the
>driving force that brought you better, bigger and faster devices at an
>incredibly fast pace.
>
>Americans like competition, and everybody wants to win.
>
>Standardization would kill innovation and turn these FPGA houses into
>drab commodity factories that compete on nothing but price.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.

Article: 13455
Subject: Re: Minimum clock freq reqd
From: iachetta@us.ibm.com (Richard Iachetta)
Date: Thu, 3 Dec 1998 12:04:27 -0600
Links: << >>  << T >>  << A >>
In article <743q9t$sl1$1@nnrp1.dejanews.com>, shailbains007@my-dejanews.com 
says...
> What factors would determine the *lowest* clock frequency that can drive a
> given digital circuit? (I can very well understand the existence of a an
> upper limit.)

Chips that use PLLs to generate internal clocks have a lower frequency 
limit due to PLLs having lower frequency limits (unless a PLL bypass mode 
is provide as is sometimes the case).

-- 
Rich Iachetta
iachetta@us.ibm.com
I do not speak for IBM.

Article: 13456
Subject: Re: XILINX FPGA reaches GHz speeds
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Thu, 03 Dec 1998 10:33:55 -0800
Links: << >>  << T >>  << A >>
Joseph H Allen wrote:
> 
<snipped>
> What is LVPECL and LVDS?  I've heard of LVTTL, but not any of these others.
> Are they ASIC I/O options or something?  I think the I/O really needs to be
> ECL or PECL since there are well established ECL logic families, ECL
> oscillators/PLLs and ECL A/D and D/A converters.  There must be some way to
> make ECL-compatiable drivers and receivers with MOSFETs on CMOS FPGAs.  They
> did it with GaS.
> 

LVPECL is just low voltage PECL, used for 3.3V-rated ECL devices. The
signal swing is
the same, just shifted relative to the reduced VCC reference. Motorola
and Synergy
seem to be moving in this direction for newer parts.

LVDS is a Low Voltage Differential Signalling. The relevant standards
are
ANSI/TIA/EIA-644 and the IEEE 1596.3 LVDS-SCI. Lots of good info on LVDS
can be found on National's site at 
http://www.national.com/appinfo/lvds/.
One big plus for LVDS is that it is compatible with standard CMOS
processes and
so it is available from ASIC vendors like LSI Logic, etc. I think ECL
type I/O is
just hard to do with CMOS, probably requiring extra processing steps.

A neat new part that has come out, the MAXIM 3885, is a 3.3V  2.5 GHz 1
to 16
demux that uses LVDS outputs. About half the power of the ECL/GaaS
alternatives, and
much cheaper, too, at <$40! It would be nice to be able to interface
this directly to
an FPGA without needing a bunch of quad translators.

regards, 
Tom Burgess
-- 
Digital Engineer
National Research Council of Canada
Herzberg Institute of Astrophysics
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3

Email:        tom.burgess@hia.nrc.ca
Office:       (250) 490-4360 
Switch Board: (250) 493-2277
Fax:          (250) 493-7767

Article: 13457
Subject: Re: Will XILINX survive?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 03 Dec 1998 10:53:39 -0800
Links: << >>  << T >>  << A >>
Peter wrote:

> My concern, however, would be whether these better, bigger and faster
> devices introduced at an incredibly fast pace are going to have the
> lifetime of the older devices such as the 3k and 4k family. This is
> quite relevant to industrial products which tend to have long
> lifetimes. ...Xilinx have a good record for maintaining production of
> "old" parts
> and I wonder if this will continue.
>  

Thanks for giving us credit for very carefully executes obsolescence
plans.
The normal sequence is that older parts become less popular since they
lack the features and speed of the new families, and their price doesn't
move down as fast as that of the new mainstream parts. Once the market
really dries up, we issue plenty of warnings and "last-time buy"
messages. Even then, we have the parts available for well over a year,
and then we hand it over to an "after-life" company. We are right now
slowly getting out of XC4000A and XC4000H, because there really is
almost no demand.

If you use very old parts, make sure you inform the sales channel about
your future needs.

Virtex is expected to dominate the more demanding designs in the near
future, but you can be sure that XC4000XL will be alive and kicking for
a very, very long time.

In the future, there will be less of a speed-creep, ( devices "secretly"
getting faster and faster, whether the user wants it or not ). Now the
process is coupled to the supply voltage, and we cannot migrate to a
faster process without changing the voltage and thus the part
designation. That is actually good news for people concerned about min
delays. They will remain more stable.

Peter Alfke, Xilinx Applications
 
 

Article: 13458
Subject: Re: Big-Endian vs Little-Endian
From: Brad Taylor <blt@emf.net>
Date: Thu, 03 Dec 1998 11:44:41 -0800
Links: << >>  << T >>  << A >>
d.cary@ieee.org wrote:
> 
> I collect Big endian vs. little endian information at
>   http://www.rdrop.com/~cary/html/endian_faq.html
> .
> 
> I have the classic article
>   ON HOLY WARS AND A PLEA FOR PEACE
>   by Danny Cohen (1980)
> there. Highly recommended.
> 
> I'm always astonished how many unexpected problems come from endian
> misunderstandings. I'm also kind of surprised at how many people say "Use
> little-endian" (or "Use Big-endian"), then try to justify it with some
> "reason" that applies equally well to the other format.
> 
> Are there any *real* reasons to favor one over the other that I haven't
> already listed ?
> 

Big-endian and Little-endian ordering can make a big difference if you
send bits, bytes or words serially through some type of hardware
processing filter. Examples are DSP filters and network packet
processors. Depending on the function, MSBs first or LSBs first will be
more natural.  

In implementing complex arithmetic circuits, the carry propagates from
the LSB to the MSB. A circuit which does math can immediately use LSBs,
but must store any MSBs until the LSBs arrive. On transmission, the LSBs
(which are computed first) must be stored until all the MSBs are sent.
The extra registers needed to implement this storage are costly and the
flow requires overly complicated sequencing. So in math circuits with
lots of adders, LSB first is going to be cheaper. 

This is not true for all algorithms however. Division requires both
complete operands before starting and generates the MSB first. Circuits
such as those used for searching a binary tree can use the MSBs first.
Circuits used for for finite field arithmetic circuts such as CRC
generators propagate information from the MSB to the LSBs. 


Best wishes,
Brad

Article: 13459
Subject: Re: Will XILINX survive?
From: "Austin Franklin" <dark4room@ix.netcom.com>
Date: 3 Dec 1998 21:05:32 GMT
Links: << >>  << T >>  << A >>
>... but you can be sure that XC4000XL will be alive and kicking for
> a very, very long time.

And what about both Spartan (5V) and Spartan XL (3.3V) parts?

I'm going through this silly exercise with DRAMs now.  None of the
manufacturers are making 5V DRAMs any more....so if you want to do a design
for a PC plug in card (of which there are  AT LEAST 100 MILLION of them out
there, and they ONLY have 5V, as opposed to 3.3V, on the ISA and PCI bus)
and not do any voltage regulation/DC-DC conversion, you are SOL, and forced
to provide 3.3V on your board.

THEN, to add insult to injury, they aren't making the smaller DRAMs any
more.  The smallest DRAM they offer now, 'for new designs', is 64Mb per
chip.  So, if my embedded design only needs, say 4MB of memory in an x32
configuration, I either have to use SRAM, and lots of it, and expensive, or
give it 4x the memory I need (2 4Mbx16 chips), and at twice the cost... 
Kind of looks like a hole in the market for embedded applications...

With hundreds of millions of PCs out there, I'm still miffed that most
manufacturers are abandoning the 5V market....and though the PCI bus can
support 3.3V, almost no PCs support it, AND who, making a PCI card, would
make a 3.3V only card (for the next few years at least), when there are so
many PCs out there that don't supply 3.3V?

Austin Franklin
darkroom@ix.netcom.com


Article: 13460
Subject: EDTN Tech Notes
From: "mdisman" <mdisman@ix.netcom.com>
Date: 3 Dec 1998 21:48:35 GMT
Links: << >>  << T >>  << A >>
This week's EDTN Tech Notes features an article by Lattice Semiconductor on
how a PCI interface can be implemented in a CPLD.  The company is offering
the source code for this implementation.

Check the Tech Notes section of http://www.edtn.com/pld 

Murray Disman
Editor
PLD DEsign Center

Article: 13461
Subject: Re: Will XILINX survive?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 03 Dec 1998 14:34:55 -0800
Links: << >>  << T >>  << A >>
Austin Franklin wrote:

> And what about both Spartan (5V) and Spartan XL (3.3V) parts?

Same long-time availability as XC4000XL.Hell, Spartan XL is barely born,
and you're talking about senility and death ?
It's still just a spunky baby!  :-)

> I'm going through this silly exercise with DRAMs now.  None of the
> manufacturers are making 5V DRAMs any more...

That's what happens in a commodity market with competition driving the
manufacturers to the brink of bankruptsy. It is to the buyer's advantage
that his supplier be profitable.You don't want to buy essentials at
garage-sale prices. Might limit your slection...

By the way, I hate the heading of this thread.
But then Xilinx stock hit $60 today, so I will not lose too much sleep. 
:-)

Peter Alfke, Xilinx Applications
  

Article: 13462
Subject: Re: Which parts are fastest for 3-state enables?
From: "gs" <guys@mediaone.net>
Date: Thu, 3 Dec 1998 17:46:29 -0600
Links: << >>  << T >>  << A >>
Dan,
Professionally advertising to the group isn't proper net edicate.  Being
that you have been around these pages for so long, you should know better
than to lower yourself to that level :-).

GS



Daniel K. Elftmann wrote in message <366358AF.81ECA389@actel.com>...
>Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds
>like a good FAE Challenge.
>
>http://www.actel.com/products/devices/SX/chall.html
>
>Steve wrote:
>
>> I'm interfacing to a Motorola MPC 860 @50Mhz.  I need to provide an
>> acknowledge signal in <10ns after the Clock.  To do this my PLD/FPGA
>> needs to have a (Clk-Q + comb delay + tristate enable) < 10ns.
>>
>> So far I haven't found a CPLD to do it.  What small FPGA's have the best
>> crack at it???  ... or prove me wrong on the CPLD issue?
>>
>> So far my only practical solution is an XCS05XL-4.
>>
>> Comments?
>>
>> Steve
>


Article: 13463
Subject: JPEG Core compliance
From: Vincenzo Liguori <enzo@nospam.com>
Date: Fri, 04 Dec 1998 11:07:23 +1100
Links: << >>  << T >>  << A >>
Hi,

I have almost finished a JPEG core for FPGA ASIC according to the
ISO specs ISO/IEC 10918-1.
I'm currently planning compliance tests according to ISO/IEC 10918-2.
I've noticed that the latter mentions a data set for the compliance
test.
Is this available on line or I must contact ISO (probably slow) ?

You can answer in this newsgroup, but if you need to email me directly,
see my web page.

Thanks,

Enzo

-------------------------------------------------------------------------------

Vincenzo Liguori
Ocean Logic Pty Ltd
PO BOX 768
Manly NSW 1655
Australia

Ph : +61-2-99054152
Fax : +61-2-99050921
WWW : http://www.bigfoot.com/~oceanlogic







Article: 13464
Subject: Re: Which parts are fastest for 3-state enables?
From: Peter Alfke <peter@xilinx.com>
Date: Thu, 03 Dec 1998 17:40:54 -0800
Links: << >>  << T >>  << A >>
gs wrote:

> Dan,
> Professionally advertising to the group isn't proper net edicate.

I disagree. I think proper net-etiquette can accomodate a mentioning of
devices made by your employer. Otherwise I would have to sign off from
this group. :-(We who work for an FPGA vendor have something to
contribute - and a hell of a lot to learn.
But we must tread lightly, and be constructive, honest, and fair.
Just my $0.02 worth.

Peter Alfke

>  

 

Article: 13465
Subject: Re: JPEG Core compliance
From: Tom Lane <tgl@netcom.com>
Date: Fri, 4 Dec 1998 01:46:04 GMT
Links: << >>  << T >>  << A >>
Vincenzo Liguori <enzo@nospam.com> writes:
> I'm currently planning compliance tests according to ISO/IEC 10918-2.
> I've noticed that the latter mentions a data set for the compliance test.
> Is this available on line or I must contact ISO (probably slow) ?

It's not available on-line, and I'm not sure that ISO ever even released
it officially.  The fact of the matter is that the draft 10918-2 dataset
is almost valueless as a test set; you can accomplish more, more easily,
by cross-testing with any well-recognized implementation.  (For example,
the free IJG code.)

Let's see, where did I put that screed ... ah, here it is...

10918-2 is completely useless for testing most production codecs anyway,
because it consists of random-noise data in a meaningless four-component
colorspace with randomly chosen sampling factors.  Most of the codecs
I know about include colorspace conversion and upsample/downsample logic
and will not work on this data.  If you can separate out those parts of
your codec and feed it raw subsampled data then you might have some
chance of using the 10918-2 data.  It's still a pretty unfriendly test
set because it's a random-noise image --- you have no chance of getting
a go/no go indication by eyeball, you have to resort to nontrivial
statistical analysis to see whether your codec works at all!  (Worse,
since your codec's roundoff errors are doubtless different from anyone
else's, you can't just compare output bits...)

And on top of that, the data set consists of one example of each of the
JPEG-defined processes.  IIRC, there are only about two datastreams that
a standard baseline codec has any hope of reading.  So it tells you
nothing at all about the robustness of your codec WRT real-world
variations in marker layout, restart markers, etc.

I'd suggest cross-testing with existing applications as a far more
useful and practical validation procedure than 10918-2.  (The IJG code
is intended in part as a freely available reference codec for such
testing.)  If you want to test the accuracy of your math, measuring the
degradation of an image over multiple compression cycles with a fixed
quality setting is a pretty sensitive check.

You can try the folks at www.jpeg.org if you want a more official
answer, but my opinion is that 10918-2 is a waste of time.

                        regards, tom lane
                        organizer, Independent JPEG Group

Article: 13466
Subject: Re: JPEG Core compliance
From: Vincenzo Liguori <enzo@nospam.com>
Date: Fri, 04 Dec 1998 14:31:03 +1100
Links: << >>  << T >>  << A >>
> Vincenzo Liguori <enzo@nospam.com> writes:
> > I'm currently planning compliance tests according to ISO/IEC 10918-2.
> > I've noticed that the latter mentions a data set for the compliance test.
> > Is this available on line or I must contact ISO (probably slow) ?
>
> It's not available on-line, and I'm not sure that ISO ever even released
> it officially.  The fact of the matter is that the draft 10918-2 dataset
> is almost valueless as a test set; you can accomplish more, more easily,
> by cross-testing with any well-recognized implementation.  (For example,
> the free IJG code.)

Tom,

thanks for your reply.
I fully agree with what you are saying and I suspected that the ISO test
would have been nearly useless.
Problem is that when someone wants to buy the core, especially large
companies (and I had quite a few inquiries), they often ask if I have
run some sort of standard test.
I have run my own, with the help on the excellent IJG software, but big
companies like to have some sort of "official" tests done.
That's why I asked. The ISO test would have only been in addition of my
own.


> Let's see, where did I put that screed ... ah, here it is...
>
> 10918-2 is completely useless for testing most production codecs anyway,
> because it consists of random-noise data in a meaningless four-component
> colorspace with randomly chosen sampling factors.  Most of the codecs
> I know about include colorspace conversion and upsample/downsample logic
> and will not work on this data.  If you can separate out those parts of
> your codec and feed it raw subsampled data then you might have some
> chance of using the 10918-2 data.

I can because my core accepts MCUs as input and outputs ECSs andviceversa. The
MCU is completely programmable (as are all the tables
within the limits of the baseline algorithm).
I did not include colour space conversion or raster to MCU converter as
every single person has its own need (laser printers CMYK or RGB,
video YUV, etc) with their own interface.

> It's still a pretty unfriendly test
> set because it's a random-noise image --- you have no chance of getting
> a go/no go indication by eyeball, you have to resort to nontrivial
> statistical analysis to see whether your codec works at all!  (Worse,
> since your codec's roundoff errors are doubtless different from anyone
> else's, you can't just compare output bits...)
>
> And on top of that, the data set consists of one example of each of the
> JPEG-defined processes.  IIRC, there are only about two datastreams that
> a standard baseline codec has any hope of reading.  So it tells you
> nothing at all about the robustness of your codec WRT real-world
> variations in marker layout, restart markers, etc.
>
> I'd suggest cross-testing with existing applications as a far more
> useful and practical validation procedure than 10918-2.  (The IJG code
> is intended in part as a freely available reference codec for such
> testing.)  If you want to test the accuracy of your math, measuring the
> degradation of an image over multiple compression cycles with a fixed
> quality setting is a pretty sensitive check.

Among my tests I run 10^6 8x8 blocks through FDCT and IDCT, calculatingthe PSNR
with each original block. The worst was better than 52dbs.

> You can try the folks at www.jpeg.org if you want a more official
> answer, but my opinion is that 10918-2 is a waste of time.
>
>                         regards, tom lane
>                         organizer, Independent JPEG Group

 Enzo

-------------------------------------------------------------------------------

Vincenzo Liguori
Ocean Logic Pty Ltd
PO BOX 768
Manly NSW 2100
Australia

Ph : +61-2-99054152
Fax : +61-2-99050921
WWW : http://www.bigfoot.com/~oceanlogic





Article: 13467
Subject: Re: Which parts are fastest for 3-state enables?
From: rk <stellare@NOSPAMerols.com>
Date: Thu, 03 Dec 1998 22:33:32 -0500
Links: << >>  << T >>  << A >>
Peter Alfke wrote:gs wrote:

dan,
Professionally advertising to the group isn't proper net edicate.  Being
that you have been around these pages for so long, you should know better
than to lower yourself to that level :-).

GS
-------------------------------

Daniel K. Elftmann wrote:

>Take a look at the Actel A54SX08 and contact your local Actel FAE, sounds
>like a good FAE Challenge.
>
>http://www.actel.com/products/devices/SX/chall.html
>
>Steve wrote:

peter alfke wrote:

> I disagree. I think proper net-etiquette can accomodate a mentioning of
> devices made by your employer. Otherwise I would have to sign off from
> this group. :-(We who work for an FPGA vendor have something to
> contribute - and a hell of a lot to learn.
> But we must tread lightly, and be constructive, honest, and fair.
> Just my $0.02 worth.

--------------------

hmmm ... i don't think dan's post was too bad, really.  nobody spoke up
about the SX parts for this problem so dan mentioned those, which was
appropriate.  perhaps actual performance numbers would have been better,
and i followed up with those, since i was interested in that parameter
anyways.  also, it's interesting that SX took a different approach from act
3, it has a faster clk -> q when measured from pin-to-pin, without any
flip-flops in the i/o modules, which act 3 did have.

on the other hand, there are posts that are flagrantly advertising,
answering technical questions with, "buy my stuff," over and over and over
and over ...

also, i think vendors should identify themselves, which dan did, and which
peter a. always does.

just a thought,

rk

Article: 13468
Subject: Re: JPEG Core compliance
From: Tom Lane <tgl@netcom.com>
Date: Fri, 4 Dec 1998 04:18:20 GMT
Links: << >>  << T >>  << A >>
Vincenzo Liguori <enzo@nospam.com> writes:
> I have run my own, with the help on the excellent IJG software, but big
> companies like to have some sort of "official" tests done.

True ... whether the tests prove anything is far too often irrelevant...

> Among my tests I run 10^6 8x8 blocks through FDCT and IDCT, calculatingthe
> PSNR with each original block. The worst was better than 52dbs.

This is good, but as far as FDCT/IDCT go there actually is a recognized
accuracy test, IEEE-1180.  IEEE withdrew this spec a couple years ago,
for reasons that were never explained in my hearing, but it's still about
as good a test procedure as you're going to find for those components.
Besides, if you need buzzword compliance then any spec with a number
on it is worth running ;-).

Now I will modestly claim to know a few things about JPEG implementation
bugs and compatibility problems ... and in my experience the DCT code
is not usually the source of problems.  (I can only ever recall seeing
one image that appeared to be made with a broken FDCT.)  The real
creepy-crawlies come from bogus assumptions about marker layout,
inability to cope with unusual Huffman tables or sampling factors,
and so forth.  And these are exactly the areas that the 10918-2 test
streams won't teach you much about :-(

I don't know whether you intend your hardware to produce/consume a
complete JPEG file directly, or whether you expect there to be a layer
of software to deal with the markers.  If you expect to consume real-
world JPEG files then there's no substitute for trying to read a
bunch of what's out there.  I have accumulated a rogue's gallery
of unusual JPEGs (some valid, most not) which I can send you if you're
interested in doing some stress testing.  It's far from official
but I daresay it'll teach you more than 10918-2 would...

			regards, tom lane
			organizer, Independent JPEG Group

Article: 13469
Subject: Re: Xilinx FPGA configuration problems... Help!
From: Olivier Hebert <hebert01@gel.ulaval.ca>
Date: Fri, 04 Dec 1998 06:06:53 GMT
Links: << >>  << T >>  << A >>

Hi! Indeed, I had the mode setting wrong. I did a little soldering today
and added a dip switch for selecting the configuration mode. Now, it
works nicely! 

Thanks to everyone, this was really appreciated.

Bye,

OH


Ray Andraka wrote:
> 
> You need to use master serial for prom, slave serial for the xchecker.  One
> connects all the mode bits to '1' the other is all '0'.  CCLK is sourced by
> the FPGA for master serial and by the xchecker for slave serial.   You need
> to disconnect the xchecker when programming from a PROM to avoid
> contention.  The configuration speed only effects the master serial's CCLK.
> 
> Olivier Hebert wrote:
> 
> > Hi! I'm currently developping a project with a Xilinx XC4010E FPGA. I'm
> > having problems configuring the device. I'm using a master serial
> > configuration (I'm trying to use the XChecker cable now, and a serial
> > PROM later).
> >
> > When I first power up the board, if I probe the CCLK pin with a scope, I
> > get a 900 kHz (approx) clean signal, but it's only 500 mV peak-to-peak.
> > When I try to configure the device using an XChecker cable, the
> > frequency of the CCLK signal goes up to something like 7 MHz, even
> > though I'm using slow configuration. When I hit the PROG button on the
> > board, the frequency goes back to it's normal rate (900 kHz). Of course,
> > the hardware debugger says something is wrong when I try to program the
> > device!

Article: 13470
Subject: package/footprint/layout
From: "Riad" <ardoise@cybercable.fr>
Date: Fri, 4 Dec 1998 11:49:18 +0100
Links: << >>  << T >>  << A >>
Hi,

I am currently working on a FPGA application and I choosed a chip provided
in a PQFD304 package. Since my PCB tool does not provide the layout for this
package, I have to draw it. So I am looking for detailed informations about
this package. Where can I find them on the Web?

Thanks.

Riad Bourguiba


Article: 13471
Subject: Re: HELP, Tool selection
From: David Pashley <David@edasource.com>
Date: Fri, 4 Dec 1998 12:15:46 +0000
Links: << >>  << T >>  << A >>
In article <741o75$ns$1@brokaw.wa.com>, Ken Coffman
<kcoffman@intermec.com> writes
>The last time I looked at FPGA Express it was not very good. I got faster
>and better out of the box performance from Synplicity, but Exemplar is
>better if you like tinkering under the hood. You can't go wrong with either
>product. Exemplar got out first with their ASIC support, but its coming soon
>from Synplicity.
>
I hear Synopsys already has some ASIC support ;-)

But seriously, I would say that comparing these tools as a standalone
FPGA synthesis solution, your results will vary considerably according
to the particular benchmark.

In September, Brian Dipert of EDN did an excellent, thoughtful
"Synthesis shoot out" benchmarking exercise (see www.ednmag.com). FPGA
Express fared well, but both Exemplar and Synplicity declined to
participate.

If your requirements encompass productivity issues, then remember that
FPGA Express 3 is available fully integrated within the Viewlogic 7.5
toolset. So you can freely combine HDL, schematics and state diagrams,
have a single flow (including integrated place and route) for all FPGAs,
and use a single environment for VHDL/Verilog, post-implementation and
board-level verification.

David
[a Viewlogic reseller, so naturally a little biased :-) ]
-- 
David Pashley                    <
 ---------------------------  <  <  <  --- mailto:david@edasource.com
| Direct Insight Ltd       <  <  <  <  >   Tel: +44 1280 700262      |
| http://www.edasource.com    <  <  <      Fax: +44 1280 700577      |
 ------------------------------  <  ---------------------------------

Article: 13472
Subject: Re: package/footprint/layout
From: David Pashley <David@edasource.com>
Date: Fri, 4 Dec 1998 12:34:41 +0000
Links: << >>  << T >>  << A >>
In article <748ek2$n4e$1@oceanite.cybercable.fr>, Riad
<ardoise@cybercable.fr> writes
>Hi,
>
>I am currently working on a FPGA application and I choosed a chip provided
>in a PQFD304 package. Since my PCB tool does not provide the layout for this
>package, I have to draw it. So I am looking for detailed informations about
>this package. Where can I find them on the Web?
>
Watch out, there are at least 4 different variants of the package you
describe.

See http://www.emulation.com/catalog/footprints/pqfp/172-304/304.gif

You should refer to the FPGA vendor's databook, and then you'll be sure
to get it right.

David


-- 
David Pashley                    <
 ---------------------------  <  <  <  --- mailto:david@edasource.com
| Direct Insight Ltd       <  <  <  <  >   Tel: +44 1280 700262      |
| http://www.edasource.com    <  <  <      Fax: +44 1280 700577      |
 ------------------------------  <  ---------------------------------

Article: 13473
Subject: Re: package/footprint/layout
From: Ray Andraka <no_spam_randraka@ids.net>
Date: Fri, 04 Dec 1998 09:27:53 -0500
Links: << >>  << T >>  << A >>
Go to the chip vendor's web page, and look at the package section of his data
book.  Use the vendor's info, otherwise subtle differences from one vendor's
package to another's may screw you.

Riad wrote:

> Hi,
>
> I am currently working on a FPGA application and I choosed a chip provided
> in a PQFD304 package. Since my PCB tool does not provide the layout for this
> package, I have to draw it. So I am looking for detailed informations about
> this package. Where can I find them on the Web?
>
> Thanks.
>
> Riad Bourguiba



--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 13474
Subject: Visit The Programmable Logic Jump Station (www.optimagic.com)
From: "Steven K. Knapp" <sknapp@optimagic.com>
Date: Fri, 4 Dec 1998 09:45:05 -0800
Links: << >>  << T >>  << A >>
See what's new on The Programmable Logic Jump Station at


                   http://www.optimagic.com/


The Programmable Logic Jump Station is a comprehensive set of
links to nearly all matters related to programmable logic.



Featuring:
---------


          --- Frequently-Asked Questions (FAQ) ---


Programmable Logic FAQ - http://www.optimagic.com/faq.html
A great resource for designers new to programmable logic.



          --- FPGAs, CPLDs, FPICs, etc. ---


Recent Developments - http://www.optimagic.com
Find out the latest news about programmable logic.


Device Vendors - http://www.optimagic.com/companies.html
FPGA, CPLD, SPLD, and FPIC manufacturers.


Device Summary - http://www.optimagic.com/summary.html
Who makes what and where to find out more.


Market Statistics - http://www.optimagic.com/market.html
Total high-density programmable logic sales and market share.



            --- Development Software ---


Free and Low-Cost Software - http://www.optimagic.com/lowcost.html
Free, downloadable demos and evaluation versions from all the major
suppliers.


Design Software - http://www.optimagic.com/software.html
Find the right tool for building your programmable logic design.


Synthesis Tutorials - http://www.optimagic.com/tutorials.html
How to use VHDL or Verilog.



              --- Related Topics ---


FPGA Boards - http://www.optimagic.com/boards.html
See the latest FPGA boards and reconfigurable computers.


Design Consultants - http://www.optimagic.com/consultants.html
Find a programmable logic expert in your area of the world.


Research Groups - http://www.optimagic.com/research.html
The latest developments from universities, industry, and
government R&D facilities covering FPGA and CPLD devices,
applications, and reconfigurable computing.


News Groups - http://www.optimagic.com/newsgroups.html
Information on useful newsgroups.


Related Conferences - http://www.optimagic.com/conferences.html
Conferences and seminars on programmable logic.


Information Search - http://www.optimagic.com/search.html
Pre-built queries for popular search engines plus other
information resources.


The Programmable Logic Bookstore - http://www.optimagic.com/books.html
Books on programmable logic, VHDL, and Verilog.  Most can be
ordered on-line, in association with Amazon.com



            . . . and much, much more.


Bookmark it today!







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
2017JanFebMarApr2017

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