-------------------------- glue logic for address decoder and datamem -----------------
s_dmem_i(0).ena_i s_dmem_sel_o '0');
s_dmem_ena_o -------------------------------------------------------------------------------------------
sram_4en0 : sram_4en -- datamemory
port MAP
(

dat_o =>s_dmem_i(0).dat_i,---- connect to address_decoder
dat_i =>s_dmem_o(0).dat_o,
adr_i => s_dmem_o(0).adr_o,
wre_i => s_dmem_sel_o,
ena_i => s_dmem_ena_o, --connect up to address_decoder logic
clk_i =>wb_i.clk_i
);

Regards tribbiani!

I am sorry OpenCores does not accept my txt and removing parts.

tribbiani

Hi tribbiani,

Ok, so you are using your custom design and ISE v14.7.

Regarding ISE - I have no experiance with MB-Lite and ISE after ver10 (ISE-ver like in original MB-Lite project). And what is you target FPGA ? Is it possible to switch to Vivado with your FPGA?

Regrading your custom design -> your log-information not really formatted, so I have no clear understanding of the situation.
In global, I would recommend you start with simulation first.
Also, I think, you must start with HDL-based BRAM instantiation - in this case you will have clearance if something goes wrong during synth-phase of MEM-logic.

=> So, to avoid future problems - you must start with very simple System-On-Chip architecture, something like this:
0) Processor-Unit,
1) Instruction-Mem,
2) Data-mem,
3) GPIO like a peripheral.
After you will be done with proper test-env, synth+PAR and HW-tests of this design you can start with more complex designs.
Like a ref-point you can use my "vmblite_base" design. I think, after you will have something like a ref-point for your simple design I can take a look, if you will find proper place for project archive.

Hi kuzmi4! Thank you for support.
Will consider to change memory from core-generated to inference(HDL).


HDL compiler warnings are:

std_pkg.vhd Line 260 Range is emty(null range)

std_pkg.vhd Line 260 Assignment ignored.

wb_i_int_i is never used.

Node Mmult_n04243 of sequential type is unconnected in block execute.

Best regards tribbiani!

Hi tribbiani,

Regarding {std_pkg.vhd Line 260} - I think this warning related to function "increment" in std_Pkg. Actually, this function used in entity "fetch":

So, this item also brought "+1" to design simulation ;)

Regarding {wb_i_int_i is never used} - you must verify your connection to this port in System-On-Chip: do you have some "real" signal for this port of MB-Lite (or you simply left it unconnected)?

Regarding {Mmult_n04243} - it looks like typical name from ISE synth-tool. You must verify you synth-log/RTL-view to determine reason for this warning.

Hi kuzmi4!
Only clk signal and output for data to be measured on oscilloscope is defined in UCF-file.
wb_i_int_i signal is defined in top entity and visible in RTL-view, there is no logic driving this signal. As for now there are no IP-Modules connected to MB-Lite top entity in/out signals. Verifying in System-On-Chip do you mean in the UCF-file? Was thinking maybe wb_i_int_i needs a initial value:)

Did look into fetch module and from what I was explained the two MSB of Madd_r_program_counter is connected to ground. The rest of the vector is used.

Regarding {std_pkg.vhd Line 260} used in fetch interesting. The increment are &00 concatenated should give 4, as in 4 bytes increment for program-counter. Did it only increment by 1 in your simulation?

The s_dmem_i(0)_ena_i signal input on address decoder is static high in VHDL description.

Take a look at m_dmem_o_dat_o and m_dmem_o_sel_o from core to address decoder. The signals are not connected inside address-decoder in either mblite_unit and in my design?


##Clock signal
Net "wb_i_clk_i" LOC=V10 | IOSTANDARD=LVCMOS33;
Net "wb_i_clk_i" TNM_NET = sys_clk_pin;
TIMESPEC TS_sys_clk_pin = PERIOD sys_clk_pin 10000 kHz;

Best regards tribbiani!

Hi tribbiani,

{Verifying in System-On-Chip} in your case means inspection of your architecture with RTL-viewer and synth-log information. Now UCF is out of the scope.

Regarding "program-counter" in my sim -> it is 16bit wide and behaves like expected from the VHDL code , min incr-value == 4, something like this: 16'h0450, 16'h0454, 16'h0458, ...

Regarding "s_dmem_i(0)_ena_i" situation - I already provided information in my post above.

Regarding "m_dmem_o_dat_o" signal - source of this signal you can find in "../core/mem.vhd" file, under the line:

And these signals simply routed in "../core/core_address_decoder.vhd" file under the "CON" generate-block. Behavior of the {dmem_o}-signals in my test-env looks OK (like expected from the VHDL sources).