Espressif uses two Tensilica cores. Tensilica is part of Cadence Systems and in the same Business as ARM or MIPS. They may have made just the best offer.
SiFive also wants to play in the same Business (together with about 10 other Startups for RISC-V) as Tensilica, ARM or MIPS. They all help you to produce a chip and want to see money for that.
So why is ARM the bad guy? Just because they had the most success?
RISC-V on FPGAs is a good alternative if you want a custom chip. As is the MICO8/MICO32 from Lattice or the NIOS2 from Altera/Intel or the Microblade from Xilinx. They all are integerated in the FPGA Toolchain and let you compound your own mix from CPU and Peripherals with some Mouseclicks.
But FPGAs are always slower, more expensive and more power hungry than ASIC solutions.
Thing is, the ESP32 has two 32 bit processors running at 240MHz with 520KB internal SRAM, 4MB FLASH, 28 GPIO, besides all it's wireless goodies.
One wonders what the point of having the puny RISC-V implementation on the board is.
It does not seem attractive, except for those like me that want to cheer along for open hardware and the RISC V.
I'd be very happy if they supplied that RISC V chip on a tiny break out board.
I'm not sure why they designed the Cinque that way either. It also has an STM32F1 IIRC for the USB stuff. The name recognition with Arduino is good for SiFive though.
I just found this thread and have very similar interests to you @Heater. I'm excited about full open source FPGA and am interested in RISC-V design. I just ordered the RISC-V Computer Organization and Design book to get some background on cpu architecture in general.
I actually emailed the SiFive folks and they sent me five of the E310 chips. They are the same as on the HiFive1 dev board they have and the Cinque. My guess is that the RAM will get better as they refine the chip. There is also mention of more peripherals like a second SPI that aren't brought out yet. They made it clear that the chips are engineering samples only.
I do a lot of work with Adafruit Feather boards so I've designed a Feather with a SAMD21 for USB and the E310 to play with. Its untested because the boards are at OSH Park atm but I'm happy to post the files if folks are interested. I'd also like to put together a Feather with an ICE40 FPGA. Ideally it'd be the newer one with the QFN but I may try my hand at BGA. I'd love to get open source support for the newer chips but doubt I can find the time for reverse engineering it along with the board designs and my day job.
Anyway, cool thread. I'd love to hear more about the status of the all open source RISC-V on FPGA.
There may be some interesting parts to this project - e.g. the debugger or FreeRTOS support. I didn't look into it very much. I finally got a Lattice board, so I'll play with PicoRV32 using Clifford's tools.
I found these Risc-V comparison tables interesting, if simply for comparing various FPGA families, and how much extra clock you get for each feature jetisoned.
We could do a similar thing for P1V, and include current consumption...
I thought I was done learning new programming languages. But Spinal looks like it makes creating hardware designs much easier than Verilog or VHDL and it integrates nicely with the Verilator and such like. Spinal is in fact a library for Scala if I understand correctly. So here we go again....
Spinal looks great. For example here is some simple combinatorial logic module in Spinal:
class MyComponent extends Component {
// Define the inputs and outputs
val io = new Bundle {
val a = in Bool
val b = in Bool
val c = in Bool
val result = out Bool
}
// Specify the logic required
io.result := (io.a & io.b) | (!io.c)
}
I'm a bit worried that it relies of Java, blech, to get the Scala running. But it certainly deserves a closer look.
I can imagine that a nice simplified language like Spinal to develop hardware designs in, wrapped up in a drop dead simple IDE like the Arduino's, and the open source synthesis tools for Lattice FPGA's, not to mention the dirt cheap parts, could create an Arduino style explosion in the use of FPGA by kids, makers, etc.
It's a bit of a long winded install but never mind.
Then we test with the Spinal demo project:
git clone https://github.com/SpinalHDL/SpinalBaseProject.git
cd SpinalBaseProject/
sbt run
ls MyTopLevel.vhd
This is quite magical. It turns nice looking code like this:
class MyTopLevel extends Component {
val io = new Bundle {
val cond0 = in Bool
val cond1 = in Bool
val flag = out Bool
val state = out UInt(8 bits)
}
val counter = Reg(UInt(8 bits)) init(0)
when(io.cond0){
counter := counter + 1
}
io.state := counter
io.flag := (counter === 0) | io.cond1
}
Into horrible looking code like this VHDL:
entity MyTopLevel is
port(
io_cond0 : in std_logic;
io_cond1 : in std_logic;
io_flag : out std_logic;
io_state : out unsigned(7 downto 0);
clk : in std_logic;
reset : in std_logic
);
end MyTopLevel;
architecture arch of MyTopLevel is
signal counter : unsigned(7 downto 0);
begin
io_flag <= (pkg_toStdLogic(counter = pkg_unsigned("00000000")) or io_cond1);
io_state <= counter;
process(clk,reset)
begin
if reset = '1' then
counter <= pkg_unsigned("00000000");
elsif rising_edge(clk) then
if io_cond0 = '1' then
counter <= (counter + pkg_unsigned("00000001"));
end if;
end if;
end process;
end arch;
Plus a a whole bunch of other VHDL function definitions.
With a little tweak it also produce Verilog code like this:
module MyTopLevel
(
input io_cond0,
input io_cond1,
output io_flag,
output [7:0] io_state,
input clk,
input reset
);
reg [7:0] counter;
wire [7:0] _1;
assign io_flag = ((counter == (8'b00000000)) || io_cond1);
assign io_state = counter;
assign _1 = (counter + (8'b00000001));
always @ (posedge clk or posedge reset)
begin
if (reset) begin
counter <= (8'b00000000);
end else begin
if(io_cond0)begin
counter <= _1;
end
end
end
endmodule
Which is great.
The downside of all this is performance. Transpiling that little example takes 40 seconds on this old PC. I get the feeling bigger projects will get annoyingly tedious. Gone is the fast hack/run turn round of writing Verilog and using the Icarus simulator. Hardly surprising since it's all based on Java which is always horribly huge, bloated and slow.
The saving in actual lines of code is only about 25% so I'd have to play with it more to see if I like the clean code vs tedious development cycle.
Of course the claim is that a language like Spinal reduces the possibility of bugs. Rather like moving from assembler to C. So the tedium might be worth it.
Of course the claim is that a language like Spinal reduces the possibility of bugs. Rather like moving from assembler to C. So the tedium might be worth it.
Hmm, perhaps.
I notice an Async Reset was added that was not in your original highest level code ?
Rather looks like it could add bugs from unexpected signals - I guess those added names generate errors later, so you can hunt & fix from there
There may be some interesting parts to this project - e.g. the debugger or FreeRTOS support. I didn't look into it very much. I finally got a Lattice board, so I'll play with PicoRV32 using Clifford's tools.
The downside of all this is performance. Transpiling that little example takes 40 seconds on this old PC. I get the feeling bigger projects will get annoyingly tedious. Gone is the fast hack/run turn round of writing Verilog and using the Icarus simulator. Hardly surprising since it's all based on Java which is always horribly huge, bloated and slow.
You are right, the turn over could take time. There is some tricks :
- Keeping SBT warm/on (Just run sbt in the command line, and then enter commands) It avoid reloading it each time
- Else, if you use a IDE like Intelij 14.1.7 Basicaly, the IDE keep a scala compiler warm/on, which make the turn over much faster
- The first time you run a project, it will take much more time than usual
I'm using a recent computer, my turn over is around 7 seconds between editing the code and getting the SoC generated.
Normaly, the bigger is the project, the less is the turnover increment
I notice an Async Reset was added that was not in your original highest level code ?
Rather looks like it could add bugs from unexpected signals - I guess those added names generate errors later, so you can hunt & fix from there
It's not a bug, val counter = Reg(UInt(8 bits)) init(0) define a 8 bits register with 0 as reset value.
In SpinalHDL clock and reset are implicite, you can define ClockDomains which define how register should be clocked/reseted and then those clock and reset signals will be wired to where it's required.
It's not a bug, val counter = Reg(UInt(8 bits)) init(0) define a 8 bits register with 0 as reset value.
In SpinalHDL clock and reset are implicite, you can define ClockDomains which define how register should be clocked/reseted and then those clock and reset signals will be wired to where it's required.
Ah, ok.
How do you select between Sync and Async resets ? or does the Async reset assume some care is taken on reset release ?
I guess that depends on FPGA, as to if Async RST has silicon paths that can reduce build sizes ?
It's not a bug, val counter = Reg(UInt(8 bits)) init(0) define a 8 bits register with 0 as reset value.
In SpinalHDL clock and reset are implicite, you can define ClockDomains which define how register should be clocked/reseted and then those clock and reset signals will be wired to where it's required.
Ah, ok.
How do you select between Sync and Async resets ? or does the Async reset assume some care is taken on reset release ?
I guess that depends on FPGA, as to if Async RST has silicon paths that can reduce build sizes ?
val mySpecificClockedArea = new ClockingArea(myClockDomain){
//All register declaration and sub component instanciated in this area will use myClockDomain by default
I have been playing with the SAP-1 project in verilog.
I downloaded a students solution. Although it looked good, it had a few nasty bugs that I have fixed, but there is still a couple that are preventing a clean compile.
So I have been looking at verilog tutorials and discovered lots of info that can cause errors realising what you want. Some just use more slower logic instead of multiplexors or counters. There must be standard muxes and counters libraries out there. Just haven't found them yet.
I wanted to see how many lines a SAP-1 verilog would take, and how many LEs.
Still I struggle with setting up the ancilary files such as pinouts, assignments and constraints. Then comes how to simulate. I am not up to trying another language like spinal yet
- ICE40-hx8k + icestorm => 53 Mhz, 2142 LC
- 0.37 DMIPS/Mhz
- 8 kB of on-chip ram
- JTAG debugger (eclipse/GDB/openocd ready)
- Interrupt support
- APB bus for peripherals
- 32 GPIO pin
- one 16 bits prescaler, two 16 bits timers
Let's me know if you want to try, You can also simulate this SoC and connect it to eclipse/GDB/openocd
Thanks for pointing that out. I'll have to take a look at this project. Do you have any advice on recommended debugger hardware? I'll be using the Lattice 8k breakout board.
What you have created is certainly very interesting. I have watched your video and read the PDF and other docs with fascination.
This might be a totally wrong forum to discuss such things, but, well, the Propeller 1 is published as Open Source HDL so we are kind of on topic.
I'll be looking forward to trying out the VexRisc on my DE0 Nano. All this FPGA and HDL is new to me after decades of writing software. I was always put off by the complexity and sluggishness of things like Quartus. It's not something that you want to play with for fun. Also FPGA were much more expensive than I could justify. All that has changed with the Lattice parts and things like Icarus and IceStorm. Looks like Spinal will be a great help there as well.
Keeping SBT "warm" certainly helps. Build time for the example project went down to 1 second!
I'm sure InteliJ is fine but I'm kind of done with using a different IDE for every project. Hope to see Scala/Spinal plugins for VS code. I was done with having to learn a new language every couple of years for every new project. I'll make an exception for Spinal as it looks so cool. Shame it's not done in Javascript Is there a Scala that does not depend on Java?
[error] (*:update) sbt.ResolveException: unresolved dependency: com.github.spinalhdl#spinalhdl-core_2.11;0.10.15: not found
[error] unresolved dependency: com.github.spinalhdl#spinalhdl-lib_2.11;0.10.15: not found
[error] Total time: 3 s, completed 30-Jul-2017 07:48:14
I did the "...get the SpinalHDL repository and do a "sbt publish-local" in it." thing but it did not help.
Thanks for pointing that out. I'll have to take a look at this project. Do you have any advice on recommended debugger hardware? I'll be using the Lattice 8k breakout board.
Personnaly i'm using this one : https://numato.com/ft2232h-breakout-module/
But normaly any JTAG which is openocd ready shoud be ok, but for sure, ft2232 based ones will be ok.
I also worked with the jtagkey-2.
[error] (*:update) sbt.ResolveException: unresolved dependency: com.github.spinalhdl#spinalhdl-core_2.11;0.10.15: not found
[error] unresolved dependency: com.github.spinalhdl#spinalhdl-lib_2.11;0.10.15: not found
[error] Total time: 3 s, completed 30-Jul-2017 07:48:14
I did the "...get the SpinalHDL repository and do a "sbt publish-local" in it." thing but it did not help.
I just tried with a clean virtual machine, and it passe with the following commands (from zero install Ubuntu 16)
Thanks for taking the time Dolu. Removing SpinalHDL and cloning again got things working for me. I now have Murax and GenSmallest built successfully. The verilated Murax even boots.
It's nice to see that building Murax only takes 20 seconds from cold. Keeping sbt warm gets that down to 7 seconds initially then only 4 seconds on subsequent runs. Magic!
I'm using Debian Stretch here. I'm going to try Spinal in the BASH shell for Windows 10...
Another thanks Dolu. I followed the build instructions that you gave on an Ubuntu 16.04.2 LTS system and they seemed to work just fine. I'm in the middle of some other stuff, but will take a closer look soon.
I was wondering about those block diagrams that you have - e.g. the diagram for Briey SOC. Do you have a tool that generates code from the diagrams or vice versa?
Also have you used any free tools for CSR (control and status register) generation? (If there is a block digram tool above, then it would sort of fit into that as you would generate the headers based on how everything is wired together.) I've seen some proprietary tools at various companies, but nothing really fully featured in the OSS world. I'm thinking verilog RTL generation, verilog/c header file generation, documentation generation, and verification features. Maybe something like SystemRDL.
I was wondering about those block diagrams that you have - e.g. the diagram for Briey SOC. Do you have a tool that generates code from the diagrams or vice versa?l
I don't have tool which generate diagrams, this one was done by hand.
Also have you used any free tools for CSR (control and status register) generation? (If there is a block digram tool above, then it would sort of fit into that as you would generate the headers based on how everything is wired together.) I've seen some proprietary tools at various companies, but nothing really fully featured in the OSS world. I'm thinking verilog RTL generation, verilog/c header file generation, documentation generation, and verification features. Maybe something like SystemRDL.
The thing with SpinalHDL is that the language is flexible enough to allow you implementing tools which generate register banks/register mapping : D Which could avoid using multiple languages and losing consistancy between them.
So there is some example.
There is specify the MSTATUS register at the address CSR.MSTATUS as a READ/WRITE one with the corresponding bits at their corresponding place :
READ_WRITE(CSR.MSTATUS,11 -> mstatus.MPP, 7 -> mstatus.MPIE, 3 -> mstatus.MIE) https://github.com/SpinalHDL/VexRiscv/blob/9fe4e1d54da02bad23073736ca77d8d6e2e90a0a/src/main/scala/vexriscv/plugin/CsrPlugin.scala#L303
or by doing this : mbadaddrAccess(CSR.MBADADDR, mbadaddr)
mbadaddrAccess -> Is a parameter which specify the kind of access (READ_ONLY, WRITE_ONLY, READ_WRITE)
CSR.MBADADDR -> specify the CSR address
mbadaddr -> is the signal
To resume, in SpinalHDL, you can define tools which alow you to build a data model of what you want (specification) and then automaticaly use generate the corresponding hardware/document/C driver
To resume, in SpinalHDL, you can define tools which alow you to build a data model of what you want (specification) and then automaticaly use generate the corresponding hardware/document/C driver
I had a feeling that might be your answer ;-)
Do you have any thoughts on formal verification and how that fits in this flow? If you're trying to stick with open and freely available tools, then this is difficult. But I saw Clifford Wolf working on this in http://symbiyosys.readthedocs.io/en/latest/ Maybe it would be of some interest if you haven't taken a look.
Do you have any thoughts on formal verification and how that fits in this flow? If you're trying to stick with open and freely available tools, then this is difficult. But I saw Clifford Wolf working on this in http://symbiyosys.readthedocs.io/en/latest/ Maybe it would be of some interest if you haven't taken a look.
I haven't hardly tried formal verification, but it would fit in the flow as vhdl/verilog/verilator/cocotb verification i think.
Basicaly, with SpinalHDL the idea is, you generate your RTL as a VHDL or Verilog file, and then to verify them, you use the flow that you are used to (traditional verification in VHDL/Verilog or their alternative)
I hear about the Clifford tool, it's a great initiative : D
That's a nice thread. I had seen references in Clifford's tweets, but this spells out the motivation pretty clearly: "My high level goal is to get a picorv32 going on the chip using the hard IPs. I want to create a board with the Adafruit Feather form factor which can basically replace an M0+ MCU but have the flexibility of custom peripherals or fully custom logic."
It looks like there's a Feather in the works that uses the SiFive chip too:
I haven't hardly tried formal verification, but it would fit in the flow as vhdl/verilog/verilator/cocotb verification i think.
Basicaly, with SpinalHDL the idea is, you generate your RTL as a VHDL or Verilog file, and then to verify them, you use the flow that you are used to (traditional verification in VHDL/Verilog or their alternative)
I don't have much experience either except with equivalence checking. It would seem ideal if the designer would write the assertions in SpinalHDL while doing the design. Given the state of the free tools it doesn't sound like an easy problem. (For example: Clifford advises that one stick with immediate assertions and build checker state machines where necessary.) Anyways this is one area that I want to explore.
Back in July I said I would try to get Spinal running on the Linux Subsystem for Windows 10. After a busy time I just found time to do it.
Pleased to say it works fine. Again the verilated Murax boots!
Took a while to install the Win 10 Creators update and then update the BASH shell to Ubuntu 16 so that I could get a JDK 8 installation. It's amazing how many giga bytes of stuff one needs to install now a days to get a program running !
Anyway, I was wondering what is the preferred way to start with a brand new Spinal project. Say one just wants to make a simple component and get it built as Verilog? I imagine it needs a new project directory and some structure in there?
I guess the SpinalBaseProject is a good start. How much of that is actually needed from scratch?
Comments
SiFive also wants to play in the same Business (together with about 10 other Startups for RISC-V) as Tensilica, ARM or MIPS. They all help you to produce a chip and want to see money for that.
So why is ARM the bad guy? Just because they had the most success?
RISC-V on FPGAs is a good alternative if you want a custom chip. As is the MICO8/MICO32 from Lattice or the NIOS2 from Altera/Intel or the Microblade from Xilinx. They all are integerated in the FPGA Toolchain and let you compound your own mix from CPU and Peripherals with some Mouseclicks.
But FPGAs are always slower, more expensive and more power hungry than ASIC solutions.
Andy
MIPS still have a following and the licensing is likely much cheaper than ARM can command. I read the other day that the MIPS was up for sale.
I'm not sure why they designed the Cinque that way either. It also has an STM32F1 IIRC for the USB stuff. The name recognition with Arduino is good for SiFive though.
I just found this thread and have very similar interests to you @Heater. I'm excited about full open source FPGA and am interested in RISC-V design. I just ordered the RISC-V Computer Organization and Design book to get some background on cpu architecture in general.
I actually emailed the SiFive folks and they sent me five of the E310 chips. They are the same as on the HiFive1 dev board they have and the Cinque. My guess is that the RAM will get better as they refine the chip. There is also mention of more peripherals like a second SPI that aren't brought out yet. They made it clear that the chips are engineering samples only.
I do a lot of work with Adafruit Feather boards so I've designed a Feather with a SAMD21 for USB and the E310 to play with. Its untested because the boards are at OSH Park atm but I'm happy to post the files if folks are interested. I'd also like to put together a Feather with an ICE40 FPGA. Ideally it'd be the newer one with the QFN but I may try my hand at BGA. I'd love to get open source support for the newer chips but doubt I can find the time for reverse engineering it along with the board designs and my day job.
Anyway, cool thread. I'd love to hear more about the status of the all open source RISC-V on FPGA.
http://hackaday.com/2017/07/21/vexriscv-a-modular-risc-v-implementation-for-fpga/
There may be some interesting parts to this project - e.g. the debugger or FreeRTOS support. I didn't look into it very much. I finally got a Lattice board, so I'll play with PicoRV32 using Clifford's tools.
We could do a similar thing for P1V, and include current consumption...
https://github.com/SpinalHDL/VexRiscv
Interesting numbers, in MHz and LUT.
No values given for Cylcone 10, or Max 10 ?
"To run the verilator simulation of the Briey SoC which can be then connected to OpenOCD/GDB"
Thanks for the heads up on SpinalHDL. Fascinating. I found a nice introductory video on Spinal here:
https://fosdem.org/2017/schedule/event/spinal_hdl/
I thought I was done learning new programming languages. But Spinal looks like it makes creating hardware designs much easier than Verilog or VHDL and it integrates nicely with the Verilator and such like. Spinal is in fact a library for Scala if I understand correctly. So here we go again....
class MyComponent extends Component { // Define the inputs and outputs val io = new Bundle { val a = in Bool val b = in Bool val c = in Bool val result = out Bool } // Specify the logic required io.result := (io.a & io.b) | (!io.c) }I'm a bit worried that it relies of Java, blech, to get the Scala running. But it certainly deserves a closer look.
I can imagine that a nice simplified language like Spinal to develop hardware designs in, wrapped up in a drop dead simple IDE like the Arduino's, and the open source synthesis tools for Lattice FPGA's, not to mention the dirt cheap parts, could create an Arduino style explosion in the use of FPGA by kids, makers, etc.
http://spinalhdl.github.io/SpinalDoc/spinal_getting_started/
It's a bit of a long winded install but never mind.
Then we test with the Spinal demo project: This is quite magical. It turns nice looking code like this:
class MyTopLevel extends Component { val io = new Bundle { val cond0 = in Bool val cond1 = in Bool val flag = out Bool val state = out UInt(8 bits) } val counter = Reg(UInt(8 bits)) init(0) when(io.cond0){ counter := counter + 1 } io.state := counter io.flag := (counter === 0) | io.cond1 }Into horrible looking code like this VHDL:entity MyTopLevel is port( io_cond0 : in std_logic; io_cond1 : in std_logic; io_flag : out std_logic; io_state : out unsigned(7 downto 0); clk : in std_logic; reset : in std_logic ); end MyTopLevel; architecture arch of MyTopLevel is signal counter : unsigned(7 downto 0); begin io_flag <= (pkg_toStdLogic(counter = pkg_unsigned("00000000")) or io_cond1); io_state <= counter; process(clk,reset) begin if reset = '1' then counter <= pkg_unsigned("00000000"); elsif rising_edge(clk) then if io_cond0 = '1' then counter <= (counter + pkg_unsigned("00000001")); end if; end if; end process; end arch;Plus a a whole bunch of other VHDL function definitions.With a little tweak it also produce Verilog code like this:
module MyTopLevel ( input io_cond0, input io_cond1, output io_flag, output [7:0] io_state, input clk, input reset ); reg [7:0] counter; wire [7:0] _1; assign io_flag = ((counter == (8'b00000000)) || io_cond1); assign io_state = counter; assign _1 = (counter + (8'b00000001)); always @ (posedge clk or posedge reset) begin if (reset) begin counter <= (8'b00000000); end else begin if(io_cond0)begin counter <= _1; end end end endmoduleWhich is great.The downside of all this is performance. Transpiling that little example takes 40 seconds on this old PC. I get the feeling bigger projects will get annoyingly tedious. Gone is the fast hack/run turn round of writing Verilog and using the Icarus simulator. Hardly surprising since it's all based on Java which is always horribly huge, bloated and slow.
The saving in actual lines of code is only about 25% so I'd have to play with it more to see if I like the clean code vs tedious development cycle.
Of course the claim is that a language like Spinal reduces the possibility of bugs. Rather like moving from assembler to C. So the tedium might be worth it.
I notice an Async Reset was added that was not in your original highest level code ?
Rather looks like it could add bugs from unexpected signals - I guess those added names generate errors later, so you can hunt & fix from there
Thanks for interrest : D
There is a SoC demo which can fit on ICE40 4K/8K :
https://github.com/SpinalHDL/VexRiscv#murax-soc
- ICE40-hx8k + icestorm => 53 Mhz, 2142 LC
- 0.37 DMIPS/Mhz
- 8 kB of on-chip ram
- JTAG debugger (eclipse/GDB/openocd ready)
- Interrupt support
- APB bus for peripherals
- 32 GPIO pin
- one 16 bits prescaler, two 16 bits timers
Let's me know if you want to try, You can also simulate this SoC and connect it to eclipse/GDB/openocd
You are right, the turn over could take time. There is some tricks :
- Keeping SBT warm/on (Just run sbt in the command line, and then enter commands) It avoid reloading it each time
- Else, if you use a IDE like Intelij 14.1.7 Basicaly, the IDE keep a scala compiler warm/on, which make the turn over much faster
- The first time you run a project, it will take much more time than usual
I'm using a recent computer, my turn over is around 7 seconds between editing the code and getting the SoC generated.
Normaly, the bigger is the project, the less is the turnover increment
On simple things the code size difference is not big, but when it come to interface / interconnect / abstractions crazy things could start
On this presentation, it start from the page 12 : https://github.com/SpinalHDL/SpinalDoc/raw/master/presentation/en/presentation_eth.pdf
It's not a bug, val counter = Reg(UInt(8 bits)) init(0) define a 8 bits register with 0 as reset value.
In SpinalHDL clock and reset are implicite, you can define ClockDomains which define how register should be clocked/reseted and then those clock and reset signals will be wired to where it's required.
How do you select between Sync and Async resets ? or does the Async reset assume some care is taken on reset release ?
I guess that depends on FPGA, as to if Async RST has silicon paths that can reduce build sizes ?
There is a simple example how is defined a ClockDomain :
(sorry i don't know how to format code on this forum, the original code is there : http://spinalhdl.github.io/SpinalDoc/spinal/core/clock_domain/#configuration)
[pre]
class CustomClockExample extends Component {
val io = new Bundle {
val clk = in Bool
val resetn = in Bool
val result = out UInt (4 bits)
}
val myClockDomain = ClockDomain(
clock = io.clk,
reset = io.resetn,
config = ClockDomainConfig(
clockEdge = RISING,
resetKind = ASYNC,
resetActiveLevel = LOW
)
)
val mySpecificClockedArea = new ClockingArea(myClockDomain){
//All register declaration and sub component instanciated in this area will use myClockDomain by default
val myReg = Reg(UInt(4 bits)) init(7)
myReg := myReg + 1
io.result := myReg
}
}
[/pre]
The resetKind value can be set to : ASYNC, SYNC and BOOT (FF values loaded by the bitstream)
I downloaded a students solution. Although it looked good, it had a few nasty bugs that I have fixed, but there is still a couple that are preventing a clean compile.
So I have been looking at verilog tutorials and discovered lots of info that can cause errors realising what you want. Some just use more slower logic instead of multiplexors or counters. There must be standard muxes and counters libraries out there. Just haven't found them yet.
I wanted to see how many lines a SAP-1 verilog would take, and how many LEs.
Still I struggle with setting up the ancilary files such as pinouts, assignments and constraints. Then comes how to simulate. I am not up to trying another language like spinal yet
Thanks for pointing that out. I'll have to take a look at this project. Do you have any advice on recommended debugger hardware? I'll be using the Lattice 8k breakout board.
What you have created is certainly very interesting. I have watched your video and read the PDF and other docs with fascination.
This might be a totally wrong forum to discuss such things, but, well, the Propeller 1 is published as Open Source HDL so we are kind of on topic.
I'll be looking forward to trying out the VexRisc on my DE0 Nano. All this FPGA and HDL is new to me after decades of writing software. I was always put off by the complexity and sluggishness of things like Quartus. It's not something that you want to play with for fun. Also FPGA were much more expensive than I could justify. All that has changed with the Lattice parts and things like Icarus and IceStorm. Looks like Spinal will be a great help there as well.
Keeping SBT "warm" certainly helps. Build time for the example project went down to 1 second!
I'm sure InteliJ is fine but I'm kind of done with using a different IDE for every project. Hope to see Scala/Spinal plugins for VS code. I was done with having to learn a new language every couple of years for every new project. I'll make an exception for Spinal as it looks so cool. Shame it's not done in Javascript
Great work, by the way.
Results in:
I did the "...get the SpinalHDL repository and do a "sbt publish-local" in it." thing but it did not help.
Personnaly i'm using this one : https://numato.com/ft2232h-breakout-module/
But normaly any JTAG which is openocd ready shoud be ok, but for sure, ft2232 based ones will be ok.
I also worked with the jtagkey-2.
I'm also using the Lattice 8k breakout board. You can find some stuff to get Murax on it there :
https://github.com/SpinalHDL/VexRiscv/tree/master/scripts/Murax
There is a project named Scala Native : https://scala-native.readthedocs.io/en/latest/
But i think it's to early to use it (But i never tested it, so i just think it)
I just tried with a clean virtual machine, and it passe with the following commands (from zero install Ubuntu 16)
# GIT
sudo apt-get install git -y
# JAVA
sudo apt-get install openjdk-8-jdk -y
# SBT
echo "deb https://dl.bintray.com/sbt/debian /" | sudo tee -a /etc/apt/sources.list.d/sbt.list
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 2EE0EA64E40A89B84B2DF73499E82A75642AC823
sudo apt-get update
sudo apt-get install sbt -y
# Compile latest SpinalHDL
rm -rf SpinalHDL
git clone https://github.com/SpinalHDL/SpinalHDL.git
cd SpinalHDL
sbt clean compile publish-local
cd ..
# VexRiscv
rm -rf VexRiscv
git clone https://github.com/SpinalHDL/VexRiscv.git
cd VexRiscv
sbt "run-main vexriscv.demo.Murax"
ls Murax.v
Let's me know if the issue is persistant. Which OS/Version do you have ?
It's nice to see that building Murax only takes 20 seconds from cold. Keeping sbt warm gets that down to 7 seconds initially then only 4 seconds on subsequent runs. Magic!
I'm using Debian Stretch here. I'm going to try Spinal in the BASH shell for Windows 10...
Thanks again.
I was wondering about those block diagrams that you have - e.g. the diagram for Briey SOC. Do you have a tool that generates code from the diagrams or vice versa?
Also have you used any free tools for CSR (control and status register) generation? (If there is a block digram tool above, then it would sort of fit into that as you would generate the headers based on how everything is wired together.) I've seen some proprietary tools at various companies, but nothing really fully featured in the OSS world. I'm thinking verilog RTL generation, verilog/c header file generation, documentation generation, and verification features. Maybe something like SystemRDL.
Edited to add: perhaps an example of what I'm talking about - https://github.com/Juniper/open-register-design-tool
I don't have tool which generate diagrams, this one was done by hand.
The thing with SpinalHDL is that the language is flexible enough to allow you implementing tools which generate register banks/register mapping : D Which could avoid using multiple languages and losing consistancy between them.
So there is some example.
There is specify the MSTATUS register at the address CSR.MSTATUS as a READ/WRITE one with the corresponding bits at their corresponding place :
READ_WRITE(CSR.MSTATUS,11 -> mstatus.MPP, 7 -> mstatus.MPIE, 3 -> mstatus.MIE)
https://github.com/SpinalHDL/VexRiscv/blob/9fe4e1d54da02bad23073736ca77d8d6e2e90a0a/src/main/scala/vexriscv/plugin/CsrPlugin.scala#L303
or by doing this : mbadaddrAccess(CSR.MBADADDR, mbadaddr)
mbadaddrAccess -> Is a parameter which specify the kind of access (READ_ONLY, WRITE_ONLY, READ_WRITE)
CSR.MBADADDR -> specify the CSR address
mbadaddr -> is the signal
The "magic" which then read the CSR mapping datamodel is there :
https://github.com/SpinalHDL/VexRiscv/blob/9fe4e1d54da02bad23073736ca77d8d6e2e90a0a/src/main/scala/vexriscv/plugin/CsrPlugin.scala#L473
(A switch case with a inner loop which will iterate over each address where there is a CSR specified to generate the corresponding logic)
Another kind of example of automatic register mapping generation in the page 17 of this document :
https://github.com/SpinalHDL/SpinalDoc/raw/master/presentation/en/presentation_eth.pdf
To resume, in SpinalHDL, you can define tools which alow you to build a data model of what you want (specification) and then automaticaly use generate the corresponding hardware/document/C driver
I had a feeling that might be your answer ;-)
Do you have any thoughts on formal verification and how that fits in this flow? If you're trying to stick with open and freely available tools, then this is difficult. But I saw Clifford Wolf working on this in http://symbiyosys.readthedocs.io/en/latest/ Maybe it would be of some interest if you haven't taken a look.
I haven't hardly tried formal verification, but it would fit in the flow as vhdl/verilog/verilator/cocotb verification i think.
Basicaly, with SpinalHDL the idea is, you generate your RTL as a VHDL or Verilog file, and then to verify them, you use the flow that you are used to (traditional verification in VHDL/Verilog or their alternative)
I hear about the Clifford tool, it's a great initiative : D
Project Icestorm may support these soon?
Let's hope so, their embedded ram could be realy practical
That's a nice thread. I had seen references in Clifford's tweets, but this spells out the motivation pretty clearly: "My high level goal is to get a picorv32 going on the chip using the hard IPs. I want to create a board with the Adafruit Feather form factor which can basically replace an M0+ MCU but have the flexibility of custom peripherals or fully custom logic."
It looks like there's a Feather in the works that uses the SiFive chip too:
I don't have much experience either except with equivalence checking. It would seem ideal if the designer would write the assertions in SpinalHDL while doing the design. Given the state of the free tools it doesn't sound like an easy problem. (For example: Clifford advises that one stick with immediate assertions and build checker state machines where necessary.) Anyways this is one area that I want to explore.
You still about?
Back in July I said I would try to get Spinal running on the Linux Subsystem for Windows 10. After a busy time I just found time to do it.
Pleased to say it works fine. Again the verilated Murax boots!
Took a while to install the Win 10 Creators update and then update the BASH shell to Ubuntu 16 so that I could get a JDK 8 installation. It's amazing how many giga bytes of stuff one needs to install now a days to get a program running !
Anyway, I was wondering what is the preferred way to start with a brand new Spinal project. Say one just wants to make a simple component and get it built as Verilog? I imagine it needs a new project directory and some structure in there?
I guess the SpinalBaseProject is a good start. How much of that is actually needed from scratch?