fshc之请求仲裁机制的代码分析

 1 always@(posedge spi_clk or negedge spiclk_rst_n)
 2 begin
 3    if(~spiclk_rst_n)
 4       arbiter2cache_ack_r <=1‘b0;
 5    else if(cache_req_sclk && flash_idle && ~atom_op_en_sync2 && ~arbiter2mcu_ack_r)
 6        arbiter2cache_ack_r <=1‘b1;
 7     else if(mcu_req_arb && flash_idle && ~arbiter2cache_ack_r)
 8        arbiter2cache_ack_r <=arbiter2cache_ack_r;
 9     else
10        arbiter2cache_ack_r <=1‘b0;
11 end
12
13 always@(posedge spi_clk or negedge spiclk_rst_n)
14  begin
15     if(~spiclk_rst_n)
16        arbiter2mcu_ack_r <=1‘b0;
17     else if(cache_req_sclk && flash_idle && ~atom_op_en_sync2 && ~arbiter2mcu_ack_r)
18     arbiter2mcu_ack_r <=arbiter2mcu_ack_r;
19      else if(mcu_req_arb && flash_idle && ~arbiter2cache_ack_r)
20         arbiter2mcu_ack_r <=1‘b1;
21      else
22         arbiter2mcu_ack_r <=1‘b0;
23 end

两个always语句块实现了三条功能:

1.cache/mcu请求如果,mcu请求已经访问flash,则cache请求不能break该访问,只能等待此次访问结束才会响应cache的访问。cache先请求也同理。两个always语句参考对比看,不要只看一个。

2.cache/mcu请求若同时有效,则cache请求的优先级高于MCU的请求。主要利用ifelse语句的优先级实现的。第6行代码优先级高于第20行代码。

3.如果atom_op_en_sysn2有效,只响应MCU的请求。

4.注意本模块处于sclk时钟域。但输入处于hclk时钟域。通过这两个always看不出来,呵呵。

时间: 2024-10-12 14:11:23

fshc之请求仲裁机制的代码分析的相关文章

Linux -- 内存控制之oom killer机制及代码分析

近期,线上一些内存占用比較敏感的应用.在訪问峰值的时候,偶尔会被kill掉,导致服务重新启动.发现是Linux的out-of-memory kiiler的机制触发的. http://linux-mm.org/OOM_Killer oom kiiler会在内存紧张的时候,会依次kill内存占用较高的进程,发送Signal 15(SIGTERM).并在/var/log/message中进行记录.里面会记录一些如pid,process name.cpu mask,trace等信息,通过监控能够发现类似

DataNode与NameNode交互机制相关代码分析

HDFS Federation是为解决HDFS单点故障而提出的NameNode水平扩展方案,该方案允许HDFS创建多个Namespace以提高集群的扩展性和隔离性.在Federation中新增了block-pool的概念,block-pool就是属于单个Namespace的一组block,每个DataNode为所有的block-pool存储block,可以理解block-pool是一个重新将block划分的逻辑概念,同一个DataNode中可以存储属于多个block-pool的多个block.所

小记--------spark资源调度机制源码分析-----Schedule

Master类位置所在:spark-core_2.11-2.1.0.jar的org.apache.spark.deploy.master下的Master类 /** * driver调度机制原理代码分析Schedule the currently available resources among waiting apps. This method will be called * every time a new app joins or resource availability change

wifi display代码 分析

转自:http://blog.csdn.net/lilian0118/article/details/23168531 这一章中我们来看Wifi Display连接过程的建立,包含P2P的部分和RTSP的部分,首先来大致看一下Wifi Display规范相关的东西. HIDC: Human Interface Device Class  (遵循HID标准的设备类)UIBC: User Input Back Channel  (UIBC分为两种,一种是Generic,包含鼠标.键盘等:另一种是HI

Redis数据持久化机制AOF原理分析二

Redis数据持久化机制AOF原理分析二 分类: Redis 2014-01-12 15:36  737人阅读  评论(0)  收藏  举报 redis AOF rewrite 目录(?)[+] 本文所引用的源码全部来自Redis2.8.2版本. Redis AOF数据持久化机制的实现相关代码是redis.c, redis.h, aof.c, bio.c, rio.c, config.c 在阅读本文之前请先阅读Redis数据持久化机制AOF原理分析之配置详解文章,了解AOF相关参数的解析,文章链

linux kernel的中断子系统之(七):GIC代码分析

一.前言 GIC(Generic Interrupt Controller)是ARM公司提供的一个通用的中断控制器,其architecture specification目前有四个版本,V1-V4(V2最多支持8个ARM core,V3/V4支持更多的ARM core,主要用于ARM64服务器系统结构).目前在ARM官方网站只能下载到Version 2的GIC architecture specification,因此,本文主要描述符合V2规范的GIC硬件及其驱动. 具体GIC硬件的实现形态有两

一个简单的&quot;RPC框架&quot;代码分析

0,服务接口定义---Echo.java /* * 定义了服务器提供的服务类型 */ public interface Echo { public String echo(String string); } 一,客户端代码分析--实现类:MainClient.java 客户端实现包括:获得一个代理对象,并使用该代理对象调用服务器的服务.获取代理对象时,需要指定被代理的类(相当于服务器端提供的服务名),Server IP,Port. Echo echo = RPC.getProxy(Echo.cl

Linux中断 - GIC代码分析

一.前言 GIC(Generic Interrupt Controller)是ARM公司提供的一个通用的中断控制器,其architecture specification目前有四个版本,V1-V4(V2最多支持8个ARM core,V3/V4支持更多的ARM core,主要用于ARM64服务器系统结构).目前在ARM官方网站只能下载到Version 2的GIC architecture specification,因此,本文主要描述符合V2规范的GIC硬件及其驱动. 具体GIC硬件的实现形态有两

2017-2018-2 《网络对抗技术》 20155322 Exp4 恶意代码分析

[-= 博客目录 =-] 1-实践目标 1.1-实践介绍 1.2-实践内容 1.3-实践要求 2-实践过程 2.1-Mac下网络监控 2.2-Windows下网络监控 2.3-Mac下恶意软件分析 2.4-Windows下恶意软件分析 2.5-基础问题回答 3-资料 1-实践目标 1.1-恶意代码分析 一般是对恶意软件做处理,让它不被杀毒软件所检测.也是渗透测试中需要使用到的技术. 要做好免杀,就时清楚杀毒软件(恶意软件检测工具)是如何工作的.AV(Anti-virus)是很大一个产业.其中主要