[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: vhdl and gschem



On Sunday 18 February 2007 20:01, Magnus Danielson wrote:
> I on the other hand would have preferred VHDL. There is many
> reasons for it.

In the long run it really doesn't matter.  The simulator core 
handles lists of blocks with connections.  Anything more than 
that is handled through plug-ins.  The native language will be 
the structural subset of Verilog-AMS.  More advanced features 
will be too slow if they are run interpreted.  Most models 
(modules, entities, etc.) will be compiled, and used as 
plug-ins.  Once the system is in place, it will be trivial to 
also support the Spectre format, "Mast" and other ways to 
describe circuits.  There can be several plugins for Spice, to 
mimic different versions of it.  It will finally become 
possible to have 100% compatibility with a particular Spice, 
and still grow beyond it, which is something no Spice can do.

For now, plug-ins are .so files.  To use one you say something 
like "attach transient.so" to say you will use the transient 
analysis plug-in, or "attach resistor.so" or whatever.  Soon, 
this will be extended so you can say "attach my-transient.cc" 
or "attach my-oscillator.vams" or whatever, and it will build 
the .so and attach it.

The choice of Verilog is simply what to support first.  Here's 
why:

Consider this:
==========
module filter (in, out);
  ground gnd;
  resistor #(.r(1K)) R1 (in, out);
  capacitor #(.c(1n)) C1(out, gnd);
endmodule

The ports could have been expressed as (.p(in), .n(out))
but I chose to use the shorter notation.
==========
or this:
==========
entity filter is
  port (terminal in, out : electrical);
end entity filter;

architecture v1 of filter is
  terminal in, out: electrical;
begin
  r1: entity resistor generic map (r => 1K)
	port map (p => in, n => out);
  c1: entity capacitor generic map (c => 1n)
	port map (p => out, n => gnd);
end architecture v1;
==========
To put it in perspective, this is the old way:
==========
.subckt filter in out
r1 in out 1k
c1 out 0 1n
.ends
==========

The problems with the third format cannot be seen with such a 
simple example, but lots of people know what they are.

Of the first two ....

If you are accustomed to the third, and need to make a change, 
which is the easier transition?

You are teaching circuits to undergraduates, half of whom failed 
the introduction to programming class.  Which would you rather 
teach?

At this level, the only real difference I see between the 
formats is the baggage "port map", "generic map", "entity" on 
every line, the "entity" block. ...

In either case, the items in the list all have the same 4 parts.  
(instance_name, parameters, type, connections)   Both languages 
are consistent.  So it is a simple change from one to the 
other.  Regardless of which is first, the other will show up 
soon.

That third format presents some real problems I would like to 
put behind.  At least they can now be pushed out to a plug-in.

As a reminder of one of the problems with the third format .. 
consider this:
  X1 a b c d e f g h i j k
Clearly, this has connections a, b, c.  It refers to a model 
named "d".  Parameters are being passed e=f, g is a binary that 
is set to true, h=i, j=k.

It's not clear to you?  Hmmm.....

For those who need it ... .. The first fomat is Verilog.  The 
second is VHDL.  The third ("old way") is Spice.


There are other factors, but most important is that when you 
look at what is important, there is no difference.  The 
plug-ins will let you parse it any way you want, and pass on 
the data.  I expect that the only parsing plugins that will be 
a mess are the multitude of Spice format plugins.  The others 
will be trivial.  I can even see being able to read gschem 
files directly, using a plug-in.





_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user