2014-09-25 68 views
0

在DUT上,我有兩個通道,每個通道由數據接口和邊帶接口組成。這些頻道發送的交易必須按順序進行,但其中一個頻道可能會停滯,而另一個頻道會趕上。 IE: 我發送事務A向下通道0,事務C向下通道1,但通道1將不接受事務C,直到通道0已收到事務B爲止。UVM:將序列拆分到不同的子順序器上

此外,數據接口可能比每個接口上的邊帶接口慢渠道和某些邊帶交易不需要與他們一起發送數據。

目前測試的設置是爲了創建單個數據和邊帶序列,將它們放入隊列中,然後將隊列分成多個通道併發送。然而,隨着通道上的接口變化和每個配置的通道數量的變化,這變得難以維持。所以理想情況下,我想編寫測試序列,以便它不知道有多少通道或抽象事務的數據需要什麼接口。

頂部順序應該只是產生這樣的序列:

'uvm_do(open_data_stream_sequence); 
'uvm_do_with(send_data_sequence, {send_data_sequence.packet_number == 0;}); 
'uvm_do_with(send_data_sequence, {send_data_sequence.packet_number == 1;}); 
'uvm_do_with(send_data_sequence, {send_data_sequence.packet_number == 2;}); 
'uvm_do_with(send_data_sequence, {send_data_sequence.packet_number == 3;}); 
'uvm_do(close_data_stream_sequence); 

這種方法的問題是,我不想一個通道阻斷其他的或者一個接口來阻止對方,除非雙方都停止回。如果我使用如上所述的虛擬序列,則當我想要將send_data_sequence傳輸到其他通道時,open_data_stream_sequence可能會失去該單個通道,或者它可能會在邊帶接口上停頓,但我想要將send_data_sequence數據事務處理到同一通道的數據接口。

但是我正在努力弄清楚如何在子程序之間實現仲裁。我想過序列分層和使用fifos只在所有接口在中間層飽和的時候纔會停止。是否有錯誤的UVM技巧?

回答

0

我不完全瞭解你的拖延條件是什麼,但我可以告訴你的是,在任何情況下都會變得複雜。

您編寫的代碼將以線性方式執行,但您所描述的是並行行爲。你可以做的是並行啓動所有序列,並根據事件阻止或釋放驅動它們。這些事件將是非常特定於應用程序:

fork 
    'uvm_do(open_data_stream_sequence); 

    begin 
    @(unblock_channel_0); 
    'uvm_do_with(send_data_sequence, {send_data_sequence.packet_number == 0;}); 
    end 

    // ... 

    begin 
    @(done_e); 
    'uvm_do(close_data_stream_sequence); 
    end 
join 
+0

該代碼將同時啓動open_data_stream和close_data_stream序列,可能在打開之前將其關閉 - 這可能不太好。我認爲他希望並行運行多個開放式數據數據數據序列,而不是並行運行該序列的各個部分。 – Stan 2014-09-27 23:37:53

+0

是的,你就在這裏,我更新了答案。基本上你在我所設想的(排隊)中所建議的事情是這樣的事件(即排隊邏輯觸發事件)。 – 2014-09-28 04:28:06

1

我不認爲有讓周圍寫一些代碼,明白以最佳的方式(當前信道狀態和進度的事情或故意未優化的方式,如果測試需要它)。例如,當數據通道停止時,您將不得不進行一定數量的排隊以便允許無數據的邊帶請求傳遞數據請求。

這仍然可以被封裝在一個基類虛擬序列中,我們稱之爲'調度器',以這種方式刺激忽略了它的實現。調度程序將有一個'start_sequence'API,它可以啓動通道序列器上給定的序列,或者在通道未停止時將其排隊以啓動它。測試編寫者可以爲他想要寫入的每個頂層序列分配「調度程序」,並放入「start_sequence(data0); start_sequence(data1); start_sequence(sideband0);」呼叫,其中每個dataN/sidebandM虛擬序列看起來像您在問題中描述的那個。

'start_sequence'應該立即返回以允許信道完全飽和,或者可以在所有信道飽和時阻塞以減少不必要的排隊。