ATF15xx Verilog/VHDL using Quartus 13.0 SP1

[barnacle]

It's 'in stock' at digi, but it's coming from Rochester. Odd rules apply, and sometimes you don't know until you push the buy button.

Neil

(Apologies, I've derailed the thread. I'll shut up now.)

[Dr Jefyll]

On the Canadian version, at least, their site features the following very handy check box. And I still see through-hole 'HC670's listed as Active and in stock.

[martingi]

Right, the HC670 is quite a bit cheaper than the HCT version. The HC version will probably be fine as long as everything else is CMOS. Spencer uses LS parts in some of his modules, so it has to be HCT.

Btw, the Z80 CPUs and peripherals now found on AliExpress are NMOS despite the CMOS markings on them (i.e. you get actual retro at no extra charge!). I measure about 4V high voltage, so they should just about work with modern 5V CMOS levels.

The CPLD route was definitely fun. As for the retro credibility, I figured that half a MB of SRAM aren’t exactly 1982 either.

[BigDumbDinosaur]

martingi wrote:

The CPLD route was definitely fun. As for the retro credibility, I figured that half a MB of SRAM aren’t exactly 1982 either.

Back then, you would have had to take out a second mortgage on your home to afford that much SRAM.  On the other hand, a couple of payday loans would have been sufficient to finance the same amount of DRAM. 

[Dr Jefyll]

martingi wrote:

The transients are terrible. You can see each edge of the clock signal on every output, even with twice as much decoupling

Martin, returning to this signal-quality issue, I'd like to talk about the power and ground rings you've established.

I get that the rings are intended to mitigate the perf board's lack of power and ground planes, and I've used the same approach myself. In regard to, as you say, seeing each edge of the clock signal on every output, you'll never be able to totally eliminate that (and some of the apparent noise may actually be the result of how your scope is connected). But I believe your ring approach has room for improvement, as ever do my own projects... it's all a learning process.

The crucial goal is to supply good power to the chip itself -- internally, I mean. We want reasonably clean DC between the tiny Gnd and Vcc traces right on the actual CPLD die. That's why we attach external bypass capacitors... and for best results we need a low-inductance circuit path between each cap and the die. That means keeping the conductors in the path short, which we do mainly in order to minimize the area of the loop that's created. Another fundamental way to lower the loop area -- and thus the inductance -- is to locate the two conductors in close mutual proximity.

Shown above is a bottom view of the socket for your CPLD. On the right I've shown one possible way to take good advantage of the eight Gnd and Vcc pins. I've used four caps, but that's not because I want more capacitance. My main concern is to make the best use of the pins. So, I began by connecting a single cap to the die, taking care to keep the connections short and the loop area low. Then I repeated the process until all the Gnd & Vcc pins were gainfully employed in the same way, ensuring reasonably clean DC on the actual CPLD die.

As for rings, they're merely secondary -- an afterthought! I know it's tempting to start by focusing on connecting the pins to a pair of nice, tidy rings, then focus on connecting the rings to the caps. But notice you've gotten distracted with a two-step approach, using the rings as a middleman. Sometimes that'll be pretty harmless, but in this case the locations of the Gnd and Vcc pins are NOT particularly tidy, and IMO it's best to begin by putting the caps where they can most effectively be attached to the pins. Then -- afterward! -- you can elaborate by adding whatever rings or other figures will (in the absence of Gnd & Vcc planes) make Gnd and Vcc conveniently available for connections to other devices on the board and to the PSU.

Perhaps your existing layout (below) will prove satisfactory. But even minor changes would be beneficial. For example, how about adding a cap between pins 22 & 23? I know you're using point-to-point wiring, but that needn't rule out the use of SMT capacitors! From my own experience, I know a SMT cap can quite comfortably be located between two adjacent points on a .1" grid....

-- Jeff

[Jmstein7]

I guess I have good timing - this thread is alive! I've been trying to use Quartus II to demux a 65C816 (data and bank) using an ATF1504as 7.5ns, but to no avail. I switched to WinCUPL, but I feel like I'm banging my head against the wall. I'm sure people have done this before; but I just can't get my code to do it. Yes, it compiles without error. Then, nothing. I have my logic analyzer hooked up, and nothing coming out onto the data lines (or bank). Here's my code - I'm at a loss:

Code: Select all

Name      CPLD_A_Interface;
Partno    ATF1504AS;
Revision  3;
Date      05/03/2025;
Device    f1504ispplcc44;

/* Pin Definitions */
PIN 43 = PHI2;
PIN 40 = RWB;
PIN [39,37,36,34,33,31,29,28] = [CPU_DB0..7];
PIN [25,24,21,20,19,18,17,16] = [DEMUX_DB0..7];
PIN [4,5,6,8,9,11,12,14] = [BANK_A0..7];
PIN 26 = MEMOEB;
PIN 27 = MEMWEB;

/* Internal Nodes for Data Latch with Explicit Macrocell Assignments */
PINNODE 601 = dfcpu0;
PINNODE 602 = dfcpu1;
PINNODE 603 = dfcpu2;
PINNODE 604 = dfcpu3;
PINNODE 605 = dfcpu4;
PINNODE 606 = dfcpu5;
PINNODE 607 = dfcpu6;
PINNODE 608 = dfcpu7;

/* Property to Guide Fitter */
PROPERTY ATMEL {SOFT_BUFFER=dfcpu0,dfcpu1,dfcpu2,dfcpu3,dfcpu4,dfcpu5,dfcpu6,dfcpu7};

/* Field Definitions */
FIELD CPU_DB = [CPU_DB0..7];
FIELD DEMUX_DB = [DEMUX_DB0..7];
FIELD BANK_A = [BANK_A0..7];
FIELD data_from_cpu = [dfcpu0..7];

/* Bank Address Latch - Latched on falling edge of PHI2 */
BANK_A.d = CPU_DB.io;
BANK_A.ck = !PHI2;

/* Data from CPU Latch - Latched on rising edge of PHI2 when RWB is low */
data_from_cpu.d = CPU_DB.io;
data_from_cpu.ck = PHI2;
data_from_cpu.ce = !RWB;

/* CPU_DB Tri-state Control - Drives DEMUX_DB to CPU_DB during read cycles */
CPU_DB = DEMUX_DB.io;
CPU_DB.oe = PHI2 & RWB;

/* DEMUX_DB Tri-state Control - Drives data_from_cpu to DEMUX_DB during write cycles */
DEMUX_DB = data_from_cpu;
DEMUX_DB.oe = PHI2 & !RWB;

/* Memory Control Signals - Active low */
MEMOEB = !(PHI2 & RWB);  /* Output enable active during read cycles */
MEMWEB = !(PHI2 & !RWB); /* Write enable active during write cycles */

Does anyone know why this won't work? Am I totally off base?

Thanks in advance!

[BigDumbDinosaur]

Jmstein7 wrote:

I switched to WinCUPL, but I feel like I'm banging my head against the wall. I'm sure people have done this before; but I just can't get my code to do it. Yes, it compiles without error. Then, nothing. I have my logic analyzer hooked up, and nothing coming out onto the data lines (or bank). Here's my code - I'm at a loss...

I cut-and-pasted your code into WinCUPL and could not get it to compile.  Additionally, the compiler reported an error due to an incomplete header.

I attached a copy of the CUPL code for a 65C816 design that compiles and simulates.  Perhaps you’ll find something useful in it.

cpld.pld.txt

Example CUPL Code

(10.76 KiB) Downloaded 93 times

[Jmstein7]

Thanks, BDD. That’s odd, though. I have to say, the behavior of WinCUPL under Win11 on my PC is erratic at best.

Jonathan

[BigDumbDinosaur]

Jmstein7 wrote:

Thanks, BDD. That’s odd, though. I have to say, the behavior of WinCUPL under Win11 on my PC is erratic at best.

WinCUPL’s sometimes-cantankerous behavior is well-known, regardless of Windows’ version.  I’ve seen anecdotes about how WinCUPL should be run as a 32-bit application on 64-bit versions of Windows.  I can’t vouch for that, as I do my 6502 development work on a creaky Windows XP SP3 machine that has been running the same hardware for nearly 13 years (except the disk).

One thing to watch out for is the WinCUPL compiler chokes on source files with UNIX-style line endings.  If you use an editor other than the one built into WinCUPL, be sure it is writing files with MS-DOS-style line endings.

Incidentally, in your code, I noted you defined your PINNODEs using distinct numbers.  In most cases, you should let the fitter make PINNODE assignments.  I have E-mail somewhere from Atmel technical support making that recommendation and explaining why, but can’t seem to locate it.

[Jmstein7]

BigDumbDinosaur wrote:

Incidentally, in your code, I noted you defined your PINNODEs using distinct numbers.  In most cases, you should let the fitter make PINNODE assignments.  I have E-mail somewhere from Atmel technical support making that recommendation and explaining why, but can’t seem to locate it.

I read something about that, too. Not much help if you’re programming the CPLD after you’ve designed the hardware.

I picked up some 74LVC245s. I hope they allow me to get away from these arcane 5V CPLDs.

Fingers crossed.

Jonathan

[plasmo]

I hope I don’t come across as smug; no, I’m sad. The difficulty in getting reliable sources of EPM7xxx is driving cpld design methodology away from a highly reliable Quartus development tool and associated inexpensive USB Blaster programmer into this ridiculously buggy WinCUPL tool and expensive Atmel programmer. The inadequate WinCUPL will fundamentally limit what can be designed in ATF150x and discourage system level trade-off and integration and associated speed up that potentially can be implemented in CPLD.

I have went down the path of acquiring reliable sources of EPM7xxx and purchased a life-supply of EPM7xxx which free me to develop complex CPLD designs based on EPM7xxx, but I lament the chilling effects of WinCUPL on CPLD designs and the CPLD developer community suffer as the result. So much potentials of CPLD are hampered by this inadequate toolchain, it is quite sad!
Bill

[BigEd]

Does it help at all to be able to drive CUPL from the command line? (It might run under a handy emulator this way, which might be more controllable and predictable than running under Windows)
WinCupl batch file cupl.bat

Likewise it might make it easier to run some chosen old version.

[plasmo]

Here is an explanation to my unusual outburst; I’ve read about an interesting CPLD design to replace a board full of TTL logic for ZX81 on VCFED site. The author published the CPLD schematic of design in Quartus, which he translated to AFT1508 programming file. Very cool design, yet only 40% of CPLD is utilized, so there are plenty room for more features and even more importantly, system level tinkering to fundamentally integrate ZX81 into a bigger design. This makes me think why I haven’t read more design integration like that and evolving system level thought experiments enabled by CPLD. My conclusion is that WinCUPL is to be blamed; our creativity is limited by tools we have.
Bill

[BigEd]

Maybe some ideas in this previous topic
Verilog to WinCUPL generator\workflow

[BigDumbDinosaur]

Jmstein7 wrote:

BigDumbDinosaur wrote:

Incidentally, in your code, I noted you defined your PINNODEs using distinct numbers.  In most cases, you should let the fitter make PINNODE assignments.  I have E-mail somewhere from Atmel technical support making that recommendation and explaining why, but can’t seem to locate it.

I read something about that, too. Not much help if you’re programming the CPLD after you’ve designed the hardware.

Buried logic usage is more-or-less independent of external pin assignments.  Even after you pin-lock your design, you can add or subtract PINNODE assignments and usually not have to worry about possible effects on the physical layout of your design.  All you have to do is not assign node numbers and let the fitter figure it out for you.