Accessing records in VHDL

[vGoodtimes]

-- buffer is 128b for convenience
-- not sure if this synthesizes, if not just use a different mux
-- construct.
process (clk) is
  variable nextStateExt : integer range 0 to 31 := 0;
  variable nextState : integer range 0 to 15 := 0;
begin
  if rising_edge(clk) then
    nextStateExt := validIn + state; -- validIn is assumed to be integer range 0 to 16
    nextState := nextStateExt mod 16;

    -- lsbs will be buffer, msbs will be dataIn
    dataOut <= buffer;
    dataOut(127 downto 8*state) <= dataIn(127 - 8*state downto 0);

    if (nextStateExt >= 16) then
      validOut <= '1';
    else
      validOut <= '0';
    end if;

    if (nextStateExt >= 16) then
      -- copy the msbs of data in to the lsbs of buffer
      buffer(127 - 8*state downto 0) <= dataIn(127 downto 8*state);
    else
      -- copy the lsbs of data to the msbs of buffer
      buffer(127 downto 8*state) <= dataIn(127 - 8*state downto 0);
    end if;

    // and update state
    state <= nextState;

  end if;
end process;

This should be the packer. Not sure if the mux is supported like that in quartus. You should probably double check it for errors as I threw it together quickly.

 

[std_match]

Both approaches in #57 should work, but the synthesis tool may prefer one of them.
You are still looping over bits:

          for j in 0 to ( bits_per_frame - 1 ) loop
            if j >= current_bit then

The lines above correspond to one comparator per output bit. Only one comparator per output symbol is needed.

 

[shaiko]

vGoodtimes,

This should be the packer. Not sure if the mux is supported like that in quartus. You should probably double check it for errors as I threw it together quickly.

dataOut(127 downto 8*[COLOR="#FF0000"]state[/COLOR]) <= dataIn(127 - 8*[COLOR="#FF0000"]state [/COLOR]downto 0);

This type of code ( I.E: runtime changing literals for setting the vector's boundaries ) is exactly what I'm trying to avoid.

std_match,
As I see it, my version of code as posted in #57 is a special case of Kevin's version when bits_per_symbol = 1. With a SUPER smart synthesis tool ( and I'm not implying that such a tool even exists ) they both should optimize to the exactly the same logic.
Would you agree ?

 

[FvM]

Strictly speaking, the thread discussion is running off-topic since long as post #13 is the last one referring to VHDL records.

Except for a few side remarks, the thread seems to miss a "synthesizable VHDL" perspective. Means, all these output(i) <= input(j) and similar constructs can be mapped to hardware, but will end up in a huge sea of gates and respective routing effort. You should be aware that some designs can't be optimized to anything good by a clever synthesis tool, you need to reconsider the design structure.

 

[std_match]

Muxing is required for symbols within a message, but not required for messages within the big message.

I agree with this, and it is a clue to a solution that might be better than what we have so far.

I think it should be a pipelined solution in 2 steps:

1. Build one complete message (16 symbols), and store it in a 128-bit register. This requires 15 symbol muxes with different number of inputs (2-16) and 16 comparators of unknown complexity. The implementation for this can be inspired by the earlier postings in this thread. Non-valid symbols can be written or not, but we never write outside of the first 128-bit register (possibly with added dummy bits that will be removed during synthesis).

2. Connect the complete message in parallel to an arbitrary number of message registers (the frame). The only required logic is to create the write strobes. This can be done without comparators since they always will be cycled in the same order. A shift register would be enough.

By describing it as 2 steps, the code will be easier to write and understand. The register after step one is good for speed, and will probably come for free since there is a register bit directly after each LUT.

The logic (muxes + comparators) for this approach will not increase with the frame size. It is only the storage for the frame that will take space.

 

[vGoodtimes]

I agree with this, and it is a clue to a solution that might be better than what we have so far.

I think it should be a pipelined solution in 2 steps:

1. Build one complete message (16 symbols), and store it in a 128-bit register. This requires 15 symbol muxes with different number of inputs (2-16) and 16 comparators of unknown complexity. The implementation for this can be inspired by the earlier postings in this thread. Non-valid symbols can be written or not, but we never write outside of the first 128-bit register (possibly with added dummy bits that will be removed during synthesis).

2. Connect the complete message in parallel to an arbitrary number of message registers (the frame). The only required logic is to create the write strobes. This can be done without comparators since they always will be cycled in the same order. A shift register would be enough.

By describing it as 2 steps, the code will be easier to write and understand. The register after step one is good for speed, and will probably come for free since there is a register bit directly after each LUT.

The logic (muxes + comparators) for this approach will not increase with the frame size. It is only the storage for the frame that will take space.

My posts #22/#24/#61 and your post #30 seem to describe this. I had suggest a BRAM because a 12800 bit bus seems like a good source of routing problems.

 

[std_match]

My posts #22/#24/#61 and your post #30 seem to describe this. I had suggest a BRAM because a 12800 bit bus seems like a good source of routing problems.

Yes, a BRAM is preferred for the frame storage. If 12800 bits are really needed in parallel, a 128-bit wide shift register is probably better than the parallel write I suggested in post #65.