VHDL exercise : 256Bytes RAM

Status
Not open for further replies.

Morell

Member level 1
Joined
Dec 1, 2015
Messages
35
Helped
0
Reputation
0
Reaction score
0
Trophy points
6
Activity points
614
Hi everybody
I want to design a 256x8 Memory (RAM) and this is my code:

Code VHDL - [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

entity RAM_256Bytes is
    Port ( CLK : in  STD_LOGIC;
           R_W : in  STD_LOGIC; -- 1 means READ, 0 means WRITE
           Address : in  STD_LOGIC_VECTOR (7 downto 0);
           Din : in  STD_LOGIC_VECTOR (7 downto 0);
           Dout : out  STD_LOGIC_VECTOR (7 downto 0));
end RAM_256Bytes;
 
architecture Behavioral of RAM_256Bytes is
 
--Defining a 2D signal as a type for RAM
type RAM_256x8 is array (0 to 255) of std_logic_vector(7 downto 0);
--Creating a 2D signal as RAM
signal RAM: RAM_256x8;
 
begin
Read_Process: Process (CLK,R_W)
begin
if rising_edge (CLK) then
        if  R_W= '1' then -- Reading has higher priority
            Dout <= RAM(conv_integer(Address));
        elsif R_W = '0' then 
            RAM (conv_integer(Address)) <= Din;
        end if;
end if;
end process;
 
end Behavioral;


I think it is correct but I'm not a pro in VHDL.
Pleas comment "CORRECT" if you think it is correct.
Any comments or suggestion would be appreciated.

Tnx alot
 

Did you consider a way to reset the RAM? How about initializing the signal RAM to all zeros? It is not mandatory to do that. The code looks alright.
 
Reactions: Morell

    Morell

    Points: 2
    Helpful Answer Positive Rating
WOW!!!!!
Thanks alot!!!
I will consider a way to reset the RAM

- - - Updated - - -

@Matrixofdynamism
I'm Trying to reset the RAM, But I don't know how to
reset a 2D signal!!!
Is there command for this type of operation?
 

Functionally, it is correct as it is for a ram with a R_W input signal. Did you consider the design against vendors RAM blocks? what signals do they implement? what code style/templates to they recommend?
Reset is not possible in a ram on FPGAs, so do not even investigate it. You can initialise the ram, simply like this:

signal RAM: RAM_256x8 := (others => (others =>'0'));

As for comments on code style:
1. You're using non-standard VHDL. conv_integer is part of the non-standard std_logic_unsigned library. You should be using numeric_std instead.
2. Why are you writing your own ram? why not just infer the ram inline in your own code, rather than have it's own entity?
3. Have you investigated recommended code styles. Usually for FPGAs they use separate read and write enables.
 
The most important part is to make something useful. Look at you tool vendor's guide for RAMs, as well as if you have a preference between distributed RAM or block RAM. 256 is just at the limit for xilinx devices -- 1 slice can create a 256b RAM however the tools will use BRAM if they are available.



Also, numeric_std is a terrible standard. If you manage to time travel 2 decades into the past, use numeric_std. otherwise, use whatever you want. IMO, numeric_std is basically monkeys on a ladder.
 
Reactions: Morell

    Morell

    Points: 2
    Helpful Answer Positive Rating
I think R_W is unnecessary within the sensibility list since changes only occurs when rising edge of clk.
 
Last edited:

vGoodtimes said:
Also, numeric_std is a terrible standard. If you manage to time travel 2 decades into the past, use numeric_std. otherwise, use whatever you want. IMO, numeric_std is basically monkeys on a ladder.
Click to expand...

So are you suggesting that everyone should use the Synopsys non-IEEE standard std_logic_arith, std_logic_unsigned, and std_logic_signed packages? (and amazingly someone gave it a helpful point)

Please clarify why everyone should not use the numeric_std package, I'd really like to know why you consider that package is basically monkeys on a ladder.
 


This is exactly why. Numeric_std vs _anything_ is never done based on technical merits. It is always done based on some tribal knowledge passed down through generations of VHDL developers.

I consider numeric_std, as written, terrible because it so heavily favors academic correctness over convenience AND is advocated as the ONLY solution. Specifically, "+" and "-" don't exist for std_logic_vectors despite being the same operation in both cases. There is no single function for converting std_logic_vector to natural for indexing -- another common task. These concepts both exist in Verilog, so I feel like the world wouldn't end if VHDL had them.
 

I know a lot of people who LOVE VHDL (personally I dislike it) and have told me that the use of std_logic_vector for numbers is really wrong because it wasn't meant to be used for numbers but is instead a container of bits. If you need to eventually split up a std_logic_vector into different fields where some are used as numbers you should have used a record.

One engineer I know exclusively uses natural for all numbers and only does conversions to deal with the antiquated use of std_logic_vector that many insist to use on all ports of sub-entities (top level entities are a different story). Because of this their code is typically very easy to read as there aren't a bunch of conversions everywhere to convert between unsigned, signed, integer, std_logic_vector, and etc on every single line of code.
 


numeric_std clarifies the intention of any code. The one thing you wont get with std_logic_vectors is correct sign extension, or a mixture of signed/unsigned in the same file, unless you include both std_logic_signed/unsigned in each package and then are explicit with every function call:

a <= b std_logic_unsigned."+" c;
d <= e std_logic_signed."+" f;

The original reason for insisting on numeric_std was exactly that it was a standard. std_logic_unsigned had different implementations for different vendors that would make code less portable. This problem is now a thing of the past, but VHDL now offers numeric_std_unsigned and numeric_std_signed exactly for the purposes of arithmatic with std_logic_vectors.
 

I worked at one place where numeric_std was strongly enforced -- using anything else meant no one would take you seriously.

I worked at another place where one office used std_logic_arith + std_logic_unsigned, and another office enjoyed feeling elite for using numeric_std. std_logic_arith + std_logic_unsigned is similar to Verilog, with the exception of implicit conversions from vector to integer. Conceptually, it doesn't make sense to include both std_logic_unsigned.all and std_logic_signed.all. I suspect people doing that believe these are required to use the signed/unsigned types or just copy/paste some other example code.

Both methods -- numeric_std only and numeric_std+numeric_std_unsigned (or std_logic_arith+std_logic_unsigned) seem valid and seem to have advantages/disadvantages compared to each other. My feeling is that unsigned/signed should be used for any operation where the operation would be ambiguous -- you also aren't forced to include "all" from any of these packages, so this is possible. It even avoids the possible annoyance of redefining "=" for std_logic_vector.

Now that all tools support std_logic_* AND there even is an IEEE library for these features, I find it hard to justify suggesting numeric_std solely based on it being an IEEE standard. However, the first comment on any post using std_logic_unsigned is to switch to numeric_std. Even if that is the only comment and even when the problem has nothing to do with numeric_std vs std_logic_unsigned.

Advocating for numeric_std only, with no explanation, is really closer to advocating the user fundamentally change their design style without actually telling them how/why. It is done when the user doesn't understand the issue and when the user is attempting to solve an unrelated issue.
 


You are more likely to be considered for a job though. More places mandate numeric_std and usage of std_logic_unsigned can make you appear antiquated/set in your ways. std_logic_unsigned/signed is also missing a several functions present in numeric std - like "/", mod and rem, resize, std_match.
I also dont like the idea that "it is more like verilog". VHDL isnt verilog. Why dont you just write verilog?
 

TrickyDicky said:
You are more likely to be considered for a job though. More places mandate numeric_std and usage of std_logic_unsigned can make you appear antiquated/set in your ways.
Click to expand...
I agree. But the reason for this is more elitism than factual -- my premise is that many developers are told NEVER to use std_logic_unsigned because HORRIBLE (unspecified/misrepresented) things will happen. They don't actually learn the differences. Ideally, they figure out how to use numeric_std in a sane manner. Less ideal, they end up hating VHDL for the perception of type-micromanagement and verbosity. But, they will very strongly advise numeric_std either way.

std_logic_unsigned/signed is also missing a several functions present in numeric std - like "/", mod and rem, resize, std_match.
Click to expand...
Sure, I don't like either as-written and prefer the practical/sane subset. My preference is to allow "+" (std_logic_unsigned), "-" (std_logic_signed), and conv_integer (std_logic_arith). "-" from signed as it is a useful unary operator for induction. conv_integer because it is convenient to have a vector-to-index function. I would prefer to force inequality comparisons for std_logic_vector to be errors. (Lexical compare is very dangerous -- confusing and not a warning. Some people will misguidedly use it as unsigned compare). I prefer equality comparison for std_logic_vector to be from the standard -- unequal lengths gives a warning.

My preference (other than conv_integer for practical reasons) is that a std_logic_vector can use +/-. Only when there could be confusion between signed/unsigned should I need to specify. This is inequality compare, resize/shift-right/multiply. I guess divide when inference wouldn't be questionable. I actually don't like using unsigned/signed when _only_ "+"/"-"/conv_integer are used. It implies values are comparable in a standard way. For things like circular buffers, comparing buffer pointers is not done using either comparison operator. It feels bad to declare them with incorrect functionality only to trust that it will not be used.

numeric_std also has fun omissions. You can't add/subtract unsigned/signed together for example.


I also dont like the idea that "it is more like verilog". VHDL isnt verilog. Why dont you just write verilog?
Click to expand...
Strong agree. But my point is that many VHDL developers can/do develop Verilog without the design failing instantly. Well, at least not failing for unsigned/signed reasons.


My point overall is that the "your design is garbage-level only because it doesn't use numeric_std" is an example of monkeys on a ladder. (google: five monkey experiment). It is almost never an actual issue. It is often used for elitism -- I suspect it is often used for misplaced elitism. It is almost always targeted at novices who will either give-up or reinforce the "numeric_std-only" choice -- without question. They will force this upon others who will force it upon others and so on.


--edit: You likely can try this experiment for yourself. Ask your coworkers if they understand the differences between numeric_std, numeric_std_unsigned, and Verilog. Ideally they will compare/contrast the benefits of each. numeric_std_unsigned is probably better as it removes the "not-standard" stigma.
 
Last edited:

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…