Hi!
I wonder if anyone here has experience with the Atmel ATF22V10C chips and using/programming them?

Since the Lattice versions has been discontinued I bought some of the Atmel chips but programming them I've seen some issues.
I use one of these for memory bank selection, basically replacing A13-A15 address lines from the 65C02 CPU to the SRAM as well as sending A16-A18.
During boot-up I'm using another input on the chip as OE so an Atmega4809 can directly talk to the SRAM and I set the OE flag in wincupl for each output to not output during this boot-up time to avoid contention.
All this works fine using the GAL22V10 chip from Lattice but seems to not set to tri-state using the Atmel version. I'm using the Xgpro software / TL866II+ to program both chips.

Here is the wincupl code, sorry for probably formatting badly:

/* *************** INPUT PINS *********************/
PIN 1 = PHI2; /* */
PIN 2 = RW; /* */
PIN 3 = CPU_A15; /* */
PIN 4 = CPU_A14; /* */
PIN 5 = CPU_A13; /* */
PIN 6 = BANKA_0; /* */
PIN 7 = BANKA_1; /* */
PIN 8 = BANKA_2; /* */
PIN 9 = BANKA_3; /* */
PIN 10 = BANKA_4; /* */
PIN 11 = BANKA_5; /* */
PIN 13 = !BOOTUP_OE; /* */
PIN 14 = BANKB_0; /* */
PIN 15 = BANKB_1; /* */


/* *************** OUTPUT PINS *********************/
PIN 23 = WE; /* */
PIN 22 = OE; /* */
PIN 21 = SRAM_A18; /* */
PIN 20 = SRAM_A17; /* */
PIN 19 = SRAM_A16; /* */
PIN 18 = SRAM_A15; /* */
PIN 17 = SRAM_A14; /* */
PIN 16 = SRAM_A13; /* */

/*
* Logic:
*/

SRAM_A18 = ((CPU_A15 & !CPU_A14 & CPU_A13) & BANKA_5) # // Bank A bit 5 selection
(CPU_A15 & CPU_A14) // Set if we are in ROM bank since all ROM is located at top of memory
;
SRAM_A17 = ((CPU_A15 & !CPU_A14 & CPU_A13) & BANKA_4) # // Bank A bit 4 selection
(CPU_A15 & CPU_A14) // Set if we are in ROM bank since all ROM is located at top of memory
;
SRAM_A16 = ((CPU_A15 & !CPU_A14 & CPU_A13) & BANKA_3) # // Bank A bit 3 selection
(CPU_A15 & CPU_A14) // Set if we are in ROM bank since all ROM is located at top of memory
;
SRAM_A15 = (CPU_A15 & !CPU_A14 & BANKA_2) # // Bank A bit 2 selection
(CPU_A15 & CPU_A14 & BANKB_1) # // Bank B bit 1 selection
(CPU_A15 & !CPU_A14 & !CPU_A13) // A15 can be used directly if we are in LOW RAM or I/O map
;
SRAM_A14 = (CPU_A15 & !CPU_A14 & CPU_A13 & BANKA_1) # // Bank A bit 1 selection
(!CPU_A15 & CPU_A14) # // A14 can be used directly if we are in LOW RAM
(CPU_A14 & BANKB_0) // Bank B bit 0 selection
;
SRAM_A13 = ((CPU_A15 & !CPU_A14 & CPU_A13) & BANKA_0) # // Bank A bit 0 selection
(!(CPU_A15 & !CPU_A14 & CPU_A13) & CPU_A13) // Use directly if we are not in RAM bank A
;

WE = !(PHI2 & !RW);
OE = !(PHI2 & RW);

SRAM_A13.oe = BOOTUP_OE;
SRAM_A14.oe = BOOTUP_OE;
SRAM_A15.oe = BOOTUP_OE;
SRAM_A16.oe = BOOTUP_OE;
SRAM_A17.oe = BOOTUP_OE;
SRAM_A18.oe = BOOTUP_OE;
WE.oe = BOOTUP_OE;
OE.oe = BOOTUP_OE;


Thanks for any ideas!
/Daniel

Atmel (now Microchip) uses a programming algorithm that is different than used with the Lattice devices. Your programmer may not be able to correctly program any of the Microchip parts.

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

Yeah, I've heard a lot about that but the programmer claims to support these chips (TL866II+ programmer).

I can't help you with that. However, someone else here may, as we do have some members who have projects with GALs in them.

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

Put a very simple equation into it - e.g. a simple inverter. Test it on breadboard with LED and a couple of resistors... That will be a crude check that it is indeed being programmed.

(I use Lattice GALs, FWIW)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Good idea and I tried a standalone GAL vs ATF test already for this reason.
The output is correct on all the pins except for the tri-state when BOOTUP_OE is high. If I set BOOTUP_OE to high (with direct wiring), I get tri-state out on the lattice GAL chip but no difference at all using ATF (which in the actual circuit leads to bus contention).

I managed to find a bunch of lattice chips from jameco so I've ordered more of those which should be an ok solution but I would prefer using some of my ATF chips too.
I've read that the ATF chipset has a power down feature which I might try out to see if that can be used in lieu of working OE per pin.

To clarify, the programming seems to be working, although I'll run some more tests to triple check that, but the OE "flag" on the output pins don't seem to make any difference at all and since I'm not really clear on how this is achieved on the actual array, I'm stumped whether this is:
1. Supported at all on the ATF22V10 chips
2. Supported but require some special wincupl code
3. Programmer bug that doesn't write this part to the chip

Have you thoroughly perused the ATF22V10 data sheet?

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

I've tried to but there are a lot of things I don't fully understand in there and OE / Output Enable is mentioned 2-3 times total and never with any details (as far as I can find).
It's specifically the output enable term that I want more details on.

FWIW, Atmel's "zero power" series GALs power down the internal product-term circuitry when it's not required to save power, but the outputs are still correctly latched and driven. Those parts should however support the tri-state product term as well.

Yes I saw that section but like you say, tri-state should work or this chip would not be able to (directly) be connected to a bus for example without contention.

The exact same code on the "similar" GAL22V10 works fine.

Thanks for the help so far everyone!

Interesting problem.

Like drogon I too use Lattice stuff. No problem getting them by the boat load. As I mentioned in another thread tonight, that may be an issue if your are going to commercialize this gizmo, but should not be if you are entertaining yourself in your hobby.

In any case, your CUPL file is a little hard to parse. I did get through it and it should work, but again, I'm coming from a Lattice perspective. I would however suggest you use intermediary values to make your code a little easier to digest (for us humans, that is).

Like:


Choose whatever names you want for a and b. This really helps highlight the nuances of each line of code, rather than having to read the same stuff over and over to see if there a little changes or errors. Just a suggestion ...

_________________
Bill

Agreed, I do have a few lattice chips and no I'm not planning to sell this so I'll stick with them for now. It's just unfortunate I can't use any of my atmel chips I've bought.

I'm new to wincupl (not a great experience for writing code imho) so I wrote the logic in another editor. I wasn't sure I could create intermediate variables so I just wrote the logic elsewhere and copy pasted the resulting code into wincupl.
Thanks for the heads up about it though, it will simplify my life trying to debug this.
I'm still playing around with the memory map and memory banks so will rewrite it a few more times.

Do you know of any good tutorials / best practices for writing wincupl code otherwise?

Cheers,
Daniel

FWIW, I get the impression that WINCUPL is the kind of format which is poorly parsed. You might hope to have a grammar and be free to express yourself, but in practice it pays to use very plain and conventional ways of describing what you want. If this is true, it doesn't directly tell you what to do, other than to look at other, working, designs, and copy their style, and resist the urge to get creative.

Having said that, it's from what I've read, not from experience.

WINCUPL is just a pretty straight forward dialect of CUPL. That being said I do not know of any good tutorials on CUPL. Sorry about that. Doing a google search on "CUPL tutorial" brings up several items, but I can't vouch for them.

_________________
Bill