How to properly use hdl.RAM for Matlab to VHDL conversion?
3 Ansichten (letzte 30 Tage)
Ältere Kommentare anzeigen
Hello everyone,
I’m working on implementing a ROM memory using the hdl.RAM block inside a MATLAB function, which I plan to convert to VHDL. The RAM is properly inferred during the conversion, but the behavior of the fixed-point and VHDL versions doesn't match the original floating-point version.
I can't share the full function, but the code looks something like this:
Ref. [1] - Input Matalb function for VHDL code generation
function [...] = HDL_convertable_function(...)
% (...) Some code lines before ROM usage
[read_val_1, read_val_2] = ROM_MEMORY(index_1, index_2);
computed_value_1 = coder.hdl.pipeline(read_val_1 * (1-input_value_under_one), 1);
computed_value_2 = coder.hdl.pipeline(read_val_2 * input_value_under_one, 1);
% (...) Some code lines after ROM usage
end
Where 'ROM_MEMORY' function is defined as follows:
Ref. [2] - Floating-point implementation of ROM memory
function [data1, data2] = ROM_MEMORY(address1, address2)
persistent prn_rang_lut;
if isempty(prn_rang_lut)
prn_rang_lut = coder.load('prn_rang_lut.mat');
end
memory = prn_rang_lut.prn_rang_local;
% Access memory using given address
data1 = memory(address1);
data2 = memory(address2);
end
During fixed-point conversion Ref.[2] is replaced with:
Ref. [3] - Fixed-point implementation of ROM memory using hdl.RAM()
function [data1, data2] = ROM_MEMORY_fixpt(address1, address2)
prn_rang_lut = coder.load('prn_rang_lut.mat');
persistent ram1;
if isempty(ram1)
ram1 = hdl.RAM('RAMType', 'True dual port', 'RAMInitialValue', prn_rang_lut.prn_rang_local);
end
wrEnA = false;
wrEnB = false;
wrAddressA = fi(address1-1, 0, 19, 0);
wrAddressB = fi(address2-1, 0, 19, 0);
wrDataA = fi([1], 1, 8, 6);
wrDataB = fi([1], 1, 8, 6);
[rdDataOutA, rdDataOutB] = ram1(wrDataA, wrAddressA, wrEnA, wrDataB, wrAddressB, wrEnB);
data1 = rdDataOutA(1);
data2 = rdDataOutB(1);
end
The issue arises when running the testbench for HDL conversion: the outputs from the fixed-point model don’t match those of the floating-point version. After some investigation, I’ve found that Ref. [3] behaves differently from Ref. [2], as it introduces a delay in producing the data1 and data2 outputs. Specifically, each time Ref. [3] is called, the output values correspond to address1 and address2 from the previous function call, rather than the current one.
As a result, every time the fixed-point version of Ref. [1] is invoked, computed_value_1 and computed_value_2 are incorrect because they rely on read_val_1 and read_val_2 inputs from the previous call.
How can I address this behavior to ensure accurate comparison between the floating-point and fixed-point function versions for validation?
0 Kommentare
Antworten (1)
Kiran Kintali
am 6 Sep. 2024
HDL Coder generated code should match the fixed point code. I see you are using coder.hdl.pipeline which are pipeline delays and those will be balanced and testbench should start checking results after initial latency. You may be encountering a bug if this is not happening.
Can you please share the MALTAB Code in a file along with the testbench? Please share the project file or a runme file with coder.config settings and the codegen command used. This will help us reproduce the issue. What version of MATLAB are you using?
Do not hesitate to reach out to tech support as well for additional assistance and the issue getting routed to my team.
2 Kommentare
Jacob Mazur
am 9 Sep. 2024
Hi Ruben,
If you could create a support ticket, we'd be happy to take a look at the issue. The easiest ways to do so are either by emailing support@mathworks.com or by creating a new ticket here: https://www.mathworks.com/support/contact_us.html
Any code you share through that ticket will not be publicly accessible. Feel free to let me know if you encounter any issues!
Jacob
Siehe auch
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!