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
You could try to break your process into two seperate ones. Sometimes
"rewording" your code has an effect on the synthesizer:
process(clk,inf)
begin
if rising_edge(clk) then
outf <= inf;
end if;
end process;
process(sync_reset,clk_ena,outf)
begin
if sync_reset = '1' then
inf <= '0';
elsif clk_ena = '1' then
inf <= '1';
else
inf <= outf;
end if;
end process;
If you get desperate, you can manually instantiate a FF. It won't be as
portable, of course.
From what code you have shown us, I can't see why the XST is doing what it's
doing, unless the logic generating sync_reset and clk_ena is somehow causing
you problems. You could run a quick experiment and synthesize only that
piece of FF code, in your post, making sync_reset and clk_ena into ports, to
see what the synthesizer does.
Best of luck.
Regards,
Vinh
Article: 61026I've just tried synthesizing the same code for Spartan II. The result is similar in terms of using REV pin, however in this case the D and CE are (correctly in my opinion) tied to GND! So, at the very least the synthesis results are not consistent and I still think the netlist for Virtex II is not valid. /MikhailArticle: 61027
I agree with Mikhail. The real problem is CE being connected to VCC. If it was connected to GND (doesn't matter what D is connected to), things would be fine.Article: 61028
> > produces a ripple counter? Yes, No? > > Looks like a synchronous counter to me. If he's using Icarus, older versions (a couple of months back) prior to the RoSync fix for the VCD writer would dump a value change entry per bitchange. As such, you could observe the value updating from the LSB->MSB if you'd look at the VCD file in a text editor. http://archives.seul.org/geda/dev/Apr-2003/msg00060.html http://archives.seul.org/geda/dev/Apr-2003/msg00061.html <etc> -tArticle: 61029
Thanks, Vinh. Just to clarify, I am using ISE 5.2.03i. Can anyone with 6.1
check this out? Here is the code:
entity weirdff is
Port ( clk : in std_logic;
clk_ena : in std_logic;
sync_reset : in std_logic;
outf : out std_logic);
end weirdff;
architecture rtl of weirdff is
begin
process(clk)
begin
if rising_edge (clk) then
if sync_reset ='1' then
outf <= '0';
elsif clk_ena ='1' then
outf <= '1';
end if;
end if;
end process;
end rtl;
Synthesize it for Spartan II and Virtex II and see the results in the FPGA
Editor....
/Mikhail
"Vinh Pham" <a@a.a> wrote in message
news:3S_cb.5816$Ak3.268@twister.socal.rr.com...
> I agree with Mikhail. The real problem is CE being connected to VCC. If
it
> was connected to GND (doesn't matter what D is connected to), things would
> be fine.
>
>
Article: 61030> I would expect that the cost of a cheap FPGA + cheap memory + simple > design would be much less than the cost of a larger FPGA + complex > design. I agree with Allan here. A simple design has the best chance of succeeding and will probably be cheaper. It's hard to imagine memory being that cost prohibitive. What prices do you have for your FPGA, memory, and other components?Article: 61031
dgleeson-2@utvinternet.com (Denis Gleeson) writes: > Ok I was confused. > > I did implement a synchronous counter as everybody points out. > The glitches are due to routing delays in the FPGA. > > Now Im not confused any more. > > All I need now is to find verilog for a 16 bit gray code counter. I once wrote a program to explore gray code sequences (more than ten years ago). You can download it from: http://gustad.com/pub/eda/jc.tgz It will generate Verilog for part of a case statement. For three bits you could do: ./jct 3 ./jct is starting up case 10'b000: ns = 10'b001; case 10'b001: ns = 10'b011; case 10'b011: ns = 10'b010; case 10'b010: ns = 10'b110; case 10'b110: ns = 10'b111; case 10'b111: ns = 10'b101; case 10'b101: ns = 10'b100; case 10'b100: ns = 10'b000; ./jct is finishing up There's also another program called jc which will generate all possible sequences, but you have to build the set of numbers in the source. Here's the output for three bits Set permute 0 1 3 2 6 4 5 7 0 1 3 2 6 7 5 4 circular 0 1 3 7 5 4 6 2 circular 0 1 5 4 6 2 3 7 0 1 5 4 6 7 3 2 circular 0 1 5 7 3 2 6 4 circular 0 2 3 1 5 4 6 7 0 2 3 1 5 7 6 4 circular ... 7 6 4 0 2 3 1 5 circular 7 6 4 5 1 0 2 3 circular 7 6 4 5 1 3 2 0 The program will give some errors/warning if compiled on a recent g++, but this should be easy to fix by moving the "unsigned int i" out of the for loop. C++ wasn't even a standard when I started programming in C++ in the late 80's. The reference was the "cfront" implementation by AT&T. Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 61032
I don't think there is any official way of doing it in VHDL. All I/O's need to be declared in the top-hierarchy file. The only way I can think of would be through adding a probe pin in the FPGA Editor, however this probably won't work either because your logic will get optimized out since if there is no port, there is no need to consider that signal... /Mikhail "Andy Greensted" <ajg112@york.ac.uk> wrote in message news:bl1p1s$9ml$1@pump1.york.ac.uk... > Hi All, > > XILINX Sparten2e - ISE5.1i > > Is is possible to created a LOC'd IO connection for signals internal to a > VHDL module? > > I've created a VHDL Module that has some normal port IO, however it also > contains some signals that are specific only to the module. These signals > need to be routed to FPGA pins - and therefore I'd like a LOC constraint on > them. > > If I declare these signals in the entity port desciption, then just apply > the LOC attribute, the signals are still 'visible' on the module symbol. > They do not need to be. So can I internally LOC these signals? Hope that > makes sense. Here's an example with some VHDL of what I'm trying to do. > > The input is dataIn - (Hopefully) LOC'd to pin 12. It's buffered, then > connected to a synchronizer (just a double flip flop). The only 'visible' > IO is dataOut and clk. > > When I try this XST sees dataIn as unconnected, so ties it to ground. Then > during translate, it get's all upset because the IBUF is drived from the > IPAD, but is also tied :-( What's the official way of doing this? > > Any help would really make my life A LOT easier. Cheers > > > library IEEE; > use IEEE.STD_LOGIC_1164.ALL; > use IEEE.STD_LOGIC_ARITH.ALL; > use IEEE.STD_LOGIC_UNSIGNED.ALL; > > library UNISIM; > use UNISIM.VComponents.all; > > entity interface is > Port ( clk : in std_logic; > dataOut : out std_logic); > > end interface; > > architecture Structural of interface is > > component IBUF > port ( O : out std_logic; > I : in std_logic ); > end component; > > component SYNC > port ( dataIn : in std_logic; > dataOut : out std_logic; > clk : in std_logic ); > end component; > > attribute box_type : string; > attribute box_type of BUFG : component is "black_box"; > > attribute LOC : string; > attribute LOC of dataBuf : label is "P12"; > > signal dataIn : std_logic; > signal dataIn_b : std_logic; > begin > > ------------ > -- Buffer -- > ------------ > dataBuf : IBUF > port map ( I => dataIn, > O => dataIn_b); > > ---------------- > -- Syncronize -- > ---------------- > dataSync : SYNC > port map ( dataIn => dataIn_b, > dataOut => dataOut, > clk => clk); > > end Structural; >Article: 61033
Mikhail,
I see your point!
The following code will address the problem
tested against F.31i
library ieee;
use ieee.std_logic_1164.all;
entity ff_test is
port (clk, sync_reset, clk_ena : in std_logic;
outf : inout std_logic
);
end entity ;
architecture test of ff_test is
signal din : std_logic := '1' ;
attribute keep : boolean ;
attribute keep of din : signal is true ;
begin
process(clk)
begin
if (clk'event and clk = '1') then
if sync_reset='1' then
outf <= '0';
elsif clk_ena='1' then
outf <= din ;
else
outf <= outf ;
end if;
end if;
end process;
end architecture test ;
MM wrote:
> Hi all,
>
> I want the code below to synthesize as a FF with a sync reset and CE,
> however XST does something quite different (target technology is Virtex II).
> It routes my clk_ena signal to the REV pin and ties D and CE to VCC. The
> sync_reset is recognized OK and gets routed correctly to the SR pin. I
> realize that if I had a "regular" input signal instead of '1' under the
> clock enable statement it would have worked fine, but what should I do if I
> need to tie it to VCC?
>
> process(clk)
> begin
> if rising_edge (clk) then
> if sync_reset='1' then
> outf <= '0';
> elsif clk_ena='1' then
> outf <= '1';
> end if;
> end if;
> end process;
>
> Thanks,
> /Mikhail
Article: 61034Folks, It seems that I owe Xilinx an apology... I overlooked little muxes with invertors enabled at the CE and D inputs for Virtex II architecture. So, the CE and D are not really tied to VCC and I have nobody to blame for my problem:( /MikhailArticle: 61035
Hi Rick,
Stuff below:-
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7257C6.91BECAD0@yahoo.com>...
> Symon wrote:
> >
> > Hi Rick,
> > OK, I suppose 'MUST' isn't strictly accurate, you might not care
> > whether the design works or not! How about 'SHOULD' instead? ;-) Those
> > signals bouncing back and forth may not affect the circuits functional
> > operation, but what are you gonna do when it happens on a 5 inch, 32
> > bit data bus and you can't pass the CE/FCC mark tests? Sell it in
> > Elbonia, I guess!
>
> Is there a good market there? If a 5 inch 32 bit data bus without
> termination precludes passing CE/FCC RFI tests, then no PC would ever be
> sold. Few RFI issues are solved purely at the PC board level. In US
> commercial markets, the requirements are very different than consumer
> markets as well.
>
PC's only pass because they're in metal boxes. Not everyone has that
luxury!
>
> > As for ground bounce, if those diodes are dumping energy, be sure
> > you've decoupled the Rx IC as well as the Tx one! Generally, it's
> > better not to have to rely on the diodes, don't you think? You end up
> > trading decoupling capacitors for termination resistors.
>
> That is assuming that the diodes would be triggered. I seem to recall
> that the basic analysis done here showed that this was unlikely.
>
> > I'm not saying simulate every trace. Simulate one, and layout the
> > rest accordingly, as I think Austin says in a parallel post. Check the
> > PCB layout very carefully, watching out for traces that don't comply
> > with your SI design. I like Austin's idea of adopting a standard
> > (HSTL, SSTL, PCI), makes it easy.
>
> That is the part I am not clear about. These traces are all individual
> circuits. If you have the luxury of a lot of open board space to route
> straight lines here and there, then sure, you can make each one very
> similar. On a small, tight board it will be very difficult to make them
> that similar. If the signal is critical enough to require a simulation,
> then I expect I would need to simulate each of them.
>
What I do is arrange the signal pins on my FPGA so they connect 'one
to one' to other devices. Worry about pin swapping signals inside the
FPGA fabric. Together with careful board layout, you can keep the
buses a nice regular structure. This keeps large numbers of tracks
similar. The PCB layout people like me too!! To me this is a BIG
advantage that FPGAs offer.
> I am surprized that the Spartan 3 chips are so sensitive to over and
> undershoot that this has become a major issue. I have seen lots of high
> speed boards and none had FPGAs or any other chips that needed this
> degree of analysis to prevent damage.
>
> --
>
I don't think the Spartan-3 is especially oversensitive per se, just
that low voltage, small geometry parts are likely victims. It's
something to consider in more and more designs as time goes by. The
FPGA is often the device that connects a lot of disparate pieces with
varying signalling standards together so deserves special attention.
Anyway, I've enjoyed (am enjoying) our discussion, I'm sure any
(hopefully) small offence caused by some posters' robust I/O and
others' sensitive inputs can be put down to a mismatch in transmission
standards!! Maybe we should terminate this before the noise going back
and forth gets above the absolute maximum tolerance!
All the best mate, Syms.
Article: 61036"MM" <mbmsv@yahoo.com> wrote in message news:<bl1i00$76rai$1@ID-204311.news.uni-berlin.de>... > Hi all, > > I want the code below to synthesize as a FF with a sync reset and CE, > however XST does something quite different (target technology is Virtex II). > It routes my clk_ena signal to the REV pin and ties D and CE to VCC. The > sync_reset is recognized OK and gets routed correctly to the SR pin. I > realize that if I had a "regular" input signal instead of '1' under the > clock enable statement it would have worked fine, but what should I do if I > need to tie it to VCC? > > process(clk) > begin > if rising_edge (clk) then > if sync_reset='1' then > outf <= '0'; > elsif clk_ena='1' then > outf <= '1'; > end if; > end if; > end process; This is interesting. Carefully re-read the data sheet. Page 12 of the "Virtex II Platform FPGAs: Detailed Description" data sheet says that, "if SR is used, the BY input is used to force the storage element into the opposite state." In your case, SR is used as the sync reset. And you're not using clk_ena as a clock enable, really, you're just using it as a synchronous set, which the tool correctly recognizes and puts on REV (through BY). However, the odd thing is that both CE and D are set high in the flop, which should result in the output of the flop _always_ high (except when sync_reset) asserted. What are your pre- and post-route simulations telling you? =aArticle: 61037
prashantj@usa.net (Prashant) wrote in message news:<ea62e09.0309251307.6cadf3a1@posting.google.com>... > Hi, > > I have a design that was compiled in Quartus II 2.0 (SP2) and used > 22,000 logic elements on the APEX20K1500E device. I compiled the same > design in Quartus II 2.2 (SP2) and it takes 42,000 logic elements !! > Has anyone seen such strange behavior with Quartus II 2.2 ? If so, how > is this bug fixed ? > > Thanks, > Prashant > > PS : Also, in the summary report, Quartus II 2.0 shows 85/493 pins > used, while Quartus II 2.2 shows 85/488 pins, for the same device. Are you absolutely sure you implemented the exact same code? =-aArticle: 61038
dgleeson-2@utvinternet.com (Denis Gleeson) wrote in message news:<184c35f9.0309260508.672fc895@posting.google.com>... > Ok I was confused. > > I did implement a synchronous counter as everybody points out. > The glitches are due to routing delays in the FPGA. You needn't be concerned with the glitches if the counter outputs will be used synchronously, assuming, of course, that the counter outputs are stable by the next clock edge. Your static timing analyzer will tell you if you win or not. --aArticle: 61039
praveen@cg-coreel.com (praveen) wrote in message news:<2dfdd359.0309252252.5c0071c3@posting.google.com>... > hi folks, > > i am using virtex2p in my design , now i want to estimate > the total design power. Xilinx provides a spread sheet for power > calculation.what is the range of power consumption for good designs > which are working in the field which are using virtex2p device. and > what are the appropriate heat sinks to be provided if power > consumption is more. > > could somebody help me out in this I'm sure that if you were to call Xilinx, they're be more than happy to help you. -aArticle: 61040
> However, the odd thing is that both CE and D are set high in the flop, > which should result in the output of the flop _always_ high (except > when sync_reset) asserted. What are your pre- and post-route > simulations telling you? I will repeat my apology to Xilinx and that I was wrong as I overlooked little muxes with invertors enabled at the CE and D inputs for Virtex II architecture. /MikhailArticle: 61041
Vinh, Please re-read my original post. This isn't complicated, really. This is NOT a question of evaluating the best hardware configuration to be used in drawing lines/circles on screen. It is one of the most basic engineering concepts: given a constraint, look for a solution. The constraint here is simple: No frame buffering. Only a few clocks's delay allowed. Simple drawing primitives: lines, circles, rectangles, triangles. Nothing else. No shading or lighting effects, plain white pixels would do. Given the above, any frame buffer based solution is simply irrelevant. Continuing to insist that a frame buffer would be a "better" approach is missing the point. That solution is simply not an option. Cost has nothing to do with it. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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:75%cb.5818$Ak3.3455@twister.socal.rr.com... > > I would expect that the cost of a cheap FPGA + cheap memory + simple > > design would be much less than the cost of a larger FPGA + complex > > design. > > I agree with Allan here. A simple design has the best chance of succeeding > and will probably be cheaper. It's hard to imagine memory being that cost > prohibitive. What prices do you have for your FPGA, memory, and other > components? > >Article: 61042
Only the most primitive shapes: lines, circles, rectangles, triangles (connected lines, really). No shading, no geometry, rasterization or texture. I have my own algorithms that, for the most part, work well. I was just trying to figure out if there was something interesting out there that I should be considering. I guess this is esoteric enough that it simply isn't out there. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu" "Bob Feng" <bfeng@sgi.com> wrote in message news:bl1spf$9osjs$1@fido.engr.sgi.com... > A frame buffer is simply a huge LUT(sort of) in which every pixel is > corresponding to the one on the screen. The reason to have it is simply > because of the huge effort to generate them in the front end. > > Bypassing the frame buffer means you need to have some fast algorithm to do > some fast drawing. Correct? > > If you only do lines or individual pixels, I agree with you they are simple. > You may also get away with circles or ovels. But for real graphics(I am > talking about geometry+rasterization+texture), you have no way to do so. > > Circles and Ovels may be done via LUT. But your VTC design in FPGA maybe > chanllenge. It should be fun though. > > ---Bob > > "Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message > news:AIRcb.6331$0K3.502@newssvr27.news.prodigy.com... > > "Bob Feng" wrote: > > > Your comments after your question do not make sense to me. > > > > You are thinking computers. I'm thinking video. > > > > Here's one possible scenario. You are required to overlay graphics > > (primitives: lines, circles, etc.) and text onto an incoming video feed, > > which is then output in the same format. The allowable input to output > > delay is in the order of just a few clocks --if that much at all-- not > > frames, not lines, a few clocks at best. > > > > Frame buffers are out of the question, of course. In addition to this, > due > > to cost constraints, you are not allowed to have rendering memory for the > > graphics overlay. You, therefore, must render text and graphics on the > fly, > > in real time, as the signal flows through. > > > > Text and horizontal/vertical lines are pretty easy to deal with. You > start > > getting into circles and rotated lines or polygons and it gets interesting > > real fast. In contrast to this, rendering these primitives to a frame > > buffer (in a "traditional" computer-type application) is a no-brainer. > > > > > Usaually a frame buffer is where you render. And then it goes through a > > DAC > > > and several video timing control units and reaches a CRT via a VGA or > 13w3 > > > connector. > > > > So, in the above context, nothing goes through a DAC. The video feed > > (assume analog) simply goes through some analog switches that, under FPGA > > control, select, on a pixel-by-pixel basis, from among the incoming video > > signal and a set of pre-established analog values (say white, to keep it > > simple). > > > > > > Hope this example clarifies it for you. > > > > -- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Martin Euredjian > > > > To send private email: > > 0_0_0_0_@pacbell.net > > where > > "0_0_0_0_" = "martineu" > > > > > >Article: 61043
rickman <spamgoeshere4@yahoo.com> wrote in message news:<3F7257C6.91BECAD0@yahoo.com>... > That is the part I am not clear about. These traces are all individual > circuits. If you have the luxury of a lot of open board space to route > straight lines here and there, then sure, you can make each one very > similar. On a small, tight board it will be very difficult to make them > that similar. If the signal is critical enough to require a simulation, > then I expect I would need to simulate each of them. The traces may not actually be individual circuits! While Austin (and others, including myself) advocate SI simulations to show the effects of terminations on line ringing and what not, what can _really_ bite you in the ass is crosstalk. In one particular case, there was an issue with crosstalk from a data bus affecting a nearby reset line. When a simulation was finally run, the problem was obvious. So, yeah, I'd say that not bothering to simulate these lines because they weren't clocks and because "the signals can bounce around for a couple of ns" was a bad idea. The time spent simulating upfront is well worth the investment. You simulate your FPGA logic, because you'd rather spend the time in front of the computer, rather than in the lab with a 'scope probe? Same thing here, except that a board spin is a lot more expensive than reprogramming that ISP EEPROM. Oh, yeah, the 'scopes and probes required to really see these types of problems in the lab cost more than the SI software. > I am surprized that the Spartan 3 chips are so sensitive to over and > undershoot that this has become a major issue. I have seen lots of high > speed boards and none had FPGAs or any other chips that needed this > degree of analysis to prevent damage. Perhap Xilinx are simply erring on the side of caution. They're informing the user of potential issues when they can be dealt with -- in the design phase -- rather than when boards are RMAed and customers are pissed. In any event, I think Austin's tone was one of frustration -- after all, he's trying to help you! Basically, he's saying that if you do the simulations up front, your board can be designed such that these potential problems don't turn out to be actual problems. --aArticle: 61044
"Vinh Pham" <a@a.a> wrote in message news:<zBRcb.15408$5z.9033@twister.socal.rr.com>... > Your problem could be the fact that your sensitivity list is incomplete. > Replace this: > > A0: process(Clock) > > With: > > A0: process(Clock,Dat) > > An incomplete sensitivity list can cause strange simulation results in > Aldec. You would think Aldec would give you a warning when your sensitivity > list is incomplete. It may not be incomplete; see below. > So what I end up doing is enter my design in Aldec. > Synthesize the design in Synplicity, which does give you a warning. Fix the > sensitivity lists. THEN simulate it in Aldec. Um, this is wrong -- if he's trying to build a flip-flop, the ONLY signals that should be in the sensitivity list are the clock and perhaps an async set/reset. Remember that a clocked flop's output doesn't change when the input changes! --aArticle: 61045
> Please re-read my original post. This isn't complicated, really. This is > NOT a question of evaluating the best hardware configuration to be used in > drawing lines/circles on screen. It is one of the most basic engineering > concepts: given a constraint, look for a solution. > > The constraint here is simple: No frame buffering. Only a few clocks's > delay allowed. Simple drawing primitives: lines, circles, rectangles, > triangles. Nothing else. No shading or lighting effects, plain white pixels > would do. > > Given the above, any frame buffer based solution is simply irrelevant. > Continuing to insist that a frame buffer would be a "better" approach is > missing the point. That solution is simply not an option. Cost has nothing > to do with it. I fear my lack of experience in video applications prevents me from seeing your point. And history is full of examples of people saying something is impossible until a brave soul proves them wrong. With that you have my best wishes and I hope you succeed in your endeavors. I am sorry I cannot be of help. Do you have a working protype yet? If not, I hope you let us know when you succeed at drawing a simple line on the screen and tell us about what parts of your design were challenging and how you solved your problems. Regards, VinhArticle: 61046
> It seems that I owe Xilinx an apology... I overlooked little muxes with > invertors enabled at the CE and D inputs for Virtex II architecture. So, the > CE and D are not really tied to VCC and I have nobody to blame for my > problem:( Heh heh honest mistake. It's very easy for humans to overlook small details. Or sometimes we spend so much time staring at a problem, we can't see the "obvious." Finally the mystery is solved!Article: 61047
"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message news:yUZcb.6391$DE6.2382@newssvr27.news.prodigy.com... > I guess I'm doing a lousy job of explaining what I'm looking for. > > The example I provided is hypothetical. Of course a frame buffer approach > would be preferred and not too expensive to implement. No question about > it. That's a no brainer. I know how to do that (Bresenham). In fact, I > am doing that on a current project. But, that's not what I'm looking for. > > I'm looking for are algorithms that can render graphic primitives from real > time screen x,y counter data (as well as the corresponding primitive > parameters). > > Example: Draw a line, 1 pixel wide, at a 32 degree angle, from screen edge > to screen edge. > > The input data would be real-time screen x and y coordinates as the pixels > are being painted on screen. On a clock-by-clock basis you get to decide > whether or not the pixel in question should be video or a white dot for your > line. > > If this were a vertical or horizontal line (or 45 degrees, actually) it's a > simple comparison: > Whats is the use to get rid of all memory, if you have to have an advanced processor per graphics element in your design... If have a 24 bit overlay for a 720 x 525 PAL video, where each pixel has a different colour value (the extreme case), then you are going to need 378000 processors. Each processor probably requiring quite a lot of storage... If on the other hand you get 2 MB DRAM; then you can store whatever you want at a couple of bucks. -- Best Regards Ulf at atmel dot com These comments are intended to be my own opinion and they may, or may not be shared by my employer, Atmel Sweden.Article: 61048
On Thu, 25 Sep 2003 06:11:19 -0700, Martin Euredjian wrote: > I know about the various algorithms to draw lines, circles, etc. All of > these pretty much rely on painting onto a frame buffer that is later > used to scan out to a CRT. > > Does anyone know of any algorithms to draw primitives that work without > the intermediate frame buffer step. In other words, the algorithm's > input would be the current x,y pixel being painted on the screen and the > desired shape's parameters. Horizontal and vertical lines (and > rectangles), of course, are easy. But, how do you do curves or diagonal > lines? > > It seems to me that you'd take y and solve for x, which could produce > multiple results (say, a line near 0 degrees). You'd have to save the > results for that y coordinate in a temporary buffer that would then be > used to compare to x. That's as simple as I can come up with. Diagonal lines are easy, assuming you have genlock and X and Y Pixel address counters, just check that Y -(MX+B) = 0 and (X >=MINX) and (X <= MAXX) or (Y >=MINY) and (Y <= MAXY) and draw your pixel if so... Peter WallaceArticle: 61049
> Do you have a working protype yet? Product. Shipping. > If not, I hope you let us know when you > succeed at drawing a simple line on the screen I think that was back in 1978, maybe '77. Don't remember exactly. > and tell us about what parts of your design were challenging Working 16 hours a day, seven days a week for nearly two years. > and how you solved your problems. I finished. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Euredjian To send private email: 0_0_0_0_@pacbell.net where "0_0_0_0_" = "martineu"
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