On Thu, 30 Mar 2006 12:25:38 -0800, "Joel Kolstad" <JKolstad71HatesSpam@yahoo.com> wrote:>"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message >news:nceo229m3lj0qi99l96ahr52jj0oduh0a6@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
PAL's and GAL's
Started by ●March 30, 2006
Reply by ●March 30, 20062006-03-30
Reply by ●March 30, 20062006-03-30
"Jonathan Kirwan" <jkirwan@easystreet.com> wrote in message news:3jgo22pjbht33oe73pqmqoeev42gstkio2@4ax.com...> Hmm?Sorry, accidentally hit the wrong button. :-)
Reply by ●March 30, 20062006-03-30
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
Reply by ●March 30, 20062006-03-30
In article <1143716945.290290.275130@j33g2000cwa.googlegroups.com>, <bill.sloman@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@rahul.net forging knowledge
Reply by ●March 31, 20062006-03-31
John Larkin wrote:> > I'm currently doing a PEEL 22CV10 designThey 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 by ●March 31, 20062006-03-31
Joel Kolstad wrote:> "Nico Coesel" <nico@puntnl.niks> wrote in message > >> Its good to use both schematics and VHDL in an FPGA design. > > 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.Only to those who didn't minimize logic in the first place. The old fashioned way was to generate minimized logic equations from Karnaugh maps, and then implement that with gates. -- "If you want to post a followup via groups.google.com, don't use the broken "Reply" link at the bottom of the article. Click on "show options" at the top of the article, then click on the "Reply" at the bottom of the article headers." - Keith Thompson More details at: <http://cfaj.freeshell.org/google/> Also see <http://www.safalra.com/special/googlegroupsreply/>
Reply by ●March 31, 20062006-03-31
Paul Burke wrote:> 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.Another PEEL lover. I thought I was alone in the world. Very nice devices and never had a lick of trouble with them.
Reply by ●March 31, 20062006-03-31
On Fri, 31 Mar 2006 09:37:07 -0800, Jim Stewart <jstewart@jkmicro.com> wrote:>Paul Burke wrote: >> 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. > >Another PEEL lover. I thought I was alone >in the world. Very nice devices and never >had a lick of trouble with them. >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 by ●April 1, 20062006-04-01
On Fri, 31 Mar 2006 10:18:22 +1200, Jim Granville <no.spam@designtools.co.nz> wrote:> 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.Elsewhere on sci.electronics.design:> On 31 Mar 2006 23:16:59 -0800, "slebetman@yahoo.com" <slebetman@gmail.com> wrote: > > >I use Digital Works to test my CPU designs. It used to be sold by > >mecanique (www.mecanique.co.uk) but they no longer sell it nor make it > >available for download. There is still a copy of version 3.04 at: > > > > http://www.electronics-lab.com/downloads/schematic/002/index.html > > > >But I don't use this version. Instead I use the freeware version (2.0) > >available at: > > > > http://www.spsu.edu/cs/faculty/bbrown/circuits/howto.html > > > >As far as I can tell the only real difference between version 2.0 and > >version 3.0 is that version 3.0 is no longer freeware. Also, files > >created in version 3.0 are not compatible with version 2.0. > > > >What I like about Digital Works is that the RAM/ROM object has a built > >in, easy to use hex editor. Otherwise, if I don't need to use RAM or > >ROM I prefer Logisim: > > > > http://ozark.hendrix.edu/~burch/logisim/ > > > >which is even nicer for complex designs because it supports busses. But > >its RAM/ROM interface sucks.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 by ●April 1, 20062006-04-01
Jonathan Kirwan wrote:> On Fri, 31 Mar 2006 10:18:22 +1200, Jim Granville > <no.spam@designtools.co.nz> wrote: > > >> 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. > > > Elsewhere on sci.electronics.design: > > >> On 31 Mar 2006 23:16:59 -0800, "slebetman@yahoo.com" <slebetman@gmail.com> wrote: >> >> >I use Digital Works to test my CPU designs. It used to be sold by >> >mecanique (www.mecanique.co.uk) but they no longer sell it nor make it >> >available for download. There is still a copy of version 3.04 at: >> > >> > http://www.electronics-lab.com/downloads/schematic/002/index.html >> > >> >But I don't use this version. Instead I use the freeware version (2.0) >> >available at: >> > >> > http://www.spsu.edu/cs/faculty/bbrown/circuits/howto.html >> > >> >As far as I can tell the only real difference between version 2.0 and >> >version 3.0 is that version 3.0 is no longer freeware. Also, files >> >created in version 3.0 are not compatible with version 2.0. >> > >> >What I like about Digital Works is that the RAM/ROM object has a built >> >in, easy to use hex editor. Otherwise, if I don't need to use RAM or >> >ROM I prefer Logisim: >> > >> > http://ozark.hendrix.edu/~burch/logisim/ >> > >> >which is even nicer for complex designs because it supports busses. But >> >its RAM/ROM interface sucks. > > > 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.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 ?> 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.The above logisim looks useful for that.> In any case, there hasn't been enough of a response from the OP. So I > should bite my tongue, I suppose.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
