VHDL ... Sideways?

Thu Jul 22, 2010 6:28 am   

VHDL is very good at describing a hierarchical system, but I'm trying
to design one now that is more of a... graph. How would I go about
describing the following relationship:

Top<->A
Top<->X
A<->B
B<->C
C->Dx
Dx<->X
Dx->E
E->X
E->F
F->C

(Where Dx indicates a number of entities)

This is a very simplified version of my system, but even this gives a
good indication of how complicated it could be if viewed purely
hierarchically. I have an arbitrary number of different D
architectures, and each D entity connects to the X and E entities
(Data travels back and forth from X, it travels only to E.) The arrows
indicate the direction of data through the system, though in all
instances flow control data is sent in both directions.

Is there any way for me to "bring" ports from entities lower in the
hierarchy up to the top without threading them all the way through?
The issue is that A and B are fairly generic components and I'd rather
they not have to know about C or any of the D's, let alone X. And C
also shouldn't have any clue about X. Right now I just route all the
signals X needs from outside of the design all the way through A, B,
C, and each Dx, but those signals have nothing to do with how D works.
This is making it impossible for me to package A and B in a way that I
can use them in some other designs I'm working on, as well as causing
all sorts of other headaches.

I can see how the configuration keyword would allow me to swap out
different architectures for each Dx, but I don't see how to hide X for
A, B, or C. Hopefully there's a nice solution...

Thanks!

Thu Jul 22, 2010 10:51 am   

On 22 Jul., 05:28, Sudoer <TheProperN...@psychophile.com> wrote:

Hi,
why should one bring ports from the lower end of a deep hierarchy to
the toplevel?
If that would be necessary there would be no need for a hierarchy,
just a number of parallel modules or processes combined by one top
level.
Except for global signals like Clock and Reset, ports from a lower
hierarchy should be seen only by the connected part one hierarchy
level above. The higher level modules don't even know about their
existence.

Configuration is for simulation only and a means to swap different
implementations of the same module for testing purposes (Like you
probably want to do with the Dx architectures).

I suspect you are going to do something weird with VHDL, beyound it's
intended focus.
So here are some tips that might be helpful.

There are so called "shared" objects. Another word for global
variables but basically the same.
They are normally considered bad, because they break up the well
structured world of hardware design. For simulation and experimental
purposes this might be ok.

Another way to save you from typing long port lists is using record
typed ports.
Search this forum, comp.arch.fpga or the forums.xilinx.com for
details.
With these you have just to type one line to route the full port list
of a module through the port description of another module. Should
save you a lot of code lines.

Also, using functions and procedures instead of instances may help.
These can be defined in a Package, and are available to all entities
where the pachage is included via the USE statement.

_________________

You say that A and B are "fairly generic components" and should'nt
know about C and Dx at all if possible?
So why do you connect C to B anyway? If you feed some data from the
top to A and B, then the results could be returned to some toplevel
signals and C is instantiated in the toplevel too.
If you want to communicate from all modules with all modules why do
you create hierarchies then. As you said your design is more like a
graph, well why don't you design it that way.
Graph connections and operators/branching points are drawn on the same
sheet, meaning they share the same hierarchy level. Only if a subgraph
can be isolated from the rest, it can create it's own subhierarchy and
is seen on the toplevel as a single Operator with a defined interface.

It should be similar to the design of hierarchical FSMs. A state can
consist of another sub-FSM. but when the top-FSM enters this state it
halts until the sub-FSM has ended it's actions and the top-FSM can
continue.


Have a nice simulation
Eilert

Thu Jul 22, 2010 2:58 pm   

On Wed, 21 Jul 2010 20:28:00 -0700 (PDT), Sudoer <TheProperNoun_at_psychophile.com>
wrote:


There are "shared variables" but they won't help you if the intent is synthesis.
They can be used as test points in testbenches so that you don't need to bring
internal test points all the way up the hierarchy, but synthesis support for
these is likely to be somewhere between poor and non-existent.


One thing to try is records as ports; the definition of the record can be hidden
in a package and (somewhat) parameterised.

One major limitation of records as ports; all members of a record have to be
used in the same direction. Thus you can collect e.g.
Addr,
Wr_Data,
Wr_En,
Rd_En
into one record (Data_Out) but you will need a second record (Data_In) for
signals in the reverse direction, e.g.
Rd_Data,
Ack,
Interrupt

Each of these records can be an output port on Dx and E respectively, then an
input port on E and Dx.

Record members can be any data type including other records, or arrays of
records. Therefore you can create records for ports A to B, and B to A, in a
package, and hide the implementation of those records in the package body.
A and B can simply use those records and pass them (or components of them) to C
internally without knowing they contain an array of records linking blocks Dx to
X or E.

It may be possible to set the array size with a generic according to the number
of D units.

It is important, inside e.g. the blocks C, to check that the package and the
blocks are consistent, eg by asserting the array size and data bus size are
consistent - then you cannot update the blocks and forget to update the package
or vice versa.

This is all synthesisable, for blocks internal to an FPGA. Top level ports (FPGA
pins) are usually restricted to std_logic[_vector] since the post-synthesis
netlist will flatten anything else to std_logic[_vector].

You could use records here too, and in the testbench, but then you would need to
write a wrapper between your ports and the post-synthesis netlist if you ever
wanted to run post-synthesis simulation.

- Brian

Thu Jul 22, 2010 3:38 pm   

On Jul 21, 11:28 pm, Sudoer <TheProperN...@psychophile.com> wrote:

I don't get what you are trying to describe. Are you saying that D is
being instantiated within A, B and C, but there are different Ds and
you don't want A,, B or C to specify the type of D (or X)? I don't
really get it... Can you be more concrete?

Rick

Thu Jul 22, 2010 4:58 pm   

TheProperNoun wrote:


Yes it can. The trick is just not to leave the procedure. And the procedure
must be called outside from a process, so directly in an architecture. This
is called a "concurrent procedure call". Such a procedure declaration might
look like:

PROCEDURE my_procedure
(
SIGNAL clk: IN std_ulogic;
SIGNAL sig_in1: IN some_type;
SIGNAL sig_in2: IN some_other_type;
SIGNAL sig_out1 OUT blaah_type
) IS
VARIABLE v1: ...;
VARIABLE v2: ...;
BEGIN
... do some (optional) initialisation
...

forever: LOOP
WAIT UNTIL clk = '1';
... do your stuff
...
END LOOP forever;
END PROCEDURE my_procedure;

I guess this is highly unsynthesisable. I use this a lot for behavioral
modeling. The models do not have a clock, they are event driven. So the
WAIT and the rest below looks a bit different:

WAIT ON sig_in1, sig_in2;

IF sig_in1'EVENT THEN
... handle event on sig_in1
END IF;

IF sig_in2'EVENT THEN
... handle event on sig_in2
END IF;

--
Paul Uiterlinden
www.aimvalley.nl
e-mail addres: remove the not.

Thu Jul 22, 2010 6:36 pm   

Thanks everyone. Yes, it seems that for the structure I should both be
flattening my hierarchy some and using records. I had started my
design before I knew enough HDL to go at it this way - time to go back
and do some re-engineering.

Someone pointed out that procedures could be used as a sort of global
process. Can such a procedure maintain state internally? I.E., when I
declare variables in a procedure does the value of the variable remain
between calls? (My guess is that it doesn't, otherwise there could be
consistency issues involving elaboration of constants passed into it.)
To maintain state I presume I'd also need to use global signals... I
don't think I'll go this route - but considering how deep I am into my
design and how time pressures are building, I could be tempted to
temporarily do this until I can go back and flatten things out.

Also, as per Eilert's suggestion and Brian's response I looked up some
older posts about using records as ports, and one mentioned their hope
that in VHDL 2006 records would allow in and out designations on
records. ISE 12.1 certainly doesn't support this in 200x mode, any
idea if this has been done as of 2008, or if it's planned for the next
revision?

Another question I saw brought up was converting between
STD_LOGIC_VECTOR and Record types. Coming from a C++ background my
first instinct is, rather than writing a custom function instead have
an override of the type's built in conversion functions. I.E.,
TYPE_NAME( ... ) is supposed to convert whatever is passed to it to
TYPE_NAME - is there any way for me to overload this standard
conversion function for STD_LOGIC_VECTOR to and from my record types?

Thanks again!

Thu Jul 22, 2010 8:28 pm   

On Thu, 22 Jul 2010 08:36:32 -0700 (PDT), TheProperNoun
<thepropernoun_at_gmail.com> wrote:


Good guess. Use a process for that; its variables are (a) invisible externally,
and (b) maintain their value between process invocations (e.g. clock events)
Much better for the purpose than global signals (though the latter can work).

If you need signals (whose semantics are sufficiently different to variables to
catch beginners out) you don't need to make them global : you can wrap the
process and its "local" signals in a block. but variables are more commonly
used.


Don't trust to it this year or next... ask again in 2012. Meanwhile use a
separate record in each direction...


to_slv(my_record_type1) and to_slv(my_record_type2) will overload safely.
Ditto to_my_record_type1(SLV_param) and to_my_record_type1(integer_param).

- Brian

Thu Jul 22, 2010 8:32 pm   

On Thu, 22 Jul 2010 10:55:01 -0700 (PDT), Andy <jonesandy_at_comcast.net> wrote:


However, WITHIN an FPGA, "inout" is of very little use, so separate read and
write paths for data are usually simpler; eliminate arbitration; don't require
tristates, and only call for a 2-port solution. (Which is why I didn't even
mention the 3rd port).

External interfaces are a different matter, so it's a good thing you brought it
up.

- Brian

Thu Jul 22, 2010 8:55 pm   

As mentioned earlier, record-type ports can make plumbing of
interfaces through levels of hierarchy easier, but there is a major
drawback: the entire record port must be of one direction. So you
could use one port of inout, or you could use three ports of in, out
and inout, and three records for each "interface". The three-port
solution is often cumbersome because different endpoints need
different subsets defined as in vs out vs inout (think about master vs
slave consumers of a common bus). Manipulating the data around between
records when trying to connect a master to a slave is ugly, but can
also be hidden in a procedure.

The single inout port is easier to plumb and manage, but you have to
use only resolved data types, and anywhere a signal is really only
used as an input, you still have to drive 'Z' to keep the port from
getting clobbered with a 'U'. It generally works best if you have a
constant record with all elements assigned to 'Z' or (others => 'Z'),
etc. and assign the port with that constant in all the leaf level
architectures just to be sure. This causes a lot of extra resolution
work for the simulator, but it allows the user to route a complex
interface through hierharchy much more easily.

I have long lobbied for a user-defined port direction declaration for
record types, such that different elements of a single record type
port could be used as ins, outs, and inouts. You could even have
multiple direction declarations for the same record type (e.g.
"master" or "slave", etc.) for use by different endpoints. This would
make using records on ports so much easier and readable, but alas, it
is not here yet.

Andy

Fri Jul 23, 2010 1:45 am   

I use inouts with tri-state logic inside FPGAs, because it is often
simpler to describe than a distributed mux, and less clutter than a
centralized mux. The synthesis tool will convert it to muxes and
separate direction signals for you. Used in records, there's usually
only one leaf level driving the inout, and it never drives 'Z'. The
others (receivers or ignorers) always drive 'Z's. No muxes, the
synthesis tool just figures it out.

The only downside is you can't use enums, integers, booleans, etc.

Andy

Fri Jul 23, 2010 6:46 am   

On Jul 22, 1:55 pm, Andy <jonesa...@comcast.net> wrote:


A search of the VHDL Analysis and Standardization Group at
http://www.eda-stds.org/vasg/bugrep.htm would indicate that either you
haven't been lobbying the correct place or the records of that
lobbying have been lost.

Searching for 'direction' doesn't produce anything resembling 'user-
defined port direction'
https://bugzilla.mentor.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=direction

Searching for 'port' doesn't produce anything resembling 'user-defined
port direction'
https://bugzilla.mentor.com/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=&content=port

Kevin Jennings

Fri Jul 23, 2010 10:31 am   

On 22 Jul., 15:58, Brian Drummond <brian_drumm...@btconnect.com>
wrote:


You can use global signals in your design and will end up with a good
synthesis result (at least with Synplify)
In therory this would allow you to build all entities without ports
and save a lot of signal routing through hierarchies.

Nevertheless I would recommend not to use global signals in rtl
because you will likely break on several points when maintaining the
code.

bye Thomas

Fri Jul 23, 2010 10:43 am   

On 23 July, 08:31, Thomas Stanka <usenet_nospam_va...@stanka-web.de>
wrote:

Altera just refuse to synthesise global signals full stop. I have
raised an issue about this and they say they will never support them
(as they say they are only really for debugging in simulation).

Fri Jul 23, 2010 10:50 am   

On Thu, 22 Jul 2010 15:45:21 -0700 (PDT), Andy <jonesandy_at_comcast.net> wrote:


If it works, that's reasonable. I ran into trouble though, when the muxes turned
out too slow. That was back on ISE 6, so it may be an assumption worth
challenging again. Thanks!

- Brian

Sat Jul 24, 2010 7:44 pm   

On Sat, 24 Jul 2010 10:32:53 -0700 (PDT), Sudoer <TheProperNoun_at_psychophile.com>
wrote:



ISIM is finally starting to look like a real simulator, but still has quite a
few errors.

I suggest a divide-and-conquer to find the specific construct that kills it -
there may well be a usable workround. I can't make specific suggestions of
course; but one anecdote:

In ISE10, ISIM would crash (Segment Violation) returning an access type
(specifically Line, = access-to-string) from a function. Pass the access type as
an OUT parameter from a procedure, and it worked fine...

- Brian