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 13975

Article: 13975
Subject: Re: Question on Exemplar synthesis
From: s_clubb@NOSPAMnetcomuk.co.uk (Stuart Clubb)
Date: Tue, 05 Jan 1999 22:36:26 GMT
Links: << >>  << T >>  << A >>
On Tue, 05 Jan 1999 11:04:16 +0000, Rick Filipkiewicz
<rick@algor.co.uk> wrote:

>Does anybody out there using the  Leonardo tools know how to do
>incremental compilation & linking.

Sure, no problem. You know, you can always give us a call at Saros for
this kind of support:

01491 837787

>i.e. I have a module foo with an instantiiated block-box called  bar
>definined in foo.v with the real bar module held in a separate file
>called bar.v. What I want to do is compile & synth foo.v and bar.v
>separately into EDIF files foo.edn & bar.edn and then link them.  In
>other words merge bar.edn into the correct place in foo.edn.  This would
>save  a lot of time by not re-synthesising and re-optimising stable
>pieces of the design.

Standard procedure for generating internal lumps of IP, as well as
integrating bought-in netlists. You can even decide to dissolve the
hierarchy (L3) and re-optimise across the boundary if that's what you
want. You have to be a little careful with global resources in FPGA's
when you synthesise instantiated blocks but there are some tricks you
can use so it isn't much of a problem.

For your simple example, below are three scripts that should show you
the essence of the process. I have assumed that your foo is a top
level and needs ports, while the bar is to be instantiated into the
design. Hence macro and chip mode synthesis runs. Note the final
foobar script does not run any synthesis. It basically reads in your
top level foo, and then reads in bar, which replaces the empty
placeholder in the work library previously written out in the foo.edf
netlist. You set the present_design to foo, as the last design read in
was bar, and then just write out the netlist. The last command just
kicks off the design manager GUI, but you can use it to run the whole
P&R if you like.

There are three individual scripts so that you can shut down the tool
between runs to satisfy yourself that there is "nothing up our
sleeves".

The scripts obviously pertain to Level 3, but for your specific
example, you can do this with Level 2 by driving the GUI. Give me a
call, and I can walk you through it if you would like.

Cheers
Stuart

foo script
----------

set part 4005xlPC84
set process 3
set wire_table 4005xl-3_avg
load_library xi4xl
read foo.v
set_attribute .work.bar.INTERFACE -name NOOPT -value 1 
PAD BUFGLS clk
optimize .work.foo.INTERFACE -target xi4xl -effort quick -area -chip
-flatten 
write -format EDIF foo.edf

bar script
----------

set part 4005xlPC84
set process 3
set wire_table 4005xl-3_avg
load_library xi4xl
read bar.v
optimize .work.bar.INTERFACE -target xi4xl -effort quick -area -macro
-flatten 
write -format EDIF bar.edf

foobar script
-------------

load_library xi4xl
read foo.edf bar.edf
present_design .work.foo.INTERFACE
auto_write -format EDIF C:/Work_sc/work/foobar.edf
place_and_route foobar.edf -target xi4xl -gui

foo.v
-----

module foo (in0, in1, out, clk);
	input in0, in1, clk;
	output out;
	wire sync_in0;
	bar U0 (in0, sync_in0, clk); // Instantiate bar
	assign out = in1 & sync_in0;
endmodule

/* Black-box definition of bar */
module bar (in, sync_in, clk);
	input in, clk;
	output sync_in;
endmodule

bar.v
-----

module bar (in, sync_in, clk);
	input in, clk;
	output sync_in;
	reg sync_in;
	always @(posedge clk)
	begin
		sync_in = in;
	end
endmodule


For Email remove "NOSPAM" from the address

Article: 13976
Subject: Re: 22V10 Metastability - my 2c
From: Rickman <spamgoeshere4@yahoo.com>
Date: Tue, 05 Jan 1999 19:18:16 -0500
Links: << >>  << T >>  << A >>
Peter wrote:
> Regarding a) I found that the AMD 22V10 was awful, while the Philips
> one was "perfect". (There was a probably unrelated problem with the
> early Philips samples I had being thoroughly duff). I had email from a
> Philips man who saw my posts and he basically says that they don't
> guarantee identical prop delays in the input buffer - well this is
> clear since that would be a theoretical impossibility anyway. I would
> however have hoped that the skew between the two signals would be less
> than the response time of the product term AND gate and this certainly
> seems to be the case in the current Philips P3Z22V10 several of which
> have been running for a week or two now with not one error.

You seem to put a lot of blame on the AMD part with the thinking that
the skew in prop delay must be much worse than in the Philips part. But
if I understand your situation correctly, skew in one direction will
cause the problem, while skew in the other direction will mask it. The
failure you are seeing is only on one edge of the input. It may just be
that the Philips part has as much skew as the AMD part, just in the
direction that helps your test case rather than harming it. 


-- 

Rick Collins

redsp@XYusa.net

remove the XY to email me.

Article: 13977
Subject: CRC16 maybe?
From: John Larkin <jjlarkin@worldnet.att.net>
Date: 6 Jan 1999 00:25:08 GMT
Links: << >>  << T >>  << A >>
Hi,

has anyone done a CRC-16 generator/checker, x16+x15+x2+1 polynomial, in
an FPGA? Preferably in schematic form? 

Wanna trade for money/food/beer?

I also have MC68332 code to boot Xilinx 4010XL's from CPU shared
program/FPGA-config EPROM if anybody's interested.... THAT one took a
while to get up!

Thanks,

John

-- 
******************************************************************

John Larkin, President           phone 415 753-5814   fax 753-3301
Highland Technology, Inc         
320 Judah Street                 jjlarkin@worldnet.att.net
San Francisco, CA 94122          http://www.highlandtechnology.com

Article: 13978
Subject: Re: Gamma correction in YUV space
From: Brad Taylor <blt@cmln.com>
Date: 05 Jan 1999 16:44:07 PST
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------7D806DDB6243A0DE1CAAFDD7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

It's amazing what you can get away with in video. If you apply the 
non-linearity to YUV and then transform to RGB, it doesn't look too bad,
but it's really not correct and will generate discernable color errors.
The correct way is:

1) transform YUV to R'G'B' where R'G'B' is the color space of the actual
monitor you are using to display the data. This is different than RGB
which seems to be generally assumed to work with NTSC monitor phosphors. 

2) apply a calibrated look-up-table to each channel. IE:

R'=Y*c0+U*c1+V*C2+C3;
rout=RLUT[R'];

This method will ignore non-linear interactions between channnels and
time dependent brightness issues as well as ambient light chroma and
intensity. It also requires you to calibrate the curves, as well as
obtaining an absolute chroma measurement for each of the monitor
phosphors. 

Another method would be to apply a 3D LUT with interpolation directly to
YUV. 
Keep in mind that the gamma function is a crude approximation to the
actual luminance curve. Also, monitors drift over time. 

All this probably impractical for your needs, so it would probably be
best to simply do a gamma (R^^2.2) function on the RGB values after
transformation from YUV. 

Best Wishes
Brad


Armin Mueller wrote:
> 
> Hello,
> 
> I know the Gamma correction is normally done in the
> RGB color space (by component).
> 
> Would it be possible to do the Gamma directly in YUV terms?
> Sure, the exp-function can't be added, but maybe there are
> some simplifications...
> 
> Armin
--------------7D806DDB6243A0DE1CAAFDD7
Content-Type: text/x-vcard; charset=us-ascii;
 name="blt.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Brad Taylor
Content-Disposition: attachment;
 filename="blt.vcf"

begin:vcard 
n:Taylor;Brad
tel;work:1-408-730-3300 ext108
x-mozilla-html:FALSE
url:www.cmln.com
org:Chameleon Systems;Applications
version:2.1
email;internet:blt@cmln.com
title:Director of Applications
adr;quoted-printable:;;1195 W. Fremont Ave=0D=0A;Sunnyvale;CA;94087-3825;USA
note;quoted-printable:Chameleon Systems is a fabless semiconductor company. Chameleon=0D=0Ais developing a new class of devices known as ASPPs for=0D=0A"Application Specific Programmable Device". Please contact me=0D=0Adirectly for more information about our product line at=0D=0Ablt@cmln.com=0D=0A=0D=0A
fn:Brad Taylor
end:vcard

--------------7D806DDB6243A0DE1CAAFDD7--

Article: 13979
Subject: Over 1100 semiconductor links!
From: "A.Tillmann" <a.tillmann@t-online.de>
Date: Tue, 05 Jan 1999 17:03:23 -0800
Links: << >>  << T >>  << A >>
Happy new year!

Visit MY SEMICONDUCTOR LINKPAGE at 

http://home.t-online.de/home/a.tillmann

where you can find semiconductor related links in the following 
categories:

Companies 
 Wafer Manufacturers(21) 
 Equipment Vendors(455) 
 Used Equipment/ Refurbished Equipment(17) 
 IC Manufacturers/ Foundries/ Wafer Processing Services(301) 
 Software/ Process and Device Simulation(46) 
 Service/ Photomask Manufacturers/ Others(78) 
 Quartz manufacturers(6) 
 Consultants(10) 
Universities/ Institutes(49) 
Journals(14) 
Organisations/ Directories/ Linkpages 
 U.S.A.(30) 
 Japan(11) 
 Europe(7) 
News(5) 
Usenet Groups(14) 
Conferences(5) 
Online Shop 
 Software(4) 
 Books in Association with Amazon.com: General Semiconductor(67) 
 Books in Association with Amazon.com: Chemical Vapor Deposition(7) 
 Books in Association with Amazon.com: Ion Implantation(7) 
 Books in Association with Amazon.com: Rapid Thermal Processing(4) 
Search Engines (english)(31) 
Search Engines (french, german)(6) 
Jobs/ Recruitment(10) 

If you would like to add your own link please submit the URL, the name of 
the company or organization and the category, where the link should 
appear.

Best regards

Article: 13980
Subject: Looking for old PLD datasheets
From: Tom Kean <tom@algotronix.com>
Date: Wed, 06 Jan 1999 01:50:09 +0000
Links: << >>  << T >>  << A >>

I'm looking for copies of datasheets on a couple of old PLD products:

Plus Logic H5110   and
Intel FlexLogic iFX780

these chips were around about 1990.  Any technical literature or
conference/
magazine papers on these products would be much appreciated!

(I know they are no longer available and am not
looking for suggestions for equivalent or better devices).

Cheers,

Tom Kean


Article: 13981
Subject: Re: 22V10 Metastability - my 1c
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Tue, 5 Jan 1999 18:07:06 -0800
Links: << >>  << T >>  << A >>
Sorry.  I'm sure you know all this, but I feel compelled to say it anyway:

You are playing with fire.  Either make sure the code is theoretically
glitchless, or sync the async input.  I would never depend on the
characteristics of 1 (or several) batches of a particular vendors parts for
a characteristic that he doesn't advertise. Who knows, maybe next month
maybe they will ship AMD parts.

Good information though.

Bruce

"Having spent untold hours at analyzing and measuring metastable
behavior, I can assure you that it is (today) a highly overrated
problem.  You can almost ignore it."
Peter Alfke
12/28/98

"Having spend untold hours debugging digital designs, I can assure you that
metastable behavior is a real problem, and every digital designer had better
understand it"
Bruce Nepple
12/31/98



Article: 13982
Subject: Great NEW Search Engine--> WWW.ISEARCH.TO
From: success114@aol.com
Date: Wed, 06 Jan 1999 03:58:50 GMT
Links: << >>  << T >>  << A >>

Hello Folks,

I've discovered a great new search engine that beats all the others
hands down. It's called I-Search Online! What makes them better than
the rest is that they filter out all spam postings so you get clean,
accurate, no nonsense results. Plus, if you're a webmaster, they also
make a great place to advertise your website because you can choose
your listing's rank which is excellent!

Go check them out at this URL: WWW.ISEARCH.TO

and tell them Dave sent you!

Best Regards,
David Allen

Article: 13983
Subject: Re: 22V10 Metastability - my 2c
From: Jamie Lokier <spamfilter.dec1998@tantalophile.demon.co.uk>
Date: 06 Jan 1999 04:30:43 +0000
Links: << >>  << T >>  << A >>
Jonathan Bromley <jsebromley@brookes.ac.uk> writes:
> [version 1: no hazard coverage]
> if (clk) then q=d else q=q   ---maps to-->    q = clk.d + /clk.q
> 
> [version 2: hazard covered]
> q = clk.d + /clk.q + d.q
> 
> Commonsense says that version 1 is dodgy and version 2 is OK.  BUT:
> in QuickLogic FPGAs, for example, [1] works just fine because clk is used
> as the select input to a multiplexer implemented by break-before-make 
> pass transistors with capacitive hold on its output.  On the other
> hand, it is possible to imagine table-lookup implementations of
> 3-input OR which could make [2] fail despite the extra term.

I have read that Xilinx and Altera FPGAs implement their logic tables in
the "safe" way you describe (pass transistors with capacitive hold, or
equivalent).  So if you pick the right devices, you don't need to worry
about these sort of hazards.

(But don't rely on my second hand info -- check the manuals if you need to).

> The net result is that any tool that attempts to achieve automatic hazard
> coverage will need to preserve information about the dynamic behaviour of 
> the logic (which transitions it will make) all the way down to the
> hardware - even, perhaps, down to place-and-route - in order to decide
> how to implement the hazard coverage.

Or use an FPGA that guarantees no hazards on single input transitions.

-- Jamie

Article: 13984
Subject: which FPGA to choose ?
From: ekuria01@kepler.poly.edu
Date: Wed, 06 Jan 1999 04:38:05 GMT
Links: << >>  << T >>  << A >>
Hello,	I must convert a microcontroller based digital AGC to an FPGA. The
AGC in question uses relatively simple math (adds, shifts, and Look up
Tables). I also need to implement digital peak detectors that peak detect
using and A/D converter.

       I am a novice with FPGAs and my expertiese only extends to micro coding
for controllers. Any help on how to choose FPGAs, and what company FPGAs sound
apt for my application will be greatly appreciated.

       Thank you all in advance.

Eldho Kuriakose

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Article: 13985
Subject: Re: 22V10 Metastability - my 2c
From: z80@ds2.com (Peter)
Date: Wed, 06 Jan 1999 08:34:41 GMT
Links: << >>  << T >>  << A >>
I believe this is correct.

>I have read that Xilinx and Altera FPGAs implement their logic tables in
>the "safe" way you describe (pass transistors with capacitive hold, or
>equivalent). 


--
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: 13986
Subject: Re: 22V10 Metastability - my 2c
From: z80@ds2.com (Peter)
Date: Wed, 06 Jan 1999 08:34:42 GMT
Links: << >>  << T >>  << A >>

I have externally synced the input with a HC74, anyway. I realise that
one cannot guarantee equal propagation delays. I merely observed that
Philips seem to have got it about right.

>now that you have it working, try cooling and heating it.
>Your problem may come back.


--
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: 13987
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: murray@pa.dec.com (Hal Murray)
Date: 6 Jan 1999 09:19:22 GMT
Links: << >>  << T >>  << A >>
In article <S4WnzrBY0ok2EwBJ@jmwa.demon.co.uk>, John Woodgate <jmw@jmwa.demon.co.uk> writes:
> <76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote:
> >If the problem is "irrelevant" for "most applications", how do I tell
> >if I'm working on one where it is relevant?
> 
> Assume that it is, until you prove that it isn't. In other words, if it
> works, OK; if it doesn't, don't rule out metastability as the cause.


That's the sort of attitude that gets people burned.  Testing
a design doesn't tell you it doesn't have any metastability problems.
It only tells you that they don't happen often enough for your
tests to catch them.

Suppose you design a disk controller.  You test it hard for a week.
It works great.  So you test 10 of them for a month.  No troubles.
So you ship it.

Suppose it has a once-a-year metastability bug that trashes your data.
Your testing only has a 50-50 chance of finding one.  Maybe you missed it.

Most systems don't run the disk as hard as test programs do but
some machines are pretty busy.  So every 10 years you get some
data trashed.  If you have a dozen machines that means an obscure
bug/glitch every year or so.  If you are running crappy software nobody
will notice a quirk a year.  But not all software is crappy.  Some of
us expect disk subsystems and operating systems to work - or at least
not trash our data without some hint.  Once a year type bugs are a real
pain to track down.

You can't test out metastability!  You have to understand things
and do it right at design time.

-- 
These are my opinions, not necessarily my employers.

Article: 13988
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Wed, 06 Jan 1999 06:58:42 -0500
Links: << >>  << T >>  << A >>
John Woodgate wrote:

> <76sf7q$1ip@src-news.pa.dec.com>, Hal Murray <murray@pa.dec.com> wrote:
> >If the problem is "irrelevant" for "most applications", how do I tell
> >if I'm working on one where it is relevant?
>
> Assume that it is, until you prove that it isn't. In other words, if it
> works, OK; if it doesn't, don't rule out metastability as the cause.

ah, the russian roullette [spell] theory of electronics design.

if you take your parameters and analyze the failure rate as a result of
metastability, then you will see it's a pretty small number, if the system is
properly designed, which includes timing margin to resolve flip-flops that have
gone metastable.  this makes a "qualification by test" somewhat, well,
impractical.

poorly designed systems may not have enough margin [getting tougher, as the times
are getting to be quite small] but worse bad design practices can leave you
further exposed to metastable [or logic hazard or whatever] problems..  so, how
do you tell if it works?  run it in the lab for a day?  over a weekend? for a
week?  for a months?  if you have to design systems that run interrupted for,
say, 15 years, and it's a critical system - it better not fail.  what do you do?
and when you test it, how do you know if you get the right combination of
parameters?  i've been called in to debug systems that were designed for YEARS
and then had a failure, frequently blamed on parts or phase of the moon.
virtually everytime it was a design defect that was not detectable by just
sticking it on a bench and running it.  or even cooking it in the oven and moving
the voltage up and down.

independent of what the design flaw is, assuming that a circuit is good until
proven guilty is really a crime against humanity and you shouldn't really have
anything to do with electronics, in my opinion.  in practice, one should follow
barto's law: EVERY CIRCUIT IS CONSIDERED GUILTY UNTIL PROVEN INNOCENT!

damn, another reason to have the little red buttons on the front of electronic
boxes,

rk

p.s. sorry 'bout the rant, but people read this stuff, this junk needs to be
stepped on, HARD!

==================================

> --
> Regards, John Woodgate, Phone +44 (0)1268 747839 Fax +44 (0)1268 777124.
> OOO - Own Opinions Only. You can fool all of the people some of the time, but
> you can't please some of the people any of the time.





Article: 13989
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: Dan Prysby <dprysby1@email.mot.com>
Date: Wed, 06 Jan 1999 10:02:22 -0600
Links: << >>  << T >>  << A >>
I have read that there is effort to design a metastable-proof
flip-flop. Anyone have any facts to share?

Dan Prysby

Peter Alfke wrote:
> 
> Hal Murray wrote:
> 
> > Big snip here.  I'm extracting the parts I want to comment on.  I
> > don't
> > think I've tossed too much context.
> >
> > > I never said that metastability does not exist. I have measured it.
> > It does
> > > exist, but the recovery delay  from the metastable (=balanced)
> > condition to the
> > > ultimately stable state is so short in modern CMOS latches and
> > flip-flops, that
> > > the problem has lost most of its impact.
> >
> > > 1. A modern CMOS latch can go metastable, but recovers so fast that
> > the problem
> > > is, in most applications, irrelevant. ( see curves in the Xilinx
> > data book,
> > > page 13-49 )
> >
> > I cringe when I see things like that, especially from people that I
> > usually
> > agree with.
> >
> 
> What I meant to say was:
> If your asynchronous events occurs at a few MHz rate, and you clock at
> less than 50 MHz, and you have a few ns "slop" between the synchronizing
> flip-flop and the next flip-flop, and you use modern chips ( I should
> say Xilinx XC4000XL, but I don't want to be accused of advertising...),
> then you can safely ignore the metastable probability.
> 
> If you try to synchronize an asynchronous even that is well above 10
> MHz, and your clock rate is so high that you have not even 2 ns spare
> time, then you should think about meatstability and do some
> calculations.
> 
> I wanted to dispel some of the paranoia, and explain that our flip-flops
> have become dramatically better, actually more so than the general chip
> performance and thus system clock rate. Flip-flop gain-bandwidth
> benefits directly from advances in semiconductor processing, while chip
> performance unfortunately gets dragged down by interconnect capacitance.
> 
> I did not realize the hornets nest...
> 
> Peter Alfke, Xilinx Applications
> 
>

Article: 13990
Subject: Gömmer grisöron...
From: thor@sm.luth.se (Jonas Thor)
Date: Wed, 06 Jan 1999 17:32:18 GMT
Links: << >>  << T >>  << A >>
Hej!

Jag har upptäckt ett lustigt beteende hos min 1 årige
(groenendal/collie/border collie). Han älskar grisöron, men när han är
mätt så gömmer han öronen (grisens öron ...). Han bäddar in de i sin
säng, trycker in de mellan kuddarna i soffan, gömmer bakom bokhyllan
osv.

Jag antar att han beter sig som ekorren och bunkrar upp sin mat. Är
detta beteende vanligt hos hundar? Det är min första hund, så jag har
inte sett detta bettende förut.

God forsättning på det nya året!

/ Jonas Thor

Article: 13991
Subject: Re: Gömmer grisöron...
From: thor@sm.luth.se (Jonas Thor)
Date: Wed, 06 Jan 1999 17:37:34 GMT
Links: << >>  << T >>  << A >>
Oops,

I am so sorry about this... I was going to send the previous message
to the swedish newsgroup for dogs. However somehow I sent it to
comp.arch.fpga. I suppose there are no swedish speaking dog owners in
this group so, please ignore my previous post :(

/ Jonas Thor

Article: 13992
Subject: ARISTOTLE BOARD
From: Khaled benkrid <k.benkrid@qub.ac.uk>
Date: Wed, 06 Jan 1999 19:15:52 +0000
Links: << >>  << T >>  << A >>
Hi All,

I am working toward the implementation of an FPGA based Image Processing
Coprocessor. My work will enable the user to describe Image Operations
from a high level description and obtains an efficient FPGA
configuration very quickly ( I generate EDIF description in less than 2
seconds for a 3 by 3 convolver for any given weights). I am moving
toward the implmentation phase. We think about using MIROTECH ARISTOTLE
board ( includes DSP processor). I would appreciate to have any
information from someone who has already used this board or has any
information about it.

Cheers.


Article: 13993
Subject: Re: which FPGA to choose ?
From: rolavine@aol.com (Rolavine)
Date: 6 Jan 1999 19:25:42 GMT
Links: << >>  << T >>  << A >>
>ekuria01@kepler.poly.edu

>Hello,	I must convert a microcontroller based digital AGC to an FPGA.
The
>AGC in question uses relatively simple math (adds, shifts, and Look up
>Tables). I also need to implement digital peak detectors that peak detect
>using and A/D converter.
>
>       I am a novice with FPGAs and my expertiese only extends to micro
>coding
>for controllers. Any help on how to choose FPGAs, and what company FPGAs
>sound
>apt for my application will be greatly appreciated.
>

The key item in you list of functions is the look up table. You will require an
fpga with some presettable ram to do a look up. Atlera and Xilinx have products
with ram. You should note how much ran you will require and try to match it to
the device. The parts with RAM are relatively expensive, so you might consisder
using an external rom. The other functions you mentioned should be fairly easy.

If your a newby then Altera's integrated software system should be easier. If
your looking at using these parts in quantity, and you work for a reasonable
sized corporation, then the field service engineers representing the vendor
will be glad to help.

Good Luck
Rocky Lavine
Rocky Test 

Article: 13994
Subject: Re: which FPGA to choose ?
From: Peter Alfke <peter@xilinx.com>
Date: Wed, 06 Jan 1999 12:08:13 -0800
Links: << >>  << T >>  << A >>
Rolavine wrote:

> The key item in you list of functions is the look up table. You will
> require an
> fpga with some presettable ram to do a look up. Atlera and Xilinx have
> products
> with ram. You should note how much ran you will require and try to
> match it to
> the device. The parts with RAM are relatively expensive, so you might
> consisder
> using an external rom. The other functions you mentioned should be
> fairly easy.
>  

   I may be biased, but I would not call the Xilinx Spartan devices
"relatively expensive", when they sell for $10 and less.
Also, a $70.- software package including a tutorial manual can be bought
at amazon.com ( look for Xilinx Foundation Student edition. )
Sorry for the "commercial".

Peter Alfke, Xilinx Applications

Article: 13995
Subject: Re: which FPGA to choose ?
From: rk <stellare@NOSPAMerols.com>
Date: Wed, 06 Jan 1999 15:37:22 -0500
Links: << >>  << T >>  << A >>
Rolavine wrote:

> The key item in you list of functions is the look up table. You will require an
> fpga with some presettable ram to do a look up. Atlera and Xilinx have products
> with ram. You should note how much ran you will require and try to match it to
> the device. The parts with RAM are relatively expensive, so you might consisder
> using an external rom. The other functions you mentioned should be fairly easy.

there are other options for a look up table and i believe that they can be done
without either an fpga with sram or an external rom device, depending on the
characteristics of the contents, of course.  as many devices do not have rom
(actel, at6k, dynachip, quicklogic, + whatever), we have spent quite a bit of time
looking at this problem.

for example, one can code up the rom contents as a constant array in vhdl and then
access it in the code, letting the synthesizer map it onto the fpga's
architecture.  another approach is to code up the contents into a case statement
located inside of a process.  another approach is to look at the rom as a
combinational function, not a memory. then, you can write down logic equations,
making each output of the "rom" a function of the "address" inputs.  there are
several ways to do this, either taking the terms that are a '1', or taking the
terms that are a '0' (and of course inverting the output).  which method works
better depends on a number of factors such as data contents, the synthesis tool
being used (and the algorithms implemented in that specific version), the device
architecture, and the coding style, discussed above.  of course, trying this out
results in quite a bit of typing.  fortunately, this is easily automated by
software, which has been done and quite large tables can be mapped this way, the
largest that i have seen done was 16-bit address with 24-bit output, about 10% of
the entries used (the rest processed as don't cares since nobody cared what their
output was).  the vhdl file was 1.6 megabytes and it took 20 minutes to run.

good luck!

rk

Article: 13996
Subject: Re: Glitchless Logic, hazards, and Metastability - Was Re: 22V10 Metastability - help please
From: rk <stellare@NOSPAMerols.com>
Date: Wed, 06 Jan 1999 15:40:45 -0500
Links: << >>  << T >>  << A >>
Dan Prysby wrote:

> I have read that there is effort to design a metastable-proof
> flip-flop. Anyone have any facts to share?

i believe the delivery data has slipped ... until just after delivery of the
perpetual motion machine.

while modern flip-flops have quite good metastable state characteristics, it
is impossible to design a guaranteed by law metastable state proof flip-flop.
the best you can do is describe it statistcally; and you can get good
performance, making the failure rate insignificant w.r.t. normal cmos device
failure rates.

also, about 10 years ago, amd (and perhaps signetics) produced
metastable-state hardened flip-flops.

rk

Article: 13997
Subject: Re: VHDL Bit String Literals
From: Jim Lewis <telejim@teleport.com>
Date: Wed, 06 Jan 1999 13:00:28 -0800
Links: << >>  << T >>  << A >>
This is a VHDL-87 vs. VHDL-93 thing.  So a library will not help you.
To be portable between both VHDL-87 and VHDL-93 either of the use the
following:

A <= to_StdLogicVector(bit_vector'(X"BE")) ;
A <= to_X01(bit_vector'(X"BE")) ;

When Synopsys supports VHDL-93, you will be able to use bit-string literals
directly.
Call you local Synopsys marketing person and submit a feature request.

Cheers,
Jim Lewis
VHDL Trainer, ASIC and HDL Consultant
telejim@teleport.com


Adam J. Elbirt wrote:

> Does anyone know the IEEE or Synopsys library that must be added to use
> bit string literals with std_logic_vectors?
>
> Thanks.
>
> Adam



Article: 13998
Subject: Re: Gamma correction in YUV space
From: Edward Moore <edmoore@edmoore.demon.co.uk>
Date: Wed, 6 Jan 1999 21:26:50 +0000
Links: << >>  << T >>  << A >>
Also bear in mind that the U and V chrominance signals have half the
luminance bandwidth and should be upsampled (interpolated by a factor of
2) before the YUV is matrixed to RGB.

Ed.

In article <3692B193.3FD685A1@cmln.com>, Brad Taylor <blt@cmln.com>
writes
>It's amazing what you can get away with in video. If you apply the 
>non-linearity to YUV and then transform to RGB, it doesn't look too bad,
>but it's really not correct and will generate discernable color errors.
>The correct way is:
>
>1) transform YUV to R'G'B' where R'G'B' is the color space of the actual
>monitor you are using to display the data. This is different than RGB
>which seems to be generally assumed to work with NTSC monitor phosphors. 
>
>2) apply a calibrated look-up-table to each channel. IE:
>
>R'=Y*c0+U*c1+V*C2+C3;
>rout=RLUT[R'];
>
>This method will ignore non-linear interactions between channnels and
>time dependent brightness issues as well as ambient light chroma and
>intensity. It also requires you to calibrate the curves, as well as
>obtaining an absolute chroma measurement for each of the monitor
>phosphors. 
>
>Another method would be to apply a 3D LUT with interpolation directly to
>YUV. 
>Keep in mind that the gamma function is a crude approximation to the
>actual luminance curve. Also, monitors drift over time. 
>
>All this probably impractical for your needs, so it would probably be
>best to simply do a gamma (R^^2.2) function on the RGB values after
>transformation from YUV. 
>
>Best Wishes
>Brad
>
>
>Armin Mueller wrote:
>> 
>> Hello,
>> 
>> I know the Gamma correction is normally done in the
>> RGB color space (by component).
>> 
>> Would it be possible to do the Gamma directly in YUV terms?
>> Sure, the exp-function can't be added, but maybe there are
>> some simplifications...
>> 
>> Armin
>[ A MIME text / x-vcard part was included here. ]
>

-- 
Edward Moore

Article: 13999
Subject: Re: Gömmer grisöron...
From: Magnus Homann <d0asta@mis.dtek.chalmers.se>
Date: 06 Jan 1999 22:32:05 +0100
Links: << >>  << T >>  << A >>
thor@sm.luth.se (Jonas Thor) writes:

> Hej!
> 
> Jag har upptäckt ett lustigt beteende hos min 1 årige
> (groenendal/collie/border collie). Han älskar grisöron, men när han är
> mätt så gömmer han öronen (grisens öron ...). Han bäddar in de i sin
> säng, trycker in de mellan kuddarna i soffan, gömmer bakom bokhyllan
> osv.
> 
> Jag antar att han beter sig som ekorren och bunkrar upp sin mat. Är
> detta beteende vanligt hos hundar? Det är min första hund, så jag har
> inte sett detta bettende förut.
> 
> God forsättning på det nya året!

Nja, jag tycker att du skall använda en PLD. Ta tex de senaste Lattice
2032VE, den har bara fyra nanoskeunders fördröjning. På så sätt tjänar
man en klockcykel. Akta dig för metastabilitet, bara!

Homann
-- 
   Magnus Homann  Email: d0asta@dtek.chalmers.se
                  URL  : http://www.dtek.chalmers.se/DCIG/d0asta.html
  The Climbing Archive!: http://www.dtek.chalmers.se/Climbing/index.html



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