So, I'll be the first to admit that I'm still mostly new to using CPLDs... having only done one so far, with some help some the group here... notably Peter (CBSCPE), who provided some great input and some coding changes when I was working with an Atmel ATF22V10CQZ over 2 years ago.

I've working on an adapter for my C02 Pocket SBC which has a 16-bit IDE port and a DS1511Y RTC. I'm using an ATF16V8BQL CPLD to manage all of the I/O decode and drive the high-byte read and write latches for the 16-bit data port as well. I seem to have a working CPLD at this point, but I'm looking for a sanity check. The datasheet shows different modes for the ATF16V8, which aren't 100% clear (to me at least).

In any case, I'm using a single I/O select which is 32-bytes wide which drives an input on the CPLD along with 5 address lines (A0-A4), a phase 2 clock aligned Read and Write signals. I'm grounding the OC line and have a Clock attached to the CLK input, but I don't think I actually need it. I'm using addresses $00 - $13 for the RTC, locations above $13 are not used. Locations $14-$15 are for the high-byte read/write latches. Locations $16-$17 are for CS1 on the IDE drive and locations $18-$1F are for CS0 on the IDE drive.

I've burned a CPLD and have it on a breadboard with pull-up resistors and switches to set the address and R/W lines, plus LEDs and resistors on the output to show the status of the lines. It seems to be working... the Simulator also follows what should be. However, I was hoping to use the OC line with the I/O select, as it "should" enable or disable all of the outputs , or so I thought. I could never get that to work regardless, so I just grounded and used another input for the select line. I'm hoping some with more knowledge and experience on this can give me some feedback/guidance on what I' m doing (right or wrong). I'm still thinking I don't need a clock signal on pin 1... but I'm not certain.

Here's the code for WinCUPL:



Note: HBT is just defined as the high byte latch address range, but it's not connected to anything.... more of a test line from the CPLD.

If anyone has some suggestions on a better way to do this, I'm open to them. I'm currently modifying the adapter board and replacing the 44-pin IDE connector with a Compact Flash socket, so I'm just using the same basic layout and the same CPLD setup. Thanks.

_________________
Regards, KM
https://github.com/floobydust

It looks like you need to explicitly set the output enable, or it defaults to 1 and always on.

so something like
tells the program that the output enable is in use for that pin.

However just adding that line to the original file crashed WinCUPL every time I tried to complie. I also had to change the GAL definition to G16V8A and let the program autoselect before it would build.

With those tweaks included the .DOC file shows that oe is enabled and the deffition for pin 15 changes from:
to:

Thanks Martin,

That does make some sense.... the WinCUPL manual isn't that clear on OE and specifically calls out some newer CPLDs that support it, but not the 16V8. I made changes to the source file and added similar statements for the rest of the outputs. It compiles without error after the changing the device type as you did. I've run the output in the simulator and changing OC does work. However, it appears that using the output control tri-states the outputs, i.e., they become floating as the simulator output shows no high or low state... just the default for an unknown, as in before the simulator was run for the first time.

I'm sorta getting it for the OC line... and for what I need, I'll just keep it grounded and use another input for the I/O select. I do want the outputs driven high and low as required, not a high-impedance float. I'm still wondering about the CLK input... as there's no logic statement that references it, I can probably just leave it connected or ground it as well. I think grounding it might be the better option, but I'm not completely sure.

Thanks again for looking at this and clearing up the output enable usage in WinCUPL!

_________________
Regards, KM
https://github.com/floobydust

I think the WinCUPL manual should not be confused with a manual on using CUPL with GAL devices specifically. It is a manual detailing the syntax of the CUPL language (including several constructs that do not apply to GALs or PALs) and the basic operation of the software. Meanwhile the GAL device datasheets are supposed to tell you what the device is capable of doing.

But there is I think a disconnect in the middle - a mapping of specific CUPL language constructs to specific GAL device features, in a way that prospective CUPL programmers can robustly understand.

With the device type set to auto, you can use CLK and OE as normal inputs. If you're not using them in their "special" forms, WinCUPL will invoke "simple" mode.

Thanks again Martin,

I'm going to reprogram the ATF16V8 and run through some more tests on the breadboard. As I don't need a clock line, I'm going to ground both the CLK and OC lines and remove them from the configuration. The remaining inputs are used and should perform as needed. Once I confirm proper operation, I'll get PCBs ordered and build one up to confirm.

_________________
Regards, KM
https://github.com/floobydust

When selecting the device type you should always select one which is available in the Devices of WinCUPL under the Options Menu (Ctrl+D). At least in my case there are only very few GAL16V8 models, the G16V8A and the G16V8CP, where the latter supports a so called power-down mode. But I know that there is also G16V8C. Which is necessary if you are using the registered mode, else the .ck extension is not allowed. Whether Pin 1 and Pin 11 are dedicated depends on the mode set for the GAL. In Registered Mode Pin1 is the CLK pin for the registers and Pin11 is the OE of the registered outputs.



In the simple and complex modes Pin1 and Pin11 are normal inputs available for the array of product terms. In the complex mode one product term of each OLMC can be used to control the output enable of this combinatorial output. So it is not just one input but a full product term that can enable the output of complex GALs and each output can have a different logic.



Note the Device Type and the product term different to the main product term used for the output control of the RTC pin (I just took this as an example).

Hi Peter,

Thanks for the reply on this. I'm still figuring out some of the WinCUPL stuff... actually, quite a bit of it. I've been using the Atmel datasheet for the ATF16V8BQL. It shows device types to be used with WinCUPL and other tools as part of it on page 9 under Compiler Mode Selection. The datasheet shows selections for:

Registered, Complex, Simple, Auto Select as: G16V8MS, G16V8MA, G16V8AS and G16V8 respectively.

Looking at the device type from Ctrl-D (for the ATF16V8B, which supports the ATF16V8BQL), it shows the following:

Mnemonic: g16v8a
Pin Count: 20
Special Options: None
Alternate Part Numbers: ATF16V8B, ATF16V8BQ, ATF16V8BQL
Related Mnemonics: g16v8, g16v8as, g16v8ma, g16v8ms, g16v8s

Depending on what is in the code and what device is selected, it might work, it might crash or it might not do anything unless you save it, quit the simulator and compiler and restart it, which magically fixes things and they start working again. I'm still learning this stuff... and need to dissect the user manual more, but you don't always know if WinCUPL has a real error or a bogus crash when things don't work.

Some of the parameters and statements you provided are new (for me), so I'll look deeper into the manual for these. I'm thinking I might have enough clarity from this post to get the simple address decoding and selecting done for the IDE/RTC adapter I'm working on. I should be able to just ignore pins 1 and 11 (e.g., just ground them) and use the rest of the inputs as already shown. The simulator is working so far, so I'll re-program the PLD and run through more tests. If everything works as intended, I'll be ordering PCBs this week. Thanks again for your knowledge on this... Martin also!

_________________
Regards, KM
https://github.com/floobydust

Hi floobydust,
about the WinCUPL crashing thing. It got a LOT better for me when I started running it in a 32 bit Win 7 VM. Running it in Win 7 x64 caused it to crash constantly.