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
> "Kryten" <kryten_droid_obfusticator@ntlworld.com> wrote in message >> Has Daniel Walner been bumped off then? "MikeJ" <mikej@fpgaarcade.nospam.com> wrote > possibly, we talked a lot for a while and then .... nothing. > He was very interested in Asteroids so I would have expected > some response. Mysterious. I hope he's fine. I know that in my life my personal projects get put on hold when I'm busy with higher priority projects (e.g. buying a home). > Possibly the patent lawyers got him ! Hmm, I think the 6502 has been around for so long it is not a choice for new designs. It has vanished into far-eastern rice cookers but with cores made just out of reach of patent infringements. I can't imagine Zilog pursuing Z80 VHDL models either: any significant commercial market will use full custom Z80 cores like the Rabbit. > I should try and get opencores to give me cvs access to the cores, > then I could update the ones there. So long as we can download your latest models that is the main thing.Article: 119801
I had a similar problem developing an LWIP raw api program. Commenting out the definition of sleep() in the EDK source tree fixed it. I also wondered how the other applications managed to get around this. Paul www.paultobias.com "Ken Ryan" <newsryan@leesburg-geeks.org> wrote in message news:4657B037.1010500@leesburg-geeks.org... > Hello all! > > Has anyone had success using LwIP along with some of the xilkernel > functions in a system that is based on the PPC and hard Trimode Ethernet > MAC? > > I keep running into a problem where the xtemac driver pulls in some xilinx > header files that collide with unistd.h (pulled in by e.g. pthread.h). ... ./ppc405_0/include/sleep.h:32: error: conflicting types for `sleep' ...Article: 119802
On Fri, 25 May 2007 13:37:09 +1000, Mark McDougall <markm@vl.com.au> wrote: >checo wrote: > >> I own a Spartan 3E Starter Kit, which I plan to use for crowd- >> entertainment purposes. Since the 3-bit VGA output is way too limiting >> for my project, I am planning to add a 12-bit VGA port to my Starter >> Kit. > >Since MikeJ must be napping... ;) > ><http://home.freeuk.com/fpgaarcade/displaytest.htm> I have seen this done with 17 resistors between a BNC socket and the parallel port of a 2.5MHz Z80 system. The fastest form of "Out" instruction on a Z80 was 4.7 uS, pretty close to perfect for a (625 line 50Hz) line sync pulse. Some assembly required... Mind you, all it could do was a 7-step (not 8-step) grayscale. No colour subcarrier, of course, and no equalizing pulses. Now if only they had a 4MHz Z80A! Culprits shall remain nameless, but the Z80 system went by the name of ZELDA, and pre-dates the game... - BrianArticle: 119803
I am using Spartan3 LVCMOS33 Open drain 24 mA output driver with 150 Ohm external pull-up to 1.8V. I would like to know the slew rate for both rising edge and falling edge. How to calculate the slew rate in this case.Article: 119804
"Test01" <cpandya@yahoo.com> wrote in message news:eea7068.-1@webx.sUN8CHnE... >I am using Spartan3 LVCMOS33 Open drain 24 mA output driver with 150 Ohm >external pull-up to 1.8V. I would like to know the slew rate for both >rising edge and falling edge. How to calculate the slew rate in this case. Search the Xilinx website for the IBIS files. The data you need is in them. Use HyperLynx for nice pictures. According to Xilinx answer 17720: You can download a free IBIS simulator from the following Web sites: http://www.mentor.com/hyperlynx http://www.eigroup.org/ibis/tools.htm You will also need models of whatever the signal is connected to outside the FPGA. HTH, Syms.Article: 119805
Symon, As much as I'd like to say "great answer"! I am concerned that this particular IO standard has been characterized for a Vcco of 3.3 volts, and he won't be simulating what he wants. By that, I mean that the IBIS file is derived from spice simulations done on the IOB at 3.3 volts, LVCMOS 24 mA. Just because he is now using the IO as pull down only, at 1.8 volts, doesn't seem to me to "match" the conditions used for the simulations. Specifically, the dV/dt listed in the IBIS file was derived under different conditions. Probably the difference will not be more than 10%, or perhaps even less than the slow/weak fast/strong IBIS corners. If he had access to an hspice license, he could also download the encrypted hspice IO models, which he can then have more control of (I believe). Since it is Saturday, and I am not at Xilinx, I am unable to offer running a "what if" for Mr Test01. Perhaps when I get back in on Tuesday, (Monday is a holiday here). Botton line? Sounds like our 'test" fellow is doing some weird and unusual stuff (which is just fine), but he may have to try it to see what he gets. For example, it was already mentioned that if one IO doesn't slew/drive enought, put two in parallel. If that doesn't do it, put three in parallel. You may do this without concern (up to the SSO limits), as the IO is CMOS, and paralleling FETs works. The time difference between signals arriving at the IOs, and IO pins is ~ 10 ps from one IO to an adjacent IO, so he really doesn't care about non-simultaneous drive. If he is really picky, he can "see" the wire in the package from the bump to the pad in the package by selecting his package in the IBIS model. Then he could synchonize all the IO signal to arrive at the same instant externally by adding a variable length of pcb trace to each IO to make tham all the "same". We only get down to +/- 5ps accuracy for these numbers, so that exercise is hardly worth it in a small device, but for a 1136, or 1704 pin package, there can be as much as 1.5 inches from the bump to the pad in the package. So some IOs get out in .2 inches, and some get out much later. Hence the reason why a 800 Mb/s DDR interface might want to have all the IOs in a bus equal length to the sink/source. He may want to look at the LVCMOS 1.8 V IBIS. In fact, if he instantiates LVCMOS 24 mA driver (even though it is a 3.3 V Vcco bank), I suspect that he will get a DRC warning (not an error), and he may go ahead and generate a bitstream anyway. That way, the pull down transistor "believes" it is in a 1.8 V system, and the dV/dt for that standard in the IBIS file is more accurate....if the software won't let him do this (as there are other 3.3V standards in the same bank), then I think you can turn off DRC (highly not-recommended unless you know what you are doing). Other than my concerns, "great answer!" AustinArticle: 119806
Frank,
Now that the truly paranoid have worked it out of their systems, here is
a bit of advice:
Like Kolja (I don't count him in the "paranoid category) has cleaqred
things up (patents time out, and expire: trademarks last much longer),
here is the practical side of things.
Patent holders have better things to do with their time than to start
legal proceedings, so it goes like this (a flowchart in pseudo-code for
all those software types out there):
if 'someone is potentially using our patents' then
if 'revenues of said company > 1 billion $ (US)' then
if 'letter sent to ask for license fees rejected' then
if 'letter sent back contains demands for licenses from their
portfolio is scary' then
do:
crosslicense() -- no money changes hands
end
else
do;
startlegalproceedings()
end
else
do:
negociatelicensefees()
end
else
do:
sendnastyscaryletter() --company too small
end
endif --keep looking for a big company with money infringing
Now, I suppose this is an engineer's view of the patent world, but I am
sure that it is a pretty good description.
Now, there is a different algorithm for patent trolls, but it only
differs in that cross-licensing is not an option.
Austin
Article: 119807I measured the slew rate using oscilloscope and it is about 0.1v/ns for 24 mA driver with 150 Ohm external pull-up to 1.8V. I would like to know if this value can be increased to 0.5v/ns. The receiver on the other end is expecting 0.5v/ns. I wish I could piggy back more FPGA outputs to increase the slew rate but I do not have that option. Also I am not sure how piggy backing will help for the improving the rise time as external pull-up determines this. Is that correct? I am particularly interested increasing the slew rate to 0.5v/ns on the rising edge as this particular signal is used as clock. Is there any way the FPGA can turn-off the bottom transistor quicker in order to improve the slew rate on the rising edge? I wish I knew how to use the Hspice/IBIS model. I really appreciate your valuable feedback. Thanks.Article: 119808
austin wrote: > do: > sendnastyscaryletter() --company too small > end Thanks for the algorithm. But what is the content of the nastyscaryletter? If it is a cease and desist letter from a lawyer, where I have to pay some thousands of dollars and have to stop using it in my designs, if I don't want to start legal proceedings, this would be not an option. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119809
Test01, To know if you are measuring what is required, I need to know: Bandwidth of the oscilloscope Bandwidth of the oscilloscope probes How the probe is connected to the pin and ground (ie, how long are the wires) You may be unable to see the rise time because the scope does not have the bandwidth, or the probes do not have the bandwidth, or you have connected to the IO with a 6" ground lead (all too common). High speed measurements require technique, and knowledge. http://www.xilinx.com/products/design_resources/signal_integrity/ http://www.sigcon.com/Pubs/straight/probes.htm AustinArticle: 119810
"Test01" <cpandya@yahoo.com> wrote in message news:eea7068.2@webx.sUN8CHnE... >I measured the slew rate using oscilloscope and it is about 0.1v/ns for 24 >mA driver with 150 Ohm external pull-up to 1.8V. I would like to know if >this value can be increased to 0.5v/ns. The receiver on the other end is >expecting 0.5v/ns. I wish I could piggy back more FPGA outputs to increase >the slew rate but I do not have that option. Also I am not sure how piggy >backing will help for the improving the rise time as external pull-up >determines this. Is that correct? > > I am particularly interested increasing the slew rate to 0.5v/ns on the > rising edge as this particular signal is used as clock. > > Is there any way the FPGA can turn-off the bottom transistor quicker in > order to improve the slew rate on the rising edge? > > I wish I knew how to use the Hspice/IBIS model. > > I really appreciate your valuable feedback. > > Thanks. Hi, OK, in your case the rise time is determined by the capacitance of the pin. It's about 10pF. The 'bottom' transistor is turning off bloody quickly, but the Cpin has to charge through the 150 R pullup. You can't change this Cpin, so you can only improve the slew rate by either driving the signal from the pin, or by using a smaller value pull up resistor. You could try driving it through 2 diodes, 3.3 - 1.4 = 1.9 V, and pull it low through a Schottky diode? Or use some of those bus switch parts. Mind you, you should be getting much better than 0.1V/ns. What is the capacitance of your 'scope probe? What is the capacitance of the signal and receiver you're driving? HTH, Syms.Article: 119811
On Sat, 26 May 2007 11:01:03 -0700, Test01 <cpandya@yahoo.com> wrote: >I measured the slew rate using oscilloscope and it is about 0.1v/ns for 24 mA driver with 150 Ohm external pull-up to 1.8V. What sort of scope/probe did you use? Is there a lot of pcb trace capacitance? That sure sounds slow to me, by a factor of 10 maybe. >I would like to know if this value can be increased to 0.5v/ns. The receiver on the other end is expecting 0.5v/ns. I wish I could piggy back more FPGA outputs to increase the slew rate but I do not have that option. Also I am not sure how piggy backing will help for the improving the rise time as external pull-up determines this. Is that correct? Paralleling open drains will add capacitance and slow down the rise. > >I am particularly interested increasing the slew rate to 0.5v/ns on the rising edge as this particular signal is used as clock. > >Is there any way the FPGA can turn-off the bottom transistor quicker in order to improve the slew rate on the rising edge? Set the output cell to max drive and max slew rate. But I know that the bottom fet turns off a lot faster than you're seeing. Again, I'm surprised it's that slow. 150 ohms from 1.8 volts is 12 mA, so a slew rate of 0.1 v/ns works out to 120 pF on that node, which doesn't make sense. Something else is wrong. Why open drain? Why not series terminate and drive hard up and down? An S3 cmos output usually goes rail to rail in a ns or less. JohnArticle: 119812
Frank, The letter is to try to get you to cease and desist, or to pay a licensing fee (licensing is typically 1 to 3% of "value" -- whatever that is). If you do not reply, or if you reply with "no way, sue me" then most companies will not waste the time. Since you are less than a billion dollars a year, chances are you don't have the money anyway, or you will likely not be in business in a year or two. In the cold, hard, real world, legal folks are incredibly practical: only companies that make money, and are likely to be around in ten years are the targets of lawsuits (unless the people involved are just running on ego, and are willing to waste time and money). So, the patent trolls (and companies with large portfolios) watch and wait: they keep track of how many patents you may be infringing on, and as soon as you announce passing one billion dollars in sales BINGO! the letters start arriving. Standard practice for legal departments, wait until the fish is worth catching before you put the hook in the water. 6502? What a laugh. How much money is there left to be made on this? How much money will a legal department spend? Do the math, then think about it. There are some companies who when faced with knowingly infringing on someone's patent, consciously choose to do so. Yes, they may have to pay treble damages if they get caught (worst of scenarios) and also cease and desist. But how often do you read about someone losing a patent lawsuit like that? Often, the benefit outweighs the downside, and once brought into court, asking for a jury trial, and having a good legal team may cost you less than licensing it in the first place would have cost. Now, a good legal department won't let anyone do this, as the risk is very large, and the treble damages and shutdown is far too great a risk. That said, in seems to happen all the time, regardless. Some products have a six month lifecycle (like a printer). Go into business, build and sell 100,000 printers, and then disappear. Happens all the time. Do they even care about infringement? Nope, they do it again under a new name... Getting back to ego, there are some who just love to go to court, and are willing to waste huge sums of money doing so. Eventually they run out of money, and end up bitching about their loss until they finally realize they were just stupid, and should have spent their energies more wisely. Or not. They never learn. And lawyers never turn down a job, as even when they lose for a client, they at least get paid for it. AustinArticle: 119813
John,
You bet something else is wrong: he doesn't seem know how to measure,
and has admitted he can't simulate. Really a bad combination,
unfortunately. Hope he spends some time reading all that good SI stuff.
If he doesn't, then I think we can safely write Mr Test off as a
tinkerer. Perhaps we need a comp.arch.not.serious.tinkerers.fpga?
Below is the 24 mA IBIS file (sorry to include it all, but it may be
useful to Mr Test).
Note dV/dt_f is 1.00/0.31n typcal for R_load = 50.00
So that is more than 3 volts per ns for a falling waveform (you can
ignore the 150 ohms for this, as the pull down less than a few ohms, so
it is only the capacitaive load that could slow you down, or bad
measurement not seeing what is really happening).
Austin
(here is the 24mA excerpted from the IBIS file -- note you can import as
csv most IBIS into Excel Spreadsheets, and draw the graphs if you like)
|************************************************************************
| Model LVCMOS25_F_24mA
|************************************************************************
|
[Model] LVCMOS25_F_24mA
Model_type I/O
Polarity Non-Inverting
Enable Active-Low
Vinl = 0.70V
Vinh = 1.70V
Vmeas = 1.25V
Cref = 0.000F
Rref = 1.00M
Vref = 0.000V
C_comp 6.38pF 4.60pF 8.23pF
|
|
[Temperature Range] 25.00 85.00 0.000
[Voltage Range] 2.50V 2.30V 2.70V
[Pulldown]
| voltage I(typ) I(min) I(max)
|
-2.50 -39.52mA -32.21mA -41.99mA
-0.70 -39.52mA -32.21mA -41.99mA
-0.60 -37.69mA -30.83mA -40.12mA
-0.50 -35.33mA -28.39mA -38.03mA
-0.40 -31.02mA -24.50mA -34.39mA
-0.30 -24.07mA -18.90mA -27.42mA
-0.20 -16.17mA -12.66mA -18.57mA
-0.10 -8.12mA -6.33mA -9.34mA
0.00 3.97nA 15.14nA 6.84nA
0.10 7.97mA 6.17mA 9.21mA
0.20 15.60mA 12.04mA 18.08mA
0.30 22.86mA 17.59mA 26.58mA
0.40 29.75mA 22.82mA 34.70mA
0.50 36.25mA 27.70mA 42.42mA
0.60 42.30mA 32.20mA 49.71mA
0.70 47.83mA 36.26mA 56.48mA
0.80 52.72mA 39.78mA 62.63mA
0.90 56.82mA 42.67mA 68.00mA
1.00 60.04mA 44.90mA 72.43mA
1.10 62.47mA 46.54mA 75.90mA
1.20 64.29mA 47.77mA 78.52mA
1.30 65.68mA 48.71mA 80.52mA
1.40 66.78mA 49.46mA 82.08mA
1.50 67.68mA 50.08mA 83.34mA
1.60 68.44mA 50.61mA 84.38mA
1.70 69.10mA 51.07mA 85.27mA
1.80 69.68mA 51.48mA 86.04mA
1.90 70.20mA 51.85mA 86.73mA
2.00 70.67mA 52.18mA 87.35mA
2.10 71.11mA 52.49mA 87.91mA
2.20 71.51mA 52.78mA 88.43mA
2.30 71.89mA 53.05mA 88.91mA
2.40 72.25mA 53.31mA 89.37mA
2.50 72.59mA 53.55mA 89.79mA
2.60 72.91mA 53.80mA 90.20mA
2.70 73.23mA 54.07mA 90.59mA
2.80 73.54mA 54.66mA 90.98mA
2.90 73.85mA 56.57mA 91.35mA
3.00 74.28mA 61.22mA 91.73mA
3.10 75.63mA 84.35mA 92.11mA
3.20 79.30mA 0.20A 92.55mA
3.30 86.13mA 0.39A 93.65mA
3.40 0.13A 0.61A 97.15mA
3.50 0.28A 0.85A 0.10A
3.60 0.49A 1.09A 0.12A
3.70 0.73A 1.34A 0.25A
3.80 0.97A 1.59A 0.45A
4.00 1.47A 2.10A 0.93A
4.20 1.98A 2.62A 1.42A
4.40 2.50A 3.14A 1.93A
4.60 3.02A 3.66A 2.45A
4.80 3.54A 4.18A 2.97A
5.00 4.06A 4.70A 3.49A
|
[Pullup]
| voltage I(typ) I(min) I(max)
|
-2.50 51.16mA 40.83mA 56.65mA
-0.70 51.16mA 40.83mA 56.65mA
-0.60 46.78mA 38.25mA 51.96mA
-0.50 41.80mA 33.92mA 46.73mA
-0.40 35.29mA 28.38mA 39.93mA
-0.30 26.86mA 21.54mA 30.67mA
-0.20 17.87mA 14.29mA 20.46mA
-0.10 8.88mA 7.08mA 10.19mA
0.00 -4.09nA -13.36nA -7.84nA
0.10 -8.64mA -6.82mA -9.99mA
0.20 -16.94mA -13.29mA -19.67mA
0.30 -24.89mA -19.41mA -29.03mA
0.40 -32.48mA -25.17mA -38.07mA
0.50 -39.70mA -30.57mA -46.77mA
0.60 -46.55mA -35.59mA -55.12mA
0.70 -53.00mA -40.24mA -63.12mA
0.80 -59.06mA -44.50mA -70.76mA
0.90 -64.72mA -48.36mA -78.02mA
1.00 -69.95mA -51.82mA -84.89mA
1.10 -74.75mA -54.82mA -91.36mA
1.20 -79.09mA -57.32mA -97.41mA
1.30 -82.91mA -59.37mA -0.10A
1.40 -86.16mA -61.11mA -0.11A
1.50 -88.91mA -62.62mA -0.11A
1.60 -91.28mA -63.94mA -0.12A
1.70 -93.35mA -65.13mA -0.12A
1.80 -95.21mA -66.22mA -0.12A
1.90 -96.88mA -67.21mA -0.13A
2.00 -98.42mA -68.13mA -0.13A
2.10 -99.83mA -68.98mA -0.13A
2.20 -0.10A -69.79mA -0.13A
2.30 -0.10A -70.54mA -0.14A
2.40 -0.10A -71.26mA -0.14A
2.50 -0.10A -71.94mA -0.14A
2.60 -0.11A -72.60mA -0.14A
2.70 -0.11A -73.24mA -0.14A
2.80 -0.11A -74.01mA -0.14A
2.90 -0.11A -75.85mA -0.14A
3.00 -0.11A -82.38mA -0.15A
3.10 -0.11A -0.14A -0.15A
3.20 -0.11A -0.60A -0.15A
3.30 -0.12A -1.57A -0.15A
3.40 -0.28A -2.75A -0.15A
3.50 -1.06A -4.02A -0.16A
3.60 -2.19A -5.34A -0.23A
3.70 -3.44A -6.68A -0.89A
3.80 -4.76A -8.05A -2.00A
4.00 -7.47A -10.81A -4.55A
4.20 -10.25A -13.60A -7.26A
4.40 -13.06A -16.42A -10.03A
4.60 -15.88A -19.24A -12.84A
4.80 -18.72A -22.08A -15.67A
5.00 -21.56A -24.92A -18.51A
|
[GND_clamp]
| voltage I(typ) I(min) I(max)
|
-2.50 -21.56A -22.07A -21.35A
-2.40 -20.13A -20.65A -19.93A
-2.30 -18.71A -19.23A -18.51A
-2.20 -17.29A -17.82A -17.08A
-2.10 -15.88A -16.41A -15.66A
-2.00 -14.46A -15.00A -14.25A
-1.90 -13.05A -13.60A -12.83A
-1.80 -11.64A -12.20A -11.42A
-1.70 -10.24A -10.80A -10.02A
-1.60 -8.85A -9.42A -8.62A
-1.50 -7.46A -8.04A -7.23A
-1.40 -6.09A -6.68A -5.86A
-1.30 -4.74A -5.33A -4.50A
-1.20 -3.41A -4.01A -3.17A
-1.10 -2.14A -2.73A -1.90A
-1.00 -0.99A -1.54A -0.78A
-0.90 -0.20A -0.56A -0.13A
-0.80 -38.51mA -87.42mA -44.56mA
-0.70 -22.72mA -20.52mA -30.56mA
-0.60 -12.96mA -9.95mA -18.92mA
-0.50 -5.43mA -4.08mA -9.17mA
-0.40 -1.21mA -0.97mA -2.67mA
-0.30 -0.12mA -0.12mA -0.35mA
-0.20 -6.24uA -9.21uA -23.23uA
-0.10 -0.21uA -0.58uA -0.74uA
0.00 -20.25nA -99.36nA -30.28nA
0.10 -13.41nA -68.12nA -13.46nA
0.20 -11.99nA -60.84nA -11.53nA
0.30 -10.88nA -55.50nA -10.13nA
0.40 -9.83nA -50.54nA -8.84nA
0.50 -8.80nA -45.73nA -7.58nA
0.60 -7.79nA -40.98nA -6.33nA
0.70 -6.79nA -36.27nA -5.10nA
0.80 -5.79nA -31.57nA -3.86nA
0.90 -4.78nA -26.86nA -2.62nA
1.00 -3.77nA -22.12nA -1.37nA
1.10 -2.75nA -17.33nA -97.85pA
1.20 -1.71nA -12.49nA 1.20nA
1.30 -0.65nA -7.58nA 2.53nA
1.40 0.43nA -2.57nA 3.89nA
1.50 1.53nA 2.55nA 5.30nA
1.60 2.67nA 7.80nA 6.77nA
1.70 3.85nA 13.23nA 8.29nA
1.80 5.07nA 18.88nA 9.89nA
1.90 6.34nA 24.83nA 11.56nA
2.00 7.67nA 31.19nA 13.33nA
2.10 9.08nA 38.27nA 15.19nA
2.20 10.59nA 47.00nA 17.17nA
2.30 12.24nA 79.37nA 19.28nA
2.40 14.14nA 0.60uA 21.55nA
2.50 19.29nA 8.49uA 24.01nA
|
[POWER_clamp]
| voltage I(typ) I(min) I(max)
|
-2.50 4.06A 4.18A 4.02A
-2.40 3.80A 3.92A 3.75A
-2.30 3.54A 3.65A 3.49A
-2.20 3.28A 3.39A 3.23A
-2.10 3.01A 3.13A 2.97A
-2.00 2.75A 2.87A 2.71A
-1.90 2.49A 2.61A 2.45A
-1.80 2.23A 2.36A 2.19A
-1.70 1.98A 2.10A 1.93A
-1.60 1.72A 1.84A 1.67A
-1.50 1.46A 1.59A 1.41A
-1.40 1.21A 1.34A 1.16A
-1.30 0.96A 1.09A 0.91A
-1.20 0.71A 0.84A 0.66A
-1.10 0.48A 0.60A 0.43A
-1.00 0.26A 0.38A 0.21A
-0.90 84.79mA 0.18A 61.18mA
-0.80 24.88mA 50.29mA 27.26mA
-0.70 15.03mA 14.55mA 18.43mA
-0.60 8.66mA 7.10mA 11.09mA
-0.50 3.65mA 2.98mA 5.05mA
-0.40 0.79mA 0.73mA 1.23mA
-0.30 70.40uA 95.28uA 0.11mA
-0.20 3.77uA 8.49uA 4.80uA
-0.10 0.15uA 0.60uA 0.16uA
0.00 19.29nA 79.37nA 32.11nA
|
[Ramp]
| variable typ min max
dV/dt_r 1.20/0.16n 1.03/0.26n 1.34/0.13n
dV/dt_f 1.17/0.23n 1.00/0.31n 1.31/0.18n
R_load = 50.00
|
[Rising Waveform]
R_fixture = 50.00
V_fixture = 0.000
| time V(typ) V(min) V(max)
|
0.000S 0.000V 1.01uV 0.000V
1.000e-10S 0.000V 1.01uV 0.000V
0.20nS 0.31uV 1.01uV 0.12mV
0.30nS -1.48mV 1.22uV -17.14mV
0.40nS -14.52mV -11.06uV -27.50mV
0.50nS -23.34mV -0.42mV -20.71mV
0.60nS -19.59mV -6.97mV -10.54mV
0.70nS -15.71mV -14.88mV 0.36V
0.80nS 2.69mV -19.80mV 1.46V
0.90nS 0.33V -16.89mV 2.06V
1.00nS 1.10V -12.72mV 2.19V
1.10nS 1.70V -10.85mV 2.22V
1.20nS 1.91V 10.12mV 2.22V
1.30nS 1.97V 0.18V 2.23V
1.40nS 1.99V 0.65V 2.23V
1.50nS 1.99V 1.09V 2.23V
1.60nS 2.00V 1.34V 2.23V
1.70nS 2.00V 1.56V 2.23V
1.80nS 2.00V 1.65V 2.23V
1.90nS 2.00V 1.69V 2.23V
2.00nS 2.00V 1.71V 2.23V
2.10nS 2.00V 1.72V 2.23V
2.20nS 2.00V 1.72V 2.23V
2.30nS 2.00V 1.72V 2.23V
2.40nS 2.00V 1.72V 2.23V
2.50nS 2.00V 1.72V 2.23V
2.60nS 2.00V 1.72V 2.23V
2.70nS 2.00V 1.72V 2.23V
2.80nS 2.00V 1.72V 2.23V
2.90nS 2.00V 1.72V 2.23V
3.00nS 2.00V 1.72V 2.23V
3.10nS 2.00V 1.72V 2.23V
3.20nS 2.00V 1.72V 2.23V
3.30nS 2.00V 1.72V 2.23V
3.40nS 2.00V 1.72V 2.23V
3.50nS 2.00V 1.72V 2.23V
3.60nS 2.00V 1.72V 2.23V
3.70nS 2.00V 1.72V 2.23V
3.80nS 2.00V 1.72V 2.23V
3.90nS 2.00V 1.72V 2.23V
4.00nS 2.00V 1.72V 2.23V
4.10nS 2.00V 1.72V 2.23V
4.20nS 2.00V 1.72V 2.23V
4.30nS 2.00V 1.72V 2.23V
4.40nS 2.00V 1.72V 2.23V
4.50nS 2.00V 1.72V 2.23V
4.60nS 2.00V 1.72V 2.23V
4.70nS 2.00V 1.72V 2.23V
4.80nS 2.00V 1.72V 2.23V
4.90nS 2.00V 1.72V 2.23V
5.00nS 2.00V 1.72V 2.23V
|
[Rising Waveform]
R_fixture = 50.00
V_fixture = 2.50
V_fixture_min = 2.30
V_fixture_max = 2.70
| time V(typ) V(min) V(max)
|
0.000S 0.55V 0.63V 0.52V
1.000e-10S 0.55V 0.63V 0.52V
0.20nS 0.55V 0.63V 0.52V
0.30nS 0.55V 0.63V 0.63V
0.40nS 0.60V 0.63V 1.10V
0.50nS 1.02V 0.63V 1.52V
0.60nS 1.42V 0.65V 1.84V
0.70nS 1.64V 0.79V 2.21V
0.80nS 1.87V 1.14V 2.59V
0.90nS 2.18V 1.44V 2.68V
1.00nS 2.41V 1.66V 2.70V
1.10nS 2.48V 1.82V 2.70V
1.20nS 2.49V 1.95V 2.70V
1.30nS 2.50V 2.09V 2.70V
1.40nS 2.50V 2.22V 2.70V
1.50nS 2.50V 2.27V 2.70V
1.60nS 2.50V 2.28V 2.70V
1.70nS 2.50V 2.29V 2.70V
1.80nS 2.50V 2.30V 2.70V
1.90nS 2.50V 2.30V 2.70V
2.00nS 2.50V 2.30V 2.70V
2.10nS 2.50V 2.30V 2.70V
2.20nS 2.50V 2.30V 2.70V
2.30nS 2.50V 2.30V 2.70V
2.40nS 2.50V 2.30V 2.70V
2.50nS 2.50V 2.30V 2.70V
2.60nS 2.50V 2.30V 2.70V
2.70nS 2.50V 2.30V 2.70V
2.80nS 2.50V 2.30V 2.70V
2.90nS 2.50V 2.30V 2.70V
3.00nS 2.50V 2.30V 2.70V
3.10nS 2.50V 2.30V 2.70V
3.20nS 2.50V 2.30V 2.70V
3.30nS 2.50V 2.30V 2.70V
3.40nS 2.50V 2.30V 2.70V
3.50nS 2.50V 2.30V 2.70V
3.60nS 2.50V 2.30V 2.70V
3.70nS 2.50V 2.30V 2.70V
3.80nS 2.50V 2.30V 2.70V
3.90nS 2.50V 2.30V 2.70V
4.00nS 2.50V 2.30V 2.70V
4.10nS 2.50V 2.30V 2.70V
4.20nS 2.50V 2.30V 2.70V
4.30nS 2.50V 2.30V 2.70V
4.40nS 2.50V 2.30V 2.70V
4.50nS 2.50V 2.30V 2.70V
4.60nS 2.50V 2.30V 2.70V
4.70nS 2.50V 2.30V 2.70V
4.80nS 2.50V 2.30V 2.70V
4.90nS 2.50V 2.30V 2.70V
5.00nS 2.50V 2.30V 2.70V
|
[Falling Waveform]
R_fixture = 50.00
V_fixture = 0.000
| time V(typ) V(min) V(max)
|
0.000S 2.00V 1.72V 2.23V
1.000e-10S 2.00V 1.72V 2.23V
0.20nS 2.00V 1.72V 2.23V
0.30nS 2.00V 1.72V 2.23V
0.40nS 2.00V 1.72V 2.23V
0.50nS 2.00V 1.72V 1.91V
0.60nS 1.91V 1.72V 1.08V
0.70nS 1.55V 1.72V 0.43V
0.80nS 0.95V 1.73V 81.22mV
0.90nS 0.33V 1.67V 15.73mV
1.00nS 82.72mV 1.35V 3.28mV
1.10nS 19.13mV 1.00V 0.48mV
1.20nS 4.39mV 0.65V 0.10mV
1.30nS 0.92mV 0.30V 26.37uV
1.40nS 0.20mV 87.74mV 6.27uV
1.50nS 59.43uV 26.46mV 1.59uV
1.60nS 30.39uV 10.72mV -15.00nV
1.70nS 11.28uV 3.37mV -0.59uV
1.80nS 3.40uV 1.20mV -0.67uV
1.90nS 0.32uV 0.49mV -0.63uV
2.00nS -0.72uV 0.22mV -0.53uV
2.10nS -1.01uV 92.12uV -0.41uV
2.20nS -1.03uV 37.33uV -0.54uV
2.30nS -0.97uV 20.84uV 0.26uV
2.40nS -0.85uV 12.22uV -61.60nV
2.50nS -0.81uV 5.48uV 19.25nV
2.60nS -0.63uV 2.12uV 32.45nV
2.70nS -0.47uV 0.53uV 0.24uV
2.80nS -0.25uV -0.13uV 0.19uV
2.90nS -0.45uV -0.77uV 0.58uV
3.00nS -85.60nV -0.49uV 0.37uV
3.10nS 0.000V -0.47uV 0.40uV
3.20nS 0.000V -0.45uV 0.38uV
3.30nS 0.000V -0.36uV 0.41uV
3.40nS 0.000V -0.34uV 0.39uV
3.50nS 0.000V 0.000V 0.42uV
3.60nS 0.000V 0.000V 0.39uV
3.70nS 0.000V 0.000V 0.48uV
3.80nS 0.000V 0.000V 0.20uV
3.90nS 0.000V 0.000V 0.62uV
4.00nS 0.000V 0.000V 0.39uV
4.10nS 0.000V 0.000V 0.42uV
4.20nS 0.000V 0.000V 0.39uV
4.30nS 0.000V 0.000V 0.42uV
4.40nS 0.000V 0.000V 0.39uV
4.50nS 0.000V 0.000V 0.42uV
4.60nS 0.000V 0.28uV 0.39uV
4.70nS 0.000V 0.27uV 0.41uV
4.80nS 0.000V 0.35uV 0.33uV
4.90nS 0.000V 0.18uV 0.57uV
5.00nS 0.000V 0.64uV 5.929e-21V
|
[Falling Waveform]
R_fixture = 50.00
V_fixture = 2.50
V_fixture_min = 2.30
V_fixture_max = 2.70
| time V(typ) V(min) V(max)
|
0.000S 2.50V 2.30V 2.70V
1.000e-10S 2.50V 2.30V 2.70V
0.20nS 2.50V 2.30V 2.70V
0.30nS 2.50V 2.30V 2.70V
0.40nS 2.50V 2.30V 2.71V
0.50nS 2.50V 2.30V 2.71V
0.60nS 2.54V 2.30V 2.37V
0.70nS 2.54V 2.30V 1.80V
0.80nS 2.31V 2.30V 1.10V
0.90nS 1.78V 2.32V 0.69V
1.00nS 1.24V 2.34V 0.56V
1.10nS 0.84V 2.33V 0.53V
1.20nS 0.65V 2.20V 0.52V
1.30nS 0.58V 1.90V 0.52V
1.40nS 0.56V 1.45V 0.52V
1.50nS 0.55V 1.13V 0.52V
1.60nS 0.55V 0.95V 0.52V
1.70nS 0.55V 0.78V 0.52V
1.80nS 0.55V 0.70V 0.52V
1.90nS 0.55V 0.66V 0.52V
2.00nS 0.55V 0.65V 0.52V
2.10nS 0.55V 0.64V 0.52V
2.20nS 0.55V 0.63V 0.52V
2.30nS 0.55V 0.63V 0.52V
2.40nS 0.55V 0.63V 0.52V
2.50nS 0.55V 0.63V 0.52V
2.60nS 0.55V 0.63V 0.52V
2.70nS 0.55V 0.63V 0.52V
2.80nS 0.55V 0.63V 0.52V
2.90nS 0.55V 0.63V 0.52V
3.00nS 0.55V 0.63V 0.52V
3.10nS 0.55V 0.63V 0.52V
3.20nS 0.55V 0.63V 0.52V
3.30nS 0.55V 0.63V 0.52V
3.40nS 0.55V 0.63V 0.52V
3.50nS 0.55V 0.63V 0.52V
3.60nS 0.55V 0.63V 0.52V
3.70nS 0.55V 0.63V 0.52V
3.80nS 0.55V 0.63V 0.52V
3.90nS 0.55V 0.63V 0.52V
4.00nS 0.55V 0.63V 0.52V
4.10nS 0.55V 0.63V 0.52V
4.20nS 0.55V 0.63V 0.52V
4.30nS 0.55V 0.63V 0.52V
4.40nS 0.55V 0.63V 0.52V
4.50nS 0.55V 0.63V 0.52V
4.60nS 0.55V 0.63V 0.52V
4.70nS 0.55V 0.63V 0.52V
4.80nS 0.55V 0.63V 0.52V
4.90nS 0.55V 0.63V 0.52V
5.00nS 0.55V 0.63V 0.52V
|
| End [Model] LVCMOS25_F_24mA
|
Article: 119814Thanks for your valuable input. You asked why open drain output: I need to generate 1.8V output for the receiver. The Spartan3 FPGA vcco pins on my board are tied to 3.3V. Driving push-pull will generate 3.3V but I needed 1.8V output. I am sorry I am a beginner in this. Can you explain how you derived 150 pf capacitance? Thanks again.Article: 119815
"Test01" <cpandya@yahoo.com> wrote in message news:eea7068.7@webx.sUN8CHnE... > Thanks for your valuable input. > > You asked why open drain output: > > I need to generate 1.8V output for the receiver. The Spartan3 FPGA vcco > pins on my board are tied to 3.3V. Driving push-pull will generate 3.3V > but I needed 1.8V output. > > I am sorry I am a beginner in this. Can you explain how you derived 150 pf > capacitance? > > Thanks again. V = It / C 0.1V = 12ma * 1ns / C C = 12ms * 1ns / 0.1 = 120pF Tada...Article: 119816
Thanks for you suggestion. I already have my board so at this point it will be difficult to adding two diodes in series. I am a begginer when it comes to this particular topic. Assuming that there is typical capacitance of 10pf load capacitance on the reciver, what do you think should be the slew rate? How did you calculate this slew rate? Thanks for your help.Article: 119817
I am not at work so I am unable to give you the scope and scope probe information. Thanks a lot. Now I agree. 120 pf capacitor is bit too much for the FPGA driver with only bottom transistor (as I am using it as open drain output). I removed the receiver and the output did not change. I see a little bit of step at around 1V and that is causing the receiver to not work properly. I am just curious if this is more of an impedance mismatch issue. The transmission line of the board is 60 Ohms. Does it not mean that I need 60 Ohm driver and 60 Ohm termination at the receiver? Thanks again.Article: 119818
On May 25, 11:19 am, Marlboro <cco...@netscape.net> wrote: > Hi, > > Is there a quick way to constraint all IO to the same standard? The > default for Spartan3 is LVCMOS25 but we want them to be LVTTL. I know > I can do it by constraint one by one, but we have several hundreds > pins... > > Thanks, If you don't plan to change your I/O names too often, setting hundreds of pins to the same IOSTANDARD shouldn't be too much of work (may be just a matter of global replacement of an expression). Or you may find ADEPT tool (http://home.comcast.net/~jimwu88/tools/adept/) very useful, which allows you to set IOSTANDARD for multiple pins at once. Cheers, JimArticle: 119819
I've implemented a first version of a 6502 core. It has a very simple architecture: First the command is read and then for every command a list of microcodes are executed, controlled by a state machine. To avoid the redundant VHDL typing, the VHDL code is generated with a Lisp program: http://www.frank-buss.de/vhdl/cpu.lisp This is the output: http://www.frank-buss.de/vhdl/t_rex_test.vhdl I've tested some instructions, like LDA, and looks like it works, but I'm sure there are many bugs and not all features are implemented (e.g. BCD mode or interrupt handling). It uses 2,960 LEs with Quartus 7.1, which is too much compared to the 797 LEs of the T65 project. Any ideas how to improve it? My idea was, that the synthesizer would be able to merge the addressing mode implementations for the commands, but maybe this has to be refactored by hand. My goal is to beat the T65 project in LE usage. Speed and 100% compatibility with the original 6502 (e.g. the strange S0 and V-flag feature or the original hardware reset vectors) is not important for me, but code compiled with http://www.cc65.org/ must work. Most FPGAs have some kbyte memory (>5 kByte, even for inexpensive FPGAs, freely configurable as ROM and RAM), so maybe a good idea would be to store some microcode in memory? What instruction set is useful to implement the 6502 instruction set? Maybe a Forth-like microcode? Any ideas how to improve the Lisp code? I like my idea of using a lambda function in addressing-commands, because this looks more clean than a macro, which I've tried first, but I don't like the explicit call of emit-lines. How can I refactor it to a more DSL like approach? -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 119820
Test01 wrote: > I measured the slew rate using oscilloscope and it is about 0.1v/ns for 24 mA driver with 150 Ohm external pull-up to 1.8V. I would like to know if this value can be increased to 0.5v/ns. The receiver on the other end is expecting 0.5v/ns. I wish I could piggy back more FPGA outputs to increase the slew rate but I do not have that option. Also I am not sure how piggy backing will help for the improving the rise time as external pull-up determines this. Is that correct? > > I am particularly interested increasing the slew rate to 0.5v/ns on the rising edge as this particular signal is used as clock. > > Is there any way the FPGA can turn-off the bottom transistor quicker in order to improve the slew rate on the rising edge? > > I wish I knew how to use the Hspice/IBIS model. > > I really appreciate your valuable feedback. Was this rise time, or fall time you are talking of ? Open drain will have skewed Tr.Tf values. What is this driving, as a load ? -jgArticle: 119821
On May 26, 3:44 pm, Jim Granville <no.s...@designtools.maps.co.nz> wrote: > Test01 wrote: > > I measured the slew rate using oscilloscope and it is about 0.1v/ns for 24 mA driver with 150 Ohm external pull-up to 1.8V. I would like to know if this value can be increased to 0.5v/ns. The receiver on the other end is expecting 0.5v/ns. I wish I could piggy back more FPGA outputs to increase the slew rate but I do not have that option. Also I am not sure how piggy backing will help for the improving the rise time as external pull-up determines this. Is that correct? > > > I am particularly interested increasing the slew rate to 0.5v/ns on the rising edge as this particular signal is used as clock. > > > Is there any way the FPGA can turn-off the bottom transistor quicker in order to improve the slew rate on the rising edge? > > > I wish I knew how to use the Hspice/IBIS model. > > > I really appreciate your valuable feedback. > > Was this rise time, or fall time you are talking of ? > Open drain will have skewed Tr.Tf values. > What is this driving, as a load ? > > -jgArticle: 119822
You mentioned that you use open drain because your Vcco is too high. Well, there is a nice trick you can use instead: Instead of permanently turning off the output pull-up transistor (as you are doing), turn it off only when the input level is High. That occurs at about 1.6 to 1.8 V, and you can keep your 150 Ohm resistor to hold the voltage at about that level. Maybe I have to explain that the input functionality is always active, even when you think of the pin as an output. The trick I mentioned has been used to speed up the initial output risetime in the opposite type of application, when a 3.3 V output has to drive a 5 V input. It works like a champ. You get the full-stregth pull-up drive when you need it, and the rising slew rate should be very fast, as fast as the falling slew rate. But the voltage does not go above ~1.8 V. Lots of answers on a lazy Saturday... Peter Alfke, Xilinx Applications On May 26, 3:12 pm, Test01 <cpan...@yahoo.com> wrote: > I am not at work so I am unable to give you the scope and scope probe information. > > Thanks a lot. Now I agree. 120 pf capacitor is bit too much for the FPGA driver with only bottom transistor (as I am using it as open drain output). > > I removed the receiver and the output did not change. I see a little bit of step at around 1V and that is causing the receiver to not work properly. > > I am just curious if this is more of an impedance mismatch issue. The transmission line of the board is 60 Ohms. Does it not mean that I need 60 Ohm driver and 60 Ohm termination at the receiver? > > Thanks again.Article: 119823
I like your trick but I am trying to understand how to express that in verilog. Currenlty my verilog output is signal_out = (test_sig ? 1'bz : 1'b0); where signal_out is an open drain output and test_sig is the signal from the FPGA fabric that I need to pass to the outside world. Here is my attempt at modifying the verilog to try your suggestion: signal_inout = (test_sig ? (signal_inout ? 1'bz : 1'b1) : 1'b0); With the above modification, signal_inout will be a bidirectional pin if not detected high by the fpga i/o and at that time the upper transistor is turned off. I would like to confirm that this is what you are suggesting. Thanks for your valuable input. This may help me out here. Please let me know.Article: 119824
Frank Buss wrote: > I've implemented a first version of a 6502 core. It has a very simple > architecture: First the command is read and then for every command a list > of microcodes are executed, controlled by a state machine. To avoid the > redundant VHDL typing, the VHDL code is generated with a Lisp program: > > http://www.frank-buss.de/vhdl/cpu.lisp > > This is the output: > > http://www.frank-buss.de/vhdl/t_rex_test.vhdl > > I've tested some instructions, like LDA, and looks like it works, but I'm > sure there are many bugs and not all features are implemented (e.g. BCD > mode or interrupt handling). It uses 2,960 LEs with Quartus 7.1, which is > too much compared to the 797 LEs of the T65 project. Any ideas how to > improve it? My idea was, that the synthesizer would be able to merge the > addressing mode implementations for the commands, but maybe this has to be > refactored by hand. That's a lot of ground to make up. Is the 'fat' in any one area ? Does the 797LE version have BCD and Interrupts ? > > My goal is to beat the T65 project in LE usage. Speed and 100% > compatibility with the original 6502 (e.g. the strange S0 and V-flag > feature or the original hardware reset vectors) is not important for me, > but code compiled with http://www.cc65.org/ must work. Err, why not use/improve the T65 work ? -jg
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