6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sat Apr 27, 2024 7:12 pm

All times are UTC




Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next
Author Message
PostPosted: Sat Mar 16, 2024 5:38 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
After great frustration, and some time away, I'm going to try and return to a W65C816 project I've been working on:

http://forum.6502.org/viewtopic.php?f=10&t=7925#p105877

Long story short, I decided to go back to a basic W65C816 SBC with 32K RAM, 16K ROM, and an ACIA, just to play around with the chip. I'm also trying out CPLDs for the first time. I picked up an ATDT1150USB isp cable and a bunch of ATF1504AS, 10 ns, PLC44s. As a test, I've connected all the GND and VCC pins, as well as the JTAG pins to the ATDT1150USB. I downloaded ATMISP and verified the connection and erased the chip successfully a few times. So, I have the JTAG connection and programmer working.

I see a bunch of pins on the ATF1504AS aside from power and I/O, such as OE2, GCLK2, GCLR, OE1, GCLK1, GCLK3, PD, etc.

Which, if any, of these absolutely need to be connected? For my purposes, all I want to do - for the moment - is hook up A8 through A15 as inputs and scalar RAM, ROM, and ACIA enable outputs.

Thereafter, I'm wondering how difficult it is to use WinCUPL? I know Verilog, but I don't seem to see any way to, say, set up a bus for the address lines (8-bit) for decoding. For example, in Verilog I might do:

assign RAM_enable_n = ~(address[15:8] < 8'h80);

I don't see any way to do anything like that.

Jonathan


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 16, 2024 6:03 pm 
Offline

Joined: Wed Nov 11, 2020 10:42 pm
Posts: 96
Location: Kelowna Canada
Before plasmo jumps in I would recommend looking at his CRC65 in the 65816 version for some inspiration.


Top
 Profile  
Reply with quote  
PostPosted: Sat Mar 16, 2024 8:21 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
Jmstein7 wrote:
I see a bunch of pins on the ATF1504AS aside from power and I/O, such as OE2, GCLK2, GCLR, OE1, GCLK1, GCLK3, PD, etc.

The data sheet tells all.  :D

In applications in which the 1504 must be clocked, the usual practice is to apply the primary clock signal, e.g., Ø2 in a 65C816 system, to GCLK1.  If the CPLD is going to act as the bank bits latch, you could apply the inverted Ø2 used to gate the latch to GCLK2 and thus save a little bit of logic in the CPLD for other purposes.

If the CPLD design includes state (bank bits would be considered state) that should be initialized to a known condition at system power-on or reset, GCLR should be wired to the reset circuit and logic written to clear state when GCLR is driven low.

Otherwise, you are free to use pins however you see fit, subject only to the I/O direction they support.  Be careful to not assign the JTAG pins to any logic functions.  Once you do that and have programmed the CPLD, it can no longer be programmed via JTAG.

The ATF1504AS has a lot of capability for a device of its size, not least of which is the concept of buried logic in the form of nodes (referred to in equations with the PINNODE keyword).  Use of buried logic is key to setting up virtual registers, bank bit latches and state machines.

I suggest you design your logic before you design your circuit.  Let the fitter make most of the CPLD’s pin assignments for you, only “hard-wiring” things such as the clock and reset inputs.  This way, usage of the device’s logic resources will be more balanced and performance will be optimized.  If you manually assign all pins, your design may compile and simulate, but not fit due to excessive product terms being applied to a single macrocell.

As for your physical hardware layout, all power and ground pins on the 1504 must be connected.  Each power pin must be bypassed and due to the amount of current the 1504 can potentially draw as circuit conditions change (a lot of logic could simultaneously change state), power and ground connections should be robust.  Ground bounce and VCC sag are never desirable, but are especially bad with programmable logic.

Note that the 1504’s outputs are specified as TTL-compatible, with a guaranteed VOH of 2.4 volts—they are not CMOS outputs.  In practice, an output that is lightly loaded and driven high will be in the 3.2 volt range (3.4 volts is the theoretical maximum).  According to tests run by Jeff (Dr Jefyll), the 65C816’s inputs recognize ~2.6 volts as a valid logic 1 when VCC is 5 volts, so you should be okay.  Devices such as EPROMs and SRAMs typically have TTL-compatible inputs, so they too will be okay.

Your intended design as you describe it seems as though you could be better served by using a GAL instead of a CPLD.  In particular, it sounds as though you aren’t planning to use extended RAM, which means no bank latching is needed.  A 22V10 should have enough logic to do what you want, and would be easier to work with, I’d think.

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 12:40 am 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
BigDumbDinosaur wrote:
Jmstein7 wrote:
.
Your intended design as you describe it seems as though you could be better served by using a GAL instead of a CPLD.  In particular, it sounds as though you aren’t planning to use extended RAM, which means no bank latching is needed.  A 22V10 should have enough logic to do what you want, and would be easier to work with, I’d think.


Thanks, BDD. Actually, the current design is a warm-up exercise. I want to get to learn how to use these handy dandy little chips. Ultimately, I’m going to want to use it to latch the bank address and data lines. I read somewhere that I would need the 7ns version for that. I don’t know if that’s accurate - I’m using the 10ns 5V variant.

And, winCUPL - it’s weird. Is there any way I can do this using Verilog?

Thanks!

Jonathan


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 2:54 am 
Offline

Joined: Fri Dec 21, 2018 1:05 am
Posts: 1076
Location: Albuquerque NM USA
No verilog for WinCUPL, not even schematic entry. Its design entry uses the original sum-of-product logic expression.

If I were designing ATF1504 with WinCUPL (quite unlikely), I would draw out the design in schematic and then translate it into sum of products and use PINNODE for buried flip flop. It is painful. I rather design in Quartus in either verilog or schematic, then translate to ATF150x using POF2JED.

Since you already plan to use ACIA and ROM, I agree with BDD that you should first design a working system with PLD such as 22V10 and connect CPLD in parallel to learn about it. Then you can gradually transfer the functions from PLD to CPLD. You can eliminate external functional blocks like ACIA and ROM as you transition to CPLD.
Bill


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 2:59 am 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
ChatGPT suggested this code for WinCUPL:
Code:
 /* *************** INPUT PINS ******************** */
PIN     =  A_8; /* Address bit 0 (LSB) */
PIN     =  A_9; /* Address bit 1       */
PIN     =  A_10; /* Address bit 2       */
PIN     =  A_11; /* Address bit 3       */
PIN     =  A_12; /* Address bit 4       */
PIN     =  A_13; /* Address bit 5       */
PIN     =  A_14; /* Address bit 6       */
PIN     =  A_15; /* Address bit 7 (MSB) */

/* *************** OUTPUT PINS ******************** */
PIN     =  ROM; /* Chip Enable Bar for ROM, active low */
PIN     =  RAM; /* Chip Enable Bar for RAM, active low */
PIN     =  ACIA; /* Chip Enable Bar for ACIA, active low */

/* *************** LOGIC EQUATIONS ******************** */

/* When A_15 downto A_8 < $80, RAM is enabled, active-low */
RAM = !(A_15 # A_14 # A_13 # A_12 # A_11 # A_10 # A_9 # !A_8);

/* When A_15 downto A_8 >= $C0, ROM is enabled, active-low */
ROM = !(A_15 & A_14 & !(A_13 # A_12 # A_11 # A_10 # A_9 # A_8));

/* When A_15 downto A_8 >= $80 and < $81, ACIA is enabled, active-low */
ACIA = !((A_15 & !A_14 & !A_13 & !A_12 & !A_11 & !A_10 & !A_9 & !A_8) #
         (A_15 & !A_14 & !A_13 & !A_12 & !A_11 & !A_10 & !A_9 & A_8)); 


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 8:38 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
Jmstein7 wrote:
ChatGPT suggested this code for WinCUPL:
Code:
 /* *************** INPUT PINS ******************** */
PIN     =  A_8; /* Address bit 0 (LSB) */
PIN     =  A_9; /* Address bit 1       */
PIN     =  A_10; /* Address bit 2       */
PIN     =  A_11; /* Address bit 3       */
PIN     =  A_12; /* Address bit 4       */
PIN     =  A_13; /* Address bit 5       */
PIN     =  A_14; /* Address bit 6       */
PIN     =  A_15; /* Address bit 7 (MSB) */

/* *************** OUTPUT PINS ******************** */
PIN     =  ROM; /* Chip Enable Bar for ROM, active low */
PIN     =  RAM; /* Chip Enable Bar for RAM, active low */
PIN     =  ACIA; /* Chip Enable Bar for ACIA, active low */

/* *************** LOGIC EQUATIONS ******************** */

/* When A_15 downto A_8 < $80, RAM is enabled, active-low */
RAM = !(A_15 # A_14 # A_13 # A_12 # A_11 # A_10 # A_9 # !A_8);

/* When A_15 downto A_8 >= $C0, ROM is enabled, active-low */
ROM = !(A_15 & A_14 & !(A_13 # A_12 # A_11 # A_10 # A_9 # A_8));

/* When A_15 downto A_8 >= $80 and < $81, ACIA is enabled, active-low */
ACIA = !((A_15 & !A_14 & !A_13 & !A_12 & !A_11 & !A_10 & !A_9 & !A_8) #
         (A_15 & !A_14 & !A_13 & !A_12 & !A_11 & !A_10 & !A_9 & A_8)); 

The above definitely shows the difference between artificial “intelligence” and a skilled, human designer when it comes to writing code.  :D

Active-low output pins should be declared as active low and the logic that controls them should be written as positive.  For example, your ROM chip-enable pin should be declared as...

Code:
pin                       = !ROM;          /* output  ROM chip select           */

...and the logic that controls it should be written as positive, for example...

Code:
ROM             = <your_rom_select_logic>;

...where <your_rom_select_logic> would express the conditions under which ROM would be selected.

In programmable logic design, you think in terms of “yes” and “true” or “no” and “false”, not “high” and “low”.  “Yes,” select the ROM when “X”, “Y” and “Z” are “true”, and “A”, “B” and “C” are “false”...that sort of thing.  Declaring the pin as low-true (!ROM in the pin declaration) insulates the electrical behavior from the logical behavior.  In general, declaring an output pin as active-high and then negating the logic that controls it will cause more product terms to be used than when the pin is declared active-low and positive logic is employed.  Best utilization of the device’s logic resources occurs when only positive logic is used.

In the case of input pins, those which are connected to an active-low driver should so declared.  For example, if a pin named RST is being driven by the reset circuit that is also connected to the 65C816’s RESETB pin, you would declare !RST, and an equation that refers to it would be written as...

Code:
<condition> = RST;

The above would cause <condition> to become “true” when the RST pin is driven low.

In logic that refers to ranges of addresses, it is more efficient to declare a group of address pins as a “field,” which makes referring to addresses more convenient and less error-prone.  A human programmer would write something like...

Code:
field addr      = [A_15..A_8];               /* address MSB        */

...and then write equations such as...

Code:
RAM = addr:['h'00xx..8Fxx];  /* RAM from $0000 to $8FFF */
ROM = addr:['h'C0xx..CFxx];  /* ROM from $C000 to $CFFF */

...which is easier for the casual reader to understand.

I’ve attached some reading material for you that goes into some depth on this.  You may find it interesting.  As for doing this in Verilog, no such luck.  CUPL is okay as a logic language.  The WinCUPL environment can be cantankerous—the compiler tends to be fussy and occasionally crash-prone.  The simulator apparently has problems with memory leaks, so you periodically have to quit and restart it.  Just save early and save often!

Attachment:
File comment: CUPL Reference Manual
cupl_reference.pdf [814.53 KiB]
Downloaded 13 times

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


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 8:55 am 
Offline

Joined: Sun Jun 29, 2014 5:42 am
Posts: 337
This thread covers a couple of options for using Verilog with ATF15xxAS parts:
Verilog to WinCUPL generator\workflow

Dave


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 8:57 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10793
Location: England
Thanks Dave!


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 3:59 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
BigDumbDinosaur wrote:

The above definitely shows the difference between artificial “intelligence” and a skilled, human designer when it comes to writing code.  :D
...
I’ve attached some reading material for you that goes into some depth on this.  You may find it interesting.  As for doing this in Verilog, no such luck.  CUPL is okay as a logic language.  The WinCUPL environment can be cantankerous—the compiler tends to be fussy and occasionally crash-prone.  The simulator apparently has problems with memory leaks, so you periodically have to quit and restart it.  Just save early and save often!

Attachment:
cupl_reference.pdf


Wow! Thank you, BDD. That makes more sense. And, thanks for the manual.

Jonathan


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 4:00 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
hoglet wrote:
This thread covers a couple of options for using Verilog with ATF15xxAS parts:
Verilog to WinCUPL generator\workflow

Dave


As always, thank you, Dave! How are your projects going?

Jonathan


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 4:01 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
BigEd wrote:
Thanks Dave!


Hi, Ed. Long time!

Jonathan


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 4:50 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
How about this?

Code:
/* *************** INPUT PINS ******************** */
PIN     =  A_8; /* Address bit 0 (LSB) */
PIN     =  A_9; /* Address bit 1       */
PIN     =  A_10; /* Address bit 2       */
PIN     =  A_11; /* Address bit 3       */
PIN     =  A_12; /* Address bit 4       */
PIN     =  A_13; /* Address bit 5       */
PIN     =  A_14; /* Address bit 6       */
PIN     =  A_15; /* Address bit 7 (MSB) */

/* *************** OUTPUT PINS ******************** */
PIN     =  !ROM; /* Chip Enable Bar for ROM, active low */
PIN     =  !RAM; /* Chip Enable Bar for RAM, active low */
PIN     =  !ACIA; /* Chip Enable Bar for ACIA, active low */

/* *************** LOGIC EQUATIONS ******************** */

field addr =    [A_15..A_8];            /* address MSB */

RAM    =    addr:['h'00xx..7Fxx];   /* RAM from $0000 to $7FFF */
ROM    =    addr:['h'C0xx..FFxx];   /* ROM from $C000 to $FFFF */
ACIA    =    addr:['h'80xx..81xx];   /* ROM from $8000 to $8100 */


Top
 Profile  
Reply with quote  
PostPosted: Sun Mar 17, 2024 10:36 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8144
Location: Midwestern USA
Jmstein7 wrote:
How about this?

Code:
/* *************** INPUT PINS ******************** */
PIN     =  A_8; /* Address bit 0 (LSB) */
PIN     =  A_9; /* Address bit 1       */
PIN     =  A_10; /* Address bit 2       */
PIN     =  A_11; /* Address bit 3       */
PIN     =  A_12; /* Address bit 4       */
PIN     =  A_13; /* Address bit 5       */
PIN     =  A_14; /* Address bit 6       */
PIN     =  A_15; /* Address bit 7 (MSB) */

/* *************** OUTPUT PINS ******************** */
PIN     =  !ROM; /* Chip Enable Bar for ROM, active low */
PIN     =  !RAM; /* Chip Enable Bar for RAM, active low */
PIN     =  !ACIA; /* Chip Enable Bar for ACIA, active low */

/* *************** LOGIC EQUATIONS ******************** */

field addr =    [A_15..A_8];            /* address MSB */

RAM    =    addr:['h'00xx..7Fxx];   /* RAM from $0000 to $7FFF */
ROM    =    addr:['h'C0xx..FFxx];   /* ROM from $C000 to $FFFF */
ACIA    =    addr:['h'80xx..81xx];   /* ROM from $8000 to $8100 */

Looks as though it should work.

I should point out that that same code would work with a GAL.  However, WinCUPL’s fitter doesn’t get involved in the design flow with a GAL, which simply means you have to decide which pins to connect to what.  Microchip’s ATF22V10C has 12 input-only pins, one being a clock input if clocking is needed, and ten I/O pins—the latter may be defined for input or output.  It’s available in a 7.5ns version, which is the pin-to-pin rating.  It’s difficult to achieve that level of performance with discrete logic.

The 22V10, despite being “obsolete,” offers quite a bit of capability.  That’s why I and Bill (plasmo) suggested you get your feet wet with a GAL before working with the more complicated CPLD.

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


Top
 Profile  
Reply with quote  
PostPosted: Mon Mar 18, 2024 2:02 pm 
Offline

Joined: Sun May 30, 2021 2:16 am
Posts: 374
BigDumbDinosaur wrote:

Looks as though it should work.

I should point out that that same code would work with a GAL.  However, WinCUPL’s fitter doesn’t get involved in the design flow with a GAL, which simply means you have to decide which pins to connect to what.  Microchip’s ATF22V10C has 12 input-only pins, one being a clock input if clocking is needed, and ten I/O pins—the latter may be defined for input or output.  It’s available in a 7.5ns version, which is the pin-to-pin rating.  It’s difficult to achieve that level of performance with discrete logic.

The 22V10, despite being “obsolete,” offers quite a bit of capability.  That’s why I and Bill (plasmo) suggested you get your feet wet with a GAL before working with the more complicated CPLD.


It worked. So, that's good.

For the GALs, they're also JTAG, right? I don't have to get another programmer? They're kind of expensive.

I saw ProChip Designer on the Microchip site, when I was getting WinCUPL and ATMISP. Is that any good? It seems to permit the use of HDL, though I guess you have to buy a license if you want to synthesize anything? Doesn't that sort of render it useless?

EDIT: I was just browsing on Mouser and I saw the following:
ATF750C-7PX
ATF750C-7JX
ATF1502AS-7JX44

The last one being a "cut down" version of the one I'm using (but 7.5ns)

Do these have enough to demultiplex the Bank Addresses from the Data lines, while also decoding addresses?

I looked at the datasheet for the ATF750Cs, and there is nothing about programing them.

Jonathan


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 39 posts ]  Go to page 1, 2, 3  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: