6502.org

Posted: **Fri May 02, 2025 5:10 pm**

scotty2541 wrote:

Dinosaur,
Thanks for the reply. Especially so late at night.

I have a sleep disorder I acquired while in the military, which often has me up in the middle of the night. When I can’t sleep, I get on the computer...

Quote:

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).

The ATF750 may be thought of as a 22V10 on steroids. However, it uses a proprietary programming format that is incompatible with many burners. My XGecu T56 burner will program the ATF750. On the other hand, my TOPS850 burner hasn’t a clue about the ATF750.

Quote:

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.

The problem is in the ease at which the 16V8 flops can be put to work. It’s just not as flexible a device as the 22V10.

Quote:

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?

In the world of programmable logic, a GAL is a “simple” programmable logic device, or SPLD. A GAL is a descendant of a programmable array of logic, or PAL, the PAL being a simpler and less-flexible SPLD that was (in most renditions) one-time programmable. A closely-related device to the GAL is the PEEL (programmable electrically erasable logic), which is basically a GAL by another name. SPLDs as a group are characterized by low-density logic, a limited number of user pins, and a limited number of pins that may be arbitrarily defined as inputs or outputs.

A complex programmable logic device—CPLD—has a much denser logic fabric than an SPLD, i.e., many more macrocells, internal (“buried”) logic that is configurable in a variety of ways, a large number of user pins, and the ability to program most of those pins as inputs, outputs, or bi-directional, including the ability to high-Z a pin that functions as an output.

In particular, the availability of buried logic is a feature that distinguishes a CPLD from an SPLD. For example, a buried node can be configured as one of several kinds of flops, or could be configured as a latch to maintain state (giving rise to the ability to set up a state machine). Clocking is more flexible, and the use of physical pins as nodes, e.g., in cascading flops, is largely avoided, which conserves device resources and improves performance.

Quote:

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.

I’ve not done any work with the 16V8, but I understand that the device type you define in your CUPL code determines what capabilities are available. The 16V8 was intended to replace a PAL with a device that could be electrically erased and reprogrammed, and the 16V8’s capabilities reflect that characteristic. So you are working a bit against the 16V8’s original raison d'être.

In WinCUPL, it appears using the g16v8a device definition confers the most flexibility—the compiler will try to infer from your logic statements how the device is to be used.

Posted: **Fri May 02, 2025 7:00 pm**

Dr Jefyll wrote:

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

Ah. I used "quote"... He used "Code". It was a formatting thing on the forum. I thought he was referring to the source code file itself.
My mistake.

Still hoping for advice from a few posts back, about getting the ATF16V8MS to give me actual FlipFlops.

Posted: **Fri May 02, 2025 7:37 pm**

BigDumbDinosaur wrote:

I have a sleep disorder I acquired while in the military, which often has me up in the middle of the night. When I can’t sleep, I get on the computer...

I searched the xgecu t56 programmer. Looks nice, but I had already placed an order for a new programmer. Besides, everywhere I look, many of these are unavailable.

BigDumbDinosaur wrote:

In the world of programmable logic, a GAL is a “simple” programmable logic device, or SPLD. A GAL is a descendant of a programmable array of logic, or PAL, the PAL being a simpler and less-flexible SPLD that was (in most renditions) one-time programmable. A closely-related device to the GAL is the PEEL (programmable electrically erasable logic), which is basically a GAL by another name. SPLDs as a group are characterized by low-density logic, a limited number of user pins, and a limited number of pins that may be arbitrarily defined as inputs or outputs...

Nice lesson, thanks. Non Volatile (memory, flash, fuses... ?) is what I was hoping for. FPGA has way to much horsepower for the small project I had in mind (which was to find a DIP substitute for a 74xxxx series that is no longer available)

BigDumbDinosaur wrote:

In WinCUPL, it appears using the g16v8a device definition confers the most flexibility—the compiler will try to infer from your logic statements how the device is to be used.

Not in this case.
I changed

Code: Select all

Q1.D = DATA;

to

Code: Select all

Q1 = DATA;

and the PDF file now indicates that Q1 is "I/O" (but the simulator still doesn't given me a FlipFlop)

Then changed the device to

Code: Select all

 Device  g16v8a;

And now it doesn't compile. I get:

Quote:

pin/node 12 invalid input Q1

My history in assembler and C makes this annoying. "Hey Compiler: Don't try to out-guess me. Let me tell you exactly what I want."

For now, I'll wait for the new programmer, then begin my lessons with the ATF750.

-Scott

Posted: **Sat May 03, 2025 1:30 pm**

BigDumbDinosaur wrote:

My XGecu T56 burner will program the ATF750. On the other hand, my TOPS850 burner hasn’t a clue about the ATF750.

I am attempting to cancel my more expensive order, and get the XGecu 76. Through Amazon, the '56 is the no longer available, but the '76 has adapters as well. And is less expensive. Seems like a better deal, if I can find the doc and drivers (a comment/review about being delivered on CD... who uses those any more??)

Posted: **Fri Jun 13, 2025 2:06 pm**

Hi guys.
Thanks for your help, I have a new issue.

I got the XGecu 76, and have programmed a V750, but it only has 1000 erase cycles, so I'm relying on the simulator first.

I was asked not to open new threads, just respond to this. So here goes...

Goal: Make a counter using D FF's, which can reset at an arbitrary value.
Problem: The AR extension doesn't work as expected.

The full size counter will be 10 bits, but to begin with, I want to do something that I can reasonably simulate, so I used 4 bits. And how high the counter reaches will be set using inputs, so a 10 bit counter would need 1024 states, so a state machine isn't an option. (I might be able to reduce it to 125 selected states, but still...

)

Here is the logic diagram, using D-FF's. When the AR line is disabled (set to 0 in code - see where it's commented out) it counts 0-15 and wraps, as expected.. Note that AR is ANDed with Q from the first two FFs, and !Q from the second two FFs, so AR goes active at "3".

Here is the full code:

Code: Select all

Name     BadCounter ;
PartNo   00 ;
Date     5/6/2025 ;
Revision 01 ;
Designer Scott ;
Company  Them ;
Assembly None ;
Location  ;
Device   v750c;

/* *************** INPUT PINS *********************/
PIN 1  =  !FREQIN;
/* *************** OUTPUT PINS *********************/
pin 19 = AR;
Pin 14 = DIV0;
Pin 15 = DIV1;
Pin 16 = DIV2;
Pin 17 = DIV3;

[DIV0..DIV3].sp = 'b'0;
DIV0.oe = 'b'1;
DIV1.oe = 'b'1;
DIV2.oe = 'b'1;
DIV3.oe = 'b'1;
/*  Counter */
DIV0.d = !DIV0; 	DIV0.CK = FREQIN;
DIV1.d = !DIV1;  	DIV1.CK = !DIV0;
DIV2.d = !DIV2;  	DIV2.CK = !DIV1;
DIV3.d = !DIV3;  	DIV3.CK = !DIV2;

/*  RESET when count is 3 */
AR = DIV0 & DIV1 & !DIV2 & !DIV3; 
/*AR = 'b'0; */

DIV0.ar = AR ;
DIV1.ar = AR ;
DIV2.ar = AR ;
DIV3.ar = AR ;

But with the AR line set to trigger when the counter reaches 3, it is not working as expected.
I would expect that all FF's would reset to Q = 0.

The simulator output, with Column 2 = Count 0, Column 3 = Count 1, ...

Note that when the count reaches 3 in column 5, the following:
DIV0 and DIV1 are high, DIV2 and DIV3 are low, so AR went high as expected.
On the NEXT column 6 (clocked) DIV0 and DIV1 are still high, and DIV2 went high.
So all is did was prevent the AR from clearing any register, so now the count jumped to 7
Then on column 7, the count is now 8

Further along, on column 15, everything is low, and it starts over again (AR is active on count=3, but the FF's do not reset)
I narrowed it down to the point where it fails to reset, it ALWAYS turns on first "DIVx" that is set to use the inverted FF output as the input to the AND gate.
( i.e.

Code: Select all

AR = DIV0 & DIV1 & DIV2 & !DIV3;

turns on DIV3 on the 7th clock, and fails to turn off DIV0..DIV2 )

I have tried variations such as clocking the AR line with the input frequency, changing to active low, etc... I cannot figure out what it is doing, why the AR line is not actually doing a reset.

Any advice would be appreciated.

-Scott

Posted: **Fri Jun 13, 2025 2:58 pm**

scotty2541 wrote:

Goal: Make a counter using D FF's, which can reset at an arbitrary value.

It might be helpful for you to reacquaint yourself with the difference between a ripple counter and a synchronous counter. Your diagram shows a ripple counter, which is called that because the various FlipFlop outputs don't change state simultaneously; instead the changes "ripple" (with a small delay) from one FF to the next.

This ripple effect can cause all sorts of glitchy problems. Work-around solutions do exist, but they're not always satisfactory. For your goal, it is probably more appropriate to construct a synchronous counter instead. All the clock inputs of all the FF's will attach together, and that's why those Q outputs which change state will do so simultaneously.

I know you don't want every FF to change state on every clock pulse, and therefore it may seem counterintuitive (uh, pun unintended

) that all the FFs would receive the same clock signal. But there are various ways to cause the FF to change state or not, as desired. Either manipulate the data presented to the D-type FF's input, or replace the D type FF with a T- or JK-type. Just some hints, but I hope you find them helpful!

- Jeff

Posted: **Sat Jun 14, 2025 12:04 am**

Dr Jefyll wrote:

scotty2541 wrote:

Goal: Make a counter using D FF's...

It might be helpful for you to reacquaint yourself with the difference between a ripple counter and a synchronous counter.

Funny coincidence! I was going to suggest the exact same thing.

Scotty, something to note in programmable logic: when you use pins as feedback nodes, as you are doing, each such node adds a maximum of tPD nanoseconds to total prop time through the chain. This characteristic inherently makes your counter a ripple counter. As Jeff notes, you need to clock all flops from a common source in order to make the counter synchronous.

You are encountering one of the limitations of GALs and why CPLDs and their buried logic displaced GALs from applications that have strict timing deadlines.

Quote:

...the various FlipFlop outputs don't change state simultaneously; instead the changes "ripple" (with a small delay) from one FF to the next.

That is the effect of the prop delay incurred by using pins as nodes. As I noted above, each node will cost you up to tPD ns—and that cost is not guaranteed to be consistent from node to node.

Quote:

I know you don't want every FF to change state on every clock pulse, and therefore it may seem counterintuitive (uh, pun unintended

)...manipulate the data presented to the D-type FF's input, or replace the D type FF with a T- or JK-type. Just some hints, but I hope you find them helpful!

Of Jeff’s two suggestions, the former will be less difficult in a GAL. Synthesizing a JK- or T-flop is a headache, in my opinion. You should be able to use combinatorial statements to control what each D-flop’s input sees on each clock.

Posted: **Sun Jun 15, 2025 5:15 pm**

Thanks. That makes sense now.

BigDumbDinosaur wrote:

Of Jeff’s two suggestions, the former will be less difficult in a GAL. Synthesizing a JK- or T-flop is a headache, in my opinion. You should be able to use combinatorial statements to control what each D-flop’s input sees on each clock.

The V750, which I'm using here, has T-FF's. I've done some little experimental tests with it to verify using the T-FFs. So it's just a matter of gating "T" to make it count synchronously, the way I want. All this has been educational, although frustrating at times.

( What annoys me (coming from C and assembler) is the WinCUPL compiler claiming to just be able to know which mode you want. All the doc I've seen states that it will enable things like registered mode based on how it reads the code. I prefer explicitly compiler directives that specify what is desired. )

Thanks again.

Posted: **Sun Jun 15, 2025 6:13 pm**

scotty2541 wrote:

The V750, which I'm using here, has T-FF's.

Oh...I was thinking about the 22V10. The ATF750 is a 22V10 with extra bells and whistles (and the ATF2500 is a slightly slower ATF750 with louder bells and whistles

). However, a GAL can’t do a D-type transparent latch, needed in a 65C816 design with extended memory. For that, there are the ATF150x CPLDs.

6502.org

sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL

Re: sanity check - ATF16V8BQL