Project: Digital Fuel Injector Pulse Width Analyzer

[ElEctric_EyE]

Finished wiring it up yesterday. What a breeze! Took me about 7 hours. Fired it up, no smoke or heat, heh . ISE rec'd the Spartan 2 and successfully programmed it. Stage 1 complete!

Stage 2, which I'm working on now, forces all the upper banking addresses low. So I have to temp remove all the opcode detecting hardware (not tested yet). Also, I have abit of reworking to do softwarewise, because the last iteration used an 8K EEPROM for the software, and a separate 512K EEPROM for character fonts, strings, etc.. This version uses 1 512K EEPROM for everything. Not to mention the Display is a little different...

I must say working with FPGA's/CPLD's is very enjoyable and rewarding. All one must have is a general idea of what to accomplish. Heck, looking back, using a 144-pin or 208-pin FPGA would allow you to hook up all the 6502's outputs and inputs, throw in a "few" 2Mx8 SRAM's an EEPROM, and you could have a system you could develop without having to rewire a thing!

The 2M SRAM address decoding is done in such away that when $0000-$3FFF is on the address bus, the SRAM sees all zero's on A14-A20. When $C000-$FFFF is present, A14-A20 are all one's. The SRAM does not see the SRAM Bank register in these cases. This preserves zero page, and a good chunk of RAM for registers etc., and the OS/interrupt/reset vectors. Here are my memory maps:

[BigDumbDinosaur]

Nice graphics. They are so clear even a big dumb dinosaur can understand them.

[ElEctric_EyE]

Been doing alot of reading recently. My last statement about this stuff being easy... Scratch that. I'm getting the feeling FPGA's are a whole other beast. Although, i'm not quite ready to give up on the Spartan II yet. The version I'm using has the potential to have 512bx8 SRAM embedded inside, which will be my last attempt, before I tuck tail and head back to CPLD's.
I'm having problems with what I think is buggy 10.1 ISE software. "think" being the keyword. Repeatability is not consistent... I blame myself for not being more knowledgeable about FPGA's, so I've taken up some reading. Compared to Xilinx' CPLD's, FPGA's can fit much much more in an identical pin package, I'm sure more care has to be taken to follow stricter rules...

Anyway, during my research I came across a subject others have brought up, and I remembered this topic:

kc5tja wrote:

OwenS wrote:

Oh, and the programming information for Xilinx devices is very well documented.

The last I looked, I was completely unable to find documentation on the bitstream format used to program Xilinx's devices. E.g., there is no information with which I could use to enhance Icarus to support synthesis for the newer FPGAs, or to create my own completely new logic design tool...

These links may help. At the very least they'll give you clues how to program FPGA's without ISE software.

The poster wanted to program a Spartan 3 FPGA with a PIC32:
http://forums.xilinx.com/t5/Spartan-Fam ... /m-p/36815 .
In the reply, an appnote was given for the general hookup:
http://www.xilinx.com/support/documenta ... app502.pdf

The Spartan II Family FPGA Data Sheet on page 15 talks about "Bit Sequence" & BSDL:
http://www.xilinx.com/support/documenta ... /ds001.pdf

http://www.xilinx.com/isp/bsdl/bsdl.htm

[ElEctric_EyE]

I hit a wall, so I am taking a temporary time-out to regroup and then attack from a different position. Tomorrow, I test. I suspect the display has issues... I could be wrong, we shall see....

Also, the main 80MHz oscillator I was powering @5V. According to the datasheet ( http://www.ecsxtal.com/store/pdf/ecs_2200.pdf ) it is capable of running at an optional 3.3V. I don't think this is an issue though as the Spartan II is auto-configured for LVTTL and is 5V input compatible.

Using schematic entry on ISE10.1 to program the Spartan II, has been a challenge. I'll leave it at that. I make progress now by saving files. Files made from scratch, and if they succeed I save them in the next "Chapter" on another computer... I am up to a chapter now that successfully manipulates /6502Reset, Phase 2 (fast, and slow), & EEPROM/SRAM /CS's & /OE's. I am also getting an active low signal to the display from the FPGA, still nothing is happening to init the display. I have been regretfully reduced to starting from scratch at this point. (This is a 1 step back, 2 step forward point...)

So during my time-out, I've been re-looking at some Maxim IC's for generating square wave frequencies for the WDC65C02 and the 16-bit pulse width counters. I say "re-looking" because I brought it up last year on page 3 of this thread, and I've learned alot thanks to this site, and now feel qualified enough to make a "re-educated" choice: The 1 that stands out is the Maxim DS1085L: ( http://www.maxim-ic.com/datasheet/index.mvp/id/3495 ). 8-pin SOIC, 3.3V device: 2 outputs, 1 from 4MHz to 66MHz (good for CPU), and the other output from 4.2kHz to 66MHz in 5kHz steps. Now that is some resolution! I'll have to learn the serial I2C interface though...

Speaking of serial, I am also looking forward to interfacing a PS/2 mini-keyboard thanks to ChuckT here ( viewtopic.php?t=1601 ). Many thanks to Daryl ( http://sbc.rictor.org/ ) who "ported" his version from an Atmel ATTiny26 to an ATTiny24, which my Genius G540 programmer can burn. ATTiny24 is <$3US. It is on my "top-shelf" of priorities after my display problem is figured out.

Also, thanks to Garth, Dr. Jeffyl, BDD, & BigEd. And Andre for starting his thread which I learned alot: viewtopic.php?t=1617&postdays=0&postorder=asc&start=0

[fachat]

ElEctric_EyE wrote:

I'm having problems with what I think is buggy 10.1 ISE software. "think" being the keyword. Repeatability is not consistent...

Not sure if that helps, but I had such problems even with CPLD, and occasionally had to do a clean build. You can do this by going in the menu to "Project" -> "Cleanup project files".

André

[Dr Jefyll]

(cross-thread from the "oscilloscope as a Logic Analyzer" topic:)

ElEctric_EyE wrote:

I tried to jump ahead and do the EEPROM to SRAM copy @1.25MHz and run the system @5MHz. SYNC went dead after the SRAM was enabled and the CPU reset meaning either: 1) I am not giving the software enough time to copy $C000-$FFFF from EEPROM to SRAM, (unlikely) or 2) There is a problem with the bank switching hardware controlling addresses to the SRAM. Since I am using zero page for indirect indexed to copy 16K, the bank hardware is constantly flipping from upper 16K, where the copy program resides, to the lower 16K where zero page is...

Before I do tackle this problem however, I think I should focus back onto initializing the display, which is just LDA/STA, running from the EEPROM @1.25MHz.

Garth I used to use a '374 as a test port as well for an initial test to make sure everything was wired correctly etc. on my first iteration of the PWA. I actually did think of trying to put it inside the FPGA, but never got around to it... Testing SYNC seems to be an even more "bare bones" approach to initial startup, because you're testing right at the CPU itself.

SYNC went dead after the SRAM was enabled? If there's no activity on SYNC then the cpu simply isn't running. It may have somehow executed a WAI or STP (Wait or Stop -- new WDC instructions). That wasn't your intention but if the system has crashed for some reason, it'll end up executing garbage (data, inappropriate code or the contents of uninitialized memory). Running amok that way it may have swallowed a WAI or STP op-code, and that would squelch the signal on SYNC.

Another possibility is that the cpu has lost its clock signal or some other basic requirement. Hence no SYNC. Is the Phase2 signal OK? Isn't your clock mux associated with the same reset logic that enables the SRAM? Smells like a clue to me... Trouble with the mux? I could be wrong...

Quote:

I think I should focus back onto initializing the display, which is just LDA/STA, running from the EEPROM @1.25MHz.

Probably a good idea. There's no need to go beyond 1.25 MHz at present. And the EEPROM to SRAM copy is kinduva handful -- lots that could go wrong.

Is the schematic on page 11 of this thread still current with respect to the Reset logic and clock mux?

-- Jeff

[kc5tja]

ElEctric_EyE wrote:

These links may help. At the very least they'll give you clues how to program FPGA's without ISE software.

Unfortunately, no -- the information contained in those documents are completely insufficient to write a synthesis tool of my own. The data provided covers only barely how to make a programmer for the chip (I still consider it insufficient; I would never trust myself to make a programmer with the datasheets alone).

[ElEctric_EyE]

Dr Jefyll wrote:

...Is the schematic on page 11 of this thread still current with respect to the Reset logic and clock mux?-- Jeff

The basic idea is still there using a 4-bit counter to manipulate the CPU/Reset, EEPROM/OE, and SRAM/OE. The counter is running 80MHz/65536/4096 @.29Hz. I've had to mod the original to be more inline with FPGA rules. This is from the latest schematic.



4 seconds plenty of time to copy 16K @1.25 MHz yes?

[BigDumbDinosaur]

Dr Jefyll wrote:

(cross-thread from the "oscilloscope as a Logic Analyzer" topic:)

ElEctric_EyE wrote:

I tried to jump ahead and do the EEPROM to SRAM copy @1.25MHz and run the system @5MHz. SYNC went dead after the SRAM was enabled and the CPU reset...

SYNC went dead after the SRAM was enabled? If there's no activity on SYNC then the cpu simply isn't running. It may have somehow executed a WAI or STP (Wait or Stop -- new WDC instructions).

WAI will halt the MPU only until an interrupt is received. I don't recall from following this thread if he has something in the system that generates an IRQ.

STP, on the other hand, means stop, and only a reset can clear it.

[Dr Jefyll]

Talking about Clock issues in my last post reminded me of something I noticed in the logic diagram. Your new version shows it too:

Code: Select all

Broken external image link
http://www.laughtonelectronics.com/6502PWA.jpg

At issue is the fact your mux select (the signal I call INITIALIZE/RUN) may not be synchronous to the 5MHz and 1.25MHz signals being selected.
In other words, it's possible for the mux to change its selection partway through a cycle -- changing horses in midstream, so to speak.

If luck is with you, the 5MHz and 1.25MHz signals will be in the same state at the instant of changeover, and no glitch results. But otherwise the transition on the mux select will result in a spurious transition on the mux output -- your cpu clock! Although it's a one-time event, the effects of this irregularity on the cpu and on program execution are unpredictable -- and presumably unfavorable. (It might explain what you said: "SYNC went dead after the SRAM was enabled" ie: after INITIALIZE/RUN changed state.)

The alternative I've shown acts as a programmable divide-by-N to generate your 1.25 and 5MHz clocks. As you see, the counter can reload either of two hardwired values, thus determining the output frequency. (I haven't worked out the reload values; they'll depend on FastCkIn.) The key point here is that, no matter when INITIALIZE/RUN changes state, there will be no effect until the next reload of the counter -- ie, until completion of the current divide-by-N cycle.

The JK flip-flop provides a 50:50 duty cycle but, with some fussing, could perhaps be judiciously eliminated.

BTW, note that, even if INITIALIZE/RUN is synchronized to the 1.25 and 5MHz clocks, it'll be difficult to manage propagation delays and get the original circuit to execute a clean changeover.

Finally, dual clock frequencies aren't the only way to allow extra access time for the EEPROM. An alternative would be to make use of the cpu RDY input.

-- Jeff
Afterthought: I just noticed that INITIALIZE/RUN should maybe pass through a D flip-flop (clocked at FastCkIn) before it reaches SEL. A discrete 74xx version of the circuit definitely needs this; inside the PLD, however, the '157 mux probably disappears, optimized away...

[BigDumbDinosaur]

Dr Jefyll wrote:

Talking about Clock issues in my last post reminded me of something I noticed in the logic diagram...At issue is the fact your mux select (the signal I call INITIALIZE/RUN) may not be synchronous to the 5MHz and 1.25MHz signals being selected.

Good call on that one!

[kc5tja]

I haven't been following this thread too closely, but after skimming it, check also the RDY signal too. If it's held low, that also will halt the CPU.

In fact, the WAI instruction works by pulling RDY low via an internal open-drain transistor through a resistor. IRQ, ABORT, and NMI simply releases the flip-flop driving that transistor. This is why the 65816 data sheet (at least the one I have) recommends connecting logic to RDY through an external resistor, to prevent the possibility of an accidental short.

[Dr Jefyll]

kc5tja wrote:

the 65816 data sheet [...] recommends connecting logic to RDY through an external resistor

So, even if RDY is unused, it's not alright simply to tie it high. OK, then! Good to know. RDY is bi-directional.
Edit: Re: the 'C02, WDC's W65C02S also should use a series resistor on RDY, whereas the Rockwell chip (and others?) don't require it -- but it'll do no harm.

BigDumbDinosaur wrote:

WAI will halt the MPU only until an interrupt is received. [...] STP, on the other hand, means stop, and only a reset can clear it.

It's amusing (to me, at least) that, back when the 'C02 was introduced, much was made of the fact that they'd corrected the NMOS chip's vulnerability to certain opcodes that'd cause it to hang: to halt execution.

Now halt (ie STP) is back -- but it's a feature!

[kc5tja]

Haha, yeah. Well, there is value in the opcode in terms of controlling power dissipation.

Of course, for historical purposes, I think they should have called it JAM. ;D

[ElEctric_EyE]

Dr Jefyll wrote:

...it's possible for the mux to change its selection partway through a cycle -- changing horses in midstream, so to speak...

My fault again. I had started a new thread about speeding up the 6502 ~1/3rd? way through this PWA thread, and this very topic came up...

I regretfully deviated from this PWA thread and created a separate one. If you're interested enough in what I was trying to do and want a quick sample, focus on the truth table below the schematic, (the counter wound up being a '163). ( viewtopic.php?t=1503&postdays=0&postorder=asc&start=24 )

This "speeding up" thread explains in more detail what I intended to accomplish. I have been successful with it because I never had the intention to switch the phase 2 during a copy execution cycle, only AFTER the $C000-$FFFF copy was completed and a JMP $xxxx was looping to itself. Then Phase 2 is sped up, cpu is reset, and SRAM /OE enabled.

It was my first iteration using discrete TTL, and I was anxious to keep this PWA thread on it's way to a quick, successful conclusion. This was before my introduction to CPLD's and FPGA's and much has changed...

EDIT: I apologize for all the edits, long day @work... I've been given some valuable troubleshooting techniques to evaluate/troubleshoot. I will update on my days off!