PAL's and GAL's

I suggest you visit

They're one of the few programmable logic vendors around who still makes GALs (aka "SPLDs," for "simple programmable logic devices"); most other vendors (Altera, Xilinx, etc.) start out with CPLDs (complex PLDs), which are just larger & fancier. All the PLD vendors have a free version of their software which will work with their smaller devices (and "smaller" is still millions of gates!)

Some of the software may still support schematic entry, but truth be told, you're largely much wasting your time using it. PLD design these days is done using hardware description languages such as Verilog and VHDL; your time is much better spent learning them. (Somewhat ironically, though, most design tools now support a graphical means of assigning schematic symbols to HDL code, and the tool they generates the code that merely connects signals between the various bits of code!)

I'd suggest you do a little Googling for "programmable logic tutorial" or similar. Get a demo board with a CPLD on it and play around; many demo boards are Joseph Zammit

Hmm... Malta, huh? OK, getting a demo board might be a little harder. I'd volunteer to send you one I had (it contained a Xilinx 9572, I believe), but unfortunately I tossed it out years ago. If you ask nicely there's a good chance someone around here will have one they're willing to part with, though.

BTW, another good newsgroup for these kinds of queries is comp.arch.fpga (which is what CPLDs turn into when they lose their AND-OR array fixation and turn into a sea of a bazillion little look-up tables).

---Joel Kolstad

What level education is it (school or university)? If the latter, I'd take the plunge and go straight for one of the free HDL development systems. Perhaps for beginners, Verilog would be easier than VHDL which is quirky to say the least. And there are loads of examples available on opencores.org. For the device, perhaps Xilinx Coolrunner, which are a bit small at the affordable level.

One disadvantage of this route is that the tools are baroque, and it seems that the developers don't talk to each other. Students could spend as much time getting the tools to behave as they do learning about the devices and logic.

If you really want the simplicity of FPGAs, something like CUPL or OPAL could be used. They used to be free, but I doubt their availability from manufactureres now. If you want to go down this route, mail me and I can send you OPALjr or one of the early Lattice schematic based ones (though licensing might be a problem for the latter). You can use GAL or PALCE devices- the fuse map is the same.

Paul Burke

You do not mention the packages, but DIP20/24 pin SPLDs are available from:

ATMEL : ATF16V8BQL, ATF22V10QCQZ, ATF750CL

Software: WinCUPL, smallish in size, compiles Boolean Equations. If you have problems programming those, the next step is PLCC44, and the ATF1502ASL are JTAG-ISP and 5V,with low cost JTAG cables available.

Lattice: GAL and ispGAL variants, tend to have high Icc at

5V variants. Their lead-free coverage is thin at the SPLD end.

Software: Part of their larger FPGA offering, so it is a large download.

Anachip PEEL series

Software : WinPLACE, smallish in size, Boolean equation entry.

Older SW : PALASM still exists in some corners of the net, but the supported devices list is now ancient.

Schematics: Not really worth it, with 8/10/32 macrocells, a text editor is probably the fastest entry - and you'll need one anyway to view the report logs.

Programming: If you can find a commercial programmer, most of those support VECTOR test of programmed PLDs.

-jg

from:

I recently dug out PALASM to modify a GAL and it still works fine with my Lattice GALs (22V10D). It will only run under real DOS though. Here it is:

--DF

CUPL is still available, for free, as Atmel WinCUPL

which also includes the command line versions.

CUPL is ideally suited to the GAL/PAL level the OP mentioned - where you code at the macrocell level.

I'd forgotten about OPALjr :)

-jg

Back in 1988/9 it was CUPL which made me write my first logic compiler (not available for windows etc.). It cost me a day to figure out why my 16V8 would not work until I discovered CUPL was not taking into account the output polarity of the feedback signals (did it right only as long as they were active high...). Fortunately, those were the days when the JTAG fusemap was listed in the datasheets so I could see what was going wrong and move forward. They may have fixed that since - I never touched it again afterwards. Perhaps still usable as a teaching tool, having access to the lower level data may be a great advantage in that respect. And well, if someone has to discover some bug yet again while learning, this will actually be advantageous, too....

Dimiter

------------------------------------------------------ Dimiter Popoff Transgalactic Instruments

------------------------------------------------------

Jim Granville wrote:

Hi

Thanks for all the information. The only interest is more academic as i want to use them for demonsration purposes since i teach a vocational engineering course i do not only need to explain the use but even to show these devices working. I cant use VHDL or Verilog because the level is pitched too high for my students.

The reason wanting schematic entry is for my students to visualize what is happening rather then the luxury of schematic entry for itself.

Joseph

I used that for years. The PA7024 was a drop-in replacment for the

22V10 work-horse, but with enough buried cells and extra routing to be a lot more flexible. On at least one occasion I was able to rescue a board where the designer had failed to tolerance the timing inside their 22V10 by dropping in a PA7024 replacement and using most of the extra cells as delay elements.

The PA7024 isn't exactly up to realising "system on a chip" applications but you can do a surprising amount of stuff with the logic it gives you.

These days, I'd look for programmalbe logic parts that support in-system programming (ISP). I really like the Coolrunner parts (originally Philips, now Xilinx) but most places where I've worked have gone for Lattice parts for their low end programmable logic.

-- Bill Sloman, Nijmegen

Most of the tools can create a series of TXT files, that show the morphing that takes place, and you can always draw covering drawings.

CUPL outputs a .DOC file, that shows the final equations, and some intermediate ones that show the pre-parser and macro expansion results.

If you use the smaller CPLDs that also use a fitter, that also creates a TXT report file, that shows how the logic finally mapped to the silicon.

As a tiny example:

~~~~~~~~~~~~~~~~ CUPL .PLD source ~~~~~~~~~~~~~~~~~~~~~~ This is the Table, or simple ROM syntax - this is a 7 segment display.

TABLE GCtr => [D4A,D4B,D4C,D4D,D4E,D4F,D4G] { Ca_ => Dri0; /* 0 */ Cb_ => Dri1; /* 1 */ Cc_ => Dri2; /* 2 */ Cd_ => Dri3; /* 3 */ Ce_ => Dri4; /* 4 */ Cf_ => Dri5; /* 5 */ Cg_ => Dri6; /* 6 */ Ch_ => Dri7; /* 7 */ }

~~~~~~~~~~~~~~~~ CUPL .DOC report ~~~~~~~~~~~~~~~~~~~~~~ D4A => !GCtr0 & GCtr1 & GCtr2 # GCtr0 & !GCtr1 & !GCtr2

D4B => GCtr0 & GCtr2

D4C => GCtr0 & GCtr1 & !GCtr2

D4D => !GCtr0 & GCtr2 # GCtr0 & !GCtr1 & !GCtr2

D4E => !GCtr0 & !GCtr1 & GCtr2 # GCtr0 & !GCtr1 & !GCtr2 # !GCtr0 & GCtr1 # GCtr0 & GCtr1 & GCtr2

D4F => !GCtr0 & !GCtr1 & GCtr2 # GCtr0 & !GCtr2 # !GCtr0 & GCtr1 & !GCtr2

D4G => !GCtr1

~~~~~~~~~~~~~~~~ Atmel Fitter .FIT report ~~~~~~~~~~~~~~~~~~~~~~ Same as above, but note the D4E has optimized by flipping the logic.

D4A = ((!GCtr0.Q & GCtr1.Q & GCtr2.Q) # (GCtr0.Q & !GCtr1.Q & !GCtr2.Q));

D4B = (GCtr0.Q & GCtr2.Q);

D4C = (GCtr0.Q & GCtr1.Q & !GCtr2.Q);

D4D = ((GCtr0.Q & !GCtr2.Q & !GCtr1.Q) # (!GCtr0.Q & GCtr2.Q));

!D4E = ((GCtr0.Q & GCtr1.Q & !GCtr2.Q) # (!GCtr0.Q & !GCtr1.Q & !GCtr2.Q) # (GCtr0.Q & !GCtr1.Q & GCtr2.Q));

D4F = ((!GCtr2.Q & GCtr1.Q) # (!GCtr0.Q & GCtr2.Q & !GCtr1.Q) # (GCtr0.Q & !GCtr2.Q));

D4G = !GCtr1.Q;

Well done for introducing your students to this. Far better than the sterile "implement the following requirements using 2 input NAND gates" that is still all too common.

How about using one of the equation input packages, but giving the students the task of producing the equations from the schematic?

Paul Burke

The ICT Place software is (I think) free

but you will need a programmer of some sort.

I'm currently doing a PEEL 22CV10 design (blast from the past! There's nothing like having 10 macrocells to make you really reduce a design) and I'm using the older Dos-based APEEL software ("if you have a system with two floppy disks...") which is just simple PALASYM/ABEL syntax text entry of logic equations.

There's probably some copies of PALASYM floating around (I must have one somewhere in the archives, I guess) for programming the genuine oldies, the PAL16L8's and such.

John

I have a hard time believing that your students can be smart enough to correctly implement designs using schematic capture but not using Verilog or VHDL. Not to mention what's already been said about industry using HDLs, so there's questionable benefit to spending time teaching people obsolete technology.

Unless you restrict your students to only using AND gates & OR gates, flip-flops and perhaps an inverter on the input & output, this isn't going to happen. All the old schematic packages already had most sophisticated functions such as counters, shift registers, etc. built up for you to use (in fact, some tools had complete libraries of almost all the 74xx logic ICs!). Some tools would let you "drill down" and see the "primitive" logic elements used to implement the functions, though.

---Joel

I've looked over the responses and do not yet see a direct answer to the question of allowing a schematic entry of logic leading to a fuse map output, with a free tool.

I would guess that if you could find a package that supports schematic entry (such as perhaps Altium Designer) and also supports GALs and PALs (don't know about Altium on this score), that you'd get there. But that's _very_ expensive to consider. What else might there be? Seems simple enough to do after the schematic entry graphical part of it is done -- and that itself can be kept relatively simple.

An idea -- not sure if it would help. But it would be possible to use Linear Tech's LTSpice (SWCADIII) to do the schematic entry part of the job. It's free to anyone. It isn't difficult to create the symbols that would be used for teaching and the schematic is saved in ASCII form. I've already written the software to parse that ASCII source into an internal form that may be usable for generating the logic equations which could then be input to CUPL, I suppose. Would this fit the need?

Jon

I have got a copy of CUPL (4.x? I think) I can send you if you are writing logic equations for 16x8 and 22v10 and such

Another alternative is to use this :

That's a very nice piece of SW, by Andreas Weber, that allows ASCII type schematics to paste into any source file.

So if we have a block that benefits from a drawing, we use this, and paste it into the source.

Sure, it is not SCH -> 'PLD opcodes', but it is SCH augmenting PLD source.

Altium have CUPL as one of their flows.

ISTR cupl had a package called Liaison (?), and it did this SCH-EQN step [ mostly..:) ] - you need a special library suite, so the symbols can map onto PLD structures.

We tried this, years ago now, and yes, it can be made to work.

The problems we found are, the features you loose in a SCH flow.

** There are no conditional defines in a SCH package ** Adding notes on "this workes better than that", is cumbersome ** Paste of SIM and FIT output into the source, is also cumbersome ** CUPL has multiple flows, this only works on BOOLEAN EQN Entry ** TABLE form of code is not accessible ** SEQUENCE {} State engine code is also not accessible ** Creating of simulation files is not supported. ** Waveform style comments ? ** Editing is quite slow ** CUPL allows control of what collapses, and what does not. ** CUPL can export Fitter control, via PROPERTY statements. Not sure how a SCH flow would manage those - attributes (more work) ?

Whilst with a good programmer's text editor ( we avoid CUPLs default 'vanilla' editor ), all of the above is very simple.

-jg

Look for Palasm.

Its good to use both schematics and VHDL in an FPGA design. Schematics show how the design structured and you can include small timing diagrams. In VHDL/Verilog code it is easier to describe complex logic functions (like a state machine) which are total spaghetti in a schematic.

If you write everyting in VHDL/Verilog you'll need to make a separate picture which shows how everything is connected if you want someone to be able to alter your design.

--
Reply to nico@nctdevpuntnl (punt=.)
Bedrijven en winkels vindt U op www.adresboekje.nl

Hi Nico,

Yes, I agree with you. The point I was trying to make -- pretty poorly given how I worded it -- was that these days a schematic symbol such as an AND gate gets mapped to some VHDL or Verilog code, which then gets synthesized down to primitives & placed/routed. Whereas historically the AND gate was, itself, a primitive.

Actually, I think you missed understanding me. Maybe not, but the above looks to me like that. Probably my fault.

The only reason I mentioned "ASCII" was technical, not visual. I am thinking about the possibility of using LTSpice as a free and graphical and supported schematic capture tool. No ASCII here. I mean, an easy to use tool for laying out the logic and editing it. The ASCII part is about the save files -- which aren't supposed to be read by humans even though they are ASCII. I was proposing the idea of reading those save files and automatically generating the input source to CUPL from that.

None of this has anything at all to do with Weber's tool (or my tool which supplements his by using LTSpice for a similar purpose.)

The point is that they aren't free... or cheap.

Which is what I'm imagining LTSpice for, if I gather you correctly.

Now to the interesting part.

Okay, this *could* be handled with specially annotated TEXT in LTSpice, I suppose. I'm no expert on this application space, so I'm ignorant about how this might work well in a schematic capture situation and I'm also ignorant about the teaching situation which may or may not need this feature. But I don't imagine it poses a serious problem, from my vague understanding of you.

What do you mean by the above? I just don't follow, at all.

I'm ignorant of this. Can you help me or point me somewhere? (I suppose I can search -- and will -- but I wouldn't object to a pointer or comment from you about it.)

I was mentioning CUPL only because I saw references. Could be PALASM or other tool input source, as well, I imagine. Whatever is needed by the teacher is all I'm thinking of.

Might be okay for teaching. We aren't talking about a complete tool here, though I wouldn't be averse to suggestions about how schematic capture could be made to work smoothly with a variety of such compiler input source formats and features.

Same comment.

Did the teacher mention that?

And why not point out which free tools might achieve that, too? If any. No reason why those input file formats couldn't be supported -- or is there?

Got me.

In LTSpice? I'm fine with it.

Again, I suppose I need to be smarter about CUPL. I'm not, right now. So my ignorance allows me to see this as "no problem, yet." The question is, can a schematic capture program like LTSpice, tethered together with a command line tool that knows how to read the save files and parse them correctly, be used in conjunction with other standard tools to make a completed and useful package for teaching? I'm still thinking so. But I'm ignorant. So I'll read with attention.

I get you. So you are arguing hard against the use of any graphical schematic entry method for the students. But the instructor has already said this is desirable for his use. I'm willing to go with that assurance.

Jon

I'm willing to go with