scott_wilson46's comments

Actually another thing I am curious about is how asynchronous clock domains are handled Usually this is something thats quite tricky to model in a HLS tool. Also, how about simulating the interactions between the domains?

I can't help but feel that the VHDL that was written is a bit overly verbose. You could probably write something like:

  i_sm: process(clk, reset)
  begin
    if (reset) then
      state <= DATA_BITS;
    elsif (clk'event and clk = '1') then
      case (state)
        when DATA_BITS => 
          if (data_valid = '1') then
            if (count < 8) then
              count <= count + 1;
            else
              state <= STOP_BIT;
              count <= 0; 
            end if;
          end if;
        when STOP_BITS => 
          if (data_valid = '1') then
            if (count < num_stop_bits) then
              count <= count + 1;
            else
              state <= DATA_BITS;
              count <= 0;
            end if; 
          end if;
       end case
    end if;
  end process i_sm;

which is not too dis-similar from the Cx example (I've missed a few things out like port/signal declerations, just wanted to show the guts of the code). The thing I like about VHDL/Verilog is that its easy to tell the exact port names, what the clk is, the name and type of reset, etc which is useful information for putting the block in the context of an overall system.

f you are interested. I did something similar for fpga: https://github.com/scottwilson46/FPGARandom

Theres also the SocKit from arrow: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E...

Very similar to Zynq but from altera rather than xilinx

It's not going to limit clock speed, its just not going to work. To write multiple values to different ram locations (considering a ram has at most two ports) would require you to stay in the INIT state for 9 cycles and do something like:

  INIT:
    begin
    if (count == 9) begin
      next_count == 0;
      nextState = `EVALUATE;
    end
    else 
      next_count == count + 1;
    case (count)
      0: begin ram_wr_addr = count; ram_wr_data = `CMD_LED_ON; ram_wr_en = 1; end
      1: begin ram_wr_addr = count; ram_wr_data = `CMD_LOAD_NEXT_TO_ACCU; ram_wr_en = 1; end
      etc....
    end

usually you have a ram module that takes an address and some write_data, wr_en, etc rather than accessing the array directly.

One thing to note is that if as the paper says:

"Many well-known web-sites deploy distributed in- memory caches, which are implemented with standard DRAM on a large array of x86 servers, to reduce access load on databases"

then a single server with an FPGA card on it is going to be a lot cheaper than an array of x86 servers. Plus I would imagine that real-estate in a data centre is another significant cost and having one server with an attached FPGA would also be an advantage in this situation

Any modern ASIC being built would be tested using Automatic Test Pattern Generation. This involves connecting all the registers in the chip into a chain and feeding patterns in and out of the chains and stimulating the logic between registers in a defined manner. These tests will at one level be looking for Stuck and 0 and Stuck at 1 faults and typically nobody would tape out a chip without >99% coverage. It would be very difficult to fiddle with individual gates as the author describes without this being detected with an ATPG test.