Help with design low-level HDL language

[XVilka]

FPGA world suffers a lot from fragmentation - some tools produce Verilog, some VHDL, some - only subsets of them, creating low-level LLVM-like alternative will help everyone, so HDL implementations will opt only for generating this low-level HDL and routing/synthesizers accept it. LLVM or WebAssembly - you can see how many languages and targets are supported now by both. With more open source tools for FPGA this is more feasible now than ever.

See SymbiFlow/ideas#19

[zhutmost]

Maybe have a look at FirRTL?

[XVilka]

@zhutmost if you open a link - it indeed discuss FIRRTL as the most probable candidate for this.

[Dolu1990]

@XVilka

It would be great to have a proper netlist language, free of the event driven paradigm.

My issues with FirRTL are : (correct me if i'm wrong, i'm not necessarly updated)

• Quite weak clock domain support (no falling edge, no active low reset, no asyncronus reset, no FPGA bistream reset)
• As far i know there is now support for Signal/components attributs (Quite often use by synthesis tools to give directives as KEEP, RAM_STYLE, ...)
• Driven by the Chisel needs (for the moment, which is a subset of what everybody need)

[Dolu1990]

Ahh another issue which is probably in FIRRTL (need to check) is that you can't assign some bits of a combinatorial signal. Ex :

myWire(4 downto 2) := miaou

[Nic30]

@Dolu1990 If clock domain support is so weak in FIRRTL it is a serious problem and it has to be fixed. I mean, do they have an issue about this?

[Dolu1990]

@Nic30 https://github.com/freechipsproject/firrtl/issues/219 => low priority ^^

[Nic30]

That is bad, anyway maybe we do not need an extra language maybe some library of in memory representation of HDL and to generate/parse HDL would be sufficient.

Maybe an extra language just adds the limitations and complexity and actual profit is not so big.

I do have Verilog/VHDL parsers and HDL generators of various Verilog/VHDL and SystemC standards. (VHDL generators and parsers are tested quite well, for Verilog I am currently writing a Verilator-based verification environment which will test all designs we have.) It sounds good but half is in C++ and second half in Python3.

My question is what you think? Should I rewrite it to pure C++ and create wrappers for Java/Python (1-2M) or FIRRTL will somehow catch up?

[Nic30]

I was thinking that java-C++ api is nightmare to maintain and compile for new user but it does not seems to be the case, for python it is easy and often used.

[XVilka]

Even with FIRRTL it would be required to reimplement it in C or C++, since it is now Scala, which is far from being friendly as a native library. On the other hand reusing the same language as FIRRTL will ease testing, speed writing, etc, even with reimplementing it in C++.

On Fri, Nov 23, 2018, 5:21 AM Nic30 <notifications@github.com wrote:

I was thinking that java-C++ api is nightmare to maintain and compile for new user but it does not seems to be the case, for python it is easy and often used.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SpinalHDL/SpinalHDL/issues/158#issuecomment-441121707, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMZ_b25SeMPq9EsqK9kwtn4wCHgjulwks5uxxVlgaJpZM4YmWPF .

[Nic30]

@XVilka I know, but problem is that the Scala is compatible only with itself. Or is is complicated to use Scala code from Java for example?

[Dolu1990]

I'm not use to that kind of things, but i'm not sure it make sense to use java when you can do scala, realy, it's more adictive than cocaine :p

[dronox]

Just to report some experiences: I implemented a VCD parser based on JavaCC (generates Java code), that uses a Scala backend to invoke for some parser rules. There is no issue, you can import your Scala classes into Java code and it feels like usual Java. If you use Scala's collections, there are corresponding converters between Scala <-> Java world which you only have to import by using import scala.collection.JavaConverters.*; (afterwards you can invoke .asScala on any Java collection or .asJava vice-versa). So, basically it's not a big deal to use Scala, libraries from within Java.

[XVilka]

Java/Scala/etc are a no-go if you want other non-Java tools to use it as a library.

[Nic30]

@dronox , @Dolu1990

So, basically it's not a big deal to use Scala, libraries from within Java.

God.

Java/Scala/etc are a no-go if you want other non-Java tools to use it as a library.

Technically is it possible to link JVM in to C++/Python/Rust :D and I am very afraid that the situation requires this. I would be already using Scala if it has generators. I mean this is not a generator http://notes.backgroundsignal.com/Generators_in_Scala.html it is use of function pointer.

And there is only one problem with it. The simulation is much much more complicated without generator data structure. The raise in complexity when randomization is used is like exponential.

[XVilka]

While everything is possible I would not expect that people will do that. Much easier and less scary way is to not use it at all in your code. So if you want wider adoption - there are some amends to be made.

On Sat, Nov 24, 2018, 7:08 PM Nic30 <notifications@github.com wrote:

@dronox https://github.com/dronox ,@Doulu1990

So, basically it's not a big deal to use Scala, libraries from within Java.

God.

Java/Scala/etc are a no-go if you want other non-Java tools to use it as a library.

Technically is it possible to link JVM in to C++/Python/Rust :D and I am very afraid that the situation requires this. I would be already using Scala if it has generators. I mean this is not a generator http://notes.backgroundsignal.com/Generators_in_Scala.html it is use of function pointer.

And there is only one problem with it. The simulation is much much more complicated without generator data structure. The raise in complexity when randomization is used is like exponential.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/SpinalHDL/SpinalHDL/issues/158#issuecomment-441359934, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMZ_a0LD_igczlKXoALB3Tr7kgMUD3Qks5uySiTgaJpZM4YmWPF .

[Nic30]

I am very afraid of this problems:

1.

• No one will rewrite their code to use some unknown library, which does not give them clear profit.
• Using such a library will not be profitable unless many project will also use it.

2.

• Lang. not based on JVM can not use Scala.
• Lang. based on Scala already have their implementation.

[numero-744]

As of 2022, providing a low-level language does not seem to be SpinalHDL's goal (yet?). It would be another project and the link with SpinalHDL would just be "generate code in this new low-level language".

So I guess this issue can be closed now.

[Dolu1990]

Right :)