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 61025

Article: 61025
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "Vinh Pham" <a@a.a>
Date: Fri, 26 Sep 2003 17:36:19 GMT
Links: << >>  << T >>  << A >>
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: 61026
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 13:37:35 -0400
Links: << >>  << T >>  << A >>
I'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.

/Mikhail



Article: 61027
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "Vinh Pham" <a@a.a>
Date: Fri, 26 Sep 2003 17:40:15 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Synchronous Binary counter question.
From: bybell@rocketmail.com (Anthony J Bybell)
Date: 26 Sep 2003 10:45:54 -0700
Links: << >>  << T >>  << A >>
> > 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>

-t

Article: 61029
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 13:52:47 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: Graphics rendering
From: "Vinh Pham" <a@a.a>
Date: Fri, 26 Sep 2003 17:56:19 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Synchronous Binary counter question.
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 26 Sep 2003 20:05:28 +0200
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx: LOC'd IO internal to VHDL Module
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 14:09:21 -0400
Links: << >>  << T >>  << A >>
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
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: Chris Ebeling <christopher.ebeling@xilinx.com>
Date: Fri, 26 Sep 2003 11:22:06 -0700
Links: << >>  << T >>  << A >>
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: 61034
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 14:23:32 -0400
Links: << >>  << T >>  << A >>
Folks,

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:(

/Mikhail



Article: 61035
Subject: Re: Xilinx S3 I/O robustness question
From: symon_brewer@hotmail.com (Symon)
Date: 26 Sep 2003 11:27:27 -0700
Links: << >>  << T >>  << A >>
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
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Sep 2003 11:36:27 -0700
Links: << >>  << T >>  << A >>
"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?

=a

Article: 61037
Subject: Re: Strange synthesis behavior from Quartus II 2.2
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Sep 2003 11:40:55 -0700
Links: << >>  << T >>  << A >>
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?

=-a

Article: 61038
Subject: Re: Synchronous Binary counter question.
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Sep 2003 11:45:05 -0700
Links: << >>  << T >>  << A >>
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.

--a

Article: 61039
Subject: Re: virtex2p power consumption
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Sep 2003 11:47:16 -0700
Links: << >>  << T >>  << A >>
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.

-a

Article: 61040
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "MM" <mbmsv@yahoo.com>
Date: Fri, 26 Sep 2003 14:47:21 -0400
Links: << >>  << T >>  << A >>
> 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.

/Mikhail



Article: 61041
Subject: Re: Graphics rendering
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 26 Sep 2003 18:53:56 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Graphics rendering
From: "Martin Euredjian" <0_0_0_0_@pacbell.net>
Date: Fri, 26 Sep 2003 18:58:15 GMT
Links: << >>  << T >>  << A >>
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
Subject: Re: Xilinx S3 I/O robustness question
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Sep 2003 12:14:45 -0700
Links: << >>  << T >>  << A >>
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.

--a

Article: 61044
Subject: Re: How to change "X" to "0" or "1" (VHDL) ?
From: Bassman59a@yahoo.com (Andy Peters)
Date: 26 Sep 2003 12:20:17 -0700
Links: << >>  << T >>  << A >>
"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!

--a

Article: 61045
Subject: Re: Graphics rendering
From: "Vinh Pham" <a@a.a>
Date: Fri, 26 Sep 2003 19:30:03 GMT
Links: << >>  << T >>  << A >>
> 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,
Vinh



Article: 61046
Subject: Re: FF with CE doesn't synthesize correctly by XST?
From: "Vinh Pham" <a@a.a>
Date: Fri, 26 Sep 2003 19:34:27 GMT
Links: << >>  << T >>  << A >>
> 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
Subject: Re: Graphics rendering
From: "Ulf Samuelsson" <ulf@NOSPAMatmel.com>
Date: Fri, 26 Sep 2003 21:34:37 +0200
Links: << >>  << T >>  << A >>

"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
Subject: Re: Graphics rendering
From: "Peter C. Wallace" <pcw@freeby.mesanet.com>
Date: Fri, 26 Sep 2003 13:17:31 -0700
Links: << >>  << T >>  << A >>
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 Wallace

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