Verilog蛋疼的地方确实很多，我写的不多，但每次也是写的想砍人的心情。但你这个pyverilog其实改成pyxxxx都可以，生成什么语言都这样写没区别，反正是手动拼接ast树，太蛋疼了...

myhdl才是pythonic的思路。如果不想myhdl这么激进，又不想pyverilog这么蛋疼，其实很多生成html的template engine都是可以用来干这个事情的。这个更糙快猛一点。

对于这类问题我曾经折腾过一个框架，实现两种不同语言的ast树的映射转换，你只需要提供一堆类似正则表达式的规则就行。但这个方法局限性也很大，用起来并没有说的这么简单。

【 在 eggcar 的大作中提到: 】
: 这是pyverilog的demo代码
: [code=py]
: from __future__ import absolute_import
: ...................
--
修改:lvsoft FROM 117.136.67.*
FROM 117.136.67.*

tcl 一切都是字符串， 所以整个程序反而不用引号来标记字符串了。

解释器也好写， 有人用几十行就写了个tcl解释器。

而且所有功能自给自足也没有什么外部依赖（或者说没有生态？），集成也特别方便，自然受一部分人的喜欢了。

【 在 eematlab (一辰未冉) 的大作中提到: 】
: 我真觉得tcl挺好的，语义特别简单， 没那么复杂的语义
: 做为工具内置脚本语言很适合
--
FROM 120.244.224.*

这个离实现verilog的meta programming差远了

而且你看很多情况下这个写的代码量可能比直接写verilog的还多

我觉得功能上过犹不及，keep it simple.

对于大部分要求来说，可能像html/template就能满足绝大多数需求
而且还保留了绝大多数可读性

pyverilog相当于写手好ast, 然后给你遍历出代码。完全缺少实现的优美性

用这个还不如直接用chipsel bluespec之类的语言来写代码

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 你这个再搞搞，是不是可以弄出一个 python 语法的新语言，编译到 verilog 去。
--
修改:eematlab FROM 64.207.220.*
FROM 64.207.220.*

agree，

我前不久基于text/template用golang写了个dft testbench生成器
输入是json格式的PIN information（name/direction/isclock/index)
然后写几个模板， 把这些pin在不同的地方展开
代码可读性非常好， 后期扩展（就是加模板）也方便

这是就一种工程中的折中。 把时间花在理解DFT业务逻辑，写出通用的模板上，比花在折腾ast上更合算


【 在 lvsoft (Lv(The Last Guardian)) 的大作中提到: 】
: Verilog蛋疼的地方确实很多，我写的不多，但每次也是写的想砍人的心情。但你这个pyverilog其实改成pyxxxx都可以，生成什么语言都这样写没区别，反正是手动拼接ast树，太蛋疼了...
: myhdl才是pythonic的思路。如果不想myhdl这么激进，又不想pyverilog这么蛋疼，其实很多生成html的template engine都是可以用来干这个事情的。这个更糙快猛一点。
: 对于这类问题我曾经折腾过一个框架，实现两种不同语言的ast树的映射转换，你只需要提供一堆类似正则表达式的规则就行。但这个方法局限性也很大，用起来并没有说的这么简单。
--
FROM 64.207.220.*

营销是异常重要的。  
  
【 在 javaboy () 的大作中提到: 】
: 是的。
:
: tcl的语法和bash/m4等等接近（同时代的产品），但是质量不知道甩bash几条街了。而且文档写得也极好。很可惜这个没成为默认shell。
:
--
FROM 203.145.95.*