Re: VHDL, was Re: gEDA-dev: Hierarchical buses

[al davis <ad136-at-NOSPAMfreeelectron_dot_net>]

On Wednesday 21 March 2007 07:35, Udi Finkelstein wrote:
> On 3/21/07, al davis <ad136@freeelectron.net> wrote:
> > I'm sorry ... I don't see it. 
> >
> > I do see a "config" keyword, but I don't see how that
> > provides the functionality of VHDL's entity/architecture.
> >
> > Can you show me?
>
> Here is a presentation  from Sutherland HDL:
> http://www.sutherland-hdl.com/papers/2000-HDLCon-presentation
>_Verilog-2000.pdf I usually don' bother loading the PDF, and
> just look at the HTML through google.

I was aware of that.  I don't see how it provides the 
entity/architecture functionality.

> What's the difference? In the bottom line, all you are using
> (from either language) is just the structural subset. All
> left to decide is the technique in which you bind a specific
> module (or symbol or entity - or any name you like to call
> it) to it's reference in the netlist.
>
> All I see is "module".
>
> If you require the exact VHDL semantics:
> 1. an entity with a function prototype
> 2. multiple architectures that has no prototype
> 3. Multiple architectures can optionally reside in the same
> file then you are right.

That is the requirement.

Actually, #2 could have a prototype, which would be checked for 
consistency against the entity.

A real mixed-mode simulator needs this, too.  One of the reasons 
the industry doesn't see this is that they all have 80's 
technology dual-engine simulators.  Take an analog simulator 
and digital simulator, compile into a single executable, call 
that "single kernel".  They claim to be tightly coupled because 
a script automatically splits them up and sends the pieces to 
the analog or digital simulator as appropriate.  That's 80's 
technology .. 20 years old.

I proposed inheritance (as in C++) to the Verilog-AMS committee, 
but it was not accepted.  I had a complete proposal with syntax 
and semantics.  This would have been more capable than VHDL's 
entity/architecture, and simpler, and fully compatible with old 
Verilog.  They did include a watered down variant 
as "paramset", that lost the original reason for the proposal.  
It added the functionality of the spice ".model" card.

With inheritance, you would have a base "module", which would 
give the "entity" functionality and more, and derived "modules" 
which would give the "architecture" functionality and more.  
Like C++, it could inherit much more than the interface.

I was not able to follow through because my life was falling 
apart as a result of a bad career move.

Maybe we should add it, making our own extended version, then 
try again to get it into the standard.  I would go for this.  
Since the gEDA group is fairly conservative technically, I 
thought this would be a bigger stretch than VHDL.

> What I meant is that the configuration block gives you the
> basic ability of switching implementation of a sub-module
> without changing the original source file where it is
> referenced, in a language defined way, and have different
> implementations on the same design (after all - you could
> solve this by defining the library search path for the tool,
> but then all instances would get the same implementation).

I saw that.  I am not sure how much it really accomplishes.  
They were still thinking of digital simulation and 
verification.  It is useful somewhat beyond that scope, but I 
think they missed the true scope of this kind of language. 

That's where the -AMS committee comes in.  They do see the wider 
scope, but are dominated by device people, and unfortunately 
still accept a Spice top-level.

> You can achieve the same thing in verilog by using the same
> approach used by OpenOffice, Java and others: A renamed ZIP
> file containing multiple files: schem/board1.v
> pcb/board1.v
> netlist/board1.v
> symbol/...
> etc.

That is one way to do it, somewhat of a kluge.  It adds extra 
complexity, which I would rather not do.  I would like a format 
that is reasonable to use directly, if we choose to do so.  
Eliminating the translation step is well worth doing, 
eventually.

I always wondered why OO and Java chose .zip over .tar.gz 
or .tar.Z.  Knowing the history of .zip, I really prefer to 
stay away.

> > I suppose it could be done by having several modules, with a
> > naming convention, and some way to say that they all
> > represent the same object.  But then, we are extending the
> > language, which I don't want to do.
> >
> > If you can show me how, you win!
> > I don't particularly like the ADA style syntax of VHDL, but
> > that is not important.
> >
> > > 4. gEDA already has a verilog simulator (Icarus), making
> > > a Verilog netlist more "native" to the project.
> >
> > Gnucap some code, in process, for Verilog.
>
> I suspected that (remembered that from reading), but couldn't
> find reference in GNUcap's web pages (either of them - BTW,
> the GNU page is not up to date as the gEDA one).

.. and the gEDA one is not as up to date as gnucap.org, which is 
not as up to date as the actual program, which is ......

There is work to do here.

I had a few bad years.

> > If you just think of one tool by itself, it doesn't buy
> > anything.  The benefit is enabling the tools to work
> > together better, by using a common interchange format.
>
> If by common you mean that each tool simply ignores the other
> tool's information (except for the netlist part, that
> everyone understands), then you are right.
> What bothers me is that there is no way to convey the PCB and
> schematic information in a VHDL or Verilog file in a
> *meaningful* way.

Meaning is implied by the reader.

> >They have the concept of a list of objects with connections
> > and parameters.  That's all you need.
>
> Having read further, looking at Verilog-AMS, and giving it
> further thought, I agree that you might have some point here.
> Lets say you have a schematic with multiple, identical
> sub-sheets (is this handled by gEDA today?)
> With the sub-sheet having several components, resistors, for
> example. Where would you keep the resistor's reference number
> and their values for each instance?
> Would you pass it in a very long parameter list on each
> sub-sheet instanciation?

What kind of parameters?  Why is the list so long?  You would 
not pass instance names.  What is a "reference number" and why 
would you pass that?  Look at how Spice handles subcircuits.

The only parameters I can think of are those that would make the 
instances different.  Suppose the "sub-sheet" is a second order 
active filter.  You might pass frequency and Q, and some 
component values would be expressions.  On 
expansion/elaboration/whatever, the expression would be 
replaced by the value.  Just like these languages do now.  Old 
stuff!

> Would PCB take the same hierarchical netlist and work on it
> directly, or do you expect it to be flattened by gschem
> before PCB can use it? 

gschem should know nothing about PCB.  Flattening throws away 
information.  The interchange format must preserve hierarchy.

> Now when you add the PCB information. 
> How do you convey the fact that a given wire is actually a
> PCB trace?

What you are referring to is the conversion process.  We have 
that now, but less clean. Using a common syntax for input and 
output formats makes the job easier and more general.  It gives 
us a new mechanism for importing and exporting foreign formats.

> when I think of this, you will need to replace each wire with
> a wire object. a schematic will break it into a chain of
> straight wires with parameters specifying their location on
> the screen
> a PCB layout will break it into a chain of objects specifying
> PCB traces, vias. each object will also have X/Y/layer
> coordinates, trace width, etc. given the correct model, this
> might even simulate in a simplistic way (for example, a trace
> model might simulate PCB delays, given the PCB material as
> parameter, but will not be able to simulate signal integrity,
> since each model has no information about other traces).

That list of wires or list of traces and vias is a reasonable 
thing to pass to a simulator, especially if it is expressed in 
a language that the simulator already understands, like the 
structural subset of VHDL or Verilog.

> > Where the components are located, and net names, .. are the
> > same thing from a language viewpoint.
> >
> > From the PCB or gschem view, a list is a list, but you need
> > to define the language.  From the simulation or synthesis
> > view, using a standard language makes things a lot easier.
>
> OK, so giving this further thought, I've been convinced that
> meaningful schematic/PCB information CAN be represented in a
> meaningful way in a structural netlist like Verilog and VHDL
> offers.

Making progress....

If someone is willing to code, I will look closer at the PCB and 
gschem formats and come up with a spec for the translation.  
gnucap can deal with it easily directly.  I am also willing to 
design an overall architecture for the translator, and act as a 
mentor.  (That's SOC mentor, not "Mentor Graphics 
Corporation" :-).

At this point, the difference between Verilog and VHDL doesn't 
matter.  If it is done properly, a command-line switch should 
be able to go either way, with very little extra effort.  Only 
the entity/architecture issue gets in the way.

I think it is a good "summer of code" project.  Difficulty = 3 
(after specifying in detail, which I am willing to do.)

From a student perspective ... You get something to call your 
own, that will make a good conference paper, that will be 
noticed by the EDA industry.


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