verticalresearchgroup / miaow Goto Github PK

In the reg_256x32b_3r_1w_fpga.v the "web" port in all three banks is assigned with "4'd0" where the port input is only 1bit wide. The value should be changed to "1'd0". This bug prevents Vivado Simulator from opening.

FPGA / ASIC Constraints file is an important add to facilitate the synthesis and implementation. To the original developers I request this detail.

Best
Mangesh

On the Architecture page, I've noticed that there are no descriptions of a VALU. I think it is used in the project, and it may be helpful in the document.

setVregValue function in wave.c:714 is assuming that the vgpr still possesses its internal 4-banked scheme for each of its 64 pages. This is no longer the case and I'm pretty sure it's causing the VGPR to be improperly filled before a test is run, resulting in improperly failed unit tests for vector instructions.

In the compute_unit_fpga.v file the reset input in modules vgpr (line 335), simd (line 1004) and simf (line 1058) are connected to the nonexistent wire "rst". The correct wire is "rst_signal".
This bug is preventing vector instructions from running.

maybe we are waiting for vulkan?

Is this project dead by any chance? If so is there a fork of this project or something?

I noticed twos_compliment* RTL signals when clearly you meant twos_complement.

On https://github.com/VerticalResearchGroup/miaow/wiki/Bringup-and-Verification, it says that synthesis scripts and supporting documentation were forthcoming in October, 2014.

Is this still planned? And if so, is anything tentatively available (perhaps not working and without documentation) in the meantime?

In the compute_unit_fpga.v file the "resultsReadyTag_in" output and the "gprCommand" register are left unconnected.

Hi
I need the area report of MIAOW. Does anybody synthesis it? Does anybody have it?

The issue unit tracks memory operations by examining the operation complete signals the sgpr and vgpr sends to the lsu. In the past when the lsu was able to perform a single register operation for each load and store this worked. Now however the lsu needs to perform multiple such operations for each memory operation. As a consequence the issue unit is prematurely advancing the program instead of waiting for the lsu to actually complete an operation. How it tracks memory operations needs to be revamped.

Hi there,

Not sure if I am missing something, but I followed the Bringup and Verification wiki and seem to be failing the 3xx unit tests and the benchmark tests.
Specifically:
test_300_tbuff_ld_fmt_x test_301_tbuff_ld_fmt_xyzw test_302_tbuff_st_fmt_x test_303_tbuff_st_fmt_xyzw test_304_ds_wr_b32 test_305_ds_rd_b32
The values are either wrong, or in the latter cases, the test hangs. The MTBUF and GDS instructions seem to be the culprits.

Any advice on what I could be doing wrong? Thanks!

Polaris is the name for the upcoming GCN 2.0 *

Hello, I think that you should consider to use this language for designing miaow.

https://github.com/ucb-bar/chisel/

Right now changes to the register space for the AXI interface requires repackaging of the IP core. This really should not be necessary and is a pain to redo. As such I am going to create a pass through axi interconnect that breaks out all of the AXI related ports. This should make the entire thing generate once and all further changes will be done in the actual neko project instead of the IP core.