• 【架构艺术】(零) 环境搭建


    写在前面

      今天尝试了如systemC,Chisel,MyHDL等方式来进行功能仿真,并生成波形到Wavedrom格式,后来发现对于学习这些简单架构,还是脑子里面根据规则进行仿真或者是编写verilog代码进行仿真即可。

      所以我们的环境依赖只有:安装wavedrom,
    在这里插入图片描述
    点击安装即可
    在这里插入图片描述
    必须要喷一下的是,它现在的icon真的好丑
    软件的教程可以参考这个

    http://www.lachun.com/202302/QdUOTnadtd.html

    附上学习参考:

    书籍:SOC设计方法与实现(第三版)、硬件架构的艺术
    视频:ETHBerkeley
    知乎:链接在正文
    CSDN:链接在正文

    下面直接进入学习

    1 跨时钟域数据传输方法之一:使用握手信号

      本节主要参考 SOC设计方法与实现(第三版)、硬件架构的艺术这两本书
      另一种方法是异步FIFO,这里就不说了,自行学习。
      书上说的比较多握手信号的可能是req、ack.
      这两本书中,都对握手有过阐述,握手主要解决的是跨时钟数据的传输问题。(《硬件架构的艺术》P64,《SOC设计方法与实现(第三版)》P131,P133)
      首先,对于CDC问题,为什么要用同步器?因为根源在另一个时钟域的信号输入到本时钟域时,很可能不满足建立保持时间,输入信号在本时钟域时钟上升沿(以上升沿的同步电路为例)前后间隙中发生了变化,导致了亚稳态。为了避免这种问题,就需要对跨时钟信号进行同步。
      握手过程中,只是进行了握手信号的跨时钟同步。而握手信号保证了在这个过程中数据payload部分不发生变化(因此数据就不会有亚稳态),因此直接对数据进行采样即可,如下图所示
    在这里插入图片描述
    但是上图不够严谨,跨时钟的控制信号从快采慢需要进行脉冲检测的处理
    在这里插入图片描述

    一些思考】  书上有这么一句话,
    在这里插入图片描述
      也就是说,如果x_req给的太短,如果是慢采快的情况,可能采不到信号。
      此外,SOC设计方法与实现(第三版)中,也说到这种握手常用于快采慢。
    在这里插入图片描述
    所以两本书都推荐用这种握手机制实现跨时钟快采慢的数据传输。那么为什么会是这样呢?下图是SOC设计方法与实现(第三版)中握手机制的图,给的也是经典快采慢的,而没有用慢采快的反馈,这是为什么呢?
    在这里插入图片描述
      我推测可能和慢采快的反馈有关,慢采快需要控制信号不能太密。但这只是我的个人推测,具体还要写代码看看波形试一试。

      除了为了跨时钟传输数据,保证数据稳定性,握手还有流控的作用,因此在同步电路或者非跨时钟的通信中,也会用到握手。比如这篇讲到的,AXI信号属于同步握手,这里握手就是为了流控,需要和本节跨时钟握手区分开。

    一些思考】  
      有没有跨时钟和流控一起用的?就是以上两种的叠加,比如AXI既需要用valid-ready进行跨时钟握手,又需要进行流控。但是GPT告诉我axi基本都是主从同步的,而且我看的一些valid-ready的教程,比如这篇,也都是默认它们是同步信号,没有对其进行跨时钟的处理。
      除此之外,是不是AXI的valid-ready只是用于流控,而跨时钟的问题是AXI组件的FIFO来实现的?那么它的valid和ready信号是如何同步的,为什么这些时序图画图的时候,都把ready、valid画在同一时钟域下
      
      
      在这篇中有提到,总线时钟都是同步时钟,都是ACLK,所以回答了上述问题,AXI4协议中,使用valid,ready作为流控握手而不是用来CDC握手,这么说来,这两本书中用req和ack是不是也有深意?

  • 相关阅读:
    vue 路由守卫实现权限控制
    openGauss学习笔记-61 openGauss 数据库管理-常见主备部署方案
    Python正则表达式一点通
    TensorBoard——Pytorch版使用(附带案例演示)
    不需要报班学课程,也能制作手办创业的新方法!
    Spring framework Day14:配置类的Lite模式和Full模式
    人脸签到系统 pyQT+数据库+深度学习
    javaweb唐院寻人表白系统计算机毕业设计MyBatis+系统+LW文档+源码+调试部署
    HTML Animation 【前端就业课 第二阶段】CSS 零基础到实战(06)
    SSL证书品牌五花八门,该选哪个好呢?
  • 原文地址:https://blog.csdn.net/SuperiorEE/article/details/133799621