Electronics > FPGA

VHDL assigning to and from array gives "XXXX"

(1/2) > >>

ivan747:
Hi everyone,

I am writing a small dual port memory. If both the read address rdptr and write address wrptr are set to the same location, the data output is "XXXXXXXXX". Why is this?
I suspect this happens every time I try to assign to and from the same array location at the same time. I am simulating this on ModelSim 10.5 if that matters.


--- Code: ---entity fifo is
port(
      DataIn: in  std_logic_vector(8 downto 0);
      DataOut: out std_logic_vector(8 downto 0);
      rden, wren: in  std_logic
      [...]
);
end entity fifo;

architecture rtl of fifo is
type fifo_array is array(7 downto 0) of std_logic_vector(8 downto 0); 
signal fifo:  fifo_array;
[...]

begin

wrProc: process(wrptr,wren) is
begin
if(wren = '1') then
fifo(wrptr) <= DataIn;
end if;
end process wrProc;

rdProc: process(rdptr,rden) is
begin
if(rden = '1') then
DataOut <= fifo(rdptr);
end if;
end process rdProc;
       [...]
end rtl;

--- End code ---




The fix I came up with is adding an if statement to catch this condition.


--- Code: --- wrProc: process(wrptr,wren) is
begin
if(wren = '1') then
fifo(to_integer(wrptr)) <= DataIn;
end if;
end process wrProc;

rdProc: process(rdptr,rden) is
begin
if(rden = '1') then
if(rdptr = wrptr) then    -- We need this to not
DataOut <= DataIn; -- get XXXX on DataOut
else
DataOut <= fifo(to_integer(rdptr));
end if;
end if;
end process rdProc;

[...]

--- End code ---


This works, but it doesn't feel very elegant to me. I'm having the feeling this will add adding an implicit multiplexer and comparator that should be unnecessary.

Any insights? I'm curious about why this is happening. It looks like one of those traps for young players that Dave always mentions.

SiliconWizard:
This comes from the fact your two processes are clockless. Which is definitely not a very good idea here.

ivan747:

--- Quote from: SiliconWizard on September 28, 2023, 12:44:00 am ---This comes from the fact your two processes are clockless. Which is definitely not a very good idea here.

--- End quote ---

Thanks! I just noticed that if I add DataIn to the sensitivity list of wrProc and add fifo to the sensitivity list of rdProc, some of the weird behavior goes away (it's no longer latching on the last value of DataIn or fifo respectively). But adding a huge piece of memory to a sensitivity list sounds negligent.

I moved over to conditional assignments and it's much better now:


--- Code: --- fifo(to_integer(wrptr)) <= DataIn when wren = '1';

DataOut    <= fifo(to_integer(rdptr)) when rden = '1'; else
"ZZZZZZZZZ" when rden = '0' else
"UUUUUUUUU";

--- End code ---


There is still an implied latch when writing but that's the point of memory, I guess.  :-+

I also had a bug in a section of the code I haven't posted here, that dealt with addresses. In one of the process statements I was incrementing the write address using the increment read address signal. I still don't know why the data output would be "XXXXXXXXX" though, I can't think of a way that would be possible. Who knows, I'm kind of tired and maybe missed a double assignment. That's my only explanation.

SiliconWizard:
Yes, but I'd still recommend implementing clocked memories for anything used outside of pure simulation.
You have implemented a combinatorial dual-port memory, which will give you poor performance (low Fmax) and a lot of potential timing issues in real-life implementations. Don't do that, or do that only if there's an absolutely good reason for doing so.

AndyC_772:

--- Quote from: ivan747 on September 28, 2023, 01:32:58 am ---adding a huge piece of memory to a sensitivity list sounds negligent.

--- End quote ---

It's completely normal to have a process be sensitive to every signal that's referenced within it. VHDL-2008 allows 'process (all)' as a shortcut.

I'll echo what others have said, though... you *really* need a clock for this to ever work in practice. As a bonus, it might even then be able to use the hard RAM blocks that most FPGAs include, rather than soaking up a huge amount of expensive, asynchronous logic.

Navigation

[0] Message Index

[#] Next page