19:23 <sb0> rjo, to avoid duplicating most of TestBench.__init__ in SyncFIFORelaxedCase how about making the tested FIFO class a class attribute of a generic test case

19:23 <sb0> and then derive that generic test case twice with different values for the class attribute?

19:31 <sb0> also, can't the level be fixed with a counter that increments on writable&we and decrements on readable&re?

19:42 <sb0> another way to do these things: http://billauer.co.il/reg_fifo.html

19:43 <sb0> but that FWFT FIFO design has one more cycle of latency

19:43 <sb0> maybe genlib/fifo can contain those designs instead:

19:44 <sb0> 1) reduced-latency FWFT FIFO (the current one)

19:44 <sb0> 2) classic non-FWFT FIFO

19:44 <sb0> 3) FWFT FIFO with the same design as the link above

19:45 <sb0> imo it would be pretty clear from the use case which one to use - and you rarely want both low-latency and high-capacity at the same time

19:45 <sb0> for example:

19:46 <sb0> for buffering SDRAM requests you'd use #1, as you want them to reach the bank controllers as soon as possible to avoid delaying the bus master. but there are few of those requests, so an asynchronous read is acceptable.

19:47 <sb0> for buffering a burst of data from e.g. a ADC that is later processed at a slower speed, #2 or #3 are good

19:47 <sb0> what do you think?

19:51 <sb0> what's your use case for the block-RAM FIFO by the way?

20:03 <sb0> I'm a bit worried about the combinatorial paths in SyncFIFORelaxed