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
Hello, I'm about to purchase a new computer and I wanted to get some opinions on what I should get. I mostly work with Quartus II on my job and wanted to know what would be a good system to run the software. I've been hearing more about dual-core and quad core systems which do you think gives better performance running Quartus? Last, should I get 4GB of memory or 2GB? I usually program the larger fpga devices and compilation time takes about 30 minutes and my simulations take about an hour. My current system is a dual processor with 2GB of memory. If anyone can comment on what would be the best computer system I'd greatly appreciate it. thanks, joeArticle: 119676
Symon, Yes, I know what the author of the post is trying to do. Yes, Hyperlynx has built in models for a number of ribbon cables. Without running the simulator, it is a complete waste of time to suggest anything as a "solution" to this question. Now that I have spent three times longer than I would have solving it with the simulator, it appears that we have paid for the simulator, once again. GET IT? (I know you do, Symon). AustinArticle: 119677
"Symon" <symon_brewer@hotmail.com> wrote in message news:f349ou$ppq$1@aioe.org... > "austin" <austin@xilinx.com> wrote in message > news:f34740$6dj2@cnn.xilinx.com... >> >> One comment: matching the transmitter impedance is a good idea, as a >> perfect match at the receiver is impossible (perfect may happen in >> textbooks, but not in real life). >> >> Austin >> > It is possible to match even Xilinx's hideous 10pF receiver pins. Here's > an example from Xilinx's own consultant's website:- > http://sigcon.com/Pubs/edn/ConstantRTermination.htm > > HTH, Syms. > Here's some more links:- http://sigcon.com/Pubs/edn/TerminatorOne.htm http://sigcon.com/Pubs/edn/TerminatorTwo.htm http://sigcon.com/Pubs/edn/TerminatorThree.htm HTH, Syms.Article: 119678
Symon, Wrong solution. Using the _DT internal differential termination, the driver will see 100 ohms in parallel with 5 pF (10pF in series with 10 pF). If you SIMULATE this load, you will find that since the capacitance is directly across the 100 ohms, the receive signal is just fine. Any reflections are absorbed by the 100 ohm driver (gee? I wonder what genius thought of doing this?). The rise times from the driver are moderate, and adequate, so mis-matches don't jump up and make life difficult, and cross talk is reduced. Some folks have lightning fast drivers, which cross talk like crazy, and even their "lower" input C looks awful, as a signal with 2X the rise makes even 3pF look really bad. "The system is the solution." Driver, termination, line, receiver, all have to be considered. I know, you, personally have issue with the solution, but, face it, Virtex family has been an astounding success: and TO THIS DAY, we are the only ones with 65nm product, shipping (at all) production parts. ONE YEAR as of May 5th.... Think of all those sockets we are being designed into. All of those LVDS interfaces working. Literally tens of millions of them. Do we have room to improve? Of course. But, any improvement is weighted against its benefits. Make the input less capacitive has no benefit (other than you would immediately post "see! I told you!" and I would not have to reply to this issue anymore). What might be a better item to work on, rather than spend time on something that "ain't broke?" Oh, did I mention how ecstatic we are that we have a one year lead on 65nm? AustinArticle: 119679
"Symon" <symon_brewer@hotmail.com> wrote in message news:f349ou$ppq$1@aioe.org... >> > It is possible to match even Xilinx's hideous 10pF receiver pins. Here's > an example from Xilinx's own consultant's website:- > http://sigcon.com/Pubs/edn/ConstantRTermination.htm > > HTH, Syms. This kind of approach certainly isn't obvious. The reflections will *certainly* be much better. Heck, the line can be probed and a good signal seen just about anywhere along the transmission line (assuming the probe doesn't introduce problems). What should be noted is that - while there are no reflections and the end of the transmission line will see a superb voltage slow thanks to the R-only termination, this clean transition sees a series Zo impedance between it and the capacitor. For a standard parallel Zo termination to a Zo characteristic impedance transmission line, the effective source is half the drive voltage through a Zo/2 impedance into the capacitor. If there is no capacitance, the transition is gorgeous at the receiver. For the termination scheme suggested, the point where the transition line sees the resistance is the same half-voltage swing. Trouble here is that the equivalent series impedance to the capacitor is no longer fed by a half voltage with Zo/2 equivalent series impedance, but now a half voltage with a Zo series impedance. If it's important to not have reflections, the R-only equivalent termination is superb. If it's important to have the high slew rate, the standard termination with the associated pin capacitance is the way to go because the reflection *will* be absorbed by the transmitter's impedance if it's properly matched. Signal Integrity *at the pin* is what's important and where a monte-carlo SI analysis will show which approach provides a cleaner interface in the end. For this implementation where the speed is low, the extra 250 ps of RC time constant (it's C/2 for a differential signal) will probably provide excellent results. - John_HArticle: 119680
"austin" <austin@xilinx.com> wrote in message news:f34blr$62p3@cnn.xilinx.com... <snip> > Without running the simulator, it is a complete waste of time to suggest > anything as a "solution" to this question. <snip> No need to get <snip>py. There were many successful high speed designs before SI got the usable, affordable tools available today. Without a fundamental understanding of what DOES affect signal fidelity, we doom our engineering future to shotgun hacks at "trying" to get the signals to perform well. Since we have the SI tools available now in a way they weren't available a decade ago, quick analysis of alternatives can be pursued. To suggest that fundamental knowledge be tossed out since there's a tool available is the short-sided view that often comes with the frustration of trying to communicate your point. Please don't ask engineers to avoid learning the basics of delivering good signal integrity just because the tools are available to avoid doing the heavy mental lifting. When's the last time you gave someone $22 for a $17 charge expecting to get a $5 bill back and they stare at you like you're nuts. "But it's only $17." The crutch of calculators and cash registers have crippled much of a generation. Lets keep engineering steeped in fundamentals and use the tools as they're meant: as tools. - John_HArticle: 119681
"austin" <austin@xilinx.com> wrote in message news:f34blr$62p3@cnn.xilinx.com... > Symon, > > Yes, I know what the author of the post is trying to do. > > Yes, Hyperlynx has built in models for a number of ribbon cables. > > Without running the simulator, it is a complete waste of time to suggest > anything as a "solution" to this question. > > Now that I have spent three times longer than I would have solving it with > the simulator, it appears that we have paid for the simulator, once again. > > GET IT? (I know you do, Symon). > > Austin Hi Austin, I do so enjoy our little chats! I also know that you're a big fan of simulation, and I totally agree it's a great tool. (Oh, and BTW, thanks for the pointer, I didn't realise that some ribbon cables were included in Hyperlynx, that's cool! Although, I fear the OP's cable is not included.) My only comment is that some people are actually interested in the mechanisms at work. I'd say it's important to learn that first, and then use the simulator. All the best, Syms.Article: 119682
<jjlindula@hotmail.com> wrote in message news:1180019992.519179.25720@q66g2000hsg.googlegroups.com... > Hello, I'm about to purchase a new computer and I wanted to get some > opinions on what I should get. I mostly work with Quartus II on my job > and wanted to know what would be a good system to run the software. > I've been hearing more about dual-core and quad core systems which do > you think gives better performance running Quartus? Last, should I get > 4GB of memory or 2GB? I usually program the larger fpga devices and > compilation time takes about 30 minutes and my simulations take about > an hour. My current system is a dual processor with 2GB of memory. If > anyone can comment on what would be the best computer system I'd > greatly appreciate it. > > thanks, > joe Multi-threaded flows that get strong performance benefits are probably years away. If you won't replace your PC for 5 years, the quad core might be good. For the next 2 years, the dual core should be *plenty* but be sure to get more L2 cache. For the larger FPGAs, larger system memory is suggested. If you were doing Cyclone and Spartan3, I'd suggest the lower memory is fine. With the higher end parts, more memory will be properly utilized. If you want to run simulations while you're compiling your design and write up the documentation while you wait for those processes to complete, get the quad core. If you just want to do one high-power task and one not so demanding activity, I would expect no improvement of quad-core over dual-core in the next 2 years. If the quad core allows less L2 cache to the main thread than the dual-core, your performance will actually be worse in the near term. Look into the L2 management as a critical factor in chosing your tool and expect 85-100% of your logical and physical synthesis to be on one core for the year or two directly ahead. These are my opinions based largely on hear-say and system understanding. I just have a single core at the moment and am trying to make my next work PC (the cheap one) to have as much L2 as is reasonable. The next home system will be the capable machine. It's sad how that goes. - John_HArticle: 119683
"austin" <austin@xilinx.com> wrote in message news:f34cle$6381@cnn.xilinx.com... > Symon, > > Wrong solution. > > Using the _DT internal differential termination, the driver will see 100 > ohms in parallel with 5 pF (10pF in series with 10 pF). > > If you SIMULATE this load, you will find that since the capacitance is > directly across the 100 ohms, the receive signal is just fine. > > Any reflections are absorbed by the 100 ohm driver (gee? I wonder what > genius thought of doing this?). > We've been here before. I'll explain again. Remember that the OP is driving the line from a S3. So the 100 ohm driver has 5pf across it. Oh dear, the same reflection mechanism as at the receiver! > > The rise times from the driver are moderate, and adequate, so mis-matches > don't jump up and make life difficult, and cross talk is reduced. > Of course they're moderate, they have to charge up a 5pF cap. That's not a good thing, no matter how you spin it! It's only adequate if your application needs a moderate rise time!? > > Some folks have lightning fast drivers, which cross talk like crazy, and > even their "lower" input C looks awful, as a signal with 2X the rise makes > even 3pF look really bad. > So, I think on all my future high speed designs I'll add on extra capacitors to the drivers, you make it sound such a great idea! (Apologies for the sarcasm) > > "The system is the solution." Driver, termination, line, receiver, all > have to be considered. I know, you, personally have issue with the > solution, but, face it, Virtex family has been an astounding success: and > TO THIS DAY, we are the only ones with 65nm product, shipping (at all) > production parts. ONE YEAR as of May 5th.... > > Think of all those sockets we are being designed into. All of those LVDS > interfaces working. Literally tens of millions of them. > > Do we have room to improve? Of course. But, any improvement is weighted > against its benefits. Make the input less capacitive has no benefit > (other than you would immediately post "see! I told you!" and I would not > have to reply to this issue anymore). > > What might be a better item to work on, rather than spend time on > something that "ain't broke?" > > Oh, did I mention how ecstatic we are that we have a one year lead on > 65nm? > > Austin Wow, what brought that on? I'm sorry but for some reason I kept seeing Tom Cruise on the couch when I was reading that! Ever thought of switching to de-caf? :-) (Just kidding!!) Anyway, we've been through this before, we're never gonna agree, your loyalty to Xilinx is too strong for that (kidding again!), but anyone who's interested can search back through comp.arch.fpga and decide for themselves whether high speed outputs and receivers are compromised by pin capacitance. Cheers, Syms.Article: 119684
Hello, I'm looking for an import utility from Intel Hex to the supported formats of ModelSim, e. g. MTI or Verilog (Hex). Many thanks in advance UdoArticle: 119685
"John_H" <newsgroup@johnhandwork.com> wrote in message news:135be6pdo0nn37e@corp.supernews.com... > "Symon" <symon_brewer@hotmail.com> wrote in message > news:f349ou$ppq$1@aioe.org... >>> >> It is possible to match even Xilinx's hideous 10pF receiver pins. Here's >> an example from Xilinx's own consultant's website:- >> http://sigcon.com/Pubs/edn/ConstantRTermination.htm >> >> HTH, Syms. > > > If it's important to not have reflections, the R-only equivalent > termination is superb. > If it's important to have the high slew rate, the standard termination > with the associated pin capacitance is the way to go because the > reflection *will* be absorbed by the transmitter's impedance if it's > properly matched. > > Signal Integrity *at the pin* is what's important and where a monte-carlo > SI analysis will show which approach provides a cleaner interface in the > end. > > For this implementation where the speed is low, the extra 250 ps of RC > time constant (it's C/2 for a differential signal) will probably provide > excellent results. > > - John_H > Hi John, Neatly summarised! Thanks, Syms.Article: 119686
Symon, We agree to disagree. I would hope that it is clear that the Xilinx solution works just fine. There are just far too many working pcbs out there to suggest otherwise. I have already agreed it could be better, but if it works, why bother? As for loyalty to Xilinx, I am trying to be an engineer: facts, facts, facts. Fact: input Z (and output Z) = 100 ohms + 5pf Fact: risetime is adequate for the job (too fast is actually a bad thing, too slow just mens you can't operate at very high rates, parts meet their specifications) Fact: Symon hates having any C in parallel with the termination. Fact: All terminations have some C. Fact: Symon and I do not agree. AustinArticle: 119687
on www.fpgaarcade.com you can get the latest version of the T65 core from Opencores. I did a lot of debuging work on the original and still maintain it as the original author has vanished. It is used in a number of the arcade game projects with great success. /MikeArticle: 119688
John, In no way did I imply that engineers should not learn about SI. But, I can not require SI knowledge, either. That is why we have IO standards (cookbook recipes). Without a degree in E&M theory, I would argue that you can't really understand what is going on. Well, a suppose a physicist might be capable of recognizing Maxwell's equations, but as far as I know, only those who have actually set up, and solved these equations, have the fundamental knowledge that is required. There are many who have practical knowledge (experience), and that sometimes passes for understanding. Anyone else is someone who is just pretending they have the knowledge. And that is just fine: just as we can not ask that all users of FPGAs know everything about heat transfer, we recognize that the team who are using the FPGA will require some support for those specialties that they lack. AustinArticle: 119689
Symon, I agree. For those for whom SI is a mystery, learn something today: go read up on SI. AustinArticle: 119690
I need to write some timing constraints for an ProAsic device. The Designer tool doesn't seem to cater for what I need; as follows: FPGA1 (Xilinx) outputs data on clk rising edge & FPGA2 (my Actel) captures data on the clk falling edge (Same clock with very low skew to both devices) Similarly Actel outputs data on clk falling edge & Xilinx capture on rising edge. I have the Xilinx input & output delays and the clock period is 30 ns. The clock M/S ratio is 40/60 though, so the total allowed time from one device clocking out to the other device clocking in is therefore 12 ns (40% of 30ns as worst case). PCB trace is assumed ~1ns. So how do I apply the constraints to my Actel chip; I've never used an SDC file, so some tips or pointers to examples would be useful. TIA, NivArticle: 119691
My supervisor installed gmake. The first problem is solved but not the second: In modelsim, when try to simulate (behavioral) it tries to load the whole system but the next massage is shown: Loading opb_arbiter_v1_02_e.or_gate(imp)#1 # ** Fatal: (vsim-3348) Port size (1) does not match actual size (32) for port '/system/opb/opb/opb_abus_i/y'. # Time: 0 ps Iteration: 0 Instance: /system/opb/opb/opb_abus_i File: /opt/xilinx/EDK8.2/hw/XilinxProcessorIPLib/pcores/ opb_arbiter_v1_02_e/hdl/vhdl/or_gate.vhd Line: 125 # FATAL ERROR while loading design # Error loading design Someone have any idea? On May 24, 9:44 am, ferorcue <le_m...@hotmail.com> wrote: > I have a question: > > I think that gmake is not installed in my operating system (solaris)>whereis gmake > gmake: > > whereas make is intalled>whereis make > > make: /usr/bin/make /usr/X11R6/bin/make /usr/bin/X11/make > /usr/share/man/man1/make.1.gz > > > > What file and how should I change in order to use make with LIBGEN ? > > Thank you for your consideration.Article: 119692
Lancer wrote:
> is it possible to use Spartan 3 BRAM (on my xc3s1000 it should be
> 432K) as a ROM memory for data storage
I make ROMs like this:
http://home.comcast.net/~mike_treseler/sync_rom.vhd
-- Mike Treseler
Article: 119693What are the rules for coding a bidirectional databus in VHDL? I must be able to connect several different entities to the same bus, and all entities but one has its outputs as 'Z'. Should the bus signals be declared as inout?Article: 119694
Fed wrote:
> What are the rules for coding a bidirectional databus in VHDL?
> I must be able to connect several different entities to the same bus, and
> all entities but one has its outputs as 'Z'.
That's the rule.
> Should the bus signals be declared as inout?
I would prefer to use separate data_in and data_out buses.
There are no real tri-state nodes inside the fpga.
-- Mike Treseler
Article: 119695On Thu, 24 May 2007 07:23:01 -0700, austin <austin@xilinx.com> wrote: >All, > >I suppose suggesting that the question could be answered in less than 10 >minutes using a SIGNAL INTEGRITY simulator would just be silly? > >I am absolutely amazed at how much time, money, and energy is wasted >just because a SI simulator is "expensive." > >One respin of a pcb is MORE $$$ than buying the SI simulator tool. > >Mentor's Hyperlynx(tm) simulator is my favorite, but Cadence has their >tool which might be more to some folks liking (it is integrated with the >PCB layout stuff). > >So, how about it? Invest in something that will save you enough money >to pay for it the first time you do not screw up. > >Submit a hotline webcase, and ask for a "what if" SI simulation. That >way you will get a free example of (one) solution to your problem. > > >One comment: matching the transmitter impedance is a good idea, as a >perfect match at the receiver is impossible (perfect may happen in >textbooks, but not in real life). > Does an LVDS transmitter have an impedance? The ones I've played with seem to behave like current sources; unloaded, the diff outputs swing (slowly!) almost rail-to-rail. That said, presenting the transmitter with an equivalent 100 ohm net diff load will normalize the swing to standard levels and speed things up a bit as compared to letting them see a 173 or whatever diff load. JohnArticle: 119696
On Thu, 24 May 2007 15:26:15 +0100, "Symon" <symon_brewer@hotmail.com> wrote: >"John_H" <newsgroup@johnhandwork.com> wrote in message >news:cUg5i.9206$ix.312@trndny01... >> stefan.elmsted@gmail.com wrote: >>> Hi >> >> On the transmitter, you want a 100 ohm to 173 ohm impedance match so the >> transmitter sees 100 ohm but the transmission line sees 173 ohm. You'll >> need a differential termination on the transmitter side of this network >> and two series resistors to the ribbon cable. The signal amplitude will >> again be reduced. >> >You don't _need_ to match both transmitter and receiver. One or the other is >good enough, provided the path between the driver and the cable has the same >impedance as the cable, or this path is short. Cf. ECL logic, low output >impedance, but can drive a properly terminated diff. pair. LVDS outputs are >matched to the line to get a belt 'n' braces approach to reduce reflections, >but it's not necessary to match the transmitter to the line. > >Here's an app note which describes the output structures. >http://www.maxim-ic.com/appnotes.cfm/an_pk/291 > >HTH, Syms. > National's CMOS structure is different, http://www.national.com/appinfo/lvds/files/lvds_ch1.pdf more of a real current source. I'd guess that the Maxim is the oddball here. The National and Fairchild transmitters I've played with will go rail-to-rail if not terminated. I haven't tried an unterminated Xilinx lvds driver; their receivers are pretty good r-r comparators. JohnArticle: 119697
Pablo wrote:
> Hi everyone, I want to design a model with my Smt338. This is a
> Sundance board with a Virtex IIPro30 ff896-6 and a Micron MT46V16M16
> as DDR memory. First of all I need to implement the hardware
> architecture, so I use edk 8.1 (or edk 8.2) to create a model with
> PowerPC and this DDR memory. In the ucf I map every port, but I have
> not any pin to DDR_CLK, that is, the feedback ddr clock.
>
> This is the loc entry: Net fpga_0_GEN_DDR_CLK_FB LOC=;
>
> What can I do?. Perhaps I could use a DCM_module but I don't know how
> could I implement it.
One way is to put the feedback on an unused pin:
DDR_Clk_fb : inout std_logic;
To keep the timing independent of PAR layout, drive the pin with a DDR
register:
DDR_CLK_FB_e: FDDRRSE
port map (
Q => DDR_Clk_fb_o,
C0 => CLK90,
C1 => CLK90n,
CE => '1',
D0 => '1',
D1 => '0',
R => '0',
S => '0'
);
Then instantiate the io buffer:
ddr_clk_io : IOBUF
port map (
I => DDR_Clk_fb_o,
IO => DDR_Clk_fb,
O => DDR_Clk_fb_i,
T => '0'
);
And so, of course, DDR_Clk_fb_i is the input feedback signal.
Article: 119698"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message news:0ppb531bd38oj99t3dne4fei8n4lrotm00@4ax.com... > > National's CMOS structure is different, > > http://www.national.com/appinfo/lvds/files/lvds_ch1.pdf > > more of a real current source. I'd guess that the Maxim is the oddball > here. The National and Fairchild transmitters I've played with will go > rail-to-rail if not terminated. I haven't tried an unterminated Xilinx > lvds driver; their receivers are pretty good r-r comparators. > > John The FPGA structures appear to be what are important to this conversation. There are transmitters that are true current sources both with and without internal 100 ohm parallel terminations. There are transmitters that present voltage drivers with (series) source impedances that roughly match the current-source approach. For anyone designing with LVDS, appropriate reading of the data sheet information on the transmitter is important. For a proper LVDS connection, the transmitter needs to appear to be a 100 ohm differential source. Different manufacturers are happy to deviate slightly from the originally proposed driver structure to present something with equivalent characteristics when properly configured whether this means plug&play, an external parallel termination, or a 3-resistor network to "look" like the equivalent source. Without the 100 ohm equivalent transmit impedance, any reflections from the receiver or other impedance mismatches will reflect back toward the receiver rather than be absorbed at the source. - John_HArticle: 119699
Niv (KP) wrote: > I need to write some timing constraints for an ProAsic device. The > Designer tool doesn't seem to cater for what I need; as follows: > > FPGA1 (Xilinx) outputs data on clk rising edge & FPGA2 (my Actel) > captures data on the clk falling edge (Same clock with very low skew > to both devices) > Similarly Actel outputs data on clk falling edge & Xilinx capture on > rising edge. > I have the Xilinx input & output delays and the clock period is 30 ns. > The clock M/S ratio is 40/60 though, so the total allowed time from > one device clocking out to the other device clocking in is therefore > 12 ns (40% of 30ns as worst case). PCB trace is assumed ~1ns. > > So how do I apply the constraints to my Actel chip; I've never used an > SDC file, so some tips or pointers to examples would be useful. > > TIA, Niv > > You need the "set_output_delay" constraint I think. Designer "help" menu will tell you how to use it. Alternatively use the Timing Analyser GUI in Designer to set the constraints. Alan
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