CPLDs

[gszakacs]

Roger,

Before you get the idea that an FPGA will solve all your problems, you should realise that the

modern FPGA families also have no internal tri-state buffers (although some older families do).

Tristates are only on the IO buffers as they are in a CPLD.  So as long as you try to generate

tristate buses, you will either need to eat up precious IO resources or rely on the tools to

properly translate the tristate bus into logic.

If you want to know how internal buses normally work in an FPGA-based CPU, you might look

at the PLB (processor local bus) from the MicroBlaze processor which is roughly based on

an IBM design.  This bus uses a distributed multiplexer that roughly mimics a tristate bus.

Instead of tristating a signal when it is not "driven" the signal is driven low.  So in effect any

bus signal not actively "driven is zero.  Then, because you can't have all of these active signals

connected together, you instead OR them together so only those who are non-zero can

affect the result.  Because OR gates are precious in a CPLD (whereas in an FPGA the

active state makes no difference because of the look-up tables), it would make sense for

the off state of the bus to be 1, and then AND the bus signals to form the "multiplexed" output.

So instead of a tristate buffer, each line goes through an OR gate (whose other input is

the "disable" signal).  Then all of the bus lines that would have connected together go

into an AND gate to form the common "bused" signal.

Regards,

Gabor

[rogerk8]

Hi Gabor!

Thank you for that fantastic solution! At first I didn't understand what you meant but after drawing the attached picture it strangely enough became quite clear to me.

The fact that the off-state of the bus is all 1's is indeed no problem, I happily understand.

I am glad that you told me about three-state buffers not beeing available for internal use because otherwise I would have put down lots of work in designing according to my recent attachment and this would not have worked as I now understand.

Now I have designed an 8X8-bit AND-gate for use in my design. I was actually sceptical if ECS could cope with such a huge symbol but it did. Now I will redesign all my modules into having separate Inputs and Outputs and include the OR-gates. The OE-signals will as usual be integrated in the new modules.

If you wonder about the strange D_REL-signal it mainly has to do with the simplicity in microgramming where you can realese the internal bus just by setting D_REL high (R/W' is almost always high). This is instead of setting R/W' low which in principle means a write but in practice not due to no CS (i.e wrong adress-area). I think I will ommit this signal in my final design. But it feels strange to set R/W' low each time you want to shuffle data internally. Can it not happen that RAM or I/O might actually be written by accident? I actually don't know. Which is why...

Take care!

Kind regards, Roger

[rogerk8]

Hi Gabor & co!

I think I am actually about to give up. The ECS drawing board is now so full that it can't even hold the whole design. There is simply not enough space ( in spite of me using the larges possible area). And I have broken down the different modules to a minimum. Disregarding the fact that all outputs (which need to go thru our "MUX") also need to be isolated from the inputs (which however can be bundled as in picture) increasig mudule pins dramatically.

Our "MUX"-solution generates the need for an enormous AND-array (and I am only designing a simple 8X16-bit CPU...). In the attached picture the AND-array is "only" 72-bits wide. But inspecting the picture you come to the conclusion that a 12X8-bit AND-array is actually needed.

This and the wiring problem makes my primitive CPU virtually impossible to realize. I somehow need to break it down to even smaller parts but I am stuck with the need for a huge AND-array because, as I recon, this can't be done locally in the different modules. And this is because each line in the internal bus needs to have all output signals available.

Finally, I also need to somehow realize the IR PROM which seems impossible using CPLD's (if I'm not prepared to use off-chip PROM or "upgrade" to a FPGA).

I was looking forward to holding the finished CPLD in my hand and proudly being able to say that "this is actually a CPU which I have designed by myself (with some well needed help from a couple of very nice american experts)".

Now I however think I should focus more on my current well needed vacation (even though this CAD is so much fun).

Have a nice sommer!

Kind regards, Roger

PS

Is there perhaps a way to bundle descrete wires into a "bus" only considering the order in which the the bus is aligned. This would simplify design enormously. I have seen such "bus-gates" while playing around with ECS. But can you define them optionally? This bit-wise wiring simply do not work anymore.

[eteam00]

Roger,

Enjoy your vacation.  Relax, and return with renewed optimism and enthusiasm.

As for your questions about the schematic capture...  sadly, I am ignorant of this tool...  and I prefer to remain ignorant of the schematic capture tool (my shrinking brain is already filled to capacity).

We'll be looking forward to hearing from you upon your return, and after you review your project with 'fresh' eyes.

Regards,

-- Bob Elkind

[rogerk8]

Hi my friends!

I am so **bleep**ing stupid I wanna cry! At first I didn't even understand that you can stack the AND-gates and therefore use them locally while merging the modules. But now I've been even more stupid. I accidently deleted all my new designs! This is after working happily for 12 hours. The only fortunate thing is that only the higher level modules got deleted. Lucky me :-). Did you know what did? I got so far as to trying to compile my ROM-less CPU. It was actually finished so far and I was very proud and happy. But I got some strange errors and noted that the new high level sub modules in the project window had question marks on them. So I doubled-clicked on them, a window popped up where I could choose (actually a NEW source but I didn't understand that just then) type of  source so I chose "schematic" and the name happened for some strange reason (I almost want to call this a bug in the ISE) to be copied and therefore the same. Clicked next and got a warning "the file already excist, do you want to replace it?". Answered stupidly yes and then the questionmark changed to a "gate". Making me very happy. Until I managed to understand that the new errors had to do with the files being totaly deleted/empty (only the names now excists).

Obviously I can't understand neither plain english nor computers. I gotta be the worst Master of Science (E.E) ever!

I really need my vacation!

Kind regards, Roger

PS

I am attaching a snap-shot I managed to get of the completed design before I destroyed it. But now that is only a picture of no real use.

[eteam00]

I really need my vacation!

After your near-miss encounter with disaster, I would recommend beer (or something a bit more potent), and then vacation.

This is after working happily for 12 hours.

Perhaps a nap, first.

Did you check in the Windows "recycle bin" for deleted files which might be recoverable?

How often do you make a duplicate copy of your design files as backup?

-- Bob Elkind

[rogerk8]

Hi Bob & co!

Vacation, what is that? :smileyhappy: Except from sleeping well into the afternoon I don't enjoy vacation much. Well, I was at an amusementpark here in Gothenburg (Liseberg) today and played some pentathlon. Shooting rubber ducks and stuff, you know. Wound up last though. But it was quite fun.

In only four hours I actually managed to manually redesign the lost files. Thanks to them being of high-level I needn't to think so much, just redraw lots of wires.

Then I finally understood that the questionmarks meant that all the sources had to be added manually to the project. Not just the highest source which I first thought would suffice. One ofter the other I manually added some 50 sources. Got it through Check Design Rules and started Assign Package Pins which actually led to me being able to assign pins!! For a while I was very happy, assigned some 130 pins (out of 144) and happily continued with the Syntesize process which listed a lot of warnings (unloaded pins) but finished ok. I also think Translate worked. But when I tried Fit I got these errors:

ERROR:Cpld:1063 - Design contains 203 macrocells, exceeds device limit 128.
ERROR:Cpld:1062 - Design contains 579 unique product terms, exceeds device limit
   384.
ERROR:Cpld:1064 - Design rules checking error. Fitting process stopped.

some mumbojumbo and finally

ERROR: Fit failed

Looks like I have run into a brick wall! But I suspected that I would run out of microcells, as you know.

Is there any other CPLD with my required capacity available? I am lazy just asking you this and I am sorry for that.

By the way, ERROR 1064 above is a later result and a standard error message or what? Because as I said, I got it through that process (Check Design Rules) the first time.

Take care!

Kind regards, Roger

PS

If you don't mind you may tell me the excact procedure for compiling and implementing a design. I am very unsure about this. I just need a basic simple procedure. What processes to run and in what order. But maybe I should read the tutorial instead? Lazy me...

Finally, it struck me that a solution might be splitting the CPU in half using two CPLD's of the chosen type.

[gszakacs]

Hi Roger,

  There are larger CoolRunner 2 CPLD's.  You can find all available parts in the Design Properties

dialog box, or you can just choose "Automatic" and let ISE select the best fit from the available

parts:



As to that last error message, ISE loves to add one error at the end, which says essentially:

ERROR:  There were errors!

So it should go away when you find a device that fits your design.  As far as splitting the

design into multiple parts, this is always an option.  However the biggest headache with

splitting the design is to deal with the partitioning.  If you can see a clear place where the

design neatly splits in two with minimal interconnect between the two halves, then you

almost always end up with a cheaper solution using two smaller parts rather than one large

one.  On the other hand, if the design does not break up so easily, then you may find that

the "smaller" parts need to be bigger than you thought just to handle the extra I/O between

the two parts.

I started designing with programmable logic when the only available parts were much

smaller than CPLD's (PAL's) and so partitioning was always a large part of the design

cycle.  Over time I came to be quite good at it, recognising for instance when it makes

sense to break up a bus into multiple parts by bit rather than by port.  Imagine taking

your CPU and implementing the LSB half in one chip and the MSB in another.  Then

there would be little or no data interconnect between the two halves - only carry chains

and control signals.  So while splitting a design in two to use smaller parts can be fun,

it can also lead to some major headaches - especially if after you build boards you

realize there is a problem that requires adding more signals between the two chips!

Have fun, and take a break, too.  Vacation is supposed to be about changing your

surroundings so you can let go of your everyday problems :-)

Regards,

Gabor

[rogerk8]

Hi Gabor & co!

I am just going to put down some thoughts here. You may of course comment if you like. In any case, I hope you will enjoy my rambling :-).

1)

Is it possible to run the CPLD on 5V? I am planning to build the test-bench with 74HC-MOS.

2)

It would actually be fun to split the CPU in half as in one Math-processor and one Mains-processor. The Math-processor will then hold the ALU, CCR and the Accumulator (AC) isolating the ALU-bus within that device. In the far future I might even add a hard-wired Multiplier as well as a Divider.

Reflection: perhaps the Accumulator should be a part of the Mains-processor though, but this increases the number of nessecary pins to use. At the same time all buses will be available at the pins which in turn makes it possible to debug the processor in a HW-fashion (which is the only type of debugging I wanna do).

The Mains-processor will then hold the Stack Pointer register (SP), the Program Counter (PC), the Adress Registers (AR) as well as the Databus circuitry (DBUS). SP will be stand-alone, PC and AR and DBUS will be integrated into one module (as it is now, called PC_DBUS).

Splitting the CPU in this fashion only makes it necessary for me to separate the AC_SP-module. This is not hard to do.

And I get more pins available which means that I can connect them to all my buses as well as the AC and even the CCR (but I think I will ommit the probing possibility of the CCR. At the same time it would be fun if the result of each full adder (FA) operation could be displayed. I will have to think about this because this would also mean some redesign).

In the Mains-processor the Instruction Register (IR) also resides (without ROM).

So the preliminary solution looks like this:

Math-processor: ALU+AC

Mains-processor: SP+PC_DBUS+IR

3)

I have been thinking about the ROM-problem. I need a 16-bit wide address-bus and a 43-bit wide data-bus. I could use 6 8-bit EPROMS (DIL for a EPROM-burner. I plan to use an ordinary 32kX8 EPROM as program memory) connecting them somewhat in paralell. Or I could use, which is smoother, 3 16-bit flash memories (which we also have at work). I would very much like my processor to be compact and over-all surface-mounted. But I am stuck with the impossibility in programming the flash. As it is done now, it is done via a HC12 processor and I was thinking of buying an adaptor, privatelly,  and solder it into one sample of this product of ours. But this is very tedious work!

Programming a FPGA-ROM seems however very simple (need only to program some 200 addresses). So maybe I could use a dedicated FPGA for the ROM-part and two CPLD's of the chosen type for the rest of my CPU. What do you think about that? I recon that the programming protocol is the same for Xilinx CPLD's as it is for Xilinx FPGA's. Meanng I could use the same programming equipment.

Finally, I couldn't find the Design Properties dialog box. I found some Project Properties though but no "Automatic" choice (I have 6.2.01i). But now this strategy of switching devices seems to be omitted so don't bother answering my rambling.

Thank you for your reply! It always makes me happy!

Kind regards, Roger

PS

Attaching my very preliminary test-bench. I will probably expand it to also display ALU-bus, internal D-bus, AC-value and CCR-value. I have been thinking of using and designing 7-segment displays instead of LED's (ordered in nibbles). But I think the coding for A-F will require quite many gates and hex-codes really are not that difficult. But this is with regards to my skills. Showing the test-bench to another won't however mean a thing and this is the boring part.

[eteam00]

First off, why are you not watching the World Cup final match?  Tied 1-1 at the beginning of 30-minute extra time!!

UPDATE:  Japan wins over USA in goal kick shootout.  Congratulations, Japan!  They came from behind twice.

Is it possible to run the CPLD on 5V?

Reworded the question:  It it possible to use 5V logic with the CPLDs?

XC9500: Yes.

XC9500XV:  No. 3.3V VCCIO.  NOT 5V tolerant.

XC9500XL:  Yes.  3.3V VCCIO, but 5V tolerant.  May need pullup Rs to 5V on outputs.

CoolRunner XPLA3: Yes.  3.3V VCCIO, but 5V tolerant.  May need pullup Rs to 5V on outputs.

I am planning to build the test-bench with 74HC-MOS.

74HCxx, 74ACxx:  Will run at 2V - 6V (compatible with all Xilinx CPLDs listed above)

74HCTxx, 74ACTxx:  4.5-5.5V only (directly compatible with XC9500 only, XPLA3 and XC9500XL parts can be made to work)

-- Bob Elkind