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
Dear all, I want to ask if there is any limitation or restriction on using the LVDS I/O on Virtex II FPGA? For example, the maximum number of LVDS I/O used at the same time? I can find similar information for the signle ended I/O from the User Guide but not for LVDS. Anyone has idea about it? Or know how to search such information? Thanks in advance. Regards, KennethArticle: 41501
Hi, does any of you know where to find a C-library handling the compilation from VHDL to the bitstream format ? Any target FPGA will do ... Thanks in advance for your help :-) -Yves.Article: 41502
I'm working on development of Intel 8051 microcontroller architecture using VHDL on FPGA. I want to write code for its memory architecture ie RAM and ROM. Can anyone please suggest me how to proceed for the same. Thanks, TinaArticle: 41503
[delays on feedback path for hyteresis] >It is positive feedback, so unless your signals are toggling very fast, the >delay is of no consequence. If you are toggling fast enough for it to be an >issue, you probably don't need the hysteresis in the first place. Thanks. I think that's the general answer I was fishing for. Can we add some numbers to this discussion? How can I compute (or estimate) if I need hyteresis and/or if the feedback will get back in time? For example, it probably won't work as well if the feedback path goes accross a large chip, say because that's where a pin was free. How much extra delay is added to an input pad when the rise time is slow? Will the feedback be fast enough if the feedback delay is less than the extra delay from the slow rise time? -- These are my opinions, not necessarily my employer's. I hate spam.Article: 41504
There are no limitations. LVDS is differential standard, therefore its outputs do not generate ground bounce. Peter Alfke ================================== Ken wrote: > Dear all, > > I want to ask if there is any limitation or restriction on using the LVDS I/O on Virtex II FPGA? For example, the maximum number of LVDS I/O used at the same time? > > I can find similar information for the signle ended I/O from the User Guide but not for LVDS. > > Anyone has idea about it? Or know how to search such information? Thanks in advance. > > Regards, > KennethArticle: 41505
Do you really want to rehash a 30-year old architecture ? Why? Homework ? Peter Alfke Tina wrote: > I'm working on development of Intel 8051 microcontroller architecture > using VHDL on FPGA. I want to write code for its memory architecture > ie RAM and ROM. Can anyone please suggest me how to proceed for the > same. > > Thanks, > TinaArticle: 41506
Yves Petinot wrote: > Hi, > > does any of you know where to find a C-library handling the compilation from > VHDL to the bitstream format ? Any target FPGA will do ... Give up on this idea. You will not find such a library, for a variety of reasons that have been thoroughly discussed in this newsgroup... Peter AlfkeArticle: 41507
Thanks for looking - According to Xilinx's web site, Xilinx does not provide schematic symbols for their FPGAs. Instead, they recommend going through some of the 'alternative' support channels, such as the comp.arch.fpga newsgroup. I am looking for the schematic symbol for a Xilinx Spartan IIE 50 in the 208 QFP package (XC2S50E PQ208). I would really appreciate getting this symbol. If you reply by email, remove the '.nomorespam' from my email address. Thanks!Article: 41508
In article <zBIp8.15888$Eb5.1425881@bgtnsc05- news.ops.worldnet.att.net>, eedigital.nomorespam@hotmail.com says... > Thanks for looking - > > According to Xilinx's web site, Xilinx does not provide schematic symbols > for their FPGAs. Instead, they recommend going through some of the > 'alternative' support channels, such as the comp.arch.fpga newsgroup. > > I am looking for the schematic symbol for a Xilinx Spartan IIE 50 in the 208 > QFP package (XC2S50E PQ208). I would really appreciate getting this > symbol. IMO, you're much better off creating meaningful symbols for your application. For larger devices (I found 680 pins a bit much for a page ;-) I break the symbols up according to function using heterogeneous blocks. It makes the schematic much easier to read. ---- KeithArticle: 41509
Digital EE wrote: > > Thanks for looking - > > According to Xilinx's web site, Xilinx does not provide schematic symbols > for their FPGAs. Instead, they recommend going through some of the > 'alternative' support channels, such as the comp.arch.fpga newsgroup. > > I am looking for the schematic symbol for a Xilinx Spartan IIE 50 in the 208 > QFP package (XC2S50E PQ208). I would really appreciate getting this > symbol. > I just went through this. I followed the advice of a message I found in the Google usenet archives. This was for a Spartan II 50, in the 256 pin BGA package. XC2S50-6FG256 I made 11 parts: Parts 1-8 each contain the i/o pins for Banks 0-7, respectively. Each part also has the two Vcco pins associated with the bank. Some of the i/o pins in a bank can also be used for Vref. These pins also go on the part. There are some pins that are dual purpose, either config or i/o. For these, I put them on Part 9, (the Config part) below. Part 9 is the clocks, GCK0-3. Part 10 is the config pins: M0-2, JTAG, and the Serial pins. Part 11 is power -- Vccint, all the GNDS, and two NC pins. The parts are all long, slim rectangles, with the pins only on the left side, except for the Power part, which has pins on both sides. If you print out the actual chip footprint from Xilinx's web page, you can mark off which pins go with each bank. I did this with colored pencils. The bank pins are grouped together in little clumps. So it makes sense to make a symbol for each bank. Also, of course, it makes electrical sense because you can change the Vcco and Vref on a per-bank basis in Xilinx chips. The library part (this is for Protel) has everything dumped on one large square, which takes up an entire A-size sheet. But I used it to speed up the part-making process. It had its pins arranged in banks. So I just copied and pasted them onto my single-bank parts. That way, I didn't have to type in all the pins myself. It saved a lot of time. The advantage of making single-bank parts is they take up a lot less space on the page, and they are a lot more flexible. -----= Posted via Newsfeeds.Com, Uncensored Usenet News =----- http://www.newsfeeds.com - The #1 Newsgroup Service in the World! -----== Over 80,000 Newsgroups - 16 Different Servers! =-----Article: 41510
Hi, one thing I noticed while getting my homebuilt ByteBlasterMV compatible cable to run is that you must connect pin 7 of the JTAG port to Vcc (e.g. via a pullup resistor) although the documentation says that pin 7 is not used in JTAG mode. If pin 7 is tied to ground the programmer software always complains that it does not recognize the chip. This means that the programmer does not ignore the state of the corresponding input pin of the parallel port (although it should, probably). Cheers, Joachim "Alexander Miks" <monstrum@tiscali.se> wrote in message news:<YvQo8.1052$m4.19063@news010.worldonline.se>... > I have built an Altera downloading-cable based on the ByteBlasterMV > datasheet. The problem is that it won't work. So where do I start > troubleshooting? I've checked all connections, so that shouldn't be the > problem. And is the cable supposed to be able to detect without being > connected to the target board (only power-supply)? > Please help me out, I'm a very poor student and I can't afford to spend $150 > (or more likely twice of that over here in Sweden).Article: 41511
Hi, I have posted the attached message almost two weeks ago. I have received responses (12 opinions) and stimulated discussions. The responses I got seem equally divided. I have learned several things which I have overlooked. You can view those opinions in the following Web site: http://petition-synplify.0catch.com I still would like to have more responses from FPGA/ASIC designers. With few more responses, I will wrap up this petition and present to Synplicity. (However, developers in Synplicity are already following this petition.) The more I hear others' opinions, the more I feel that this is something Verilog standard didn't do a good job. I can find both "for" and "against" reasons in the standard. My goal was not to force my opinion to Synplicity. My goal was to examine what the logic mapping should be for such RTL design. We are "engineer", aren't we? Hope my posting has provided something constructive to the FPGA/ASIC/synthesis community. Best regards, Aki Niimura // My posting (Date: Mon, 18 Mar 2002) Dear Fellow FPGA designers, I would like to have your feedbacks / supports. Synplicity has released Synplify 7.0.x with lots of enhancements last November. One of the enhancements is called "Tri-state push thru" feature. The following are excerpts from e-mails from Synplicity explaining how the feature works: > For example in the verilog code > > assign data = en ? data_in : 1'bz; > always @(posedge clk) > begin > q_out = data; > end > > will be implemented with tristate after the q_out flipflop currently ( 7.02 > ) to match simulation. The tristate will be implemented > before the q_out flip flop with the switch ( 6.2.4 behavior). > In 6.2.4 we didn't perform Tri-state push through across boundaries > as like every other Synthesis tool on the market. We (and many > of our customers) deemed this logically incorrect. We enabled > Tri-state push thru in 7.0, but some of our customers requested > a 'compatibility' switch so that our results matched our competition, > hence the switch in 7.1. > This switch fixes what we consider to be bad logic and was a > definite requirement from our customers. Simply saying, Synplify 7.x will implement the logic differently from the RTL code you have specified to prevent simulation from causing a mismatch. I have noticed this new feature because my design becomes 30% larger and yet slower when I resynthesized my existing design using Synplify 7.0.2. With this feature: 1086LUTs (30.2MHz) <<-- default in Synplify 7.x W/o this feature : 833LUTs (31.8MHz) My design uses tri-state gates to implement a multiplexer with a large number of inputs efficiently which is a widely used FPGA technique. I hand-crafted the multiplexer such that speed and logic size are both satisfied. Synplify 7.x will implement the multiplexer using LUTs and put a tri-state gate after the LUTs. (tri-state gate is pushed-thru) I thought this feature was creating more harms than goods. Not only because I'm getting inferior results but also I feel the synthesis tool should deliver the exact logic which the input RTL code specified. (Otherwise, FPGA designers can not control how the logic is laid out.) Note: Synplify 7.1 has a switch to select this feature. However this feature is always turned on by default. However, the response I got from Synplicity is quite different from what I had imagined. After many e-mail exchanges, Synplicity has notified me their conclusion: > We still strongly feel that disabling the Tri-state push thru by > default would hurt too many of our customers - who specifically > demanded this feature. We have accommodated for those customers > who prefer the legacy implementation by adding the switch. > > We have several test designs with test-benches which clearly > show RTL / simulation mismatches with this switch disabled. > > Our senior management strongly believes this decision is correct > and in-line with our policy of correct logic implementation. Unfortunately, their conclusion is completely opposite to my understanding. I'm still not convinced that such logic mapping is correct. Since Synplify is #1 in the FPGA synthesis market, a huge number of engineers in the world are using Synplify to design FPGAs. I would like to ask everyone about this new feature of Synplify 7.x. If you feel this feature is incorrect and dangerous (or support Synplicity's arguments), please send me an e-mail. I will present all e-mails I receive to Synplicity (both for and against). Feedback / support to : synp_petition@usa.net I will post the update when I have something to report. Thank you for your attention. Hope I can hear from many of you. You can forward this to any other newsgroups or your friends to get more feedbacks. Sincerely yours, Aki Niimura - being a Synplify user since 1999 P/S I have created a Web site to list feedbacks I receive. http://www.petition-synplify.0catch.comArticle: 41512
Hey all, I use Foundation (Xilinx) at work and I recently started working with the Webpack software and the way the schematic handles a bus tap is confusing. How do I take a tap off of a buss for one single signal? Example: DATA(7:0). I added the buss tap symbol on the bus, and pull a single net off the bus tap symbol and name the net A(7). When I use the check on the schematic editor for errors, I get a silly message saying that one side of the bus tap is a bus and the other is a single net. Please don't tell me that Xilinx went from idiotic (Foundation) to completely moronic with Webpack. Anyway, I just need to know how to tap off a bus in Webpack. Thanks for taking the time to read my ranting. LTArticle: 41513
Are there even any V2 Pro parts available yet? I'd image development boards should be available soon after the parts themselves start shipping, but I'm not sure the parts are out there yet. -Pete- Unit Manager <antipattern@hotmail.com> wrote in message news:e1f38cc5.0203290119.6aeecfb2@posting.google.com... > Do you aware of any Virtex II pro development board on market? > > and > > Which high density FPGA board you would suggest? > > Thanks, > ~pat!Article: 41514
Hi all, I am generating a pulse (the pulsewith is 66.6ns) according to a look-up table. The maximum PRF is 80kHz. Let say the original signal name is X, then I also drive this signal off the chip at 3 different pins with different signal names. In fact all 3 signals are the same only names differ. I observed glitches on X but not on Y and Z. My question is what can I do in the FPGA in order to prevent glitches. I am using Altera Apex20K400E-1X device. Thanks in advance. -- Posted via Mailgate.ORG Server - http://www.Mailgate.ORGArticle: 41515
Brian,
While to_X01(ts_mux) may not work, I have confirmed that writing your own
resolution function does for both 7.03, and 7.1 beta:
signal res_01 ;
function res_01( a : std_logic ) return std_logic is
begin if( a = '0') then return( '0' ) else return ('1') end if ;
That function is completely portable.
The thing that grates me about this whole debate is that Synplicity doesn't
infer the tri-state drivers on the combinatorial side when this default
"feature" is in the code. And this includes 7.1 beta. How can they claim
to infer propagation of a 'Z' that they first eliminate? It was the loss of
the tri-state on the LHS that first got Aki's attention.
Simulation of the combinatorial net does not match Synplify 7.03, or 7.1
default output, period. Take the various cases, simulate and display the
states on both sides of the FF, and then take the output from 7.03, or 7.1
and compare. Depending on version and settings, either the LHS, or the RHS
pre-synthesis and post-synthesis will not match. Worse, the behavior in 7.1
with the default push-through enabled produces different results in response
to different, but exactly equivalent coding styles.
If you code a tri-state into a function, and invoke that function in-line,
then 7.1 performs with push-through as discussed on this thread. However,
merely encapsulating the function in a component, magically returns 7.1 with
push-through turned on to the coded behavior, tri-state on the LHS, and a
straight FF.
On the matter of whether the push-through should be done at all, I would
like any advocate of the Z push-through to explain how it is that in either
VHDL or Verilog we can have store a result without first declaring a Verilog
reg, or VHDL signal to hold that result? Nowhere in any of the code
examples I have seen is there a declaration of that stored result that
Synplify dutifully produces. Do these advocates recognize that their
position dictates a discrete 'Z' state register for every address location
in a memory array where the data input is a tri-state bus?
Simulation is a fantasy that we do our best to make useful. Part of that
task is construction of a reasonable model for the tool, and sane
interpretation of the results. Whether the simulator chooses to acknowledge
it or not, a voltage storage device has no means to propagate the impedance
condition present at its input. If we want to be thorough, we can overcome
the simulator limitation with a resolution function. Overcoming reality
with the synthesis tool seems a poor choice. I want to see the poor devil
who thinks a semiconductor manufacturer will change the design of their
parts because the way they work on his board isn't the same as in his SPICE
simulation.
This is one of the few times that Synplicity screwed-up, and they need to
fix it sooner rather than later. The first step is to restore the correct
synthesis of tri-states on the combinatorial side where the code has
explicitly placed them.
Then, if they still find that loopy customers expect magic FF's, and want
them, let those users put the tool in Timothy Leary mode. But IMO, by no
means should simulation aberrations drive default synthesis behavior.
Regards,
Steve
"Brian Davis" <brimdavis@aol.com> wrote in message
news:a528ffe0.0203241856.35a17d34@posting.google.com...
> Allan wrote:
>
> >
> >I would add to this:
> >
> > sig3 <= to_X01(ts_mux);
> >
> >This should *never* allow a tristate to propagate through
> > a flip flop, regardless of any tool settings.
> >
>
> Thanks, I added that one to my test-case-in-progress.
>
> sig1 <= ts_mux;
> sig2 <= ts_mux AND '1';
> sig3 <= to_X01(ts_mux);
>
> Although both sig2 and sig3 resolve to 'X' in pre-synthesis
> simulation, Synplify 7.0.3 builds a tristate on all three outputs
> instead of just on sig1.
>
> That is completely incorrect from any perspective, whether you
> believe in Z-transport DFFs or not.
>
>
> Test Case notes ( see code below):
>
> Sig5 shows the tristate pushthough in action across a big shift
> register, which requires pipelining the phantom enable to match.
>
> Also see sig7, which shows the tristate pushthough affecting
> some combinatorial logic described with a conditional assignment.
>
> For a real chuckle:
> - synthesize the test case below
> - look at the synthesis results in the HDL Analyst RTL viewer
> - uncomment the fourth driver on the tristate bus & resynthesize
> - look at the synthesis results again
>
>
> Improved workaround:
>
> Although "to_X01" doesn't work in Synplify 7.0.3, you could write
> the following and still be fairly portable if you always use this
> resolved signal as the input to registers or other logic:
>
> attribute syn_keep : boolean;
> attribute syn_keep of ts_mux_resolved : signal is true;
> .
> .
> ts_mux_resolved <= to_X01(ts_mux)
>
>
> Other Notes:
>
> I was going to try this test case with Synplify 7.1, but it doesn't
> seem to be available on the website.
>
> I spent a while last night searching for this switch in 7.0.3;
> there seems to be no mention of this tristate pushthrough feature
> in the 7.0.3 release notes or documentation.
>
>
> thanks,
> Brian
>
>
> --
> -- tt2.vhd
> --
> -- - demonstrates nasty side effects of tristate pushthrough,
> -- which will unpredictably create tristates at output pins
> --
> -- - demonstrates improper implementation of the pushthrough feature
> -- - signals that have 'X's in pre-synth RTL sim also incorrectly
> -- suffer from tristate pushthrough
> --
> -- - tested with Synplicity 7.0.3, targeting Spartan-2
> --
> --
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity tt2 is
> port
> (
> clk : in std_logic;
>
> sel : in std_logic_vector( 1 downto 0 );
>
> a_in : in std_logic;
> b_in : in std_logic;
> c_in : in std_logic;
> d_in : in std_logic;
>
> dummy : in std_logic;
>
> sig1 : out std_logic;
> sig2 : out std_logic;
> sig3 : out std_logic;
> sig4 : out std_logic;
> sig5 : out std_logic;
> sig6 : out std_logic;
> sig7 : out std_logic;
> sig8 : out std_logic
> );
> end tt2;
>
> architecture arch1 of tt2 is
>
> signal ts_mux : std_logic;
>
> constant PIPE_MSB : natural := 17;
> signal pipe : std_logic_vector(PIPE_MSB downto 0);
>
> begin
>
> --
> -- build an not-fully-populated internal tristate mux
> --
> ts_mux <= a_in when sel = "00" else 'Z';
> ts_mux <= b_in when sel = "01" else 'Z';
> ts_mux <= c_in when sel = "10" else 'Z';
>
> --
> -- Need to comment out the last driver so tristate pushthrough
> -- behavior appears. If the tristate mux is fully populated,
> -- some of the output tristates vanish, as Synplify's analysis
> -- of the enables concludes that the bus is always being driven
> --
> -- ts_mux <= d_in when sel = "11" else 'Z';
>
> --
> -- register the mux several ways
> --
> --
> out_reg: process(clk)
> begin
>
> if rising_edge(clk) then
>
> --
> -- results w/7.0.3 : sig1 has a tristate output
> -- MATCH
> --
> sig1 <= ts_mux;
>
> --
> -- results w/7.0.3 : sig2 has a tristate output
> -- MISMATCH
> -- AND is optimized away, although it should resolve signal
> --
> sig2 <= ts_mux AND '1';
>
> --
> -- results w/7.0.3 : sig3 has a tristate output
> -- MISMATCH
> -- resolution function is apparently ignored
> --
> sig3 <= to_X01(ts_mux);
>
> --
> -- results w/7.0.3 : sig4 has a normal output
> -- MATCH
> -- Synplify can't optimize this AND away, so it works
> --
> sig4 <= ts_mux AND dummy;
>
>
> --
> -- create a big shift register for the next two signals
> --
> pipe <= pipe(PIPE_MSB-1 downto 0) & ts_mux;
>
> --
> -- results w/7.0.3 : sig5 has a tristate output
> -- MATCH
> -- lots of enable pipelining
> --
> sig5 <= pipe(PIPE_MSB);
>
> --
> -- results w/7.0.3 : sig6 has a normal output
> -- MATCH
> --
> sig6 <= pipe(PIPE_MSB) XOR pipe(7);
>
> end if;
>
> --
> -- try a FF with reset
> --
> if dummy = '0' then
> sig7 <= '0';
>
> elsif rising_edge(clk) then
> --
> -- results w/7.0.3 : sig7 has a tristate output
> -- MATCH
> --
> sig7 <= ts_mux;
>
> end if;
>
> end process;
>
>
> --
> -- this pushthrough feature also affects combinatorial logic
> --
> sig8 <= ts_mux when dummy = '0' else NOT ts_mux;
>
> end arch1;
Article: 41516"Pete Dudley" <pete.dudley@comcast.net> schrieb im Newsbeitrag news:Wacp8.128139$7b.11591039@bin7.nnrp.aus1.giganews.com... > Quicklogic has a new family called Eclipse that is antifuse and goes up to > "500K" gates. They claim 600MHz internal clock frequency is possible. That > sounds competitive at a glance anyway. Does this really mean 600 MHz or "just" maximum FlipFlop toggle frequency? -- MfG FalkArticle: 41517
-- MfG Falk "I. Servan Uzun" <isu@btae.mam.gov.tr> schrieb im Newsbeitrag news:4f1f439498d164bee248303833255002.10234@mygate.mailgate.org... > Hi all, > > I am generating a pulse (the pulsewith is 66.6ns) according to a look-up > table. The maximum PRF is 80kHz. > Let say the original signal name is X, then I also drive this signal off > the chip at 3 different pins with different signal names. In fact all 3 > signals are the same only names differ. > I observed glitches on X but not on Y and Z. My question is what can I > do in the FPGA in order to prevent glitches. > I am using Altera Apex20K400E-1X device. Just use a FlipFlop after the decoder, this will avoid any glitches (as long as setup/hold times are met). Almost all decoders inhibit glitches. -- MfG FalkArticle: 41518
"I. Servan Uzun" <isu@btae.mam.gov.tr> wrote in message news:4f1f439498d164bee248303833255002.10234@mygate.mailgate.org... > Hi all, > > I am generating a pulse (the pulsewith is 66.6ns) according to a look-up > table. The maximum PRF is 80kHz. > Let say the original signal name is X, then I also drive this signal off > the chip at 3 different pins with different signal names. In fact all 3 > signals are the same only names differ. > I observed glitches on X but not on Y and Z. My question is what can I > do in the FPGA in order to prevent glitches. > I am using Altera Apex20K400E-1X device. Could you adjust the slew rate on all three outputs or other outputs around them to limit current spikes? You can adjust output slew rates on just a portion of the outputs from the chip to reduce such current surges. Are there other switching outputs around the glitching pin? Maybe its a power supply decoupling issue?Article: 41519
"Cyrille de Br=E9bisson" wrote: > Hello, > > Actually, I have a related question. > In our design we are using an ARM CPU. My question is: > Can we put an ARM in the virtex 2 pro? > Were can I find/buy an ARM cpu core source (or precompiled) file to pro= gram > in my FPGA? > > Regards, Cyrille AFAIK Altera devices support ARM. UtkuArticle: 41520
Peter, Are you saying that putting an ARM core into a Virtex II is not doable, or just not practical? Or are you only talking about the V2 Pro? --------- Ron Huizen BittWare Peter Alfke wrote: > > "Cyrille de Brébisson" wrote: > > > In our design we are using an ARM CPU. My question is: > > Can we put an ARM in the virtex 2 pro? > > Were can I find/buy an ARM cpu core source (or precompiled) file to program > > in my FPGA? > > > > Cyrille, > the answer to both your questions is: No. > The PowerPC in Virtex-II Pro is a "hard" implementation, packing the > microprocessor with its caches and MMU into the smallest possible silicon > area, <4 square millimeters. > What you seem to be looking for is a "soft" implementation, using the > programmable logic "fabric". > That solution is impractical for something as complex as PowerPC or even ARM. > It would take up an unreasonable portion of a large chip, and achieve mediocre > performance at best. > Xilinx offers a soft microprocessor, called MicroBlaze, especially tuned for > efficient implementation in the Virtex architecture. It is not as fast and > capable as PowerPC, but uses only ~900 slices. > "Half the size and twice the speed of NIOS" is the Xilinx slogan. Please, no > flames... > > Peter Alfke, Xilinx ApplicationsArticle: 41521
> Note also that there is a substantial difference between 5V- and 3.3V PCI. Aside from the I/O standard (which is merely an attribute on the pin), what else? The core logic is the same...the I/O timing is the same... May be my little doggie mind isn't out of the fog yet, and I haven't had enough DC yet (Diet Coke) this morning, but I wouldn't call the difference "substantial" by any stretch of the word, as far as implementation goes... > The general rule is: try to keep the voltage as low as you can. 5V has less, if > any, future... Yeah, except that almost NO PC systems, except server boards, have 3.3V slots (much less universal slots). There are millions and millions of 5V PCI compliant computers out there...that beckon to not be ignored ;-) If anyone is making a new PCI card, and their market is for more than two years, I'd suggest a universal (5V and 3.3V) card. I believe there is (or at least was) a "slight" problem with Xilinx (and probably other FPGA manufacturers parts too) and universal PCI I/O... I'm not sure if that's been solved yet...I know of all the dozen or so Xilinx based PCI cards I've designed, with everything but the latest Xilinx technology, it required two different bit streams... Again, may be my LDM isn't quite engaged yet... AustinArticle: 41522
> > This is more of a signal processing problem which I am implementing on FPGA > (Spartan II 200k). I have two 40 tap FIR filters for a complex signal. The > imaginary filter is a normal low pass filter which has been convolved with a > hilbert transform. The real filter is just a normal low pass filter. > > My question is this: I want to add a dc blocker into the real filter to > attempt to get my passbands in the imaginary and real filters the same. The > imaginary filter has one automatically due to the nature of the hilbert > transform, which makes the roll-off to DC very large. As the filters were > designed using a hamming window, my first attempt was to subtract a 40 unit > hamming window from the real coefficients such that the DC gain of the > coefficients was 0. This is effectively a DC block. However, due to the > nature of the infinite negative spike I have put in the pass band, the > roll-off to DC is not as large as the imaginary filter => pass bands do not > match. > > Does anyone have any other ideas on how to implement a DC block and still > have the same roll-off to DC as that in a hilbert transform. It seems this > won't be possible, since the "negative spike" in a hilbert transform is > finite, but the DC block is infinite. > Try to use the DC suppressor using the allpass filter. It has rather accurate phase characteristic, small group delay, and 100% DC suppression. Anatoli Sergyienko.Article: 41523
Peter is right, but.... The pre-drivers do generate a small amount of ground bounce. We have recommended that the same SSO entry for LVTTL 2 mA FAST be used for maximum number of LVDS pairs (one pair = one single LVTTL 2mA FAST IOB). Now there may not be more than 40 LVDS pairs per power/ground pin pair (for ff packages per the table for 80 IOBs) in a bank, but the generation of a bounce is real, and bypassing can not be ignored. Austin Peter Alfke wrote: > There are no limitations. > LVDS is differential standard, therefore its outputs do not generate ground bounce. > > Peter Alfke > ================================== > Ken wrote: > > > Dear all, > > > > I want to ask if there is any limitation or restriction on using the LVDS I/O on Virtex II FPGA? For example, the maximum number of LVDS I/O used at the same time? > > > > I can find similar information for the signle ended I/O from the User Guide but not for LVDS. > > > > Anyone has idea about it? Or know how to search such information? Thanks in advance. > > > > Regards, > > KennethArticle: 41524
Hi all, I am trying to find best general purpose data (text, audio, video and other types) compression algorithm suitable for FPGA implementation. On doing some research LZW compression and variations of LZ (LZ-77, LZS etc) compression seems to be a good fit. Can someone point me to other hardware based loss less data compression algorithms? Did anyone implement data compressors in FPGAs? Any pointers/references would be greatly appreciated. Thanks
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