Updated master?

[jctullos]

Is there any plans to bump master? There are changes in FPGA shells that would be good to have into master. But trying to bump submodules ends up with errors. I've tried using branch Sbt_error, which were the errors I was receiving, but that build fails due to nvdlaBlocks compilation.

The branch bump stuff fails as well.

Thank you!

[jctullos]

@erikdanie In case you're able to help:

Here's the error I get when compiling bump-stuff or Soheil_br:

[error] /home/justin/freedom/src/main/scala/unleashed/DevKitFPGADesign.scala:78:52: 3 more arguments than can be applied to method apply: (node: freechips.rocketchip.diplomacy.BundleBridgeSource[sifive.blocks.devices.uart.UARTPortIO])(implicit p: freechips.rocketchip.config.Parameters)sifive.fpgashells.shell.UARTDesignInput in object UARTDesignInput
[error] val u = uoverlay.place(UARTDesignInput(uparam, divinit, pbus, ibus.fromAsync)).overlayOutput
[error] ^
[error] /home/justin/freedom/src/main/scala/unleashed/DevKitFPGADesign.scala:83:63: too many arguments (3) for method apply: (spiParam: sifive.blocks.devices.spi.SPIParams, node: freechips.rocketchip.diplomacy.BundleBridgeSource[sifive.blocks.devices.spi.SPIPortIO])(implicit p: freechips.rocketchip.config.Parameters)sifive.fpgashells.shell.SDIODesignInput in object SDIODesignInput
[error] val s = soverlay.place(SDIODesignInput(sparam, pbus, ibus.fromAsync)).overlayOutput
[error] ^
[error] two errors found

I'm sure it has something to do with the syntax.

Thank you

[erikdanie]

Hi jctullos,

I intend to merge one of those two branches soon, but overall, freedom's submodules will not be bumped by sifive with much frequency at all.

Did you further bump submodules past those branches? What is happening is that the controller instantiation used to happen in fpga-shells, and has now moved out. This will be confusing though because a lot of this stuff is changing in master of fpga-shells and sifive-blocks as we speak. But in essence, instead of passing the overlay a bunch of parameters (uartParams, divini, pbus etc), now you just pass the overlay a BundleBridge[UARTPortIO], which you get from doing the instantiation. The general code should look something like overlay.place(UARTDesignInput(UART.attachTo().ioNode), but that relies on the scope of the design mixing in the Attachable trait.

[jctullos]

@erikdanie

Ah thanks Erik. Is there any updated DevkitFPGADesign.scala that can be posted? I think all the changes that get bumped are good, there's just not updated src/main/scala/unleashed scala designs to use them. Are those still needed?

[bchetwynd]

@erikdanie - If possible, I would also appreciate updates to DevkitFPGADeisgn.scala that are compatible with the updated fpga-shells / sifive-blocks usage. Being only moderately familiar with the codebase makes reversing this from the posted updates challenging. If possible, compliance with the latest rocket-chip API would also be of benefit.

[jctullos]

I didn't mean to close this issue. Sorry about that, meant to keep it open when I commented last night.

And @bchetwynd @erikdanie same as above. I end up breaking more things than fixing due to the changes. Those 3 in the src/main/scala/unleashed with updates would help a ton.

[bchetwynd]

@jctullos - Thanks. Having updated rocket-chip, fpga-shells, and sifive-blocks to the latest I am stumbling through getting the U500 to build by updating DevkitFPGADesign.scala and DevkitConfigs.scala (I am targeting the vc707)

[jctullos]

@bchetwynd I have it running on the vc707. For now, if you're trying to get a running build, just revert back to cloning master at sifive/freedom.

If you have the PCIE FMC module, using the makefile is pretty straightforward. If you don't (like me), then you'll just follow the last part of the readme where it says what to put in.

I've reverted multiple times to the master, even though it's older it still builds and runs everything correctly. I was hoping for getting these updated as @erikdanie and his team have made some really good updates to the FPGA shells repo that I need.

[bchetwynd]

@jctullos - I have a working build based on the existing freedom platform (old rocket-chip, fpga-shells, and sifive-blocks). I am also hoping to be able to inherit some of the improvements that SiFive and others have added recently.

For reference, my derived repo is : https://github.com/mit-ll/CEP

[erikdanie]

Updating DevKitFPGADesign is the work that needs to be done to tie it all together, though not much should need to change. I hope to get to this in the next month or so, but could possibly be delayed.

[bchetwynd]

@erikdanie - Thanks for the note, Erik. It is a good learning experience to do some of the work on my end and even any preliminary hints you could provide would be welcome. I do appreciate that there are many competing priorities for your time.

[bchetwynd]

@erikdanie - I think a small nudge will go a long way.

From DevKitFPGADesign.scala, one used to "connect" with the FPGA JTAG interface via the following:

val jt = p(JTAGDebugOverlayKey).headOption.map(_(JTAGDebugOverlayParams())).get

However, the VC707 shell has changed from:

val jtag = Overlay(JTAGDebugOverlayKey) (new JTAGDebugVC707Overlay (_, _, _))

to

Overlay(JTAGDebugOverlayKey, new JTAGDebugVC707ShellPlacer(this, JTAGDebugShellInput()))

Might you be able to provide an example of how to update the line in DevKitFPGADesign.scala to accommodate the new mechanism?

[erikdanie]

Hi bchetwynd,

Sure, and I know these APIs are a bit obscure, one of the tasks in bumping the repos is to increase the comments and README to help people who want to leverage the code. Here is a long description of the changes, but a tl;dr at the bottom if you just want to get it working:

From DevKitFPGADesign.scala, one used to "connect" with the FPGA JTAG interface via the following:

The way I like to describe it is that we have an FPGA shell, which is a collection of overlays. These overlays are "created" by the shell itself and define the possible top-level configurations. You see this list here for the old way and here for the newer way. More on what has changed below.

Then, your design can choose which of these existing overlays to "place". Only when this happens does the code in the overlay get executed and the IOs are created. If a design chooses not to place an overlay, it is the same as that overlay not existing in the first place – nothing is done. Thus, the abstraction is that a shell only knows its own possible permutations and full potential IOs, and a design is placed into a shell and must:

1. find out what overlays it has available to it and
2. place the ones it wants and connect them accordingly.

The issue with the old way was that it was hard for the design to decide when it wanted to place an overlay. All it could do was lookup the key and get a List of all the defined overlays for that Key. So, what I did is change it so that now, an Overlay has 2 "Inputs", a ShellInputand a DesignInput.

The ShellInput is defined by the shell when the Overlay is created (this is what you are seeing here
Overlay(JTAGDebugOverlayKey, new JTAGDebugVC707ShellPlacer(this, JTAGDebugShellInput()))
though the JTAG one is empty)
This acts as a form of metadata, so the shell can tell the design interesting things about the overlay before the design chooses to place it or not. This is particularly useful for things there would be multiple of, for example LEDs. Each LED overlay is now 1 bit and has a LEDShellInput that can define things like the index, the color, what bank of LEDs it is in, etc.

What used to be called the OverlayParams has been renamed the DesignInput to make it clear the difference between it and the ShellInput The DesignInput is stuff that is passed from the Design into the Overlay. Often these are empty as the JTAG one is in your example.

Lastly, now overlayOutput is a case class that groups together anything that might want to be outputted by the overlay, so that it is easier to access different outputs.

So, a version of the jtag overlay placing code you linked that doesn't do anything fancy, but adheres to those new APIs might look something like this:
val jt = p(JTAGDebugOverlayKey).headOption.map(_.place(JTAGDebugDesignInput())).get.overlayOutput.jtag
(note one other small change is requiring explicitly calling .place to make code more readable

But if you wanted to get fancy with it, say for LEDs you could do something like this:
val greenLEDs = p(LEDOverlayKey).filter(_.shellInput.color == "green").map(_.place(LEDDesignInput()).overlayOutput.led)

I hope this makes sense, I know it is a lot of changes that aren't well-documented.

tl;dr:
try val jt = p(JTAGDebugOverlayKey).headOption.map(_.place(JTAGDebugDesignInput())).get.overlayOutput.jtag and see if it works or what the errors are.

[jctullos]

@erikdanie

Thank you for the insight, those comments help me out a lot. I've ported over some of your code in FPGAshells to have the vc707 use 4GB RAM depth, instead of the 1GB. While I can get Linux to boot, I'm having issues with kernel panics running anything due to paging requests. I think there's something I'm missing to enable in the defconfig. Have you seen anything like that? I'm running Linux 5.3. I can run the same program on my Linux 1GB VC707 bitstream just fine with no errors.

[bchetwynd]

@erikdanie

Thank you much for the information! Your proposed change definitely eliminate the issue with JTAG. I am now working through the other items in DevKitFPGADesign.scala to properly enumerate the other interfaces (UART, SDIO, DDR, etc.)

[bchetwynd]

@erikdanie

I think I may need to wait until a full-scale upgrade of DevKitFPGADesign.scala.

The other interfaces prove to be a bit more complicated given my only moderate understanding of Chisel!

[tmagik]

@jctullos do you have a commit and kernel config I can look at? I would like to try rebuilding the FPGA image from source. What are you using for an SBI/bootloader?

…

On May 3, 2020, at 3:28 PM, jctullos ***@***.***> wrote: @erikdanie Thank you for the insight, those comments help me out a lot. I've ported over some of your code in FPGAshells to have the vc707 use 4GB RAM depth, instead of the 1GB. While I can get Linux to boot, I'm having issues with kernel panics running anything due to paging requests. I think there's something I'm missing to enable in the defconfig. Have you seen anything like that? I'm running Linux 5.3. I can run the same program on my Linux 1GB VC707 bitstream just fine with no errors. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[jctullos]

@tmagik so I don't have a personal repo with the commit. But I can send you the changes I've made to your email (I have your gmail from an earlier response in the Keystone group).

For VC707 no PCIe/FMC: I'm using the default freedom master, for 100 MHz, but with 4 Gb ram instead of 1 (you can change in the FPGA shells). For the bootloader, I'm using the FU540, but modified by MCD500 for VC707 at: https://github.com/keystone-enclave/freedom-u540-c000-bootloader.git use commit bbfcc288. With some changes to the memory locations that I can send you to match the increased memory size, and speed.

But I did just verify the same kernel panics with the freedom-u-sdk bootloader with 4 Gb. Using: https://github.com/mcd500/freedom-u-sdk.git on the vc707 devkit branch. So this one might be quicker to reproduce if you wanted to see it.

[jctullos]

@tmagik I'm going to get my repo going today, and I'll send you the commit. It'll be easier than the crazy instructions I just put here. :)

[bchetwynd]

@jctullos If you would not mind sharing your commit here, I'd appreciate it. It would be good to see how you modified the DevKitFPGADesign.scala file to work with the new fpga-shells and sifive-blocks.

[jctullos]

@tmagik I just invited you to the repo.

@bchetwynd I didn't modify the DevKitFPGADesign.scala. I stayed with the default commit from Freedom, but just went FPGA Shells to see how he added the 4gb version awhile back, because I couldn't get the DevKitFPGADesign.scala to work. Like you, my knowledge with Chisel/Scala is limited. I could probably learn, but I'm afraid I'll break more than I fix right now lol.

[bchetwynd]

@jctullos - Thanks for the clarification! Good luck with your build.

[tmagik]

@jctullos I can't seem to find the repo anywhere obvious, can you put a link here and we can all look at it?

[jctullos]

@tmagik See if this works: https://github.com/jctullos/freedom

[jctullos]

@erikdanie

I was able to get the VCU118 working with the FU540 bootloader and supporting multiple partitions.

The VCU118 had an SPI speed problem. I verified through a logic analyzer. But once I slowed the speed down to 1MHz and it loads Linux now. Next work will be on the VC707.

[bchetwynd]

@erikdanie - Any update on bumping DevKitFPGADesign.scala?

[erikdanie]

@bchetwynd take a look at the jun-20-update branch. I think it is close to ready, but need to do some more small fixes and tests

[bchetwynd]

@erikdanie - Will do! I will let you know

[bchetwynd]

@erikdanie , I checked out this branch, did a submodule init and got the following error when I tried to generate the verilog:

[error] ./freedom_new/nvidia-dla-blocks/src/main/scala/devices/nvdla/Periphery.scala:21:10: value control_bus is not a member of freechips.rocketchip.subsystem.SystemBus
[error] sbus.control_bus.toFixedWidthSingleBeatSlave(4, Some("nvdla_cfg")) { nvdla.cfg_tl_node }
[error] ^
[error] one error found
[info] Compiling 103 Scala sources to ./freedom_new/fpga-shells/target/scala-2.12/classes ...
[error] ./freedom_new/fpga-shells/src/main/scala/shell/Util.scala:41:43: value repeat is not a member of String
[error] | assign a = b_en ? b : $w'b${"z".repeat(w)};
[error] ^
[error] one error found
[error] (nvdlaBlocks / Compile / compileIncremental) Compilation failed
[error] (fpgaShells / Compile / compileIncremental) Compilation failed
[error] Total time: 136 s (02:16), completed Aug 18, 2020 11:38:00 AM

I am about to add some major features to my platform and would prefer to start with the latest and greatest rocket-chip and sifive-blocks....

The command I executed was "make -f Makefile.vc707-u500devkit verilog"

Thank you.

[erikdanie]

Just to confirm, you did a git submodule --init --recursive? The recursive part is important, to pick up changes in subrepos

[bchetwynd]

@erikdanie - Yes, I ran the following command after cloning: git submodule update --init --recursive . I then ran the following Make -f Makefile.vc707-u500devkit verilog

I also tried updating the sifive-blocks, fpga-shells, and rocket-chip to later versions to no avail.

In that case, it seems the methods for GPIO and SDIO attachment have changed.... but the compilation is only down to 7 errors!

[erikdanie]

I see the error, just pushed a fix to that same branch, try it now

[bchetwynd]

@erikdanie - Erik, I was able to successfully build the verilog but have not taken the verification further. Thank you much for this update.

I am now exploring rolling to the latest rocket-chip / fpga-shells / sifive-blocks, but this is a great step towards that.

Thanks!

[bchetwynd]

@erikdanie - Thanks again for these updates. Would it be possible to create a branch based on later versions of the rocket-chip / fpga-shells / sifive-blocks? We are looking to run with the latest we possibly can before committing to a final design as there have been quite a few bug fixes since Jan-20.

[bchetwynd]

@erikdanie - I finally got around to building the U500 with Vivado 2018.3.

I ran "make -f Makefile.vc707-u500devkit verilog mcs"

The following error comes up:
ERROR: [Synth 8-439] module 'AnalogToUInt' not found

[bchetwynd]

Per you note:

#143

I created two files, which I added to VSRCS: AnalogToUInt.v and UIntToAnalog.v, with the contents as mentioned in the aforementioned issue and it continued to build.