@Diarmuid Collins Congratulations! Using

FP_PIN_ORDER_CFG

, you could set the minimum distance and add a lot of virtual pins. The other way is to use

FP_DEF_TEMPLATE

and a def file to specify fixed locations (see

openlane/user_project_wrapper/config.json

). This overrides any

FP_PIN_ORDER_CFG

settings.

Thanks @Mitch Bailey. I have cloned openlane2 (git clone https://github.com/efabless/openlane2) and I dont see the dir:

openlane/user_project_wrapper/

. Closest thing I could find is: ~/openlane2/openlane/examples/spm-user_project_wrapper However, that didnt contain FP_DEF_TEMPLATE in the config.json file.

Sorry for the confusion. The repo is

caravel_user_project

which I assumed you were already using as your project directory. Do you have a

caravel_user_project/openlane/user_project_wrapper/config.json

file?

@Mitch Bailey So I just need to clone from: https://github.com/efabless/caravel_user_project.git and start running from there? I was running from openlane2 dir. Is the below understanding correct: • Running openlane from the caravel_user_project area sets me up for the caravel chip. • Running openlane from the openlane2 dir is not customer to caravel. If the above is correct. I plan taping out on openframe and not caravel. Do I still run openlane from the caravel_user_project area? Txs

For openframe, please start from the openframe_timer_example repo.

Great. Im not in my Linux environment at the moment so will be cloning the below later: https://github.com/efabless/openframe_timer_example Thanks.

@Diarmuid Collins I’ll tag @Marwan Abbas and @Anton Maurovic because they provide more support regarding tapeout and can explain much clearer than I can. For tapeout with openframe, you will need to push

gds/openframe_project_wrapper.gds

to a git repo on the efabless servers.

Tagging my Efabless account: @Anton Maurovic (efabless support)

Hi @Diarmuid Collins! I hope you've been well. This is the conventional flow using our repositories (whether you are using Caravel or OpenFrame) -- and it automatically installs OpenLane 1.x and the PDK for you locally within your project subdirectory. OpenLane 2 is not yet officially recommended for chipIgnite designs, so stick with the OpenLane 1.x unless you have a specific need. They produce quite similar results, but have different setup requirements... 1. After cloning "openframe_timer_example", go into that repo's subdirectory, and run the following:

# Make sure there's no lingering env vars from OL2 or anything:
unset MPW_TAG PDK PDK_ROOT MCW_ROOT OPENLANE_ROOT
unset OPENLANE_IMAGE_NAME OPENLANE_RUN_TAG OPENLANE_TAG

# Set up the Caravel tools within this repo directory (about 10GB):
make setup

Hi @Anton Maurovic. Thanks for that amazing amount of material. I was working directly on openlane-2 so seems I need to take a step back and start from the openframe_timer_example clone. I'll be doing this over the coming days so will get back you to. Cheers

Sounds good @Diarmuid Collins. OL2 is OK to use, but probably requires a bit more effort and we have less collective effort/documentation in supporting it as yet. For the majority of cases OL1 is still great.

Hi @Anton Maurovic: Just reading through this again - when I run "make setup", a version of the PDK gets installed locally. However, I already have the PDK installed. Up to now I was putting "--manual-pdk" after my openlane comments so it would pick up this installed PDK. Is it ok to do this still for the above setup? I want to avoid having multiple versions of PDK installed as presumably it would eat up my diskspace.

Hi @Diarmuid Collins that is probably OK but with respect to the PDK version just note that for now our standard advice is to use whichever version of the PDK is "verified" for your respective version of OpenLane, and for the default "make setup" that is currently a "known-good for digital PnR" OpenLane/PDK pair from mid-2023. Yes, that does mean using more disk space, but lowers risk. Having said that, although 90% of customers are using this exact version for digital PnR, there is a newer version pair that a colleague (@Marwan Abbas) has found to be good, and it potentially improves OpenLane's performance (while also being compatible with our commercial EF_SRAM IP and our upcoming IP offerings). That involves modifying your caravel_user_project's Makefile to replace these two vars, and then [re]running "make setup":

OPEN_PDKS_COMMIT=bdc9412b3e468c102d01b7cf6337be06ec6e9c9a
OPENLANE_TAG=2024.04.22

I agree with @Anton Maurovic (efabless support). but if you are using OpenLane2, I'd recommend using the default PDK that it installs, OpenLane and the PDK are usually paired together, and tested together, so I don't recommend using different versions, except in some cases where there's a known bug.

I think that statement applies also for OL1, right @Marwan Abbas?

Yes, but for caravel user project, we have a specific OpenLane version and PDK version pair that are in the makefile. Also the pair you sent works great for me.

Great! Thanks for confirming 🙂 So there you go @Diarmuid Collins, that's our official advice. That is known to work well (i.e. both the `OPEN_PDKS_COMMIT`/`OPENLANE_TAG` pair already defined in the Makefile, as well as the pair posted above).

Thanks @Anton Maurovic, @Marwan Abbas. So I will use the reccomended PDK. I presume this reccomended PDK can be accessed by xschem for analog designs? With my manually installed PDK, I would just reference the relevant model files in my xschem files. I presume the same applies here i.e. the PDK will be contained in some sub-dir that I can just add paths to. I guess all this will become clearer when I go through the setup in the next day or so. Cheers

@Diarmuid Collins It should be fine, and it should work well. Your manually-installed PDK is probably already

bdc9412b3e468c102d01b7cf6337be06ec6e9c9a

and in my experience it's good to use for both: xschem & analog designs; and OpenLane digital designs. I personally have done some small mixed-signal designs using it for the analog layouts (and analog/digital integration), though at the time I was using the "default" (mid-2023) PDK for OpenLane to produce the digital block -- on this point, you CAN use different PDK versions for those different (analog vs. digital) tasks and mix their layouts, and in fact you might want to consider looking at the official latest PDK (

0fe599b2afb6708d281543108caf8310912f54af

) in your xschem, because it has a small few updates but also some enhancements to the "top.sch" xschem demo page -- niceties. But... not essential. Stick with

bdc9412b3e468c102d01b7cf6337be06ec6e9c9a

all the way (xschem/analog + openlane/digital) and only make a change if something fails to pass tapeout (though in the case of failing tapeout, we'll usually jump on it to help you out anyway).

Thanks @Anton Maurovic. I'll do that so. Interestingly you said you've done integration of both analog and digital blocks. This was in the openlane flow I presume? If so, is there any documentation on this or examples I can piggy back off since this is ultimately where I want to get to as my intended openframe tapeout will be predominantly analog with some digital around it.

Hi @Diarmuid Collins, in my case I hardened a digital block with OpenLane first, then it was manual layout after that: I did layout for my analog blocks, and placed the digital and analog cells and hand-routed them together. This is not the only way to do it, though. The main thing is that OpenLane can't route decent analog signals... so any technique is intended to make up for that.

Thanks @Anton Maurovic. It will be some months before I get to this stage but good to know I can reach out to you when I do. Cheers