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 86650

Article: 86650
Subject: FPGA system RAM
From: "Doug Jones" <dougdjones@hotmail.com>
Date: 1 Jul 2005 14:36:59 -0700
Links: << >>  << T >>  << A >>
I am in the early design stages of an FPGA-based audio / video stream
source and sink.  The FPGA board will be an ethernet node that will
accept digitized video from a local video camera for compression as
well as digitized audio.  The compressed video/audio stream will be
streamed out over ethernet.  Simultaneously, the FPGA board will accept
via incoming ethernet a compressed video/audio stream which will be
decompressed and sent to a video DAC for display on a local screen.

My question is about the RAM design for the system - RAM will be needed
for (1) storage & decompression of video/audio, (2) for storage and
compression of audio/video, (3) a memory for the local display (really
just the output from the decompression system), and (4) RAM for
microblaze embedded processor.  The target FPGA is Spartan 3. I was
hoping to use generic DDR RAM. So there are 3 or maybe 4 subsystems
competing for RAM bandwidth. Is it likely that such a design will
require separate RAM for the input and output sides? What about dual
port RAM? On the display side, is dual port RAM generally needed where
there is contention for the RAM between a video controller reading out
pixels and video decompression of an input stream to generate those
pixels? What about the microblaze? I would think it would be the most
tolerant of sharing of RAM bandwidth, given that wait states may be
needed if the RAM is busy.

All suggestions are much appreciated.
Thanks, Doug Jones


Article: 86651
Subject: Re: FPGA system RAM
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Jul 2005 14:46:27 -0700
Links: << >>  << T >>  << A >>
Doug, before anybody can give you a meaningful answer, we need to know
something about the speed or bandwidth required by your system.
Peter Alfke


Article: 86652
Subject: Re: FPGA system RAM
From: "Doug Jones" <dougdjones@hotmail.com>
Date: 1 Jul 2005 15:22:45 -0700
Links: << >>  << T >>  << A >>
Video is 640 x 480 x 24 bits x 30FPS = 220 Mbps uncompressed.  Assume
50:1 compression (is that realistic?) = 4.4 Mbps.  Audio is 44.1 kHz x
4 bytes = 1.4 Mbps.  Audio is uncompressed so total is 5.8Mbps
bidirectionally so grand total is around 11.6 Mbps. Microblaze will be
running web server for TCP/IP support.


Article: 86653
Subject: Re: FPGA system RAM
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Jul 2005 15:53:04 -0700
Links: << >>  << T >>  << A >>
I do not know to what the compression ratio i deterministic and
predictable, and what you have to assume worst-case.
At the low ates you mention, there seems to be plenty of room for
creative ideas to use available nanoseconds intelligently. You do not
need a dual-port mamory if there is enough time to time-multiplex the
data.
Good luck, this looks like a fun project...
Peter Alfke


Article: 86654
Subject: Re: FPGA system RAM
From: "Doug Jones" <dougdjones@hotmail.com>
Date: 1 Jul 2005 15:58:28 -0700
Links: << >>  << T >>  << A >>
Thank you for your advice.
Doug Jones


Article: 86655
Subject: Re: Foundation 3.1 in WinXP machine Problems!
From: "Tony" <nicemanYep@yahoo.co.uk>
Date: 1 Jul 2005 16:24:36 -0700
Links: << >>  << T >>  << A >>
Many thanks to both of you,
although i was sure that F3.1i is a 32 bit application, i have removed
SP2 and do a re-install of xilinx foundation. Unfortunately, the
problem persists!
win95 does not support NTFS (file system), so i have to re install win
NT in the same computer. i hope it is possible!



Gabor wrote:
> I'm running Foundation 4.1i on Windows XP SP1.  I believe there are
> issues with 16 bit applications under XP service pack 2.  I don't think
> there are significant differences between Xilinx releases 3.1i and 4.1i
> that would cause your problems.  If you have an XP machine that hasn't
> been updated to SP2 yet I would try that.
>
> Good luck,
> Gabor
>
> Tony wrote:
> > Hi,
> >
> > I have tried today to install Foundation 3.1 in my windows xp machine.
> > I have not done any FPGA design for 4 years and i have the new version
> > of xilinx tool but need to complete then convert some of my old
> > schematic based projects which are not supported any more by the
> > current version of xilinx tools.
> >
> > keep getting this error: Error: XIE32.exe is unable to locate
> > libbasxi.dll:" the implementation button is greyed out, i.e. i can't
> > synthesis my projects anymore (i need to do this to complete some old
> > projects using old chips)
> >
> > I have tried the solution suggested at this link:
> > http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=10791
> >
> >
> > but simply it is not working. I am using windows XP with SP2. could
> > this be the reason?
> >
> > if anyone has any suggestion, i'll be extremely delighted as xilinx
> > technical support does not handle f 3.1 related issues
> > 
> > Cheers


Article: 86656
Subject: Re: FPGA system RAM
From: "Peter Alfke" <peter@xilinx.com>
Date: 1 Jul 2005 16:25:01 -0700
Links: << >>  << T >>  << A >>
Sorry for the awful typos. I am really a good speller, but I got
distracted...
Peter Alfke


Article: 86657
Subject: Re: Cyclone Board with // LVDS lines
From: "Rob" <robnstef@frontiernet.net>
Date: Sat, 02 Jul 2005 03:09:15 GMT
Links: << >>  << T >>  << A >>
Not sure you'll find one, at least from Altera.

Rapid Technology has a Stratix board that might meet your needs, although 
the price is much more than you want to spend--check it out:

 http://www.rapid-technology.com/stratix_HS.htm

The ironic thing is that I'm in the midst of a Cyclone (1C6) design that 
could easily be made to accommodate you requirements.

Rob


"Keith Williams" <e_s_p_i_a_n_@insightbb.com> wrote in message 
news:nG2xe.106182$x96.7497@attbi_s72...
> Hi!
>
> I've already googled and dug through several online lists of FPGA boards,
> but haven't found what I'm looking for, yet.
>
> I'm needing a Cyclone board that has at least 32 LVDS I/O pins available
> (and terminated). With at least one PLL available to be driven from an
> external source.
>
> Target price of less than $500 U.S.
>
> Thanks,
>
> Keith
>
> 



Article: 86658
Subject: re:Problem for xilinx!!!
From: dejavu99@hotmail-dot-it.no-spam.invalid (damidar)
Date: Sat, 02 Jul 2005 11:15:26 -0500
Links: << >>  << T >>  << A >>
HELP ME HELP ME.....

THANKS :(


Article: 86659
Subject: Re: Problem for xilinx!!!
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 2 Jul 2005 14:24:54 -0700
Links: << >>  << T >>  << A >>
Netiquette:
1. Do not use triple-exclamation marks
2. Do not blindly assume it's a "problem for Xilinx" when it looks more
like a "problem for damidar"
3. Follow the helpful hints
4. Realize that this is the July 4 long weekend in the US. Most people
do something more relaxing than reading the newsgroup.
5. Wait till Tuesday...
Peter Alfke


Article: 86660
Subject: Re: Foundation 3.1 in WinXP machine Problems!
From: fred <not@for.mail>
Date: Sun, 03 Jul 2005 00:28:00 GMT
Links: << >>  << T >>  << A >>
In article <1120260275.855041.197780@g47g2000cwa.googlegroups.com
>, Tony <nicemanYep@yahoo.co.uk> writes
>Many thanks to both of you,
>although i was sure that F3.1i is a 32 bit application, i have removed
>SP2 and do a re-install of xilinx foundation. Unfortunately, the
>problem persists!
>win95 does not support NTFS (file system), so i have to re install win
>NT in the same computer. i hope it is possible!

The bios on my asus mobo lets me select the boot drive on startup (F8), a
separate drive is my preferred choice for dual-boot.
-- 
fred

Article: 86661
Subject: Re: Clock buffering in VirtexE FPGA
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 3 Jul 2005 01:40:40 -0700
Links: << >>  << T >>  << A >>
Thanks Ben for your advice. Will do that way. One more doubt i have is
:"the logic condition from an unconnected input pin will taken as '1'
if i set the pin type to LVTTL in a virtex E device ????
Thank you


Article: 86662
Subject: Re: Clock buffering in VirtexE FPGA
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 3 Jul 2005 01:43:36 -0700
Links: << >>  << T >>  << A >>
Thanks Aflek for your suggestion.


Article: 86663
Subject: Re: Clock buffering in VirtexE FPGA
From: "vssumesh" <vssumesh_asic@yahoo.com>
Date: 3 Jul 2005 01:47:25 -0700
Links: << >>  << T >>  << A >>
Thanks gabor for your suggestion...


Article: 86664
Subject: Re: Clock buffering in VirtexE FPGA
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 3 Jul 2005 07:52:21 -0700
Links: << >>  << T >>  << A >>
If you use the "weak pull-up option".
Peter Alfke


Article: 86665
Subject: Xilinx: XST synchronous FIFO using BRAMs
From: Sidney Cadot <sidney@jigsaw.nl>
Date: Sun, 03 Jul 2005 17:59:19 +0200
Links: << >>  << T >>  << A >>
Dear all,

Lately I have been trying to design and implement a synchronous FIFO 
using a cyclic buffer, that can be synthesized by XST to use Block RAMs.

I now have a version that works (it does so in simulation using GHDL). I 
have attached it below. However, since it doesn't follow the prescribed 
pattern for BLOCK RAM inference, the code as shown synthesizes to an 
implementation that uses "distributed RAM" instead.

Fortunately, I can easily get it in a form where BRAM can be inferred by 
enabling the currently-commented-out line marked "ENABLE FOR BRAM", 
around line 70.

The thing is that if I do this, the entity stops functioning as 
intended. This is particularly strange since (as far as I can tell) the 
change shouldn't affect the architecture's semantics in any way!

Any help/pointers by one of the VHDL gurus here would be much appreciated.

Best regards,

   Sidney

------------- ramfifo.vhdl


library ieee;

use ieee.std_logic_1164.all,
     ieee.numeric_std.all;

entity RAMFIFO is
     port(
         CLK       : in  std_logic;
         data_in   : in  std_logic_vector(7 downto 0);
         data_out  : out std_logic_vector(7 downto 0);
         status    : out std_logic_vector(7 downto 0);
         reset     : in  std_logic;
         shift_in  : in  std_logic;
         shift_out : in  std_logic
     );
end entity RAMFIFO;

architecture arch of RAMFIFO is

     signal cur_address_r   : unsigned(3 downto 0) := "0000";
     signal cur_address_r2  : unsigned(3 downto 0) := "0000";
     signal cur_num_entries : unsigned(3 downto 0) := "0000";
     signal cur_address_w   : unsigned(3 downto 0);

     signal nxt_address_r   : unsigned(3 downto 0);
     signal nxt_num_entries : unsigned(3 downto 0);

     signal sig_data_r      : std_logic_vector(7 downto 0);

     type RAMType is array(0 to 15) of std_logic_vector(7 downto 0);

     -- initialize the ram below with sensible ascii values for debugging
     signal ram : RAMType := (
         x"30", x"31", x"32", x"33", x"34", x"35", x"36", x"37",
         x"38", x"39", x"41", x"42", x"43", x"44", x"45", x"46"
     );

     signal shift_in_possible     : std_logic;
     signal shift_out_possible    : std_logic;
     signal shift_in_will_happen  : std_logic;
     signal shift_out_will_happen : std_logic;

begin

     status <= std_logic_vector(cur_address_r) & 
std_logic_vector(cur_num_entries);

     process (CLK) is
     begin
         if rising_edge(CLK) then
             if reset = '1' then
                 cur_num_entries <= "0000";
             else
                 if shift_in_will_happen = '1' then
                     ram(to_integer(cur_address_w)) <= data_in;
                 end if;
                 cur_address_r   <= nxt_address_r;
                 cur_num_entries <= nxt_num_entries;

                 -- if the line below is commented out,
                 --       XST generates DISTRIBUTED RAM,
                 --       and the FIFO works properly.
                 --
                 -- if the line below is enabled,
                 --       XST generates BLOCK RAM,
                 --       and the fifo does not work properly.

                 -- cur_address_r2  <= nxt_address_r; -- ENABLE FOR BRAM

             end if;
         end if;
     end process;

     sig_data_r <= ram(to_integer(cur_address_r));

     with cur_num_entries select
         data_out <= x"00"      when "0000",
                     sig_data_r when others;

     nxt_address_r <= cur_address_r + 1 when shift_out_will_happen = '1'
                 else cur_address_r;

     nxt_num_entries <= cur_num_entries + 1 when shift_in_will_happen = 
'1' and shift_out_will_happen = '0'
                   else cur_num_entries - 1 when shift_in_will_happen = 
'0' and shift_out_will_happen = '1'
                   else cur_num_entries;

     cur_address_w <= cur_address_r + cur_num_entries;

     shift_in_will_happen  <= shift_in and shift_in_possible;
     shift_out_will_happen <= shift_out and shift_out_possible;

     shift_in_possible  <= '1' when (cur_num_entries /= "1111") or 
shift_out = '1' else '0';
     shift_out_possible <= '1' when (cur_num_entries /= "0000") else '0';

end architecture arch;

Article: 86666
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 3 Jul 2005 10:57:59 -0700
Links: << >>  << T >>  << A >>
Sidney. I am not a VHDL guru, but I claim to understand FIFOs.
There is an important difference between LUTRAM and BlockRAM:
In LUTRAM the reading is non-clocked (Change the read address, and the
new data appears immediately at the output), while the reading from a
BlockRAM is clocked (change the read address, and nothing happens at
the output until the next rising clock edge)

BTW, this is a long holoday weekend in the US.
Most people have better things to do than watching this ng.  :-)
Peter Alfke


Article: 86667
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sun, 03 Jul 2005 12:26:01 -0700
Links: << >>  << T >>  << A >>
Sidney Cadot wrote:

> Any help/pointers by one of the VHDL gurus here would be much appreciated.

http://groups-beta.google.com/groups?q=ram_dq_da


       --  Mike Treseler

Article: 86668
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 3 Jul 2005 13:08:42 -0700
Links: << >>  << T >>  << A >>
Mike Treseler wrote:

> http://groups-beta.google.com/groups?q=ram_dq_da

I reviewed the results of this query, but I don't see anything that is
relevant to my problem I am afraid.

The example code I gave can be inferred as BRAMs by XST by the deletion
of 1 (semantically empty) line, as explained in my previous post. In
that case however, it ceases to work as expected. My only conclusion is
that either XST or my VHDL code must have a bug.

Regards, Sidney


Article: 86669
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 3 Jul 2005 13:10:37 -0700
Links: << >>  << T >>  << A >>
Peter Alfke wrote:

> Sidney. I am not a VHDL guru, but I claim to understand FIFOs.
> There is an important difference between LUTRAM and BlockRAM:
> In LUTRAM the reading is non-clocked (Change the read address, and the
> new data appears immediately at the output), while the reading from a
> BlockRAM is clocked (change the read address, and nothing happens at
> the output until the next rising clock edge)

Yes, I understand this. My FIFO design has a delay of at least one
clock cycle, I am not expecting the output to appear immediately.

Note, too, that my code carefully refrains from using any
Xilinx-specific components. If I enable the "ENABLE FOR BRAM" line in
the code I gave, XST is able to infer a Block-RAM implementation all by
itself (cf. the 'VHDL Coding Techniques' chapter of the XST User's
Guide), so it apparently 'thinks' that the BRAM can provide the VHDL
semantics of my code in that case.

> BTW, this is a long holoday weekend in the US.
> Most people have better things to do than watching this ng.  :-)

Impossible ... :) Thanks for your help so far.

Regards, Sidney


Article: 86670
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 3 Jul 2005 13:25:27 -0700
Links: << >>  << T >>  << A >>
Sidney,
a synchronous FIFO (same clock for write and read) is really a trivial
design, using two counters.
But have you made sure that the two perverse cases are done propery:
FULL and EMPTY.
This is quite easy in a synchronous design, but still requires some
thought. (It's really tricky when the two clocks are not related...)
Peter Alfke


Article: 86671
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: sidney@jigsaw.nl
Date: 3 Jul 2005 14:26:03 -0700
Links: << >>  << T >>  << A >>


Peter Alfke wrote:
> Sidney,
> a synchronous FIFO (same clock for write and read) is really a trivial
> design, using two counters.

Sure. This is exactly what I am using: a counter that points to the
location where we are reading, and a counter that gives the number of
elements currently in the FIFO. All the rest is combinatorial logic.

Alternatively, I could do the same with counters that point to the
'read' and 'write' positions- it doesn't matter a lot.

> But have you made sure that the two perverse cases are done propery:
> FULL and EMPTY.

My implementation works flawlessly, including all border cases, both in
hardware (when distributed RAM is derived) and in simulation. It
handles simultaneous reads/writes on the same cycle a-ok, also in cases
when this happens on an empty FIFO.

The only instance where things go awry is if I allow XST to derive
BRAMs (by adding a semantically empty register that the XST structural
pattern matcher seems to need). This, to me, indicates either a subtle
bug in my VHDL (I am not an expert) or a not-so-subtle bug in XST.

> This is quite easy in a synchronous design, but still requires some
> thought. (It's really tricky when the two clocks are not related...)

I like to think I have got all cases covered. I hope a VHDL veteran can
take a look at my code and point out my error. Alternatively, this
issue could indicate a problem with XST.

Regards, Sidney


Article: 86672
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: Mike Treseler <mike_treseler@comcast.net>
Date: Sun, 03 Jul 2005 16:51:12 -0700
Links: << >>  << T >>  << A >>
sidney@jigsaw.nl wrote:

> I reviewed the results of this query, but I don't see anything that is
> relevant to my problem I am afraid.

For some reason google pointed to the wrong item.
#13 in the thread has the keyword.

           -- Mike Treseler

Article: 86673
Subject: Re: Xilinx: XST synchronous FIFO using BRAMs
From: "Peter Alfke" <alfke@sbcglobal.net>
Date: 3 Jul 2005 16:53:54 -0700
Links: << >>  << T >>  << A >>
So let's wait for a VHDL guru. Probably on Tuesday...
Cheers
Peter


Article: 86674
Subject: Re: Problem for xilinx!!!
From: dejavu99@hotmail-dot-it.no-spam.invalid (damidar)
Date: Sun, 03 Jul 2005 19:16:02 -0500
Links: << >>  << T >>  << A >>
> Peter Alfkewrote:
Netiquette:
> 1. Do not use triple-exclamation marks
> 2. Do not blindly assume it's a "problem for Xilinx" when it looks
more
> like a "problem for damidar"
> 3. Follow the helpful hints
> 4. Realize that this is the July 4 long weekend in the US. Most
people
> do something more relaxing than reading the newsgroup.
> 5. Wait till Tuesday...
> Peter Alfke

What?????  :shock: 

....I've resolved....

Regards......




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