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;
exit when i = inputSize;
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;
if i = inputSize-1 then
process(clk)
begin
if rising_edge(clk) then
z <= a & z(0 to inputSize-2);
end if;
end process;
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.Why bothing with a counter at all - why not just make Z a shift register?
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;
if (clk'event and clk = '1') then
if i < inputSize then
z(i) <= a;
i := i + 1;
end if;
end if;
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.Why bothing with a counter at all - why not just make Z a shift register?
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.Regarding your idea:
1) z should be inout which I fixed that.
Then you have no clue what Tricky was talking about.2) I think your solution also has the problem of "how to find the array is valid".
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.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;
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.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.
Because you don't understand VHDL and how to write hardware descriptions, you keep writing software descriptions.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.
You replied2) I think your solution also has the problem of "how to find the array is valid".
Sentence of the year! Thank you man...Then you have no clue what Tricky was talking about.
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.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!
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.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.
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.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.
Wait, where is the second waveform from? I suspect previous posts have been edited.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?