Resolve function doesn't work

[erw kltrkea]

I've been trying a simple resolve function of open collector outputs.
There are no syntax errors normally, and output waveform looks ok, but
if try to connect together two signals or outputs, I'll get an error
message saying "Nonresolved signal 'cc' has multiple sources."

I am using Modelsim PE ide.

Any help?

Here is declaration of resolve function and stuff.

PACKAGE oc IS
TYPE ocbit IS ( '0', 'Z', 'H' );
TYPE ocbit_vector IS ARRAY (natural RANGE <>) OF ocbit;
FUNCTION resold ( v: i2c_bit_vector ) RETURN ocbit;
SUBTYPE ocbit_resolved IS resold ocbit;
END oc;

And this is now in testbench. It is the same where ever I put it.

 

[kennheinrich]

I've been trying a simple resolve function of open collector outputs.
There are no syntax errors normally, and output waveform looks ok, but
if try to connect together two signals or outputs, I'll get an error
message saying "Nonresolved signal 'cc' has multiple sources."

I am using Modelsim PE ide.

Any help?

Here is declaration of resolve function and stuff.

PACKAGE oc IS
TYPE ocbit IS ( '0', 'Z', 'H' );
TYPE ocbit_vector IS ARRAY (natural RANGE <>) OF ocbit;
FUNCTION resold ( v: i2c_bit_vector ) RETURN ocbit;
SUBTYPE ocbit_resolved IS resold ocbit;
END oc;

And this is now in testbench. It is the same where ever I put it.

A valid resolution function for a type t has to take an array of type
t and return a value of type t. Your "resold" doesn't seem to follow
that pattern. Try making it take an array of ocbit instead.

FUNCTION resold ( v: i2c_bit_vector ) RETURN ocbit;

- Kenn

 

[erw kltrkea]

A valid resolution function for a type t has to take an array of type
t and return a value of type t. Your "resold" doesn't seem to follow
that pattern. Try making it take an array of ocbit instead.


- Kenn

My copy/paste mistake, it should indeed be array of ocbits. Here is the
rest of the function.



PACKAGE BODY oc IS

type ocbit_logic_table is array (ocbit, ocbit) of ocbit;
constant resolution_table: ocbit_logic_table := (
-- ---------------------------------------------------------
-- | 0 Z H - | |
-- ---------------------------------------------------------
( '0', '0', '0' ), -- | 0 |
( '0', 'Z', 'H' ), -- | Z |
( '0', 'H', 'H' ) -- | H |
);

function resold (v: ocbit_vector) return ocbit is
variable result: ocbit := 'Z';
begin
if (v'length) = 1 then
return v(v'low);
else
for i in v'range loop
result := resolution_table(result, v(i));
end loop;
end if;
return result;
end resold;

This is my latest test:

library ieee;
use ieee.std_logic_1164.ALL;
use work.oc.all;
use work.all;

entity testm is
port (
aa,bb : in ocbit;
oout : out ocbit
);
end testm;

architecture mainn of testm is
signal sisoa,sisob : ocbit;
begin
hhhh: entity testr port map (inpa=>aa, outa=>sisoa);
gggg: entity testr port map (inpa=>bb, outa=>sisob);
oout<=sisoa; --short
oout<=sisob; --short
end mainn;


Rest is probably easy to quess. There is an other file with input
connected to output. I changed the short signal a bit. And a testbench.
Should be easy, but isn't.

Leif

 

[erw kltrkea]

I've been trying a simple resolve function of open collector outputs. [...]
message saying "Nonresolved signal 'cc' has multiple sources."

PACKAGE oc IS
TYPE ocbit IS ( '0', 'Z', 'H' );
TYPE ocbit_vector IS ARRAY (natural RANGE <>) OF ocbit;
FUNCTION resold ( v: ocbit_vector ) RETURN ocbit;
SUBTYPE ocbit_resolved IS resold ocbit;
END oc; [...]
signal inpa, inpb, cc : ocbit; [...]
cc<=outa;
cc<=outb;

Oops. cc should be declared as ocbit_resolved.
The other signals can still be ocbit if you prefer.
You can't expect to get your resolution function
unless you use the resolved subtype!

You will have trouble with this in synthesis;
most synth tools don't understand custom resolution
functions. In practice it's probably better (though
obviously less elegant) to make use of std_logic
to get your open-collector behaviour; just create
an open-collector/drain driver structure thus:

oc_sig <= 'H' when to_X01(drive) = '1' else '0';
--
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
(e-mail address removed)
http://www.MYCOMPANY.com

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

Oops. cc should be declared as ocbit_resolved.

That helped, it works now. Modelsim seems to be happy with this but I
havn't tried to synthesise this. I wonder, I thought that ocbit was to
be the resolved type. SUBTYPE ocbit_resolved IS resold ocbit; was just a
line copied from an other source. When nothing worked. Type name
*_resolved is a clue though. Is it possible to get "ocbit" as a resolved
type here. Or is it so that starting type ocbit and resolved type must
be different.

An other issue is, that it would probably be better to not use ocbit as
internal type here, and use it only for outputs.

oc_sig <= 'H' when to_X01(drive) = '1' else '0';

This is good to know.

Thanks for help and happy new year
Leif

 

[erw kltrkea]

Errrm, yes, it would, since that makes the code
correct whereas it wasn't before. I suppose
that counts as "helped".


Read my post again: almost every synth tool will either
choke on, or ignore, your custom resolution function.
Go back to using std_logic even if it's less pretty.


You were wrong, I'm afraid. You can't declare a
resolved TYPE, but only a resolved SUBTYPE of
another existing type. The original type remains
unresolved. Just like std_ulogic, which is the base
type for the resolved subtype std_logic.
--

Good to know

Another thing, I noticed that there is some wrong values in the output.
So if someone in spite of all warnings will use that code, you will get
"my bugs" as well.