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 61375

Article: 61375
Subject: Safe state machine design problem
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 2 Oct 2003 14:26:15 -0400
Links: << >>  << T >>  << A >>
Hi all,

I've been going through the archives trying to find a hint to the problem I
am having with a state machine (it occasionaly enters illegal states and
doesn't come out) and I found this post:
---------------------------------------------------------------------
From: iglam (rluking@deletethispart.home.com)
Subject: Re: safe state machine design problem
Newsgroups: comp.lang.vhdl, comp.arch.fpga
Date: 2001-06-08 08:26:41 PST


If you are using enumerated types, then your
when others clause is doing nothing.  You've already listed
all of the elements of the state type when you built your
case statement.  So, the first thing is, your synthesis tool
tosses that line.

Next, your synthesis engine decides to one-hot build the state machine.
OK, great.  Then, you screw up the state by forcing two bits high, and
it goes out to lunch.  Makes sense.  The synthesis tool was not
instructed to put in logic to avoid or get out of lockout states.

Either enumerate the Illegal states and get the synthesis tool to
build a regulare state machine

or

Get the synthesis tool to put the lockout state protection in.  I'm not
familiar with Leonardo, so someone else will have to suggest specific
solutions.

Bob
---------------------------------------------------------------------

So, I was wondering if ignoring illegal states when using enumerated types
is true for XST? That would explain at least some of my problems... Can I
somehow force XST to make a state machine safe without manually coding all
the states?


Thanks,
/Mikhail



Article: 61376
Subject: Re: LVDS_25_DCI : Top Ten List
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Thu, 02 Oct 2003 18:34:43 GMT
Links: << >>  << T >>  << A >>
On 1 Oct 2003 20:56:59 -0700, brimdavis@aol.com (Brian Davis) wrote:

>Top Ten Things I wish I never had needed to learn about LVDS_25_DCI:
>
>
> 1) Parallel DCI input standards in Virtex2 continuously modulate
>   the input termination offset voltage unless you enable bitgen's
>   FreezeDCI option

First, thanks for your post; it's very informative.

Second, how much offset voltage modulation are you seeing with DCI
update enabled?  Is it enough to justify all the difficulties you're
experiencing with FreezeDCI?

Thanks,
Bob Perlman
Cambrian Design Works


Article: 61377
Subject: Re: Good VHDL/Verilog editor?
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 2 Oct 2003 11:54:06 -0700
Links: << >>  << T >>  << A >>
"Valentin Tihomirov" <valentin@abelectron.com> wrote in message news:<3f7c1470_1@news.estpak.ee>...
> > I still like Aldec for design entry.  Editor is very much studio editor
> > like, plus you can run sims right there as well as integrate in the rest
> > of your tool flow.  For the price, I think it is a great value.
> 
> Heh, I appretiate Aldec cos it is not studio-like as opposed to Xilinx's
> WebPack. And more feature rich and its level ov integration of different
> tools (like jumping to errorous code line and more).

Are you saying you think Xilinx's tools are "Visual Studio"-like? 
I'll certainly agree that the Xilinx tools are poor at best, but I
wouldn't say they are Studio-like.  Coming from a command-line
background, I've never been a big IDE fan.  I tried to avoid them at
all costs because they were big, clunky, and just got in the way of
development.  Then recently (last two years) I tried Visual Studio
.NET for a software app I needed to write.  Within a couple days I
really learned to appreciate the package.  It is very
intelligently-designed.  Function pop-ups to help remind you of the
return type and parameters of a call are very helpful (I always used
to have a window for editing and a window for 'man' pages
side-by-side.).

Similarly, I recently started using Protel DXP for PCB work after
having used OrCAD, Microsim, Eagle, Allegro, Mentor, and one or two
others.  Big difference.  Someone actually took the time to design a
piece of software that had function for the people who use it.

If Aldec can do the same, I'll switch.  It's a shame Xilinx's tools
couldn't be tweaked a bit better to accomplish similar goals.  They're
getting close to the level of integration they need.  If they could
combine Visual Studio's editing capabilities with Protel DXP's way of
handling packages and projects, they would be well on their way. 
Currently, they provide nothing more than 'make' functionality with
nothing near it's flexibility.

   End of my rant...
   Jake

Article: 61378
Subject: Re: Digesting runs of ones or zeros "well"
From: "Vinh Pham" <a@a.a>
Date: Thu, 02 Oct 2003 19:18:57 GMT
Links: << >>  << T >>  << A >>
> Thanks for noticing :-)

Yeah, it hit me when I was laying down to sleep.  I wanted to put it off
till today but it annoyed me too much.

> synthesizer, I'm sure.  It can be done with fewer LUTs by using
> 4-input LUTs covering 3 compares each but then the symmetry gets lost
> and the coding gets unpleasant.

Great catch.  Yes, you can save a LUT per byte by comparing on tribbles
instead of dibbles, but the code gets even more ugly than it already is.

> I think I have an acceptable solution together that gives me good
> speed and good utilization which I'll post separately.

Cool, I'm looking forward to seeing it.



Article: 61379
Subject: Re: High-performance workstation
From: Steve Lass <lass@xilinx.com>
Date: Thu, 02 Oct 2003 13:57:41 -0600
Links: << >>  << T >>  << A >>
DK wrote:

>Hi,
>
>could somebody suggest hi-performance workstation I can use to compile my
>designs in a fastest possible way?
>
>I use Altera Quartus III and EP1C12Q240 device. It 90% full with most of the
>memory used. My Athlon XP 1800+ on ASUS A7V266-C motherboard with 512M of
>RAM takes 8/23 minutes to compile/fit. I did try dual Xeon 2200 on TYAN MB
>and it did only 5% faster..
>
>Did somebody try Athlon 64-bit processor?
>
No, but we tried a 64 bit Opteron and found that a 3Ghz Xeon is about 
30% faster than a 1.8G Opteron.

Steve


Article: 61380
Subject: Re: Safe state machine design problem
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 02 Oct 2003 13:20:50 -0700
Links: << >>  << T >>  << A >>
MM wrote:

> I've been going through the archives trying to find a hint to the problem I
> am having with a state machine (it occasionaly enters illegal states and
> doesn't come out) 

The most likely reason for *getting* into an illegal state
is missing input synchronization.

The most likely reason for *staying* in an illegal state
is not covering all the state cases in your code.

Consider binary encoding.

  -- Mike Treseler


Article: 61381
Subject: Re: Safe state machine design problem
From: "MM" <mbmsv@yahoo.com>
Date: Thu, 2 Oct 2003 17:26:51 -0400
Links: << >>  << T >>  << A >>
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3F7C88A2.7040200@flukenetworks.com...
> The most likely reason for *getting* into an illegal state
> is missing input synchronization.

Understood...

> The most likely reason for *staying* in an illegal state
> is not covering all the state cases in your code.

That's what my original question was about. I do have a statement covering
all other states:
when others =>
     fsm_reg <= idle;
however it doesn't seem to do anything...

> Consider binary encoding.

You mean manual?

Thanks,
/Mikhail



Article: 61382
(removed)


Article: 61383
Subject: Re: Safe state machine design problem
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 02 Oct 2003 14:36:57 -0700
Links: << >>  << T >>  << A >>
MM wrote:

> That's what my original question was about. I do have a statement covering
> all other states:
> when others =>
>      fsm_reg <= idle;
> however it doesn't seem to do anything...
> 
>>Consider binary encoding.
> 
> You mean manual?

No. I mean change the synthesis seting from one-hot to binary.

Synthesis does not always cover the "others" case
completely for one-hot encoding.


    -- Mike Treseler


Article: 61384
Subject: Re: Xilinx XST 6.x and Verilog-2001?
From: Steve Lass <lass@xilinx.com>
Date: Thu, 02 Oct 2003 15:39:47 -0600
Links: << >>  << T >>  << A >>
Allan Herriman wrote:

>Hi,
>
>Does Xilinx XST 6.x support RTL-synthesis of Verilog-2001?
>
>This document
>http://toolbox.xilinx.com/docsan/xilinx5/data/docs/xst/xst0083_11.html
>shows that the older version, XST 5.x, has partial support for Verilog
>2001.
>
>I was wondering if the support is better in the newer version of ISE.
>
Yes.  You can see the main improvements at:
http://toolbox.xilinx.com/docsan/xilinx6/swcol/whatsnew.htm

>In particular, I'm interested in knowing if 'generate' works, and 
>whether arrays of instances work.
>
XST supports both of these in version 6.1i.

Steve

>  The latter was actually added to
>the language in 1995, but XST 5.x doesn't seem to support it.
>
>Regards,
>Allan.
>  
>


Article: 61385
Subject: Quartus II tutorial vs the real world
From: hjones1380@hotmail.com (pjjones)
Date: 2 Oct 2003 15:05:38 -0700
Links: << >>  << T >>  << A >>
I'm working with a Stratix EP1S40 evaluation baord, after going
through the tutorial successfully (there is no mention of pin
assignments in the tutorial, that would have been a nice touch i
think), I tried a similar nios processor design from scratch to no
avail.

What I've figured out is this:  if I begin with the given tutorial
files, delete everything on the block diagram, and make a minimal
system, everything works great.  If I make the exact same minimal
system starting from a new project file, then it won't work. 
Obviously there is some setting already adjusted in the example
tutorial file that is not mentioned in the tutorial, but I can't
figure out what it is.  Has anyone else experienced this?

When it does not work, here is what happens.  After programming the
fpga, it runs momentarily (I can configure the led's to a given state
to verify, also the GERMS monitor spits out the correct system boot
id) and then the board defaults back to its original demo
configuration.

any advice on what I need to do to get a new project working would be
greatly appreciated.

-P

Article: 61386
Subject: MicroBlaze size
From: jon@beniston.com (Jon Beniston)
Date: 2 Oct 2003 15:05:48 -0700
Links: << >>  << T >>  << A >>
Xilinx's MicroBlaze CPU is listed as requiring 950 LUTs. Does this
include the register file, or does that use a block RAM?

Cheers,
JonB

Article: 61387
Subject: Re: Looking for recent Altera Quartus Verilog synthesis experience
From: H. Peter Anvin <hpa@zytor.com>
Date: 2 Oct 2003 15:11:09 -0700
Links: << >>  << T >>  << A >>
Followup to:  <349ef8f4.0310010922.254c437a@posting.google.com>
By author:    johnp3+nospam@probo.com (John Providenza)
In newsgroup: comp.arch.fpga
>
> I'm looking at doing a design with Apex-II parts and will
> probably need to use the Verilog synthesizer that comes with
> Quartus.   My last experience (multiple years ago) was very
> unpleasant - lots of synthesis bugs.
> 
> Has this gotten better?  
> 
> My experience with XST synthesis recently has been pretty good,
> so I'm debating about sticking with Xilinx for this next project
> or jumping to Altera since their Apex-II parts seem to fit my 
> application a bit better.
> 

I have recently used Altera's Cyclone device as well as supported a
legacy project with APEX20K.  The recent versions of Quartus seem to
do quite well; 2.2SP2 was OK and 3.0 seems to be better.

That being said, I have found that at least the webpack versions of
both the Xilinx and Altera packages have simulations that are all but
unusable.  It hasn't been a big deal for me as I have had access to
logic analyzers and have had debugging pins available on the board.

That being said, I doubt either of these tools would do a hugely good
job optimizing very complex "far from hardware" idioms.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 61388
Subject: Re: High-performance workstation
From: H. Peter Anvin <hpa@zytor.com>
Date: 2 Oct 2003 15:26:45 -0700
Links: << >>  << T >>  << A >>
Followup to:  <3f7af52e_1@newsfeed.slurp.net>
By author:    "DK" <dknews@ueidaq.com>
In newsgroup: comp.arch.fpga
> 
> could somebody suggest hi-performance workstation I can use to compile my
> designs in a fastest possible way?
> 
> I use Altera Quartus III and EP1C12Q240 device. It 90% full with most of the
> memory used. My Athlon XP 1800+ on ASUS A7V266-C motherboard with 512M of
> RAM takes 8/23 minutes to compile/fit. I did try dual Xeon 2200 on TYAN MB
> and it did only 5% faster..
> 
> Did somebody try Athlon 64-bit processor?
> 

You may want to get more and/or faster memory to begin with.

Both the recent 800 MHz FSB Pentium4's and the Opteron/Athlon64
on-chip memory controllers help in terms of memory bandwidth, too.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 61389
Subject: Re: ByteBlaster with USB<->PP adapter?
From: H. Peter Anvin <hpa@zytor.com>
Date: 2 Oct 2003 15:30:31 -0700
Links: << >>  << T >>  << A >>
Followup to:  <rvBeb.7724$JF5.5449@newssvr33.news.prodigy.com>
By author:    "Subroto Datta" <sdatta@altera.com>
In newsgroup: comp.arch.fpga
>
> Peter,
> 
>     I asked the experts at Altera, and they verified that using a parallel
> port to USB adapter will not work.
> 

Thanks.  I ended up finding a vendor which carried the proprietary
parallel port interface (really just a special cable plugging into a
nonstandard header on the motherboard -- had they used a standard
header the problem would have been solved long ago) for this machine
and could deliver it with a reasonable lead time; FedEx is supposed to
deliver it today.

A USB solution would have been nicer because of portability, of course.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Article: 61390
Subject: Re: Frustrations with Marketing
From: soar2morrow@yahoo.com (Tom Seim)
Date: 2 Oct 2003 15:47:05 -0700
Links: << >>  << T >>  << A >>
> 
> A larger company has the option of redesigning a product with an
> alternate FPGA if a vendor switches to the "dark side".  But the small
> company with lower volumes does not have that luxury until the problem
> becomes untenable.  Even then schedules may preclude such a change.  In
> those cases, the small business is just SOL.  That is why all new boards
> use as few parts as possible that can not be replaced.  I much prefer to
> not use serial proms of any kind and like to keep the FPGAs as generic
> as possible.  The Xilinx parts would have had an advantage on our new
> board, but they are not supporting modular configuration on the Spartan
> 3s and so they are the same to us as the Cyclone chips at this point.  

Way back when we designed with basic logic parts (good old 7400
series) that we could get from multiple vendors. Now we have to use
complex parts from single sources. The last design I was working on
before closing my company was from ZF Micro, which used NSM as their
only foundary. That was ok, I was told, because NSM was an investor in
ZF Micro. Guess what? NSM pulled the rug out from under ZF, and good
by MACH-Z. If I had been struggling to stay in business that, for
sure, would have sunk me.

The plus side of FPGAs is they are high volume parts and Xilinx does
have a good track record of producing parts for a long time period.
The proms are now multiple sourced, so they aren't the problem they
used to be.

That last joust with their marketing people left me in a slow burn...

Article: 61391
Subject: Apology to Martin Erudjian
From: "Vinh Pham" <a@a.a>
Date: Thu, 02 Oct 2003 23:50:50 GMT
Links: << >>  << T >>  << A >>
Martin,

I owe you an apology for how I treated you during last week's thread. Though
I disagreed with you, you didn't say anything that deserved being insulted.
I rashly formed a negative, and inaccurate, image of the type of person you
were and didn't treat you with respect. I failed miserably at being open
minded during my first few posts and ended up instead being condesending.
Naturally you were upset, but you handled things more graciously than I did.

So a long overdue, "I'm sorry Martin."


Regards,
Vinh

Since I can't help myself, I'll comment on something I noticed during last
week's ill fated thread. Martin made the comment that an engineer's job is
to deal with what ever crazy product specs get thrown at them. After
thinking about it, I guess if you work on a huge project, where your part of
the design is just one small box among hundreds, it's probably pointless to
argue about the specs you are given. Good luck finding the person who
created the specs. And you'd have even less luck convincing them to change
their minds because the specs they gave you are a results of specs someone
else gave them. Add to the fact that defense contractors have to work in
secrecy, you'll always be kept in the dark. In the end all you can do is
accept each assignment as a challenge to solve, and pray that someone in
upper management is more enlightened than you.

I guess those of us on smaller teams have the luxary of arguing over specs,
if we don't like what we hear. In fact it's our job to do a sanity check on
whatever we're told to do. But, it's probably not the right attitude to have
on a news group. It's not practical to expect a person to explain the entire
context of their question to our satisfaction. We just have to assume they
know what they are doing.



Article: 61392
Subject: Re: ISE 6.1 Dies Out of the Gate
From: Marc Guardiani <marc@guardiani.com>
Date: Thu, 02 Oct 2003 23:52:33 GMT
Links: << >>  << T >>  << A >>
What OS are you using? Xilinx dropped NT support with version 5.1i (even 
though it worked). Now with 6.1i I can't get Impact or Core Generator to 
run.

Tom Seim wrote:
> I just installed ISE 6.1 and tried to start a new project. The program
> responded by immediately crashing (several times, same result).
> Anybody else experience this?


Article: 61393
Subject: Graphics rendering revisited
From: "Vinh Pham" <a@a.a>
Date: Fri, 03 Oct 2003 00:00:06 GMT
Links: << >>  << T >>  << A >>
Since I was responsible for de-railling the original thread, let me be the
one to beat the horse back to life, since it has interesting potential.

The orignal question was: What algorithms can you use to generate live
video, that contains only line art (lines, rectangles, curves, circles,
etc.), if you can't use a frame buffer.

The benefit of using a frame buffer is flexibility. Namely you get random
access to any pixel on the screen. This opens up a wide range of algorithms
you can use to play the performance-area-complexity tradeoff game.

Without a frame buffer, you only have sequential access to your pixels. No
going back, no going forward. Quite Zen I suppose. Anyways, you lose access
to a lot of frame buffer algorithms, but some can still be used.

The conceptually easy ones to understand are math based algorithms, but
often they're expensive hardware wise. In the first section, I'll go over
implementation issues of the ideas that other people gave. Nothing super
complex.

The second section contains a more novel (maybe) approach based on pixel
spacing. It's conceptually harder to get a handle on, but has the potential
to require less resources. Unfortunately there are problems with the idea
that I haven't flushed out. Perhaps someone will have some ideas, or maybe
it'll inspire something better.

Oh yeah, I was too lazy to double check what I wrote, so there might be
problems. I also left things unfinished towards the end, I've got other
things to think about. Hopefully it gets the ball rolling though.

Regards,
Vinh


MATH ALGORITHMS
================

Lines
-----
There was a math based algorithm mentioned by Peter Wallace, where you use
y - (mx + c) = 0 and minx<x<maxx to decide whether to light up a pixel or
not. This algorithm works on a per-pixel basis, so it doesn't need random
access.

I like how Peter formatted the equation as y - (mx + c) = 0 rather than y =
(mx + c) since a compare against zero uses less logic than a compare against
any arbitrary number. On the other hand, y = (mx + c) might produce a design
that can be clocked faster, since you only have one adder. But Xilinx (and I
would assume the other vendors also) have pretty fast carry chains, so it
might not be an issue.

I would recommend using the form x - (my + c) = 0 instead. The reason is
because we're scanning through the pixels left-right, top-bottom. x is
always changing while y takes many clock cycles to change. Therefore you can
use a multicycle multiplier that trades off time for area savings. Also the
(my) term can be implemented with a constant-multiplier (a * K) which uses
less area than a regular multiplier (a * b).

Also because y changes slowly, it's better to use miny<y<maxy. But I guess
if you have a horizontal line, you'll need to use minx<x<maxx.

Oh yeah, (x) and (y) are integers, but (m) and (c) have a fractional part.
I'm not sure if this thinking is correct, but if we assume the resolution of
a TV screen is 512x512 (yes I know it's never that good), then (m) could be
as small as 1/512 and as large as 512, so we'd need 9 bits of integer and 9
bits of fraction (9.9). I suppose (c) would need the same thing. Cool,
that's 18-bits, just right for the dedicated multipliers in Xilinx and
Altera.

Curves
------
Instead of thinking of curves as smooth lines, you can imagine them being a
string of straight lines connected together (piece-wise linear). So
theoretically you can draw any curve "just" by varying (m) and (c) over
time. Of course the prospect of doing this inside the FPGA doesn't look
promising. You could use embedded RAMs to contain a table of these values,
but that could be a large table. Don't forget you would need a table for
each curve in your image. Also, you have to calculate those tables
somewhere. Naturally you'd use an external processor/host computer but
depending on the application, you might not have that luxary.

So that's probably a bad idea, and it might be better to use a math based
solution to curves.

Circles
-------
Roger Larsson's idea for a circle is also math based:

    (x - x0)^2 + (y - y0)^2 - r^2 = 0

We can expand this to:

    x^2 -2x0(x) + x0^2 + y^2 -2y0(y) + y0^2 - r^2 = 0

x0^2, y0^2, and r^2 are constants so they can be combined into one big
constant K:

    x^2 -2x0(x) + y^2 -2y0(y) + K = 0

(x^2 + y^2) is independent of x0,y0, and r, so it can be pre-computed into a
table K(x,y), that's can be used for all circles:

    -2x0(x) + -2y0(y) + K(x,y) + K = 0

Of course if you don't have the ram for it, you can break up K(x,y) into two
seperate, smaller tables and do K(x) + K(y). But do keep in mind that K(x,y)
can be used for all circles, so it might be a worthwhile use of RAM.

    -2y0(y) can use a multicycle-constant-multiplier while -2x0(x) would
need a pipelined-constant-multiplier.

Now if you got more ram to spare, you could take advantage of the fact
that -2x0(x) is independent of y, and vice versa for -2y0(y). Therefore you
could pre-compute them into their own tables and get:

    X0(x) + Y0(y) + K(x,y) + K = 0

Unfortunately you'd need a pair of those tables for every circle in your
image, and more importantly you'd also have to recompute them whenever your
parameters change.

So you can save some logic and improve performance if your parameters don't
change often. If they're pretty dynamic, you'll have to bite the bullet and
use up a lot of logic.

Dealing With Rational Numbers
-----------------------------
Our x and y values are integer only, but the lines and circles described by
the math formulas exist in a rational number space. I haven't given it much
thought, but you might have to be a little careful when comparing values
against zero. Close enough to zero would be more like it. But it might not
be a big problem.


PIXEL SPACING ALGORITHM
=======================

So far we've viewed things as a 2D array. If we think of things in as a 1D
vector, an alternative algorithm presents itself, though I'm not sure how
fruitful it may be in the long run.

BTW, 0 degrees = East, 90 = South, 180 = West, 270 = North.

If you drew a verticle line on the screen, and "rolled out" the pixels into
a vector, what you would see is a bunch of black pixels, evenly spaced. The
spacing would be equal to the width of the screen. Advanced apologies for
the clumsy notation.

Position of line-pixel i, p[i], is equal to:

    p[i] = p[i-1] + W

    W = width of screen

To relate the value of p to the x,y space:

    p = y*W + x
    x = p%W
    y = (p - x)/W

If you drew a 45 degrees diagonal, you would notice that the spacing was W +
1:

    p[i] = p[i-1] + W + 1

A 135 degrees diagonal would be:

    p[i] = p[i-1] + W - 1

So you would think you can draw a line of arbitrary angle simply by
following the formula:

    p[0] = starting point of line
    p[i] = p[i-1] + W + m
    m = function of x/y slope

Unfortunately you run into problems when abs(m)>1. I'll go into it later.
For now, let's assume this algorithm works perfectly for all occasions.

The nice thing about this is there's no multiplication involved, just
addition. You use a down counter and when it reaches zero, you create a
pixel and put a new value in the down counter. You'll need to take into
consideration that (m) can have a fractional part though.

Also, as I said earlier, you can think of a curve as a straight line whose
slope changes as you draw it. The nice thing here is we only have (m) to
worry about, and no (c). To create a circular arc, you'd only need to
increment (m) by a constant. The constant would control the radius of the
circle that the arc belongs to.

But alas, this algorithm doesn't work for all (m). Actually angles from 0 to
45 degrees isn't so bad. 135 to 180 is trickier. I also have a feeling it'd
be difficult to get "pretty" visual results with this.



Article: 61394
Subject: Re: Host-PCI Bridge
From: naveenk23@yahoo.com (naveen)
Date: 2 Oct 2003 17:34:51 -0700
Links: << >>  << T >>  << A >>
Hi,
   But if the host frequency is different from pci frequency we need
to keep asynchronous fifo, i guess. Am i true? In that case do we need
totally 4 fifos?
Also, can i get any document of implementation for host-pci bridge on
net? I searched but unable to find out.
In case of configuration transactions in host-pci bridge how will be
the flow?
naveen


Mario Trams <Mario.Trams@informatik.tu-chemnitz.de> wrote in message news:<blgnka$jie$1@anderson.hrz.tu-chemnitz.de>...
> naveen wrote:
> 
> > Hi group,
> >           I had a small clarification on Host-PCI Bridge. For Host-PCI
> > bridge design, PCI 2.3 specs. itself are enough or PCI-PCI Bridge
> 
> The PCI-to-PCI bridge spec is intended just for what it says. 
> It does not cover host-bridge issues. 
> That is at least true for the PCI-to-PCI bridge spec I've at hand here.
> Nevertheless, it cannot be a mistake to read this spec as well when
> designing other bridges.
> 
> > specs. are needed? Also in case of a Host-PCI Bridge, can we have
> > Memory Read line, Memory Read Multiple, Memory write and invalidate
> 
> Of course. Why not?
> 
> > commands executed? If we need to implement them do we need larger fifo
> > inside the bridge? Minimum of how many fifos do we need in a Host to
> > PCI Bridge Design?
> 
> It depends mainly on your host bus. If you don't want to support 
> delayed transaction completion (especially for reads but also for 
> writes) you do not need FiFos (or better say buffers) at all. 
> When there's some data not available, you could easily deassert 
> TRDY# until the data becomes available. 
> Btw., a PCI-to-PCI bridge is also not required to implement any 
> data buffers.
>  
> Of course, that is not the best idea in view of PCI bus efficiency.
> But finally it depends on the final application and how much time 
> you want invest to develop your host bridge (and how much space you
> have available in your FPGA ;-).
> 
> Regards,
> Mario

Article: 61395
Subject: Re: Apology to Martin Erudjian
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 03 Oct 2003 00:53:09 GMT
Links: << >>  << T >>  << A >>
Oh, boy... Vinh, you didn't need to apologize.  But I do appreciate the
gesture.  It's far too easy to get wires (messages, meaning, intent,
whatever) crossed over this form of communication.

I did not take offense to anything you said.  Yeah, maybe it bugged me a
bit.  But, when you are as busy as some of us are, you just can't let the
lack of fluidity and clarity in a non-real-time conversation medium get to
you or nothing gets done.  I try to practice what I preach.  The one thing
that I keep repeating is that there are very few failures of process and
that, if you dig deep enough, most failures are failures of design.  And,
with that comes my deep belief that one must be humble in understanding
one's limitations, accepting criticism and evaluating other's opinions.  I
could go on, but don't want to turn this into a huge philosophy thread.

So, I just thought it was funny that it seemed I couldn't explain myself out
of a paper bag.  I kept saying "these are the specs" and you (and others)
would say "never mind the specs, this is the better way to do it".  And
round-and-round in circles we went.  No big deal.

But thanks, I appreciate it.  I'll go ahead and take back all those bad
things I said about you as soon as my wife gets home.  I promise.  :-)


-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"






"Vinh Pham" <a@a.a> wrote in message
news:uR2fb.40556$5z.29015@twister.socal.rr.com...
> Martin,
>
> I owe you an apology for how I treated you during last week's thread.
Though
> I disagreed with you, you didn't say anything that deserved being
insulted.
> I rashly formed a negative, and inaccurate, image of the type of person
you
> were and didn't treat you with respect. I failed miserably at being open
> minded during my first few posts and ended up instead being condesending.
> Naturally you were upset, but you handled things more graciously than I
did.
>
> So a long overdue, "I'm sorry Martin."
>
>
> Regards,
> Vinh
>
> Since I can't help myself, I'll comment on something I noticed during last
> week's ill fated thread. Martin made the comment that an engineer's job is
> to deal with what ever crazy product specs get thrown at them. After
> thinking about it, I guess if you work on a huge project, where your part
of
> the design is just one small box among hundreds, it's probably pointless
to
> argue about the specs you are given. Good luck finding the person who
> created the specs. And you'd have even less luck convincing them to change
> their minds because the specs they gave you are a results of specs someone
> else gave them. Add to the fact that defense contractors have to work in
> secrecy, you'll always be kept in the dark. In the end all you can do is
> accept each assignment as a challenge to solve, and pray that someone in
> upper management is more enlightened than you.
>
> I guess those of us on smaller teams have the luxary of arguing over
specs,
> if we don't like what we hear. In fact it's our job to do a sanity check
on
> whatever we're told to do. But, it's probably not the right attitude to
have
> on a news group. It's not practical to expect a person to explain the
entire
> context of their question to our satisfaction. We just have to assume they
> know what they are doing.
>
>



Article: 61396
Subject: Re: Graphics rendering revisited
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 03 Oct 2003 01:08:25 GMT
Links: << >>  << T >>  << A >>
Lot's of good stuff.  I'll have to read it later tonight.  I just wanted to
modify one assumption you made.  Resolution.  I'll be working at 4K x 2.5K
and maybe as high as 4K x 4K and 60 frames per second soon.  My current work
is at 2K x 1.5K, 60 fps though.

Here's a product I finished recently that's working at 1920 x 1200 and
60fps.
http://www.ecinemasys.com/products/display/edp100/pdf/edp100_preliminary.pdf

The design is 100% mine, electrical, board layout, mechanical, FPGA,
firmware, GUI, etc.

Some of the highlights: Two 1.485GHz inputs,  two 1.485GHz outputs,  165MHz
DVI output,  USB, lots of interesting real-time processing going on.

Yes, it has a frame buffer (four frames actually).  No, it shouldn't be used
to render graphics primitives.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"



"Vinh Pham" <a@a.a> wrote in message
news:a_2fb.40558$5z.28069@twister.socal.rr.com...
> Since I was responsible for de-railling the original thread, let me be the
> one to beat the horse back to life, since it has interesting potential.
>
> The orignal question was: What algorithms can you use to generate live
> video, that contains only line art (lines, rectangles, curves, circles,
> etc.), if you can't use a frame buffer.
>
> The benefit of using a frame buffer is flexibility. Namely you get random
> access to any pixel on the screen. This opens up a wide range of
algorithms
> you can use to play the performance-area-complexity tradeoff game.
>
> Without a frame buffer, you only have sequential access to your pixels. No
> going back, no going forward. Quite Zen I suppose. Anyways, you lose
access
> to a lot of frame buffer algorithms, but some can still be used.
>
> The conceptually easy ones to understand are math based algorithms, but
> often they're expensive hardware wise. In the first section, I'll go over
> implementation issues of the ideas that other people gave. Nothing super
> complex.
>
> The second section contains a more novel (maybe) approach based on pixel
> spacing. It's conceptually harder to get a handle on, but has the
potential
> to require less resources. Unfortunately there are problems with the idea
> that I haven't flushed out. Perhaps someone will have some ideas, or maybe
> it'll inspire something better.
>
> Oh yeah, I was too lazy to double check what I wrote, so there might be
> problems. I also left things unfinished towards the end, I've got other
> things to think about. Hopefully it gets the ball rolling though.
>
> Regards,
> Vinh
>
>
> MATH ALGORITHMS
> ================
>
> Lines
> -----
> There was a math based algorithm mentioned by Peter Wallace, where you use
> y - (mx + c) = 0 and minx<x<maxx to decide whether to light up a pixel or
> not. This algorithm works on a per-pixel basis, so it doesn't need random
> access.
>
> I like how Peter formatted the equation as y - (mx + c) = 0 rather than y
=
> (mx + c) since a compare against zero uses less logic than a compare
against
> any arbitrary number. On the other hand, y = (mx + c) might produce a
design
> that can be clocked faster, since you only have one adder. But Xilinx (and
I
> would assume the other vendors also) have pretty fast carry chains, so it
> might not be an issue.
>
> I would recommend using the form x - (my + c) = 0 instead. The reason is
> because we're scanning through the pixels left-right, top-bottom. x is
> always changing while y takes many clock cycles to change. Therefore you
can
> use a multicycle multiplier that trades off time for area savings. Also
the
> (my) term can be implemented with a constant-multiplier (a * K) which uses
> less area than a regular multiplier (a * b).
>
> Also because y changes slowly, it's better to use miny<y<maxy. But I guess
> if you have a horizontal line, you'll need to use minx<x<maxx.
>
> Oh yeah, (x) and (y) are integers, but (m) and (c) have a fractional part.
> I'm not sure if this thinking is correct, but if we assume the resolution
of
> a TV screen is 512x512 (yes I know it's never that good), then (m) could
be
> as small as 1/512 and as large as 512, so we'd need 9 bits of integer and
9
> bits of fraction (9.9). I suppose (c) would need the same thing. Cool,
> that's 18-bits, just right for the dedicated multipliers in Xilinx and
> Altera.
>
> Curves
> ------
> Instead of thinking of curves as smooth lines, you can imagine them being
a
> string of straight lines connected together (piece-wise linear). So
> theoretically you can draw any curve "just" by varying (m) and (c) over
> time. Of course the prospect of doing this inside the FPGA doesn't look
> promising. You could use embedded RAMs to contain a table of these values,
> but that could be a large table. Don't forget you would need a table for
> each curve in your image. Also, you have to calculate those tables
> somewhere. Naturally you'd use an external processor/host computer but
> depending on the application, you might not have that luxary.
>
> So that's probably a bad idea, and it might be better to use a math based
> solution to curves.
>
> Circles
> -------
> Roger Larsson's idea for a circle is also math based:
>
>     (x - x0)^2 + (y - y0)^2 - r^2 = 0
>
> We can expand this to:
>
>     x^2 -2x0(x) + x0^2 + y^2 -2y0(y) + y0^2 - r^2 = 0
>
> x0^2, y0^2, and r^2 are constants so they can be combined into one big
> constant K:
>
>     x^2 -2x0(x) + y^2 -2y0(y) + K = 0
>
> (x^2 + y^2) is independent of x0,y0, and r, so it can be pre-computed into
a
> table K(x,y), that's can be used for all circles:
>
>     -2x0(x) + -2y0(y) + K(x,y) + K = 0
>
> Of course if you don't have the ram for it, you can break up K(x,y) into
two
> seperate, smaller tables and do K(x) + K(y). But do keep in mind that
K(x,y)
> can be used for all circles, so it might be a worthwhile use of RAM.
>
>     -2y0(y) can use a multicycle-constant-multiplier while -2x0(x) would
> need a pipelined-constant-multiplier.
>
> Now if you got more ram to spare, you could take advantage of the fact
> that -2x0(x) is independent of y, and vice versa for -2y0(y). Therefore
you
> could pre-compute them into their own tables and get:
>
>     X0(x) + Y0(y) + K(x,y) + K = 0
>
> Unfortunately you'd need a pair of those tables for every circle in your
> image, and more importantly you'd also have to recompute them whenever
your
> parameters change.
>
> So you can save some logic and improve performance if your parameters
don't
> change often. If they're pretty dynamic, you'll have to bite the bullet
and
> use up a lot of logic.
>
> Dealing With Rational Numbers
> -----------------------------
> Our x and y values are integer only, but the lines and circles described
by
> the math formulas exist in a rational number space. I haven't given it
much
> thought, but you might have to be a little careful when comparing values
> against zero. Close enough to zero would be more like it. But it might not
> be a big problem.
>
>
> PIXEL SPACING ALGORITHM
> =======================
>
> So far we've viewed things as a 2D array. If we think of things in as a 1D
> vector, an alternative algorithm presents itself, though I'm not sure how
> fruitful it may be in the long run.
>
> BTW, 0 degrees = East, 90 = South, 180 = West, 270 = North.
>
> If you drew a verticle line on the screen, and "rolled out" the pixels
into
> a vector, what you would see is a bunch of black pixels, evenly spaced.
The
> spacing would be equal to the width of the screen. Advanced apologies for
> the clumsy notation.
>
> Position of line-pixel i, p[i], is equal to:
>
>     p[i] = p[i-1] + W
>
>     W = width of screen
>
> To relate the value of p to the x,y space:
>
>     p = y*W + x
>     x = p%W
>     y = (p - x)/W
>
> If you drew a 45 degrees diagonal, you would notice that the spacing was W
+
> 1:
>
>     p[i] = p[i-1] + W + 1
>
> A 135 degrees diagonal would be:
>
>     p[i] = p[i-1] + W - 1
>
> So you would think you can draw a line of arbitrary angle simply by
> following the formula:
>
>     p[0] = starting point of line
>     p[i] = p[i-1] + W + m
>     m = function of x/y slope
>
> Unfortunately you run into problems when abs(m)>1. I'll go into it later.
> For now, let's assume this algorithm works perfectly for all occasions.
>
> The nice thing about this is there's no multiplication involved, just
> addition. You use a down counter and when it reaches zero, you create a
> pixel and put a new value in the down counter. You'll need to take into
> consideration that (m) can have a fractional part though.
>
> Also, as I said earlier, you can think of a curve as a straight line whose
> slope changes as you draw it. The nice thing here is we only have (m) to
> worry about, and no (c). To create a circular arc, you'd only need to
> increment (m) by a constant. The constant would control the radius of the
> circle that the arc belongs to.
>
> But alas, this algorithm doesn't work for all (m). Actually angles from 0
to
> 45 degrees isn't so bad. 135 to 180 is trickier. I also have a feeling
it'd
> be difficult to get "pretty" visual results with this.
>
>
>



Article: 61397
Subject: Re: Digesting runs of ones or zeros "well"
From: johnhandwork@mail.com (John_H)
Date: 2 Oct 2003 18:31:18 -0700
Links: << >>  << T >>  << A >>
Goran Bilski <goran@xilinx.com> wrote in message news:<blhm91$h0f1@cliff.xsj.xilinx.com>...
> Hi,
> 
> Why not use the carry-chain?
> 
> You can do any kind of detection on that primitive and it will save you LUTs
> 
> Göran

I tried that approach earlier today but I wasn't getting the carry
chain I was trying to infer.  The Virtex-IIs started getting poorer at
getting on/off carry chains timing-wise relative to the general logic
resources so I was trying to get general logic to work; I suspect
Spartan-3s are similar.  If I go straight to register, I would need 4
LUTs to go into the register through the XORCY instead of the natural
XORCY so the logic savings isn't a given to achieve the speed but I
could keep it to 3 LUTs with a small routing hit.

I believe I'd need to implement all the carry chain primitives through
the generate block, including the MUXCYs and XORCY elements because
the synthesizer sees that "oh, it's a short chain" and converts my
simple arithmetic form to a cascade of LUTs rather than the carry
chain.  I tried my tricks, I stopped pursuing.

Maybe I'll try to coax it again tomorrow.  Thank goodness for that
generate!

Article: 61398
Subject: Re: Evaluation time of Emac Core?
From: John Williams <jwilliams@itee.uq.edu.au>
Date: Fri, 03 Oct 2003 11:42:43 +1000
Links: << >>  << T >>  << A >>
Don wrote:
> Hi I am using the EDK 3.2 to build a MicroBlaze-design with an ethernet-MAC
> attached. When synthesizing my design it gives me a warning: "Emac Licensing
> in effect".
> My question is, how long (hours) can I evaluate the core before the FPGA
> needs to be reloaded?

I left a microblaze uClinux kernel running over night with the 
evaluation xemac core  - I could still telnet into the board the 
following morning...

not a firm answer, but should give you some idea.

Regards,

John


Article: 61399
Subject: Re: Quartus II tutorial vs the real world
From: "Jerry" <nospam@nowhere.com>
Date: Thu, 2 Oct 2003 22:11:28 -0400
Links: << >>  << T >>  << A >>
ITS NOT JUST ME!!!!!

THANK YOU FOR POSTING.

I too am having problems with the NIOS eval board. I too have worked the
tutorials and I too have modified the tutorials as you. See the post NIOS
and OCI.

My FAE did call me back. I'm doing other things but come Monday I'll be back
on the eval board
trying my darnest to get it to do real world stuff.

Keep ya all posted.

Jer

"pjjones" <hjones1380@hotmail.com> wrote in message
news:2e1d5e40.0310021405.1c01b331@posting.google.com...
> I'm working with a Stratix EP1S40 evaluation baord, after going
> through the tutorial successfully (there is no mention of pin
> assignments in the tutorial, that would have been a nice touch i
> think), I tried a similar nios processor design from scratch to no
> avail.
>
> What I've figured out is this:  if I begin with the given tutorial
> files, delete everything on the block diagram, and make a minimal
> system, everything works great.  If I make the exact same minimal
> system starting from a new project file, then it won't work.
> Obviously there is some setting already adjusted in the example
> tutorial file that is not mentioned in the tutorial, but I can't
> figure out what it is.  Has anyone else experienced this?
>
> When it does not work, here is what happens.  After programming the
> fpga, it runs momentarily (I can configure the led's to a given state
> to verify, also the GERMS monitor spits out the correct system boot
> id) and then the board defaults back to its original demo
> configuration.
>
> any advice on what I need to do to get a new project working would be
> greatly appreciated.
>
> -P





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