VHDL: assignment to two different fields of the record in two different processes
wzab
ports connecting different blocks (to be synthesized in the same FPGA) as a
record.
It resulted in a code, in which two different processes (each in one of
connected blocks) assign values to the different fields of the same record.
Unfortunately my VHDL simulator (namely: GHDL) recognizes this situation
as the conflict, and sets the whole record to 'U'.
Have I really overlooked something in the VHDL rules?
It seems, that it should not be considered a conflict, as each field is driven
by a single process.
--
TIA
WZab
wzab
http://www.velocityreviews.com/forums/t487026-vhdl-port-inout-problem.html
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".
This solution works, however I'm afraid that setting a signal to 'Z' in any
place instead of ports of top entity may confuse the synthesis tools...
Does any of you have any experiences with such a problem?
--
TIA
WZab
Eric Smith
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
maurizio.tranchero
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
KJ
> To simplify design of the DSP system I have decided to describe the
> ports connecting different blocks (to be synthesized in the same FPGA) as a
> record.
> It resulted in a code, in which two different processes (each in one of
> connected blocks) assign values to the different fields of the same record.
> Unfortunately my VHDL simulator (namely: GHDL) recognizes this situation
> as the conflict, and sets the whole record to 'U'.
>
What exactly is connected to the ports? The entire record or the
particular element of the record? If it's the entire record, like
this...
u1 : entity work.my_thing1 port map(s => my_record);
u2 : entity work.my_thing2 port map(v => my_record);
Then you will have problems because (as you've begun to discover based
on your later post) you will have multiple processes driving the
'my_record' signal. It doesn't matter that the entity only has one
obvious statement that is driving one element of the record.
> Have I really overlooked something in the VHDL rules?
The fact is that the two entities are defined to have an output that
is of the record type. That you choose to not have anything in the
architecture for that entity to drive the other elements of the record
means that those other elements gets the VHDL default assignment of
'U'.
> It seems, that it should not be considered a conflict, as each field is driven
> by a single process.
The output of the entity in your case is not an element of the record,
but the record itself.
Kevin Jennings
KJ
> 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
KJ
> 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
Eric Smith
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".