sanity check - ATF16V8BQL

Topics relating to PALs, CPLDs, FPGAs, and other PLDs used for the support or creation of 65-family processors, both hardware and HDL.
User avatar
floobydust
Posts: 1394
Joined: 05 Mar 2013

sanity check - ATF16V8BQL

Post by floobydust »

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:

Code: Select all

Name     IDE-RTC ;
PartNo   01 ;
Date     1/04/2020 ;
Revision 01 ;
Designer KM ;
Company  Analogue Technologies ;
Assembly SBC2 ;
Location  ;
Device   G16V8MS ;

/* *************** INPUT PINS *********************/
PIN 1    = CLK                       ; /*                                 */
PIN 2    = A0                        ; /*                                 */
PIN 3    = A1                        ; /*                                 */
PIN 4    = A2                        ; /*                                 */
PIN 5    = A3                        ; /*                                 */
PIN 6    = A4                        ; /*                                 */
PIN 7    = !MRD                      ; /*                                 */
PIN 8    = !MWR                      ; /*                                 */
PIN 9    = !SEL                      ; /*                                 */
PIN 11   = !OC                       ; /*                                 */

/* *************** OUTPUT PINS *********************/
PIN 18   = !UBWE                     ; /*                                 */
PIN 16   = !UBRE                     ; /*                                 */
PIN 19   = UBWL                      ; /*                                 */
PIN 17   = UBRL                      ; /*                                 */
PIN 12   = !CS0                      ; /*                                 */
PIN 13   = !CS1                      ; /*                                 */
PIN 15   = !RTC                      ; /*                                 */
PIN 14   = !HBT                      ; /*                                 */

/** Declarations and Intermediate Variables Definitions **/
FIELD ADDRESS = [A4..0];

RTC = SEL & ADDRESS:['h'00..13];
HBT = SEL & ADDRESS:['h'14..15];
CS1 = SEL & ADDRESS:['h'16..17];
CS0 = SEL & ADDRESS:['h'18..1F];

/** Logic Equations **/

UBWE = MWR & SEL & ADDRESS:['h'18..18];
UBRE = MRD & SEL & ADDRESS:['h'14..14];
UBWL = MWR & SEL & ADDRESS:['h'15..15];
UBRL = MRD & SEL & ADDRESS:['h'18..18];

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.
Martin A
Posts: 197
Joined: 02 Jan 2016

Re: sanity check - ATF16V8BQL

Post by Martin A »

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

so something like

Code: Select all

RTC.oe = OC ;
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:

Code: Select all

Pin #15  02052  Pol x  02124  Ac1 - 
 01024 -------------------------------- 
 01056 -----------------x-----------x-- 
 01088 ---------x---x---------------x-- 
 01120 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01152 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01184 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01216 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01248 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
to:

Code: Select all

Pin #15  02052  Pol x  02124  Ac1 - 
 01024 -------------------------------x 
 01056 -----------------x-----------x-- 
 01088 ---------x---x---------------x-- 
 01120 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01152 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01184 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01216 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
 01248 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
User avatar
floobydust
Posts: 1394
Joined: 05 Mar 2013

Re: sanity check - ATF16V8BQL

Post by floobydust »

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!
Chromatix
Posts: 1462
Joined: 21 May 2018

Re: sanity check - ATF16V8BQL

Post by Chromatix »

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.
Martin A
Posts: 197
Joined: 02 Jan 2016

Re: sanity check - ATF16V8BQL

Post by Martin A »

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.
User avatar
floobydust
Posts: 1394
Joined: 05 Mar 2013

Re: sanity check - ATF16V8BQL

Post by floobydust »

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.
User avatar
cbscpe
Posts: 491
Joined: 13 Oct 2013
Location: Switzerland
Contact:

Re: sanity check - ATF16V8BQL

Post by cbscpe »

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.

Code: Select all

Device   G16V8C ;
Q1.ck = CLK;
Q1.d  = SEL & ADDRESS:['h'00..13];
Q1.oe = OC; 
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.

Code: Select all

Device   G16V8A ;
RTC = SEL & ADDRESS:['h'00..13];
RTC.oe = SEL & ADDRESS:['h'10..13];
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).
User avatar
floobydust
Posts: 1394
Joined: 05 Mar 2013

Re: sanity check - ATF16V8BQL

Post by floobydust »

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!
SteveD
Posts: 15
Joined: 18 Apr 2020
Location: Canberra, Australia

Re: sanity check - ATF16V8BQL

Post by SteveD »

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.
scotty2541
Posts: 8
Joined: 26 Apr 2025

Re: sanity check - ATF16V8BQL

Post by scotty2541 »

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.

Code: Select all

Device   G16V8C ;
Q1.ck = CLK;
Q1.d  = SEL & ADDRESS:['h'00..13];
Q1.oe = OC; 
Hello,
Like "floobydust" I'm a newbie to this material as well. But not to programming in general. (the lack of good instructional material is annoying... just goes from basic logic to code statements, no explanation about device specifics or how the compiler is making these decisions.)

I am asking a follow-up, in the hope that someone is still watching this thread. Otherwise, I will create a new post.

From the code segment above, and it reports that the G16V8C is not in the library. And WinCUPL came with only two libraries, ATMEL.DL and CUPL.DL. Neither one works.

I am consulting a document: CUPL_Reference.pdf (attached).

Trying other devices is getting nowhere. Sometimes I get an "unknown extension .ck" If I think I've gotten around that, I get a "unknown extension .dfb"

In the list, WinCUPL has only 3 listed:
ATF18V8B (says to use g16v8a)
ATF18V8C (says to use g16v8a)
ATF18V8C-PD (says to use g16v8cp)

The intro/educational chip I have, has ATF18V8CZ stamped on it.

I've exhausted all these choices, and cannot get past compiler errors.

WinCUPL I found (ver 5.3) has a doc called DevHelp.pdf which I attached. It lists devices, modes, IO pins, Mnemonic, etc..

Everywhere I look, it says the .CK extension is available in "registered" mode.
And it also tells me that the compiler selects which mode.

Well, I've never found whatever pixie dust is needed to get the compiler to decide to build it in "Registered Mode", to convince it to use the FlipFlops I'm trying to use.

As an example, here is simple two FlipFlop chain, my goal is to divide the clock input by 4. ( Q1 out into Q2 in)

(If the logic is wrong, I will learn that and fix it on my own. My issue here is that it is telling me these extensions are not known, even though they are... something to do with making it know to use "registered" mode ??)

Code: Select all


Name     Div4 ;
PartNo   00 ;
Date     4/26/2025 ;
Assembly None ;
Location  ;
DEVICE    g16v8;
     
/*********************************
   g16v8ms =  no .CK
   g16v8ma = no Q.D  Need DFB.   Then no .CK
   
*********************************/
                                               
/**  Inputs  **/
Pin 1 = CLK;
Pin 2 = DATA;
Pin 11 = OE_EN;

/**      Outputs       **/
Pin 19 = Q1;
Pin 12 = Q2;

/**      Logic Equations      **/ 
Q1.D = DATA;
Q1.CK = CLK;
Q2.CK = Q1.D & DATA;
Thanks for any hints on figuring this out.

-Scott
Attachments
CUPL_Reference.pdf
(1.87 MiB) Downloaded 119 times
Devhelp.pdf
The DevHelp file
(23.67 KiB) Downloaded 115 times
"Code shown is not to scale"
GlennSmith
Posts: 162
Joined: 26 Dec 2002
Location: Occitanie, France

Re: sanity check - ATF16V8BQL

Post by GlennSmith »

Hi,
If I look at the ATF16V8C datasheet (dated march 2014 - the devhelp file looks -OLD-), it describes the 3 programming modes possible, and the correct 'model' of 16V8 to declare in WINCUPL. IIRC, for the 16v8 there aren't any extensions to use, they are intrinsically activated.
ATF16V8C_datasheet-P10.png
here's the said PDF.
ATF16V8C.pdf
(951.3 KiB) Downloaded 122 times
If you look at page 12 you see a fairly simple explanation.
This is how I managed to (finally) get my head around pretty much the same problem when I started out on the same road. Hope it helps.
Glenn-in-France
scotty2541
Posts: 8
Joined: 26 Apr 2025

Re: sanity check - ATF16V8BQL

Post by scotty2541 »

GlennSmith wrote:
Hi,
If I look at the ATF16V8C datasheet (dated march 2014 - the devhelp file looks -OLD-), it describes the 3 programming modes possible, and the correct 'model' of 16V8 to declare in WINCUPL. IIRC, for the 16v8 there aren't any extensions to use, they are intrinsically activated.
The attachment ATF16V8C_datasheet-P10.png is no longer available
here's the said PDF.
The attachment ATF16V8C.pdf is no longer available
If you look at page 12 you see a fairly simple explanation.
This is how I managed to (finally) get my head around pretty much the same problem when I started out on the same road. Hope it helps.
Thanks. I saw someone wrote WinCUPL is a blessing and a curse... I haven't reached the "blessing" part.

I know this is a 6502 forum, but it's the only place I have found that has people with this skill set. So it's the only place I have been able to ask. I'd be happy to message or email, so as to take this topic outside the forum's charter.

Anyway, RTFM is something I've had to tell people too, so I figure I should be told that :-)

But I wish there was something, somewhere, in writing that says which extensions can be used with which device. Now it just seems to be a crap shoot.

I saw that table, and thought I now have the answer. Except it's still not working. I tried with "g16v8a" and "g16v8MS"
(By the way, what is "Registered Configuration for Registered Mode" versus "Combinatorial Configuration for Registered Mode" ? Its' something else not explained or in the table in section 7 )
Section8.jpg
Looking at the digital block diagram, I see the CLOCK line is all connected together. So I realize now that I can't make a divider. So I tried to make a simple shift register. Something like this:
Shift.jpg
Shift.jpg (5.9 KiB) Viewed 2628 times
And this is the code:
Quote:
Name Div4 ;
PartNo 00 ;
Date 4/26/2025 ;
Revision 01 ;
Designer Engineer ;
Company me ;
Assembly None ;
Location ;
Device g16v8a;

Pin 1 = CLK;
Pin 2 = DATA;
Pin 11 = OE_EN;
Pin 12 = Q1;
Pin 13 = Q2;
Pin 14 = Q3;
Pin 15 = Q4;
Pin 16 = Q5;
Pin 17 = Q6;
Pin 18 = Q7;
Pin 19 = Q8;

BIT = DATA;

Q1.D = BIT; /* removing the ".D" gives an error: Invalid input on Q1 ?? */
Q2 = Q1;
Q3 = Q2;
Q4 = Q3;
Q5 = Q4;
Q6 = Q5;
Q7 = Q6;
Q8 = Q7;
Okay, except the PDF file, although I'm not sure what it means, does, or what all the statements are, I can see that it says Q1 is an INPUT. Here is that segment.
Quote:

{SYMBOL
{PIN_DEF
[Ly "PINCON"]
{P OE_EN {Pt "INPUT"}{Lq 0}{Ploc 100 100}}
{P CLK {Pt "INPUT"}{Lq 0}{Ploc 100 80}}
{P DATA {Pt "INPUT"}{Lq 0}{Ploc 100 40}}
{P Q1 {Pt "INPUT"}{Lq 0}{Ploc 100 20}}
{P Q2 {Pt "I/O"}{Lq 0}{Ploc 280 20}}
{P Q3 {Pt "I/O"}{Lq 0}{Ploc 280 40}}
{P Q4 {Pt "I/O"}{Lq 0}{Ploc 280 60}}
{P Q5 {Pt "I/O"}{Lq 0}{Ploc 280 80}}
{P Q6 {Pt "I/O"}{Lq 0}{Ploc 280 100}}
{P Q7 {Pt "I/O"}{Lq 0}{Ploc 280 120}}
{P Q8 {Pt "I/O"}{Lq 0}{Ploc 280 140}}
}
And the simulator is not giving me FlipFlops. More like latches.
sim.jpg
The clock transition latches the high on BOTH Q2, 3, 4, 5 at the same time. Then not sure what the deal it with Q6 and Q7 being on the negative transition.

Any additional advice is appreciated.

-Scott
"Code shown is not to scale"
User avatar
BigDumbDinosaur
Posts: 9428
Joined: 28 May 2009
Location: Midwestern USA (JB Pritzker’s dystopia)
Contact:

Re: sanity check - ATF16V8BQL

Post by BigDumbDinosaur »

scotty2541 wrote:
I know this is a 6502 forum, but it's the only place I have found that has people with this skill set...

Not to discourage you, but you should consider using the ATF22V10C instead of the 16V8.  Although the former is in a somewhat larger package than the latter (24 pins vs 20), you will have a significantly more flexible part at your disposal.  In WinCUPL, I use the g22v10 device type with the 22V10, permitting the use of both combinatorial and registered logic in the same design.

Quote:
Looking at the digital block diagram, I see the CLOCK line is all connected together.  So I realize now that I can't make a divider.

That limitation, and others, is why CPLDs replaced GALs in many applications in the days before FPGAs started to take over.  Microchip’s ATF1502 and ATF1504 CPLDs take up scarcely more room on a PCB than a 22V10, yet offer far more design options, especially when using buried logic.  You can have multiple clock inputs or use buried flip-flops to act as clock dividers.  Combinatorial logic can be much denser and you can implement transparent latches—something not possible with a GAL.

BTW, for better formatting of code, you can surround text with code tags, like this:

Code: Select all

Name Div4 ;
PartNo 00 ;
Date 4/26/2025 ;
Revision 01 ;
Designer Engineer ;
Company me ;
Assembly None ;
Location ;
Device g16v8a;

Pin 1 = CLK;
Pin 2 = DATA;
Pin 11 = OE_EN;
Pin 12 = Q1;
Pin 13 = Q2;
Pin 14 = Q3;
Pin 15 = Q4;
Pin 16 = Q5;
Pin 17 = Q6;
Pin 18 = Q7;
Pin 19 = Q8;

BIT = DATA;

Q1.D = BIT; /* removing the ".D" gives an error: Invalid input on Q1 ?? */
Q2 = Q1;
Q3 = Q2;
Q4 = Q3;
Q5 = Q4;
Q6 = Q5;
Q7 = Q6;
Q8 = Q7;
x86?  We ain't got no x86.  We don't NEED no stinking x86!
scotty2541
Posts: 8
Joined: 26 Apr 2025

Re: sanity check - ATF16V8BQL

Post by scotty2541 »

Dinosaur,
Thanks for the reply. Especially so late at night.
BigDumbDinosaur wrote:
Not to discourage you, but you should consider using the ATF22V10C instead of the 16V8. 
The ATF18V8 was part of a learner kit I bought years ago, then set aside. Now I've dusted it off and started over.
So after doing a part search and reading some data sheets, I thought the ATF750 would be a good unit for the final project. I picked up a hand full of them (in case I do a brain dead error and fry one).

Then I discover the VP-290 that was part of the kit 1) isn't even made any more and 2) its older brother doesn't support the ATF750! So now I have to decide whether to invest a lot more $$ in a larger programmer for this... a small educational task.

Or in baby steps, get a slightly bigger PLD. But my programmer doesn't support the ATF22 either. So there is still that issue.

And if the 16V8 says it's got FlipFlops (as it does all over the data sheet) and I can't make it happen, I'm not confident can I make FlipFlops work in the ATF750.
BigDumbDinosaur wrote:
That limitation, and others, is why CPLDs replaced GALs in many applications in the days before FPGAs started to take over. 
And yet another piece of information I can't get defined:
Where are GALs, relative to PLD's ? Just size? Is it still CPLD when they just drop the "C" and call it a PLD? All the doc, even for the 16V8, says it's a PLD, and says it's got D FlipFlops, not just combinational logic and latches. But I'm not seeing that work.

Sorry to be asking so much, but this is the only place I've seen that discusses it, and has people experienced in it.
BigDumbDinosaur wrote:
BTW, for better formatting of code, you can surround text with code tags, like this:
Um... that looked the same. Did Copy/Paste byte you in the rear? Happens to me often too. :-)
"Code shown is not to scale"
User avatar
Dr Jefyll
Posts: 3526
Joined: 11 Dec 2009
Location: Ontario, Canada
Contact:

Re: sanity check - ATF16V8BQL

Post by Dr Jefyll »

scotty2541 wrote:
Um... that looked the same.
Hi, Scott. The code tags cause your text to be rendered in a monospace font. Not so much in this case, but often this can be crucial in preserving the readability and visual arrangement intended by the author. :)

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