6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Thu Nov 21, 2024 12:55 pm

All times are UTC




Post new topic Reply to topic  [ 41 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Thu Apr 14, 2016 11:38 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Both packages have just arrived. All I have to do now is build myself a PLCC to DIP adapter for testing/programming. Fun!
I then need to see about writing some basic 'code' to see what can be done.
BTW are the product terms set per pin or can they be split up as and how you want them?


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 1:42 pm 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 336
banedon wrote:
BTW are the product terms set per pin or can they be split up as and how you want them?


The ATF1504AS has 64 macrocells, each with 5 product terms. Since you've got the 44 pin version, there are many macrocells not connected to pins. If you need more than 5 product terms anywhere, you can put some into one of the unconnected macrocells and feed its output back into the matrix.

But that adds to the delay. To speed things up, there's an optional sixth input to the or gate in each macrocell, which can take the output of the or gate of the neighbouring cell directly. If that cell is unused, you can use that input to increase the number of product terms with a much smaller delay.

The compiler should do all of this automatically. If you want it to use the fast path you'll have to give it some help by assigning your more complicated logic to pins that have unused neighbour macrocells. Page 21 of the datasheet gives the map.

I see JTAG pins on the pinout. I'm not familiar with Kanda's programmer, but there should be no need for an adapter for programming. Just add a header to your board, and program in circuit. That's what JTAG is there for.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 1:58 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Hmmm 5 seems a bit poor compared with what GALS/PALS offer - unless they do the same thing and hide the fact...


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 3:39 pm 
Offline

Joined: Tue Sep 03, 2002 12:58 pm
Posts: 336
Remember that there are more macrocells than pins. The idea is that you probably don't need that many product terms on every single output. You use the local ones in the simpler cases, and distribute the spares among the ones that need more. It's a more flexible architecture than a GAL.

There's an xor in each macrocell as well. In some cases that can greatly reduce the number of product terms you need.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 7:20 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8503
Location: Midwestern USA
John West wrote:
The ATF1504AS has 64 macrocells, each with 5 product terms. Since you've got the 44 pin version, there are many macrocells not connected to pins. If you need more than 5 product terms anywhere, you can put some into one of the unconnected macrocells and feed its output back into the matrix. But that adds to the delay.

Logic doubling in the ATF150x series, which is the process of "borrowing" otherwise unused macrocells (MCs) to implement complicated logic that would otherwise fail with a "too many product terms" error, is a very useful feature that does not significantly affect pin-to-pin propagation time. Use of pin nodes (discussed below) and cascaded logic add a small amount of internal prop time that can be largely ignored in 65C02 or 65C816 designs, even at 20 MHz. So don't hesitate to use these capabilities in your designs.

One can specify logic doubling in the CUPL source file, and the "borrowing" of unused MCs will occur automatically as needed. The statement is as follows:

Code:
property   atmel {logic_doubling=on};

Property statements must be placed in the file after the device declaration but before any pin assignments or logic statements. Here are the property statements I used in the CUPL code for POC V2's CPLD design:

Code:
property   atmel {cascade_logic=on};
property   atmel {logic_doubling=on};
property   atmel {output_fast=off};
property   atmel {pin_keep=off};
property   atmel {preassign=keep};
property   atmel {security=off};
property   atmel {xor_synthesis=on};

The property atmel {output_fast=off}; statement is interesting. This statement sets the output slew rate to fast or slow, and could be useful in diagnosing circuit instability problems. Even when set to slow, as is the above case, slew is still quite fast. I plan to try it both ways once I get POC V2 constructed.

Also useful are "pin nodes," which can be described as "virtual" pins. Pin nodes are the key to setting up latches and flops, as well as implementing state machines. Unlike using actual pins in a GAL, pin nodes don't use any physical resources and have a vanishingly small effect on total device propagation time.

Here are the pin node assignments I used for my POC V2 design:

Code:
/*
=========================
BURIED LOGIC DECLARATIONS
=========================
*/
pinnode   = [blatch0..3];                         /* bank address latches                 */
pinnode   = [hmumcfg0..3];                        /* hardware management unit             */
pinnode   = wsff;                                 /* wait-state flip-flop                 */

pinnode   = bank0;                                /* 1 = address is $000000-$00FFFF       */
pinnode   = basram;                               /* 1 = address is $000000-$00BFFF       */
pinnode   = bbus;                                 /* 1 = valid bank address               */
pinnode   = cblk;                                 /* 1 = address is $00C000-$00CFFF       */
pinnode   = dblk;                                 /* 1 = address is $00D000-$00DFFF       */
pinnode   = eblk;                                 /* 1 = address is $00E000-$00FFFF       */
pinnode   = extram;                               /* 1 = address is $010000-$07FFFF       */
pinnode   = hmusel;                               /* 1 = HMU being accessed               */
pinnode   = ioblk;                                /* 1 = I/O address space being accessed */
pinnode   = iosel;                                /* 1 = I/O device selected              */
pinnode   = mcfgsel;                              /* 1 = HMU configuration being accessed */
pinnode   = ramsel;                               /* 1 = RAM selected                     */
pinnode   = rdflag;                               /* 1 = data fetch in progress           */
pinnode   = rdyout;                               /* 1 = MPU wait-stated                  */
pinnode   = rhflag;                               /* 1 = data fetch on high clock         */
pinnode   = romsel;                               /* 1 = ROM selected                     */
pinnode   = vab;                                  /* 1 = address bus valid                */
pinnode   = vplatch;                              /* 1 = hardware vector being accessed   */
pinnode   = wdflag;                               /* 1 = data store in progress           */
pinnode   = wsflag;                               /* 1 = wait-state in progress           */

The first, second and third pin node declarations set up D-type flip-flops and the rest act as flags.

One of the things I did when I developed my design was to allow the fitter to automatically assign pins for all signals that did not have to be attached to a specific pin. The JTAG pins, of course, are not assigned, since using them for logic I/O makes it impossible to subsequently reprogram the device via JTAG. I statically assigned the Ø2 input, as well as reset (RESB). Everything else was worked out by the fitter. The result was this:

Code:
                                 R    P                         
                           V  V  E V  H  G  A  A                 
                  D  R  W  C  P  S D  I  N  1  1                 
                  1  D  D  C  A  B A  2  D  3  1                 
               ____________________________________             
              /   6  5  4  3  2  1 44 43 42 41 40  \             
         TDI |  7                                39 | A10       
          D2 |  8                                38 | TDO       
          D0 |  9                                37 | A9         
         GND | 10                                36 | A8         
         IO0 | 11                                35 | VCC       
         IO1 | 12            ATF1504             34 | A12       
         TMS | 13          44-Lead PLCC          33 | D3         
         RDY | 14                                32 | TCK       
         VCC | 15                                31 | RST       
         IO2 | 16                                30 | GND       
         IO3 | 17                                29 | ROM       
             |   18 19 20 21 22 23 24 25 26 27 28   |           
              \____________________________________/             
                 I  A  A  A  G  V  R  A  A  R  R                 
                 O  1  1  1  N  C  W  1  1  A  A                 
                 4  8  6  7  D  C  B  5  4  M  M                 
                                            1  0

From that, I did the PCB layout.

For the most part, one need not get overly concerned about how the internal "connections" are made. The purpose of having a programming language like CUPL is to relieve the designer of having to deal with the tedious minutia of the CPLD's architecture. Back in the early days of programmable logic, the designer did have to deal with that stuff to stay within the limitations of the targeted device. Not so much anymore.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 8:48 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi banedon,

I use WinCUPL as well. However I recommend to use your own text editor to edit the PLD files. As for the 5 product terms, that is plenty enough. In case you need more PT for an equation then adjacent macro cells can be put together (the software does this automatically) and use the cascade feature. This adds only very little delay, approx 0.8ns. As for the adapter, I use these small PCBs and the TQFP-44 versions of the ATF1504 http://forum.6502.org/viewtopic.php?f=4&t=3488&p=41106&hilit=adapter+tqfp#p41106 I also bought one of these PLCC-84 adapters to test my ATF1508 designs. They also have PLCC-44 adapters.


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 9:24 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8503
Location: Midwestern USA
cbscpe wrote:
I use WinCUPL as well. However I recommend to use your own text editor to edit the PLD files.

I use UltraEdit to write the source code until I get to the point where I'm ready to compile and simulate. At that point I switch to the WinCUPL editor, since compilation and simulation are linked in. It's a little more convenient during the testing phase.

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


Top
 Profile  
Reply with quote  
PostPosted: Thu Apr 14, 2016 10:54 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Just tried the following as a test.... and it crashes WinCUPL when compiling :roll:.

Code:
Name     AddressDecoderTest;
PartNo   00;
Date     14.04.2016;
Revision 01;
Designer Banedon;
Company  None;
Assembly None;
Location GB;
Device   f1504ispplcc44

property   atmel {cascade_logic=on};
property   atmel {logic_doubling=on};
property   atmel {output_fast=off};
property   atmel {pin_keep=off};
property   atmel {preassign=keep};
property   atmel {security=off};
property   atmel {xor_synthesis=on};

/*
 * Inputs
 */

Pin 40 = phi2;
Pin 39 = cpuRW;
Pin [4..6,8..9,12,14,16] = [A15..8];

Pin 17 = romEN;

/*
 * Outputs
 */

Pin [18..21,24,26..27] = ![S0..6];

Pin 29 = !aWR;
Pin 31 = aRD;

aRD = !cpuRW;
aWR = !cpuRW & phi2;

/*
 * Main
 */

FIELD AddressBus = [A15..0];
FIELD Selects = [S6..0];

TABLE AddressBus => Selects {
   [00xx..7Fxx] => 'b'0001000;   /* RAM   */
   [81xx..81xx] => 'b'0100000;   /* VIA#1 */
   [82xx..82xx] => 'b'0000100;   /* VIA#2 */
   [83xx..83xx] => 'b'0000010;   /* VIA#3 */
   [84xx..84xx] => 'b'0000001;   /* VIA#4 */
   [85xx..85xx] => 'b'0010000;   /* ACIA  */
   [86xx..8Fxx] => 'b'0001000;   /* RAM   */
   [90xx..FFxx] => 'b'0001000 & !cpuRW;           /* ROM WRITE --- but write to RAM instead */
   [90xx..FFxx] => 'b'1000000 & cpuRW & !romEN; /* ROM READ ---- fine. */
   [90xx..FFxx] => 'b'0001000 & romEN;         /* ROM READ, but ROM enable is disabled ---- READ from RAM instead */
}


I'll have a play around, but as I've double checked the device and ensured that only I/O pins are being used I thought I'd got it right.


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 15, 2016 6:08 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8503
Location: Midwestern USA
banedon wrote:
Just tried the following as a test.... and it crashes WinCUPL when compiling :roll:...

Code:
Pin [4..6,8..9,12,14,16] = [A15..8];

Just for grins, try converting the above statement to individual pin assignments, 4 = A15, 5 = A14, etc. I have a suspicion... :)

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


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 15, 2016 6:27 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Hi banedon,

I copy&pasted your design file into the editor of WinCUPL and it does not crash. (except I had to remove the hex character 0xA0 caused by copying from the web-page to space). Which editor did you use to create the file? WinCUPL is very sensitive to the file format and non-ASCII characters and that causes WinCUPL to crash very easily. Make sure that your file only contains <CR>, <LF>, <TAB> and ASCII values in the range 0x20..0x7E. Also some words about using WinCUPL

1. Make sure your source file has no non-ASCII characters and only the DOS text file format with the correct CRLF at the end. Previously I used the text editors on my MAC (WinCUPL runs in a virtual machine) and I got my bunch of surprises, UltraEdit is a very good text editor, I also used it a long time ago and I still think it is one of the best, currently I use TextPad, in my opinion, when UltraEdit has 10 out of 10 points then TextPad has 9 out of 10 (I use TextPad because at my work place it is available, so I bought it for private use to have the same editor everywhere). There is also NotePad+ and many others I don't have any experience.
2. You should only use the atmel properties when you need them explicitely, especially the properties cascade_logic, logic_doubling are handled automatically and need to be switched on or off only if you really understand what they do and if they are required, activating them on a standard base for complex designs can be counterproductive
3. When I start a design I normally do not assign pin numbers, so instead of "Pin 40 = phi2;" I only say "Pin = phi2;". Although you have 32 IO pins they are not all equal. There are some special pins like Pin 1, 43 and 44 on a PLCC which cannot be used as output, in addition Pin 1, 2, 41, 43 and 44 serve special functions in regard of global clear (e.g. used as RESET to initialize the flip-flops), global clocks or global output enables. So you should start your design without specifying the pin numbers, once your design has reached a mature state you can then copy the allocation made by WinCUPL to the source to make sure that pins are locked to known pin-numbers so you can make changes without redesigning your PCB or breadboard layout.

There are also other conditions which require WinCUPL to freely allocate PINs else the design will not "fit". You need to be aware of the fact that the CPLD is divided into blocks of 16 macro cells (this concerns all three CPLDs 1502/4/8). Although all pins are available internally, and that concerns IO pins and buried macro cells, you can only input 40 signals to each block, each block can have of course a different set of 40 input signals. This restriction is called "Fan-In". Of course there are also local signals (the outputs of the 16 macro-cells within a block) that can be fed back that do not contribute to the "Fan-In" limitation, but these signals are only usable within the block. Within a block you can cascade the product terms. Again there is a limitation. Cascading only works for certain macro cell compinations, e.g. from the output file of the fitter you see at the bottom the following information in respect to your design and chip package. Also the special pins do not contribute to the "Fan-In" limitation, so let WinCUPL decide which pins should go to special pins to minimize "Fan-In".

Code:
MCell Pin# Oe   PinDrive  DCERP  FBDrive  DCERP  Foldback  CascadeOut     TotPT output_slew
MC1   12   --   A10       INPUT  --              --        --             0     slow
MC2   0         --               --              --        --             0     slow
MC3   11        --               --              --        --             0     slow
MC4   9    --   A11       INPUT  --              --        --             0     slow
MC5   8    --   A12       INPUT  --              --        --             0     slow
MC6   0         --               --              --        --             0     slow
MC7   0         --               --              --        --             0     slow
MC8   7    --   TDI       INPUT  --              --        --             0     slow
MC9   0         --               --              --        --             0     slow
MC10  0         --               --              --        --             0     slow
MC11  6    --   A13       INPUT  --              --        --             0     slow
MC12  0         --               --              --        --             0     slow
MC13  0         --               --              --        --             0     slow
MC14  5    --   A14       INPUT  --              --        --             0     slow
MC15  0         --               --              --        --             0     slow
MC16  4    --   A15       INPUT  --              --        --             0     slow
MC17  21   on   S3        C----  --              NA        --             5     slow


A macro cell can only borrow cascaded product terms from cells within the same block and from cells that are not linked to output pins. MC4 on Pin 9 can borrow PTs from MC2,3 only if MC1 is used as output. MC5 on Pin 8 cannot borrow any PT when MC4 pin 8 is an output. However MC11 on Pin 6 can always borrow PT from MC6,7,8,9,10, so it can borrow up to 40 PT, this is also the maximum. Borrowing is called "cascade_logic".

Regards

Peter

P.S. the pin allocation you used in your design works perfectly well, as I could tell from my run with your design, the syntax is correct, so BDDs suspicion is not your problem.


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 15, 2016 9:00 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Thanks for the advice, Peter. I didn't have time to look into the issue last night, but managed to compile the design/code at work. Tried it on both computers at home... lock up.
I moved the test code out of the profile (was in documents) and into the root off a sub folder and hey presto it worked. Seen this before with WinCUPL - it gets very funny about profiles. And it's not down to NTFS permissions.
Not a major problem though as I don't keep my main projects in my profile/Documents :).

As for the other information that you posted: I didn't know that WinCUPL supported dynamic pin assignments. I'll certainly have a play around with this. I assume that you read the actual assigned pins in the .DOC file?


Top
 Profile  
Reply with quote  
PostPosted: Fri Apr 15, 2016 9:50 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
Depends, for GAL it is in the doc file, for CPLD I always consult the .fit report which shows a nice ASCII layout of the package and other useful information. And most importantly at the bottom it tells you whether the design fits.


Top
 Profile  
Reply with quote  
PostPosted: Sun Apr 17, 2016 11:57 pm 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Just completed my home brew PLCC44 to DIP44 adapter. I think I hate point to point soldering now lol.
Here it is. I haven't made it look good and the soldering is a bit pants - mostly as I need a smaller tip for my Weller and, well, I'm not hugely great at small/close in work. However, the solder blobs on the pins were put there to keep the pin headers in place. I'll clean those up later (and get rid of the remaining flux residue).

The wires are colour coded thus:

Blue - Inputs only or special
Green - I/O
Yellow - I/O or special
Red - VCC/Power
Black - Ground

Each pair of VCC/GND pins has a 100nF (0.1uF) decoupling capacitor.

Attachment:
PLCC_DIP_Adapter_TOP.gif
PLCC_DIP_Adapter_TOP.gif [ 145.29 KiB | Viewed 4708 times ]

Attachment:
PLCC_DIP_Adapter_UNDERSIDE.gif
PLCC_DIP_Adapter_UNDERSIDE.gif [ 184.11 KiB | Viewed 4708 times ]

Attachment:
PLCC_DIP_Adapter_POPULATED.gif
PLCC_DIP_Adapter_POPULATED.gif [ 248.66 KiB | Viewed 4708 times ]


I'll try and set up a JTAG (ISP) header tomorrow and see if I can write a basic design to a CPLD.

Hope the flippin' thing works! :mrgreen:


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 19, 2016 12:27 am 
Offline
User avatar

Joined: Sun Sep 08, 2013 10:24 am
Posts: 740
Location: A missile silo somewhere under southern England
Got it working, so added the JTAG header on the end and that now works as well - at least for a blank check. I'll do some more testing tomorrow.

Attachment:
20160419_005651_002.gif
20160419_005651_002.gif [ 537.92 KiB | Viewed 4683 times ]

Attachment:
20160419_005855.gif
20160419_005855.gif [ 530.51 KiB | Viewed 4683 times ]


Top
 Profile  
Reply with quote  
PostPosted: Tue Apr 19, 2016 6:12 am 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8503
Location: Midwestern USA
banedon wrote:
Got it working, so added the JTAG header on the end and that now works as well - at least for a blank check. I'll do some more testing tomorrow.

The successful blank check is a good sign. If the JTAG setup wasn't right you would have had an immediate failure. I don't think you'll have any trouble programming the thing.

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


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

All times are UTC


Who is online

Users browsing this forum: No registered users and 3 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: