Yes, I send it attached. It's a modified version of the current testbench. Another thing I would like to add. The performance of the FML bridge could be slightly improved. Think about this situation: while it is doing a REFILL (due to a previous wishbone read or write transaction) and a read operation comes meanwhile, it has to wait till all the refill operation has completed in order to check the cache hit and return data. But if the read is already a hit, there's no need to wait and the data can be returned immediately.
Zeus. 2010/1/20 Sébastien Bourdeauducq <[email protected]> > Hi, > > On Monday 18 January 2010 11:32:00 you wrote: > > Just one observation regarding FML. In the specification page 3, section > > 2.7 "Overlapping reads and writes" it says "The slave must assert the > ack > > signal at least two clock cycles after it asserted it to acknowledge the > > previous bus cycle". I understand that the read-write sequence could be > > faster if there is no wait state in the middle, that is, it's possible > to > > have two consecutive ack's, as read and write channels are different. As > > we consider the ack signal like a one cycle pulse. What do you think? > That > > is not very useful for the HPDMC as that throughput would not be > possible, > > but at least the protocol allows it :) > > > > I made a testbench for the HPDMC DDR32 to stress reads and writes and see > > the full pipeline in action, but I saw some failing tests. fml_stb is > > always 1 and I'm combining reads and writes in different order. I saw > that > > when doing a read after a write, the ack for the read comes too early > and > > the last 64-bit word of the previous write transaction is not written to > > memory. So I modified the read_safe_counter after a write, initializing > it > > to 4 (I guess that for CAS = 3 it would be 3). > > > > On the other hand, I saw that reducing the write_safe_counter in 1, both > > after a read and after a write it continues to work in both cases, > > increasing the overall throughput. I'm not sure if you want to try that. > I > > can send you the diff. > > > > --- milkymist/cores/hpdmc_ddr32/rtl/hpdmc_datactl.v 2009-12-21 > > 12:47:11.000000000 +0100 > > +++ hpsys/cores/hpdmc_ddr32/rtl/hpdmc_datactl.v 2010-01-18 > > 04:07:34.000000000 +0100 > > @@ -49,11 +49,11 @@ > > read_safe_counter <= 3'd4; > > read_safe <= 1'b0; > > end else if(write) begin > > - /* after a write, read is unsafe for 5-CL cycles, therefore we load : > > - * 3 at CAS Latency 2 (tim_cas = 0) > > - * 2 at CAS Latency 3 (tim_cas = 1) > > + /* after a write, read is unsafe for 6-CL cycles, therefore we load : > > + * 4 at CAS Latency 2 (tim_cas = 0) > > + * 3 at CAS Latency 3 (tim_cas = 1) > > */ > > - read_safe_counter <= {2'b01, ~tim_cas}; > > + read_safe_counter <= {~tim_cas, tim_cas, tim_cas}; > > read_safe <= 1'b0; > > end else begin > > if(read_safe_counter == 3'd1) > > @@ -76,10 +76,10 @@ > > write_safe <= 1'b1; > > end else begin > > if(read) begin > > - write_safe_counter <= {2'b11, tim_cas}; > > + write_safe_counter <= {1'b1, tim_cas, ~tim_cas}; > > write_safe <= 1'b0; > > end else if(write) begin > > - write_safe_counter <= 3'd4; > > + write_safe_counter <= 3'd3; > > write_safe <= 1'b0; > > end else begin > > if(write_safe_counter == 3'd1) > > Thanks. I will check. > > Could you send your test bench for it to be included with the others, in > order > to improve the HPDMC test suite? > > Sébastien >
tb_hpdmc.v
Description: Binary data
_______________________________________________ http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org IRC: #milkym...@freenode Webchat: www.milkymist.org/irc.html Wiki: www.milkymist.org/wiki
