Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
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 JonesArticle: 86651
Doug, before anybody can give you a meaningful answer, we need to know something about the speed or bandwidth required by your system. Peter AlfkeArticle: 86652
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
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 AlfkeArticle: 86654
Thank you for your advice. Doug JonesArticle: 86655
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 > > > > CheersArticle: 86656
Sorry for the awful typos. I am really a good speller, but I got distracted... Peter AlfkeArticle: 86657
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
HELP ME HELP ME..... THANKS :(Article: 86659
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 AlfkeArticle: 86660
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. -- fredArticle: 86661
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 youArticle: 86662
Thanks Aflek for your suggestion.Article: 86663
Thanks gabor for your suggestion...Article: 86664
If you use the "weak pull-up option". Peter AlfkeArticle: 86665
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: 86666Sidney. 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 AlfkeArticle: 86667
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: 86668Mike 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, SidneyArticle: 86669
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, SidneyArticle: 86670
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 AlfkeArticle: 86671
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, SidneyArticle: 86672
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: 86673So let's wait for a VHDL guru. Probably on Tuesday... Cheers PeterArticle: 86674
> 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:
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