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'm looking for a FPGA that will b e used with a SERDES device. Originally I was looking at an XCV2000 or APEX1000 along with a SERDES device (most likely TI or Conexant 3.125Gbps) but I've heard that Xilinx is coming out with a FPGA that will have high-speed SERDES functionality built in. Does anyone know what the story is with that? Would you recommend that as a better/cheaper (how much?) alternative? DaveArticle: 36126
David wrote: > > I'm looking for a FPGA that will b e used with a SERDES > device. Originally I was looking at an XCV2000 or APEX1000 > along with a SERDES device (most likely TI or Conexant > 3.125Gbps) but I've heard that Xilinx is coming out with a > FPGA that will have high-speed SERDES functionality built in. > Does anyone know what the story is with that? Would you > recommend that as a better/cheaper (how much?) alternative? If you are in a hurry, just buy an off the shelf SERDES. Both brand A and X have new parts out designed for this, but you know how version 1.0 of anything can go . . . --Mike TreselerArticle: 36127
Mike Treseler wrote: > > Russell Shaw wrote: > > > I'm using leonardo-spectrum from the altera site: > > > > Version: v2001_1d.24_OEM_Altera > > (Release OEM Altera Candidate, compiled Jul 5 2001 at 23:42:12) > > > > When i modify vhdl code in a file and save it within leonardo, a > > new "run flow" compilation frequently doesn't read the new file. > > Is there a way around this problem? > > Leo reloads a file every time. > Check the file exemplar.log to see what it used. > The file path/name is the first uncommented line. The most recent exemplar.log on my pc isn't being updated when i do a compile. > Perhaps you forgot to save your project settings. I've tried that plenty of times, but leonardo has lots of bugs, and one of them is that most of the device settings you do in the flow tabs don't get saved with the project. Are you using a similar version?Article: 36128
Hi,
I have a been thinking about the feasibility of using FPGA's in
wireless computing devices like the much talked about "3rd Generation"
cellular terminals. With plenty of different wireless interfaces vying
for market share (GSM,GPRS, UMTS, 802.11, bluetooth - I'm in the UK :)
) it would appear that having a terminal reconfigure itself to suit
its environment is a neat solution.
However, after a casual play around with the Xilinx Virtex Power
Estimate Worksheet (http://www.xilinx.com/cgi-bin/powerweb.pl) it is
clear that power consumption did not make top priority in the design
of this architecture - quiescent power consumption appears to be in
the order of 10's to 100's of milli-Watts, however portable devices
demand idle power wastage to be in the order of micro-Watts or less.
So, do you think it is possible to apply similar power saving
techniques as used in low power DSPs like the TI C55X devices in order
to make FPGAs feasible in un-tethered devices? By this I don't mean to
suggest the FPGA would replace the DSP, I simply think it could be
integrated somehow and take on certain highly compute intensive
kernels to meet timing constraints and reduce energy consumption.
To make my question a little less philosophical I will list some of
the things that I believe (somewhat naively) could be done to reduce
quiescent energy consumption at the device level in an architecture
like the Xilinx Virtex.
(I guess some of these ideas, like other engineering decisions would
incur certain overheads - like an increase in die area or a decrease
in speed).
* Use less "leaky" transistors! (?)
* Ability to switch off power to non-volatile hardware (everything
except for configuration memory, RAM and flip/flops).
* Remove all the unnecessary circuitry - like all the different I/O
standard stuff. ("Unnecessary" in this specific high volume
application)
* Ability to prune the clock tree, hence only deliver the clock to the
parts of the device in use.
* Use very low power SRAM for configuration memory (since this cannot
be switched off without incurring a huge latency/energy penalty next
time the FPGA is required).
any comments or opinions on how far energy wastage could be reduced
and the consequences in terms of die area/speed?
Irwin Kennedy
PhD Student
University of Edinburgh
Article: 36129There were some news about Virtex II with PowerPC cores. Altera announced Excalibur series with ARM or MIPS cores. What is the schedule of production of the first one? Is there any good story on the use of the second one? Please let me know...Article: 36130
Russell Shaw wrote: > > I'm using leonardo-spectrum from the altera site: > > > > Version: v2001_1d.24_OEM_Altera > The most recent exemplar.log on my pc isn't being > updated when i do a compile. Either your project directory isn't where you think it is, or you need to reinstall the software. > most of the > device settings you do in the flow tabs don't get > saved with the project. Haven't seen anything like that. > Are you using a similar version? I am using v2001_1a.32 You might try a released version. --Mike TreselerArticle: 36131
Hello VR, Device support can be found in Answer Record 12562 in the Answers Database. In regards to your question, the 4.1i version of the Foundation software does not add any new device support. I hope this helps. Best regards, Kamal Patel VR wrote: > I didn't see this question answered, so I'm posting under a slightly > different subject. > > I just would like to know if Foundation 4.1i (w/SP1?) supports any more > parts than 3.1i w/SP8. > > Trying to find this information on Xilinx's site isn't easy, I've already > tried, that's why I'm asking here. > > I'm also curious if Foundation 4.1i actually has any real usefulness over > Foundation 3.1i(w/SP8)? Is "XST" synth much better than the latest > offerings from Synplicity(Synplify Pro 7.0) or Exemplar(Leonardo 2001.1d)? > > I found Foundation 3.3ISE pretty non-intuitive and I didn't like how with > Foundation 3.3ISE the Xilinx ver. of FPGA Express would overwrite a > non-Xilinx FPGA Express (and subsequently, wouldn't call the non-Xilinx > version!). > > Thanks, > VR.Article: 36132
The Xilinx Virtex-2 is the underlying FPGA for their upcomming Virtex-2 Pro parts that they say will have the 3.125GBaud SerDes blocks on it. Xilinx press releases and presentations say that the underlying SerDes technology is the Conexant SerDes that they have licensed. I believe that Conexant SerDes technology has been spun out into a separate company named MindSpeed. Given this, I would recommend doing your design with Xilinx Virtex-2 and the MindSpeed/Conexant SerDes, and use the integrated product when it becomes available. You can probably get more info on this by contacting your local Xilinx sales office. Philip Freidin On 30 Oct 2001 14:25:55 -0800, dvdprsns36@hotmail.com (David) wrote: >I'm looking for a FPGA that will b e used with a SERDES >device. Originally I was looking at an XCV2000 or APEX1000 >along with a SERDES device (most likely TI or Conexant >3.125Gbps) but I've heard that Xilinx is coming out with a >FPGA that will have high-speed SERDES functionality built in. >Does anyone know what the story is with that? Would you >recommend that as a better/cheaper (how much?) alternative? > > >Dave Philip Freidin FliptronicsArticle: 36133
I'd update to 4.1i. There are some improvements in the placer. Also, don't overconstrain (i.e., set multicycle paths, etc.) and maybe do some area constraints in the floorplanner. "William Lenihan" <lenihan3we@earthlink.net> wrote in message news:3BDE59A3.3C188BD5@earthlink.net... > I have a xcv600E design that is fairly well populated (82% utilization) > and the P&R time (starting from scratch) on our best Sun workstation is > ~ 2 hours (using Alliance s/w version 3.1i, though it says 'v3.3.08i' in > the "About" dialog box). > > I've been reading up on the concept of 'guided design', which is > supposed to let the software leverage the last P&R in doing the next > P&R, which presumably produces a new bitstream in much less time. ...... > my problem: I can see from the messages scrolling by in the Flow > Engine's window, that yes the switches are activated for guided design, > but it still takes in excess of 2 hours to do the P&R. This isn't the > efficiency gain I was hoping for. > > I tried this for a design that had a small change (INIT contents of a > Block RAM) and no change (same EDIF netlist), and there was no > difference. > > What are the trick(s) to making this guided design thing actually work > (faster)? > > Do I need to move up to the 4.1i release? > Special patches? > Does it even work at all (i.e., produce small design changes in less > time)? > > > Thanks in advance for any suggestions. > > -- > ============================== > William Lenihan > lenihan3weNOSPAM@earthlink.net > .... remove "NOSPAM" when replying > ============================== > >Article: 36134
On Tue, 30 Oct 2001 19:55:43 +0100, Falk Brunner <Falk.Brunner@gmx.de> wrote: >django625 schrieb: >> >> Greetings >> >> I'm using a Spartan XCS40XL part in a design which has several shift >> registers of various lengths and I'm using schematic entry. I'm >> confused as to how to specify the timing. I don't have enough clock >> buffers to use one for each shift register and I need obviously to >> ensure that a clock edge arrives at shift register flip-flop N before >> data has been shifted by flip-flop N-1, and it seems that this is a >> problem with my longer shift registers. > >;-)) >The global clock buffers drive a clock net for the whole chip. So all >you need is just to connect your clock input pin to a global clock >buffer and then use this signal for all FFs in the shift register. To be more accurate, your clock signal from outside the chip is connected to the input of a clock buffer, and the output of the clock buffer is connected to the clock pin of all your flipflops. The clock buffers have dedicated routing resources on their outputs, called "clock nets", that have been pre-designed to have minimal skew between all destinations. The net also has sufficient buffering that it can drive all flipflops in the chip. > Works >nice, you dont have to worry about skew, fan-out, hold-time etc. > Philip Philip Freidin FliptronicsArticle: 36135
I want design bi-direction bus within the chip not on the interface of the chip.3-state gate is only used on the interface of the chip. I had solved the problem by using another group of pins. 3-state gate is very good. Thank you! "Peter Alfke" <palfke@earthlink.net> ??????:3BDE390F.FA1AC592@earthlink.net... > > > deerlux wrote: > > > I want to implement a bideriction bus buffer controlled by "DIR". But I > > don't want to use 3-state gate.Can I do it? > > No, you cannot. What's wrong with 3-state? It has served us well for 35 > years... > > Peter Alfke > >Article: 36136
"Ian Dedic" <ian.dedic@acg.fujitsu-fme.com> wrote in message news:1476aea8.0110300737.70ca6884@posting.google.com... > I doubt if any integrated DLL/PLL is good enough for this, depending > on what level of phase noise/jitter performance you're looking for. -100dBc/Hz from 1kHz to 10kHz, down from there... :-( > When we're doing our DAC evaluations we have difficulty finding any > clock source with low enough jitter, even low-noise benchtop RF > generators. > > You might want to look at PLLs based on voltage-controlled SAW > oscillators from vendors like Sawtek -- their lowest jitter VCSOs have > about 0.01ps rms jitter... > Thanks for the comments. I was pretty sure that an integrated device wasn't going to be suitable for what we wanted (including the PLLs built in to some of the DACs). We're currently looking at a "discrete" Colpitts oscillator, with a ceramic resonator as an inductor, and a seperate PLL control chip, as a clock source. The Sawtek idea is worth looking at, but I need a non-standard frequency, and it would probably cost megabucks for a custom VCO... The FPGA clock is EASY compared to this analog/RF stuff.... Paul T CAE Inc [from home]Article: 36137
Mike Treseler wrote: > > Russell Shaw wrote: > > > > I'm using leonardo-spectrum from the altera site: > > > > > > Version: v2001_1d.24_OEM_Altera > > The most recent exemplar.log on my pc isn't being > > updated when i do a compile. > > Either your project directory isn't where > you think it is, or you need to reinstall the > software. I downloaded and re-installed it, but nothing changed. A search of exemplar.log on the whole pc didn't find anything other than what's in the current directory. > > most of the > > device settings you do in the flow tabs don't get > > saved with the project. > > Haven't seen anything like that. > > > Are you using a similar version? > > I am using v2001_1a.32 > > You might try a released version. I guess mine's released, as it came from the altera site. Also, if i open the project in leonardo, but don't open the .vhd text file, then "run flow" compiles it. If i use note-pad to put some garbage in the file and save it, leonardo doesn't show the syntax errors. If i delete the .vhd file, leonardo still compiles it, giving the same error messages as the last compilation. It seems like a data-base thing. I'm using win2k.Article: 36138
Irwin Kennedy wrote:
> Hi,
> I have a been thinking about the feasibility of using FPGA's in
> wireless computing devices like the much talked about "3rd Generation"
> cellular terminals. <snip>
> To make my question a little less philosophical I will list some of
> the things that I believe (somewhat naively) could be done to reduce
> quiescent energy consumption at the device level in an architecture
> like the Xilinx Virtex.
>
> (I guess some of these ideas, like other engineering decisions would
> incur certain overheads - like an increase in die area or a decrease
> in speed).
FPGA design, like all engineering, involves trade-offs.
We at Xilinx are being pressured by our customers to deliver FPGAs that
are:
faster, bigger in logic capacity, cheaper, more flexible and easier to
use, and consume less power. In my estimate somewhat in that order. And
we try to do a good job responding to all these conflicting demands. Here
are some comments:
>
>
> * Use less "leaky" transistors! (?)
Until recently, there was extremely little junction leakage or
sub-threshold leakage current. XC3000L could run on 50 microamps.
Unfortunately, as we approach 100 nm technology, subthreshold leakage
current becomes significant ( for every IC manufacturer. Ask Intel! )
>
>
> * Ability to switch off power to non-volatile hardware (everything
> except for configuration memory, RAM and flip/flops).
All storage in our FPGAs is inherently volatile, but CoolRunner CPLDs
uses non-volatile storage for their configuration. And they consume
extremely low power, down to microamps. Powered by grapefruits. :-)
>
>
> * Remove all the unnecessary circuitry - like all the different I/O
> standard stuff. ("Unnecessary" in this specific high volume
> application)
Removing it would separate us from very attractive markets. Although it
costs area, it costs hardly any extra power, and if, then only in
high-frequency outputs.
>
>
> * Ability to prune the clock tree, hence only deliver the clock to the
> parts of the device in use.
That's what we do. We distribute the clocks on a horizontal spine, but
activate the vertical "ribs" only when needed. Thanks for the suggestion,
we anticipated your idea. :-)
>
>
> * Use very low power SRAM for configuration memory (since this cannot
> be switched off without incurring a huge latency/energy penalty next
> time the FPGA is required).
The configuration store used to consume microamps at most. It is only
recently that deep sub-micron technology has increased this current to
milliamps. There is little we can do about subthreshold leakage.
>
>
> any comments or opinions on how far energy wastage could be reduced
> and the consequences in terms of die area/speed?
For the present generation FPGAs, speed, flexibility (versatility), and
cost have been the main driving forces.
Our CoolRunner CPLDs address the issue of low power brilliantly. They are
by far the least power-hungry programmable devices in the universe. And
they are easy to design with. And the software is free. But they do not
reach the complexity level of the bigger Virtex and Spartan device.
Everything is a trade-off. Believe us that we try to keep the static and
dynamic power as low as possible, but for FPGAs, speed and versatility
come first.
You can still buy XC3000L, but you would not be impressed by the
functionality and performance.
You might also look at SpartanXL, a 3.3-V, XC4000-derived family with
fairly low power and more modern features. But CoolRunner is the
all-time champion of low power in programmable logic.
Peter Alfke, Xilinx Applications
Article: 36139Hi all experts out there, I would like to seek help in ways to reduce BRAM usage in the following two scenarios. This post contains only the first scenario. I will post the second scenario in another post. (1) I need a 2600 deep 16 bit wide FIFO (independent read/write clocks). Using Xilinx's 4Kbit DPRAM, I realize I will need 16 blocks of them, giving me a 4096 by 16 bit FIFO instead. (In fact, I am using the gray-coded FIFO as supplied by Xilinx in XAPP131, after some modification). I am wasting too many block rams. So I am thinking of cascading a 2048x16 and a 1024x16 FIFOs to give me a 3072x16 FIFO (I stuck to depth of power 2 to avoid muxing control/output and also to keep it easier for the gray codes). There will be a simple data relaying between the 2048x16 and the 1024x16 FIFOs: whenever the second FIFO is not full and the first FIFO is not empty, read out the first FIFO and write into the second FIFO (taking into account the delayed response of the empty/full flags). I would like to seek out opinions on any pitfall in this approach. If there are others ways of reducing block ram usage, I would be glad to hear them. Thanks in advance. TA TA. Best Regards, kahheanArticle: 36140
Hi all experts out there, I would like to seek help in ways to reduce BRAM usage under two scenarios. This post contains only the second scenario. I have posted the first scenario in an earlier post. (2) I need a 1024 by 9 FIFO (independent read/write clocks). If I implement a 1024 by 16, I will be needing four 4Kbit BRAMs and actually wasting 7/16 of the capacity. Suppose I can afford only two block RAMs. Can I implement a 1024 by 8 (two blocks) BRAM-based FIFO and then parallel it with a 1024 by 1 FIFO implemented with distributed SRAM? I am personally not uncomfortable with this approach, because the full/empty flags of the two FIFOs may not be in-sync (especially now that one is BRAM based, and another distributed SRAM based). And if they do go out of sync, the only way back is to reset both FIFOs. :-P Supposing I can solve the above problem, how do I code a 1024 by 1 FIFO for Xilinx Virtex-E FPGA? I noticed that Coregen only allows depth of 256 for both async FIFO and DPRAM. If I have to build SRAM-based from scratch, is there a primitive for SRAM-based Dual Port? Thanks in advance. TA TA. Regards, kahheanArticle: 36141
Hello banana, Unfortunaltely you cannot use both the rising as the falling edge in a single process. What you can do is 1. double the clock (by using a dll) 2. use the rising edge of that clock signal to generate a 'switch bit' (0 - 1 - 0 - 1 - 0) 3. yhen use the double clock in a process together with the 'switch bit' (if double_clk'event and double_clk = '1' then if switchbit is 1 then ...code... else ...code... end if; good luck, philipArticle: 36142
Good Morning,
I sinthesize a counter by 3 that I also use to interpolate the clock
by one,
this code is working with Active HDL but It give me some problem with
Xilinx , in particular during the synthesis I've the error :
Analyzing Entity <counter_divider_3> (Architecture
<counter_divider_3_arch>).
ERROR : (VHDL_0047).
C:\Documenti\XilinxDesign\QPSKModulator\counter_divider_3.vhd (Line
23). Bad Form of Clock Condition.
-->
Following there is the code, can you explain me why it doesn't work on
Xilinx and how I can modify it to work properly ?? The line that is
not good is
"if clk'event then "
Thanks ,
Bananone
library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
entity counter_divider_3 is
port (
clk : in STD_LOGIC;
reset : in STD_LOGIC;
count_3 : out STD_LOGIC_VECTOR (2 downto 0);
clk_div_3 : out STD_LOGIC
);
end counter_divider_3;
architecture counter_divider_3_arch of counter_divider_3 is
begin
process (clk, reset)
variable count_3_interno : STD_LOGIC_VECTOR (2 downto 0);
begin
if reset = '1' then
count_3_interno := "000";
else
if clk'event then
if falling_edge(clk) then
if count_3_interno < 2 then
count_3_interno := count_3_interno + 1;
else -- si deve riazzerare il contatore
count_3_interno := "000";
clk_div_3 <= '0' ;
end if;
else -- vuol dire che siamo sul fronte positivo
if count_3_interno = 1 then
clk_div_3 <= '1' ;
else null;
end if ;
end if ;
else null ;
end if;
end if ;
count_3 <= count_3_interno;
end process;
end counter_divider_3_arch;
Article: 36143In ds030.pdf, v1.8, I haven't found any PROM that can hold config data of 2 separate XCS30XLs. Is there any such big PROM? Or shall I use 2 separate XC17S30XLs? UtkuArticle: 36144
Peter Alfke wrote: > Irwin Kennedy wrote: > > > Hi, > > I have a been thinking about the feasibility of using FPGA's in > > wireless computing devices like the much talked about "3rd Generation" > > cellular terminals. <snip> Have a look at http://bwrc.eecs.berkeley.edu/Research/Old/Infopad/ For the same netlist, an ASIC requires a lot less power than an FPGA, but with FPGAs the netlist can be specializes to the current application. This results in a smaller netlist and less switching. <snip> > > * Use less "leaky" transistors! (?) > > Until recently, there was extremely little junction leakage or > sub-threshold leakage current. XC3000L could run on 50 microamps. > Unfortunately, as we approach 100 nm technology, subthreshold leakage > current becomes significant ( for every IC manufacturer. Ask Intel! ) > > > * Use very low power SRAM for configuration memory (since this cannot > > be switched off without incurring a huge latency/energy penalty next > > time the FPGA is required). > > The configuration store used to consume microamps at most. It is only > recently that deep sub-micron technology has increased this current to > milliamps. There is little we can do about subthreshold leakage. You can. You do not need fast transistors in your configuration memory. As you are using an SOI technology for Virtex-II you could easily use a higher threshold voltage for your configuration SRAM transistors as for your CLB logic transistors. (Hmmm. You probably do allready.) You could do the same for your logic: A configuration bit could select between fast, high leakage transistors and slow, low leakage transistors on a per CLB basis. The software tools could automatically set this bit for all CLBs that are not on the critical path. A power down mode could even dymically controll the threshold voltage. Kolja SulimmaArticle: 36145
Eric Smith wrote: > Kevin Brace wrote: > > Xilinx IP Evaluation License Agreement > > > > Xilinx Evaluation IP is owned and controlled by Xilinx and > > must be used solely for design, simulation, implementation and > > creation of design files limited to Xilinx devices or technologies. > > Use with non-Xilinx devices or technologies is expressly prohibited > > and immediately terminates your license. > > Kolja Sulimma <kolja@sulimma.de> writes: > > This violates the "principle of first sale" > > Many things in the US violate the principle of first sale. In general, > U.S. copyright law does. For instance, when you buy a VHS tape of a > movie, you aren't allowed to use it for public exhibition. Yes, But Sony Home Entertainment video can not terminate your license when you play it on a Grundig VCR. > License agreements may well violate the principle of first sale. The > question is whether the license is binding and enforceable. Kolja SulimmaArticle: 36146
Eric Crabill wrote: > Hi Kolja, > > I'm not a lawyer, so I can't say for sure... But I think > the Xilinx IP Evaluation License Agreement means that Xilinx > retains ownership of the IP and is licensing it, not selling > it, to whoever happens to download the evaluation. I believe > the same is true of the full-featured product. A contract to transfer a good for an unlimited amount of time without paying a recurrent fee is a purchase, no matter what it is called in the contract. I am pretty sure that after purchasing the core package I own the documentation, constraints files and the core generator software. To be able to sell copies of the core to customers I need of course a license as this can not be covered by the purchase alone. In a b2b context this license can be more or less contain arbitrary agreements between me and the vendor. However, a license that states that Xilinx remains the owner of the IP is worthless, as this would mean that Xilinx would own part of any product that contains the core. At least the end customer of my product must become owner of the netlist in the FPGA. And this of course allows me to become owner of the netlist myself. (Would you buy a network adapter that comes with a license agreement that states that part of the adapter is owned by Xilinx?) If I use part of the netlist or source code in my own PCI core I of course violate theire copyright. I can however not violate any Xilinx patents because I licensed them from SIGPCI. Kolja Sulimma (DISCLAIMER: I want to state that I designed my own PCI core _before_ I downloaded the Xilinx PCI core)Article: 36147
> I am sure that it depends on the skill of the designer, but from my > experience trying to meeting timings with my own PCI IP core, I think > meeting 33MHz PCI timings with a synthesizable (HDL based) PCI IP core > with only automatic P&R is very challenging to say the least. I found that most constraints violations were false paths. For a PCI slave only TRDY and the output enable generation is a real problem. In Virtex architectures there is a special logic block for this. The functionality was documented earlier in this newsgroup. Kolja SulimmaArticle: 36148
Hello all, I am searching for a high density non bga package FPGA. I don't want to use BGA since the high prototyping costs involved. My estimation is that PGA packages are cheaper to produce. Are there any SPartanII Virtex/II/E devices in this package? Hope you can help. Richard -- Quest Innovations tel: +31 (0) 227 604046 fax: +31 (0) 227 604053 http://www.quest-innovations.comArticle: 36149
Chua Kah Hean schrieb: > > Hi all experts out there, > > I would like to seek help in ways to reduce BRAM usage in the > following two scenarios. This post contains only the first scenario. > I will post the second scenario in another post. > > (1) > > I need a 2600 deep 16 bit wide FIFO (independent read/write clocks). > > Using Xilinx's 4Kbit DPRAM, I realize I will need 16 blocks of them, > giving me a 4096 by 16 bit FIFO instead. (In fact, I am using the > gray-coded FIFO as supplied by Xilinx in XAPP131, after some > modification). > > I am wasting too many block rams. So I am thinking of cascading a > 2048x16 and a 1024x16 FIFOs to give me a 3072x16 FIFO (I stuck to > depth of power 2 to avoid muxing control/output and also to keep it > easier for the gray codes). There will be a simple data relaying > between the 2048x16 and the 1024x16 FIFOs: whenever the second FIFO is > not full and the first FIFO is not empty, read out the first FIFO and > write into the second FIFO (taking into account the delayed response > of the empty/full flags). > > I would like to seek out opinions on any pitfall in this approach. Hmm, possible BUT, - this will increase latency - using two FIFO from Xapp131 will take 3 clock nets (write clock, in-between clock, read clock) > > If there are others ways of reducing block ram usage, I would be glad > to hear them. Why dont you rearange the RAMS? Just use 12 256x16 BRAMs and create a chip select from the address counter[11:8]. Since this is just a 4 bit decoder it take only 1 LUT, so only 1 level of locic -> very fast -- MFG Falk
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