(sorry for the bad pun, couldn't help myself)

So, I've been trying my hand at CUPL in an attempt to create a couple of support chips for my next build, both of which are designed to fit on to an Atmel/Microchip ATF1504ASL-25JU44, a PLCC44 CPLD with 32 I/Os and 64 macrocells:

Chip 1. An extension of Daryl's 65SPI to include 16-bit transfers and
Chip 2. An MMU based on the 74LS612 MMU from TI, with rudimentary support for a protection rings.

I have carefully designed each to fit within the constraints of the ATF1504 architecture, and yet, when I came to implement the MMU, the CUPL fitter seems to be using an extra eight latches beyond what I think it should be using, which causes the design to fail, and I cannot figure out why.

I was hoping one of the PLD-happy people here might be able to help me track this problem down. Google-fu fails me here, there seems to be little-to-no help for CUPL on the interweb, and what there is is usually hideously out of date or downright confusing.

Attached are the CUPL source and the output of the fitter. If I reduce the size of the busses+registers, to 7 bits then the design does fit, but it still uses more latches than I'd expect it to, so I don't think its just that I've made a typo. Note the design is not finished; this is as far as I got before encountering the problem.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I don't have the architecture of this part handy, but it seems to me, from reading your source and the fitter report, that you're exceeding the FB inputs and the tool is having to "share" some of the unused resources in adjacent FB. From what I'm seeing in your code and extrapolating from the Xilinx 9500/Coolrunner CPLDs, I think that you're going to need a bigger part or scale back your logic to 6 or even 4 bits per mapping register. Eight 8-bit registers is going to need 64 macrocells. Even though you've declared them as buried, that by itself will likely prevent you from using the associated I/O pins for your output functions without some macrocells to support the multiplexer logic. Can't say my interpretation of your problem is correct, but I think this is the typical issue with this class of programmable logic.

_________________
Michael A.

Yes, I did have a theory running around my head that the output multiplexor might require things to loop back through, using up a few more macrocells. However, the ATF1504 datasheet, figure 1, shows the macrocell diagram. It includes - as i'm reading it - the ability to have both a path from the MUX to the I/O Pin and to the Latch, but also from the Latch to the I/O pin and feedback into the interconnect array. So, unless there's a restriction on these combinations, it seems to me that theoretically you could have a setup whereby the Latch feeds back into the matrix, which goes into the MUX, which implements the multiplexor, which then bypasses the Latch out to the I/O pin. Hence, only one macrocell is used.

I've made a crude drawing of the datapath I just tried to describe, see attached.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I suppose that it may be possible to make the connections as you described and annotate on your diagram. I will not claim knowledge of CUPL, as my use of it is very dated. (The last I used it was with some GALs 15-20 years ago.) Describing the connectivity as you've drawn in the architecture diagram has always eluded me. Perhaps it's limitation of the automatic fitter. The Xilinx CPLDs have virtually the same architecture, and I've not been particularly successful in describing the type of connections you've shown.

Perhaps BDD, who uses these Atmel parts a lot, can suggest an approach to accomplishing your goals with the semantics / syntax of CUPL.

My apologies for not being more helpful.

_________________
Michael A.

In your source code, you have:

Code:

/* Internal Nodes */
NODE [map0reg0..7];      /* Map Register 0 */
NODE [map1reg0..7];      /* Map Register 1 */
NODE [map2reg0..7];      /* Map Register 2 */
NODE [map3reg0..7];      /* Map Register 3 */
NODE [map4reg0..7];      /* Map Register 4 */
NODE [map5reg0..7];      /* Map Register 5 */
NODE [map6reg0..7];      /* Map Register 6 */
NODE [map7reg0..7];      /* Map Register 7 */

Try this:

Code:

/* Internal Nodes */
PINNODE [mapareg0..7];      /* Map Register 0 */
PINNODE [mapbreg0..7];      /* Map Register 1 */
PINNODE [mapcreg0..7];      /* Map Register 2 */
PINNODE [mapdreg0..7];      /* Map Register 3 */
PINNODE [mapereg0..7];      /* Map Register 4 */
PINNODE [mapfreg0..7];      /* Map Register 5 */
PINNODE [mapgreg0..7];      /* Map Register 6 */
PINNODE [maphreg0..7];      /* Map Register 7 */

...and see what happens. Be sure to make corresponding changes in other statements.

You cannot use a numeral in the register name and also specify an array for that same name, as you are doing. For example, map0reg0..7 is confusing to the compiler, as you have double-indexed the name (0, followed by the 0..7 declaration). Read up on the CUPL programming manual for more detals.

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

Using PINNODE causes a compilation error; sticking to NODE but using alphabetic chars makes no difference - fitter still reports 72 macrocells rather than 64, and therefore failure.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

It's likely the design simply won't fit the 1504. You could try disabling logic doubling on the off-chance it's causing "over-borrowing" of logic from adjacent MCs, but I doubt that will matter.

Just for grins, switch the device to the 1508 (f1508ispplcc84) with suitable changes to match the reset and global clock (GCLK) inputs, and try again with PINNODE declarations (not NODE, which doesn't work as expected in the ATF15xx devices). The 1508 has twice the MCs of the 1504, therefore this experiment should demonstrate if the failure to fit was due to a lack of logic resources or something else. Be sure all diagnostics that occur during the compilation stage are cleared up before you attempt to fit the design.

The .FIT file will give you details about how the fitter worked through the design. You should be able to determine exactly where the failure occurred by studying .FIT and some of the other files, such as .DOC.

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

What is the difference between a PINNODE and a NODE? Most of the stuff I've read seems to use them interchangably. Also, just to be clear, I'm not against slimming the design down, I'm just trying to understand - as a learning exercise - why CUPL is behaving in a way I do not expect it to.

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

Regarding NODE vs. PINNODE, here's what I was told by Atmel:

Hi Bill,

The only difference between node and pinnode is that for node, the compiler will automatically assign the node #s for these signals where as for pinnode, the user can assign the node #s. Details of this are available in Section 1.1.11 of the CUPL Reference Manual (Help .. CUPL Programmers Reference). It is recommended for ATF15xx because when node is used, the compiler can assign an invalid node #. This will cause the fitter to report a warning message in the .FIT file.

Thanks & best regards,

Alan Wong
CSP Applications Engineering Manager / Atmel Corporation

Hence the recommendation to use PINNODE.

You also may find the below attachments useful.


Go to page 18 in the CUPL reference manual for a discussion on the use of PINNODE.

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

I decided to give this a try as I was thinking a few weeks back about converting my 65SPI from Xilinx to ATF.

I loaded your MMU source in my WinCUPL and have the same error messages. I then tried to remove 1 of the 8 registers and the error messages changed but still no fit. It leads me to think that there are not enough logic paths to support the decoding logic as it is being fitted. I did read that it does allow a buried register with pin IO connected to combinatorial logic, so I believe this may be possible with some optimization.

Thanks BDD for the reference material. I may play more with this over the weekend to see if I can make any headway. It will give me a chance to prepare for the conversion of the 65SPI.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

That would be great to have the 65SPI available again (and presumably at a lower power consumption) !

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

And if it won't work with just one ATF - don't hesitate to use another -


Regards,
Arne

So I did a lot of reading and some experimenting today. I can get a 7 8-bit registers to fit but even an 8th register with 2 bits won't fit. The nice thing is that when a design fits, all the resource mapping are given in the fit report. My hope is this will help decipher what part of the macrocell is the limiting factor. I first thought it might be only having 5 product terms. I also wonder if the OR gate from the Product term mux is an issue as when the register is buried, there's no path for the output of that OR to go.

I still need to research more. I am attaching a fit report for the 7 register version.

Daryl

_________________
Please visit my website -> https://sbc.rictor.org/

I am curious if there's been a resolution found for Alarm Siren's problem?

_________________
Michael A.

There is no solution. Eigth 8-bit registers require all 64 macrocells. Each output also requires a macrocell. It wonˋt fit. I would reduce the number of bits in each register.