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