I can't promise anything, but I will check my supplies. I know I have the 84-pin socket adapters. Will check for the 84-pin xc95108 tonight. I don't foresee using one anytime soon.

EDIT: Check these people: www.avnetexpress.avnet.com .They have stock in europe. In the US, you have to buy a minimum of 4. This may be different from where you are.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I checked. Unfortunately, what I have is a XC9572-10PC84. Probably not enough macrocells for your app. However, if it suits your needs let me know. The 2 I have are still in original antistatic bags from Digikey I ordered from Feb2010...

If you need 5V I/O compatibility, Xilinx has the XPLA3 series in 100-pin QFP. These 100-pin QFP packages are the typical industry standard "square" packages, and you may find a cheap adapter socket for them. I started looking into these back when I needed 5V I/O compatibility programmable logic. I must confess though, I've never used them, as I drifted into Spartan 2 FPGA at this point. Now maybe you see, if one is going to spend so much on an adapter socket, one will want to maximize the IC fitting inside that socket...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

How much macrocells can i actually save with an external alu?
If i could shrink it using the 72' and the external alu that would be great.

Dajgoro:

I am still working on a Minimal CPU concept to be implemented in a CPLD.

The ALU I starting working to implement as part of the Minimal CPU is a 6-bit ALU. When I fitted my design to a XC9572 CPLD, it resulted in using 27 macrocells, and I thought to myself "woohoo". The number of macrocells was 8 more than I estimated (19), but that could be accounted for by the estimates provided in that Xilinx appnote I pointed you to earlier regarding the "TTL Burn Rate" of Xilinx CPLDs.

Unfortunately, the XC95xxx CPLD family has only 5 p-terms in each macrocell. Sharing logic in each macrocell allows p-terms to be completely or partially shared between adjacent macrocells. When sharing p-terms from macrocells not adjacent to the macrocell in need of additional p-terms (the CPLD's wide AND gate), these p-terms are chained together through multiple p-term sharing levels . The chaining of p-terms through multiple p-term sharing blocks increases the signal path delays, lowers overall performance, but allows the fitting of logic equations with a large number of p-terms feeding a summing gate (CPLD OR gate).

I think that I made note of this issue in an eralier reply. However, I did not pick up on the effect of this architectural feature with respect to the XC95xx CPLDs while I was celebrating the fitting of the ALU into a CPLD. The real issue is not the number of macrocells, but the number of p-terms used. An XC9572 has 72 macrocells, each having 5 shareable p-terms for a total of 360 p-terms. When I finally realized what that number meant, I found that the ALU implementation that I had fitted to the CPLD was actually using 306/360 p-terms, or 84% of all of the programmable logic resources.

A four bit ALU as you planned to use is likely to use about the same as used in my ALU. The ALU architecture you posted earlier has four 4-bit registers and 4-bit ALU. The registers in your ALU alone represent about the same number of macrocells as my ALU with its three 6-bit registers. Your more general purpose, two operand architecture will require at least the same amount of multiplexers as my 3 register ALU.

I think the answer to your question is that a 4-bit '181 ALU can be estimated to represent about 150 p-terms, or about 50% of the logic of an XC9572 CPLD.

As a quick reaction to that depressing result, last night I converted my parallel ALU to operate as a serial ALU. A serial implementation, with the word size increased from 6 bits to 8 bits, requires 25 macrocells (3 8-bit registers, plus a Carry register) and 201/306 p-terms. In the case of one particular signal, the number of p-terms required is so high (22) that 3 adjacent macrocells share all 5 of their p-terms. This means that those macrocells are effectively completely used as well. (I will have to look deeper into why that signal requires such a high number of p-terms.)

I have always wanted to implement a serial CPU using a SEEPROM and a serial FRAM, so I am going to continue down this path for the time being. From these results, without further refinements and optimizations, I predict that a Minimal CPU with a serial internal architecture can be constructed to fit into an XC95108 CPLD. (Performance estimate for the serial ALU is ~72 MHz, and for the parallel ALU is ~37 MHz. With an 8-bit word length, the serial ALU will require at least 8 cycles to complete an operation. This provides an effective computational rate of ~9 MHz, which is not too bad. However, the SPI interface will only allow operation at a maximum of 40 MHz. Thus, the estimated performance decreases to 5 MHz, which is still pretty respectable for an 8-bit microprocessor.)

_________________
Michael A.

So i can save half of the 72' by using the 181 alu?
In that case i should use it, and save some space for other stuff.
I sent an email to Unicorelectornics, lets hope they can came up with some plcc 108', because i don't like ordering from that huge sites, because they tend to have crazy shipping prices.

If not ill be forced to use the 72'. I was thinking of putting 2 plcc sockets and 2 181' so i can later connect them into full 8 bit cpu, or try to build a contraption that was supposed to use toes 181' in the first place.

And if somebody could comment the MC6875 as a clock generator ic.

An update on the Serial ALU for a Minimal CPU.

I examined the equations in the output report. I was curious as to why the MSB of the first ALU register required 22 p-terms to implement. I verified that the equations matched my HDL model, and then I noticed that default case I had defiend held the registers when instructions did not directly affect them. Since ALU operations are separately enabled, I decided that while the ALU CE is asserted all the ALU registers can be circularly shifted.

This change reduced the number of p-terms required from 201/360 to 125/360. I will look for other optimizations like this one that can save additional p-terms.

PS: fitted into a XC9536-5PC44, the speed estimate for the ALU increases from ~70 MHz to ~86 MHz.

_________________
Michael A.

Nice! Not a lesson you need, but a good lesson in inspecting the implementation as much as you can, when it's time to optimise. Synthesis is good as a black box process, but the information is there to see what's happening.
Cheers
Ed

ElEctric_EyE agreed to send me toes two 72' so i am thinking about making a board with two of them and with two 181' connected to them, and some ram/rom so i can plug it all in my 6502 sbc expansion backboard and use the existing hardware that I've built for my 6502 sbc.
Any suggestions about using the MC6875 as a clock generator or something else?

You are using a Rockwell65C02 which I'm not familiar with... With WDC65C02, only Phase2in is needed and it provides O1 out I believe. The MC6875 provides both phase 1 and phase 2 clocks for an old school NMOS 6502, with the provision for DMA by taking advantage of phase 1. I am not actually fully qualified to comment on this matter, as I have always provided a single phase 2 clock on my 6502 projects...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

The NMOS 6502 that i have and use on my sbc has clock in and phi1 and 2 out, i feed the clock from a 4040 divider to the clock in, and i get phi1 and 2 out. If i remember correctly the 6800 had no clock generator in the cpu, so it must use the MC6875. I checked the Intel family too, and Intel also has a similar chip, but it is kinda weird(like the entire Intel family). The MC6875 takes in 4 or 8 MHz and outputs 1 or 2 MHz, where the NMOS 6502 integrated clock generator outputs the same frequency as the input. I am able to run my sbc @4MHz(I guess due to the 33ns ram), so i would like to clock the MC6875 to 16MHz so i get 4 but who knows how would it perform...

I'm sorry I can't send you the IC's. Croatia beat US in water polo olympics.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

I don't follow sport events, so i am on neutral ground on that matter.

I purchased the MC6875, so ill see how it performs.

Sorry, that was really a 'joke'. I've been accused in the past of having a bad sense of humor. I apologize. Should be able to send you those IC's by the Aug 14th or 15th as promised!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

No problem, i assume it will take more time for that Motorola ic to arrive, and i still didn't finish the vhdl...

Dajgoro:

I have completed the development and testing of a serial ALU for a Minimal CPU targeting CPLDs. I have posted MiniCPU_SerALU on GitHub. Now that the serial ALU is complete and fits, albeit at 100% macrocell utilization, in an XC9572-7PC44 CPLD, I will be moving onto the MiniCPU's Program Control Unit (PCU). I have a plan for that component, although given my current workload and the fact that college football is about to start here in the US, I can't say how long it will take to complete and test.

Regardless, following your lead, the plan is to fit the PCU into a second XC9572. If you examine the referenced source files on GitHub, you will see that the ALU registers are implemented as buried nodes, and that only a limited interface consisting of just 14 signals is required to exchange data between the serial ALU and the serial PCU (when complete). The default configuration of the MiniCPU-Serial (MiniCPU-S) CPU will be as a 16-bit microcomputer.

If you decide to download and simulate the source in ISim, you will need to uncomment the `define DEBUG line immediately after the file header. This will enable the test port of the module, and allow the self-checking testbench to examine the contents of the buried registers in the serial ALU.

_________________
Michael A.