Adding support for ASIC synthesis

[sjalloq]

• added 'stdcell' arch option
• added 'verilog' output format option
• added 'tech_lib' option to specify .lib
• updated Jinja templates

[sjalloq]

This update allows the user to specify an ASIC synthesis flow using a standard cell library using:

    tools:
      yosys:
        arch: stdcell
        tech_lib: /some/path/to/your/std/cell/library/cell_name_tt_typical_max_1p50v_25c.lib
        output_format: verilog

I also noticed that even though the scripts and Jinja templates support selecting an output_format, this is ignored and all output file formats are generated. Is that a mistake? Happy to fix the template for that but wanted to ask.

[sjalloq]

OK, think that does it from my side. I now know more about your pytest setup.

[mithro]

FYI - @olofk

[olofk]

This is great! Thanks. Regarding the output format, it's a bit of a mess for no good reason other than no one bothered to clean it up so far. The original problem I had was that arachne-pnr and nextpnr needed different file types so in the end I found it easiest to just generate both and from there it has grown.Would be great to fix that though. I always get these annoying warnings from the edf generator, which isn't even used in the flow

Anyway, two questions.

1. Do you happen to know if stdcell is what would be used for the openlane flow? I'm asking because I'm about to start a project to do a full openlane edalize backend so it would be good to a) learn a bit and b) see what is already in place

2. How would the tools normally find the tech_lib? From the test case you added I get the feeling it's a .lib file and that the user is expected to tell the tool where to find it. I see you set it as a tool option which is not optimal for files. While Edalize should be useful on it's own I also greatly care about how a FuseSoC user would interact with it, and having it as a tool option means that the user either needs to write a hard coded path in the .core file (this is not portable between machines) or specify it on the command line every time (which is also a bit cumbersome). A better way would be to have a new file type instead and have the yosys backend pick out these files. And to follow up on that, a) are these Liberty files? If so, there's a libertySource file type defined in IP-XACT (which is what we use when we can for file types) and b) can you specify multiple .lib files?

[sjalloq]

Hi, I might try and clean up the output formats at some point then but as you say, it's not that horrid.

On your questions, for 1) the issue I think is that this changes not only between EDA vendors but also between companies and even between teams within the same company. I picked stdcell just so that it would be easily understood. I've not looked at OpenLane in much detail yet but most flows would load in multiple libraries for different corners etc. For Yosys I just wanted a quick way to run a basic synthesis to get some comparative cell counts.

On 2), yeah, in my experience all back end files are installed in a central location and mapped to all machines via NFS so they're always file paths to fixed locations. All machines I work on are either a cluster with a shared file system or a number of standalone servers that NFS mount NAS locations. I think this is for a number of reasons including the size of the installation and security. Technology files for advanced nodes tend to come with strict stipulations on who has access so they tend to be locked down.

Regarding the file paths, I'm pretty new to Fusesoc so am still learning but yes, these are Liberty files and yes, you'd normally supply a number of them depending on the MCMM capabilities of your tools. But then if you're using proper tools, you've probably got a team running the flow using some sort of vendor reference flow, not Fusesoc.

[olofk]

I think part of this functionality is still of interest, but I would like to take a fresh look as things have moved forward and also now that I better understand myself.

I'm about to merge a patch that adds verilog output, so that part should soon be taken care of. I also think that we should make yosys recognize the filetype libertySource rather than adding a tech_lib parameter. The only remaining question I have is what to call the arch when we just run the synth command. I'm inclined towards running that when arch is not defined at all. Think that would be the most symmetrical thing to do but I'm not sure if that makes sense.

[shareefj]

I haven't even looked at this since I made the PR so can't remember much about it now.

[olofk]

Should we just close it then and open a new one if the need arises again?

[shareefj]

Yeah, I'm not using Yosys any more.