Re: [N8VEM-S100:974] i960 / V96BMC ~BLAST timing

[mike <mi...@pikeaero.com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, looking at the basic access timing diagram in the V96BMC diagram
they show the ~BLAST signal remaining low for the duration of the
transaction whereas the i960 shows it rising after one PCLK. I would
be willing to bet that the V96BMC does not care about the rising edge,
and that it's just sampling at the second PCLK following the start of
the transaction. I bet for the 386 you could just tie it to ground to
run in basic access mode.

- --Mike

On 07/16/2012 03:06 AM, Mike Sharkey wrote:
> Hmmm...I wonder if the B96BMC would be happy if you just left
> ~BLAST asserted (i.e. tied to ground) in the case of the 386? Or
> does it need to see it rise at some point? I would think perhaps
> not.
> 
> --MIke
> 
> On 07/16/2012 02:59 AM, mike wrote:
> 
> 
>> So looking at the i960 datasheet and the V96BMC datasheet timing
>>  diagram, it appears that ~BLAST should be asserted before the 
>> rising edge of the second PCLK. I understand the first PCLK to
>> be the rising edge following the assertion of ~ADS.
> 
>> In any case I think the critical timing is that ~BLAST is
>> asserted before the second PCLK rising edge in order to indicate
>> that is is not a burst mode transaction.
> 
>> -Mike
> 
>> On 07/16/2012 02:00 AM, mike wrote:
> 
> 
>>> Since the V96BMC was designed specifically for the i960 
>>> processor, it might be worthwhile to get the documents for
>>> that processor and study the burst mode vs non-burst mode
>>> transactions to determine the proper signal timing
>>> relationships.
> 
>>> --Mike
> 
> 
>>> On 07/16/2012 01:50 AM, mike wrote:
> 
> 
>>>> Actually the basic access timing diagram in the one document
>>>>  shows ~BLAST falling at the rising edge of the first PCLK
>>>> and the other shows at the first falling edge, so maybe PCLK
>>>> is not the right reference, perhaps it's relative to ~ADS?
> 
>>>> In any case, it looks like the idea is that you assert ~BLAST
>>>>  shortly after the beginning of the transaction cycle, and
>>>> that indicates that it is basic access I think.
> 
>>>> --Mike
> 
>>>> On 07/16/2012 01:33 AM, mike wrote:
> 
> 
>>>>> My understanding is that the device is capable of doing
>>>>> burst mode or basic access mode.
> 
>>>>> If you look at the timing diagrams that show basic timing
>>>>> vs burst mode timing it looks like to do basic timing you 
>>>>> would have to come up with something that would simulate 
>>>>> ~BLAST on the first falling PCLK at the start of a read or 
>>>>> write since I don't think the 386 has a BLAST signal (i.e. 
>>>>> does not have a burst mode).
> 
>>>>> Don't take that to the bank, but that's my take on it so 
>>>>> far.
> 
>>>>> --Mike
> 
>>>>> On 07/16/2012 01:11 AM, John Monahan wrote:
> 
>>>>>> It looks like it only does "Burst mode refresh".  Can
>>>>>> this refresh mode be done with the 80386.   Are special
>>>>>> DRAM chips required. John
> 
> 
>>>>>> John Monahan Ph.D e-mail: mon...@vitasoft.org Text: 
>>>>>> mon...@txt.att.net
> 
> 
>>>>>> -----Original Message----- From: 
>>>>>> n8vem...@googlegroups.com 
>>>>>> [mailto:n8vem...@googlegroups.com] On Behalf Of mike 
>>>>>> Sent: Sunday, July 15, 2012 8:47 PM Cc: 
>>>>>> n8vem...@googlegroups.com Subject: [N8VEM-S100:962] 
>>>>>> V96BMC-33LP - More documents
> 
> 
>>>>>> More documents on the V96BMC chip.
> 
>>>>>> There is one document that covers programming the plain 
>>>>>> V96BMC (not Rev-D) so only appear to be capable of
>>>>>> driving 256MB DRAMs but should be pretty similar. I'll
>>>>>> continue to see if I can find the programming data for
>>>>>> Rev-D.
> 
>>>>>> --Mike
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQA77LAAoJEA7EcEr0emgfEPcIALfuiSdnaXD+kJJRc0WIqHKS
FaYHijJzgjpXZHKaE/oKJLE+lYChYdf/5cbsCBmm1ugWqZ74JKsqIqcaUJQQcMUo
OZKvmM74b4SgCPFTFmVfpqr10ItEPlp6QppF6yxuXOuZS+6+UZQZoXnj0nIkJRDV
cNJBh/kAuX+bQsXtXruPvRgHmooMLRfcb4KHO2uBtHi3kmzbFFjJydY3nPpycfgp
vlGQf67yJk5N1yB4FvoFjsUvcBkoAqZyzx8Dgc5cuodUmaM55KSIKynf51UJ5AHL
PW1o0ZLFKGgBnrZpd+a1lgnH8/lKkmy7ZDB0z74Z0kT54avPfFDHpFSgMHxbd9Q=
=8LXr
-----END PGP SIGNATURE-----