Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
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, /MikhailArticle: 61376
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 WorksArticle: 61377
"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... JakeArticle: 61378
> 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
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. SteveArticle: 61380
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 TreselerArticle: 61381
"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
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: 61384Allan 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
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. -PArticle: 61386
Xilinx's MicroBlaze CPU is listed as requiring 950 LUTs. Does this include the register file, or does that use a block RAM? Cheers, JonBArticle: 61387
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-64Article: 61388
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-64Article: 61389
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-64Article: 61390
> > 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
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
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
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: 61394Hi, 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, > MarioArticle: 61395
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
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
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
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, JohnArticle: 61399
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:
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