NIC400生成Flow全解析(八)Micro Architechture

当所有配置完成后,就可以生成Micro Architechture了。在Micro Architechture中也会进行一系列配置。比如微架构、timing closure、buffering等配置。
生成Micro Architechture的方法如下:

在这里插入图片描述


生成时需要解决掉所有报错问题后,即可打开Micro Architechture。打开方式如下:

在这里插入图片描述


大致界面如下:

在这里插入图片描述

其中主要包含了如下元素:

  • Micro Architechture窗口
  • Parameter/Timing Closure/Buffering窗口
  • Overlays窗口

1.Micro Architechture窗口

该窗口主要是设定需要的互联微架构,AMBA Designer生成NIC-400时需要手动定义,Socrates生成NIC-400时会根据工具内部算法生成一个微架构。生成后也可以根据自己的需求进行调整。图中的各种标志如下所示:

在这里插入图片描述


Micro Architechture的左边有一排按键,11个按键的含义从上到下依次为:

  • Zoom in:视图放大
  • Zoom out:视图放小
  • Zoom fix:最佳视图
  • Creat Group:创建Group。比如想在两个接口之间,或一个BusMatrix和一个ASIB或AMIB之间连接,则可以选中目标后点击Group
  • Connect:连接不同的组件。
  • Delete:删除组件。
  • Create IB:创建IB,在不同的BusMatrix之间连接时通常会自动创建
  • Create GPV:创建GPV
  • Create Default slave:创建Default slave
  • Optimize Switch:优化BusMatrix结构,丢弃不存在的Path
  • Layout:重新排列视图,使Micro Architechture美观

我们可以自定义微架构,比如想让CPU访问SRAM和FLASH的延时尽可能小,就可以使CPU和FLASH ,SRAM之间只经过一级BusMatrix。自定流程如下:

分别选中2个switch执行Optimize Switch优化不必要的结构,最后点击Layout则可呈现比较规则的Micro Architechture。

在这里插入图片描述

同理,cpu也要访问其他如timer,uart的外设,因此按"Ctrl"先选中switch5再选中switch4,然后点击”Connect“:

在这里插入图片描述


直到Micro Architechture上没有黄色虚线,才表示苏哦有的互联关系都有了实际的电路访问。

由于dma也需要访问flash和sram,因此这里让switch4和switch5之间连接,也就是说,如果DMA想访问flash的话,需要先经过switch5,再经过switch4。按"Ctrl"先选中switch4再选中switch5,然后点击”Connect“:

在这里插入图片描述

按"Ctrl"选中dma、mcu_mstr、APB Group(uart+timer)、ahb_sub、mcu_slv,然后点击”Group“,让其通过1个Bus Matrix互联。

在这里插入图片描述

按"Ctrl"选中cpu、flash、sramc,然后点击”Group“,让其通过1个Bus Matrix互联。

在这里插入图片描述

删除所有生成好的组件,ASIB和AMIB之间以”黄色虚线“连接。此时只是一种虚拟的映射关系,无实际的连接关系。

在这里插入图片描述

Read more

彻底掀翻前端桌子!2026年HTML最被严重低估的神仙功能,直接干废一票JS组件库!

就在上周一,我还在为了一个破下拉菜单,死磕着整整 150 行 JavaScript 代码。这破玩意儿不仅要管展开、收起,还得处理焦点管理和无障碍访问(Accessibility)。更别提那无穷无尽、让人崩溃的 z-index 层级大战了;移动端上按 ESC 键退出的逻辑直接罢工;至于那个“点击空白处自动关闭”的屎山代码,更是让我连吐槽的力气都没有了。 就在我快要砸键盘的时候,我猛然醒悟:Popover API 已经在 2025 年 4 月达成了 Baseline Widely Available(基线广泛可用) 状态!这意味着,它现在已经在 Chrome、Firefox、Safari 和 Edge 里实现了完美的跨浏览器支持。于是,我直接把那个恶心的组件彻底推翻,只用了区区 8 行纯 HTML

前端微前端:别让你的应用变成巨石应用

前端微前端:别让你的应用变成巨石应用 毒舌时刻 这应用做得跟巨石似的,想改个功能都得动全身。 各位前端同行,咱们今天聊聊前端微前端。别告诉我你还在维护一个巨大的单体应用,那感觉就像在没有分区的大房子里生活——能住,但乱得要命。 为什么你需要微前端 最近看到一个项目,代码量超过 100 万行,构建时间超过 10 分钟,团队协作困难。我就想问:你是在做应用还是在做代码仓库? 反面教材 // 反面教材:单体应用 // App.jsx import React from 'react'; import Header from './components/Header'; import Sidebar from './components/Sidebar'; import Dashboard from

Clawdbot整合Qwen3-32B保姆级教程:Web网关18789端口调试全记录

Clawdbot整合Qwen3-32B保姆级教程:Web网关18789端口调试全记录 1. 为什么需要这个整合方案 你是不是也遇到过这样的问题:想用本地部署的大模型做聊天机器人,但发现直接调用Ollama的API在Web前端里跨域报错?或者Clawdbot配置完后一直连不上模型,控制台疯狂刷404?又或者好不容易跑起来了,发个消息却卡在“正在思考”半天没反应? 这正是我们搭建这套环境时踩过的坑。Clawdbot本身不直接对接Ollama,它需要一个中间层来处理协议转换、请求转发和端口映射。而18789这个端口,就是整个链路里最关键的“通关密码”——它不是随便选的,而是Clawdbot默认监听的Web网关入口。 整套方案的核心逻辑其实很朴素: * 你在浏览器里访问 http://localhost:18789,看到的是Clawdbot的聊天界面 * Clawdbot收到你的消息后,不自己去算答案,而是把请求转给内部代理 * 代理再把请求发到 http://localhost:8080(Ollama API地址) * Ollama调用本地的Qwen3-32B模型生成回复

Z-Image-Turbo输出格式限制:PNG转JPG/WEBP后处理方案

Z-Image-Turbo输出格式限制:PNG转JPG/WEBP后处理方案 你是不是也遇到过这样的烦恼?用Z-Image-Turbo生成了一张特别满意的图片,想分享到社交媒体或者用在网页上,结果发现文件太大了——一张1024×1024的PNG图片,动不动就几兆甚至十几兆,加载慢不说,还特别占存储空间。 更让人头疼的是,很多平台对上传的图片格式和大小都有严格限制。微信朋友圈上传大图会压缩得惨不忍睹,网站上传大文件又慢又容易失败。难道每次生成完图片,还得手动用Photoshop或者在线工具转换格式、压缩大小吗? 今天我就来分享一个简单实用的解决方案:为Z-Image-Turbo添加自动后处理功能,让生成的PNG图片自动转换成更轻量的JPG或WEBP格式,还能智能压缩,保持画质的同时大幅减小文件体积。 1. 为什么需要后处理转换? 1.1 PNG格式的优缺点 先说说Z-Image-Turbo默认输出的PNG格式。PNG是个好格式,它支持透明背景,采用无损压缩,画质保持得非常好。但问题也在这里: * 文件体积大:同样一张1024×1024的图片,PNG格式可能5-10MB,而