eugene-tarassov / vivado-risc-v

Xilinx Vivado block designs for FPGA RISC-V SoC running Debian Linux distro
820 stars 186 forks source link

VC 707 Flash Module is Broken #119

Closed gnodipac886 closed 1 year ago

gnodipac886 commented 1 year ago

Hi all,

My flash memory chip on my vc 707 is faulty, and does not even pass the BIST test. Is there a way of bypassing the flash stage and just program the bit stream via the jtag?

Thanks :)

eugene-tarassov commented 1 year ago

Yes. Vivado, Vitis and XSDB all have commands to program bitstream via JTAG. For example, in XSDB:

connect
fpga workspace/rocket64b2/vivado-vc707-riscv/vc707-riscv.runs/impl_1/riscv_wrapper.bit
gnodipac886 commented 1 year ago

@eugene-tarassov I would also like to ask whether ethernet support for VC707 already? I see the ethernet files under boards/vc707 but when I boot it up and plug in the ethernet cord, and I do ifconfig, I only get localhost 127.0.0.1

gnodipac886 commented 1 year ago

currently ip addr show shows:


1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:0a:35:00:00:00 brd ff:ff:ff:ff:ff:ff
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0```
eugene-tarassov commented 1 year ago

Yes, Ethernet works on VC707.

gnodipac886 commented 1 year ago

@eugene-tarassov Looking at the Rocket64b2gem config, it seems like WithGemmini(2, 64) means that the mesh size is 2x2 right, aka there are a total of 4 elements in the systolic array? This means that running gemmini code on linux, we should also config it DIM=2 right?

Is this because the PEs aren't synthesized optimally? We should definitely look into this...

I was able to solve the ethernet issue by running ifup eth0 Seems like it wasn't on by default

cheers

eugene-tarassov commented 1 year ago

the mesh size is 2x2 right, aka there are a total of 4 elements in the systolic array?

Yes

This means that running gemmini code on linux, we should also config it DIM=2 right?

I don't know about the code. I would expect it to read Gemmini configuration from a register.

Is this because the PEs aren't synthesized optimally?

Right, they are not synthesized optimally, use a lot of LUTs. Bigger mesh would not fit into FPGA. At least, it used to be the case. I have not tried bigger mesh with the latest Gemmini source.

I was able to solve the ethernet issue by running ifup eth0 Seems like it wasn't on by default

Ethernet is on by default. But it can, for example, timeout trying to obtain DHCP lease from network and stay down after that. For me it works fine.

gnodipac886 commented 1 year ago

Happy Thanksgiving!

Right, they are not synthesized optimally, use a lot of LUTs. Bigger mesh would not fit into FPGA. At least, it used to be the case. I have not tried bigger mesh with the latest Gemmini source.

I wrote the processing element (PE) in verilog and now I can generate a 4x4 one :) however, I still can't generate a 8x8 one due to lack of resources. In the image below, you can see that its actually the scratch pad that is consuming the most LUTs. VC707 has a total of around 300K LUTs

Would it be possible if we tried to infer block ram? I'm not sure how that would work. It seems like Chisel really generates inefficient verilog code -.-

image
eugene-tarassov commented 1 year ago

scratch pad ... is consuming the most LUTs

This is not normal, and I cannot reproduce. The scratch pad uses block RAM and looks fine when I try to build Rocket64b2gem:

spad

gnodipac886 commented 1 year ago

This is not normal, and I cannot reproduce. The scratch pad uses block RAM and looks fine when I try to build Rocket64b2gem:

*Also please see side note on the bottom

I think I found the issue. I was wondering if you can help me find a fix for this repo? The bug resides in how sram.v is generated. The following code is for a 16x16 gemmini config In the repo, the mem is generated by declaring a single register cluster "ram" as such

module mem_0_ext_16(
  input W0_clk,
  input [8:0] W0_addr,
  input W0_en,
  input [511:0] W0_data,
  input [63:0] W0_mask,
  input R0_clk,
  input [8:0] R0_addr,
  input R0_en,
  output [511:0] R0_data
);

  reg reg_R0_ren;
  reg [8:0] reg_R0_addr;
  reg [511:0] ram [511:0]; // <---------------------- like this
  ...

while the mem that gemmini would generate using their build_vcs.sh script under gemmini/scripts generates several chunk of split_mem as follows:

module mem_0_ext(
  input  [8:0]   W0_addr,
  input          W0_clk,
  input  [511:0] W0_data,
  input          W0_en,
  input  [63:0]  W0_mask,
  input  [8:0]   R0_addr,
  input          R0_clk,
  output [511:0] R0_data,
  input          R0_en
);
...
split_mem_0_ext mem_0_0 ( // <-------------- like this
    .W0_addr(mem_0_0_W0_addr),
    .W0_clk(mem_0_0_W0_clk),
    .W0_data(mem_0_0_W0_data),
    .W0_en(mem_0_0_W0_en),
    .W0_mask(mem_0_0_W0_mask),
    .R0_addr(mem_0_0_R0_addr),
    .R0_clk(mem_0_0_R0_clk),
    .R0_data(mem_0_0_R0_data),
    .R0_en(mem_0_0_R0_en)
  );
...
  split_mem_0_ext mem_0_63 (
    .W0_addr(mem_0_63_W0_addr),
    .W0_clk(mem_0_63_W0_clk),
    .W0_data(mem_0_63_W0_data),
    .W0_en(mem_0_63_W0_en),
    .W0_mask(mem_0_63_W0_mask),
    .R0_addr(mem_0_63_R0_addr),
    .R0_clk(mem_0_63_R0_clk),
    .R0_data(mem_0_63_R0_data),
    .R0_en(mem_0_63_R0_en)
  );
...

Using this split mem design, BRAM was inferred successfully and now the 16x16 gemmini deisgn looks like this screenshot

I have also attached the files to the different sram files as well (had to do .txt since github doesn't do .v files...) sram_16_from_repo.txt sram_gemmini_generated.txt

*sidenote Do you happen to know if it's possible to swap the dram on these fpga boards? VC707 has a 1GB stick and I would like to replace to 8GB. When I swap them, linux wouldn't boot properly. Is there something that needs to be configured with the OS or the FPGA design?

eugene-tarassov commented 1 year ago

Using this split mem design, BRAM was inferred successfully...

Interesting. I will investigate.

Do you happen to know if it's possible to swap the dram on these fpga boards?

I believe it is possible. To make it work, you need changes in the FPGA design:

  1. Use Rocket Chip configuration with at least 34-bit memory address bus. By default, it is 32-bit, not enough to address 8GB. You need to add new WithExtMemSize(0x200000000L) ++, see Rocket64b2m config as example.
  2. Rebuild the project with MEMORY_SIZE argument make MEMORY_SIZE=0x200000000 BOARD=vc707 ....
  3. In Vivado block design, re-configure DDR3 controller for the new memory module.
gnodipac886 commented 1 year ago

Interesting. I will investigate.

After some initial investigation, there are some timing issues when I build with split_mem... Will report back though

I also built Gemmini on VCS with 2x2 configuration, same as this project, and running basic examples doesn't seem to work even in VCS simulation. Most likely due to the small sys array size. I think it first starts working at 8x8 or 16x16. If we can get the split_mem to work, we don't need to worry about this :)

gnodipac886 commented 1 year ago

3. In Vivado block design, re-configure DDR3 controller for the new memory module.

A bit confused as to how this step works, could you point me to the right direction? Thank you!

eugene-tarassov commented 1 year ago

In Vivado, click Open Block Design, double click DDR block in the diagram, double click mig_7series_0 - it will open re-configuration dialog box. Look through pages of the dialog box, there is Memory Part selection.

gnodipac886 commented 1 year ago

In Vivado, click Open Block Design, double click DDR block in the diagram, double click mig_7series_0 - it will open re-configuration dialog box. Look through pages of the dialog box, there is Memory Part selection.

That almost worked, it seems like it is write locked somehow? It can only be generated by the parent project? See error message below.

How's the BRAM going? I'd be happy to help you out!

screenshot

eugene-tarassov commented 1 year ago

That almost worked, it seems like it is write locked somehow?

It looks like a glitch in Vivado.

have directly edited riscv-2021.1.tcl ...

Yes, eventually you have to edit the Tcl file. But I would use Vivado GUI to validate and test the changes before editing the file.

How's the BRAM going?

I tried all kind of tests, and Vivado appears to fail to infer block RAM when a write mask is used. It looks like a bug in Vivado. I modified the script to split RAM to slices along write mask. It works much better. I will commit after some more testing.

gnodipac886 commented 1 year ago

I tried all kind of tests, and Vivado appears to fail to infer block RAM when a write mask is used. It looks like a bug in Vivado. I modified the script to split RAM to slices along write mask. It works much better. I will commit after some more testing.

Would it be possible to have your current updates on a separate branch? I have a project report tomorrow and would love to have some results here :)

Also Gemmini has had a version bump to 0.7.0, could be worth while investigating. In their commit message, they claim to have power and area reductions.

Lastly, I have added a blackbox PE design using SystemVerilog in my fork of gemmini. The SV design is here. It should have significant area savings. Chisel synthesized 700+ LUTs while my design only takes around 325 LUTs. In order to include the design in the build you need to add the file in vivado.tcl which I have here in my fork of your repo.

Gemmini's original PE unit might have synthesized 2 MAC units (didn't check, just guessing) in one PE unit while mine uses just 1. Using my MAC unit, I was able to synthesize a 16x16 design (though with timing issues caused by spad which you will likely fix in your update). I cannot synthesize(vivado implement) a 16x16 design with their original design (309K+ LUTs).

Could you test with these? Or if you add the updates I can try testing them with my design :)

Cheers mate

eugene-tarassov commented 1 year ago

Would it be possible to have your current updates on a separate branch?

The tests are running OK so far, so I have committed the changes to the master branch. I test RocketChip itself, I don't run Gemmini functional tests, only check that it builds. 8x8 looks OK, 16x16 is about 15K LUTs bigger than VC707 FPGA size. I'll check the latest Gemmini version and your fork.

gnodipac886 commented 1 year ago

I'll check the latest Gemmini version and your fork.

I just fixed my fork of Gemmini, originally the pushed version was using the original PE design.

gnodipac886 commented 1 year ago

8x8 looks OK, 16x16 is about 15K LUTs bigger than VC707 FPGA size.

I just synthesized a 16x16 one with your newest update with my MAC unit and still getting timinig issues. screenshot Were you able to compile without timing issues? I will try to make a 8x8 one and see if there are timing issues.

eugene-tarassov commented 1 year ago

Max clock frequency of Gemmini is rather low, about 30MHz. The Makefile selects clock frequency from this table board/rocket-freq, but your configuration name Rocket64b2gem_custom does not have an entry in the table, so it uses default 100MHz - too high for Gemmini.

You can change the frequency without re-creating the project - double-click Clocking Wizard in the Block Design diagram.

gnodipac886 commented 1 year ago

You can change the frequency without re-creating the project - double-click Clocking Wizard in the Block Design diagram.

Thank you for this info, will be reporting back

One more thing, I tried to add 8gb ram in the design by changing the tcl file, but I'm getting a complaint that says with current design I can only achieve 400Mhz clock which is not enough for the 8gb stick which needs a min of 800Mhz. It tells me to change the parameters etc. Do you know where I should look into?

Thanks for all this help by the way, really appreciate it! :)

eugene-tarassov commented 1 year ago

I tried to add 8gb ram ... It tells me to change the parameters etc. Do you know where I should look into?

No, I don't know. A common way to change the parameters is to use Memory Interface Generator dialog box. If it does not works, it becomes complicated.

gnodipac886 commented 1 year ago

No, I don't know. A common way to change the parameters is to use Memory Interface Generator dialog box. If it does not works, it becomes complicated.

Currently, I have 8gb working on a standalone MIG build and I can see via ILA that it is reading correctly. This is based off the vc707 mig example on Xilinx website. However, I can't reproduce it on this project, so I was wondering where I should add an ILA to monitor traffic in this project? (the AXI bus or the DDR output pins?)

Yes, Ethernet works on VC707.

I realized that my debian images has been booting in emergency mode which could be the cause of ethernet being down on boot (ssh also disabled). Have you ever ran into an issue like this? These lines from the boot process seem to indicate some error with the file system, but I can't seem to pinpoint it.

Warning: fsck not present, so skipping root file system
[  238.955928] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[  238.963892] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[  252.174824] EXT4-fs (mmcblk0p2): recovery complete
[  252.208248] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Quota mode: disabled.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... Failed to send exit request: Resource temporarily unavailable
done.

The debian image I've been using was originally built from mk-sd-image, then I booted this image using qemu to install the dependencies faster. I think this method is much faster than installing everything on the board. Could we add such a flow to this project? It would be very nice to have!

eugene-tarassov commented 1 year ago

I have 8gb working on a standalone MIG build

8GB DDR3 SODIMM is dual rank module. I found that support of dual rank memory was disabled in the Memory Interface Generator for VC707, because the board design does not meet timing requirements of dual rank SODIMM. I'm testing changes to support 4GB single rank modules. It looks OK so far.

I realized that my debian images has been booting in emergency mode

I reproduced it using slow RISC-V config, 1 core at 50MHz. The problem is caused by udev daemon taking very long time to start, about 50min. systemd hits multiple timeouts, and OS falls into emergency mode. This used to work, and it works OK on faster configs. It looks like a bug in the latest Linux code, in either udev or kernel. As a workaround, I changed systemd timeouts to 2 hours, it works OK, but takes over 1 hour to boot. This is not normal. I'm not sure how to fix it yet.

qemu to install the dependencies faster

If you post details on how you boot qemu, I will add this flow to the project. I mostly use 64b2 100MHz config, it is pretty fast, so installing packages is not a problem.

gnodipac886 commented 1 year ago

8GB DDR3 SODIMM is dual rank module. I found that support of dual rank memory was disabled in the Memory Interface Generator for VC707, because the board design does not meet timing requirements of dual rank SODIMM.

Hmm, interesting, I tried to bypass that issue by using a clock of 400Mhz like the following picture dram_config

This is the waveform that I get waveform

Could you try with the following config in the attached file? MIG.tar.gz

If you post details on how you boot qemu, I will add this flow to the project.

I can make a pull request in a bit with a readme and everything :) EDIT pull request created #121

This is not normal. I'm not sure how to fix it yet.

Do you know a commit number that works?

As a workaround, I changed systemd timeouts to 2 hours

Where did you change this? Sorry I'm a bit inexperienced in this area.

eugene-tarassov commented 1 year ago

I tried to bypass that issue by using a clock of 400Mhz like the following picture

Yes, this looks like a valid workaround. I've got 4GB module working OK, but I had to make changes in SD card controller to support DMA address >32-bit. Linux would not boot without this changes, wait until I commit it.

I can make a pull request

Merged

Do you know a commit number that works?

Not yet.

Where did you change this?

sed -i 's/.*DefaultTimeoutStartSec=[0-9]*s/DefaultTimeoutStartSec=5000s/g' /etc/systemd/system.conf
sed -i 's/.*DefaultTimeoutStopSec=[0-9]*s/DefaultTimeoutStopSec=5000s/g' /etc/systemd/system.conf
sed -i 's/.*DefaultDeviceTimeoutSec=[0-9]*s/DefaultDeviceTimeoutSec=5000s/g' /etc/systemd/system.conf
sed -i 's/.*DefaultTimeoutStartSec=[0-9]*s/DefaultTimeoutStartSec=5000s/g' /etc/systemd/user.conf
sed -i 's/.*DefaultTimeoutStopSec=[0-9]*s/DefaultTimeoutStopSec=5000s/g' /etc/systemd/user.conf
sed -i 's/then udevadm settle.*; fi/then udevadm settle --timeout=5000; fi/g' /usr/lib/systemd/system/ifupdown-pre.service
sed -i 's/.*TimeoutSec=[0-9]*/TimeoutSec=6000/g' /usr/lib/systemd/system/ifupdown-pre.service
sed -i 's/udevadm settle.*/udevadm settle --timeout=5000/g' /usr/lib/systemd/system/systemd-udev-settle.service
sed -i 's/.*TimeoutSec=[0-9]*/TimeoutSec=5000/g' /usr/lib/systemd/system/systemd-udev-settle.service
sed -i 's/.*WAIT_ONLINE_TIMEOUT=.*/WAIT_ONLINE_TIMEOUT=5000/g' /etc/default/networking
sed -i 's/LOGIN_TIMEOUT[ \t]*[0-9]*/LOGIN_TIMEOUT 5000/g' /etc/login.defs
gnodipac886 commented 1 year ago

Merged

I added another PR #122 to add QEMU to the README section

Linux would not boot without this changes, wait until I commit it.

Please let me know when this happens :), it will be very useful!

eugene-tarassov commented 1 year ago

I have committed changes to support larger memory modules on VC707 and KC705 boards. For example, VC707 with 8GB SODIMM:

make BOARD=vc707 MEMORY_SIZE=0x200000000 CONFIG=rocket64b2 bitstream

I looked into slow boot problem. It is caused by newer version of systemd package in the Debian rootfs. Debian upgraded the package from 250.4 to 252.2. With a faster RISC-V config, Linux used to boot in 3min, now it takes 8min. With a slower CPU it takes about 1hour. The list of changes between systemd versions is huge. I don't know which one is causing problems.

gnodipac886 commented 1 year ago

I have committed changes to support larger memory modules on VC707 and KC705 boards. For example, VC707 with 8GB SODIMM:

Thank you for this, however when I am running the above command, I am running into the following issue:

ERROR: [DRC REQP-83] IDATAIN_connected: riscv_i/DDR/mig_7series_0/u_riscv_mig_7series_0_0_mig/u_memc_ui_top_axi/mem_intfc0/ddr_phy_top0/u_ddr_mc_phy_wrapper/u_ddr_mc_phy/ddr_phy_4lanes_2.u_ddr_phy_4lanes/ddr_byte_lane_B.ddr_byte_lane_B/ddr_byte_group_io/input_[6].iserdes_dq_.idelay_dq.idelaye2: For DELAY_SRC IDATAIN programming the IDATAIN input pin of IDELAYE2 must be connected.
ERROR: [DRC RTSTAT-2] Partially routed nets: 3 net(s) are partially routed. The problem bus(es) and/or net(s) are riscv_i/DDR/mig_7series_0/u_riscv_mig_7series_0_0_mig/u_memc_ui_top_axi/mem_intfc0/ddr_phy_top0/u_ddr_mc_phy_wrapper/u_ddr_mc_phy/ddr_phy_4lanes_2.u_ddr_phy_4lanes/ddr_byte_lane_B.ddr_byte_lane_B/iserdes_clkdiv, riscv_i/DDR/mig_7series_0/u_riscv_mig_7series_0_0_mig/u_memc_ui_top_axi/mem_intfc0/ddr_phy_top0/u_ddr_mc_phy_wrapper/u_ddr_mc_phy/ddr_phy_4lanes_2.u_ddr_phy_4lanes/ddr_byte_lane_B.ddr_byte_lane_B/oserdes_clk, and riscv_i/DDR/mig_7series_0/u_riscv_mig_7series_0_0_mig/u_memc_ui_top_axi/mem_intfc0/ddr_phy_top0/u_ddr_mc_phy_wrapper/u_ddr_mc_phy/ddr_phy_4lanes_2.u_ddr_phy_4lanes/ddr_byte_lane_B.ddr_byte_lane_B/phaser_in_gen.phaser_in_0.

Would you happen to have any ideas?

gnodipac886 commented 1 year ago
make BOARD=vc707 MEMORY_SIZE=0x200000000 CONFIG=rocket64b2 bitstream

I got it to build on Vivado fine using this prj file down here: However, now I get

RISC-V 64, Boot ROM V3.5
Cannot read BOOT.ELF: Disk I/O error
.prj file
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<Project NoOfControllers="1">

<!-- IMPORTANT: This is an internal file that has been generated by the MIG software. Any direct editing or changes made to this file may result in unpredictable behavior or data corruption. It is strongly advised that users do not edit the contents of this file. Re-run the MIG GUI with the required settings if any of the options provided below need to be altered. -->

  <ModuleName>riscv_mig_7series_0_0</ModuleName>

  <dci_inouts_inputs>1</dci_inouts_inputs>

  <dci_inputs>1</dci_inputs>

  <Debug_En>OFF</Debug_En>

  <DataDepth_En>1024</DataDepth_En>

  <LowPower_En>ON</LowPower_En>

  <XADC_En>Disabled</XADC_En>

  <TargetFPGA>xc7vx485t-ffg1761/-2</TargetFPGA>

  <Version>4.2</Version>

  <SystemClock>No Buffer</SystemClock>

  <ReferenceClock>Use System Clock</ReferenceClock>

  <SysResetPolarity>ACTIVE HIGH</SysResetPolarity>

  <BankSelectionFlag>FALSE</BankSelectionFlag>

  <InternalVref>0</InternalVref>

  <dci_hr_inouts_inputs>50 Ohms</dci_hr_inouts_inputs>

  <dci_cascade>0</dci_cascade>

  <Controller number="0">
    <MemoryDevice>DDR3_SDRAM/SODIMMs/MT16KTF1G64HZ-1G6</MemoryDevice>
    <TimePeriod>2500</TimePeriod>
    <VccAuxIO>1.8V</VccAuxIO>
    <PHYRatio>4:1</PHYRatio>
    <InputClkFreq>200</InputClkFreq>
    <UIExtraClocks>0</UIExtraClocks>
    <MMCM_VCO>800</MMCM_VCO>
    <MMCMClkOut0> 1.000</MMCMClkOut0>
    <MMCMClkOut1>1</MMCMClkOut1>
    <MMCMClkOut2>1</MMCMClkOut2>
    <MMCMClkOut3>1</MMCMClkOut3>
    <MMCMClkOut4>1</MMCMClkOut4>
    <DataWidth>64</DataWidth>
    <DeepMemory>2</DeepMemory>
    <DataMask>1</DataMask>
    <ECC>Disabled</ECC>
    <Ordering>Normal</Ordering>
    <BankMachineCnt>4</BankMachineCnt>
    <CustomPart>FALSE</CustomPart>
    <NewPartName></NewPartName>
    <RowAddress>16</RowAddress>
    <ColAddress>10</ColAddress>
    <BankAddress>3</BankAddress>
    <MemoryVoltage>1.35V</MemoryVoltage>
    <UserMemoryAddressMap>BANK_ROW_COLUMN</UserMemoryAddressMap>
    <PinSelection>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="B21" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[10]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="B17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[11]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[12]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A21" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[13]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="E17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[14]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="F17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[15]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="B19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[2]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[3]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[4]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[5]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="D20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[6]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C18" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[7]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="D17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[8]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_addr[9]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="D21" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ba[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C21" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ba[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="D18" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ba[2]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="K17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_cas_n"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135" PADName="G18" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ck_n[0]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135" PADName="F19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ck_n[1]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135" PADName="H19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ck_p[0]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135" PADName="G19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ck_p[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="K19" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_cke[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="J18" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_cke[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="J17" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_cs_n[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="J20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_cs_n[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="M13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="K15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="F12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[2]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="A14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[3]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C23" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[4]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="D25" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[5]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C31" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[6]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="F31" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dm[7]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="N14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="H13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[10]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="J13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[11]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="L16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[12]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="L15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[13]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="H14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[14]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="J15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[15]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[16]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[17]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[18]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[19]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="N13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="G13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[20]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="G12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[21]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[22]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="G14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[23]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[24]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="C13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[25]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[26]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[27]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[28]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[29]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="L14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[2]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="C16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[30]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[31]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A24" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[32]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B23" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[33]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B27" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[34]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B26" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[35]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A22" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[36]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B22" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[37]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A25" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[38]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="C24" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[39]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="M14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[3]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E24" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[40]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D23" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[41]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D26" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[42]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="C25" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[43]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E23" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[44]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D22" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[45]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F22" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[46]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E22" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[47]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A30" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[48]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D27" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[49]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="M12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[4]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A29" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[50]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="C28" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[51]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D28" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[52]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="B31" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[53]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A31" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[54]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="A32" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[55]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E30" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[56]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F29" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[57]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F30" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[58]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F27" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[59]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="N15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[5]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="C30" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[60]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="E29" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[61]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="F26" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[62]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="D30" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[63]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="M11" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[6]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="L12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[7]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="K14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[8]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135_T_DCI" PADName="K13" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dq[9]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="M16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[0]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="J12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[1]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="G16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[2]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="C14" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[3]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="A27" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[4]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="E25" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[5]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="B29" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[6]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="E28" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_n[7]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="N16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[0]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="K12" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[1]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="H16" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[2]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="C15" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[3]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="A26" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[4]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="F25" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[5]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="B28" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[6]"/>
      <Pin IN_TERM="" IOSTANDARD="DIFF_SSTL135_T_DCI" PADName="E27" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_dqs_p[7]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="H20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_odt[0]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="H18" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_odt[1]"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="E20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_ras_n"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="C29" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_reset_n"/>
      <Pin IN_TERM="" IOSTANDARD="SSTL135" PADName="F20" SLEW="" VCCAUX_IO="NORMAL" name="ddr3_we_n"/>
    </PinSelection>
    <System_Clock>
      <Pin Bank="38" PADName="E19/E18(CC_P/N)" name="sys_clk_p/n"/>
    </System_Clock>
    <System_Control>
      <Pin Bank="15" PADName="AV40" name="sys_rst"/>
      <Pin Bank="Select Bank" PADName="No connect" name="init_calib_complete"/>
      <Pin Bank="Select Bank" PADName="No connect" name="tg_compare_error"/>
    </System_Control>
    <TimingParameters>
      <Parameters tcke="5" tfaw="30" tras="35" trcd="13.75" trefi="7.8" trfc="260" trp="13.125" trrd="6" trtp="7.5" twtr="7.5"/>
    </TimingParameters>
    <mrBurstLength name="Burst Length">8 - Fixed</mrBurstLength>
    <mrBurstType name="Read Burst Type and Length">Sequential</mrBurstType>
    <mrCasLatency name="CAS Latency">6</mrCasLatency>
    <mrMode name="Mode">Normal</mrMode>
    <mrDllReset name="DLL Reset">No</mrDllReset>
    <mrPdMode name="DLL control for precharge PD">Slow Exit</mrPdMode>
    <emrDllEnable name="DLL Enable">Enable</emrDllEnable>
    <emrOutputDriveStrength name="Output Driver Impedance Control">RZQ/7</emrOutputDriveStrength>
    <emrMirrorSelection name="Address Mirroring">Disable</emrMirrorSelection>
    <emrRTT name="RTT (nominal) - On Die Termination (ODT)">RZQ/6</emrRTT>
    <emrPosted name="Additive Latency (AL)">0</emrPosted>
    <emrOCD name="Write Leveling Enable">Disabled</emrOCD>
    <emrDQS name="TDQS enable">Enabled</emrDQS>
    <emrRDQS name="Qoff">Output Buffer Enabled</emrRDQS>
    <mr2PartialArraySelfRefresh name="Partial-Array Self Refresh">Full Array</mr2PartialArraySelfRefresh>
    <mr2CasWriteLatency name="CAS write latency">5</mr2CasWriteLatency>
    <mr2AutoSelfRefresh name="Auto Self Refresh">Enabled</mr2AutoSelfRefresh>
    <mr2SelfRefreshTempRange name="High Temparature Self Refresh Rate">Normal</mr2SelfRefreshTempRange>
    <mr2RTTWR name="RTT_WR - Dynamic On Die Termination (ODT)">Dynamic ODT off</mr2RTTWR>
    <PortInterface>AXI</PortInterface>
       <AXIParameters>
       <C0_C_RD_WR_ARB_ALGORITHM>RD_PRI_REG</C0_C_RD_WR_ARB_ALGORITHM>
       <C0_S_AXI_ADDR_WIDTH>33</C0_S_AXI_ADDR_WIDTH>
       <C0_S_AXI_DATA_WIDTH>512</C0_S_AXI_DATA_WIDTH>
       <C0_S_AXI_ID_WIDTH>4</C0_S_AXI_ID_WIDTH>
       <C0_S_AXI_SUPPORTS_NARROW_BURST>0</C0_S_AXI_SUPPORTS_NARROW_BURST>
       </AXIParameters>
  </Controller>

</Project>

eugene-tarassov commented 1 year ago

I'm currently testing an updated version of the scripts, using 4GB and 8GB modules, VC707 and KC705 boards - these boards have similar DDR3 SODIMM interfaces. 4GB module works fine on both boards, 8GB works on KC705, but Linux freezes during boot on VC707. I'm still investigating. BTW, your prj file assumes 1.35V power, I think it is incorrect. DDR3 on VC707 is powered by 1.5V.

gnodipac886 commented 1 year ago

these boards have similar DDR3 SODIMM interfaces. 4GB module works fine on both boards, 8GB works on KC705, but Linux freezes during boot on VC707. I'm still investigating

Awesome work! I really appreciate it! Please let me know if are any updates or anything I can help with :)

eugene-tarassov commented 1 year ago

Please let me know if are any updates

I have committed new version of DDR3 modules support. It seems working fine now. Let me know if there is any problem.

gnodipac886 commented 1 year ago

Let me know if there is any problem.

Hmm, I'm getting this right now, perhaps something wrong with my OS? I'm going to try building the OS again.

[    5.130562] mmc0: error -22 whilst initialising SD card
[    6.191423] Freeing unused kernel image (initmem) memory: 2148K
[    6.212089] Run /init as init process
[    6.227800] mmc0: error -22 whilst initialising SD card
Loading, please wait...
[    7.065940] mmc0: error -22 whilst initialising SD card
Starting systemd-udevd version 252~rc3-2
[    7.934202] mmc0: error -22 whilst initialising SD card
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device.  Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT!  UUID=68d82fa1-1bb5-435f-a5e3-862176586eec does not exist.  Dropping to a shell!
(initramfs)
eugene-tarassov commented 1 year ago

To support more than 2GB memory, I had to make changes in the SD card driver, so you need to rebuild Linux kernel:

make clean
./mk-sd-card
gnodipac886 commented 1 year ago

To support more than 2GB memory, I had to make changes in the SD card driver, so you need to rebuild Linux kernel:

Yep that worked, thanks a ton!

reitowo commented 1 year ago

Debian upgraded the package from 250.4 to 252.2.

Is it possible to partially revert this package?

gnodipac886 commented 1 year ago

Hi @eugene-tarassov, Gemmini has merged my commit to the PE to save resources, we can potentially include this in this repo's flow. https://github.com/ucb-bar/gemmini/blob/dev/src/main/scala/gemmini/PE.scala

eugene-tarassov commented 1 year ago

Hi @gnodipac886, I have updated this repo to include your changes in the Gemmini PE.