WIP: SDF parsing

[Blebowski]

Hi,

This is initial MR for SDF parser. It is not ready for merge, I send it here just to get some feedback whether
you are OK with it, or whether you would drop it completely. It is almost orthogonal to the rest of the code base.

I keep the same structure of SDF objects as is for the tree/psl/vlog/type. I have extended the object.c code
to encode up to 8 different object types. Its just minor modification of shifts, not sure if it has some negative effect
on the rest of the codebase.

The parser uses YACC similarly as the Vlog stub that you have. I have started from the Vlog in sort of
"copy and change" fashion. The lexer is almost untouched besides defining new mode and adding the
keywords. There is one small conflict if Vlog exists at the same time. For now, I have just commented
the vlog global vars. Eventually, I will need to resolve this, e.g. by adding prefix to the SDF parser.
AFAIK, this is the preffered way to do it once you have multiple generated parsers by YACC.
I didn't want to do it, because the code in scan.c relies on yyval and yyloc for proper lexing and
figuring out the source location. Having all the loc_t infrastructure seemed convenient.

As for the parsing, I use global context to track current cell, delay and delay_kind. I am not sure this
is the preffered way since it turns "context free grammar" into "context dependant parser". However,
SDF grammar is simple, and no recursions occur, so it should not matter. I first tried to keep no
context, and return all crated objects, but the .y file quickly became total mess.

[nickg]

I'm not opposed to adding SDF in general, but I do think it would be better if it did something useful. E.g. ModelSim has a -sdf option to set VITAL generics from an SDF file. So we could have an elaboration option --sdf=typ,file.sdf or similar.

I keep the same structure of SDF objects as is for the tree/psl/vlog/type.

I think it would be better in this case to parse it directly into plain C structs. The object_t infrastructure is mainly useful for automatic serialisation to disk and garbage collection of unused nodes, but I don't think we need either here. E.g.

typedef struct {
   char *design;
   char *vendor;
   ...
   sdf_cell_t *cells;
} sdf_delayfile_t;

typedef struct {
   sdf_cell_t *next;
   char *celltype;
   ...
} sdf_cell_t;

[Blebowski]

I'm not opposed to adding SDF in general, but I do think it would be better if it did something useful. E.g. ModelSim has a -sdf option to set VITAL generics from an SDF file. So we could have an elaboration option --sdf=typ,file.sdf or similar.

That is the plan, but first I need to at least get it parsed/dumped and somewhat checked. I don't expect to have it merged while "doing nothing". I want to put together at least basic Vital annotator and test against some free models and models of older Xilinx FPGA cells.

As for the controlling of the annotation, there is whole bunch of things to be configured, like the root hierarchy where to apply, corner selection, way to treat negative tchecks, disabling parts of tcheks, etc... It will most likely end up with small config file (similar to coverage exclusion, coverage spec files).

I think it would be better in this case to parse it directly into plain C structs. The object_t infrastructure is mainly useful for automatic serialisation to disk and garbage collection of unused nodes, but I don't think we need either here. E.g.

I am not sure. Parsing to structs may be faster, however, dumping the file onto the disk may be needed. I know Xcelium does this trick, where you pass SDF file only once, and it compiles it into a binary compiled form. Then, for next elaborations, you only pass the compiled SDF file and the elaboration and annotation are much faster. That would indicate compile/check is the most time consuming operation, rather than the annotation itself. Even simple SDF files are millions lines of code, so parsing it upon each elaboration may be a bottleneck. This feature helped me a lot during pre TO debug loops with Xcelium.

Either way, If I keep the API in sdf-node.c , the underlying representation of the nodes by structs or object_t should be easy to change.

[Blebowski]

This reminded me a perfect article I read about SDF sign-off gate sims:

http://www.deepchip.com/items/0569-02.html

[nickg]

This reminded me a perfect article I read about SDF sign-off gate sims:

http://www.deepchip.com/items/0569-02.html

Thanks, it's an interesting article. I never used gate level simulation before when I used to do FPGA design.

[Blebowski]

Its rather uncommon to do gate sims in FPGA devices. If something does not work, you simply generate new bit-stream. Commercially, I have seen it only in Aero-space design that needed to meet DO-254 certification.

The feature is rather used in ASICs, where it can help to discover bugs in the clock tree, reset tree, etc... It helps to reveal bugs, that cause your silicon to never come out of reset. And even with ASICs, since the devices got much more complex over the past years, SDF annotating full design with 100M+ gates is barely feasible. People still do gate-sims, but mostly zero delay to check e.g. ATPG pattern. Those simulate much faster if the simulator has parallel event processing (lot of events in single simulation time).

Still, I think SDF annotation is extremely usefull when you do smaller chips (lets say below 10-20M gates). Especially when you have heavily clock gated design, use non-reset flops to save area, or use other "non-standard" design techniques.

[nickg]

@avelure mentioned they do VHDL gate-level simulation with back-annotation using the output from the Microsemi toolchain. It would be good if we could get that flow working here.

[Blebowski]

OK, I will keep that in mind. @avelure do you know where I could find the VITAL models of Microsemi / Microchip FPGA cells? I have tried to install latest Libero, and search through the installation for VHDL files that include vital keyword, but I can only find the Vital packages themselves, or some "dummy" examples.

I would expect, that after PnR i can write down the VHDL netlist and SDF. Then, If I compile Vital cell models + netlist, I can annotate the design.

[avelure]

Microsemi changed to verilog libraries in the later Libero versions unfortunately. However we are using some older devices, the Proasic3 and RTAX, which are anyway not supported in the later versions. You need to install Libero 9.2 SP4. You will then find the device libraries with vital annotations in Designer\lib\vtl\95[proasic3e.vhd|axcellerator.vhd]
Libero\designer tool can output a VHDL95 backannotated netlist with SDF.

[Blebowski]

Perfect, thanks, that is exactly what I was looking for.