04-12-2011 02:47 AM
Is anyone else experiencing problems with FSL version 2.11.d? I'm doing an EDK design containing an FSL bus between a MicroBlaze and a custom component. With FSL v2.11.c the design works fine; after upgrading the FSL component to v2.11.d the design doesn't work correctly anymore.
The particular FSL configuration I use:
PARAMETER C_EXT_RESET_HIGH = 1
PARAMETER C_ASYNC_CLKS = 0
PARAMETER C_IMPL_STYLE = 0
PARAMETER C_USE_CONTROL = 0
PARAMETER C_FSL_DWIDTH = 32
PARAMETER C_FSL_DEPTH = 512
Targetting Virtex-6 LX240T-1; using EDK 13.1 (Build EDK_O.40d).
04-14-2011 10:07 AM
Yep, we're having problems as well and are about to give up on FSL unless someone can figure out why we are seeing the glitches we are seeing. We are using the FSL bus to communicate back and forth with a custom component as well. We use the control bit to indicate address. Control bit = 1 is address, control = 0 is data. Quite often the data and addresses coming up are wrong. There is logic in our custom component to increment the address of each new integer of data until it sees another address (control = 1). Look below, the problem we are currently seeing is that fairly often the Exists bit goes high before the data is ready or the control bit goes high, so we read garbage. Then the exists bit doesn't go high again during the period where the data is valid so we miss the good data (in this case an address, kind of important :)). Any ideas? Would going back to version c help? We've been on D the whole time as far as I know so I don't know if it works on C yet. We'll try that before we give up and switch to a PLB implementation.
04-15-2011 01:59 AM
Just did a quick investigation of the FSL component itself. I compared the VHDL of versions 2.11.c and 2.11.d. No functional changes, except for the following:
diff fsl_v20_v2_11_c/hdl/vhdl/sync_fifo.vhd fsl_v20_v2_11_d/hdl/vhdl/sync_fifo.vhd
< signal read_addr_ptr : natural range 0 to MemSize-1;
< signal write_addr_ptr : natural range 0 to MemSize-1;
> signal read_addr_ptr : natural range 0 to AddrWidth-1;
> signal write_addr_ptr : natural range 0 to AddrWidth-1;
This change seems suspicious, so let's compare some synthesis reports. All configuration parameters of the FSL are kept the same, only the version number is changed:
diff synthesis2.11.c/testfsl_wrapper_xst.srp synthesis2.11.d/
< Found 9-bit register for signal <FSL_Flag_Handle.read_addr_ptr>.
< Found 9-bit register for signal <FSL_Flag_Handle.write_addr_ptr>.
> Found 4-bit register for signal <FSL_Flag_Handle.read_addr_ptr>.
> Found 4-bit register for signal <FSL_Flag_Handle.write_addr_ptr>.
So FSL 2.11.d has only 4 bits to address a memory of 512 elements. That's not gonna work... ;-)
Bottom line: it seems memory-based synchronous implementations of FSL v2.11.d will not work correctly. Downgrading to v2.11.c may solve your problem.
04-19-2011 01:20 AM
Yes, v2.11d is broken and v2.11.c should be used until 13.2 is released.
We will create a new version v2.11e which will fix the pointer range in v2.11d.
Thanks for finding this.
04-19-2011 11:11 PM - edited 04-19-2011 11:57 PM
Using depth of 16 is fine since it use another section of the code.
The issue is only for synchronous fifo with depth more than 16.
fsl_v20_v2.11.c is included in 13.1 so there shouldn't be any issues using it.