I have previously talked about my use of IntelliJ as my primary development environment for Scala, C++ (CLion), JavaScript (Webstorm), and Python (PyCharm). I cannot recommend it enough. As luck would have it, a company is developing an IntelliJ plugin for Verilog and SystemVerilog. The plugin is in beta phase but remains exceptionally usable. The author is responsive in addressing my bug reports. Most refreshing is the tools' transparent pricing structure. No EDA sales representatives to deal with!
In summary, I wholeheartedly recommend hardware developers check out: https://www.edaphic.studio/.
Showing posts with label IntelliJ. Show all posts
Showing posts with label IntelliJ. Show all posts
Thursday, November 15, 2018
Kudos to Edaphic Studio
Tuesday, April 10, 2018
Using IntelliJ as RocketChip IDE
• Checkout the code according to instructions here.
$ git clone https://github.com/ucb-bar/rocket-chip.git
$ cd rocket-chip
$ git submodule update --init
$ export ROCKET_CHIP=`realpath ./rocket-chip`
• Build and publish FIRRTL, as usual:
$ cd $ROCKET_CHIP/firrtl
$ sbt clean publishLocal
• Verify that Rocket Chip can be compiled outside of IDE:
$ cd $ROCKET_CHIP
$ sbt clean publishLocal
• Wipe existing IDE configuration .idea, if necessary:
$ rm -rf $ROCKET_CHIP/.idea
• Import project into IntelliJ
Navigate to build.sbt, select default settings.
• (Optional) Attempt to compile using sbt, within IntelliJ:
• Rebuild project using IntelliJ
• Now for the secret sauce, write your generator object:
Start with running freechips.rocketchip.groundtest.Generator.
It will fail. That is good.
Exception in thread "main" java.lang.IllegalArgumentException: requirement failed: Usage: sbt> run TargetDir TopModuleProjectName TopModuleName ConfigProjectName ConfigNameString
at scala.Predef$.require(Predef.scala:224)
at freechips.rocketchip.util.GeneratorApp$class.names(GeneratorUtils.scala:76)
at freechips.rocketchip.groundtest.Generator$.names$lzycompute(Generator.scala:7)
at freechips.rocketchip.groundtest.Generator$.names(Generator.scala:7)
at freechips.rocketchip.groundtest.Generator$.delayedEndpoint$freechips$rocketchip$groundtest$Generator$1(Generator.scala:8)
at freechips.rocketchip.groundtest.Generator$delayedInit$body.apply(Generator.scala:7)
Fixing this is left as an exercise to the reader, but I will provide this simple (and, oh so powerful, tip).
Right click on 'GeneratorApp' from line 'object Generator extends App' and click 'Go To'. This will bring you the definition of the GeneratorApp trait.
So, why not add a breakpoint and debug yourself? The process is outside of the scope of this post.
• Tips for advanced users:
I typically do not do work inside the rocket-chip repo. Similar to the firrtl publishLocal step, I do a publishLocal of rocketchip and import the jar into my project. My generator function is highly customized.
See the following for more information:
Wednesday, May 3, 2017
Using IDEA Scala debugger for Chisel
This a quick follow up on an older post where I set up IntelliJ IDEA and Scala. I wrote this to make sure my steps for getting the debugger up and running were reproducable. The steps assume you have a working Chisel project that compiles using sbt.
Check if sbt compile works from the command line for your Chisel project ...
Check if sbt compile works from the command line for your Chisel project ...
[plus]:~/gitrepos/plus/arbiterdemo$ sbt compile [info] Loading global plugins from /home/edc/.sbt/0.13/plugins [info] Loading project definition from /home/edc/gitrepos/plus/arbiterdemo/project [info] Set current project to memctrldemo (in build file:/home/edc/gitrepos/plus/arbiterdemo/) [info] Updating {file:/home/edc/gitrepos/plus/arbiterdemo/}arbiterdemo... [..] [info] Done updating. [info] Compiling 3 Scala sources to /home/edc/gitrepos/plus/arbiterdemo/target/scala-2.11/classes... [success] Total time: 4 s, completed May 3, 2017 8:26:36 PM
Use the default project settings ...
Right click on your class that contains call to chisel3.Driver.execute, hit Run ...
Right click on your class that contains call to chisel3.Driver.execute, hit Run ...
Follow up by checking that that Verilog code is generated as expected (yes)
Finally, try setting a breakpoint by right clicking to the left of the source window and hit shift-F9 to begin debug. I was 100% successfull following only these steps on IDEA 2017.1 with the project-specific IDEA settings (i.e. .idea/ diretory) wiped out prior.
Finally, try setting a breakpoint by right clicking to the left of the source window and hit shift-F9 to begin debug. I was 100% successfull following only these steps on IDEA 2017.1 with the project-specific IDEA settings (i.e. .idea/ diretory) wiped out prior.
Tuesday, May 2, 2017
One simple command and voila ...
I have been trying to get IntelliJ IDEA's debugger working with Scala (support via plugin) for the better part of this past week. Each time the debugger was launched, I hit an issue that presented itself as a runtime exception: ClassNotFoundException for: org.jetbrains.plugins.scala.testingSupport.scalaTest.ScalaTestRunner.
My initial guess was "JAR Hell". The best trick I found for debugging library dependency issues is using sbt-depdency-graph plugin to visualize the dependency tree using sbt. To make use of the plugin you you need to add the following line to your plugins.sbt file. Use command sbt dependencyTree to view the output (library dependency tree) of the plugin.
addSbtPlugin("net.virtual-void" % "sbt-dependency-graph" % "0.8.2")
Connected to the target VM, address: '127.0.0.1:36512', transport: 'socket'
Luckily enough, I knew that something was up with my firewall as my Jenkins instance was no longer accepting connections. I had yet to debug this. On further inspection, I found my workstation's firewall rules had been completely wiped. The effect was no local TCP connections werepossible. The simple solution was to re-add the loopback network interface (lo) to firewalld and apply the trusted firewall zone to it. The not-so-simple solution, aka. the one that I first tried, was to identify the ports that IDEA's Scala plugin uses for local remote debugging. It turns out the port choice is random, thus the simple solution.
% firewall-cmd --zone=trusted --add-interface=lo --permanent
The debugger works fine now.
Tuesday, May 12, 2015
Wednesday Night (Pre-)Hack #13 - Chisel and IntelliJ Integration
Before getting started. Make sure the following is complete.
IntelliJ is downloaded and installed. The Scala plugin for IntelliJ is also installed.
It is unbelievable how simple the process was. I had never used IntelliJ before, but I am a user and fan of their PyCharm and CLion tools.
For basic testing, use the following shortcuts :
Ctrl-Shift-F9 to compile
Ctrl-Shift-F10 to run
Use: File.. Project Structure.. Global Libraries..
I picked up the following version: edu.berkeley.cs:chisel_2.11:2.2.26
IntelliJ is downloaded and installed. The Scala plugin for IntelliJ is also installed.
It is unbelievable how simple the process was. I had never used IntelliJ before, but I am a user and fan of their PyCharm and CLion tools.
1. Create a new Scala project
2. Make sure Project SDK and Scala SDK are properly set
3. Write, compile, and test a small Scala program
Ctrl-Shift-F9 to compile
Ctrl-Shift-F10 to run
4. Download Chisel from Maven repository
I picked up the following version: edu.berkeley.cs:chisel_2.11:2.2.26
5. Write, compile, and test a small Scala program
One gotcha I encountered was the name of the source file (HelloWorld.scala) needed to match the name of the object containing main function call.
Subscribe to:
Posts (Atom)