I need to program sevetal PAL's and GAL's in an educational enviroment.
I will be using a hobbyist programmer to do the programming as i do not
need any large volumes.
What software is available to enter the logic equations and compile to
the fuse file? Does any schematic entry software exist which one can
enter the schemtic and compule to the fuse map?
Any sort of help on PAL's and GAL's would be greatly appeciated.
Joseph Zammit
Malta
I suggest you visit www.latticesemi.com. 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!)
> Any sort of help on PAL's and GAL's would be greatly appeciated.
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 <$50 and you can re-program the CPLD to your heart's content using, e.g.,
a PC's parallel port connection.
> Joseph Zammit
> Malta
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 software is available to enter the logic equations and compile to
> the fuse file? Does any schematic entry software exist which one can
> enter the schemtic and compule to the fuse map?
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
http://www.atmel.com/dyn/products/param_table.asp?family_id=653&OrderBy=part_no&Direction=ASC
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
http://www.anachip.com/eng/product/pld.php
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
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:
http://www.engr.uky.edu/~melham01/ee481/software.htm
--DF
> joz...@gmail.com wrote:
>
>> What software is available to enter the logic equations and compile to
>> the fuse file? Does any schematic entry software exist which one can
>> enter the schemtic and compule to the fuse map?
>
>
> 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.
CUPL is still available, for free, as
Atmel WinCUPL
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=2759
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.
> 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.
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
http://www.tgi-sci.com
------------------------------------------------------
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
<snip>
> Anachip PEEL series
> http://www.anachip.com/eng/product/pld.php
> Software : WinPLACE, smallish in size, Boolean equation entry.
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
http://www.ictpld.com/ftp/an7.pdf
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.
> The reason wanting schematic entry is for my students to visualize what
> is happening rather then the luxury of schematic entry for itself.
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
><snip>
>What software is available to enter the logic equations and compile to
>the fuse file? Does any schematic entry software exist which one can
>enter the schemtic and compule to the fuse map?
><snip>
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
> On 29 Mar 2006 22:02:06 -0800, "joz...@gmail.com" <joz...@gmail.com>
> wrote:
>
>
>><snip>
>>What software is available to enter the logic equations and compile to
>>the fuse file? Does any schematic entry software exist which one can
>>enter the schemtic and compule to the fuse map?
>><snip>
>
>
> 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.
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.
>
> 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.
> 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.
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
><joz...@gmail.com> wrote in message
>news:1143698526....@i40g2000cwc.googlegroups.com...
>> What software is available to enter the logic equations and compile to
>> the fuse file? Does any schematic entry software exist which one can
>> enter the schemtic and compule to the fuse map?
>
>I suggest you visit www.latticesemi.com. 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!)
Look for Palasm.
>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!)
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
"Nico Coesel" <ni...@puntnl.niks> wrote in message
news:442c3708....@news.kpnplanet.nl...
> 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.
>Jonathan Kirwan wrote:
>
>> On 29 Mar 2006 22:02:06 -0800, "joz...@gmail.com" <joz...@gmail.com>
>> wrote:
>>
>>
>>><snip>
>>>What software is available to enter the logic equations and compile to
>>>the fuse file? Does any schematic entry software exist which one can
>>>enter the schemtic and compule to the fuse map?
>>><snip>
>>
>>
>> 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.
>
>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 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.
>> 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.
>** Adding notes on "this workes better than that", is cumbersome
What do you mean by the above? I just don't follow, at all.
>** 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.)
>** 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.
>** Creating of simulation files is not supported.
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?
>** Waveform style comments ?
Got me.
>** Editing is quite slow
In LTSpice? I'm fine with it.
>** 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.
>** 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.
Jon
Hmm?
Jon
Sorry, accidentally hit the wrong button. :-)
> 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
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
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.
--
--
kens...@rahul.net forging knowledge
>
> 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
Another PEEL lover. I thought I was alone
in the world. Very nice devices and never
had a lick of trouble with them.
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/>
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
> 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, "sleb...@yahoo.com" <sleb...@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
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
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
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