PAL's and GAL's
in [Design]
|
Prev: LEAD ACID BATTERY
Next: Running Palasm on WinXP
From: Jonathan Kirwan on 30 Mar 2006 15:41 On Thu, 30 Mar 2006 12:25:38 -0800, "Joel Kolstad" <JKolstad71HatesSpam(a)yahoo.com> wrote: >"Jonathan Kirwan" <jkirwan(a)easystreet.com> wrote in message >news:nceo229m3lj0qi99l96ahr52jj0oduh0a6(a)4ax.com... >> So [someone else is] 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. Hmm? Jon
From: Joel Kolstad on 30 Mar 2006 17:07 "Jonathan Kirwan" <jkirwan(a)easystreet.com> wrote in message news:3jgo22pjbht33oe73pqmqoeev42gstkio2(a)4ax.com... > Hmm? Sorry, accidentally hit the wrong button. :-)
From: Jim Granville on 30 Mar 2006 17:18 Jonathan Kirwan wrote: > On Fri, 31 Mar 2006 08:02:00 +1200, Jim Granville >>Another alternative is to use this : >>http://www.tech-chat.de/download.html >> >>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. > > > 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.) I think I understood, I merely menioned this as another alternative. What the OP was after was <paste> "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. > > >>>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. >> >>Altium have CUPL as one of their flows. > > > The point is that they aren't free... or cheap. Very True - I was just clarifying your (question) about Altium and PALs > >>>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? >> >> 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. > > > Which is what I'm imagining LTSpice for, if I gather you correctly. > > >> 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. > > > Now to the interesting part. > > >>** There are no conditional defines in a SCH package > > > 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. 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 > > >>** Adding notes on "this workes better than that", is cumbersome > > What do you mean by the above? I just don't follow, at all. 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... */ > > >>** Paste of SIM and FIT output into the source, is also cumbersome > > > 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.) 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 > >>** CUPL has multiple flows, this only works on BOOLEAN EQN Entry > > > 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. > > >>** TABLE form of code is not accessible > > > 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. > > >>** SEQUENCE {} State engine code is also not accessible > > > Same comment. There are tools out there for Graphical State diagram entry, so I suppose an ideal Schematic front end would include/emulate one of those ? > > >>** Creating of simulation files is not supported. > > > Did the teacher mention that? 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. > > And why not point out which free tools might achieve that, too? If > any. CUPL is free No reason why those input file formats couldn't be supported -- > or is there? > > >>** Waveform style comments ? > > > Got me. > > >>** Editing is quite slow > > > In LTSpice? I'm fine with it. 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. > >>** CUPL allows control of what collapses, and what does not. > > > 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. 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. > >>** 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. > > > 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. 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
From: Ken Smith on 30 Mar 2006 20:08 In article <1143716945.290290.275130(a)j33g2000cwa.googlegroups.com>, <bill.sloman(a)ieee.org> wrote: [....] >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. 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(a)rahul.net forging knowledge
From: Paul Burke on 31 Mar 2006 02:08
John Larkin wrote: > > I'm currently doing a PEEL 22CV10 design 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 |