Support for third party testbench wrappers

[DHWinterWolf]

I've run into a bit of an issue creating a suitable core file for a project I'm working on that uses Altera's DDR3 controller IP for Arria 10. Synthesis is great - you can supply the QSys and IP files in the core file, Edalize creates appropriate TCL for adding them to the project and Quartus processes them fine. The issue comes with simulation, which I'm attempting to perform in ModelSim.

The problem here is that the DDR simulation models don't work if you just run your testbench as normal. They provide a TCL script declaring procedures that get run from within ModelSim, taking parameters including the same of the actual testbench to run. These TCL procedures seem to be tied in to the exact version of the DDR controller IP being used, so for example upgrading Quartus products one that, whilst having a compatible interface, does some quite different things when you run it to set up the simulation.

The running of these procedures replaces the vsim call that Edalize uses to start a simulation. I was wondering how best to handle situations like this. It looks like it should be possible to include a TCL file that runs the DDR simulation procedures to get the testbench set up and run, but then I think it would still try to run the top level using vsim afterwards, which would fail.

It's not clear to me what the best way to handle this is in a general way - obviously we don't want to end up with a special case for Altera DDR and any other core that has unusual simulation requirements like this. However, I wondered if there is merit in maybe having an option to avoid the vsim call, if the simulation is handled in some other way (such as a TCL file being included in the fileset)? Or is there some better way that might handle this in the general case, do you think?

[DHWinterWolf]

I'm currently working around this by supplying a TCL file in the fileset that performs the actual simulation. However, empty top level lists are not supported in a target, so I've had to create a dummy entity and architecture that do nothing, and specify this as the top level in the target. It isn't ideal, but it does work. I'm wondering if supporting an empty lop level list might be a neatest way to handle testbenches that need to be explicitly scripted like this?

[olofk]

Hi,

Sorry for the lack of replies. This does sound like a tricky problem. Very annoying that they need their own setup to achieve this. Good to hear that you managed to hack your way around this at least.

I'm not sure either which would be the best way to handle this. Allowing an empty toplevel list could be one way to achieve what you're looking for. Perhaps allowing to override the simulation run command could be another. Right now I think you're in a better position than me to judge what would be the easiest and least intrusive way to support this. Also trying to think of similar issues and if this would help in those cases as well

[wespiard]

I'm starting to consider tools like FuseSoC or just using Edalize, and this issue with simulating Quartus IP has been the thing I'm worried about the most.

As @DHWinterWolf described, to simulate IP (even floating point entities, not just DDR3 controller IP, for example) you have to generate a simulation setup script from Quartus, open your simulator (Modelsim), then call said setup script.

@olofk Two years later, any new ideas on how to easily handle this, or new features that have already been added since the original post?