VHDL refactoring tools

[c d saunter]

Greetings All,

I've just spent 20 mins editing 12 VHDL files to add two signals and route
them up and down a design hierarchy.

Tedious and not exactly rocket science.

Is anyone aware of any refactoring tools out there to automate such
processes?

Regards,
Chris

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:cdrp54tdqqao7guh0cf1gcv3jfr70mmi7m@4ax.com...

If it's a more fundamental change, then it raises a much
bigger question about the design of component hierarchy
and why you got the interfaces between components wrong
in the first place (that's not a criticism, just a bald
statement of the problem).

Actually not. The software folks who practice agile development insist on
incremental development, frequent testable deliverables and designing in
absolutely no more than is required for the current deliverable. Given
that, the changing of interfaces and hierarchy and the re-factoring of code
into different functionality is part of the way of going about business.
Whether you subscribe to or accept that as a 'good' design approach or not
for developing hardware, it does appear to be an increasingly popular
software development method and these changes do not necessarily mean that
the interfaces were wrong in the first place.

Kevin Jennings

 

[KJ]

<kennheinrich@sympatico.ca> wrote in message
news:149d8a46-8a59-417d-aee4-e71317e0ed35@59g2000hsb.googlegroups.com...

Sometimes, the use of heavy hierarchy and awkward structure is imposed
on you, no matter how much of a better job you could have done
yourself. I've been through the original poster's experience many
times, too. One case in point was when using a machine-generated
interface module generated by one of the wizard tools from one of the
"big two" FPGA vendors.

Choosing to use IP from a vendor is not the same as something being imposed
on you. There was a business decision made by someone in your company to
use the vendor's IP to implement the function. While you personally may
have had no input on the decision and therefore had the IP imposed on you,
the same can not be said of your company. Presumably part of that decision
was that it will cost less to use something that somebody already has than
it would be to re-design it yourselves. To the extent that the IP block
indeed does exactly what you expected of it than the decision will turn out
to be a sound one...when it doesn't, well one can cast blame widely but it
usually doesn't do much to solve the problem.

The module itself was built using structural
instantiation many levels deep, and the total code base from the
vendor tool was on the order of 100+ files. The module instantiated
at the lowest level one of the "hard IP" blocks in the FPGA.
Unfortunately, there was a problem with the hard IP which required a
two-way control/status bus to be "plumbed" down into the lowest level
block from the top.

You're the customer on the IP, generate a service request and put the heat
on the vendor to get the problem fixed. Then start working on the work
around because you have customers too who won't accept delays.

Also, there was a feature provided by the low-
level IP block (let's say, a CRC generator/checker module) that wasn't
made visible at the top level by the vendor's module, and we needed to
use it to save fabric gates. We then had to "plumb in" a two-way bus
all the way down through the hierarchy to access the ports on the low
level block.

Another service request, although this would be a feature suggestion...and
we all know where those end up in the priority pile. It's still worth
putting in if you think it could have some general utility. Although it
wouldn't help you in your particular case, if it gets implemented it would
benefit others in the future....just like you may have (or will) benefit
from others putting in feature suggestion on IP that you choose to use
further down the road...open source anything are examples of this continued
refinement, that one can benefit from and (unfortuneatly if you're working
under deadline) may contribute to in various ways.

To make the matter worse, there were seven or eight
different flavours of interface module we needed, and instead of
providing a module with generics, the vendor insisted on producing
seven or eight completely independent, but subtly different, copies of
the entire module. Now we had 700+ files to manage, and for each
flavour, we had to do the same control and CRC bus plumbing. Needless
to say, there were many errors made and much cursing Testbenches,
version control, regression, dumb typing errors -- all a complete
nightmare.

Clearly there's a (good) argument that says the vendor could have been
more foresighted and structured the module differently.

Actually the vendor is trying to protect the IP from being generic in any
sense because they are trying to also sell you silicon. Trying to make the
code somewhat opaque and non-generic hinders at least some from reverse
engineering it and creating something that gets used on competitor's
silicon. But remember, you don't have to choose to use the IP, you can
engineer the solution yourself...just like the vendor did. They spent their
money engineering a solution that might be acceptable to a majority of their
users, it's up to the market to sort out the winners and losers.

But I had
exactly the same thought as the OP -- to develop a refactoring tool
that could manage this type of thing well. Using something like a GUI
tool (like HDL Analyser, as mentioned) can assist, but then you get
into the whole other mess of having code that's been mangled, with
machine-generated random signal names all over the place, and all the
other stuff that goes along with these tools (lack of integration in
your existing version control system, binary proprietary file formats,
I can flame for hours on this ...! )

So enough with the war story. To the OP -- I feel your pain. To the
rest of the group -- this is an interesting thread - any other good
suggestions?

It is an interesting one, but like the others I don't know of any tools
either. Perhaps perusing the agile software developer communities might
provide something close.

Kevin Jennings

 

[KJ]

"Jonathan Bromley" <jonathan.bromley@MYCOMPANY.com> wrote in message
news:9tvs549ijq30lbbpp24n5c58bstsaj79mt@4ax.com...

On Sun, 22 Jun 2008 12:12:03 -0400, "KJ" wrote:


Jonathan Bromley wrote ...
If it's a more fundamental change, then it raises a much
bigger question about the design of component hierarchy
and why you got the interfaces between components wrong
in the first place (that's not a criticism, just a bald
statement of the problem).

Actually not. The software folks who practice agile development insist on
incremental development, frequent testable deliverables and designing in
absolutely no more than is required for the current deliverable. Given
that, the changing of interfaces and hierarchy and the re-factoring of
code
into different functionality is part of the way of going about business.
Whether you subscribe to or accept that as a 'good' design approach or not
for developing hardware, it does appear to be an increasingly popular
software development method and these changes do not necessarily mean that
the interfaces were wrong in the first place.

Interesting, but don't necessarily expect me to agree

Didn't expect you to, nor was I implying that I agree with developing in

that fashion, just that there are things to be learned from other
disciplines that can be applicable to what we do...and that reworking an
interface or refactoring is not necessarily a symptom of an initially
'wrong' interface/partitioning.

Why do we even bother to do hierarchical partitioning in
the first place? Because we wish to localise our design
activity sufficiently to be able to reason about it reliably.

Agreed...but also I would say to create reusable components so that on some
future project one can reuse instead of redo.

"Agile" refactoring of a design, as you describe, inevitably
widens the scope of that reasoning, making me question
whether the original partitioning was useful; if we can
think sufficiently clearly (perhaps with help from tools)
about the whole design to be able to redesign its internal
interfaces at the drop of a hat, then we didn't need it
to be partitioned.

I'm not quite sure what you're getting at. As I understand it, agile
development is still disciplined and correct design partitioning for the
deliverable at hand is still important, but it accepts that the partitioning
might change as new deliverables are being worked on in the future...it just
doesn't bog down current development with the needs for things that are down
the road. They would probably see it more as a continuous refinement
process that improves what they have but a willingness to toss out and redo
the things that (now in hindsight) may have been designed badly, or perhaps
were designed well for their purpose, but that purpose is no longer useful
and a more generalized design would be better.

How the interfaces and partitioning evolve over time as 'the project' moves
along and whether the original interfaces and partitioning were in fact
'good' or not, will depend almost completely on the skill of the
designer...I've yet to come across a case where that was not true. Skilled
people (working in their area of skill) generally produce good designs; good
designs can usually be readily modified to accomodate new situations but
that in no way necessarily reflects badly on the original design's
'constraints' for not foreseeing that new situation.

My experience (and note, only experience - no theory
at work here at all) is that if I need to change
an interface between components, I almost certainly
have the partitioning wrong; by contrast, if I got the
partitioning (reasonably) right, then I likely was able
to create a clean, reliable design for the interfaces
between blocks at the outset.

My experience is a mix, sometimes it is as you stated, but often it is
because of refinements and generalizations that occur later when you reuse
designs in new applications (sometimes no further than in the testbench for
the design itself). The refinements and generalizations of the reusable
component creates a better, more useful component that can be used in more
situations. Use of reusable code is the main way to get design productivity
advantage over the competition which (in theory) should lead to shorter
development times.

I don't consider anyone to be so experienced and wise that they could (or
should) develop the most generally useful and customizable widget at the
first crack. Darn near everything can be improved by application of more
thinking, but applying that thinking all upfront can result in late designs,
missed product windows, etc.

Creating the most generally useful widget right out of the shoot is probably
not cost appropriate for most projects since it burdens that project for the
cost and time of development of something that is only used in a (probably)
small subset of the possible cases that can be handled. However, *usage* of
that generally useful widget many times IS appropriate for many
projects...trouble starts when that generally useful widget doesn't quite
work right, but that's a totally separate issue.

On the other hand, we still have quite a lot to learn
from the Extreme Programming "test first, implement
later" approach. And there is a long history of the
hardware design community lagging a couple of decades
behind software design in its methodologies.

Hey, we're not THAT backwards out in hardware land....after all we know all
about concurrent processes executing in parallel. The software folks are
still grappling with how to deal with more than one processor.

Always a pleasure bantering with you.

Kevin Jennings

 

[KJ]

"Mike Treseler" <mtreseler@gmail.com> wrote in message
news:485E956A.8090701@gmail.com...

Jonathan Bromley wrote:

Why do we even bother to do hierarchical partitioning in the first place?

Exactly. A preference for describing lots
of boxes and wires is a hindrance to agile development

I disagree in that it can (should) encourage design reuse.

of vhdl synthesis code because the language
provides little assistance in this area.

Finally...something that emacs doesn't handle

And why do I need an interface if I'm writing
all the code in the design entity?

So you can reuse that widget in the future (or use something that you wrote
in the past) knowing that when simply connected it will work properly and
not spend any time redoing what you've already written and tested would be
one good reason.

For a three week development "sprint"
I focus on the top entity IO
and procedures to update the register
variables. When it sims, and makes Fmax,
I'm ready for the next sprint.

Certainly interfaces are required when
multiple designers work on the
same project

That would be another good reason.

, but there is no
upside to me in coding and
instancing an entity
just to update a register.

Presumably one would instance something that does something functionally
useful (maybe a PCI interface, a memory controller) that does not border on
the near trivial (like an internal memory that doesn't get synthesized to
flops).

When the level of functionality delivered by the entity is low, it had best
not come along with an interface that is difficult to understand since the
learning curve when using the entity must be considered as well. The bang
for the buck ratio here is how much function you get per unit of time needed
to understand how to use it (versus time needed to design and test it
yourself).

Kevin Jennings

 

[Andy]

On Jun 19, 7:32 am, christopher.saun...@durham.ac.uk (c d saunter)
wrote:

Greetings All,

I've just spent 20 mins editing 12 VHDL files to add two signals and route
them up and down a design hierarchy.

Tedious and not exactly rocket science.

Is anyone aware of any refactoring tools out there to automate such
processes?

Regards,
Chris

Well this method is not perfect, but it can help: Declare a record
type (either one and make all signals inout, or three for in, out,
inout) in a package and use that record type on the ports. Then you
can add/delete elements to the record by editing the package. This
typically works best for a bus or group of related signals that
typically go anywhere as a group. The entities may have multiple
record ports if they attach to multiple buses or signal groups.

It would be REALLY NICE if VHDL had user defined modes for record
types such that different elements of a record type port could have
different modes. Those user defined modes could then be used in a port
specification with a port of that type. You could define multiple
modes for the same type (i.e. master, slave for a bus).

Besides that, I strongly recommend not using components/configurations
if you do not need the configurability. Directly instantiate the
entity/architectures, and then you don't have any components or
configurations to keep up to date.

Andy

 

[Jonathan Bromley]

On Thu, 19 Jun 2008 12:32:21 c d saunter wrote:

I've just spent 20 mins editing 12 VHDL files to add two
signals and route them up and down a design hierarchy.

Tedious and not exactly rocket science.

Is anyone aware of any refactoring tools out there to
automate such processes?

I'm not sure I know exactly what you mean by "refactoring"
in this context. If you want to rearrange the hierarchy to
make such changes simpler then, no, I don't know of
anything that does it automatically. Design capture
tools such as HDL Designer might help, at a price.

I'm intrigued by the problem you describe. I agree that it
is neither exciting nor cutting-edge work, but I'm interested
to know why you need to do it at all.

If you merely need a temporary probe on a couple of internal
nodes, there are other ways to do it - not pretty ways,
but they exist and they work. No need to drill your
probe signals all the way through your hierarchy.

If it's a more fundamental change, then it raises a much
bigger question about the design of component hierarchy
and why you got the interfaces between components wrong
in the first place (that's not a criticism, just a bald
statement of the problem). It's certainly happened to me,
but in pretty much every case it has been self-inflicted
pain caused by carelessly building the hierarchy at too
fine a granularity. Procedures typically provide a much
cleaner and more flexible way to decompose functionality
than the heavy use of instance hierarchy, and a procedural
interface is usually much easier to extend or tweak than
a port interface.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

kennheinrich@sympatico.ca wrote:

So enough with the war story. To the OP -- I feel your pain. To the
rest of the group -- this is an interesting thread - any other good
suggestions?

Since you asked, I would suggest using real synthesis code
rather than vendor netlists. I would rather spend
the same amount of "wartime" writing/siming
and sometimes buying clean, portable, testable vhdl sources.

This is a matter of style and mine is a minority opinion.
The classical hardware method is to wire together prefabricated
modules, turn on the power, and start probing.
This works, but it shifts most of the working to debugging.

I agree with Jonathan about procedural rather than
structural decomposition. The base function of
a crc check is just a shift with a twist, and
adding procedural layers is something the vhdl
language is good for. VHDL synthesis works better
than most designers believe.

-- Mike Treseler

 

On Jun 21, 8:11 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Thu, 19 Jun 2008 12:32:21 c d saunter wrote:

I've just spent 20 mins editing 12 VHDL files to add two
signals and route them up and down a design hierarchy.

Tedious and not exactly rocket science.

Is anyone aware of any refactoring tools out there to
automate such processes?

I'm not sure I know exactly what you mean by "refactoring"
in this context. If you want to rearrange the hierarchy to
make such changes simpler then, no, I don't know of
anything that does it automatically. Design capture
tools such as HDL Designer might help, at a price.

I'm intrigued by the problem you describe. I agree that it
is neither exciting nor cutting-edge work, but I'm interested
to know why you need to do it at all.

If you merely need a temporary probe on a couple of internal
nodes, there are other ways to do it - not pretty ways,
but they exist and they work. No need to drill your
probe signals all the way through your hierarchy.

If it's a more fundamental change, then it raises a much
bigger question about the design of component hierarchy
and why you got the interfaces between components wrong
in the first place (that's not a criticism, just a bald
statement of the problem). It's certainly happened to me,
but in pretty much every case it has been self-inflicted
pain caused by carelessly building the hierarchy at too
fine a granularity. Procedures typically provide a much
cleaner and more flexible way to decompose functionality
than the heavy use of instance hierarchy, and a procedural
interface is usually much easier to extend or tweak than
a port interface.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

Johnathan wrote one point on which I can comment:

I'm intrigued by the problem you describe. I agree that it
is neither exciting nor cutting-edge work, but I'm interested
to know why you need to do it at all.

Sometimes, the use of heavy hierarchy and awkward structure is imposed
on you, no matter how much of a better job you could have done
yourself. I've been through the original poster's experience many
times, too. One case in point was when using a machine-generated
interface module generated by one of the wizard tools from one of the
"big two" FPGA vendors. The module itself was built using structural
instantiation many levels deep, and the total code base from the
vendor tool was on the order of 100+ files. The module instantiated
at the lowest level one of the "hard IP" blocks in the FPGA.
Unfortunately, there was a problem with the hard IP which required a
two-way control/status bus to be "plumbed" down into the lowest level
block from the top. Also, there was a feature provided by the low-
level IP block (let's say, a CRC generator/checker module) that wasn't
made visible at the top level by the vendor's module, and we needed to
use it to save fabric gates. We then had to "plumb in" a two-way bus
all the way down through the hierarchy to access the ports on the low
level block. To make the matter worse, there were seven or eight
different flavours of interface module we needed, and instead of
providing a module with generics, the vendor insisted on producing
seven or eight completely independent, but subtly different, copies of
the entire module. Now we had 700+ files to manage, and for each
flavour, we had to do the same control and CRC bus plumbing. Needless
to say, there were many errors made and much cursing Testbenches,
version control, regression, dumb typing errors -- all a complete
nightmare.

Clearly there's a (good) argument that says the vendor could have been
more foresighted and structured the module differently. But I had
exactly the same thought as the OP -- to develop a refactoring tool
that could manage this type of thing well. Using something like a GUI
tool (like HDL Analyser, as mentioned) can assist, but then you get
into the whole other mess of having code that's been mangled, with
machine-generated random signal names all over the place, and all the
other stuff that goes along with these tools (lack of integration in
your existing version control system, binary proprietary file formats,
I can flame for hours on this ...! )

So enough with the war story. To the OP -- I feel your pain. To the
rest of the group -- this is an interesting thread - any other good
suggestions?

- Kenn

 

[Jonathan Bromley]

On Sat, 21 Jun 2008 13:32:00 -0700 (PDT),
kennheinrich@sympatico.ca wrote:

I agree with you and Jonathan to a large extent about ways of
decomposing the design. I also prefer to infer and describe designs
[...]
In this particular example, though, and in many like it, I was trying
to use VHDL to get access to pre-existing hard resources in the FPGA
(a hard-wired CRC module

OK, I certainly see what you mean.

It seems to me that this exposes an unhappy and - I suspect -
intractable asymmetry in the way HDLs work: Once you have
wrapped something as an entity or other instantiable block,
you are committed to using it in a structural manner. At
any higher level of the hierarchy, there can be no appeal
to procedural code when using it. Procedural code must
be at a leaf of the instance tree.

I have never made any serious effort to get familiar
with any purely procedural hardware description schemes
such as MyHDL. Maybe now is the time for me to start
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

On Jun 21, 12:41 pm, Mike Treseler <mtrese...@gmail.com> wrote:

kennheinr...@sympatico.ca wrote:
So enough with the war story. To the OP -- I feel your pain. To the
rest of the group -- this is an interesting thread - any other good
suggestions?

Since you asked, I would suggest using real synthesis code
rather than vendor netlists. I would rather spend
the same amount of "wartime" writing/siming
and sometimes buying clean, portable, testable vhdl sources.

This is a matter of style and mine is a minority opinion.
The classical hardware method is to wire together prefabricated
modules, turn on the power, and start probing.
This works, but it shifts most of the working to debugging.

I agree with Jonathan about procedural rather than
structural decomposition. The base function of
a crc check is just a shift with a twist, and
adding procedural layers is something the vhdl
language is good for. VHDL synthesis works better
than most designers believe.

-- Mike Treseler

Mike,

I agree with you and Jonathan to a large extent about ways of
decomposing the design. I also prefer to infer and describe designs
rather than instantiating literally. I've actually seen guys who
randomly mixed inferred flops (the usual if rising_edge(clk) style),
and component-instantiated D-flops, not for any performance or
esoteric reason, but because they were, not to put too fine a point on
it, marginally incompetent. I still shudder when I think of that code!

In this particular example, though, and in many like it, I was trying
to use VHDL to get access to pre-existing hard resources in the FPGA
(a hard-wired CRC module that would run at 500 MHz and use up no
fabric, and there were twenty of them on the chip!). While I would
have liked to use VHDL to describe the CRC function, and as you point
out, would have been trivial to do, it would have cost me gates and
speed. The problem I was attacking was simply wiring and getting
access to ports on an inner hardware block.

- Kenn

 

[Jonathan Bromley]

On Sun, 22 Jun 2008 12:12:03 -0400, "KJ" wrote:

Jonathan Bromley wrote ...
If it's a more fundamental change, then it raises a much
bigger question about the design of component hierarchy
and why you got the interfaces between components wrong
in the first place (that's not a criticism, just a bald
statement of the problem).

Actually not. The software folks who practice agile development insist on
incremental development, frequent testable deliverables and designing in
absolutely no more than is required for the current deliverable. Given
that, the changing of interfaces and hierarchy and the re-factoring of code
into different functionality is part of the way of going about business.
Whether you subscribe to or accept that as a 'good' design approach or not
for developing hardware, it does appear to be an increasingly popular
software development method and these changes do not necessarily mean that
the interfaces were wrong in the first place.

Interesting, but don't necessarily expect me to agree

Why do we even bother to do hierarchical partitioning in
the first place? Because we wish to localise our design
activity sufficiently to be able to reason about it reliably.
"Agile" refactoring of a design, as you describe, inevitably
widens the scope of that reasoning, making me question
whether the original partitioning was useful; if we can
think sufficiently clearly (perhaps with help from tools)
about the whole design to be able to redesign its internal
interfaces at the drop of a hat, then we didn't need it
to be partitioned.

My experience (and note, only experience - no theory
at work here at all) is that if I need to change
an interface between components, I almost certainly
have the partitioning wrong; by contrast, if I got the
partitioning (reasonably) right, then I likely was able
to create a clean, reliable design for the interfaces
between blocks at the outset.

On the other hand, we still have quite a lot to learn
from the Extreme Programming "test first, implement
later" approach. And there is a long history of the
hardware design community lagging a couple of decades
behind software design in its methodologies.

thanks
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Jonathan Bromley wrote:

Why do we even bother to do hierarchical partitioning in
the first place?

Exactly. A preference for describing lots
of boxes and wires is a hindrance to agile development
of vhdl synthesis code because the language
provides little assistance in this area.
And why do I need an interface if I'm writing
all the code in the design entity?

For a three week development "sprint"
I focus on the top entity IO
and procedures to update the register
variables. When it sims, and makes Fmax,
I'm ready for the next sprint.

Certainly interfaces are required when
multiple designers work on the
same project, but there is no
upside to me in coding and
instancing an entity
just to update a register.

-- Mike Treseler

 

[Jonathan Bromley]

On Sun, 22 Jun 2008 14:34:41 -0400, "KJ" wrote:

As I understand it, agile development is still disciplined
and correct design partitioning for the deliverable at hand
is still important, but it accepts that the partitioning
might change as new deliverables are being worked on in the future

Oh dear, it looks as though I need to find out about what
this is all about before I say anything more

Interesting stuff.

When I plan for future re-use, I know that for almost every
future re-use my planning will be wrong. But it's still
worth trying, because when I plan for future re-use, I write
much better code than when I don't.

Maybe, just maybe, one day I'll learn how to be a proper
programmer.

Hey, we're not THAT backwards out in hardware land....
after all we know all about concurrent processes executing
in parallel. The software folks are still grappling with
how to deal with more than one processor.

Now THAT is a really good way of (as one of my colleagues
recently said, in a different context) "pressing my bad
behaviour buttons". Way, way back in about 1976 I heard
Tony Hoare talking about CSP, and after a while the glorious
realisation dawned on me that I couldn't tell whether he was
talking about hardware or software. But that was a lone
voice in the wilderness. One of the few really deep
frustrations of my largely happy career has been the way
in which many software folk have so persistently ignored
any ideas that don't fit into a sequential model.

thanks
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Mike Treseler]

Andy wrote:

Am I missing something? Procedural interfaces still require data to be
passed in and out, but if the needed data was not passed, the same
problem exists.

I should have explained that I write single process
entities so that my register update procedures
have direct access to all the register variables
in the process. For this reason I use
either a simple interface list like this,

procedure retime
(arg_in : in std_ulogic; -- input value
update : inout retime_t -- 3 bit shifter
)
is
begin
update.f3 := update.f2; -- f2[DQ]f3
-- \__
-- \
update.f2 := update.f1; -- f1[DQ]f2
-- \__
-- \
update.f1 := arg_in; -- in[DQ]f1
end procedure retime;

or sometimes no interface at all, like this:

procedure inc_tic_count is
begin
RxBitSampleCount_v := RxBitSampleCount_v+1;
end procedure inc_tic_count;

just to unify repeated statements.

I do use port maps at the top level,
but my bias is for large entities with
small interfaces. Some generic interface
entities are reusable by others, but I find that
most reuse by me involves scavenging bits and pieces
from old designs. Packaging procedures like
retime above adds some formality to this process.

-- Mike Treseler

 

[Jonathan Bromley]

On Mon, 23 Jun 2008 06:47:40 -0700 (PDT), Andy wrote:

Am I missing something? Procedural interfaces still require data to be
passed in and out, but if the needed data was not passed, the same
problem exists.

Yes, but you can add new procedures without breaking code that
uses the old set of procedures. That ain't true for ports. [*]
Procedures also compose better than ports: if I have a procedure
that *nearly* does what I want, I can usually wrap it in another
procedure that adjusts things to make it do *exactly* what I want;
and again the old interface isn't broken, and the existing users
of my old interface are not disrupted by the new extensions.

I know it's never really quite that simple, but...

[*] In VHDL where it's fairly easy to put defaults on ports
and to leave ports unconnected on an instance, this back-
compatibility argument is not so strong as it is for Verilog
where such things are painful.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

On Jun 21, 11:41 am, Mike Treseler <mtrese...@gmail.com> wrote:

I agree with Jonathan about procedural rather than
structural decomposition. The base function of
a crc check is just a shift with a twist, and
adding procedural layers is something the vhdl
language is good for. VHDL synthesis works better
than most designers believe.

-- Mike Treseler

Am I missing something? Procedural interfaces still require data to be
passed in and out, but if the needed data was not passed, the same
problem exists. Unless you go to global signals, where there is no
hierarchy at all, or you use one huge file to take advantage of local
scope (always defining procedures inside the scope of the procedure in
which they are called), procedures vs entities don't appear to make a
difference. Both methods (globals and entirely local scope) have been
discredited in SW and HW design for a long time. Actually, one
language (ada, from which much of vhdl was borrowed) allows a
procedure to be locally declared and externally implemented in a
separate file, but I don't know if that eliminates local scope
advantages.

The ability to "containerize' the interface (procedure or entity),
like running virtual conduit through a building's walls, allows one to
add/subtract interface elements, without having to tear into the
intervening walls. And VDHL "conduits" (record types), unlike real
ones, never "fill up". They just don't currently have a flexible means
of defining directionality (port modes).

Andy

 

[Mike Treseler]

Andy wrote:

local inheritance, which can avoid ports in the first place, but that
also obviates the possibility for reuse of that procedure, since it is
out of scope everywhere else, and always operates on the same local
objects.

I use procedures for clarity and speed of coding.
Reuse is sometimes a nice side effect.

The original post exhibited a need for being able to easily plumb new
data through multiple levels of hierarchy in a design. Short of making
a whole project (ASIC or FPGA) one big entity/architecture with nested
local scopes for various procedures (and one huge source file), I
don't see how using procedures solves his problem.

I think both Jonathan and I punted that part of the problem.
Your suggestion of structured ports at least addresses Chris's problem.

So every procedure must be in the same
process. This is likely to complicate managing the order of
operations, which with variables, implies register usage.

Yes, I use one process per entity.
Yes, the variables I declare become registers.
The order of operations is a single thread per tick.
Or do you mean the order of piped registers?

I actually like the use of procedures on a small scale (i.e. within a
modestly sized process for clarification/separation of distinct
functionality). But there is a practical limit to the scope of their
application in synchronous, synthesizable code.

There is a practical limit to every style.

-- Mike Treseler

 

[Andy]

On Jun 23, 10:32 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

On Mon, 23 Jun 2008 06:47:40 -0700 (PDT), Andy wrote:
Am I missing something? Procedural interfaces still require data to be
passed in and out, but if the needed data was not passed, the same
problem exists.

Yes, but you can add new procedures without breaking code that
uses the old set of procedures. That ain't true for ports. [*]
Procedures also compose better than ports: if I have a procedure
that *nearly* does what I want, I can usually wrap it in another
procedure that adjusts things to make it do *exactly* what I want;
and again the old interface isn't broken, and the existing users
of my old interface are not disrupted by the new extensions.

I know it's never really quite that simple, but...

I guess I'm still not following. Any procedure than can be wrapped by
another procedure to "fix things" can also be represented by an entity
wrapped by another entity/architecture to do the same thing. Granted,
to do it in one source file, you'd have to have more than one entity/
architecture in the file, but that is a matter of form, not imposed by
the language or tools. If the ports have to be changed, they have to
be changed either way (entity or procedure). The procedure allows
local inheritance, which can avoid ports in the first place, but that
also obviates the possibility for reuse of that procedure, since it is
out of scope everywhere else, and always operates on the same local
objects. Without reuse, the need to keep it unmodified for fear of
breaking another instance (call) of it is also eliminated.

The original post exhibited a need for being able to easily plumb new
data through multiple levels of hierarchy in a design. Short of making
a whole project (ASIC or FPGA) one big entity/architecture with nested
local scopes for various procedures (and one huge source file), I
don't see how using procedures solves his problem. In fact, block
statements could be used to do the same thing without procedures, but
they will all necessarily be in the same source file.

Using procedures on the scale being proposed (eliminating all but a
single top level entity/architecture) is also unworkable due to the
current synthesis tool's inability to allow a subprogram to span time
(include a wait statement). So every procedure must be in the same
process. This is likely to complicate managing the order of
operations, which with variables, implies register usage.

I actually like the use of procedures on a small scale (i.e. within a
modestly sized process for clarification/separation of distinct
functionality). But there is a practical limit to the scope of their
application in synchronous, synthesizable code.

Andy

 

[Mike Treseler]

kennheinrich@sympatico.ca wrote:

No matter how elegant the academic theory behind
it might be, I'll never try to infer a Sonet controller similarly to
the way I infer a block RAM.

Who has the free Sonet controllers?

I've seen guys who implement every interface as a std_logic_vector,
that just grows, and grows, and grows, as needed. I've also seen their
code: it's an endless sea of meaningless code like

if (interface_a(16) and not interface_b(14)) then

-- this means the event triggered
interface_c(14) := '1';
-- so clear the reset

I think I know those guys

Good example of "untouchable" code.
Use it while it works, but start over when it doesn't.

-- Mike Treseler