最近看不少群里聊怎么實(shí)現(xiàn)，也有一些具體實(shí)現(xiàn)，我們就不聊這些了，今天聊一下為什么要這么做，有哪些注意事項(xiàng)，以及怎么做（理論層面不牽扯代碼），手機(jī)打字有錯(cuò)誤請(qǐng)見諒

為什么要做？

在使用arm riscv和x86系統(tǒng)時(shí)，沒有c與其它語言交互的途徑和方法，更不要說格式化打印，這就導(dǎo)致我們對(duì)于c的debug會(huì)相對(duì)困難。畢竟通過pc查找反匯編方法debug不太直觀，很多時(shí)候我們知道他不會(huì)掛，只想單純知道它運(yùn)行到哪里了，以方便做進(jìn)一步操作。

另一方面使用c調(diào)用其它語言比如sv的task并執(zhí)行也是我們所需要的。假設(shè)一個(gè)場(chǎng)景通過c調(diào)用一個(gè)sv i2c task執(zhí)行進(jìn)行數(shù)據(jù)發(fā)送，并在c端不斷檢測(cè)i2c task是否執(zhí)行完畢（這期間可以先做別的，做完了再回來看看）。

當(dāng)然還有更復(fù)雜的操作，這就讓我們的c寫法靈活性更大，可復(fù)用性更強(qiáng)，這是系統(tǒng)方案的一部分，不能孤立的看。

需要注意什么？

執(zhí)行效率 支持多種不同的硬件接口 cache 多核并行等

執(zhí)行效率，就是我們?cè)谡{(diào)用該方法的執(zhí)行速度，比如不少人通過uart實(shí)現(xiàn)，先不說uart的頻率很難上去，就它的串行執(zhí)行，如果數(shù)據(jù)多一點(diǎn)，我們的case執(zhí)行被打印占據(jù)大量時(shí)間肯定不是想要的。當(dāng)然可以減少打印，太少了就有點(diǎn)坑了。

支持不同的硬件接口，一般來說axi的速度快很多，也可以并行執(zhí)行，是一個(gè)理想的總線，但因?yàn)橐恍┫拗疲ê蠓拢?，線并不總能被找到，i2c uart都需要可以被支持，且可以靈活切換。

cache，這里說cache原因，當(dāng)我們使用axi時(shí)，cpu發(fā)出的指令都是以一個(gè)cacheline為單位的，這就讓我們?cè)鹊囊恍┙换ゲ呗允В枰崆翱紤]。

多核并行，需要我們對(duì)不同cpu發(fā)出的命令區(qū)分開，以防命令串?dāng)_，使得打印出亂七八糟的東西出來。

怎么做？

有不少人寫，這里不多說，補(bǔ)充一點(diǎn)個(gè)人的理解。

我們需要做出一種有針對(duì)性的交互協(xié)議，用于對(duì)上述為什么以及注意事項(xiàng)的支持，也要盡量減少對(duì)地址的占用，畢竟有的項(xiàng)目地址還是挺緊張的，我們大致可以實(shí)現(xiàn)使用64byte對(duì)應(yīng)的地址的占用，很多時(shí)候使用1個(gè)dw就好了。

如果有對(duì)sv task調(diào)用（其它語言類似），就需要支持更多，比如多核對(duì)同一task并行調(diào)用，對(duì)task實(shí)施kill操作，獲取返回值，查看task執(zhí)行狀態(tài)等操作。

更進(jìn)一步我們還可以通過virtualcpu等方案讓該c在ip階段就完成測(cè)試，soc階段只是進(jìn)一步測(cè)試，而不需要重新編寫，讓soc case盡量提前，實(shí)現(xiàn)多維度并行。