Is Pseudo-Sync the same as "asynchronous mode"?

Discussion in 'IBM' started by Anon, Sep 12, 2004.

  1. I already explained... at the end... meaning I'd missed the EDO/SDRAM dual
    capability of the chipset... and the existence of the Soyo (previously
    M-Tech) mbrd which implemented both socket styles. The "asynchronous
    memory" post was a red herring in the context of
    synchronous/pseudo-synchronous FSB:pCI ratios. So I got hooked??:)
    See Dave's post.
    35-40ns EDO memory would probably be about what you'd need to operate at a
    FSB of 100MHz without an excessive number of wait states on the (100MHz)
    memory controller strobes and "dead" FSB clock periods. FPM/EDO was rated
    by acccess time delay from RAS#, i.e. tRAC... not by clock cycles.
    I'd suggest you read up on it a bit more - docs are probably still
    available.. and no 60ns FPM/EDO did not have an effective 16.7MHz - the
    66MHz FSB was a match.

    SDRAM was "better" because it spec'd reference clocks for the memory,
    eventually 4 per DIMM, and did away with much of the morass of delay,
    setup, transition and hold times which had to spec'd between the memory
    controller and the memory chips.. and because it implemented a command
    based access structure which was much more amenable to pipelined and burst
    accessing.
    What was being discussed, "the one here", was the relative FSB:pCI clocking
    schemes available from various chipset mfrs, in particular synchronous,
    pseudo-synchronous and asynchronous. Seems you somehow missed that with
    the "asynchronous memory" canard.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
     
    George Macdonald, Sep 18, 2004
    #21
    1. Advertisements

  2. Anon

    Franc Zabkar Guest

    Why should anyone care? The only thing that should matter in Usenet is
    one's written word, not one's reputation, whatever that may be.
    IMO, people should avoid sending large attachments via email for that
    very reason.

    - Franc Zabkar
     
    Franc Zabkar, Sep 18, 2004
    #22
    1. Advertisements

  3. Could be. It's just not wise to 'titter' about someone else being wrong
    when they were right. Kinda keeps the mistake 'alive', as CBS is learning.

    I *am* 'Dave'.

    "Without an excessive number." That's just arm waving.

    Try doing some simple math: like invert 60ns.

    I'd point out that 66MHz FSB wasn't a 'match' but after your arm waving
    about "excessive number" your version of 'match' could mean anything.

    That 'burst' processing and reduced delays you speak of are because the
    stuff streams at 15ns instead of 60ns read access times.

    What you missed is that asynchronous is not dependent on there being ANY
    clocks, as I said in the first post and again just above, nor is it
    dependent on busses, or memory, or anything else. Asynchronous is asynchronous.
     
    David Maynard, Sep 18, 2004
    #23
  4. What part of "red herring" is it you don't understand? Tom doesn't need me
    to blacken his reputation.
    <snigger> Did your server not pick up David Wang's post? Read it in detail
    - Google if necessary. Hint: don't argue with David - it'll be an uphill
    fight which you will certainly lose.:)

    Note: SDRAM does not have a "10ns access rate". It's just a single clock
    cycle of a 100MHz SDRAM clock.
    Read the last sentence above again!... "FPM/EDO was rated......."
    "Excessive" would be more wait states than a 60ns EDO DRAM needs with a
    66MHz FSB bus... which would be just a waste of the enhanced 100MHz FSB
    speed. There is, of course, more to it than just wait states... in the
    timing tolerances.
    That's not how it works. Clearly you do not know how EDO DRAM works nor
    what the 60ns means. Again, read D. Wang's post and the above referenced
    sentence - the 60ns is the time for a complete random access, tRAC,
    including RAS# and CAS#**. In contrast, the 10ns of a 100MHz SDRAM clock
    is just one event in a series (usually 5 or 6) required for the same random
    access.

    **Note that tRAC is the delay from RAS# till data is output on the bus. A
    complete cycle is much longer: tRC, the time between successive RAS# is
    ~100ns.
    Once you've digested how FPM/EDO DRAM is rated... all will be clear.:)
    Nope - apples 'n' oranges. EDO rated at 60ns "streams" at ~25ns per access
    (with pipelining) and of course did not have a burst mode so requires a
    fresh CAS# for each open page access. In fact early SDRAMs did not
    effectively operate any faster, apart from the added advantage of bursting
    - they had only two banks and the chipsets did not manage the interleaving
    properly... in fact some (most ?) early SDRAM chipsets worked only with
    auto-precharge on every access.
    "Asynchronous" can mean different things to different people in different
    situations. I'm afraid you're just ill-equipped for this discussion.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
     
    George Macdonald, Sep 19, 2004
    #24
  5. I understand "red herring" just fine. But your mixing of what you claim was
    someone's 'red herring' (someone bringing up async RAM) with
    unsubstantiated ad hominens is pure illogic.

    But whether it was a 'red herring', or not, doesn't alter the fact you
    claimed "The MVP3 did *NOT* support "asynchronous"... clocking of any kind"
    nor does it suddenly make that incorrect declaration somehow 'correct'.
    How silly of me to not know that there's only one "Dave" in the world. I
    guess I missed that memo.

    After setup SDRAM streams at 100Mhz, which is a 10ns clock cycle and the
    rate for each subsequent access in the data set to keep up with the stream.
    You didn't originally say anything about "in order to have equal wait
    cycles as 60ns FPM on a 66MHz Bus" as the definition of "respond to a
    100MHz FSB pass-through rate," which is still arbitrary arm waving

    It was the motherboard cache, when included, that 'matched' the 66Mhz FSB
    and the purpose of it.
    You never put anything 'clear'.
    Of course.
    SDRAM streams at that 10ns at 100Mhz.

    I.E. The initial setup requires more than one clock. After that each bus
    wide set comes in 10ns increments.
    What you're apparently calling a 'complete cycle' is actually a stream
    burst of multiple reads.
    Try mulling over the purpose of motherboard cache for a while.

    Speaking of apples and oranges, nice try at arbitrarily switching from from
    FPM to EDO. Even so, you will note that ~25ns is not 15.
    A lot of smoke to hide the fact that the topic *was* the SDRAM burst rate,
    which is the bus clock rate. The thing you dismiss with 'apart from'.

    All of which has been an even bigger smoke screen to cover up the fact you
    were incorrect when you said "the MVP3 chipset did *NOT* support
    'asynchronous' ... clocking of any kind.
    Even if true you covered that 'diversity' well, and incorrectly, with "does
    not support asynchronous of any kind."
    Throwing ad hominems accomplishes nothing.
     
    David Maynard, Sep 19, 2004
    #25
  6. The confusion comes from it being 'converted', if you will, from
    asynchronous, at the RAM, to synchronous by the chipset.

    Yes, I misspoke.
    Yes, except that FPM/EDO is simply holding the Row Address so the chipset
    'can' do subsequent reads without that delay, if the data is in that range.
    The chipset 'can', then, do multiple reads, setting the column address, as
    in a 'stream' but it is not required to (by the RAM) nor are the column
    addresses required to be in any particular order (beyond the dictates of
    practicality). Of course, doing a stream 'makes sense' but the async RAM
    doesn't care; it's a function of the chipset design.

    With SDRAM, however, the stream (burst mode) is inherent to the RAM itself,
    not just good sense, with each subsequent data set in the stream implicit
    and internally incremented (synchronous with the clock) by the SDRAM.

    The more significant difference, in the context of async vs sync, is that
    SDRAM does not look to the edges of multiple 'strobe' signals for timing.
    All timing comes from the clock edges. e.g. addresses are not latched, I.E.
    'clocked', by CAS and RAS, as with async RAM, they're latched on clock
    edges. All timing comes directly from the clock (which does not even exist
    on the async RAM bus) and therein lies the 'synchronous' nature of it.

    Now, one might argue that all those 'async' strobe signals generated by the
    chipset are traceable to the chipset clock and so, in some manner,
    'synchronous' with it but that's talking about the nature of the chipset;
    not the async RAM. I.E. the async RAM doesn't care if the strobes come from
    a 'clocked' chipset or a bank of one-shots, as long as they meet the setup
    and hold times, but you aren't going to get squat out of SDRAM without the
    clock that all it's internal timing is derived in synchrony with.
    I'll add that to my list of Zen quotes ;)
     
    David Maynard, Sep 19, 2004
    #26
  7. Anon

    keith Guest

    I can't help it if you can't understand how wrong you are. The databases
    have been purged, so I no longer have access to the original information.
    It's only been five and a half years since I worked in x86.
    The original SP97s were either pseudo-sync or async (now you have me
    thinking), though async was more in the SiS style. ...and I wouldn't have
    spent so much time on the SP97-V if it were pseudo-sync.

    Read the sentence again. I was talking about the "yndreds of boards"
    here, not specifically the SP97. Slow down, kid.
    I didn't use the K6 on that board. Since the K6 was only specified for a
    66MHz bus, it's not surprising that it would be unstable in psuedo-sync
    (75MHz) operation. The M2 was quite happy with the 5598 at 75MHz, though.
    Read the datasheets. Via coined the term, meanwhile SiS was busy doing
    async.
     
    keith, Sep 19, 2004
    #27
  8. Anon

    keith Guest

    Ah, so you openly admit that you haven't a clue what you're talking about.
    Before you ask, yes in a previous job I had datasheets to everyting that
    was going into PCs (most marked &company. Confidential). You really
    should talk like a god, if you're a lesser mortal.
    On the contrary, there were many boards that supported 2.5x clocking (and
    async PCI). Apparently the clock-gens were difficult to come by at
    times though, since board manufacturers did slip in other clock chips
    from time to time. We went through *every* socket-7 board (even though
    some were identical, we had them all) looking for those that supported
    75Mhz and 83MHz. Over-clocking the PCI bus (or anything else) was an
    automatic failure, and wasn't listed as supporting that frequency.
    You dislike yourself that much?
    Ah, so you really don't care about the facts. Not that I ever suspected
    anythign else.
    ....a likely violation of copyright.
     
    keith, Sep 19, 2004
    #28
  9. Anon

    keith Guest

    There are a lot of web sites out there that are wrong. Just because you
    read it...
    It means litterally, without clock. Practically it means an interface
    that isn't clocked - crosses a clock domain that is not synchronized. Two
    oscillators implies not-synchronized (a little more complicated, but...).

    I'd say that's a good analysis of the situation. Note that pseudo-sync
    *is* really synchronous, with a non-integral relationship beteen the
    domains. Syncronous interfaces (integral multipliers, or not) avoid many
    pitfalls of asynchronous interfaces. Though there are many asynchronous
    interfaces in a typical PC.
     
    keith, Sep 19, 2004
    #29
  10. Anon

    Franc Zabkar Guest

    I could care less about your mythical databases or other pathetic
    attempts at obfuscation. You had *several* opportunities to present
    the evidence that you claimed was in your hands. All you had to do was
    to identify the part number(s) of the clock chip(s). The fact that you
    avoided doing so speaks volumes for your character, or lack thereof.


    - Franc Zabkar
     
    Franc Zabkar, Sep 20, 2004
    #30
  11. Did you read Tom's article? It's rubbish and does not reflect how the MVP3
    chipset worked at all.... WebJunk!
    While the discussion was diverted from its original theme, on further
    consideration, I stand by what I said. The MVP3 does not support
    "asynchronous", VIA makes no mention of such and in fact says quite
    explicitly that the DRAM "uses CPU clock" or uses AGP clock". The fact
    that you want to include FPM/EDO memory as an "asynchronous" mode of
    operation is irrelevant to the discussion... other than your desire to have
    a fight... again... based on some picayune premise.
    Yes - within limits of persistent ability to burst data... which can be
    derailed by several different situations and events. It is not an "access
    rate".
    I presumed you were sufficiently informed on the history of normal
    operation of FSB relative to DRAM channel speeds - apparently not, which is
    precisely why you make the accusation of "arm waving"? 60ns EDO DRAM was
    what was used with 66MHz FSB systems... it matched... e.g., a 50ns EDO DRAM
    would not have brought any improvement.
    You implied you thought you knew how DRAM works.
    Beyond a single burst length of 2, 4 or 8 words, that ideal world can get
    upset by several different events, depending on the chipset
    capability/strategy to manage open pages... and memory access patterns -
    pointer chasing being a prime example.
    No - I thought I was quite explicit: tRC = the min time between successive
    random access reads (from RAS# active, followed by CAS# active, to the next
    RAS# active). For FPM/EDO I'd consider a "stream burst" as RAS# followed
    by several consecutive CAS#'s.
    What?... another red herring?:-[]
    Huh? The point was that the SDRAM period for intraburst data transfers of
    15ns (16.7ns ?) is not comparable to the time for a full RAS#+CAS# FPM/EDO
    access.... and where did we focus on FPM exclusively? I've tried to
    mention both where applicable and EDO only where applicable. Suggesting
    some devious intent is simply churlish.
    The err, "topic" was that you were mistakenly comparing a full random
    access time for FPM/EDO with SDRAM intraburst data transfers. I did not
    dismiss anything - SDRAM added bursting, and some new restrictions, to the
    pipelining of EDO.
    Nope read the MVP3 data sheets and then read Tom's article again - it's
    crap. And forget the "ansynchronous" FPM/EDO DRAM as an excuse here - as
    Dave Wang has pointed out, the memory controller runs off a clock (FSB or
    AGP for the MVP3); the fact that FPM/EDO could be considered a *somewhat*
    asynchronous *device* is irrelevant to the fact that, in any system
    implementation, it effectively operates in lock step with the memory
    controller clock.
    .... which is, in fact, true!
    No ad hominems. It seems that you finally took (some of) the advice to get
    better informed.

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
     
    George Macdonald, Sep 20, 2004
    #31
  12. Anon

    chrisv Guest

    Why don't you cross-post to a few more groups, you idiot?
     
    chrisv, Sep 20, 2004
    #32
  13. Anon

    Anon Guest

    All those newsgroups were relevant. If I'd have wanted a bunch of
    arrogant bastards replying to my post then I would have posted to a
    newsgroup for arrogant bastards, such as comp.os.linux.advocacy a
    newsgroup which you love so much.

    It was extremely amusing reading the number of times you call people
    'idiot' in the elitist newsgroups that you visit like
    rec.music.classical and comp.os.linux.advocacy. Actually, it's
    probably very unfair to label those newsgroups elitist. Perhaps there
    are just small cells of elitists that make all the decent folk look
    bad. Or maybe you're all alone in your little elitist cell!
     
    Anon, Sep 20, 2004
    #33
  14. Anon

    kony Guest

    Yeah, but it's not really appropriate to post to ALL
    "potentially" relevant newsgroups either, since there is a
    lot of overlap that would result in many, many groups
    getting swamped with posts. Try one or two MOST APPROPRIATE
    groups.

    Now onto the main issue, why do you post this?
    Is there a specific problem or do you expect the entire
    world to stop what they're doing and educate you instead of
    bothering to use a search engine?
     
    kony, Sep 20, 2004
    #34
  15. I have read the MPV3 spec sheets.

    http://www.mit.edu/afs/sipb.mit.edu/contrib/doc/specs/ic/bridge/vt82c598.pdf

    The MPV3 chipset supports 1. fully synchronous operation, 2. what VIA calls
    "pseudo-synchronous" PCI (2.5 divisor) and SDRAM (AGP clock) clocking, and
    3. FPM/EDO asynchronous RAM.
    It's not an 'excuse' to call FPM/EDO what it is: asynchronous RAM.
    How 'the memory controller', as you put it, derives it's signals is it's
    own business and irrelevant to the asynchronous FPM/EDO RAM (as long as the
    signals meet timing requirements).

    I.E. One could, if they had a mind to, design a memory controller that
    creates the asynchronous FPM/EDO signals without using any clock, e.g.
    one-shots or whatever creative solution one might devise, and the FPM/EDO
    would be perfectly happy with it. The controller functions themselves might
    suffer but, again, that's a controller issue unrelated to the asynchronous
    FPM/EDO RAM.

    SDRAM will simply not function without the proper clock, that is wholly non
    existent with async FPM/EDO RAM, and you better be in SOME form of
    synchrony with that clock or you aren't going to be able to send commands,
    read data, or anything else.
    FPM/EDO are not 'somewhat' asynchronous devices. The *are* asynchronous
    devices and you will not find any 'synchronizing' clock pin on either of them.

    The memory controller operates from a clock for it's own reasons but there
    is no 'clock' going to FPM/EDO RAM for them to be in 'synchrony' with. They
    operate asynchronously.

    There's a reason why SDRAM is called synchronous and FPM/EDO isn't. Namely,
    because SDRAM is and FPM/EDO isn't.

    Your claim is, in fact, false.
     
    David Maynard, Sep 21, 2004
    #35
  16. Anon

    Anon Guest

    I did use a search engine - the great google, and the results that
    seemed most appropriate were those of toms hardware. Which were very
    unhelpful. Did you know some people are actually happy to have
    information archived to help many others?

    If it were just for education, it would not just be for my education,
    but for the rest of the world since google archives everything. Plus,
    since it archives everything and there was nothing explaining the term
    'asynchronous mode', on usenet or the web, that I could find, I feel
    that WE are all doing a great service to the world, moreso those gerat
    people like keith frank george and dave M and dave W that respond with
    answers or questions or debate on the topic (not you kony of course).
    Infact, if you look at archives and study my post. You will see that I
    spent a lot of time going through earlier posts which included reading
    posts from people that performed the same crime as me, posting a
    question on usenet. Those questions and the responses were extremely
    helpful and benefit people till the end of time. Infact some of the
    posters that posted a similar question in earlier years did not
    research previous answers as much as I did. Their crime was and is
    helping future posters. And my crime is theirs.
    I even referenced those posts in my first post. Since I am not asking
    the question just to serve my own purposes, but to help others that
    are interested in years to come. Infact, I even summarised the
    opinions of keith and frank from a long previous thread. I have made a
    great effort to be extremely helpful to people who want to know what
    the term means. I invested a lot of time researching previous posts,
    referencing them, summarising the opinions of authors writing in other
    long threads that were hard to follow since the authors assigned
    different meaning to their terminology and realised/cleared it up at
    the end. And this thread actually answers that 'asynchronous mode'
    question completely, and shows that Toms Hardware was extremely
    unclear and misleading in its implications.

    It is YOU that has not done his research. Had you bothered to read my
    original post, you would have seen that I had done a lot of research
    and made great efforts (as mentioned above) so that my post would help
    others in the future.

    How could I have researched for writing my post, summarised opinions
    from previous posts, without a search engine? Without making thorough
    use of a search engine?
    How can you be so stupid as to think I didn't bother to use a search
    engine???

    How does my crime compare with the crime of earlier posters that
    posted questions about pseudo-sync which were very helpful to me and
    others?

    Why do you think I summarised the research that I had done from
    previous threads, even though that research contained no questions?
    That's a hard question for you to answer, since you don't read posts,
    but the answer is written in this post. I'll give you a hint
    hint: that huge chunk of my post is archived to help others.

    I wonder why you don't always notice when soembody is helping others
    or using search engines. Even when it's blatantly obvious. Perhaps
    it's because these qualities are alien to you.
     
    Anon, Sep 21, 2004
    #36
  17. Anon

    chrisv Guest

    Heh. I always get a kick out of you weirdos who, when offended,
    immediately run-off to google to try to dig-up some "dirt" on the
    other person. In this case, you discovered that I also post in the
    linux advocacy group (which you claim is evidence of my being an
    "elitist"). Wow, I am so ashamed of the fact that I post in the linux
    advocacy group, and that I've used the word "idiot" to describe the
    many trolls that frequent that group. Not.

    It's difficult to not feel superior when surrounded by idiots like
    you. 8)
     
    chrisv, Sep 21, 2004
    #37
  18. Anon

    kony Guest

    On 21 Sep 2004 01:25:17 -0700,
    (Anon) wrote:

    .... or perhaps you go off on a tangent and just assume it's
    a noble cause, ingoring that the end does not always justify
    the means.
     
    kony, Sep 21, 2004
    #38
  19. The data sheet has been in my possession for 6 years, almost to the day,
    and I have studied it in great detail over the years. The word
    "asynchronous" does not appear in it... anywhere. Is this something you've
    made up in the hope it'll slide by? Your feeble attempt above, to make it
    seem like VIA has confirmed your contention, is contemptible. The data
    sheet specifies 8 different clocking schemes for relative bus speeds, 4
    synchronous and 4 pseudo synchronous. In 4, the memory controller runs at
    FSB speed; in the other 4 it runs at AGP speed.
    Yes - it's your excuse... invention or whatever. I havent seen FPM/EDO
    memory called "asynchronous RAM" by any of the memory mfrs or in any data
    sheet anywhere. The chips are asynchronous devices... within certain
    timing margins... but calling them asynchronous RAMs is a stretch by any
    measure.
    What the hell are you talking about: "as I put it" - it's a memory
    controller on the chipset which talks to the DRAMs - it runs off a system
    clock! You need a RAM device which can understand its signal timings &
    margins and respond within certain time constraints.

    "Irrelevant .... as long as" That's a good one.:-[] Nearly as good as you
    trying to argue with Dave Wang... utterly oblivious!
    I think you should try that... even if it makes no bloody sense at all. Do
    report back!
    That clock runs the I/O interface of the SDRAM - uhh, that's what it's for.
    The clock has been basically moved from the FSB+memory controller to
    multiple clocks on the modules and ultimately to the chip interfaces. Uhh,
    statement of the obvious is not changing your case.
    They are not fully asynchronous. They function within certain expected
    timing margins. They are designed to work and respond according to the
    expected speed usage within a narrow margin. You can't just throw signals
    at them at any rate you feel like and expect them to work.
    I never said there was a clock to the chips. Why do you insist on stating
    the obvious? The memory controller does not have its "own reasons" - it's
    interfacing to a system of AGP, PCI and FSB buses. The memory has to be
    capable of working in concert with it.

    As usual you have started from a position of ignorance and folksy
    self-invented ideas. Then you have set out to defend this madness by
    reading data sheets and fitting their facts into your weird framework. You
    could have the honesty to acknowledge where you were wrong, instead of
    which you make statements which are elementary knowledge of DRAM operation
    as though it somehow elevates your position. I've had enough of this.

    If you feel that TomsHardware enriches your pool of knowledge, that's your
    problem. I think we're done here!

    Rgds, George Macdonald

    "Just because they're paranoid doesn't mean you're not psychotic" - Who, me??
     
    George Macdonald, Sep 22, 2004
    #39
  20. There's no need for someone to 'explain' in their spec sheets what type of
    memory EDO/FPM is as it's not an electronics training course; it's a
    specification for their chipset.

    The point was the chipset supports it.
    Made up? The specs are on the mit.edu site.
    Yes, and the support of EDO/FPM async memory.
    Well, one won't see unless they look.

    http://www.crucial.com/library/sfiles2.asp

    "Both FPM and EDO are said to be asynchronous. In other words, the memory
    and the system clock are not synchronized."
    Then you're the only one who doesn't know that FPM/EDO RAM is asynchronous.

    http://www.crucial.com/library/sfiles2.asp

    "Both FPM and EDO are said to be asynchronous. In other words, the memory
    and the system clock are not synchronized."
    It's rather the other way around: the memory controller is designed to
    operate with the RAM it 'supports'.
    And accurate. Obviously the controller must operate properly with the RAM
    it 'supports' (the "as long as" part) but the 'nature' of the RAM is not
    'dependent' on the memory controller (the "irrelevant" part) or else we'd
    have RAM sticks spontaneously changing their 'type' every time someone
    creatively engineered a new memory solution.

    I.E. "What kind of RAM is that stick? Gee, I dunno. Yesterday it was async
    but Bob over there is designing a new memory controller so..."
    You apparently didn't understand that conversation either.

    Piece of cake, actually. Did one once a looooong time ago to emulate the
    front panel memory read/store switches typical on old minicomputers.
    And everything inside.
    And why it's called synchronous.
    It doesn't exist on FPM/EDO memory busses because they're asynchronous.
    There's no place for it to go and nothing for it to 'synchronize'.
    I know it's obvious, which is why you're inability to grasp it is such a
    mystery.

    There's no need to argue this one because whether it is 'fully'
    asynchronous, whatever you think that means, isn't necessary as you've
    admitted it falls within 'any kind' of asynchronous.

    I didn't say you did. I'm pointing it out to help you understand it.
    Because you keep having problems understanding it.
    One could, if they felt the need, talk to both the PCI and AGP busses
    asynchronously too but doing clock divisions happens to be a convenient
    means, which is the chipset's 'own reason' for it.

    Or, faced with the normal synchronous means being problematic with 83 Mhz
    FSB processors, one could, as VIA did, devise a "pseudo-synchronous"
    mechanism. The 'nature' of the busses, however, did not change. In fact,
    the new means was dictated by a desire to keep them in spec and was that
    chipset's 'own reason' for it.

    No, the memory controller has to be able to operate the RAM type it
    'supports' but I can use the RAM in anything I like. It is a device with
    it's own specifications and doesn't 'depend' on the memory controller for
    it's 'nature', or what 'type' it is. I could interface FPM/EDO to a simple
    microprocessor that has no 'memory controller' at all, or use it in
    something that's not even a 'computer'.
    All you're doing is making a fool of yourself by thinking the throwing of
    insults constitutes a technical case.
    Yes, and we might as well let Crucial-Micron sum it up.

    http://www.crucial.com/library/sfiles2.asp

    "Both FPM and EDO are said to be asynchronous. In other words, the memory
    and the system clock are not synchronized."
     
    David Maynard, Sep 22, 2004
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.