PAL's and GAL's
in [Design]
|
Prev: LEAD ACID BATTERY
Next: Running Palasm on WinXP
From: Jonathan Kirwan on 1 Apr 2006 17:36 On Sun, 02 Apr 2006 10:04:57 +1200, Jim Granville <no.spam(a)designtools.co.nz> wrote: >Jonathan Kirwan wrote: >> On Fri, 31 Mar 2006 10:18:22 +1200, Jim Granville >> <no.spam(a)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(a)yahoo.com" <slebetman(a)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. 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. ;) >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, 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. >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. Good. I thought so from my limited perspective. Maybe this tool would be a launching point for something, then... >> 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. :) He does! >My present area is pushing PLDs into mixed-signal space, and >this will be using a good graphical tool for the teaching (Spice). Understood. I can see better now why you were chipping in -- because this is something close by to what you've been considering. >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. Fix the holes, first. Then worry about an easy flow. >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.... 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
From: Jim Granville on 1 Apr 2006 19:32
Jonathan Kirwan wrote: <snip> >>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, > > > 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. 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 |