Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

How to instantiate a submodule in Verilog

Status
Not open for further replies.

Pastel

Member level 3
Joined
Jun 30, 2019
Messages
55
Helped
2
Reputation
4
Reaction score
1
Trophy points
8
Activity points
969
Hello!

I'm using Quartus with Verilog. I have made a design that works, but as it becomes bigger everyday,
I have to start splitting it into modules.
Now I have been reading books about verilog and made some experiments, but unfortunately it never
compiles, there are always errors.

What I did is as follows:
1. The working code
I made a simplified version of my code which is a lot larger, but I guess you don't want to dig in large
sources. I have an external DAC, and I'm sending data (DA) which is latched. One clk: set data, next
clk: latch data. I have also a LED blinker which divides the frequency by 50000000 to get 1Hz and blink the LED.
This first code works fine.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
module Test190801(DA, clk, dac_clk, ledb, ledr);
    output reg[15:0]DA;     //  Output to a digital analog converter
    input clk;                  //  System clock (100 MHz)
    output reg dac_clk;     //  Half of system clock (50 MHz)
    output reg ledb, ledr;  //  Two leds
    reg[32:0] div;              //  One register to count clocks
    reg div_clk;                //  One very low frequency clock used to blink LED
    //  Initialisation
    initial begin
        DA <= 0;                    //  Set data to 0 (not crucial but cleaner)
        dac_clk <= 0;           //  Set dac clk to 1 so that the first action is load data
        ledb <= 1;              //  Illuminates blue led
        ledr <= 0;              //  Clear red led
        div <= 0;               //  Cloc divider. Set to N-1 to divide by N
        div_clk <= 0;           //  Signal that will be used to blink the red LED
    end
    //  Runtime
    always@(posedge clk) begin
        //  Take care of the low frequency of the LED
        div <= div+1;           //  Increment divider
        if(div == 49999999) begin   //  Reaching the 50 000 000 division to get 1 Hz for LED
            div <= 0;
            if(div_clk == 0) begin
                div_clk <= 1;
            end
            else begin
                div_clk <= 0;
            end
        end
        //  Put the sawtooth to the DAC
        if(dac_clk == 1) begin
            DA <= DA+1;         //  Increment data
            dac_clk <= 0;       //  Set latch to 0
        end
        else begin
            dac_clk <= 1;   //  Larch data to DAC
        end
    end
    //  Take the div_clk to perform the LED blinking
    always@(posedge div_clk) begin
        if(ledr == 0) begin
            ledr <= 1;
        end
        else begin
            ledr <= 0;
        end
    end
endmodule



2. The non-working code.
See hereafter. I wanted to make a clock divider module to simplify the top module.
I have read books and also found examples. So basically all what I have to do is
to instantiate a divider with what I want to divide (clk) and set the output to the signal
I want (div_clk).
Here are my questions:
1. Can anybody tell me what's wrong?
2. I have read some conflicting stories. Some people seem to instantiate like it would
be done in C, with the variable names, but some others instantiate with expressions like
.clk_in(clk). Could anybody explain the difference?
3. Could anybody tell me how to have a color syntax when I'm posting questions?
I tried code syntax="VERILOG" but it doesn't work.


Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
module Test190801(DA, clk, dac_clk, ledb, ledr);
    output reg[15:0]DA;     //  Output to a digital analog converter
    input clk;                  //  System clock (100 MHz)
    output reg dac_clk;     //  Half of system clock (50 MHz)
    output reg ledb, ledr;  //  Two leds
    reg[32:0] div;              //  One register to count clocks
    reg div_clk;                //  One very low frequency clock used to blink LED
    //  Initialisation
    initial begin
        DA <= 0;                    //  Set data to 0 (not crucial but cleaner)
        dac_clk <= 0;           //  Set dac clk to 1 so that the first action is load data
        ledb <= 1;              //  Lights blue led
        ledr <= 0;              //  Clear red led
        div <= 0;               //  Cloc divider. Set to N-1 to divide by N
        div_clk <= 0;           //  Signal that will be used to blink the red LED
    end
    //  Runtime
    Divider my_div(div_clk, clk);
    always@(posedge clk) begin
        //  Put the sawtooth to the DAC
        if(dac_clk == 1) begin
            DA <= DA+1;         //  Increment data
            dac_clk <= 0;       //  Set latch to 0
        end
        else begin
            dac_clk <= 1;       //  Latch data to DAC
        end
    end
    //  Take the div_clk to perform the LED blinking
    always@(posedge div_clk) begin
        if(ledr == 0) begin
            ledr <= 1;
        end
        else begin
            ledr <= 0;
        end
    end
endmodule
 
module Divider(clk_out, clk_in);
    output reg clk_out;
    input clk_in;
    reg[32:0] div;
    initial begin
        clk_out <= 0;
        div <= 0;
    end
    always@(posedge clk_in) begin
        div <= div+1;
        if(div == 49999999) begin
            div <= 0;
            if(clk_out == 0) begin
                clk_out <= 1;
            end
            else begin
                clk_out <= 0;
            end
        end 
    end
endmodule



Thanks for any hint.

Pastel
 
Last edited by a moderator:

Hello!

I'm using Quartus with Verilog. I have made a design that works, but as it becomes bigger everyday,
I have to start splitting it into modules.
Now I have been reading books about verilog and made some experiments, but unfortunately it never
compiles, there are always errors.

What I did is as follows:
1. The working code
I made a simplified version of my code which is a lot larger, but I guess you don't want to dig in large
sources. I have an external DAC, and I'm sending data (DA) which is latched. One clk: set data, next
clk: latch data. I have also a LED blinker which divides the frequency by 50000000 to get 1Hz and blink the LED.
This first code works fine.
Code:
module Test190801(DA, clk, dac_clk, ledb, ledr);
	output reg[15:0]DA;		//	Output to a digital analog converter
	input clk;					//	System clock (100 MHz)
	output reg dac_clk;		//	Half of system clock (50 MHz)
	output reg ledb, ledr;	//	Two leds
	reg[32:0] div;				//	One register to count clocks
	reg div_clk;				//	One very low frequency clock used to blink LED
	//	Initialisation
	initial begin
		DA <= 0;					//	Set data to 0 (not crucial but cleaner)
		dac_clk <= 0;			//	Set dac clk to 1 so that the first action is load data
		ledb <= 1;				//	Illuminates blue led
		ledr <= 0;				//	Clear red led
		div <= 0;				//	Cloc divider. Set to N-1 to divide by N
		div_clk <= 0;			//	Signal that will be used to blink the red LED
	end
	//	Runtime
	always@(posedge clk) begin
		//	Take care of the low frequency of the LED
		div <= div+1;			//	Increment divider
		if(div == 49999999) begin	//	Reaching the 50 000 000 division to get 1 Hz for LED
			div <= 0;
			if(div_clk == 0) begin
				div_clk <= 1;
			end
			else begin
				div_clk <= 0;
			end
		end
		//	Put the sawtooth to the DAC
		if(dac_clk == 1) begin
			DA <= DA+1;			//	Increment data
			dac_clk <= 0;		//	Set latch to 0
		end
		else begin
			dac_clk <= 1;	//	Larch data to DAC
		end
	end
	//	Take the div_clk to perform the LED blinking
	always@(posedge div_clk) begin
		if(ledr == 0) begin
			ledr <= 1;
		end
		else begin
			ledr <= 0;
		end
	end
endmodule

2. The non-working code.
See hereafter. I wanted to make a clock divider module to simplify the top module.
I have read books and also found examples. So basically all what I have to do is
to instantiate a divider with what I want to divide (clk) and set the output to the signal
I want (div_clk).
Here are my questions:
1. Can anybody tell me what's wrong?
2. I have read some conflicting stories. Some people seem to instantiate like it would
be done in C, with the variable names, but some others instantiate with expressions like
.clk_in(clk). Could anybody explain the difference?
3. Could anybody tell me how to have a color syntax when I'm posting questions?
I tried code syntax="VERILOG" but it doesn't work.

Code:
module Test190801(DA, clk, dac_clk, ledb, ledr);
	output reg[15:0]DA;		//	Output to a digital analog converter
	input clk;					//	System clock (100 MHz)
	output reg dac_clk;		//	Half of system clock (50 MHz)
	output reg ledb, ledr;	//	Two leds
	reg[32:0] div;				//	One register to count clocks
	reg div_clk;				//	One very low frequency clock used to blink LED
	//	Initialisation
	initial begin
		DA <= 0;					//	Set data to 0 (not crucial but cleaner)
		dac_clk <= 0;			//	Set dac clk to 1 so that the first action is load data
		ledb <= 1;				//	Lights blue led
		ledr <= 0;				//	Clear red led
		div <= 0;				//	Cloc divider. Set to N-1 to divide by N
		div_clk <= 0;			//	Signal that will be used to blink the red LED
	end
	//	Runtime
	Divider my_div(div_clk, clk);
	always@(posedge clk) begin
		//	Put the sawtooth to the DAC
		if(dac_clk == 1) begin
			DA <= DA+1;			//	Increment data
			dac_clk <= 0;		//	Set latch to 0
		end
		else begin
			dac_clk <= 1;		//	Latch data to DAC
		end
	end
	//	Take the div_clk to perform the LED blinking
	always@(posedge div_clk) begin
		if(ledr == 0) begin
			ledr <= 1;
		end
		else begin
			ledr <= 0;
		end
	end
endmodule

module Divider(clk_out, clk_in);
	output reg clk_out;
	input clk_in;
	reg[32:0] div;
	initial begin
		clk_out <= 0;
		div <= 0;
	end
	always@(posedge clk_in) begin
		div <= div+1;
		if(div == 49999999) begin
			div <= 0;
			if(clk_out == 0) begin
				clk_out <= 1;
			end
			else begin
				clk_out <= 0;
			end
		end	
	end
endmodule

Thanks for any hint.

Pastel


From my 10 second glance at the code, it looks like you are not breaking up the code into multiple files. different modules go into different files, that simple. keep the testbench stuff separated from the logic itself.
 

You didn't tell in which sense the second design is not working. How did you test it?

Although it's a bad practice to use clock dividers to generate clocks because it likely causes timing issues in real designs, it won't hinder basic function of the circuit. Having the whole design in a single file may be considered bad or not, but it's no technical problem.
 

The design doesn't compile because you used reg for div_clk and it is assigned an initial value in the initial block. The signal should be defined as a wire and not a reg (variable).

2. I have read some conflicting stories. Some people seem to instantiate like it would
be done in C, with the variable names, but some others instantiate with expressions like
.clk_in(clk). Could anybody explain the difference?
You see the difference, because most people are taught antiquated syntax in school from academics that never updated their skills. The only stuff you find online that is done with 2001 syntax and on is from experienced people who are probably working or are trainers and have a blog or website. Most sties are written by students and are useless for learning Verilog/Systemverilog, even many books use the pre-2001 syntax (see above about those academic types, some of whom write books).

Non-C like module ports are antiquated and are from pre-2001 Verilog use the C style it's less verbose.

Instantiations with named association (.clk_in(clk)) are preferable over positional association (clk). In positional order is important and can cause debug issues if you don't notice one of your signals is out of order. With named association the order of the ports has no bearing on the connectivity.

Don't use initial blocks in synthesizable code to set default values, use a reset. Initial blocks are not synthesizable across all technologies, only RAM based FPGAs like Altera and Xilinx have flip-flops that are loaded with defaults from initial blocks as the initial flip-flop contents are held in their bitstreams. ASICs and flash based devices will require a reset to ensure the initial values are loaded into the flip-flops.

Please use whitespace....
itshardtoreadrunon
textwithnowhitespace.
 

The design doesn't compile because you used reg for div_clk and it is assigned an initial value in the initial block. The signal should be defined as a wire and not a reg (variable).
Quartus has no problem with the design when selecting SystemVerilog settings for Verilog HDL.
 

Quartus has no problem with the design when selecting SystemVerilog settings for Verilog HDL.
Okay fine, so switching to Systemverilog masks the coding problem due to the changes to reg and wire in sv which reduces the Modelsim error to a warning about the multiple drivers between the intitial block assignment to div_clk and the module Divider clk_out output. Yeah it compiles, but it is confusing to write what looks like Verilog and then compile using Systemverilog to get around coding errors in Verilog. This doesn't teach anyone how to properly write code it teaches them how to hack a design.

Hack jobs like using an -sv switch to compensate for coding "errors" is why I have to regularly close my eyes when getting old code from our repository as it's usually filled with poorly written code with tool hacks that generates 100's of warnings during synthesis and relies on what amounts to a specific tool's behaviour on how it interprets some piece of ambiguous code with compilation warnings.
 

From my 10 second glance at the code, it looks like you are not breaking up the code into multiple files. different modules go into different files, that simple. keep the testbench stuff separated from the logic itself.

Don't agree.

I often find it preferable to leave multiple associated modules in a single file including the test-bench for that module.


And it certainly isn't the cause of the problems here.
 

Don't agree.

I often find it preferable to leave multiple associated modules in a single file including the test-bench for that module.


And it certainly isn't the cause of the problems here.

I have not seen that coding style in any of the companies I have worked for, taught for, or consulted for. Never allowed. My experience of 1, of course.
 

I have not seen that coding style in any of the companies I have worked for, taught for, or consulted for. Never allowed. My experience of 1, of course.
Never seen the multiple modules in the same file at over 10 companies with more than 50 different HDL coders. I've only done this a couple of times where the second module was a workaround for a VHDL/Systemverilog mixed language issue that was used if a parameter was set/not-set

So now it's the experience of 2 ;-)

Besides that, the code formatting window was added by a moderator, who probably didn't notice there there two modules in the code and didn't put each module in it's own formatting window. So it's likely the OP's code is in separate files anyway.
 

No. Just changed code tags to Verilog syntax tags...

- - - Updated - - -

You are talking about System Verilog and legacy Verilog as if they are different languages. The strict distinction between wire and reg in classical Verilog is a formalism with limited purpose, I think. Multiple driver is a different thing and would cause a synthesis error. But initial block is no strong driver, it can be easily overridden respectively ignored by the synthesis tool.

I agree of course that the initialization of div_clk is useless and should be deleted to clarify that the variable has an external driver. Also with your suggestion to use an explicit reset for the driver.
 

Hello!

Thanks for so many replies while I was sleeping!
I changed div_clk to wire, and it compiled at once. Thanks a lot!

I also changed the instantiation by using .clk_out(div_clk) and it doesn't change anything (I mean
it also compiles), so if it's better, then I'll stick to that notation. Thanks for the hint.

About initialization, you mean I should add a reset signal and an always@(posedge reset) block?
Something like this?:

Code:
always@(posedge reset) begin
    DA <= 0;                //  Set data to 0 (not crucial but cleaner)
    dac_clk <= 0;           //  Set dac clk to 1 so that the first action is load data
    ledb <= 1;              //  Lights blue led
    ledr <= 0;              //  Clear red led
    div <= 0;               //  Cloc divider. Set to N-1 to divide by N
end
NB: I appreciate for the syntax tag, but could you tell me how to do it myself?

Please use whitespace....
itshardtoreadrunon
textwithnowhitespace.

Where did I forget white spaces? On my browser, the words are properly separated by 1 space.
I don't see any specific place where 2 words are glued.

Thanka again!

Pastel
 

Never seen the multiple modules in the same file at over 10 companies with more than 50 different HDL coders. I've only done this a couple of times where the second module was a workaround for a VHDL/Systemverilog mixed language issue that was used if a parameter was set/not-set

So now it's the experience of 2 ;-)

I know I've seen this. I think some code generators will do this for convenience. I know I've seen people put short testbenches in the same file. I'm pretty accepting of that because the alternative is usually no tb other than a full system tb.
 

Never seen the multiple modules in the same file at over 10 companies with more than 50 different HDL coders. I've only done this a couple of times where the second module was a workaround for a VHDL/Systemverilog mixed language issue that was used if a parameter was set/not-set

So now it's the experience of 2 ;-)

Besides that, the code formatting window was added by a moderator, who probably didn't notice there there two modules in the code and didn't put each module in it's own formatting window. So it's likely the OP's code is in separate files anyway.

Yes its common thus worth me saying “It doesn’t have to be that way”.

The software world has the same debate about classes and I think the right answer is the same: it makes sense sometimes.

In one example I have 4 versions of a single pole IIR filter (signed, unsigned etc), all slim modules that wrap a 5th base module and a test bench that verifies all of them simultaneously. Having 6 files instead of one doesn’t make anyone’s life better in this case. In my opinion.
 

I also changed the instantiation by using .clk_out(div_clk) and it doesn't change anything (I mean
it also compiles), so if it's better, then I'll stick to that notation. Thanks for the hint.
Yes it's better just because there is no ambiguity on the connections and as you've written your code, one has to examine the port ordering to determine that clk_out in one file is div_clk in another.

About initialization, you mean I should add a reset signal and an always@(posedge reset) block?
Something like this?:

Code:
always@(posedge reset) begin
    DA <= 0;                //  Set data to 0 (not crucial but cleaner)
    dac_clk <= 0;           //  Set dac clk to 1 so that the first action is load data
    ledb <= 1;              //  Lights blue led
    ledr <= 0;              //  Clear red led
    div <= 0;               //  Cloc divider. Set to N-1 to divide by N
end
No you don't add another block that could result in multiple driver issues in Verilog and warnings about multiple drivers in SystemVerilog, besides that you will then be relying on the synthesis tool correctly interpreting your non-standard code.

To add a reset to a flip-flop description you write your synchronous code with the following structure

Code Verilog - [expand]
1
2
3
4
5
6
7
always @(posedge clk, posedge rst) begin
  if (rst) begin
    my_sig <= 1'b0;  // reset value
  else begin
    my_sig  <= din;  // code implements a D-FF with asynchronous reset
  end
end



NB: I appreciate for the syntax tag, but could you tell me how to do it myself?
PHP:
[syntax=verilog] ...your code goes here... [/syntax]


Where did I forget white spaces? On my browser, the words are properly separated by 1 space.
I don't see any specific place where 2 words are glued.
Not the space between words it is the lack of spaces between keywords, signals, and operators, i.e.

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
module x (clk,a,din,c)input clk;
input[7:0]a;
input[15:0]din;
output reg[7:0]c;
always@(posedge clk)begin
  if(a==8'h23)begin
    c<=din[11:4];
  else if(a==8'h44)begin
    c<=din[7:0];
  else
    c<=din[15:8];
  end
end
endmodule


Which I would use whitespace to make it easier to read at a glance

Code Verilog - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
module x (
  input           clk,    // using Verilog 2001 C-like syntax for ports
  input  [7:0]    a,      // this is less verbose and is easier to maintain
  input  [15:0]   din,    // also using whitespace to line up thing so it is
  output [7:0]    c       // much easier to read at a glance.
)
 
  // whitespace is added to make it easier to see the comparisons.
  always @(posedge clk) begin
    if (a == 8'h 23) begin
      c <= din[11:4];
    else if (a == 8'h 44) begin
      c <= din[7:0];
    else
      c <= din[15:8];
    end
  end
 
endmodule

Of course this simple example isn't the best to show the difference, but it's much easier to see the difference when the file has 100's of lines of code all compacted together with the minimum amount of white space (like they are attempting to conserving hard-drive space).
 

Hello!

Thanks for the explanation.
Ok for the formatting. I didn't know I could put comments in the middle of the definition.
In fact, doing that way does not take more space because the parameters' comments can
be written between the ()s, so I will do that.
Beside this, I'm not fan of having empty lines everywhere. If you don't need a comment,
then you don't need a white line, and the opposite, if you need a white line for separation,
then you need a comment.
I'm used to write very compact code in C++ in order to keep one function in one page.

Ok, not I have further question. The other day somebody told me how to initialize an array
at once by using readmemhex or something like that and it works great.
Now there is something I don't understand. The FPGA I'm using is one of the biggest
in the MAX10 series, and it features a memory of 1MBit, therefore 128k.

For my generator, I'm using a data array. At first I have set a 1024 samples (2kbytes)
which was already very tedious to setup by hand (1024 lines of sine = xxxxx;
Now the problem is solved, and I wanted to test with a larger array just to check the effect
on the SN ratio. I have generated a sine file and I'm trying to read it with readmemhex.
But at 8k, it complains that there are not enough logic units, or something like that.
Is there a simple way to fit it in the RAM which is large enough?
The next step will be to store only 1/4 of the array and make a module to use the symmetry.

Thanks for any hint!

Pastel
 

Hello!

Thanks for the explanation.
Ok for the formatting. I didn't know I could put comments in the middle of the definition.
In fact, doing that way does not take more space because the parameters' comments can
be written between the ()s, so I will do that.
Beside this, I'm not fan of having empty lines everywhere. If you don't need a comment,
then you don't need a white line, and the opposite, if you need a white line for separation,
then you need a comment.
Then we will just have agree to disagree
If code is formatted with separations in between portions of code I can read through the code in seconds as I scroll at through the code with <ctrl-d> (vim), but with code all compacted like you like to write I have to slow down significantly to determine where each block of statements actually ends and starts. All my coding rules are direct result of maintaining large amounts of code and making the job less work for the next person using that code.

I'm used to write very compact code in C++ in order to keep one function in one page.
Being able to scan through unfamiliar code quickly is much more important to me than the aesthetics of keeping everything super compact so it fits on one page. Do you seriously print code out on paper? I've only printed stuff out when we had reviews and the other engineers wanted hard copies to mark up. Otherwise I only use a monitor and the monitors I use allow me to have 90 lines when horizontal and 150 line when vertical. I normally split the text window vertically so I can effectively look at 180 lines in the same file.

Ok, not I have further question. The other day somebody told me how to initialize an array
at once by using readmemhex or something like that and it works great.
Now there is something I don't understand. The FPGA I'm using is one of the biggest
in the MAX10 series, and it features a memory of 1MBit, therefore 128k.

For my generator, I'm using a data array. At first I have set a 1024 samples (2kbytes)
which was already very tedious to setup by hand (1024 lines of sine = xxxxx;
Now the problem is solved, and I wanted to test with a larger array just to check the effect
on the SN ratio. I have generated a sine file and I'm trying to read it with readmemhex.
But at 8k, it complains that there are not enough logic units, or something like that.
Is there a simple way to fit it in the RAM which is large enough?
The next step will be to store only 1/4 of the array and make a module to use the symmetry.

Thanks for any hint!

Pastel


Without code, memory file, error/warnings from tools (preferably the entire synthesis report) it is impossible to make guesses as to what is wrong. Descriptions like "it complains that there are not enough logic units, or something like that." are not helpful, give the exact error message.
 

But at 8k, it complains that there are not enough logic units, or something like that.
Is there a simple way to fit it in the RAM which is large enough?
Looks like the sine table is implemented in logic instead of block ram. I guess, you are using a MAX10xxSC or DC (compact) type, it has no RAM initialization feature and thus can't implement ROM. If you get the error with other MAX10 types, there's probably a problem in your code that prevents ROM inference.
 

I'm used to write very compact code in C++ in order to keep one function in one page.
I test different code styles. There is a style that uses tasks/functions to make complex code shorter. I had mixed results -- the code intent was clear but the tasks had to be written in a specific way to avoid accidents. It was a good argument for and against using tasks.

If code is formatted with separations in between portions of code I can read through the code in seconds as I scroll
Have you considered rigorously applying marker based code folding? When substantially all of the code is in folds the file opens in a "table of contents" view. It's amazing if you commit to rigorous application of MBCF. If you half-commit you lose the benefits quickly.
 

Have you considered rigorously applying marker based code folding? When substantially all of the code is in folds the file opens in a "table of contents" view. It's amazing if you commit to rigorous application of MBCF. If you half-commit you lose the benefits quickly.

Works great if you are the one writing the code. The problem is in most places you are using code that other people wrote and most of it is poorly commented, poorly formatted, poorly documented, poorly verified, etc. So there is no benefit with using MBCF on your modifications or additions to the code.

All I want is consistency and some amount of whitespace so I can quickly scan and not have to examine code to see the sections.

I once ran across code that had no whitespace, no comments, and had a combination of 2, 3, 4, and 8 character indenting using a mixture of tabs and spaces.
 

Hello!

Thanks for your reply.

there's probably a problem in your code that prevents ROM inference.

Not necessarily a problem with my code (it works) but a problem in the way I declare the array
and on the way I initialize it. When it compiles (i.e. when the array is, say, 2k samples or 4k
bytes), I noticed that the RAM bits usage is 0%, but 32kbit should be close to 3% of the 1Mbit
of the chip, so there must be an instruction of some kind that writes these bits in the RAM
and not using logic elements.
For example with a microcontroller, you can write some data in flash (or in FRAM for MSP430
based CPUs for example), but if you declare one variable, it will be in RAM, not in FRAM, so you
have to write it to the FRAM on purpose.

Without code, memory file, error/warnings from tools

I don't think it's necessary. It boils down to "how do I write data in RAM on MAX10".
The ideal case would be some kind of hint (like the other day with the way to read data and
put it into an array, with the function $readmemhex that I didn't know).
I have seached on the net, and got for instance this document.

It's certainly interesting if you want to understand every bit of the memory, but what I need
is completely differnt. I would need one verilog module or part of it, explaining how I write
my array into RAM, and then at runtine, how to read this data back and set it to the GPIO.

When you start learning C, you can try to read the whole Kernighan & Richie before doing
anything, or you can try to write printf("Hello!\n");
And I'm very much in favor of the printf method when it comes to learning programming.
K&R comes later when you have specificproblems. To me, the link above is a kind of K&R
reference, which is way to complicated for beginners like me at this point.

So to summarize: can anybody explain me how to use MAX10 memory bits, access in both
directions, read & write?

Pastel
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top