Design Entry

[julio_avr]

Hi,

I need to target multiple different devices (S3E, S3A_DSP, S6) from a common set of design files, and I'd appreciate some feedback/suggestions on the possible ways to handle the generated cores (not all logic can be simply inferred from RTL).

1. Keep a single set of cores, and use the "Regenerate Core" "Under Current Project Setting" process option (TCL or GUI flows), when creating and building for a particular target device.

2. Create a separate core directory per target device and associated coregen projects, and regenerate in each directory all the required cores.

I use TCL to generate for each device/RTL combination a separate project (ISE 13.2-13.4 under Win7) in separate directories, and trigger a build. The script also takes care of cores and logic that don't relate to a particular target device. 

Questions:

-When a project is created and built from scratch, when does the regeneration take place? (after synthesis?)

-Does this re-generation happen everytime a build from source files happens, if the project was already created?

-When a core is regenerated, is it done in place (i.e. on the directory containing the cores) or in the build directory?

-What happens if I remove the line below from the TCL script that creates the ISE project? (no rebuild happens?)

  project set "Regenerate Core" "Under Current Project Setting" -process "Regenerate Core"

-Any other advantages/disadvantages of re-generating the cores on every build?

Thanks!

Julio

[rcingham]

We use the "separate core directory per target device" methodology here (for Virtex-4 and two Virtex-5 sub-families) and can make it work ok, including building "production" devices from scripts. Not sure I can answer the rest of your questions, though.

[howardp]

-When a project is created and built from scratch, when does the regeneration take place? (after synthesis?)

[howardp] What flow are you using?  If Project Navigator: then regeneration only happens when the user specifies.  If synthesis is run and the needed files associated with a core .xco file do not exist, they should be given the choice to generate at that point.  Otherwise, it the files exist, they will be used as they are whether they were generated for the current architecture or not.

If you are using PlanAhead for project control, generation happens automatically as part of Synthesis process if the files do not exist (no user dialog as in Project Navigator).

If you use a Generate_core statement in the HDL (not generally recommended) the generation will happen every time synthesis is run.

-Does this re-generation happen everytime a build from source files happens, if the project was already created?

[howardp]  If the core and all of the associated files exist, it should not need to be regenerated.

-When a core is regenerated, is it done in place (i.e.. On the directory containing the cores) or in the build directory?

[howardp] It is regenerated relative to the location of the xco file.  If you wish to not over write a master xco file, you should use the copy file to project option.

-What happens if I remove the line below from the TCL script that creates the ISE project? (no rebuild happens?)

  project set "Regenerate Core" "Under Current Project Setting" -process "Regenerate Core"

[howardp] Nothing, that is just a project process setting.  If you run that process later, it will regenerate the core under using the current project settings.

-Any other advantages/disadvantages of re-generating the cores on every build?

[howardp] Biggest disadvantage is the time it takes if you have a lot of cores.  Depending on the verification procedures and requirements, the generated netlists may have to be reverified.

If you are going to regenerate for a new project, I suggest you also upgrade to the latest version of the core at the same time.  That way you know all of the project cores are targeting the current project device and are the latest version of the core.

[julio_avr]

Hi Howard,

From your reply, it looks like core regeneration has to be triggered by hand, when the .VHD/.NGO files don't exist, using the existing and related .XCO, is this correct?

The idea is to target multiple devices from the same scripts and source code, but I need some guidelines as to how to handle the cores, and the advantages/disadvantages of the strategies below: (I'd appreciate any recommendations as well)

-generate a single set of cores for the older (or newer?) device, and feed them to all devices

-re-generate the cores for each device, keeping them in separate directories

I'm currently using a series of TCL scripts that create a project file for Project navigator, and these are loosely based on the TCL script generated from that tool. In this way, I can fully build for a particular device from the scripts, or just create a project and then run the Project navigator GUI to build it an analyze it.

The scripts can handle a somewhat different set of files or cores, according to the target device.

Thanks!

Julio

[howardp]

I think it is really a matter of preference.

What is easiest for you to maintain and verify that the cores sources were generated correctly for each device.

Personally, I prefer re-generating the core(s) for each device in a separate directory.  That way I know that all the cores in a specific directory or project are valid for a given device.

However, a good script can make it easy to change a device and regenerate a core or set of cores. 

If you look at hte .xco file, you will see that it is just a command file that sets the IP core properties and generates a core.  Running "coregen -b <core_name>.xco" executes the commands.