a186@mindlink.UUCP (Harvey Taylor) (02/14/90)
I posted this a couple of weeks ago, then some burbles developed
in the feed to Mindlink & then the EuroDevCon happened, so please
to excuse reposting bandwidth waste of humble supplicant...
---
As interesting as the MC68040 is, it is going to take Dave a while
to get it from his bench to your desk. Another item in the Motorola
news release was the 50MHz MC68030. HP has already introduced products
using them (the HP 9000 Series 300 Model 345 and Model 375).
What I wonder is...
Who is going to produce the first Amiga 50 MHz '030 card?
Dave, is this clock feasible on the A2630? On any released '030 card?
<-Harvey
"Avoid implying that you might suppress technological improvements unless
competition forces your hand." - IBM's lawyers' advice to its executives"
-Big Blue:IBM's Use & Abuse of Power by Richard T. Delamarter
Harvey Taylor Meta Media Productions
uunet!van-bc!rsoft!mindlink!Harvey_Taylor
a186@mindlink.UUCPdaveh@cbmvax.commodore.com (Dave Haynie) (02/15/90)
In article <1129@mindlink.UUCP> a186@mindlink.UUCP (Harvey Taylor) writes: > Who is going to produce the first Amiga 50 MHz '030 card? > Dave, is this clock feasible on the A2630? On any released '030 card? In general, it probably can be done on existing cards, but it's certainly not a simple drop-in. There are three main problems. The first of these is the problem of clock quality throughout the board. Lots of tweaking went into the A2630's 25MHz clocking system to keep those fast clocks looking reasonably close to what chips like digital clocks signals to look like all over the board. When you drop in a double-speed clock, all that nice tuning may not be so nice any more. So that's the first hurdle. The second one will be any synchronous logic on the board. Anything clocked off the 50MHz clock will now likely go twice as fast. Some things, especially memory circuits, shouldn't really run that fast. So some state logic may have to be redesigned; if you're lucky, there's enough room left over in a programmable part somewhere and no major hacking to the actual board will be required. The last issue is component speed. There's no DRAM yet out that can hope to keep up with a 50MHz 68030, even as well as the 100ns DRAM on the A2630 keeps up with the 25MHz 68030. So some tweaking will be required to add wait states to support even 60ns or 70ns DRAM. Then there's the fact that lots of TTL and PAL parts just don't work very well at 50MHz, so faster parts will have to be substituted, if they exist. Bottom line: if I ever get a free week or so around here for some hacking, I may try it on an A2630. It won't be a piece of cake, but it'll probably be possible. > Harvey Taylor Meta Media Productions -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
abair@turbinia.oakhill.uucp (Alan Bair) (02/16/90)
Considering what you described as the problems of going to 50MHz, would it be any easier to just go to 33MHz? Is there a higher speed that would only require a change in clock and DRAM speed? I know you have described the restraints placed on the design, but it would be nice to know how far the design can be pushed without major changes. -- Alan Bair SPS CAD Logic Simulation & Test Motorola, Inc. Austin, Texas ...!cs.utexas.edu!oakhill!turbinia!abair
daveh@cbmvax.commodore.com (Dave Haynie) (02/16/90)
In article <ABAIR.90Feb15214210@turbinia.oakhill.uucp> abair@turbinia.oakhill.uucp (Alan Bair) writes: >Considering what you described as the problems of going to 50MHz, would it >be any easier to just go to 33MHz? It is easier to go to 33MHz, in fact, I have a few that do. I don't suppose Commodore is interested in 33MHz these days, but I do intend to make the information public when I'm reasonably sure it's safe. You should have your choice of going to faster memories or not. No clock problems show up at 33MHz. >Alan Bair -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
djh@dragon.metaphor.com (Dallas J. Hodgson) (02/21/90)
It seems to me that the state of Amiga speed-ups is at the primitive level that AT's were when the first 12MHz boards came out. For a long time there was big confusion over clock speed vs. wait states vs. caching strategies, etc. I will put the question to all listening out there : Where are the boards with Cache? Where are the REAL specs? There's plenty of memory management variations on high-speed projects, (page-mode, interleaving, write-back cache, write-thru cache) but I don't see this information an any 3rd-party advertising. Until the Amiga community can agree on a suite of benchmarks, ads are all we have to go on. And I don't want to hear that the 68030's on-chip cache is sufficient, it's not. We're paying big bucks for speedup boards now that could buy us 386's with more efficient design. Anybody care to comment? -Dallas "Down with Wait States" Hodgson
allen@grebyn.com (Allen Farrington) (02/21/90)
In Article 238 of comp.sys.amiga.hardware: >Where are the boards with Cache? >We're paying big bucks for speedup boards now that could buy us >386's with more efficient design. Anybody care to comment? >-Dallas "Down with Wait States" Hodgson Let's be real careful when talking about cache. Cache is expensive, very expensive--$600+ for 64KB. The bottom line is that any SYSTEM which does not use a cache will be limited to about 14MHz (70nS DRAM) memory execution. Beware of super-fast boards which execute at 25-28-33MHz and have no cache. Over the past several years, CPU technology has far outstripped other sub-system technology. All this adds up to a CPU spending a lot of wait-states in instruction fetches. An example is Intel's 386/133 Multibus II single board computer. It has a 386 running at 33MHz. It also has a cache (I forget how large). The point is, this board contains 16MB of DRAM with an 8/16 wait-state penalty for missing the cache/cache and page, respectively. I don't agree that any 386's have an inherently more efficient design over the standard Amiga with an accelerator board. I do agree that a 386 with 64KB of cache is more efficient than the stock Amiga. Perhaps we need a large cache card for the 2630 or other accelerators. --Allen -- |------------------------------------------| | Allen H. Farrington (703) 222-9612 | "It's like nothing we've ever | allen@grebyn.com | dealt with before." |------------------------------------------| -Mr. Spock
swarren@convex.com (Steve Warren) (02/22/90)
In article <19411@grebyn.com> allen@grebyn.UUCP (Allen Farrington) writes: >In Article 238 of comp.sys.amiga.hardware: > >>Where are the boards with Cache? >>We're paying big bucks for speedup boards now that could buy us >>386's with more efficient design. Anybody care to comment? > >>-Dallas "Down with Wait States" Hodgson > >Let's be real careful when talking about cache. Cache is expensive, >very expensive--$600+ for 64KB. > >The bottom line is that any SYSTEM which does not use a cache will be >limited to about 14MHz (70nS DRAM) memory execution. Beware of Well, Hitachi has come out with 1 Mbit DRAMs with a 35 ns access time and 70 ns cycle time. This would allow a zero-wait-state daughter-card to be designed for the 2630 without resorting to any fancy gymnastics. There is no RAS or CAS on these chips. The addr bus is not multiplexed. They have a static column mode and come in 1M X 1 & 256K X 4. They are not commodity chips, however. The process is Bi-CMOS. I haven't seen prices on them yet. My guess would be that once they are in full production they will be reasonable, considering the performance. To me reasonable would be $30-$40 (the price of 100 ns parts last year). -- --Steve ------------------------------------------------------------------------- {uunet,sun}!convex!swarren; swarren@convex.COM
daveh@cbmvax.commodore.com (Dave Haynie) (02/22/90)
In article <1013@metaphor.Metaphor.COM> djh@dragon.metaphor.com (Dallas J. Hodgson) writes: >It seems to me that the state of Amiga speed-ups is at the primitive level that AT's >were when the first 12MHz boards came out. Just based on the nature of the machines, we're both ahead and behind what's happening in the PC market. All but one of the commercial accelerator cards are full 32 bit cards. The vast majority of the PC world isn't even running 32 bit code. Most folks are still using MS-DOS, which executes a really bad 16 bit model, the 8086 model. Some use the '286 model under various DOS add-ons or OS/2. When you're only fetching things in 16 bit chunks, addressing in 16 bit segments, much of the value of fast hardware is lost. Probably about 99% of what's done on a PC will run almost as fast on a 16MHz 386SX as a real 386, and much of it goes even faster on a 16MHz 286. The main value of a 33MHz 386 to most folks has merely been that you can't get a 33MHz 286 yet. UNIX, of course, is the one thing that really takes advantage of such systems. Real 32 bit code should go about twice as fast as 16 bit code. It's the extreme competition in the PC market that's driven this, without a doubt. Neither Amigas nor Macintoshes are settling into a basic high end of 33MHz and about 32-64k of external cache just yet. With Amigas that are currently shipping, the basic 32 bit systems are on coprocessor slot cards. Since you have a limited space here, you have your choice on card of supplying either 32 bit wide memory or a secondary cache. All of these cards have opted for 32 bit memory as a primary concern, and for good reason -- it gives you at least a four-fold speedup guaranteed. All the Amiga code in existance takes advantage of a full 32 bit bus. Far as I know, only the A2630 accelerator supports an add-on secondary cache, though no such card exists as yet. >For a long time there was big confusion over clock speed vs. wait states vs. >caching strategies, etc. People are still confused, and it gets worse when start thinking about the 68030, which has a much more efficient bus interface than either a '386 or an '020, but also supports lots more memory options. For example, the 68030 can fetch on longword every 2 clocks, which is every 80ns for a 25MHz part. Using burst mode with plain old nybble-mode DRAM (such as GVP's memory card), you can achieve the same thing, on paper -- 4 longwords in 8 clock cycles. If that's all there was to it, you'd have no need for any secondary cache; cache only makes sense when you're running with main memory wait states, at least until you get to multiprocessor systems. >I will put the question to all listening out there : Where are the boards with >Cache? As I mentioned, cache isn't yet the primary concern. But there's at least one system out there that will support it, should it become important enough for someone to work on. Truthfully, without a bit of research on the subject, there's some question how much a secondary cache will actually help things. Especially if it's the rather primitive direct mapped write through variety used on most of the PClones. >Where are the REAL specs? Who's currently shipping 68030 systems? I know of C-A, GVP, and whomever's currently selling the Ronin board. I've read all the details on the GVP memory system, we've discussed the details of that and the A2630 here on the net. >There's plenty of memory management variations on high-speed projects, (page-mode, >interleaving, write-back cache, write-thru cache) but I don't see this information >an any 3rd-party advertising. I'm no marketroid, but that doesn't surprise me. As an engineer, I wouldn't mind hearing of the details of these things. Benchmarks aren't a bad thing to publish, since most people can handle a number or two. But most of the people buying these things are not hardware engineers. Trying to explain the low-level differences and tradeoffs between burst fetching, memory interleave, SCRAMs, secondary caches, the effect of memory speed, etc. is simply going to confuse the vast majority of people out there. Not only that, anyone publishing gads of technical details in their ads are very likely trying to impress their customers with lots of powerful sounding technoid stuff that may not amount to a hill of beans. Every add ever written is desigend to make US sound good and THEM sound bad, wherever applicable. If you want technical details, benchmark results, etc. on Amiga systems, you don't count on ads, anymore than you should count on ads for PClones. You read reviews, lots of them. And comparisons. You _research_ before you buy, no matter what you're buying. If you don't, you'll only be lucky if you get what you really want. >And I don't want to hear that the 68030's on-chip cache is sufficient, it's not. Sufficient for what?!? The 68030 caches aren't large, but when they hit, the 68030 is going faster any any '386 every _dreamed_ of going. You are getting simultaneous fetch of instruction and data when both caches hit, each of which is faster than the '386 can fetch from any external primary cache. >We're paying big bucks for speedup boards now that could buy us 386's with >more efficient design. Anybody care to comment? While I agree that seconday cache would be a nice thing to have, and I'll most likely buy a cache board for my A2500/30 should anyone offer one, I think that statement is silly. You're overly concerned about technical details. Only a couple of things really matter: [1] Does it do what I want [2] Is it the best tradeoff of bang/buck vs. reliability out of the set of [1]. Market pressures and the Intel vs. Motorola architecture have pushed the Intel-based machines in one direction, the Motorola-based machines in another. >-Dallas "Down with Wait States" Hodgson -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough
daveh@cbmvax.commodore.com (Dave Haynie) (02/22/90)
In article <100149@convex.convex.com> swarren@convex.com (Steve Warren) writes: >In article <19411@grebyn.com> allen@grebyn.UUCP (Allen Farrington) writes: >>The bottom line is that any SYSTEM which does not use a cache will be >>limited to about 14MHz (70nS DRAM) memory execution. Beware of >Well, Hitachi has come out with 1 Mbit DRAMs with a 35 ns access time >and 70 ns cycle time. This would allow a zero-wait-state daughter-card >to be designed for the 2630 without resorting to any fancy gymnastics. That might would just do it, though with buffer delays even that could result in a required wait state without some interleaving. >There is no RAS or CAS on these chips. The addr bus is not multiplexed. >They have a static column mode and come in 1M X 1 & 256K X 4. I heard about this approach some time ago, but haven't seen any data sheets yet. But static column mode? I suppose that would imply these guys actually latch the internal row address on a CS* like input, but allow the internal column address to be statically varied. But if normal access time is 35ns, what's static column likely to be? >--Steve -- Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: hazy BIX: hazy Too much of everything is just enough