I have an ATF1508 I want to experiment with for a 6502 project. I tried the WinCUPL program and simulator but they are both really buggy and unpleasant to use. I would like to just solder a few LEDs and switches to a board to test on real hardware. Other than the 4 JTAG pins, is there anything I need to break out (OE1, PD1, GCLR, etc)? Does anything else need to be pulled up or down? Unfortunately, the datasheet doesn't have much to say about the other pins. Also, if I want to group together 8 pins in the code, does it matter which 8 I use?

I'm interested in looking at Atmel programmable logic (the 5V FPGAs, not really the CPLDs) but got put off by the software support. It's a shame because it looks like nice hardware.

So no answers, but share your frustration.

_________________
8 bit fun and games: https://www.aslak.net/

Unfortunately, as you guys noted, Atmel's software leaves something to be desired. WinCUPL apparently was little more than a windowized port of the the old DOS program produced by LSI before Atmel bought them out. I have documented numerous bugs and forwarded them to Atmel, but they apparently are tone-deaf about this stuff. Perhaps if enough people complain to them they might be motivated to fix their software. The contact I have there is a gentleman named Alan Wong. His E-mail address is alan.wong@atmel.com. If you contact him don't hesitate to attach the CUPL source file that is causing you grief.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Please have a look at the attached, which is how I have the ATF1508as connected in my yet-to-be-built POC V2. It should answer some of your questions.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Maybe a reverse-engineering effort is called for, presuming that the license terms allow for it? I know that my issue with considering Atmel programmable logic is purely a matter of their software being essentially unusable for me.

Thanks! That clears a few things up. Do you have capacitors on all the various Vcc lines? Also, do you know if the JTAG pins run from VccINT or VccIO? I would like to get away with programming at 3.3v so I don't need a level shifter.

Judging by the error messages it (constantly) pop up, I'm pretty sure it is a Visual Basic (pre .NET of course) application. I know people have worked on decompilers before if you wanted to go that route.

Also, do you have any idea how many resources it would take up to store 20-30 bytes of ROM code in the CPLD? I want to run from an SD card and I hate to waste the board space of an 8k ROM for a few dozen bytes of bootloader code. I could even use one of those 20k EEPROM in TO-92 package for a bootloader if the CPLD can bitbang a few bytes out of it at start up. A 256 byte EEPROM in DIP package would work but I can't find anything under 8k.

I was more thinking "black box". The program apparently produces "bitstream" files or something like that given some logic description as input. Feed in a bunch of test designs, get a bunch of compiled bitstreams, do a bit of a correlation analysis...

If having the CPLD do bit-banging is ok (since you were talking about one in a TO-92), then is the I²C 24cXX family of EEPROMs (all available in 8-pin DIP) ok? It goes all the way down to 16 bytes in the 24C00. The only differences I remember offhand across the entire family are in addressing, where the 24c00, 24c01, and 24c02 have a single address byte, then above that it goes to two address bytes. I have not looked at how the densest ones in the family (128K and 256K bytes) address them. They're not very complicated though. I've used the ones up to 32KB several times. If I²C is too slow, you can use the 93cXX family of Microwire EEPROMs (also in 8-pin DIP). The similar SPI family is 25cXX which you'll probably find in much faster speeds than Microwire.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes. They should be placed as close to the Vcc pins as practicable. I use 0.1µF 50 volt X7R MLCC caps.


The JTAG pins have to be driven at 5 volts for programming. See attached data sheet.


Thirty bytes would require at least 240 latches. I don't know if the 1508 can support that many. The only way to found out is to write minimal code that creates the required latches and I/O statements, and try simulating it in WinCUPL.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Thanks for the datasheet, BDD. And, as you say, writing some test code may be a useful step. PLDs are very general in their scope of application, and it can be hard to make the leap from what the datasheet says to a specific usage one might have in mind.

It's true a ROM will consume significant CPLD resources, but your "240 latches" estimate is misguided as no actual latches are required. A ROM's output is combinatorial -- determined entirely by currently prevailing inputs, and not dependent on any stored information (as might be contained in a latch).

I'm no expert on ATF1508 but luckily that's not necessary to describe, logically, what a ROM does. A good place to start is to imagine a ROM that's one bit wide, not eight. The equation will be a Sum of Products -- ie; it describes an OR gate each of whose inputs comes from an AND gate. For every ROM location we want to contain a "0" we do nothing. For every ROM location we want to contain a "1" we include a Product Term (an AND gate) that says, "Hey! -- right now all the address inputs match my address!" The Product Terms get summed (ORed) to produce the result.

Sorry I don't know the WinCUPL syntax. But a byte-wide ROM can be described by eight instances of such a Sum-of-Products equation. In a practical case you'll also need a Chip-Select input to control the tri-state outputs.

cheers, & HTH
JeffPS- here's a one-bit wide ROM with 8 locations, addressed by A2, A1 and A0. In this example locations 0, 1, 4 and 7 contain ones; the remaining locations contain zero.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I agree with Dr Jefyll with regards to the method for representing the contents of a ROM in a CPLD like the ATF1508 being discussed. I wrote a GIST on GitHUB a few years ago that might be of interest. It describes a technique that utilizes the Sum-Of-Products logic in a CPLD to store the contents of a small ROM. Optimization/reduction of the equations is left to the tool, i.e. ISE or WinCUPL. That GIST is decribed here, and it references a control ROM for a microprogrammed FIFO described here. The completed source for the microprogrammed FIFO is located on GitHUB.

_________________
Michael A.

That does sound good but if it doesn't have parallel access, I might as well stick with the TO-92 package to save space unless it's protocol is much more complicated.

That makes sense.

Do you have an idea of how many bytes you were able to squeeze in to your design? I'm wondering if 30 bytes is out of the question with the other address decoding I want to do.

Druzyek:

If you've followed the links in my earlier reply, then you'll see that the example "ROM" that I was referring to has 16 locations of 14 bits. In a direct mapping to registers, the "ROM" would require 224 FFs. Using the technique that Dr Jefyll and I suggest, and described in the Verilog file that I linked to, I was able to map the "ROM" into a XC9536 CPLD as shown in the following JPEG:

_________________
Michael A.

Thanks, Michael. It's also interesting to note that the same Sum of Products logic can alternatively be implemented using a diode matrix, as mentioned in two posts here.

An EEPROM in a TO-92 -- is that what's implied here? I like the sound of that, even though the 8-pin DIP is already pretty small. Either way, the CPLD could convert the serial bitstream into bytes to be written to RAM. The price tag in resources wouldn't be very great, and you'd come out ahead except for a very small ROM.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

I expect the EEPROM in TO-92 is 1-Wire which is much slower than even I²C and has timing requirements that must be adhered to. Still, it's interesting.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?