Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Asking for help about extending MEM_W to 64 bit #90

Closed
Mousavikia opened this issue Jul 3, 2022 · 1 comment
Closed

Asking for help about extending MEM_W to 64 bit #90

Mousavikia opened this issue Jul 3, 2022 · 1 comment
Labels
duplicate This issue or pull request already exists

Comments

@Mousavikia
Copy link

Hi @michael-platzer , @stevobailey , @kuoyaoming93 , @moimfeld
I tried to add a config to config.mk file but in spite of the @michael-platzer help, I couldn't get the result when implementing on FPGA. The whole problem and his answers are in https://github.com/vproc/vicuna/issues/78.
Config:

ifeq ($(VPROC_CONFIG), newconfig)
  VMEM_W          := 64
  VREG_W          ?= 128
  VPROC_PIPELINES ?= $(VMEM_W):VLSU $(shell echo $$(($(VREG_W) / 2))):VALU,VELEM                  \
                                    $(shell echo $$(($(VREG_W) / 2))):VMUL,VSLD

I also tried to simulate the issue via Verilator or Vivado simulator but I couldn't find the problem. The problem is when I change the VMEM_W to 64 or any other number except 32, if I don't want to use instruction or data cache I have to make MEM_W to 64 as well. I changed the SRAM and hwreg_iface implementation as @michael-platzer said in https://github.com/vproc/vicuna/issues/78 but when I simulate it using Vivado simulator the vproc_top just requests 0,4,8,C addresses and in console of Vivado I see illegal instruction being printed out. I completely understand the advices that @michael-platzer mentioned for me but I couldn't solve this problem and I am running out of time. I even added the caches so that I don't have to make MEM_W to 64-bit but again it is not working. If any of you can suggest a solution for this I will be very thankful. I do all these tests to get a better delay for my written codes since they are memory bound as @michael-platzer mentioned in issues and also provided in the documentation. Also, I should mention the tested codes are working in all of the configs in config.mk file.

@michael-platzer michael-platzer added the duplicate This issue or pull request already exists label Jul 4, 2022
@michael-platzer
Copy link
Contributor

Hi @Mousavikia, as you state yourself, there is already another issue for this problem. The discussion should be kept in #78. There is no need for a separate thread.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

2 participants