Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Valued Contributor III
753 Views

Problem with resolving signals in vhdl

Hey guys! 

 

I'm dealing with an annoying vhdl problem. I've made a couple of blocks that communicate with each other and now I'm writing a testbench for them. One of the modules is a ram module and I want to initialize it with some data for the rest of the blocks to work on. I am getting the problem that the memory address has mutiple sources. (Actually I am getting an error in modelsim: "Nonresolved signal 'addr_1' has multiple sources.") This makes sense since I am trying to interact with the port from the testbench (I am reading from a file and storing it in the memory) and afterwards I will operate on the data from another module. I thought this would work since I am assigning the port at different points in time, but thats not the case. Whats the general way of dealing with this problem, w/o changing your whole code around.After all its a testbench, it should be able to operate with minimum interference. I thought of two ideas, neither of which sound very appealing: 

 

1) Renaming the respective signals from the two sources, and assigning them in a third process. Which gets very ugly, very quick. 

 

2) The addr_1 is actually an integer (and is therefore not resolved??, compared to other std_logic signals that I do the same with, and dont give problems). So I could try to write a resolution function for the integers, but im not sure its going to work as i am trying to actually resolve the sources and not the values from those sources. (The std_logic signals might also give problems that way).  

 

 

Here is the signal im talking about: 

signal addr_1: integer range 0 to addr_width; 

 

How do I go about this? 

Thanks for your time!
0 Kudos
6 Replies
Highlighted
Valued Contributor III
9 Views

two options: 

1) decide the driver logically (applies to synthesis or testbench) 

2) decide the driver based on time sequence using wait statements (applies to testbench only) 

The target signal should not be driven otherwise by some fixed driver somewhere else by direct assignment or being portmapped 

by the way you can use mif file to initialise the ram if that helps.
0 Kudos
Highlighted
Valued Contributor III
9 Views

Is you DUT the ram? or is the DUT something else? If the DUT is not the ram, why not create a ram model that allows some other mechanism to initialise the ram contents, so you can just let the DUT have exclusive interface to the address interface? 

 

Otherwise, what kind of ram is it? if it has integers as the addr interface, It must be a custom one of your own?  

 

There are many solutions to this problem, but it really depends on the architecture. 

Post some code/examples and maybe we can help in more detail.
0 Kudos
Highlighted
Valued Contributor III
9 Views

 

--- Quote Start ---  

two options: 

1) decide the driver logically (applies to synthesis or testbench) 

2) decide the driver based on time sequence using wait statements (applies to testbench only) 

The target signal should not be driven otherwise by some fixed driver somewhere else by direct assignment or being portmapped 

by the way you can use mif file to initialise the ram if that helps. 

--- Quote End ---  

 

 

Thanks for your help! Is there no way to resolve the sources instead of the values? How does one make a centralised memory that is operated on by multiple entities?
0 Kudos
Highlighted
Valued Contributor III
9 Views

 

--- Quote Start ---  

Is you DUT the ram? or is the DUT something else? If the DUT is not the ram, why not create a ram model that allows some other mechanism to initialise the ram contents, so you can just let the DUT have exclusive interface to the address interface? 

 

Otherwise, what kind of ram is it? if it has integers as the addr interface, It must be a custom one of your own?  

 

There are many solutions to this problem, but it really depends on the architecture. 

Post some code/examples and maybe we can help in more detail. 

--- Quote End ---  

 

Thanks for your help! 

The DUT consists of two modules a ram module and a discrete wavelet transform module, I want to test both and therefore I need to input the data into the RAM first. Yh it is a custom 2port ram, that can read while writing. Initializing the ram contents is a good idea, but I intend to add more modules that all operate on the same memory so that doesnt really solve my problem 

 

entity true_dual_port_ram_single_clock is 

generic 

DATA_WIDTH : natural := 8; 

ADDR_WIDTH : natural := 262144 

); 

port 

clk : in std_logic; 

addr_a: in natural range 0 to ADDR_WIDTH- 1; 

addr_b: in natural range 0 to ADDR_WIDTH- 1; 

data_a: in std_logic_vector((DATA_WIDTH-1) downto 0); 

data_b: in std_logic_vector((DATA_WIDTH-1) downto 0); 

we_a: in std_logic := '1'; 

we_b: in std_logic := '1'; 

q_a : out std_logic_vector((DATA_WIDTH -1) downto 0); 

q_b : out std_logic_vector((DATA_WIDTH -1) downto 0) 

); 

end true_dual_port_ram_single_clock;
0 Kudos
Highlighted
Valued Contributor III
9 Views

Then in that case, with multiple sources, you'll have to build an arbiter that only grants access to the ram one module at a time. Only 1 device can have access to the ram on any given clock cycle. Connecting them all to the addr_a port is just impossible, regardless of the type of addr_a (while a resolved type like std_logic_vector would work in simulation, it would not synthesise as FPGAs do not have internal tri-states).

0 Kudos
Highlighted
Valued Contributor III
9 Views

I figured it out, I just have to make a mux that handles this stuff.

0 Kudos