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
On 27 Jul 2004 21:38:07 -0700, rajarsheeb@yahoo.com (raj) wrote:
>Thanks Rick for your inputs.
>Can you suggest some pointers regarding these?
>--raj
Have a look at a similar reqest and my response at:
http://www.fpga-faq.com/archives/55100.html#55101
There is a wealth of detailed info available at www.uspto.gov
for example patent 4,870,302 would be a good place to start.
start here: http://patft.uspto.gov/netahtml/search-bool.html
Others that might interest you include:
5631577
5598424
5742531
5995988
Philip Freidin
===================
Philip Freidin
philip.freidin@fpga-faq.com
Host for WWW.FPGA-FAQ.COM
Article: 71701Drew wrote: > Hello Guys, > > Have anybody tried to make On-Chip Oscillator on Altera EPLD/CPLD? I > am using Altera Max family parts. I was wondering we can program it > using VHDL? It is possible to make ring oscillators in CPLD, using a series of inverters. These will have wide process/vcc/temp variations, and should ideally be started with a NAND + Reset structures, to avoid possible stable harmonic cases. > Another question I have is, How do I reduce the Rise Time > of clock output from CPLD? I need rise time of < 2ns. I need external > circuitry but not sure what? Most CPLDs have a choice of OP Slew rates, with slow bein used to reduce the bounce and RFI effects. In the FAST mode, actual speed is largely a function of load capacitance. What is it that requires tr < 2ns ? -jgArticle: 71702
"rickman" <spamgoeshere4@yahoo.com> wrote in message news:41074120.65200AB6@yahoo.com... > After reformatting the code to make it more readable, I see that C is > declared as a vector 15 downto 0, but you never assign a value (or use > the result) of element 0. My guess is that the Altera tool was giving > you a warning, and then ignoring element C(0). The Xilinx tool was just > ignoring element C(0) without a warning. I don't think any synthesis > tool would consider this an error unless you have it configured for > that. This type of warning can be useful. In a recent design parts of an interim scaling process were being optimised out. Checking the warnings told me this and I was able to add a 'noreduce' synthesis attribute to stop it. Nial ------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone Based 'Easy PCI' proto board www.nialstewartdevelopments.co.ukArticle: 71703
Hi, I have the following problem: The Altera Cyclone device I am using does have two PLLs. Because of the fact that I am using only one PLL the compiler seems to use PLL1 on bank 1 of the device. But I need to route the external clock output of the PLL to bank 3 of the device. For that purpose I need PLL2 at bank 3 to be used. How can I tell the compiler not to use PLL1 (bank 1) but PLL2 (bank 3) ? Is there some option? I would be very thankful for your help. Besr regards André V.Article: 71704
Hello, What is the differences between FPGA and CPLD? What basis on which i should select. whether to go for cpld or fpga? waiting for reply with regards praveenArticle: 71705
Yup, But I was trying to deal with the original generator! But you are absolutely correct! Nice to remember if you suspect someone has an unfair coin...... Best to test the original random number generator (as close to the core of its function). Then one can add correction for 1/0 density, as you suggest. That does not solve for frequency effects, however. The NIST suite of tests, or Diehard tests are best applied to the core generator, so you can see its problems. Then there are known and accepted techniques to use a biased generator, or even a RNG with frequency problems to create a better TRNG. Austin Nicholas Weaver wrote: > In article <ce6dhn$r892@cliff.xsj.xilinx.com>, > Austin Lesea <austin@xilinx.com> wrote: > >>Symon, >> >>Your method is greatly flawed. In addition to being very slow, it is >>subject to the imbalance of the weight of the device. You would first >>have to add weight or trim weight to make sure the toss was fair. > > > Nah, a biased coin is perfectly fine: > > Flip twice: > HH -> try again > HT -> Heads > TH -> Tails > TT -> try again.Article: 71706
Rick, I know you are referring to FPGA_Editor. FPGA_Editor is a software view of the part function, and really has very little to do with the hardware.... Many make the mistake of assuming that the hardware looks just like the editor view (internally here at Xilinx those not in IC design), and find out later that it is a fantasy perpetrated by the software group to represent the actual functionality at a level that is easy to deal with, and understand. Austin rickman wrote: > I'm not sure what you mean by pointers. If you mean references, then I > could recommend the data sheets. But most of what you are asking about > is not needed to use the chips, so it is not talked about a lot. The > readback operation is discussed in app notes mainly. Check the Xilinx > and Altera web sites for app notes on your topic. Also, if you can get > your hands on a paid copy of the Xilinx software, they have a chip level > editor that shows a pretty accurate layout of the chip. But even this > will not really show you details of the config memory, it is just > assumed to be there and work invisibly. > > > raj wrote: > >>Thanks Rick for your inputs. >>Can you suggest some pointers regarding these? >>--raj >> >>rickman <spamgoeshere4@yahoo.com> wrote in message news:<410660E4.D29D86B6@yahoo.com>... >> >>>raj wrote: >>> >>>>Hello everybody, >>>> >>>>I am not new to the world of FPGAs but have not found enough >>>>literature regarding the SRAMs used for configuration. >>>>I need some inputs, help or pointers(papers, articles) from the FPGA >>>>community >>>>regarding these. There are very few literature relating to this(May be >>>>I am not looking in the right places). >>>> >>>>1. Are these SRAM cells arranged in a big nxn array like normal SRAM >>>>memory, or they are in small chunks of memories distributed all over >>>>the FPGA layout. >>> >>>Physically they are scattered all over the chip. Each bit of memory >>>controls a single transistor or mux input in the chip. The (pass) >>>transistors are used to control routing or are used in the LUT ram mux. >>>The muxes are used inside the logic elements to connect different inputs >>>and outputs to provide the exact configuration of logic and FFs that you >>>need. >>> >>> >>>>2.Are they physically placed adjacent to their corresponding >>>>CLB/Switch >>>> boxes. >>> >>>Yes, or even integrated. >>> >>> >>>>3. As interconnects are fixed after configuration i guess they should >>>>always be read only mode, hence should be different from LUTs SRAM >>>>cells. >>> >>>In reality they don't typically distinguish between routing and LUT >>>config memory. Both can be read back. This is useful for high >>>reliability systems where the device is read back to verify the >>>configuration has not changed due to electrical noise and/or radiation. > >Article: 71707
"praveen" <praveenkumar1979@rediffmail.com> wrote in message news:ff8a3afb.0407280557.36cb274f@posting.google.com... > Hello, > What is the differences between FPGA and CPLD? > > What basis on which i should select. whether to go for cpld or fpga? It's getting very blurred. Altera's new CPLD, the MAX II, is really an FPGA, apparently. LeonArticle: 71708
On Wed, 28 Jul 2004 06:57:51 -0700, praveen wrote: > Hello, > What is the differences between FPGA and CPLD? > > What basis on which i should select. whether to go for cpld or fpga? > > waiting for reply > with regards > praveen Is this a serious question? The internal architectures are very different, go download the architecture documents from the Xilinx site. From an application standpoint FPGAs are much much bigger than CPLDs. CPLDs are used for very simple glue logic applications, they are cheap and nonvolatile. FPGAs can implement very complex systems, but they are more expensive on a per package basis although they are much cheaper on a per gate basis. FPGAs require some support logic to initialize them, either a serial prom or an interface to a CPU (frequently implemented with a CPLD).Article: 71709
Shahabuddin, I ran this code through ISE/WebPack 6.2.03i (the current version), and I see the following warning issued during HDL Synthesis: WARNING:Xst:1780 - Signal <C<0>> is never used or assigned. Any unused or unconnected signal should trigger this warning in XST. thanks, david. Shahab wrote: > Hi.. > > I have one question regarding xilinx ise webpack. > > Why it doesn’t give any error of type missing source code . bcoz I tried > to run some codes on xilinx ise webpack and then on altera maxpllus II. > > On altera I was continuously getting messges like missing source code > "C0" while the same code was running fine on xilinx tool. > > the code is : > > library ieee; > use ieee.std_logic_1164.all; > > entity fib is > port (Clock,Clear: in std_ulogic; > Load: in std_ulogic; > Data_in: in std_ulogic_vector(15 downto 0); > S: out std_ulogic_vector(15 downto 0)); > end entity fib; > > architecture behavior of fib is > signal Restart,Cout: std_ulogic; > signal Stmp: std_ulogic_vector(15 downto 0); > signal X, Y: std_ulogic_vector(15 downto 0); > signal C : std_ulogic_vector (15 downto 0 ); > signal Zero: std_ulogic; > signal CarryIn, CarryOut: std_ulogic_vector(15 downto 0); > > begin > P1: process(Clock) > begin > if rising_edge(Clock) then > Restart <= Cout; end if; end process P1; > > Stmp <= X xor y xor CarryIn; Zero <= '1' when Stmp = "0000000000000000" > else '0'; > > CarryIn <= C(15 downto 1) & '0'; CarryOut <= (Y and X) or ((Y or X) and > CarryIn); C(15 downto 1) <= CarryOut(14 downto 0); Cout <= CarryOut(15); > > P2: process(Clock,Clear,Restart) > begin > if Clear = '1' or Restart = '1' then > X <= "0000000000000000"; Y <= "0000000000000000"; elsif > rising_edge(Clock) then if Load = '1' then X <= Data_in; elsif Zero = > '1' then X <= "0000000000000001"; else X <= Y; end if; Y <= Stmp; end > if; end process P2; > > S <= Stmp; end behavior; > > I would like to know what is the addition in xilinx ise which altera > maxplus II doesn’t have? > > Waiting for your reply. > > Shahabuddin InamdarArticle: 71710
Hi Seb Avnet doesn't use EDK as far as I know and they only gave us the bitmap of a PCIX implementation to show that the card works. I will ask them again about whether they have done EDK implementation since we bought the board. Thanks again. Jackson <seb> wrote in message news:ee878f6.4@webx.sUN8CHnE... It looks good. Try to get a PCI design example from Avnet to underline differencesArticle: 71711
Hi Erik Thanks so much for your input and offer. I am working for a research group at Cal Poly and we have very limited funds. It is a learning experience for us to be able use PCI with our intelligent NIC. However, due to our license agreement with Xilinx, we cannot get any technical support to help us pin point what is wrong with our PCI/OPB core implementation. I'd also like to try implementing the OPB/PCI wrapper to the Xilinx Logicore to get a better understanding of the core. I'd like to know if you're willing to share your OPB/PCI interface wrapper implementation experience. Thanks for your help Jackson FYI - our project is on the web at http://netprl.calpoly.edu "Erik Widding" <widding@birger.com> wrote in message news:afe40eec.0407271638.28365ac6@posting.google.com... > "Jackson Pang" <jacpang@cisco.com> wrote in message news:<1089908158.304115@sj-nntpcache-3>... > > Hello > > > > I'd like to know if anybody had any success in using Xilinx OPB/PCI bridge > > core using EDK. I set up the project and configured all the core parameters > > correctly. I also double checked the constraint file for pin assignments for > > the PCI finger. The compile and programming process goes well without any > > error, but I cannot even get my host PC to recognize my development board > > with the PCI bitmap. I am using Avnet's Virtex II PCI Development Board. > > Thanks for your input in advance. > > Jackson, > > From your other email I noticed that you are using v1_00_b of the > opb pci. It was our experience with this version of the core that > the PCI target read transactions will hang the PCI bus. This bug > was reported Nov 2003. I did a very cursory search of the answers > database, and did not see an entry on the topic. > > IIRC, config cycles worked okay on the core, so this is not your > current problem. I would recomend that you use a more recent > revision of the core than v1_00_b. I would assume that this bug is > fixed by now, but you might want to ask. > > As we could not wait for the bugs to be fixed, we developed a PCI > to PLB, and PCI to OPB bridge, with DMA (pci master) support on > the PLB side. This core supports bursting on all but the OPB buses > at present. We can make this available on a commercial basis. It > is wrapped around the Xilinx PCI logicore, which I should note is > one of the best documented, most flexible, pieces of IP we have > ever used. > > > Regards, > Erik Widding. > > --- > Birger Engineering, Inc. -------------------------------- 617.695.9233 > 100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.comArticle: 71712
Austin Lesea wrote: > > Rick, > > I know you are referring to FPGA_Editor. > > FPGA_Editor is a software view of the part function, and really has very > little to do with the hardware.... > > Many make the mistake of assuming that the hardware looks just like the > editor view (internally here at Xilinx those not in IC design), and find > out later that it is a fantasy perpetrated by the software group to > represent the actual functionality at a level that is easy to deal with, > and understand. I haven't used the tool in a few years, but if it is not close to the hardware, then it is way more complex looking than it needs to be. I have had to do a few hand routes and it is a real PITA to try to understand anything about how the routing works by looking at the graphical view. I am sure a more schematic method of showing the interconnects would been more useful and perhaps easier to develop and maintain. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71713
Jackson, Support for the Universities is provided by: http://www.xilinx.com/univ/ And not through the regular Xilinx hotline system. http://xup.msu.edu/ Michigan State University is tasked with being the "University Hotline" for our hundreds of thousands of students world wide. This allows the commercial hotline to provide the best possible solutions to our 'paying customers', and also allows students to work directly with their peers who have been trained by Xilinx to answer their questions. I hope no one is confused enough (by your email domain)to think that Xilinx has a license that prevents the support of a product! Austin Jackson Pang wrote: > Hi Erik > > Thanks so much for your input and offer. I am working for a research group > at Cal Poly and we have very limited funds. It is a learning experience for > us to be able use PCI with our intelligent NIC. However, due to our license > agreement with Xilinx, we cannot get any technical support to help us pin > point what is wrong with our PCI/OPB core implementation. I'd also like to > try implementing the OPB/PCI wrapper to the Xilinx Logicore to get a better > understanding of the core. I'd like to know if you're willing to share your > OPB/PCI interface wrapper implementation experience. > > Thanks for your help > Jackson > > FYI - our project is on the web at http://netprl.calpoly.edu > > > > > "Erik Widding" <widding@birger.com> wrote in message > news:afe40eec.0407271638.28365ac6@posting.google.com... > >>"Jackson Pang" <jacpang@cisco.com> wrote in message > > news:<1089908158.304115@sj-nntpcache-3>... > >>>Hello >>> >>>I'd like to know if anybody had any success in using Xilinx OPB/PCI > > bridge > >>>core using EDK. I set up the project and configured all the core > > parameters > >>>correctly. I also double checked the constraint file for pin assignments > > for > >>>the PCI finger. The compile and programming process goes well without > > any > >>>error, but I cannot even get my host PC to recognize my development > > board > >>>with the PCI bitmap. I am using Avnet's Virtex II PCI Development Board. >>>Thanks for your input in advance. >> >>Jackson, >> >>From your other email I noticed that you are using v1_00_b of the >>opb pci. It was our experience with this version of the core that >>the PCI target read transactions will hang the PCI bus. This bug >>was reported Nov 2003. I did a very cursory search of the answers >>database, and did not see an entry on the topic. >> >>IIRC, config cycles worked okay on the core, so this is not your >>current problem. I would recomend that you use a more recent >>revision of the core than v1_00_b. I would assume that this bug is >>fixed by now, but you might want to ask. >> >>As we could not wait for the bugs to be fixed, we developed a PCI >>to PLB, and PCI to OPB bridge, with DMA (pci master) support on >>the PLB side. This core supports bursting on all but the OPB buses >>at present. We can make this available on a commercial basis. It >>is wrapped around the Xilinx PCI logicore, which I should note is >>one of the best documented, most flexible, pieces of IP we have >>ever used. >> >> >>Regards, >>Erik Widding. >> >>--- >>Birger Engineering, Inc. -------------------------------- 617.695.9233 >>100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com > > >Article: 71714
praveen wrote: > Hello, > What is the differences between FPGA and CPLD? > > What basis on which i should select. whether to go for cpld or fpga? The common understanding is that CPLDs are EEPOM or Flash based and have to be programmed once. They have up to say 512 Flipflops. FPGAs on the other hand are RAM based, meaning they have to be programmed at every powerup. This usually happens with a small external Flash, a CPU or whatever. The smallest FPFA is far bigger than the biggest CPLD. Hope that helps. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 71715
Rick, And thus the battle is joined.....again Yes, well, we have only been at this for twenty years now, and we are still refining the whole process. Routing by hand is a pretty useful thing to know (when all else fails, or there is something that just has to be done a certain way), but it is also something that leads to the longest time to market, so it naturally does not get much attention (why should it, when it delays the sale of a part?). One issue in making FPGA_Editor look like the hardware schematic, is that we have to make the hardware view match the software view. I know, radical. Hardware vs. Software..... Austin rickman wrote: > Austin Lesea wrote: > >>Rick, >> >>I know you are referring to FPGA_Editor. >> >>FPGA_Editor is a software view of the part function, and really has very >>little to do with the hardware.... >> >>Many make the mistake of assuming that the hardware looks just like the >>editor view (internally here at Xilinx those not in IC design), and find >>out later that it is a fantasy perpetrated by the software group to >>represent the actual functionality at a level that is easy to deal with, >>and understand. > > > I haven't used the tool in a few years, but if it is not close to the > hardware, then it is way more complex looking than it needs to be. I > have had to do a few hand routes and it is a real PITA to try to > understand anything about how the routing works by looking at the > graphical view. I am sure a more schematic method of showing the > interconnects would been more useful and perhaps easier to develop and > maintain. >Article: 71716
Hi Allan, hi Austin,
thank you for you reply, but it won't help.
Of course, at MGT's speeds everything becomes just esoteric.
But we know this, we've designed serial gigabit board for several
years. We are familiar to single ended and differential impedance
and know how to lay out a board for these signals.
We've carried out _true_ TDR measurement with Tek CSA8000
series scope which is able to send a positive and a negative pulse
exactly at the same time. Both the board and the MGT receiver
don't seem to be the issue, as I wrote earlier (see below).
When I cut off the signal path by lifting the AC-coupling capacitors
100mil before the MGT receiver and short the differential pair by
a simple 100 Ohms termination resistor, then I get wonderful waveform
and eye diagram!!! So it is proven, that I do not have a problem
along the traces, but together with MGT receiver.
We use such links in the opposite direction as well, with the MGT as
the transmitter and a competitor's chip as the receiver. All other details
are absolutely identical - same trace geometry, same connectors, same
distances - just different direction. Those links work _excellent_ and the
eyes look as pretty as in a schoolbook!!! So what do you thing?
Do I have a problem with my pcb???
We have contacted the local FAE and he had no idea except the noise
at the MGT supply voltage. We were advised to measure at the
regulator and found app. 70mVpp noise. But even a lower noise supply
with 30mV hardly provided signal improvement.
After 15" FR4 and two special high speed connector (AMP HM-Zd)
we get an 65mV eye opening at the MGT receiver package pin, but an
650mV overall signal swing! App. 90% is degraded by reflections!
I could double the transmitter voltage swing, but I wonder, if this is the
right approch...
I'm out of ideas now.
Thank you for your assistance!
Regards.
Michael
Allan Herriman wrote:
>On Fri, 23 Jul 2004 08:03:05 -0700, Austin Lesea <austin@xilinx.com>
>wrote:
>
>
>
>>Michael,
>>
>>At the speeds of the MGT signals, just about anything can be a 'bump in
>>the road', and cause reflections.
>>
>>No, the termination in the receiver is not perfect, (nothing is
>>perfect), but it is just fine regardless. Thousands of customers have
>>pcb's working at 3.125 Gbs error free, so it is more likely that you
>>have a pcb issue in your board.
>>
>>I suggest you immediately contact your local FAE, and arrange to go
>>visit one of our RocketLabs locations, where we have all of the
>>equipment to troubleshoot just such an issue, and the FAEs associated
>>with the RocketLab are all trained and familiar with the equipment, and
>>how to address the issues.
>>
>>One of the most common mistakes made in measuring the input impedance,
>>or return loss of the 100 ohm differential receiver, is that they
>>measure it single ended (50 ohm) and fail to take into account that a
>>differential return loss measurement is not a trivial or simple thing to
>> characterize accurately. For example, two single ended 50 ohm traces
>>are NOT 100 ohms differential (they are less if they are routed together
>>as they should be to be differential). Bad mismatch right there!
>>
>>This goes for TDR as well. Unless it is a true differential TDR
>>measurement, you are not measuring what you need to measure (eg the Tek
>>CSA8000 is the only true differential TDR scope that I know of, although
>>I think Agilent now has one as well -- check! does it send two impulses
>>(or steps) at the same time of opposite voltages? If not it isn't
>>differential).
>>
>>
>
>I've used an Agilent 54754A dual 18.4GHz TDR plugin in an 86100A scope
>for testing 10Gbps connections. I *think* it does a true differential
>measurement. [ I don't have the documentation handy. ]
>
>
>
>>As well, the time resolution fo the TDR may be much faster than the rise
>>time of the MGT signal, and may be showing issues that do not affect the
>>MGT operation (ie a mis-match at 20 GHz is not an issue, as the signal
>>has no energy at 20 GHz).
>>
>>
>
>Yes, but better time resolution means better spatial resolution,
>allowing you to work out what went wrong with your board design.
>
>(I found this out the hard way.)
>
>Regards,
>Allan.
>
>
> > Hi anyone out there,
> >
> > we have designed a board with XILINX Virtex II Pro using the
> > RocketIO / MGT serial high speed transceivers.
> > Recently we experienced a problem with bit error rate (BER) and
> > measured the signal quality of the MGT serial links with a 20Gsample
> > scope and 5GHz differential probe. We found a very poor signal
> > waveform and got an almost closed eye diagram.
> > We analyzed this phenomenon and now we assume, that the signal
> > degradation is caused by high reflections on the line. The overshoot
> > and undershoot amounts to 50% of the singal swing. It seemed, that
> > the MGT receiver's input termination does not work properly.
> > Then we tried a TDR ("time domain reflectometer") measurement
> > to check the impedance characteristics of our board even into
> > the MGT's termination. The board traces are fine. Some impedance
> > mismatches are to be seen at vias, AC-coupling capacitors and the
> > Virtex II Pro package. But we think, these are not too bad, the
> > mismatch is in the range of 20%.
> >
> > Does anyone have experience with Virtex II Pro RocketIO?
> > Did anyone measure signal quality or eye diagrams on such a link?
> > May the impedance mismatches cause the high ringing we found?
> > Can anyone imagine the reason for the reflections though the signal
> > path's impedance seems to be not so bad?
> >
> > At the moment I don't have a clue.
> > Thank you for any hint!
> >
> > Michael
> >
Article: 71717sorry for the possible confusion. my messages on this forum does not reflect my current employer's opinion. However, I do admit that the quality of support on XUP is very poor. But then again, we get what we pay for. thanks for clearing things up Austin Jackson Pang "Austin Lesea" <austin@xilinx.com> wrote in message news:4107D527.7050801@xilinx.com... > Jackson, > > Support for the Universities is provided by: > > http://www.xilinx.com/univ/ > > And not through the regular Xilinx hotline system. > > http://xup.msu.edu/ > > Michigan State University is tasked with being the "University Hotline" > for our hundreds of thousands of students world wide. This allows the > commercial hotline to provide the best possible solutions to our 'paying > customers', and also allows students to work directly with their peers > who have been trained by Xilinx to answer their questions. > > I hope no one is confused enough (by your email domain)to think that > Xilinx has a license that prevents the support of a product! > > Austin > > Jackson Pang wrote: > > > Hi Erik > > > > Thanks so much for your input and offer. I am working for a research group > > at Cal Poly and we have very limited funds. It is a learning experience for > > us to be able use PCI with our intelligent NIC. However, due to our license > > agreement with Xilinx, we cannot get any technical support to help us pin > > point what is wrong with our PCI/OPB core implementation. I'd also like to > > try implementing the OPB/PCI wrapper to the Xilinx Logicore to get a better > > understanding of the core. I'd like to know if you're willing to share your > > OPB/PCI interface wrapper implementation experience. > > > > Thanks for your help > > Jackson > > > > FYI - our project is on the web at http://netprl.calpoly.edu > > > > > > > > > > "Erik Widding" <widding@birger.com> wrote in message > > news:afe40eec.0407271638.28365ac6@posting.google.com... > > > >>"Jackson Pang" <jacpang@cisco.com> wrote in message > > > > news:<1089908158.304115@sj-nntpcache-3>... > > > >>>Hello > >>> > >>>I'd like to know if anybody had any success in using Xilinx OPB/PCI > > > > bridge > > > >>>core using EDK. I set up the project and configured all the core > > > > parameters > > > >>>correctly. I also double checked the constraint file for pin assignments > > > > for > > > >>>the PCI finger. The compile and programming process goes well without > > > > any > > > >>>error, but I cannot even get my host PC to recognize my development > > > > board > > > >>>with the PCI bitmap. I am using Avnet's Virtex II PCI Development Board. > >>>Thanks for your input in advance. > >> > >>Jackson, > >> > >>From your other email I noticed that you are using v1_00_b of the > >>opb pci. It was our experience with this version of the core that > >>the PCI target read transactions will hang the PCI bus. This bug > >>was reported Nov 2003. I did a very cursory search of the answers > >>database, and did not see an entry on the topic. > >> > >>IIRC, config cycles worked okay on the core, so this is not your > >>current problem. I would recomend that you use a more recent > >>revision of the core than v1_00_b. I would assume that this bug is > >>fixed by now, but you might want to ask. > >> > >>As we could not wait for the bugs to be fixed, we developed a PCI > >>to PLB, and PCI to OPB bridge, with DMA (pci master) support on > >>the PLB side. This core supports bursting on all but the OPB buses > >>at present. We can make this available on a commercial basis. It > >>is wrapped around the Xilinx PCI logicore, which I should note is > >>one of the best documented, most flexible, pieces of IP we have > >>ever used. > >> > >> > >>Regards, > >>Erik Widding. > >> > >>--- > >>Birger Engineering, Inc. -------------------------------- 617.695.9233 > >>100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com > > > > > >Article: 71718
On Sat, 24 Jul 2004 07:11:29 +1000, Allan Herriman <allan.herriman.hates.spam@ctam.com.au.invalid> wrote: >On Fri, 23 Jul 2004 08:03:05 -0700, Austin Lesea <austin@xilinx.com> >wrote: [snip] >>This goes for TDR as well. Unless it is a true differential TDR >>measurement, you are not measuring what you need to measure (eg the Tek >>CSA8000 is the only true differential TDR scope that I know of, although >>I think Agilent now has one as well -- check! does it send two impulses >>(or steps) at the same time of opposite voltages? If not it isn't >>differential). > >I've used an Agilent 54754A dual 18.4GHz TDR plugin in an 86100A scope >for testing 10Gbps connections. I *think* it does a true differential >measurement. [ I don't have the documentation handy. ] I checked the 54754A. It claims to be a true differential tester. Regards, Allan.Article: 71719
Michael,
I apologize if I seemed to imply that you were new at this.
Series capacitors? Why? When you AC couple, now you have the impedance
bump due to the layout from the caps, and their own ESL/ESR.
Has anyone extracted the pcb layout and simulated the pcb traces using a
3D field solver? Have you looked at the impedance mismatch created by
the series caps?
Again, I strongly suggest getting to a RocektLab which is equipped to
handle this. A quick call to a disti FAE (or even a Xilinx FAE) that
has no real knowledge of your situation is not really going to get you
the help you need.
Is there a case on this? Who is the CAE?
Working with our Hotline is the best, fastest, and most effective way to
solve any issue. This forum here is probably the worst from a
time/accuracy/solution point of view for a specific customer issue. It
is very useful to ping others in the community.
Austin
Michael Mustermann wrote:
> Hi Allan, hi Austin,
>
> thank you for you reply, but it won't help.
> Of course, at MGT's speeds everything becomes just esoteric.
> But we know this, we've designed serial gigabit board for several
> years. We are familiar to single ended and differential impedance
> and know how to lay out a board for these signals.
>
> We've carried out _true_ TDR measurement with Tek CSA8000
> series scope which is able to send a positive and a negative pulse
> exactly at the same time. Both the board and the MGT receiver
> don't seem to be the issue, as I wrote earlier (see below).
>
> When I cut off the signal path by lifting the AC-coupling capacitors
> 100mil before the MGT receiver and short the differential pair by
> a simple 100 Ohms termination resistor, then I get wonderful waveform
> and eye diagram!!! So it is proven, that I do not have a problem
> along the traces, but together with MGT receiver.
>
> We use such links in the opposite direction as well, with the MGT as
> the transmitter and a competitor's chip as the receiver. All other details
> are absolutely identical - same trace geometry, same connectors, same
> distances - just different direction. Those links work _excellent_ and the
> eyes look as pretty as in a schoolbook!!! So what do you thing?
> Do I have a problem with my pcb???
>
> We have contacted the local FAE and he had no idea except the noise
> at the MGT supply voltage. We were advised to measure at the
> regulator and found app. 70mVpp noise. But even a lower noise supply
> with 30mV hardly provided signal improvement.
>
> After 15" FR4 and two special high speed connector (AMP HM-Zd)
> we get an 65mV eye opening at the MGT receiver package pin, but an
> 650mV overall signal swing! App. 90% is degraded by reflections!
> I could double the transmitter voltage swing, but I wonder, if this is the
> right approch...
>
> I'm out of ideas now.
> Thank you for your assistance!
>
> Regards.
>
> Michael
>
>
>
>
> Allan Herriman wrote:
>
>> On Fri, 23 Jul 2004 08:03:05 -0700, Austin Lesea <austin@xilinx.com>
>> wrote:
>>
>>
>>
>>> Michael,
>>>
>>> At the speeds of the MGT signals, just about anything can be a 'bump
>>> in the road', and cause reflections.
>>>
>>> No, the termination in the receiver is not perfect, (nothing is
>>> perfect), but it is just fine regardless. Thousands of customers
>>> have pcb's working at 3.125 Gbs error free, so it is more likely that
>>> you have a pcb issue in your board.
>>>
>>> I suggest you immediately contact your local FAE, and arrange to go
>>> visit one of our RocketLabs locations, where we have all of the
>>> equipment to troubleshoot just such an issue, and the FAEs associated
>>> with the RocketLab are all trained and familiar with the equipment,
>>> and how to address the issues.
>>>
>>> One of the most common mistakes made in measuring the input
>>> impedance, or return loss of the 100 ohm differential receiver, is
>>> that they measure it single ended (50 ohm) and fail to take into
>>> account that a differential return loss measurement is not a trivial
>>> or simple thing to characterize accurately. For example, two single
>>> ended 50 ohm traces are NOT 100 ohms differential (they are less if
>>> they are routed together as they should be to be differential). Bad
>>> mismatch right there!
>>>
>>> This goes for TDR as well. Unless it is a true differential TDR
>>> measurement, you are not measuring what you need to measure (eg the
>>> Tek CSA8000 is the only true differential TDR scope that I know of,
>>> although I think Agilent now has one as well -- check! does it send
>>> two impulses (or steps) at the same time of opposite voltages? If
>>> not it isn't differential).
>>>
>>
>>
>> I've used an Agilent 54754A dual 18.4GHz TDR plugin in an 86100A scope
>> for testing 10Gbps connections. I *think* it does a true differential
>> measurement. [ I don't have the documentation handy. ]
>>
>>
>>
>>> As well, the time resolution fo the TDR may be much faster than the
>>> rise time of the MGT signal, and may be showing issues that do not
>>> affect the MGT operation (ie a mis-match at 20 GHz is not an issue,
>>> as the signal has no energy at 20 GHz).
>>>
>>
>>
>> Yes, but better time resolution means better spatial resolution,
>> allowing you to work out what went wrong with your board design.
>>
>> (I found this out the hard way.)
>>
>> Regards,
>> Allan.
>>
>>
> > > Hi anyone out there,
> > >
> > > we have designed a board with XILINX Virtex II Pro using the
> > > RocketIO / MGT serial high speed transceivers.
> > > Recently we experienced a problem with bit error rate (BER) and
> > > measured the signal quality of the MGT serial links with a 20Gsample
> > > scope and 5GHz differential probe. We found a very poor signal
> > > waveform and got an almost closed eye diagram.
> > > We analyzed this phenomenon and now we assume, that the signal
> > > degradation is caused by high reflections on the line. The overshoot
> > > and undershoot amounts to 50% of the singal swing. It seemed, that
> > > the MGT receiver's input termination does not work properly.
> > > Then we tried a TDR ("time domain reflectometer") measurement
> > > to check the impedance characteristics of our board even into
> > > the MGT's termination. The board traces are fine. Some impedance
> > > mismatches are to be seen at vias, AC-coupling capacitors and the
> > > Virtex II Pro package. But we think, these are not too bad, the
> > > mismatch is in the range of 20%.
> > >
> > > Does anyone have experience with Virtex II Pro RocketIO?
> > > Did anyone measure signal quality or eye diagrams on such a link?
> > > May the impedance mismatches cause the high ringing we found?
> > > Can anyone imagine the reason for the reflections though the signal
> > > path's impedance seems to be not so bad?
> > >
> > > At the moment I don't have a clue.
> > > Thank you for any hint!
> > >
> > > Michael
> > >
Article: 71720Jackson, Poor support on XUP from MSU? Really? I would like to know of your experience. Perhaps your work is too advanced for their knowledge base? You may email me directly at austin ___ @ ___ xilinx ___ . ____ com (remove puncuation). I am sure there are other universities that would like to provide what MSU does (for the benefits they gain from us), so letting us know how well our partners perform is beneficial. If you are working with EDK, and the PPC, and the various busses, you may be doing work that is well advanced ahead of what the XUP is able to provide right now. This is useful for us to know. By donating millions of dollars to education, we do not serve ourselves by then ignoring the support (so we do not). We also can not allow the XUP patrons to use the commercial support as that would adversely impact business. A delicate balance. Austin Jackson Pang wrote: > sorry for the possible confusion. my messages on this forum does not reflect > my current employer's opinion. However, I do admit that the quality of > support on XUP is very poor. But then again, we get what we pay for. > > thanks for clearing things up Austin > > Jackson Pang > > > "Austin Lesea" <austin@xilinx.com> wrote in message > news:4107D527.7050801@xilinx.com... > >>Jackson, >> >>Support for the Universities is provided by: >> >>http://www.xilinx.com/univ/ >> >>And not through the regular Xilinx hotline system. >> >>http://xup.msu.edu/ >> >>Michigan State University is tasked with being the "University Hotline" >>for our hundreds of thousands of students world wide. This allows the >>commercial hotline to provide the best possible solutions to our 'paying >>customers', and also allows students to work directly with their peers >>who have been trained by Xilinx to answer their questions. >> >>I hope no one is confused enough (by your email domain)to think that >>Xilinx has a license that prevents the support of a product! >> >>Austin >> >>Jackson Pang wrote: >> >> >>>Hi Erik >>> >>>Thanks so much for your input and offer. I am working for a research > > group > >>>at Cal Poly and we have very limited funds. It is a learning experience > > for > >>>us to be able use PCI with our intelligent NIC. However, due to our > > license > >>>agreement with Xilinx, we cannot get any technical support to help us > > pin > >>>point what is wrong with our PCI/OPB core implementation. I'd also like > > to > >>>try implementing the OPB/PCI wrapper to the Xilinx Logicore to get a > > better > >>>understanding of the core. I'd like to know if you're willing to share > > your > >>>OPB/PCI interface wrapper implementation experience. >>> >>>Thanks for your help >>>Jackson >>> >>>FYI - our project is on the web at http://netprl.calpoly.edu >>> >>> >>> >>> >>>"Erik Widding" <widding@birger.com> wrote in message >>>news:afe40eec.0407271638.28365ac6@posting.google.com... >>> >>> >>>>"Jackson Pang" <jacpang@cisco.com> wrote in message >>> >>>news:<1089908158.304115@sj-nntpcache-3>... >>> >>> >>>>>Hello >>>>> >>>>>I'd like to know if anybody had any success in using Xilinx OPB/PCI >>> >>>bridge >>> >>> >>>>>core using EDK. I set up the project and configured all the core >>> >>>parameters >>> >>> >>>>>correctly. I also double checked the constraint file for pin > > assignments > >>>for >>> >>> >>>>>the PCI finger. The compile and programming process goes well without >>> >>>any >>> >>> >>>>>error, but I cannot even get my host PC to recognize my development >>> >>>board >>> >>> >>>>>with the PCI bitmap. I am using Avnet's Virtex II PCI Development > > Board. > >>>>>Thanks for your input in advance. >>>> >>>>Jackson, >>>> >>> >>>>From your other email I noticed that you are using v1_00_b of the >>> >>>>opb pci. It was our experience with this version of the core that >>>>the PCI target read transactions will hang the PCI bus. This bug >>>>was reported Nov 2003. I did a very cursory search of the answers >>>>database, and did not see an entry on the topic. >>>> >>>>IIRC, config cycles worked okay on the core, so this is not your >>>>current problem. I would recomend that you use a more recent >>>>revision of the core than v1_00_b. I would assume that this bug is >>>>fixed by now, but you might want to ask. >>>> >>>>As we could not wait for the bugs to be fixed, we developed a PCI >>>>to PLB, and PCI to OPB bridge, with DMA (pci master) support on >>>>the PLB side. This core supports bursting on all but the OPB buses >>>>at present. We can make this available on a commercial basis. It >>>>is wrapped around the Xilinx PCI logicore, which I should note is >>>>one of the best documented, most flexible, pieces of IP we have >>>>ever used. >>>> >>>> >>>>Regards, >>>>Erik Widding. >>>> >>>>--- >>>>Birger Engineering, Inc. -------------------------------- 617.695.9233 >>>>100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com >>> >>> >>> > >Article: 71721
praveenkumar1979@rediffmail.com (praveen) wrote in message news:<ff8a3afb.0407280557.36cb274f@posting.google.com>... > Hello, > What is the differences between FPGA and CPLD? General logics vs. Simple reg/decoder Expensive ($10 - $20) vs. Cheap ($1 - $2) Big (> 100 pins) vs. Small (> 44 pins) ...Article: 71722
Austin Lesea wrote: > > Rick, > > And thus the battle is joined.....again > > Yes, well, we have only been at this for twenty years now, and we are > still refining the whole process. Routing by hand is a pretty useful > thing to know (when all else fails, or there is something that just has > to be done a certain way), but it is also something that leads to the > longest time to market, so it naturally does not get much attention (why > should it, when it delays the sale of a part?). That rational actually makes no sense. If I could get a given product to market without hand routing, I would. I only use the chip editor when it is absolutely required. I don't need any encouragement from tools that are hard to use. The most recent example I can remember is a very short path from one pin to another for muxing a clock and sending back out of the chip. I needed a total delay below a specific number which was possible within the chip, but the tool would not use the fastest route. The pinout had been picked to optimize this, but the standard tool got in the way. So every time I routed the design, I had to tweek that one route in the chip editor regardless of the time to market impact. Besides, the time to market is fixed... my overtime is not. I'd rather spend a few extra minutes every time I do a route than fight a tool for weeks. > One issue in making FPGA_Editor look like the hardware schematic, is > that we have to make the hardware view match the software view. So how would that make it different? The software view is *very* abstract. The view in the chip editor contains lots of eccentric twists and turns in routes with little info on what can connect to what. I fail to see how that *matches* the software. > I know, radical. > > Hardware vs. Software..... This is the sort of comment that you can leave out if you are trying to communicate. I have no idea what you are trying to say, just that you are being sarcastic. -- Rick "rickman" Collins rick.collins@XYarius.com Ignore the reply address. To email me use the above address with the XY removed. Arius - A Signal Processing Solutions Company Specializing in DSP and FPGA design URL http://www.arius.com 4 King Ave 301-682-7772 Voice Frederick, MD 21701-3110 301-682-7666 FAXArticle: 71723
"Rune Christensen" <rune.christensen@adslhome.dk> wrote in message news:410769bb$0$287$edfadb0f@dread12.news.tele.dk... > Hello > > Does anyone know a cheap PC/104 FPGA module? try http://www.mesanet.com/ the above site has also nice hidden goodies as well, like ISA bus VHDL core 12 DSP core, JTAG controller - they are hidden in different downloadable archives worth to check out :) Antti http://stores.ebay.com/OpenChip-Online-ShopArticle: 71724
Rick, There is nothing I can say to you to that seems to explain anything at all, so I will stop now (trying to explain why the software and hardware differ in their view of the chip). No sarcasm whatsoever. Hand tweaking an occasional path is just what FPGA_Editor does best, so I am glad it is useful in your designs. I am surprised that you could not get the same results by using a local constraint, but then, I have already stated I am not a software expert. They do a wonderful job of addressing software bugs, however. Austin rickman wrote: > Austin Lesea wrote: > >>Rick, >> >>And thus the battle is joined.....again >> >>Yes, well, we have only been at this for twenty years now, and we are >>still refining the whole process. Routing by hand is a pretty useful >>thing to know (when all else fails, or there is something that just has >>to be done a certain way), but it is also something that leads to the >>longest time to market, so it naturally does not get much attention (why >>should it, when it delays the sale of a part?). > > > That rational actually makes no sense. If I could get a given product > to market without hand routing, I would. I only use the chip editor > when it is absolutely required. I don't need any encouragement from > tools that are hard to use. > > The most recent example I can remember is a very short path from one pin > to another for muxing a clock and sending back out of the chip. I > needed a total delay below a specific number which was possible within > the chip, but the tool would not use the fastest route. The pinout had > been picked to optimize this, but the standard tool got in the way. So > every time I routed the design, I had to tweek that one route in the > chip editor regardless of the time to market impact. Besides, the time > to market is fixed... my overtime is not. I'd rather spend a few extra > minutes every time I do a route than fight a tool for weeks. > > > >>One issue in making FPGA_Editor look like the hardware schematic, is >>that we have to make the hardware view match the software view. > > > So how would that make it different? The software view is *very* > abstract. The view in the chip editor contains lots of eccentric twists > and turns in routes with little info on what can connect to what. I > fail to see how that *matches* the software. > > >>I know, radical. >> >>Hardware vs. Software..... > > > This is the sort of comment that you can leave out if you are trying to > communicate. I have no idea what you are trying to say, just that you > are being sarcastic. >
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