6502.org http://forum.6502.org/ |
|
WinCUPL out of product terms with Address Decoder GAL http://forum.6502.org/viewtopic.php?f=10&t=3673 |
Page 2 of 3 |
Author: | banedon [ Thu Apr 14, 2016 11:38 am ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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? |
Author: | John West [ Thu Apr 14, 2016 1:42 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | banedon [ Thu Apr 14, 2016 1:58 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
Hmmm 5 seems a bit poor compared with what GALS/PALS offer - unless they do the same thing and hide the fact... |
Author: | John West [ Thu Apr 14, 2016 3:39 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | BigDumbDinosaur [ Thu Apr 14, 2016 7:20 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | cbscpe [ Thu Apr 14, 2016 8:48 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | BigDumbDinosaur [ Thu Apr 14, 2016 9:24 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | banedon [ Thu Apr 14, 2016 10:54 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
Just tried the following as a test.... and it crashes WinCUPL when compiling . 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. |
Author: | BigDumbDinosaur [ Fri Apr 15, 2016 6:08 am ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
banedon wrote: Just tried the following as a test.... and it crashes WinCUPL when compiling ... 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... |
Author: | cbscpe [ Fri Apr 15, 2016 6:27 am ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | banedon [ Fri Apr 15, 2016 9:00 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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? |
Author: | cbscpe [ Fri Apr 15, 2016 9:50 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Author: | banedon [ Sun Apr 17, 2016 11:57 pm ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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: Attachment: Attachment: 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! |
Author: | banedon [ Tue Apr 19, 2016 12:27 am ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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: Attachment:
|
Author: | BigDumbDinosaur [ Tue Apr 19, 2016 6:12 am ] |
Post subject: | Re: WinCUPL out of product terms with Address Decoder GAL |
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. |
Page 2 of 3 | All times are UTC |
Powered by phpBB® Forum Software © phpBB Group http://www.phpbb.com/ |