# SPI BFM spi\_slave\_transmit exit time **URL:** \ **Category:** Bitvis VIP SPI\ **Created:** [August 31, 2023, 12:44pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388 "2023-08-31T12:44:08Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![EZA](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/eza/32/143_2.png) [@EZA](https://forum.uvvm.org/u/EZA)\ **Post date:** [August 31, 2023, 12:44pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/1 "2023-08-31T12:44:08Z")
Hi, I’m using the SPI BFM function spi\_slave\_transmit in single-word mode with two BFM configured differently. The first has CPOL=‘0’ and CPHA=‘0’ the second has CPOL=‘1’ and CPHA=‘1’ During the simulation, the first BFM (CPOL=‘0’ and CPHA=‘0’) completes the spi\_slave\_transmit function right after the SPI clock rising edge. This means I can start a new spi\_slave\_transmit because the next MISO should change after the next SPI clock falling edge. While the second BFM (CPOL=‘1’ and CPHA=‘1’) complete the spi\_slave\_transmit function right after the SPI clock falling edge. This means I can NOT start a new spi\_slave\_transmit because the next MISO should have already been changed. Is this behaviour correct? ---
**Author:** ![UVVM\_Team](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/uvvm_team/32/102_2.png) [@UVVM\_Team](https://forum.uvvm.org/u/UVVM_Team)\ **Post date:** [October 18, 2023, 8:59am UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/2 "2023-10-18T08:59:19Z")
Thanks for your feedback. We will check this. ---
**Author:** ![UVVM\_Team](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/uvvm_team/32/102_2.png) [@UVVM\_Team](https://forum.uvvm.org/u/UVVM_Team)\ **Post date:** [October 30, 2023, 1:36pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/3 "2023-10-30T13:36:50Z")
Could you please elaborate a bit on this? ---
**Author:** ![EZA](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/eza/32/143_2.png) [@EZA](https://forum.uvvm.org/u/EZA)\ **Post date:** [November 24, 2023, 5:39pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/4 "2023-11-24T17:39:19Z")
Hi, I worked on this problem, maybe the previous post is not clear. I will retry. In my TB I use the spi\_slave\_receive/transmit in single-word mode. I have: loop 1. spi\_slave\_receive( v\_data, “Receiving from DUT”, spi\_if, START\_TRANSFER\_ON\_NEXT\_SS, C\_SCOPE, shared\_msg\_id\_panel, config); 2. my TB decode v\_data 3. spi\_slave\_transmit (…START\_TRANSFER\_IMMEDIATE) end loop I have a breakpoint right after the function spi\_slave\_receive( v\_data, “Receiving from DUT”, spi\_if, START\_TRANSFER\_ON\_NEXT\_SS, C\_SCOPE, shared\_msg\_id\_panel, config); If I configure the SPI BFM in CPOL=‘0’ and CPHA=‘0’ The breakpoint is triggered after the falling SCLK edge ![SPI_MODE_0](https://europe1.discourse-cdn.com/flex017/uploads/uvvm/original/1X/aa1bbbecc816d086df317e2dca138a735213016d.png) The problem is that in CPOL=‘0’ and CPHA=‘0’ I should update my MISO line at the SCLK falling edge, but when I call the spi\_slave\_transmit (3.) the miso is updated using the spi\_slave\_transmit\_and\_receive too late. In fact, the first MISO update in the spi\_slave\_transmit\_and\_receive is when: ``` if not config.CPHA then miso <= bfm_tx_data(C_ACCESS_SIZE - v_tx_count - 1); v_tx_count := v_tx_count + 1; end if; ``` so in my configuration when SCLK=‘1’ but at the SCLK rising edge the MISO should be valid. ---
**Author:** ![dbemlogic](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/dbemlogic/32/138_2.png) [@dbemlogic](https://forum.uvvm.org/u/dbemlogic)\ **Post date:** [January 15, 2024, 8:24am UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/5 "2024-01-15T08:24:41Z")
Hi, I have taken a look at this issue now. I think my testbench may not be configured identically to yours, because I can’t trigger the problem. I have two BFMs in my testbench. Both are configured to CPHA = ‘0’ and CPOL = ‘0’. One is a master and the other is a slave. The following code is used to trigger the VVCs using the BFMs: ```auto -- Chip select shall not be deasserted between operations, and there shall be no pause on SCLK between operations. spi_master_transmit(data => 8x"55", action_when_transfer_is_done => HOLD_LINE_AFTER_TRANSFER); spi_slave_check(data_exp => 8x"55", when_to_start_transfer => START_TRANSFER_ON_NEXT_SS); spi_slave_transmit(data => 8x"AA", when_to_start_transfer => START_TRANSFER_IMMEDIATE); spi_master_check(data_exp => 8x"AA", action_when_transfer_is_done => RELEASE_LINE_AFTER_TRANSFER); await_completion(SPI_VVCT, 0, 1 us); await_completion(SPI_VVCT, 1, 1 us); ``` As you can see from the code, I issue two commands to each of the two VVCs. First I command the master to transmit and slave to receive. Then, without any pause, I trigger the slave to transmit and master to receive. In this example the BFM config is set so that bit time is 40 ns and the _ss\_n\_to\_sclk_ setting is 6 ns. The following picture shows the moment where the master transmit/slave receive ends and the slave transmit/master receive begins. ![spi_slave_transmit](https://europe1.discourse-cdn.com/flex017/uploads/uvvm/original/1X/3e8b75b8083e9dedf6cebd34e8224475da22dbe0.png) The _spi\_slave\_receive()_ procedure is finished at the final falling edge of SCLK + _t\_spi\_bfm\_config.ss\_n\_to\_sclk_ . In my TB that is the time of the last falling edge of SCLK + 6 ns. The _spi\_slave\_transmit()_ procedure then sets the value of MISO, also at the last falling edge of SCLK + 6 ns. Because the BFM is set to SPI mode 0 the data shall be transmitted at the falling edge of SCLK and sampled at the rising edge of SCLK. Depending on the setting of _spi\_bit\_time_ and _ss\_n\_to\_sclk_ the start of _spi\_slave\_transmit()_ begins well within the required time before the rising edge of SCLK. The MISO updates 6 ns after the last falling edge of SCLK of the previous transaction, and 14 ns before the first rising edge of the _spi\_slave\_transmit()_ procedure. Have I configured anything differently with respect to your testbench? Best regards, Daniel Blomkvist EmLogic Edit: Here’s the BFM config I am using: ```auto constant C_SPI_BFM_CONFIG_DEFAULT : t_spi_bfm_config := (CPOL => '0', CPHA => '0', spi_bit_time => 40 ns, ss_n_to_sclk => 6 ns, sclk_to_ss_n => 5 ns, inter_word_delay => 0 ns, match_strictness => MATCH_EXACT, id_for_bfm => ID_BFM); ``` ---
**Author:** ![EZA](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/eza/32/143_2.png) [@EZA](https://forum.uvvm.org/u/EZA)\ **Post date:** [January 16, 2024, 12:03pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/6 "2024-01-16T12:03:40Z")
Dear Daniel, to reproduce the error in your configuration I changed the spi\_bit\_time, ss\_n\_to\_sclk and sclk\_to\_ss\_n to match the real SPI timing I want to simulate. My BFM config is: ```auto constant C_SPI_BFM_CONFIG_DEFAULT : t_spi_bfm_config := (CPOL => '0', CPHA => '0', spi_bit_time => (1000.0/96.0)*5.0 *1 ns, ss_n_to_sclk => 40 ns, sclk_to_ss_n => 40 ns, inter_word_delay => 0 ns, match_strictness => MATCH_EXACT, id_for_bfm => ID_BFM); ``` in this configuration, I have: ![image](https://europe1.discourse-cdn.com/flex017/uploads/uvvm/original/1X/cec9cd42d56c086e77a2042ee3d24a6dba168a01.png) The miso is updated after the sclk rising edge. I think that the problem comes from the time ss\_n\_to\_sclk which is bigger than the spi\_bit\_time. The SPI spi\_slave\_check function exit time is after the sclk rising edge. If you want I can share with you my tb. Best regards, Emanuele ---
**Author:** ![dbemlogic](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/dbemlogic/32/138_2.png) [@dbemlogic](https://forum.uvvm.org/u/dbemlogic)\ **Post date:** [January 21, 2024, 7:01pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/7 "2024-01-21T19:01:47Z")
Hi Emanuele, I changed my TB to use your BFM and now my TB also fails in the same way as yours. I will investigate some more and discuss this with the other developers and I will get back to you. Thank you for reporting this issue. Best regards, Daniel Blomkvist ---
**Author:** ![EZA](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/eza/32/143_2.png) [@EZA](https://forum.uvvm.org/u/EZA)\ **Post date:** [October 7, 2024, 4:06pm UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/8 "2024-10-07T16:06:28Z")
Dear Daniel, do you have any news about this issue? Best regards, Emanuele Zaccaro ---
**Author:** ![UVVM\_Team](https://dub1.discourse-cdn.com/flex017/user_avatar/forum.uvvm.org/uvvm_team/32/102_2.png) [@UVVM\_Team](https://forum.uvvm.org/u/UVVM_Team)\ **Post date:** [October 8, 2024, 6:25am UTC](https://forum.uvvm.org/t/spi-bfm-spi-slave-transmit-exit-time/388/9 "2024-10-08T06:25:35Z")
Hi Emanuele, We have found the issue. The issue was as you suspected with the relation between _ss\_n\_to\_sclk_ and _spi\_bit\_time_. A fix has been implemented and will be part of the next release of UVVM. Here is the fix: ![fix](https://europe1.discourse-cdn.com/flex017/uploads/uvvm/original/1X/cb48af9970384e11327d55962b7a62895d4d91a8.png) Best regards, The UVVM Team