PAL's and GAL's

Hmm?

Jon

Reply to
Jonathan Kirwan
Loading thread data ...

Sorry, accidentally hit the wrong button. :-)

Reply to
Joel Kolstad

I think I understood, I merely menioned this as another alternative.

What the OP was after was

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

ie to me that is more a concept/visualize request, than a full tool flow.

It's his call, as to how to get that visual assist to his students.

Very True - I was just clarifying your (question) about Altium and PALs

Here is a CUPL conditional define :

$IFDEF TermC_Zero CountEN = !(DivFD : 'd'000); /* terminal Count, loads when hits 0, so Divides by NUM+1, not NUM */ $ELSE CountEN = !(DivFD : 'd'001); /* terminal Count, loads when hits 1, so Divides by NUM, not NUM+1 */ $ENDIF

Just ones normal source code comment, in any deisgn language.

Here is a real example, of a result comment, from a CUPL design /* Fitter v1897 => 440.5Hz with 001 TC, and 76 PT, Fitter v1897 => 440.1Hz with 000 TC, and 85 PT, -- hmmmm...

*/

another example, here are SIM and FIT outputs :

This from a CUPL .SO file ( sim Output ) - can be pasted into source, /* inside comments */

================================== K O O Ne O s s ID ey s c c ID ne wS c F F ne cc Kt I B B cc DD ea N T N ButQ DD QQ yb GCtr ================================== Revised for Version 1.0 POWER ON, Osc Check

0001: 0 L X 1111 LL LL LL LLL 0002: 1 H X 1111 LL LL LL LLL 0003: 0 L X 1111 LL LL LL LLL State track, one click, Ba_ to Bb_ 0004: C L X 1110 LL LL HL LLL 0005: C L X 1110 LL LL LH LLL 0006: C L X 1100 HL HL LH LLL 0007: C L X 1100 LL LL LH LLH 0008: C L X 1100 LL LL LH LLH 0009: C L X 1100 LL LL LH LLH 0010: C L X 1100 LL LL LH LLH 0011: C L X 1100 LL LL LH LLH

and this from a FIT file (Squashed to hopefully avoid wrap ) Device here is an ATF1502BE

MCell Pin# PinDrive DCERP FBDrive DCERP CascadeOut TotP MC4 1 TDI INPUT -- -> IncD 5 MC5 2 -- IncD C---- -- 3 MC7 5 -- IncDQ Dg--- -- 1 MC9 7 TMS INPUT -- -> DecD 5 MC10 8 -- DecD C---- -- 3 MC13 12 But0 INPUT KeyEdgeA Dg--- -- 1 MC15 14 But1 INPUT DecDQ Dg--- -- 1 MC27 23 -- -- -> GCtr0 5 MC28 22 -- GCtr0 Dg--- -- 2 MC29 21 -- -- -> GCtr1 5 MC30 20 But3 INPUT GCtr1 Dg--- -- 2 MC31 19 -- -- -> GCtr2 5 MC32 18 But2 INPUT GCtr2 Dg--- -- 3 MC0 37 OscIN INPUT -- -- 0

Total Pts 60

There are tools out there for Graphical State diagram entry, so I suppose an ideal Schematic front end would include/emulate one of those ?

No, but he did mention programming real devices, and if I was teaching this, I'd certainly try and match theory with practise.

If he wants to set simple class tests, simulation is a great way to mark them.

It also outputs TestVectors on the JED files, but in this case, the OP's budget might not run to a Vector-Programmer.

CUPL is free

No reason why those input file formats couldn't be supported --

How does that handle BUS connections, and node names ?

The Spice I have has no BUS support (why should it?), and it uses the spice std of node numbers.

Yes, it can certainly be made to 'work' - I was just pointing out what one stand's to loose, in functionality, for the cost of another layer of complexity.

Not really - I offered above an alternative method of involving circuit drawings - which we use here quite productively. No extra SW needed.

I also have some Spice examples here, and am working with a Spice supplier, to encourage them to import PLD eqn infos, so they can do mixed Analog/PLD simulations.

To clarify, with some of the design constructs we use, I have no idea how one would draw them with any clarity in a schematic, so to me that will always be a subset-flow.

Where I can see a strong case, is for using Spice/Schematics in the simulation side of the design flow. - ie use your tools to their strengths.

-jg

Reply to
Jim Granville

In article , wrote: [....]

Unfortunately they never made a CMOS version of the PA7024s. They are quite power hungry. This is the only real down side to the part. I really liked the ability to use the flip-flop on the input, it let you get a lot done in a small package.

--
--
kensmith@rahul.net   forging knowledge
Reply to
Ken Smith

They are beautiful devices, worlds better than GALs. A rich choice of feedback (you can configure an embedded flipflop, and use the associated pin as an input) and the clock is fed into the product matrix. Sad that they never really caught on, and I'm not sure that anyone else ever made them. Though ICT did irritate me badly by changing the programming algorithm just after the manufacturer of my programmer stopped supporting that model.

Paul Burke

Reply to
Paul Burke

Another PEEL lover. I thought I was alone in the world. Very nice devices and never had a lick of trouble with them.

Reply to
Jim Stewart

They're handy. Nice 5-volt logic blocks. Production can program and label a tube of them at the programming station, and later plug them into sockets on boards without all that JTAG nonsense.

John

Reply to
John Larkin

Elsewhere on sci.electronics.design:

The latter, logisim, allows a bus. It's also at SourceForge, so modifications to it to support what's needed not only for simulation of the logic but also then creating a fuse map are possible, I'd suppose.

I have used VHDL and Verilog with some CPLD and FPGA parts and have enjoyed that. But I haven't had to do PAL and GAL programming with PALASM or CUPL. So my ignorance allows me to imagine that a good, free graphical tool could be applied to good purpose in teaching.

In any case, there hasn't been enough of a response from the OP. So I should bite my tongue, I suppose.

Jon

Reply to
Jonathan Kirwan

Interesting, I've book marked that. The OP could use this to get the ideas across, then code in CUPL. Seems logism is purely digital, so misses my target of mixed-simulation, but I can see it could expand in that domain by :

a) Adding EQN output ( also needs library work ) ? These libraries then tend to restrict the flow to specific back ends.

b) Adding table SIM output, in JED.Vector syntax, which would append to the JED file created by the other flow

Doing the latter would give some interesting parallel paths.

c) Add an ASCII export, so you can paste into TEXT based source ?

The above logisim looks useful for that.

Well, he now has many suggestions to follow up on. :)

My present area is pushing PLDs into mixed-signal space, and this will be using a good graphical tool for the teaching (Spice).

I will not be (initially) pushing for this as a whole flow, for the reasons previously mentioned, but will focus on the areas where there are presently no tools at all.

Another drawback of Schematic Entry, is you tend to get binary format source files, that can have lifetime dead-ends. See some of the threads in Comp.arch.fpga on this issue....

-jg

Reply to
Jim Granville

Me, too. I've only played around with it for a moment or two, but it's reasonably easy to use. Actually, looking at both it and the Digital Works mentioned earlier, logisim looks a lot like it was developed afterwards to expand on the ideas of the other. Too similar in their handling of manual input sources and led outputs.

What I liked about logisim is that there is no installation at all. It's just an exe and it works right away. Couldn't be easier unless it was grafted into the BIOS. ;)

Which isn't my focus (I mean, mixed signal isn't), though I'm attracted to it. It's just that I haven't found convenience (I'm a hobbyist) and quality in the same package -- the Cypress PSoC mixed-signal thing didn't impress me much on the analog side so I've just stayed traditional, with separate substrates for digital and analog -- I think it is just still too hard for FABs to try and do it well, monolithically.

Good. I thought so from my limited perspective. Maybe this tool would be a launching point for something, then...

He does!

Understood. I can see better now why you were chipping in -- because this is something close by to what you've been considering.

Fix the holes, first. Then worry about an easy flow.

LTSpice puts out ASCII. It's not exactly human-readable, but it transports easily through just about any software layer on the net and can survive various translations of end-of-line and end-of-file file system variations. I wrote a lexer/parser by hand for it in about two days, without any documentation from Linear and just creating lots of files for examination. So far, it's been holding up okay.

I haven't checked on the output of logisim or digital works, so I can't speak to them.

One nice thing about this being SourceForge'd, assuming all the source and development tools are in the open there, is that it can be kept alive nearly forever if it continues to have some interested folks needing it. It's not going to die just because some company decides it's past its profitable maturity cycle.

Jon

Reply to
Jonathan Kirwan

I should clarify my mixed-simulation a little. I'm with you on the "Full analog with Digital" issues, but where I am pushing the CPLDs is more into Oscillators (RC, one, two , three terminal), LC, and Crystal, Digital DACs, and Oscillator Trim schemes, and also PLLs ( a la 4046 ) (etc). So this is more Quasi-Analog : Nice to know what values R & C to choose, and a 'picture is worth 1000 words' education stuff.

I do have a nice design for a Function generator, using a CPLD and a Quad Opamp.

-jg

Reply to
Jim Granville

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.