02:29 <rjo> sb0: re SyncFIFORelaxed: it's more logic. and sometimes (actually often) ISE managed to find a register to balance into SyncFIFO and make it mappable to BRAM.

02:32 <rjo> sb0: i would consider SyncFIFORelaxed as a solution to a problem that only occurs in some hard to predict situations.

02:37 <rjo> sb0: ISE is surprisingly stupid when it comes to collecting registers to cancel asynchronous reads. i have a testcase where i have to add a dummy register (that naturally then gets trimmed later) for it to realize that it can use BRAM.

02:51 <rjo> sb0: in my tests i have not seen it degrade timing. but in general it is worse than the bare SyncFIFO. see e.g. the mux on dout.

02:55 <rjo> BTW: what minimum latency does AsyncFIFO have? i am too lazy to think it through.

03:01 <sb0> the effect on timing of the mux on dout is not obvious; you have register -> mux -> dout vs. register -> async read -> dout

03:02 <sb0> for a large FIFO not mapped to BRAM, I imagine the mux is actually faster

04:09 <rjo> sb0: true. and both cases can end up looking completely different after ISE is has optimized it...

04:11 <rjo> sb0: one thing i would be worried about is the complicated combinatorial do_shunt signal that depends on pretty much everything, including _both_ re and we which are usually pretty complex by themselves.

04:12 <rjo> sb0: and i also dont like the name SyncFIFORelaxed but could not come up with something better.

16:18 <ysionneau> M-labs is quoted (and Sebastien's biography as well) in a report which has been given to the French Minister of innovation and digital economy

16:18 <ysionneau> french link : http://www.lesechos.fr/entreprises-secteurs/tech-medias/actu/0203393893415-la-france-met-ses-developpeurs-a-l-honneur-659366.php#Xtor=AD-6001

16:18 <ysionneau> page 136-137 of the PDF :)