From: Eric Smith on
As enticing as it is, I've found that using record types in
synthesizable VHDL is just inviting problems. I certainly wouldn't do
it if I needed separate processes to drive different elements of the
record.

Avoiding 'Z' except for actual tri-state hardware (e.g., IOB pins on
FPGAs) is a good idea. The synthesizers can often deal with Z OK, but
I prefer to keep my designs closer to what the hardware can actually
implement, rather than counting on the cleverness of the synthesizer.
(Obviously I still do count on the cleverness of the synthesizer; I
just try not to do it more than necessary.)

Eric
From: maurizio.tranchero on
Hallo,
Have you tried to create an interface process with two different input
interfaces
and one output interface, devoted to acquire data from the two writing
processes
and to merge them into the record you need?
I didn't check if this can work, but it should.

Ciao,
Maurizio

From: KJ on
On Dec 26, 3:28 am, Eric Smith <space...(a)gmail.com> wrote:
> As enticing as it is, I've found that using record types in
> synthesizable VHDL is just inviting problems.  

Not using records, just invites other problems...like when bit fields
definitions change. A record allows this change to be handled
completely in one file, three locations in that file: in the record
definition and within two functions. Not using a record involves
finding and changing every instance where the (could've been) record
is used, which is generally in far more places in the code and not
always as easy to find. Plus to find them, you need to rely on text
search tools rather than the VHDL compiler. Far more likely to miss
an usage instance in that case, thus the problem

Kevin Jennings
From: KJ on
On Dec 25, 5:50 pm, wzab <w...(a)ise.pw.edu.pl> wrote:
> I have found the following discussion:http://www.velocityreviews.com/forums/t487026-vhdl-port-inout-problem...
>
> And according to the solution decribed there, I set ALL fields (elements)  
> of the record in ALL processes. If the particular process does not drive
> the particular signal, I set it to "Z".
>

Step back a minute and think about why you would have an entity that
is defined to have a record output that does not drive all the
elements? Doesn't that seem to you like the entity *really* does not
have the record output that you've defined? (Hint: The answer is
'yes').

What this suggests is that you've defined the record per some pre-
conceived notion of how it should be, but it does not match how you're
defining your entities. You should go back to the drawing board and
re-think the record definitions to match how you really intend to use
them. The alternative is the kludge you've found regarding setting
unused record fields to 'Z'.

Kevin Jennings
From: Eric Smith on
It's easier for me to manage keeping my definitions consistent,
because I have direct control over that, than to deal with how
multiple synthesis tools deal with records. If all the tools did a
good job of dealing with records, I'd be happy to use them, but
several of the tools have problems, and the tool vendors' answer when
one runs into these problems is just like the doctor's reply to "it
hurts when I do this".