- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I created a OnChipMemory Component with s1 port connected to avalon memory mapped slave (dma +pcie). I changed the source code generated by SOBC to the one below (replaced original single port altsync with dual port one). I want to access to the memory data on the second altsyncram port. When i'm accessing data trough PCIExpress. After writing to address for e.g. 0x50 value 0x12345678 the read back value is 0x00000000, but reading from 0x54 gives 0x12345678. (The original altsync works perfect). Why does this happen? https://www.alteraforum.com/forum/attachment.php?attachmentid=6740
entity onchip_memory2_0 is
generic (
INIT_FILE : STRING := "onchip_memory2_0.hex"
);
port (
-- inputs:
signal address : IN STD_LOGIC_VECTOR (9 DOWNTO 0);
signal byteenable : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
signal chipselect : IN STD_LOGIC;
signal clk : IN STD_LOGIC;
signal clken : IN STD_LOGIC;
signal reset : IN STD_LOGIC;
signal write : IN STD_LOGIC;
signal writedata : IN STD_LOGIC_VECTOR (31 DOWNTO 0);
-- test outputs
signal red_leds_to_pcie : OUT STD_LOGIC_VECTOR (8 DOWNTO 0);
signal green_leds_to_pcie : OUT STD_LOGIC_VECTOR (8 DOWNTO 0);
signal left_hand_bus_to_pcie : OUT STD_LOGIC_VECTOR (18 DOWNTO 0);
signal right_hand_bus_to_pcie : OUT STD_LOGIC_VECTOR (17 DOWNTO 0);
-- outputs:
signal readdata : OUT STD_LOGIC_VECTOR (31 DOWNTO 0)
);
end entity onchip_memory2_0;
architecture europa of onchip_memory2_0 is
SIGNAL sub_wire0 : STD_LOGIC_VECTOR (31 DOWNTO 0);
SIGNAL sub_wire1 : STD_LOGIC_VECTOR (31 DOWNTO 0);
COMPONENT altsyncram
GENERIC (
address_reg_b : STRING;
byteena_reg_b : STRING;
byte_size : NATURAL;
clock_enable_input_a : STRING;
clock_enable_input_b : STRING;
clock_enable_output_a : STRING;
clock_enable_output_b : STRING;
indata_reg_b : STRING;
intended_device_family : STRING;
lpm_type : STRING;
numwords_a : NATURAL;
numwords_b : NATURAL;
operation_mode : STRING;
outdata_aclr_a : STRING;
outdata_aclr_b : STRING;
outdata_reg_a : STRING;
outdata_reg_b : STRING;
power_up_uninitialized : STRING;
read_during_write_mode_port_a : STRING;
read_during_write_mode_port_b : STRING;
widthad_a : NATURAL;
widthad_b : NATURAL;
width_a : NATURAL;
width_b : NATURAL;
width_byteena_a : NATURAL;
width_byteena_b : NATURAL;
wrcontrol_wraddress_reg_b : STRING
);
PORT (
byteena_a : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
clock0 : IN STD_LOGIC ;
clocken1 : IN STD_LOGIC ;
wren_a : IN STD_LOGIC ;
byteena_b : IN STD_LOGIC_VECTOR (3 DOWNTO 0);
clock1 : IN STD_LOGIC ;
q_a : OUT STD_LOGIC_VECTOR (31 DOWNTO 0);
wren_b : IN STD_LOGIC ;
address_a : IN STD_LOGIC_VECTOR (9 DOWNTO 0);
data_a : IN STD_LOGIC_VECTOR (31 DOWNTO 0);
q_b : OUT STD_LOGIC_VECTOR (31 DOWNTO 0);
address_b : IN STD_LOGIC_VECTOR (9 DOWNTO 0);
clocken0 : IN STD_LOGIC ;
data_b : IN STD_LOGIC_VECTOR (31 DOWNTO 0)
);
END COMPONENT;
signal internal_readdata : STD_LOGIC_VECTOR (31 DOWNTO 0);
signal internal_writedata : STD_LOGIC_VECTOR (31 DOWNTO 0);
signal internal_address : std_logic_vector (9 downto 0);
signal internal_byteen : std_logic_vector (3 downto 0);
signal wren : STD_LOGIC;
signal readdata_b : STD_LOGIC_VECTOR (31 DOWNTO 0);
signal writedata_b : STD_LOGIC_VECTOR (31 DOWNTO 0);
signal address_b : std_logic_vector (9 downto 0);
signal byteen_b : std_logic_vector (3 downto 0);
signal wren_b : STD_LOGIC;
signal clken_b : STD_LOGIC;
begin
wren <= (chipselect AND write) AND clken;
--s1, which is an e_avalon_slave
--s2, which is an e_avalon_slave
--vhdl renameroo for output signals
readdata <= internal_readdata;
green_leds_to_pcie <= "111010111";
internal_address <= address;
internal_writedata <= writedata;
internal_byteen <= byteenable;
altsyncram_component : altsyncram
GENERIC MAP (
address_reg_b => "CLOCK1",
byteena_reg_b => "CLOCK1",
byte_size => 8,
clock_enable_input_a => "NORMAL",
clock_enable_input_b => "NORMAL",
clock_enable_output_a => "BYPASS",
clock_enable_output_b => "BYPASS",
indata_reg_b => "CLOCK1",
intended_device_family => "Arria II GX",
lpm_type => "altsyncram",
numwords_a => 1024,
numwords_b => 1024,
operation_mode => "BIDIR_DUAL_PORT",
outdata_aclr_a => "NONE",
outdata_aclr_b => "NONE",
outdata_reg_a => "CLOCK0",
outdata_reg_b => "CLOCK1",
power_up_uninitialized => "FALSE",
read_during_write_mode_port_a => "NEW_DATA_NO_NBE_READ",
read_during_write_mode_port_b => "NEW_DATA_NO_NBE_READ",
widthad_a => 10,
widthad_b => 10,
width_a => 32,
width_b => 32,
width_byteena_a => 4,
width_byteena_b => 4,
wrcontrol_wraddress_reg_b => "CLOCK1"
)
PORT MAP (
byteena_a => byteenable,
clock0 => clk,
clocken0 => clken,
wren_a => wren,
address_a => address,
data_a => writedata,
q_a => internal_readdata,
address_b => address_b,
byteena_b => byteen_b,
data_b => writedata_b,
wren_b => wren_b,
clocken1 => clken_b,
clock1 => clk,
q_b => readdata_b
);
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If it isn't a silly question, why aren't you using the standard dual ported internal memory definition?
It can be worth looking at what the RTL viewer shows.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- If it isn't a silly question, why aren't you using the standard dual ported internal memory definition? It can be worth looking at what the RTL viewer shows. --- Quote End --- Meybe i don't now how to export port S2 to be available from vhdl? If it's possible, plese tell me how can i do it. When i created such a dual port memory, i got an error, that S2 must be connected to avalon, however i don't want that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
IIRC dwh recently posted a component that exposed the second memory interface as a conduit.
I also thought that the Avalon interface and the memory one were very similar. If you only have a single master-slave pair then almost all the logic for the avalon 'bus' will get deleted.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, You rembered correctly owh posted an example of such component in this post titled: Avalon -> Dual Port RAM -> custom hardware interface.
But i think i miss something, becouse it still doesn't work. I connected new component as an Avalon Slave, but when i'm trying to read/write data, all i see is 0xffffffff. I'e also tried to look into RTL, but i couldn't find anything strange. Both memories - working and fault one - looks, for me, the same.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page