Question

所以我的问题源于我认为我非常聪明并尝试在Golang中建模硬件。是的，将它用于我在Verilog写的日常工作中的那种东西。

首先，我尝试做最简单的硬件管道。即将数据推送到Reg阶段的数据源，该阶段将其推送到下一个将其推送到接收阶段的Reg。事情只能在时间上推进。问题是事件经理似乎对我有这个。从时钟发送的数据开始

  select {
    case out_chan <- tmp:
      front_chan = saved_front_chan
      out_chan = nil
      fmt.Println("Sent Data, ", tmp, name)
    default:
      c.ckwg.Done() // Send failed so remove token
      if out_chan != nil {
        log.Fatal("Stalled, Can't send ", tmp, name)
       } else {
        fmt.Println("Nothing to send ", name)
      }
    }

即。如果我们可以发送数据，那么，如果我们不能那么好;但如果我们无法发送数据，那么前端接收器（请参阅主代码）不会重新启用接收。这是发送到一个更简单的前端

for itm := range in_chan {
        c.ckwg.Done()
        fmt.Println("Front Channel received", itm, name)
        saved_front_chan <- itm
    }

请注意使用sync.WaitGroup以确保在时钟评估阶段结束之前运行此代码。到现在为止还挺好。问题是有时这些前端中的一个将成功地＆＃34; saved_front_chan＆lt; - itm＆＃34;但是不会回过头去听in_chan。

这意味着管道中的前一阶段会认为它已经停滞不前。现在，这在数据处理管道中会很好，但是对于那些尝试对硬件进行某种程度精确建模的事情，它并非如此。（对于这个测试用例，我建模了一个试图支持摊位但不需要停顿的管道，所以没有）据我所知，虽然我没有任何技巧来强制调度程序让循环准备好阅读。从根本上说，我需要知道因为管道背压而导致渠道无法收到的差异＆＃34;并且＆＃34;频道无法接收，因为调度程序还没有接触到该例程。＆＃34;

所以完整代码在这里：

https://github.com/cbehopkins/cbhdl/blob/master/pipe_test.go

对于上下文，我实际上试图满足的规范是仅在时钟脉冲上提前数据的阶段，并且该时钟脉冲被提供给所有阶段＆＃34;同时＆＃34;。是的，我知道没有什么是真正的并行，但我试图伪造这种行为。具体而言，必须出现在时钟阶段开始时对输入进行采样，然后在时钟阶段结束时输出数据。最重要的是在并行性的伪造中，reg阶段接收其时钟脉冲的顺序无关紧要。我还试验过流量控制不是通过golang通道背压来完成的，而是通过一个单独的令牌系统来完成 - 但是这种情况非常复杂且容易出错。

FWIW我有另一个试用版本，其中时钟脉冲的广播使用同步包广播结构完成 - 但该代码阻碍了我所遇到的问题。

提前致谢。

Golang事件模型

0 个答案: