Mail Archives: geda-user/2011/11/29/01:49:31
On Mon, Nov 28, 2011 at 10:39 PM, Vanessa Ezekowitz
<vanessaezekowitz AT gmail DOT com> wrote:
> On Mon, 28 Nov 2011 19:18:08 -0600
> John Griessen <john AT ecosensory DOT com> wrote:
>
>> On 11/28/2011 02:07 PM, Vanessa Ezekowitz wrote:
>> > after a week of wrangling with this, I finally turned out a working
>> > design - or at least, it simulates (iverilog + gtkwave)*and* Â synthesizes
>> > properly
>>
>> Hey, you did it!
>> Looks like dotclock is a sequence you create after being triggered so as to
>> put out some stored values, right? and that sequence is done with #delay
>> statements. (it's been 20 years since I was doing this daily to make iic
>> ports, serial ports, etc...)
>>
>> John
>
> Actually, you're pretty close to what I was originally trying to do. Â The RAM controller chip used in C64 (of course) RAM Expansion Modules only produces enough signals during refresh to handle the 256k x 1 RAMs the use, and in RAS-Only refresh mode at that.
>
> So I had to detect those RAS-Only refresh signals and replace them with CAS-before-RAS pulses. Â I originally tried to use a state machine driven by the dot clock, until I realized the 22v10's flip-flops are all clocked by the same line... Â so a state machine was out.
>
> I worked out that, assuming my testbench model is accurate, I could use the dot clock to directly drive the RAS output line as long as I pulled all of the CAS lines low first, and as long as I provided it in inverted form. Â Since the 22v10 can't invert the clock line, I had to loop it through the chip and invert it that way.
>
> The truly sad thing is the test bench is more complicated than the code it drives. :-)
>
Don't feel badly about that, it is pretty typical for the testbench to
be larger than the code it tests.
- Raw text -