Conditional Generates

I've a question with regards to conditional generates. I'm using a 'for
generate' to interconnect an array of signals. I'm then using the index
of this generate to set the connectivity of the array.

The following is an example to demonstrate the problem (A complete
example module is described below). It seems that 'Method One' should
work, as x-1 is only used when x>0. However, Modelsim complains about
the indexing being out of range. If, however, I use method Two,
everything is OK.

I'm guessing that 'Method One' is not legal/valid VHDL, but would like
to know for sure. Also, is 'method Two' the only available approach to
this problem? It seems far more prone to error, and in the real module
in which I need to do this, it would require a great deal more code.

I believe ModelSim is right here. The conditional signal assignment
works not only with constants but also with any expression as the
conditional, so "datavector(x-1)" is part of the overall expression;
I know that (x=0) is a constant expression, but that's an
optimisation issue. Effectively, one pass of your generate
loop gets re-written as

where "index_shuffle" is a function that takes the integer
value x and returns the modified index you want. Now all
the messy complexity can be pushed into the function.
What's more, you can avoid any compiler warnings
by declaring the function so that its return value is of
type "dataVector'range", so the body of the generate
statement cannot possibly have any out-of-range access.

On Tue, 13 Jun 2006 11:06:18 -0700, Mike Treseler
<> wrote:
>What is a possible upside to generating processes
>and wiring them up vs. using some array
>type and declaring some variables to be
>updated every clock in a single processs?
>
>So far, I have:
> 1. A generate could drive a tri-state pin interface.

And, in general, it's rather easier to control what
drivers you're creating when using generate.
Sometimes that matters. Most times, though,
there's an easier way around it. I'm not as
completely convinced as Mike of the virtues of
big single-process designs - I was brought up on
Occam and CSP, so my instinct is to decompose
a design into blocks that communicate in a
well-structured way - but for anything
algorithmic, software-like processes are IMHO
something that's worth striving for.
> 2. ?

My standard answer to that always used to be
"because generates allow you to describe variable-
sized structures, and allow you to declare the variable-
sized interconnects between the parts of those structures".
For Verilog, this would be completely true, I think. But
in VHDL we have the delights of dynamically-elaborated
subprograms - the variables in a function are manufactured
only when the function is called - and this does pretty
much everything you need for building funny-shaped
hardware: trees, jagged arrays and the like. Any
interconnect that gets unnecessarily declared will
in due course be optimised away by synthesis. So
my views on this are increasingly aligned with Mike's.

However, you may well be confronted with existing
design fragments that are structured as components
or processes, and you need to create groupings of
those things. In such a case, generate provides an
easy way out.
>The generate loop works and is very popular,
>but it is also very tedious on the edges
>and in the wiring.

Jonathan Bromley wrote:
> I was brought up on
> Occam and CSP, so my instinct is to decompose
> a design into blocks that communicate in a
> well-structured way -

You are ahead of your time.
At some high level, communication becomes
serial and very well-structured. It used
to be cross-country. Buses like
PCIe make it happen at a few centimeters.
I have no doubt this will become
a canned, on-chip "buffer" someday.
> but for anything
> algorithmic, software-like processes are IMHO
> something that's worth striving for.

That's a software-like thread
describing *parallel* hardware.
The point is to get the outputs
I really want without mentioning
every wire and mux involved.

A vhdl process is a fantastic virtual
machine with registers arranged
and updated however I like.
Synthesis maintains this illusion
by unwinding procedures, arrays, and loops
without complaint. Simulation lets me
take a test drive before actual
construction has even begun.
> However, you may well be confronted with existing
> design fragments that are structured as components
> or processes, and you need to create groupings of
> those things. In such a case, generate provides an
> easy way out.

That's a fine list item 2.
There is plenty of working code around
that I prefer to leave in the black box.

"Mike Treseler" <> wrote in message
news:...
> Andy wrote:
>
> What is a possible upside to generating processes
> and wiring them up vs. using some array
> type and declaring some variables to be
> updated every clock in a single processs?
>
> So far, I have:
>
> 1. A generate could drive a tri-state pin interface.
> 2. ?
>
This is pretty much along the same lines as Jonathon's earlier reply, but
generated processes would seem to fit in better when the 'other' things in
the architecture don't fit into that single clocked process model (i.e. the
'other' things being components that need to be instantiated and
combinatorial equations). One example that I've used several times is
needing a bank of fifos for some purpose. Overall control of that bank
tends to be in a clocked process but the actual read and write controls into
the fifos tend to be combinatorial since they tend to involve combinatorial
gating with the full/empty status bits out of the instantiated fifos.

So you end up needing combinatorial equations to connect the process to the
instantiated component so why not put all of that inside of the same single
generate block instead of putting a single process with a for loop and the
'other' stuff inside the still needed anyway generate block?

Then again, even your #1 item about tri-states is just another example of
something that doesn't fit into the clocked process model.

If the code for the architecture of the entity's required function does fit
nicely into the single clocked process model though I agree with you that it
is generally better to use the for loops inside the single
process...although I might tend to break them up into several basically
identical processes with loops, but that's just me.

On Tue, 13 Jun 2006 14:00:54 -0700, Mike Treseler
<> wrote:
>Jonathan Bromley wrote:
>
>> I was brought up on
>> Occam and CSP, so my instinct is to decompose
>> a design into blocks that communicate in a
>> well-structured way -
>
>You are ahead of your time.
>At some high level, communication becomes
>serial and very well-structured. It used
>to be cross-country. Buses like
>PCIe make it happen at a few centimeters.
>I have no doubt this will become
>a canned, on-chip "buffer" someday.

Someday? How about Transputer Links, vintage 1975?
Now that's an idea that was ahead of its time (and, in
fairness, ahead of the technological capabilities that
would have made it genuinely useful). Bromley's
First Law of Technology Business asserts that any
technology product is certain to fail in the marketplace
if it meets the following three criteria:

1) It is technically competent and founded on valid theory.
2) It is ahead of its time by more than 2 years.
3) It is British in origin.

SERDES I/Os on modern FPGAs do a nice job, but it
would be good if they had a handshaking protocol
layered on top of them so that you could use them
easily for synchronisation. I'm sure lots of people
do exactly that for themselves, already.
--
Jonathan Bromley, Consultant

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!