The top level module in Xilinx ISE 11.1 projects
apparently cannot contain 
more than one VHDL architecture. If that module is already the top level in 
the project, both (all) architectures are marked as top-level in the Design 
pane Heirarchy view. Both architectures are apparently synthesized. (Device 
utilization approximately doubled.)

Neither top level architecture is available to select as the Top Level 
Module, as they are already top-level from the tool's point of view. Setting 
some other module as top level temporarily allows reselection of the 
intended top-level in the tool. However, doing so causes _pn.exe to spin 
continually and Project Navigator to become unresponsive. The Project 
Navigator status bar flashes "Generating Summary Page", while _pn.exe spins 
at 100% of its core. Killing the ise.exe process (minutes later) leaves the 
_pn.exe process orphaned, still spinning at 100%. _pn.exe has to be killed 
manually. (Win XP, 32-bit.)

Setting the top-level module and architecture using TCL has the identical 
effect. (project set top RTL fooModule). _pn.exe spins, while PN flashes 
"Generating Summary Page" in its status bar.

ISIM post-route simulation apparently also has problems with multiple 
architectures. One architecture is consistently selected over the other, 
perhaps by first in alphabetic order. Direct instantiation with entity 
work.<module>(<arch>) does not find the module in work. Behavioral 
simulation worked fine with this notation. I didn't pursue this further.

Selecting the desired top level architecture for implementation, in the 
Design pane heirarchy, does not influence the behavior. Both architectures 
are synthesized.

Most curious of all, commenting out the extraneous architecture in the VHD 
module has NO EFFECT on synthesis and implementation UNTIL the project files 
are removed with the Project menu|Cleanup project files... Example 
indications: Device utilization still shows the bloated size; the synthesis 
report lists FSM encodings for modules referenced only from the "deleted" 
architecture; the map report lists utilization from modules no longer 
referenced; etc.

Last, the .XISE project file became no longer usable, whether from the 
thrashing it received or from some other garbage. Opening the project in ISE 
caused it to crash with a messagebox. I had to recover the project file from 
version control.

The errors are easy enough to reproduce. Add a second architecture to the 
top level VHDL module in the project.

[Addendum]: ISE continues to crash with an
exception messagebox during 
startup with that .xise project, even after recovering an old version of the 
<project>.xise file from version control. Deleting and recreating an empty 
project directory solved the problem.


"MikeWhy" <b...@yahoo.com> wrote in message 
news:AoFSl.27311$c...@nlpi065.nbdc.sbc.com...
> The top level module in Xilinx ISE 11.1 projects apparently cannot contain 
> more than one VHDL architecture. If that module is already the top level 
> in the project, both (all) architectures are marked as top-level in the 
> Design pane Heirarchy view. Both architectures are apparently synthesized. 
> (Device utilization approximately doubled.)
>
> Neither top level architecture is available to select as the Top Level 
> Module, as they are already top-level from the tool's point of view. 
> Setting some other module as top level temporarily allows reselection of 
> the intended top-level in the tool. However, doing so causes _pn.exe to 
> spin continually and Project Navigator to become unresponsive. The Project 
> Navigator status bar flashes "Generating Summary Page", while _pn.exe 
> spins at 100% of its core. Killing the ise.exe process (minutes later) 
> leaves the _pn.exe process orphaned, still spinning at 100%. _pn.exe has 
> to be killed manually. (Win XP, 32-bit.)
>
> Setting the top-level module and architecture using TCL has the identical 
> effect. (project set top RTL fooModule). _pn.exe spins, while PN flashes 
> "Generating Summary Page" in its status bar.
>
> ISIM post-route simulation apparently also has problems with multiple 
> architectures. One architecture is consistently selected over the other, 
> perhaps by first in alphabetic order. Direct instantiation with entity 
> work.<module>(<arch>) does not find the module in work. Behavioral 
> simulation worked fine with this notation. I didn't pursue this further.
>
> Selecting the desired top level architecture for implementation, in the 
> Design pane heirarchy, does not influence the behavior. Both architectures 
> are synthesized.
>
> Most curious of all, commenting out the extraneous architecture in the VHD 
> module has NO EFFECT on synthesis and implementation UNTIL the project 
> files are removed with the Project menu|Cleanup project files... Example 
> indications: Device utilization still shows the bloated size; the 
> synthesis report lists FSM encodings for modules referenced only from the 
> "deleted" architecture; the map report lists utilization from modules no 
> longer referenced; etc.
>
> Last, the .XISE project file became no longer usable, whether from the 
> thrashing it received or from some other garbage. Opening the project in 
> ISE caused it to crash with a messagebox. I had to recover the project 
> file from version control.
>
> The errors are easy enough to reproduce. Add a second architecture to the 
> top level VHDL module in the project.
> 

On Mon, 25 May 2009 17:58:40 -0500,
"MikeWhy" <b...@yahoo.com> wrote:

>The top level module in Xilinx ISE 11.1 projects apparently cannot contain 
>more than one VHDL architecture. If that module is already the top level in 
>the project, both (all) architectures are marked as top-level in the Design 
>pane Heirarchy view. Both architectures are apparently synthesized. (Device 
>utilization approximately doubled.)

Is this something you have used in previous versions of ISE, i.e. a regression,
or something you hadn't tried previously?

Are both architectures in the same file?
If they are in different files, do the symptoms differ?

Previous ISE versions have had problems recognising design units and selecting
the correct design unit, both (a) because they couldn't handle configurations
correctly (or even see them at all, unless there was an ent/arch in the same
file!) and (b) because they didn't implement the VHDL library/use clauses.
The latter was to be fixed in 11.1, according to previous reports from Xilinx.

I haven't seen across this specific example in 10.1.
Then I haven't specifically looked for it, but I have compiled two architectures
in separate files for the same entity, and had trouble making it select a
specific arch either through configurations or embedded configuration
statements.

I was looking forward to a shiny new version that cleared up the whole mess...

- Brian

"Brian Drummond"
<b...@btconnect.com> wrote in message 
news:0...@4ax.com...
> On Mon, 25 May 2009 17:58:40 -0500, "MikeWhy"
<b...@yahoo.com> 
> wrote:
>
>>The top level module in Xilinx ISE 11.1 projects apparently cannot contain
>>more than one VHDL architecture. If that module is already the top level 
>>in
>>the project, both (all) architectures are marked as top-level in the 
>>Design
>>pane Heirarchy view. Both architectures are apparently synthesized. 
>>(Device
>>utilization approximately doubled.)
>
> Is this something you have used in previous versions of ISE, i.e. a 
> regression,
> or something you hadn't tried previously?

I haven't tried previous to 11.1.

> Are both architectures in the same file?
> If they are in different files, do the symptoms differ?

The architectures are in the same file. I did not try separating the arch 
into different files.

> Previous ISE versions have had problems recognising design units and 
> selecting
> the correct design unit, both (a) because they couldn't handle 
> configurations
> correctly (or even see them at all, unless there was an ent/arch in the 
> same
> file!) and (b) because they didn't implement the VHDL library/use clauses.
> The latter was to be fixed in 11.1, according to previous reports from 
> Xilinx.
>
> I haven't seen across this specific example in 10.1.
> Then I haven't specifically looked for it, but I have compiled two 
> architectures
> in separate files for the same entity, and had trouble making it select a
> specific arch either through configurations or embedded configuration
> statements.
>
> I was looking forward to a shiny new version that cleared up the whole 
> mess...

I could almost forgive it as a GUI tool issue, but the double implementation 
even with the "extra" architecture commented out in the source makes the 
situation extremely scary. Once the build is polluted this way, the 
intermediate files need to be removed to recover. It also raises questions 
about what else is tagging along, hidden, in the intermediate files after 
the code is modified.

ISE drives me crazy!

One of the most powerful features of VHDL is the ability to handle 
multiple architectures and configurations for the same entity.  This 
makes for efficient simulation, regression testing, and promotes code 
reuse.  

I've spent way too many hours trying to figure out problems with 
ISE synthesis (XST).  I have tried various permutations of 
configurations, separate files for each configuration, using just 
a single configuration file in the project, all to no avail.  The 
GUI always seems to display the incorrect architecture.  Now, I 
"think" this is just a GUI anomaly and in actuality the tool 
knows which architecture bind.  But, when you need to use the GUI 
to help diagnose a synthesis problem how do you trust it?  The only
thing you can do is let it rip the use the (terrible) schematic RTL
viewer to get a sense of what it did.  This is not efficient if you
tend to have a heavily scripted development flow.  Who wants to look
at the RTL view for every regression?


Same files, same configuration used with Synplicity and everything
is great!  I always know what architecture it is going to use, and 
(get this) I can select which top-level configuration to synthesize!  
However many times Synplicity has difficulty closing timing or I can't 
check-out a license because someone else has it tied up (but that's 
rant for a later time).  Plus, Synplicity is expensive compared to 
ISE (OK, you get what you pay for).
 

It's one thing to be frustrated because I cannot get a design to 
synthesize with XST.  It's another problem altogether when it 
synthesizes incorrectly!  I spent a lot of time debugging why some
logic was getting optimized away.  Turns out XST did not use the 
architecture it was instructed to use at a lower level in the design.

Bottom line:  
Xilinx cannot handle VHDL configuration constructs properly. So until 
it does, I will have to overcome my loathing to dumb-down my code andscripts in order to accommodate Xilinx. 
 

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

<snip>

>Bottom line:  
>Xilinx cannot handle VHDL configuration constructs properly. So until 
>it does, I will have to overcome my loathing to dumb-down my code and
>scripts in order to accommodate Xilinx. 
> 

The Design Manager GUI isn't clever in the way it handles conditionalgenerates, either. Thus I haven't told it the whereabouts of the filecontaining the behavioural model of one of the sub-modules that mostly Iuse when simulating, in case XST tries to synthesize it!

My experience is that synthesis tools are less smart with regards togenerates and configurations than simulators (ModelSim, at least).
	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com