FPGA-specific passes in FIRRTL

[jjb...@gmail.com]

Hi there,

First of all I would like to thank all chisel/firrtl contributors for the hard work, done and still on-going !

I am just starting an industrial PhD in France which focuses on "Abstracting FPGA development flows" and it is thrilling to see a growing interest for open-source tools and contributions as well in academic researches as in the industry.

In the ICCAD2017 paper about reusability, it is a lot question of adapting the various FIRRTL passes to the final target FPGA or ASIC, for example when it comes to memory primitives.

Going forward, we have already some ideas to tweak chisel/firrtl towards our FPGA-specific needs but we first would like to know if there is currently some on-going work on this particular topic ?

In any case we would be more than a happy to share with you and contribute back to the community.

Cheers,

John

[Edmond Cote]

<+ Eric>

I did some work on this before changing focus.

If I recall, there is this .conf file interface that describes behavioral memories. Take that file (or generate a pass that consumes that data, does transforms, etc.) and generate your own FPGA-specific memory compiler (or tighten up the interface w/ FPGA vendor compiler). Rocket Chip repo has the vlsi_mem_gen script that you could (but probably shouldn't, its ugly) use as an example.

https://github.com/freechipsproject/firrtl/blob/75284395ba7ef285daefd2da38e720590b465ad7/src/main/scala/firrtl/passes/memlib/ReplaceMemTransform.scala#L49 

 

... but all of this is old info, I wonder if and/or how things have changed (i.e., I see some YAML interface, memory decorators, etc.)

This paper has some potential transforms that you could develop: http://fpgacpu.ca/multiport/TRETS2014-LaForest-Article.pdf

Not FPGA related, but you could also directly target OpenRAM (only single port though, hence the challenge).

Drop me an e-mail if you have questions or wish to brainstorm.

--
You received this message because you are subscribed to the Google Groups "chisel-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chisel-users...@googlegroups.com.
To post to this group, send email to chisel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/680896dc-42e4-49b7-8f3f-3ae54721ec43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jack Koenig]

Hello John!

Thank you for your interest and for reaching out!

To my knowledge, most development of Chisel and FIRRTL has targeted toward ASICs, so I am delighted to hear about your interest in targeting FPGAs and I would be happy to assist where I can.

As Edmond mentioned, the general approach (historically) for memory customization has been using ReplaceMemTransforms (the --repl-seq-mem argument to FIRRTL) which generates a .conf file that the vlsi_mem_gen script uses to pick appropriate memory macros from the ones available for a given technology.

I'm not super familiar with it, but there has been recent work on HAMMER for abstracting VLSI flows, and I believe it uses the MacroCompiler in barstools.

Other interesting related work, although geared toward using FPGAs as simulation platforms rather than as targets in themselves is MIDAS and Firesim. MIDAS (which Firesim is built on) makes extensive use of FIRRTL transformations to specialize the RTL for FPGA-hosted simulation of target ASIC designs.

The Chisel/FIRRTL developers meeting is on Fridays (starting up again next week), from 1-3 pm PST. If you have the time and interest it would be great for you to stop by there. I would also be happy to find another time to chat about your ideas and how we can go about integrating them.

Cheers,

Jack

 

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/CALzVNFC9ov%2BRE5ZP77UdfjMF7c262CAGH1ihcHpzmGywn5Ws8Q%40mail.gmail.com.

[Jack Koenig]

I forgot to include a few other things!

We recently had the first Chisel Community Conference. There are great presentations on many of these topics--including intensives on the internals of FIRRTL, writing libraries for Chisel/FIRRTL, and Firesim and MIDAS. You can see the videos on YouTube. Unfortunately, someone (me) forgot to record the intensive for Chisel internals, but we plan to re-record it at some point in the near future.

I would also like to point out FPGA shells which provides a layer of abstraction between the resources provided by different FPGAs and those actually needed by a particular design. This makes it easier to map many different designs to different FPGAs without having to specialize particular designs for particular FPGAs. I talk about it a little (at a very high level) in my ORConf talk (it's the last of 4 topics in that talk). The SiFive Freedom platform uses FPGA shells.

~Jack

[jjb vhc]

Hi Jack & Edmond, thanks a lot for your answers.

Concerning memory customization, I was not considering it as a priority but there is indeed a lot of interesting stuff in the article you shared.

FPGA shells are also an interesting concept, that we might dig especially when it comes to abstracting PCIe layers.

However and to be perfectly honest this will not be a priority either since we have a large existing infrastructure composed of costly FPGA boards.

Hence for us, adding a new board reference in such an infrastructure, is a strategic move and often a cost-driven decision.

As it is rare, assigning an engineer on adapting the top module and the constraints file is not a big deal.

To introduce my first contribution idea, let me set a bit of context:

1. Routing FPGA is hard and long (especially Xilinx's ones but that is not the point)

2. Reset is primordial on ASIC since at t=0 (power-up) register's states are unknown

3. FPGA offers the ability to set any register at a precise state at t=0 (programming)

and a simple way of expressing this in verilog is for example reg my_valid = '0;

4. Using this "programming-reset" allows us to kick out the reset tree routing constraint which highly improves the routing capabilities of the design

5. Chisel offers automatic clock & reset inference, which is nice but comes with a drawback for us :

val my_valid  = RegInit(false.B) will infer a synchronous reset process for my_valid which is not what we want.

I would hence like to somehow add an option to FIRRTL in order to would translate Chisel's val x = RegInit(value) into (downto verilog) reg x = value;

Actually I don't know what could be the best way of doing this :

- Adding a new construct to Chisel ? Such as RegT0()

- Adding an option to RegInit ? Such as RegInit(value, method)

- Adding an option (global/local?) to FIRRTL to use a different transform which would translates reg my_valid : UInt<1>, clock with : (reset => (reset, UInt<1>("h00"))) into another form

Additionally register randomization should be turned off on those registers.

I would be glad to hear your inputs on this first idea and to join the next Chisel/FIRRTL developers meeting (on Friday, January 7 ?), just let me know how to reach you technically speaking.

John

To view this discussion on the web visit https://groups.google.com/d/msgid/chisel-users/CAFooY_SH%2Bd%3D65QvKLRtVr_swM13nnXA6o0EW9eif4MrH9irdGg%40mail.gmail.com.

[Schuyler Eldridge]

I'm in favor of your third option. 

The overall aim of the Chisel/FIRRTL hardware compiler framework is that the front end (Chisel or others) is decoupled from the middle end (FIRRTL Compiler) and the back end (Verilog emitter or others). What it seems like you want is to change only the back end emission behavior. It would seem to be very heavy handed to introduce a construct at the Chisel level or in the FIRRTL IR level, that is coupled to a particular back end (an FPGA).