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.

Reading numbers and assign them to an array

Status
Not open for further replies.

mahmood.n

Member level 5
Joined
Dec 2, 2011
Messages
85
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
2,046
I want to read some numbers in multiple clock cycles and put them in an array. The code is simple

Code:
package types is				 
	constant inputSize: integer := 20;
	constant maxNumber: integer := 8;
	type intArray is array (0 to inputSize-1) of integer range 0 to maxNumber-1;
end;
entity read is
	port( a: in integer range 0 to maxNumber-1;
				clk: in std_logic;
				z: out intArray);
end;
architecture arch1 of read is
begin								
	process( clk )
		variable i: integer range 0 to inputSize-1 := 0;
		variable myAr: intArray;
	begin
		if (clk'event and clk = '1') then
			myAr(i) := a;
			i := i + 1;
		end if;
		z <= myAr;
	end process;
end;

Due to the global clock signal in my design, I want to terminate this read operation after reading 20 numbers. With that code, it is not possible. I have another version of such reading with for loop inside the clock event. There I can write

Code:
exit when i = inputSize;

That means, in one clock read all numbers and assign them to the array elements. For large numbers (large inputSize), that becomes a bottleneck since all assign and increment (due to the array logic) have to be replicated.
 

Whats the question?
Your alternative approach is not viable hardware - it looks like you are trying to write software, which VHDL is not.
Your first attempt is more realistic, as you only ever receive 1 integer per clock cycle, so I dont know how you think you can assign the entire array in a single clock cycle?

Other notes:
1. z <= myAr; should be assigned inside the clocked part of the process
2. why are you using variables? signals would make more sense in terms of hardware - there is NOTHING you can do with variables you cannot do with signals - and signals map better to hardware.
3. No comments
4. What is the point of this code?
 

Yes I know that reading all at one clock cycle is not hardware realistic.

Code:
process( clk, a )
	variable i: integer range 0 to inputSize-1 := 0;
begin
	if (clk'event and clk = '1') then
		z(i) <= a;
		i := i + 1;
		if i = inputSize then
			i := 0;
	end if;
end process;

The code is trying to read multiple integer numbers from input and put them in a array for further process (sort). After the process, I have a write entity which sends out each element in a clock cycle. The write entity is fine and working. With this design, I want to reduce the IO pins.

Do you agree with this code?
 

I agree in that it should work, except for this minor change:

Code:
if i = inputSize-1 then

I will comment though - how does the next entity know when the output Z is valid? at the moment it is a sliding window with Z holding that values. Why bothing with a counter at all - why not just make Z a shift register?

Code:
process(clk)
begin
  if rising_edge(clk) then
    z <= a & z(0 to inputSize-2);
  end if;
end process;
 

Why bothing with a counter at all - why not just make Z a shift register?
Because the OP has consistently shown they design using a software paradigm and haven't learned to think in terms of circuit schematics and hardware implementation.
 

Regarding your idea:
1) z should be inout which I fixed that.
2) I think your solution also has the problem of "how to find the array is valid".

The test bench looks like

Code:
	process( c )	
	begin
		c <= not c after 2 ns;
	end process;				 
	process
	begin
		a <= 4;
		wait for 4 ns;
		a <= 5;
		wait for 4 ns;
		a <= 1;
		wait for 4 ns;
		a <= 6;
		wait for 4 ns;
		a <= 3;
		wait for 4 ns;
		a <= 2;
		wait for 4 ns;
		a <= 7;
		wait for 4 ns;
		a <= 3;
		wait for 30 ns;
	end process;

However, as you can see in the picture, the output doesn't represent the "sorted input". If you want to know that the sorter is working properly, I have to say yes! because I designed that in a step by step fashion
1- I created 8 inputs and put them in an array in one entity (sorter) which sends out an array. I verified that it is working
2- I created a write entity to take the sorted array and send out each number (array element) one by one in each cycle. That also worked.
3- I created a read entity which causes problem.

I have to say that I tried this code also:
Code:
if (clk'event and clk = '1') then
	if i < inputSize then
		z(i) <= a;
		i := i + 1;
	end if;
end if;

This is a software solution though but still have the same problem.
 

Attachments

  • so.jpg
    so.jpg
    51.7 KB · Views: 54

Why bothing with a counter at all - why not just make Z a shift register?
Because the OP has consistently shown they design using a software paradigm and haven't learned to think in terms of circuit schematics and hardware implementation.

Hence everything is an integer unless it is a control bit. Use for loops and variables (software never calls places you hold stuff a signal).

There are only a few concepts that are portable from software to HDL coding.
1. Adherence to consistent code formatting.
2. Commenting code.
3. Modularity and code reuse.
4. Understanding and using source control.
 

Regarding your idea:
1) z should be inout which I fixed that.
INOUT do you know what INOUT is supposed to be used for? It certainly isn't used inside an FPGA between different components. It should only be used for package PINs where there is a physical tri-state buffer.

2) I think your solution also has the problem of "how to find the array is valid".
Then you have no clue what Tricky was talking about.

The test bench looks like

Code:
	process( c )	
	begin
		c <= not c after 2 ns;
	end process;				 
	process
	begin
		a <= 4;
		wait for 4 ns;
		a <= 5;
		wait for 4 ns;
		a <= 1;
		wait for 4 ns;
		a <= 6;
		wait for 4 ns;
		a <= 3;
		wait for 4 ns;
		a <= 2;
		wait for 4 ns;
		a <= 7;
		wait for 4 ns;
		a <= 3;
		wait for 30 ns;
	end process;
Uh, unless the rising edges of the clock c (you use terrible uninformative names) is NOT aligned with the input data a, You will end up with problems with the scheduler that result in race conditions between c and a, which will make your simulation waveforms lie to you (see the c and a relationship after time tick 56). You need to read a good book on VHDL instead of learning it by trial and error or from the garbage tutorials you find on the internet.

However, as you can see in the picture, the output doesn't represent the "sorted input". If you want to know that the sorter is working properly, I have to say yes! because I designed that in a step by step fashion
1- I created 8 inputs and put them in an array in one entity (sorter) which sends out an array. I verified that it is working
2- I created a write entity to take the sorted array and send out each number (array element) one by one in each cycle. That also worked.
3- I created a read entity which causes problem.
all I can say is GIGO (Garbage In, Garbage Out), if all your testbenches look like the one you posted for testing each part of your design then if you stimulate your design with garbage vectors and make it work then you'll likely have garbage outputs as the simulation ends up lying to you as it doesn't represent what will happen in reality.

I have to say that I tried this code also:
Code:
if (clk'event and clk = '1') then
	if i < inputSize then
		z(i) <= a;
		i := i + 1;
	end if;
end if;

This is a software solution though but still have the same problem.
Because you don't understand VHDL and how to write hardware descriptions, you keep writing software descriptions.

Draw a schematic of the design first at the register transfer level (RTL) then translate it to VHDL. If you can't draw the circuit then you shouldn't be coding in VHDL, because it means you don't know how to design digital hardware and need to learn logic design first.
 

The method for creating clock is written in many pages and examples. The idea is to create a loop or something that repeatedly executed and then "not"ing the signal after some time units. I also did that in verilog programs and didn't see any problem at least for exercises I wrote. So, if you have better idea please let us know. Just saying such things are garbage and you have to find good books is not a solution!

I didn't find a helpful answer from your text but only "go and understand vhdl because it is your problem"!!. If you are a teacher, then this is not a good teaching method. Believe me!

I asked TrickyDicky
2) I think your solution also has the problem of "how to find the array is valid".
You replied
Then you have no clue what Tricky was talking about.
Sentence of the year! Thank you man...
 

I never said the clock was wrong, I wrote that you've aligned your input data a so it changes at the same time as the clock edges. I guess it must be very hard to see that in the waveforms after 56 time units? Ever heard of setup and hold time, so why would you try to violate both in your testbench? The VHDL scheduler can end up with race conditions when you toggle a clock at the same time you attempt to assign a new value. You can sometimes end up getting new values or old values depending on the order of statements, etc (and it can vary depending on the simulator used).

I didn't find a helpful answer from your text but only "go and understand vhdl because it is your problem"!!. If you are a teacher, then this is not a good teaching method. Believe me!
Members might be more helpful if you listened to the recommendations from members (who do this for a living) and actually did what they suggest. Completely ignoring those recommendations says a lot about what you think of those suggestions and the help given. It certainly doesn't make me want to give a detailed answer with examples.

Sorry for pointing it out, but not knowing VHDL IS your problem. You treat VHDL like a software language after repeatedly being told it is a hardware description language (description being the key word here). I'm not a teacher, I have no patience for someone who doesn't listen to an answer after asking a question and ignores issues pointed out by others.

I won't even comment about the sentence of the year...as you still don't get what TrickyDicky's code example was explaining (which had nothing to do with the lack of a way to determine valid).

I'll add you to my ignore list, so I won't be tempted to answer any more of your threads/posts. :)
 

Many of the software design skills are actually applicable. You just have to realize which ones and how they apply. Knowing algorithms and data structures is very useful for example. It gives a concept of "how things scale" that is important. Knowing the value of consistent interfaces as well. The worst designs are ones where the HW dev knows that every interface must be unique and optimized. And uncommented because they are brilliant...

There is a misguided distrust among FPGA developers for anything that might be software engineer related. The end goal is to describe hardware using a language that has "describes hardware" as a happy accident. The main goal is simulation of logic -- if someone can figure out how to also do synthesis so much the better... This is a vicious cycle where better methods never gain acceptance due to be too-SW so better methods are not developed or supported as no-one will use them as they are too-SW...


The OP's design is marginal. The logic loads 20 values exactly one time after programming, with the load occurring immediately after the FPGA programming. This is not practical and is something that would be expected from a simulation-only design. A real design would have a reset, as well as a protocol that was well defined and described when data was loading and when loading was finished.

The coding style is ok. It isn't the normal method, but it is no worse in terms of synthesis. I don't like using variables for registers. Otherwise, it does not confuse me and almost certainly will not confuse synthesis tools. Calling it a software approach is odd to me though as it seems to infer the same hardware as more traditional approaches.

The design choice is not optimal -- a shift register almost certainly is a better choice. But it is probably ok for modern devices. As this seems to be a design that is never going to be practical and will only ever be run in a simulator, the choice is likely to be better for simulation speed.

The simulation is also marginal but probably ok. The data apparently changes during falling edges of the clock from the waveform. There doesn't appear to be any issue with the order of process evaluation being important when the time-based event and clock-based event happen to occur in the same simulation time.


The simulation issues I can't solve. I have no idea what "f" is in the image. It isn't in the code provided. I see similar numbers but that is all I can say. Perhaps these numbers are correct for whatever "f" is? The post makes me think they are not though.

The code is clearly a simulation-only design intended to provide a starting point to digital design. I also have no idea how an inout port would seem like a good idea or be useful. I'm actually more curious to hear the logic behind that.
 

The simulation is also marginal but probably ok. The data apparently changes during falling edges of the clock from the waveform. There doesn't appear to be any issue with the order of process evaluation being important when the time-based event and clock-based event happen to occur in the same simulation time.
then you need to look at the simulation output and not their testbench code, because they didn't use that code to simulate the design based on the simulation output.
falling edge changes for a (top waveform).
Capture.JPG
rising edge changes for a
Capture2.JPG

The code is clearly a simulation-only design intended to provide a starting point to digital design. I also have no idea how an inout port would seem like a good idea or be useful. I'm actually more curious to hear the logic behind that.
INOUT was obviously used because they are not using VHDL 2005? support for reading out ports in the architecture. This is the standard mistake that most VHDL newbies make.
 

Wait, where is the second waveform from? I suspect previous posts have been edited.
 

Wait, where is the second waveform from? I suspect previous posts have been edited.

Seriously? Both images are clips from the same waveform at different locations. I figured I needed to explicitly show what happens after 65 ns, since there seems to be an issue with others being able to resd the waveform posted by the OP.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top