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 61000

Article: 61000
Subject: Re: Graphics rendering
From: Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid>
Date: Fri, 26 Sep 2003 20:10:32 +1000
Links: << >>  << T >>  << A >>
On Fri, 26 Sep 2003 07:15:44 GMT, "Martin Euredjian"
<0_0_0_0_@pacbell.net> wrote:

>"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.  

I don't see how this follows from your constraints.

You say that the input to output video delay is at most a few clocks,
however you don't indicate that this constraint applies to the
overlay, e.g. the overlay could come from a frame buffer and then be
combined with the incoming video using some low latency method (either
digital or analog, using e.g. the analog switch method you mentioned).
You would need to genlock the FPGA generated video to the incoming
video, but that's not too hard.

>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.

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.
(Actually, I think the cost of the ram will be less than the cost of
fitting the heatsink you'll need if you don't have a ram. :)

IOW, due to cost constraints, you should have rendering memory for the
graphics overlay.  Of course, you'll need to do a detailed costing to
be sure, but I'd be surprised if the version with ram doesn't end up
being cheaper and get to market sooner.

Note that larger FPGAs may be able to hold the frame buffer in
internal ram (but this depends on your resolution and pixel depth).

Regards,
Allan.

Article: 61001
Subject: Re: WARNING do not use your real email address in USENET postings! Swem/Gibe virus will spam you 1000x!
From: "Mark" <markp100@hotmail.com>
Date: Fri, 26 Sep 2003 10:38:55 GMT
Links: << >>  << T >>  << A >>
Get your own domain name (register privately with no info about you
revealed) and email addresses in your private domain which you can easily
control.  I did it a couple of years ago now and got an address for me and
one each for the family.  Spam blocking software can be included, web mail
access is available, and you can switch ISP's at any time and be independent
of their spam-ridden email systems.  Web hosting is also there if you need
it.

Got mine from www.mydoname.com and for about $20 per year, it's a steal.

"jaideep" <jaideep@sasken.com> wrote in message
news:c4312ee4.0309252242.2fa34638@posting.google.com...
> Jan Panteltje <panteltjeNSOAPM@yahoo.com> wrote in message
news:<1064411674.535376@evisp-news-01.ops.asmr-01.energis-idc.net>...
> > What more can I say: I lost yahoo now.
> > That virus searches Usenet for email addresses, and then sends
> > thousands of times that microft fix with the worm.
>
> Hi,
>
> I am also facing the same problem.Is there a fix to avoid this?
>
> Regards,
>
> Jaideep



Article: 61002
Subject: Re: Reading from FPGA Issue
From: fpga_uk@yahoo.co.uk (Isaac)
Date: 26 Sep 2003 04:43:22 -0700
Links: << >>  << T >>  << A >>
charles.elias@wpafb.af.mil (Charles M. Elias) wrote in message news:<35849667.0309250248.5c8b4ef3@posting.google.com>...
> fpga_uk@yahoo.co.uk (Isaac) wrote in message news:<889eb3fb.0309240705.2bb5e86c@posting.google.com>...


> 
> 
> Without seeing your code it is not possible to make an exact diagnosis
> (maybe I couldn't even if I did see it), but I do have suggestions. 
> Any signal that is an input to the FPGA synchronous logic should be
> internally synchronized with the logic's clock using 2 d flip-flops. 
> The bus data need not be synchronized in this manner if the transfer
> logic (handshake) is synchronized.  The read operation should have
> some sort of handshake to ensure that the output data is stable before
> it is read and that the FPGA logic "knows" when new data is requested.
>  Does PCI protocol involve a handshake?  If so, have you implemented
> it on the FPGA side?
> 
> A typical handshake would be: The reader asserts data_request; the
> FPGA logic puts the data on the bus and asserts data_ready.  The
> reader sees data_ready, reads the data, and unasserts data_request
> (this lets the FPGA logic know that the data has been read and it
> unasserts data_ready and).  There are a number of variations on this,
> but without some sort of handshake it is quite likely that there will
> be missed data, multiple reads of the same data, etc.
> 
> Charles

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

> Without seeing your code it is not possible to make an exact diagnosis
> (maybe I couldn't even if I did see it), but I do have suggestions. 
> Any signal that is an input to the FPGA synchronous logic should be
> internally synchronized with the logic's clock using 2 d flip-flops. 
> The bus data need not be synchronized in this manner if the transfer
> logic (handshake) is synchronized.  The read operation should have
> some sort of handshake to ensure that the output data is stable before
> it is read and that the FPGA logic "knows" when new data is requested.
>  Does PCI protocol involve a handshake?  If so, have you implemented
> it on the FPGA side?
> 
> A typical handshake would be: The reader asserts data_request; the
> FPGA logic puts the data on the bus and asserts data_ready.  The
> reader sees data_ready, reads the data, and unasserts data_request
> (this lets the FPGA logic know that the data has been read and it
> unasserts data_ready and).  There are a number of variations on this,
> but without some sort of handshake it is quite likely that there will
> be missed data, multiple reads of the same data, etc.
> 
> Charles
-------------------------------------------------------------------
Here is the Case Statement which I am using, in this you will see
different signal which I am using in differnt process which I haven't
included .


process1: process (CLK_2X)
  begin 
	if RISING_EDGE(CLK_2X) then
      state <= next_state; 
    else 
	Null;
    end if; 
  end process process1; 
  process2 : process
(state,LOCKED,CLK_2X,SR_ADDR_IO,SR_DATA_IO,SR_IRD,SR_IWR,SR_IVCS_V3)
  begin 
    case state is 
	when s1 => 			  
		paritycheck <= '0';
	        k <= 0;
                next_state <= s2; 
	when s2 => 
		if LOCKED = '1' then
--		LED_V3 <= LED_V3_int;
		STAT_V3 <= STAT_V3_int;		   
	-- Inputs
--		SR_ADDR_IO_int <= SR_ADDR_IO;
--	    	SR_DATA_IO_int <= SR_DATA_IO;
--		SR_IRD_int <= SR_IRD;
--		SR_IWR_int <= SR_IWR;
		SR_IVCS_V3_int <= SR_IVCS_V3;  
		next_state <= s3;								else 
		  Null;
		end if;

          when s3 =>
		if SR_IVCS_V3 = '0' then  
		 SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
		  if SR_IWR = '0' then
		    if SR_ADDR_IO = "000000" then	
			channelbit1 <= SR_DATA_IO(2 downto 0) ; 	
		  	   next_state <= s32;
		    else 
			next_state <= s3;
		    end if ;
		 else 
			Null;
		 end if ;
	       else 
		Null;
	       end if;	
	when s32 =>	
  	if SR_IVCS_V3 = '0' then  
        	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
	    if SR_ADDR_IO = "000001" then	
		channelbit2 <= SR_DATA_IO(2 downto 0) ; 	
	    next_state <= s33;
	    else 
		next_state <= s32;
	    end if ;
	  else 
	    Null;
	  end if ;
	else 
	  Null;
	 end if;	   
     when s33 =>	
	if SR_IVCS_V3 = '0' then  
         SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
		if SR_ADDR_IO = "000010" then	
		   channelbit3 <= SR_DATA_IO(2 downto 0) ; 	
	        next_state <= s34;
		else 
	        next_state <= s33;
		end if ;
	  else 
	    Null;
	  end if ;
	else 
	  Null;
	end if;	 
     when s34 =>	
	if SR_IVCS_V3 = '0' then  
        	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
	   if SR_ADDR_IO = "000011" then	
	     channelbit4 <= SR_DATA_IO(2 downto 0) ; 	
	      next_state <= s35;
	   else 
	      next_state <= s34;
	   end if ;
	  else 
	    Null;
	  end if ;
	else 
	  Null;
	end if;						 

     when s35 =>	
	if SR_IVCS_V3 = '0' then  
        	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
		if SR_ADDR_IO <= "000100" then	
		   channelbit5 <= SR_DATA_IO(2 downto 0) ; 	
	        next_state <= s36;
		else 
		next_state <= s35;
		end if ;
         else 
	   Null;
	 end if ;
       else 
	 Null;
       end if;		
     when s36 =>	
	if SR_IVCS_V3 = '0' then  
        	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
	    if SR_ADDR_IO = "000101" then	
		channelbit6 <= SR_DATA_IO(2 downto 0) ; 	
		next_state <= s37;
            else 
		next_state <= s36;
	    end if ;
	  else 
		Null;
	  end if ;
	else 
	  Null;
	end if;	

     when s37 =>	
	if SR_IVCS_V3 = '0' then  
        	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
	    if SR_ADDR_IO = "000110" then	
		  channelbit7 <= SR_DATA_IO(2 downto 0) ; 	
		   next_state <= s38;
	    else 
		   next_state <= s37;
	    end if ;
	 else 
	  Null;
	 end if ;				  
       else 
	 Null;
	end if;
     when s38 =>	
	if SR_IVCS_V3 = '0' then  
        	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
	  if SR_IWR = '0' then
		if SR_ADDR_IO = "000111" then	
		   channelbit8 <= SR_DATA_IO(2 downto 0) ; 	
		   next_state <= s39;
		else 
		next_state <= s38;
		end if ;
	  else 
		Null;
	  end if ;
	else 
	  Null;
	end if;	 

    when s39	=>
	if SR_IVCS_V3 = '0' then  
		SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
		if SR_IWR = '0' then
			if SR_ADDR_IO = "001000" then	
			   channelbit9 <= SR_DATA_IO(2 downto 0) ; 	
			   next_state <= s310;
			else 
			next_state <= s39;
			end if ;
		else 
		Null;
		end if ;
	else 
	Null;
	end if;
when s310	=>

	if SR_IVCS_V3 = '0' then  
	SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
		if SR_IWR = '0' then
			if SR_ADDR_IO = "001001" then	
			   channelbit10 <= SR_DATA_IO(2 downto 0) ; 	
			   next_state <= s311;
			else 
			next_state <= s310;
			end if ;
		else 
		Null;
         	end if ;	 
	else 
		Null;
	end if;		 
when s311	=>
	if SR_IVCS_V3 = '0' then  
		SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
		if SR_IWR = '0' then
			if SR_ADDR_IO = "001010" then	
			   channelbit11 <= SR_DATA_IO(2 downto 0) ; 	
		   next_state <= s312;
		else 
			next_state <= s311;
		end if ;
		else 
			Null;
	end if ;	
	else 
		Null;
end if ;
when s312 =>	
	if SR_IVCS_V3 = '0' then  
		SR_DATA_IO <= "ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ";
		if SR_IWR = '0' then
			if SR_ADDR_IO = "001011" then	
			   channelbit12 <= SR_DATA_IO(2 downto 0) ; 	
			   LED_V3(2 downto 0) <= channelbit11;
			   next_state <= s4;
			else 
			next_state <= s312;
		end if ;
		else 
			Null;
		end if ;
	else 
		Null;
	end if;		

    when s4 =>
 		 k <= k + 1;		
  		 next_state <= s5; 
  when s5 => 
		if remainder = 0 then  
			k <= 0;
			next_state <= s6 ;
			paritycheck <= '1';	  
			else
			next_state <= s4 ;
		 k<= k+1;
		end if ;	
  when s6 =>   
		if SR_IVCS_V3 = '0' then  
			if SR_IRD = '0' then 
--						if remainder = 0 then 
			if SR_ADDR_IO = "001100" then	
		   	SR_DATA_IO (11 downto 0)<= eb_hat_bits (0 to 11); 
			SR_DATA_IO (31 downto 12) <= "00000000000000000000";   
			elsif SR_ADDR_IO = "001101" then	
			next_state <= s1;
			end if;	
--							end if;	
			else 
					Null;
			end if;
		else 
			Null;
			end if ;
		when others =>
					Null;
	    end case; 
end process process2;

Article: 61003
Subject: Re: Synchronous Binary counter question.
From: dgleeson-2@utvinternet.com (Denis Gleeson)
Date: 26 Sep 2003 06:08:08 -0700
Links: << >>  << T >>  << A >>
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.

Many thanks

Denis



"Bob Feng" <yi.feng@sbcglobal.net> wrote in message news:<XLPcb.3437$6b6.3086@newssvr29.news.prodigy.com>...
> I am confused by your terminology.
> 
> Correct me if I am wrong.
> 1. You are looking for a "synchrounous binary counter". Isn't it the one you
> just wrote?
> 2. What is the matter with ripple counter? And what is the difference from a
> "synchrounous binary counter"?
> 3. Gray code should be able to walk through all the addresses.
> 
> ---Bob
> "Denis Gleeson" <dgleeson-2@utvinternet.com> wrote in message
> news:184c35f9.0309250354.763cf662@posting.google.com...
> > Hello All
> >
> > OK Im a bit confused.
> >
> > the verilog code
> >
> > always @(posedge CLK or posedge CLR)
> > begin
> >    if (CLR)
> >       Q <= 20'b0;
> >    else
> > if (CE) // Is counter Enabled.
> >   begin
> >           Q<=Q+1;
> >   end
> > end
> >
> > produces a ripple counter? Yes, No?
> >
> > When I look at my simulation results I see glitches in the count output
> > leading me to assume that I have implemented a ripple counter.
> >
> > IS it possible to remove the glitches with a synchronous Binary counter?
> > If yes what is the verilog code?
> >
> > Ive read about Gray counters but as Im using the counter to step through
> > SRAM addresses I dont want to loose storage locations in my SRAM just
>  because
> > my counter doesnt count through all possible binary counts.
> >
> >
> > Thanks in advance for all suggestions.
> >
> >
> > Denis

Article: 61004
Subject: Re: WARNING do not use your real email address in USENET postings! Swem/Gibe virus will spam you 1000x!
From: oen_br@yahoo.com.br (Luiz Carlos)
Date: 26 Sep 2003 06:53:12 -0700
Links: << >>  << T >>  << A >>
The same with me.

Luiz Carlos

Article: 61005
Subject: Re: IEEE 1284 Core for Xilinx | Reading Japanese FPGA pages
From: "James Williams" <james@williams-eng.com>
Date: Fri, 26 Sep 2003 08:54:56 -0500
Links: << >>  << T >>  << A >>
What parts are the plug and play?

Why is there a separate IEEE1284_IN and out port?  Couldn't that be the same
8bit bidirectional port?

Also,

I asked if I could get the EPP VHDL that you mentioned, but I had to change
my email address because of the current virus going around was swamping my
incoming messages.  My new email is jlw@williams-eng.com

Regards,


James

"Antti Lukats" <antti@case2000.com> wrote in message
news:80a3aea5.0309252122.75ef10c2@posting.google.com...
> "James Williams" <james@williams-eng.com> wrote in message
news:<bkv30s$pp0$1@news3.infoave.net>...
> > I found that it did synthesise into an XC95144, however is does not fit
into
> > the device use the fitter of the ISE.
> >
> > Regards,
>
> with plug and play and debug disabled it fits into XC9572 with ISE
>
> antti



Article: 61006
Subject: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 10:22:10 -0400
Links: << >>  << T >>  << A >>
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: 61007
Subject: Re: Xilinx S3 I/O robustness question
From: Austin Lesea <Austin.Lesea@xilinx.com>
Date: Fri, 26 Sep 2003 07:43:00 -0700
Links: << >>  << T >>  << A >>
Rick,

Sorry to have offended, but you really are arguing a lost cause.  Ignore SI?  At your
peril.  And not (just) for relibility reasons, just plain work reasons.

As for your example, of less than 12", and 3.300V, again, I ask you to go simulate the
exact situation you are asking about.

What impedance trace?  What strength driver?  What is(are) the load(s)?  What is
potentially coupling to the trace(s)?  Too many variables to just say:  "hey, no
problem."

By the way, I would never state "hey, no problem,"  as Murphy says, "whatever can go
wrong, will go wrong...."     that is why we simulate.

Austin

rickman wrote:

> I find your tone offensive Austin.  I am simply trying to understand the
> issue being discussed by yourself as well as others.  On my board there
> will be no traces that are near 12" much less 24" and the power supply
> will not be 3.6 volts.  So what you are now talking about is not a
> typical board design, but rather a *bad* board design.  That is not what
> you said.  Your statements, as well as others, was that *every* board
> needs to be simulated.  I agree that clock signals are very sensitive to
> signal integrity, but most data lines, that are not excessively long,
> will do no hard to most chips and SI issues will only add to the setup
> time.
>
> So if my traces are 6" and under and my Vccio is 3.3 volts or less, is
> it likely that a data trace will be at issue if it is not simulated?  As
> I said, this is the first time I have heard anyone say that it can be an
> issue, *especially* an issue of doing damage to a chip.
>
> Ringing has been an accepted part of digital logic design since logic
> was invented.  It is a problem, not because it exists, but only if it
> creats a malfunction.  It can ring for an hour and I won't care if I
> have two hours of settling time on my bus.
>
> If you don't wish to discuss this politely, then please feel free to
> ignore my post.
>
> Austin Lesea wrote:
> >
> > Rick,
> >
> > Get off that horse:  'typical' ringing is not the issue here.
> >
> > Have said it a number of times:  overshoot and undershoot is bad (period), and is
> > a sign of a bad board design.  The fact that if you have
> >
> > 1) 85C Tj AND
> > 2) you have a power supply at 3.6 volts AND
> > 3) you have crappy SI over long t-lines (which store more energy -- like 12 - 24")
> >
> > MAY lead to exceeding the Abs Max spec.
> >
> > The point is that you have to simulate to get good SI, so do so.  While you are at
> > it, if the SI is terrible, fix it.  If you can't fix it, then make sure you are
> > within the Abs Max specs.
> >
> > Austin
> >
> > rickman wrote:
> >
> > > Austin Lesea wrote:
> > > >
> > > > Rick,
> > > >
> > > > Fight it as long as you can, but everyone else is using the more advanced
> > > > tools, and simulating everything (at the companies where they want to be
> > > > successful on the first pcb turn -- as for the others, I don't hear from
> > > > them often anymore....).
> > >
> > > Funny.  But I doubt it is very accurate.  I have worked at some of the
> > > larger companies making telecom test equipment and I have yet to meet a
> > > board designer who simulates all of the traces.  The ones I spoke with
> > > only simulate the clock lines or other signal lines when the timing is
> > > tight with no time for settling.
> > >
> > > Like I said, this is the first time I have heard a chip maker claim that
> > > typical ringing and undershoot can cause chip damage.  Of course an
> > > absurdly designed trace and create excessive swings.  But the typical
> > > amount of ringing is normally listed in data sheets as being within spec
> > > for chips.
> > >
> > > > And yes, if you do not pay attention now, you will cause ground bounce (50 -
> > > > 60 mA of reflection current per IO is possible),
> > >
> > > Under what conditions is this "possible"?  I would expect this to be an
> > > extreme case.  The analyis listed here indicated much lower currents
> > > (~35 mA) and only for the brief time (< 1 ns) of the overshoot.  If the
> > > device can't handle these low currents without ground bounce, how can it
> > > possibly provide the much larger currents (> 55 mA) for the initial
> > > level change without ground bounce?
> > >
> > > > and with the Virtex II Pro,
> > > > and Spartan 3 if the IOs are operated at 3.3V, you may exceed the Abs Max
> > > > data sheet limits if you do not pay attention to what you are doing.  And
> > > > that will cause a reduction in the 20 year projected lifetime.  Below 3.0V,
> > > > there are no reliability issues to consider, as the clamp diodes are
> > > > sufficient to protect the IOs.  Smaller, faster, less expensive technology
> > > > from the foundries has some drawbacks:  leakage current, and IO robustness
> > > > at voltages greater than 3.75 volts being two of them.
> > > >
> > > > The new tools allow for extraction of all pcb parameters, and easy
> > > > simulation of all tracks/traces.  You can also create a design that is
> > > > correct by construction:  use DCI or series or parallel termination, and
> > > > make 50 ohm (or whatever) traces.  Then you do not have to simulate
> > > > everything.
> > >
> > > So the DCI in the S3 chips will allow matching of the chip IO impedance
> > > to the trace, right?
> > >
> > > > Or use a standard:  HSTL, SSTL, PCI.  Then you also don't have to think.
> > > > But I also simulate to make sure I haven't missed anything.
> > >
> > > I only wish standards really did preclude the "thinking".  I have worked
> > > with RS-232 and many others too long to beleive that.
> > >
> > > --
> > >
> > > Rick "rickman" Collins
> > >
> > > rick.collins@XYarius.com
> > > Ignore the reply address. To email me use the above address with the XY
> > > removed.
> > >
> > > Arius - A Signal Processing Solutions Company
> > > Specializing in DSP and FPGA design      URL http://www.arius.com
> > > 4 King Ave                               301-682-7772 Voice
> > > Frederick, MD 21701-3110                 301-682-7666 FAX
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 61008
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 26 Sep 2003 08:32:56 -0700
Links: << >>  << T >>  << A >>
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.

XST is just doing its job, making a valid netlist per your description.
A synth will often do unexpected things, but it will work just fine.

> 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,

Both are "fine".
You write the description, the synth makes the netlist.

  -- Mike Treseler


-- makes an fdre module on Virtex:
library ieee;
use ieee.std_logic_1164.all;

entity sreset_ce is
    port (
       clk        : in  std_ulogic;
       clk_ena    : in  std_ulogic;
       sync_reset : in  std_ulogic;
       inf        : in  std_ulogic;
       outf       : out std_ulogic);

end entity sreset_ce;

architecture synth of sreset_ce is
begin
    process(clk) is
    begin
       if rising_edge (clk) then
          if sync_reset = '1' then
             outf <= '0';
          elsif clk_ena = '1' then
             outf <= inf;
          end if;
       end if;
    end process;
end architecture synth;


Article: 61009
Subject: Re: pullup on inputs
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 26 Sep 2003 15:40:27 GMT
Links: << >>  << T >>  << A >>
If your syntax does work, you can see the pullup in the FPGA Editor for your
Placed & Routed design.  Find one of the IOBs, double click on the IOB and
you'll get a pop-up for just that cell.  Included are checkboxes for some of
the IOB options including logic standard, fast/slow, and pullup.  If the
pullup isn't indicated *there* it isn't in your finalized design.


"Max" <cialdi@firenze.net> wrote in message
news:8e077568.0309252330.21aae0c5@posting.google.com...
> I use xilinx ise webpack 6.1 sp1.
> In may project I tried to add contrains like:
>
> NET "probes<0><0>"  LOC = "D11" | PULLUP ;
> NET "probes<0><1>"  LOC = "D12" | PULLUP ;
> NET "probes<0><2>"  LOC = "C12" | PULLUP ;
>
> This signals are all input.
>
> In translate report is reported:
>
> Attached a PULLUP primitive to pad net probes<0><2>
> Attached a PULLUP primitive to pad net probes<0><1>
> Attached a PULLUP primitive to pad net probes<0><0>
>
>
> But in place&route report there is no reference to pullups:
> Resolved that IOB <probes<0><0>> must be placed at site D11.
> Resolved that IOB <probes<0><1>> must be placed at site D12.
> Resolved that IOB <probes<0><2>> must be placed at site C12.
>
> Even in pad report is not mentioned pullup resistor for that signals.
>
> How can I be sure about the presence of pullup resistors on that ports?
>
> thanks



Article: 61010
Subject: Re: WARNING do not use your real email address in USENET postings! Swem/Gibe virus will spam you 1000x!
From: "John_H" <johnhandwork@mail.com>
Date: Fri, 26 Sep 2003 15:43:43 GMT
Links: << >>  << T >>  << A >>
My fix was to stop forwarding my mail to my Verizon.com isp and redirect it
to my email-only account with nwlink.com.  Verizon doesn't filter the junk.
My forwarding service mail.com doesn't filter the junk.  NWlink.com filters
out the "microsoft patch" junk easily.  Beautiful.

Some ISPs are on the ball.

"jaideep" <jaideep@sasken.com> wrote in message
news:c4312ee4.0309252242.2fa34638@posting.google.com...
> Jan Panteltje <panteltjeNSOAPM@yahoo.com> wrote in message
news:<1064411674.535376@evisp-news-01.ops.asmr-01.energis-idc.net>...
> > What more can I say: I lost yahoo now.
> > That virus searches Usenet for email addresses, and then sends
> > thousands of times that microft fix with the worm.
>
> Hi,
>
> I am also facing the same problem.Is there a fix to avoid this?
>
> Regards,
>
> Jaideep



Article: 61011
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: Chris Ebeling <christopher.ebeling@xilinx.com>
Date: Fri, 26 Sep 2003 09:05:12 -0700
Links: << >>  << T >>  << A >>
Mikhail,
Your last statement suggests a solution.
Have you tried creating signal and assigning that to one outside of the process?

I this may (or may not) work.

If you absolutely want some particular interconnect configuration of a Xilinx
Basic Element you can always instantiate any component in the the unisim library

(unisim_VCOMP.vhd) FDRE in this case

I'll also just mention XST implementation is logically correct even if it wasn't
what
you wanted.

Chris



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: 61012
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 12:14:32 -0400
Links: << >>  << T >>  << A >>
"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3F745C28.4090401@flukenetworks.com...
> 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.
>
> XST is just doing its job, making a valid netlist per your description.
> A synth will often do unexpected things, but it will work just fine.

I don't think the netlist is valid. With D and CE both tied to VCC the flop
reverts to '1' on every clock regardless of my clk_ena signal. This is a
part of a bigger design that used to work on Spartan II. I only found the
problem when I moved it to Virtex II.... Any other ideas?

Thanks,
/Mikhail





Article: 61013
Subject: Re: Synchronous Binary counter question.
From: Bob Perlman <bobsrefusebin@hotmail.com>
Date: Fri, 26 Sep 2003 16:17:52 GMT
Links: << >>  << T >>  << A >>
On 26 Sep 2003 06:08:08 -0700, dgleeson-2@utvinternet.com (Denis
Gleeson) wrote:

>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.

Try this.  Credit where credit is due: as noted in the comments, the
gray code calculation comes from a paper by Cliff Cummings.

Bob Perlman
Cambrian Design Works

//===============================================================
//                          Module
//===============================================================
//
// Module:       gray_ctr_module.v
//
// Author:       Bob Perlman
//
// Description:  The Verilog code for a gray-code counter 
//    incorporates a gray-to-binary converter, a binary-
//    to-gray converter and increments the binary value 
//    between conversions.  
//
//    This code was based on Cliff Cummings' 2001 SNUG paper, 
//    "Synthesis and Scripting Techniques for Designing
//    Multi-Asynchronous Clock Designs."
//
// Revision history:
//     Rev.  Date            Modification
//     ----  --------
----------------------------------------------
//      -    12/29/01        Baseline version

`timescale 1 ns / 1 ps 
module gray_ctr_module 
  (// Outputs
   gray_ctr, 
   // Inputs
   inc_en, preload_en, preload_val, clk, global_async_reset
   );

//==================
// Parameters
//==================

parameter SIZE = 4;


//==================
// Port declarations
//==================

  output [SIZE-1:0] gray_ctr;

  input             inc_en; 
  input             preload_en;
  input  [SIZE-1:0] preload_val;
  input             clk;
  input             global_async_reset; // Global asynchronous reset

//====================================================
// Reg, wire, integer, task, and function declarations
//====================================================

  reg [SIZE-1:0] gray_plus_1, gray_ctr, bnext, bin;
  integer        i;

//=================
// Logic
//=================

  always @(posedge clk or posedge global_async_reset)
    gray_ctr <= #1 global_async_reset ? 0 :           
                   preload_en         ? preload_val : 
                   inc_en             ? gray_plus_1 : 
                                        gray_ctr;     

// Calculate next gray code by:
//    1) Converting current gray counter value to binary
//    2) Incrementing the binary value
//    3) Converting the incremented binary value to gray code

  always @(gray_ctr or inc_en) begin
    for (i=0; i<SIZE; i=i+1)
      bin[i] = ^(gray_ctr >> i);
    bnext = bin + 1;
    gray_plus_1 = (bnext>>1) ^ bnext;
  end

endmodule


Article: 61014
Subject: Xilinx: LOC'd IO internal to VHDL Module
From: Andy Greensted <ajg112@york.ac.uk>
Date: Fri, 26 Sep 2003 17:21:16 +0100
Links: << >>  << T >>  << A >>
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: 61015
Subject: Re: WARNING do not use your real email address in USENET postings! Swem/Gibe virus will spam you 1000x!
From: jakespambox@yahoo.com (Jake Janovetz)
Date: 26 Sep 2003 09:33:54 -0700
Links: << >>  << T >>  << A >>
It's interesting you say this.  I have my own domain name which I use
for private email but I would never post the email address on Usenet
(even with a NOSPAM thing in it).  You can use filter software to put
things into different folders.  For example, when registering on
various corporate web pages, I often use newly generated emails:

robert-analogdevices@mydomain.com
robert-xilinx@mydomain.com

When mail comes from those sites, it is placed into my folders "Analog
Devices" or "Xilinx".  If I start getting spam on one, I know who sold
the database!  And, it does a much better job at keeping my real email
address clean (which has been clean for almost four years now).

For usenet, you can see I signed up using a different email address on
Yahoo.

   Jake



"Mark" <markp100@hotmail.com> wrote in message news:<3HUcb.124132$bo1.76644@news-server.bigpond.net.au>...
> Get your own domain name (register privately with no info about you
> revealed) and email addresses in your private domain which you can easily
> control.  I did it a couple of years ago now and got an address for me and
> one each for the family.  Spam blocking software can be included, web mail
> access is available, and you can switch ISP's at any time and be independent
> of their spam-ridden email systems.  Web hosting is also there if you need
> it.

Article: 61016
Subject: Re: Graphics rendering
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 26 Sep 2003 16:34:38 GMT
Links: << >>  << T >>  << A >>
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:

Vertical line:   if x is equal to desired x position, light the pixel
Horizontal line: if y is equal to the desired y position, light the pixel
Diagonal line:   if x and y are equal to a dedicated line x,y counter
values, light the pixel.

Line length is easily handled by means of limit registers.

All of this happens in real time, without using any frame buffers whatsoever
and with relatively minimal hardware resources (very small FPGA will do the
job nicely).

You could probably do arbitrary-angle diagonal lines in real time by simply
having an algoritm increment/decrement a set of line x,y counters.  Inputs
would be screen pixel x,y coordinates and line parameters.  That's one
algorithm I'm interested in learning about.  I'm working on my own, but if
there's something out there I should consider I don't mind stopping wheel
re-invention cold in its tracks.

Drawing circular arcs might take a similar approach, but it would be a bit
(or a lot) more complex.  Maybe a LUT would be used to translate the graphic
primitive's x,y counters into a circular arc.  Of course, for a circle you
have to deal with two or more points per scan line.

Things get a bit more interesting if you need to add width to the graphic
primitives.

I hope I did a better job on this post.


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

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





"Allan Herriman" <allan.herriman.hates.spam@ctam.com.au.invalid> wrote in
message news:av28nv4njnt0ps2c23qoipe2nm1s5s98c9@4ax.com...
> On Fri, 26 Sep 2003 07:15:44 GMT, "Martin Euredjian"
> <0_0_0_0_@pacbell.net> wrote:
>
> >"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.
>
> I don't see how this follows from your constraints.
>
> You say that the input to output video delay is at most a few clocks,
> however you don't indicate that this constraint applies to the
> overlay, e.g. the overlay could come from a frame buffer and then be
> combined with the incoming video using some low latency method (either
> digital or analog, using e.g. the analog switch method you mentioned).
> You would need to genlock the FPGA generated video to the incoming
> video, but that's not too hard.
>
> >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.
>
> 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.
> (Actually, I think the cost of the ram will be less than the cost of
> fitting the heatsink you'll need if you don't have a ram. :)
>
> IOW, due to cost constraints, you should have rendering memory for the
> graphics overlay.  Of course, you'll need to do a detailed costing to
> be sure, but I'd be surprised if the version with ram doesn't end up
> being cheaper and get to market sooner.
>
> Note that larger FPGAs may be able to hold the frame buffer in
> internal ram (but this depends on your resolution and pixel depth).
>
> Regards,
> Allan.



Article: 61017
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Fri, 26 Sep 2003 09:39:05 -0700
Links: << >>  << T >>  << A >>
MM wrote:

> I don't think the netlist is valid. With D and CE both tied to VCC the flop
> reverts to '1' on every clock regardless of my clk_ena signal. 

Your description says outf is low for reset, high otherwise.
The only way to get a low with that description
is to reset and immediately disble the clock.

  -- Mike Treseler


Article: 61018
Subject: Re: WARNING do not use your real email address in USENET postings!
From: Duane Clark <junkmail@junkmail.com>
Date: Fri, 26 Sep 2003 09:40:36 -0700
Links: << >>  << T >>  << A >>
jaideep wrote:
> Jan Panteltje <panteltjeNSOAPM@yahoo.com> wrote in message news:<1064411674.535376@evisp-news-01.ops.asmr-01.energis-idc.net>...
> 
>>What more can I say: I lost yahoo now.
>>That virus searches Usenet for email addresses, and then sends
>>thousands of times that microft fix with the worm.
> 
> 
> Hi,
> 
> I am also facing the same problem.Is there a fix to avoid this?
> 

The normal fix is to replace your From email address with a munged or 
fake one, something like mine. At least with Mozilla/Netscape, that is 
easy to do; just create a new email account with a fake return address. 
If you do that, you normally should include a brief message at the 
bottom in your signature indicating that your email address is faked.

It is unfortunate that things have come to this.

-- 
My real email is akamail.com@dclark (or something like that).


Article: 61019
Subject: Re: Graphics rendering
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 26 Sep 2003 16:42:54 GMT
Links: << >>  << T >>  << A >>
"Vinh Pham" wrote:

> You've got quite a set of challenging constraints there.  So you're saying
> an FPGA is cheaper than using a frame buffer and a micro-controller?

Well, yes.  I have to process half a billion pixels per second.  Kinda hard
to do with a microprocessor.

> Another thing to think about is you'll need memory for each drawing
> primitive in your overlay graphics, which might be a problem if you're
going
> to have a lot of primitives.

I'm looking for an approach that would essentially evaluate equations for
these primitives in real time.  Therefore, no storage other than a few
registes and counters would be required.

It's relatively easy if you go to first principles, but probably not very
efficient hardware-wise.  I mean, look at Bresenham when compared to
evaluating the equation of a line in real time.

> By the way, how are you planning to sync to the incoming video
> signal?

That's easy.  We call it "genlock", for "(sync) generator lock".  A PLL does
it.  In the old days you had to design your own.  Today there are many very
nice canned solutions.

> Well if you pull this off, it'll be quite impressive.  Please let us know
of
> your progress.

It's nothing to warrant being impressed.  Seriously.  It's just a matter of
implementation.


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

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



Article: 61020
Subject: Re: How to change "X" to "0" or "1" (VHDL) ?
From: mikroprog@yahoo.com (Vakaras)
Date: 26 Sep 2003 09:46:57 -0700
Links: << >>  << T >>  << A >>
Hello,

  Thanks for everybody.
  Seems, that Flip-flops would be the best solution.
  Yes, Aldec gave me a warning, but ... nothing to do with it.. :) 

  Becouse "X" will be "0" or "1" in real, so I simply shifted testable
"Dat" signal, adjusted a freequency to be repeated of Clock, and it
worked.

  Other partitial solution of this problem - to make "And" operation
with "X" and the same "Dat" signal after a short delay: "X and 0 = 0".
But it will work only with negative "Dat" edge. For positive, "X or 1
= 1", will work too. But no chanse to find a way, how to force to work
for both edges... :)

/Vakaras/

Article: 61021
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 13:17:33 -0400
Links: << >>  << T >>  << A >>
OK, so how should I describe a D flip-flop with a synchronous reset and a
clock enable with the D input tied to VCC?

/Mikhail


"Mike Treseler" <mike.treseler@flukenetworks.com> wrote in message
news:3F746BA9.20409@flukenetworks.com...
> MM wrote:
>
> > I don't think the netlist is valid. With D and CE both tied to VCC the
flop
> > reverts to '1' on every clock regardless of my clk_ena signal.
>
> Your description says outf is low for reset, high otherwise.
> The only way to get a low with that description
> is to reset and immediately disble the clock.
>
>   -- Mike Treseler
>



Article: 61022
Subject: Re: Graphics rendering
From: bfeng <bfeng@sgi.com>
Date: Fri, 26 Sep 2003 10:18:00 -0700
Links: << >>  << T >>  << A >>


Martin Euredjian wrote:
> "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.
> 

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


Article: 61023
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 13:21:53 -0400
Links: << >>  << T >>  << A >>
"Chris Ebeling" <christopher.ebeling@xilinx.com> wrote in message
news:3F7463B8.9687C89F@xilinx.com...
> Mikhail,
> Your last statement suggests a solution.
> Have you tried creating signal and assigning that to one outside of the
process?
>
> I this may (or may not) work.

Tried, it doesn't work.

> If you absolutely want some particular interconnect configuration of a
Xilinx
> Basic Element you can always instantiate any component in the the unisim
library
>
> (unisim_VCOMP.vhd) FDRE in this case

I would like to avoid this.

> I'll also just mention XST implementation is logically correct even if it
wasn't
> what
> you wanted.

So, is there a way to describe what I want in VHDL so that XST will
understand it?

/Mikhail



Article: 61024
Subject: Re: Graphics rendering
From: "Bob Feng" <bfeng@sgi.com>
Date: Fri, 26 Sep 2003 10:25:02 -0700
Links: << >>  << T >>  << A >>
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"
>
>





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