Re: Xilinx ISE ver 8.2.02i is optimizing away and removing "redundant" logic - help!

On 12 Sep 2006 08:34:10 -0700, james7uw@yahoo.ca wrote:

>> What you need to do is to simulate the post-map VHDL file and trace it back
>> to why output signal 'x' at time t is set to '0' but when you use your
>> original code it is '1'.  Use the sim results from using your original code
>> as your guide for what 'should' happen and the post-map VHDL simulation for
>> what is actually happen and debug the problem.
>
>I agree that finding out what is going on is the best
>approach. Do you have any debugging tips other than comparing
>the simulation results in detail and seeing what logic calculations
>must be getting removed?

One tip: instantiate both behavioural and post-map modules in your
testbench, and run them in parallel. You can assert on differences in
the outputs, and trace internal signals in the wave window (to the
extent that you can still recognize internal signals). 

Possibly also set breakpoints on differences in internal signals which
ought to be the same.

- Brian

Handy link for this entire thread:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

Thank you for your advice! I'll try to keep this thread
posted if and when I find answers.

Best regards,
-James

Handy link for this entire thread:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

Xilinx tech. support said to separately register each level of logic,
since I have some lines of up to four xor statements being assigned to
a signal. I tried that, but it didn't help. However, the sub-module in
which the mapper is connecting two of my output registers together,
works on its own in in a separate project in post-map simulation when
those output registers are treated as port signals. It works on its on
without or without the added registers that do one xor at a time, but
still cross-connects with or without the added registers when used as a
submodule of user_logic.

Clearly I am dealing with undocumented features of the mapper; certain
coding techniques are required in order for it to accomplish my intent.
Xilinx really should be documenting these requirements; it's not fair
to tell people that "the problem is with the way you write your VHDL"
otherwise. Documentation for synthesis and translate is much better.

-James

Handy link for this entire thread:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

I tried adding a separate level of registering in my main
line VHDL code and was trying to test it when the ModelSim
simulator died. No clock; therefore no signal processing. The
transcript
(output window) looks normal and ends up with:

# ** Failure: Simulation successful (not a failure).  No problems
detected.
#    Time: 1320 ns  Iteration: 0  Process: /user_logic_tb/line__94
File: user_logic_tb.vhw
# Break at user_logic_tb.vhw line 273
# Simulation Breakpoint: Break at user_logic_tb.vhw line 273
# MACRO ./user_logic_tb.fdo PAUSED at line 16

Both post-Map and behavioral simulation show no clock and no
signal processing; all flat lines all of a sudden.
I'm looking at reinstalling. I'm using the ModelSim XE III 6.1e starter
edition. Does anyone know how to fix this without reinstalling?

Also in regards to my previous message:
Xilinx tech. support said to separately register each level of logic,
since I have some lines of up to four xor statements being assigned to
a signal. I tried that, but it didn't help. ...but
still cross-connects with or without the added registers when used as a
submodule of user_logic.

Would anyone have some suggestions about how to write the VHDL
so it won't do that?

Thanks in advance,
-James

<james7uw@yahoo.ca> wrote in message 
news:1159160810.953243.94120@i3g2000cwc.googlegroups.com...
> Handy link for this entire thread:
> http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6
>
> I tried adding a separate level of registering in my main
> line VHDL code and was trying to test it when the ModelSim
> simulator died. No clock; therefore no signal processing. The
> transcript
> (output window) looks normal and ends up with:
>
> # ** Failure: Simulation successful (not a failure).  No problems
> detected.
> #    Time: 1320 ns  Iteration: 0  Process: /user_logic_tb/line__94
> File: user_logic_tb.vhw
> # Break at user_logic_tb.vhw line 273
> # Simulation Breakpoint: Break at user_logic_tb.vhw line 273
> # MACRO ./user_logic_tb.fdo PAUSED at line 16
>
> Both post-Map and behavioral simulation show no clock and no
> signal processing; all flat lines all of a sudden.
> I'm looking at reinstalling. I'm using the ModelSim XE III 6.1e starter
> edition. Does anyone know how to fix this without reinstalling?

While it's not impossible that your Modelsim install got corrupted, I highly 
doubt it and therefore suggest that reinstalling is likely going to be 
wasted time.  I've yet to 'fix' anything by re-installing Modelsim.  I'd 
suggest debugging as to why the clock signal is not running any more.

>
> Also in regards to my previous message:
> Xilinx tech. support said to separately register each level of logic,
> since I have some lines of up to four xor statements being assigned to
> a signal. I tried that, but it didn't help. ...but
> still cross-connects with or without the added registers when used as a
> submodule of user_logic.

It didn't work because that was just a random guess on Xilinx tech supports 
part to try to close the service request.  Since the problem of why pre and 
post VHDL models are acting differently has absolutely nothing to do with 
your source code is there suggestion has 0% chance of solving the 
problem....which you confirmed.

I don't know how you actually posed the question to Xilinx but the question 
that should have been posed to them is along the lines of:  "I have a 
pre-route VHDL simulation design file and a post-route/map/whatever VHDL 
simulation file that is the output of ISE version X.X.  Given the same 
input, they don't simulate the same.  Signal 'X' at time 't' is a '1' using 
the original design file and it is '0' using the VHDL output from ISE.  I've 
attached the original source VHDL files, the ISE project files which 
includes the post-map VHDL as well as the testbench VHDL that generates the 
stimulus and a Modelsim '.do' file which runs each design up until time 't' 
where you can see that the signal 'X' coming out is different between the 
two models.  I've confirmed that my testbench generates input stimulus to 
both designs that meets the input setup/hold time requirements of the final 
routed design.  My question is 'Why are the outputs different?"

Is that anything close to how you worded it?

When posed in that manner, any answer/suggestion from Xilinx that does not 
address the question of "Why are the outputs from the two simulations 
different?" is irrelevant.  Letting them off the hook with the suggestion of 
changing your source code to add registers because you have "some lines of 
up to four xor statements being assigned to a signal" (whatever that really 
means) is just trying to make you go away without addressing your real 
problem....but if your service request did not ask that basic question and 
provide them with the two simulation models that demonstrate this difference 
in the first place, well, they can only deal with what you provide them.

>
> Would anyone have some suggestions about how to write the VHDL
> so it won't do that?
>
Yes...as pointed out earlier in the thread...

1. Write (if you don't have one already) a testbench that instantiates the 
original design file.  Make sure all input setup and hold times in the 
testbench meet the timing requirements listed by ISE in the timing analysis 
report.
2. Run the testbench with both the original design file and the post-map 
file and document where the two predict different results.
3a. Open a service request to Xilinx sending them this information and ask 
the question as I mentioned in the previous paragraph.
3b. Debug into the post-map design file and see if you can determine the 
cause for the difference while Xilinx is also chewing on it.

Always keep in mind that the 'pre' and 'post' simulation models are ALWAYS 
supposed to produce the same result given the same stimulus that meets all 
input timing requirements and that this is ALWAYS TRUE NO MATTER WHAT the 
original source code is.  When this is not the case (and it does happen), as 
I mentioned earlier in this thread the root cause of the discrepancy is 
generally...

1. Testbench not meeting input setup/hold time requirements (i.e. you need 
to fix your testbench).
2. Improper use of types other than 'std_logic/std_ulogic'.  (From earlier 
in the thread I thought you said there were none in your code.  But if there 
were than again, this would be yours to fix).
3. Bug in the tool, in this case ISE. In this case, you need to open a 
service request and have them explain to you why 'pre' and 'post' simulation 
is producing different results....and not let them off with anything that 
causes you to change your code except to fix something along the lines of #1 
or #2 that you missed.  Changing the design because "some lines of up to 
four xor statements being assigned to a signal" is not an acceptable 
reason...see the previous paragraph with the 'ALWAYS' in it for 
justification.

KJ 

Handy link for this entire thread:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

Hi KJ,

Thanks for your information and moral support.

About ModelSim not seeming to work, I think I was just tired. I wasn't
expanding the waveform window pane to look at the whole view. Without
doing that, I was just looking at the initial "offset" time of 100 ns
in which nothing was happening. It's also possible I was tired and not
remembering that I have to wait for the simulation to complete; I
recall seeing the final output was 'U' - Uninitialized, and that may be
the reason. Next time I should record screenshots so that I can prove I
was not hallucinating, or, alternatively, while I'm at it, give me time
to realize what is going on.

"input setup/hold time" is the time required before a clock edge to
setup and hold an input signal so that the receiving FF will
successfully register it, is that right?

I am using the "Test Bench WaveForm" GUI feature (Xilinx ISE ver
8.2.03i, now) and in the clock timing input window that comes up
automatically when I create a tbw file, there are settings for "Input
setup time" and "output valid delay", that I have to fill in. "Input
setup time" is the time duration that the testbench will place my input
signal transitions before its clock edges, is that right? For example,
I have a "load" pulse that I draw in the GUI and the testbench will
make sure to activate its edges 1ns before the matching clock edges if
I set "input setup time" to 1ns, is that right? Does "output valid
delay" mean the time duration after a clock edge at which output data
becomes valid? If so, I don't understand what that tells the testbench
to do. Since that seems to be dependent upon the device under test and
yet it is a testbench entry parameter, I am confused as to the meaning
of that and must be understanding it wrong.

So I have to make sure that my "Input setup time" that I specify has
got to satisfy all input setup/hold times required by the mapper timing
report, is that right? What do I look at to specify the "output valid
delay" (it must be some kind of data in the timing report. I'll take a
look)? Does that mean I'm telling the testbench not to "look" at data
before that time period after a clock pulse just for reporting and
display purposes?

I am synthesizing and translating and getting correct operation in
simulation but then mapping and getting incorrect operation -- I have
an initial load into a submodule of 128 bits and a simple subsequent
output from the submodule of that separated into its four 32-bit words.
In that, post-map, the lower three bytes of the second register are
being duplicated into the third register, both in the signals used in
the calling module and in the signals used in the submodule. It looks
like logic is getting optimized away incorrectly, but could that really
be happening by violating setup and hold times in the testbench?

I am getting seven warnings of the following type from ModelSim when it
does post-map simulation:
# ** Warning: /X_SFF SETUP High VIOLATION ON CE WITH RESPECT TO CLK;
#   Expected := 0.74 ns; Observed := 0.583 ns; At : 291.975 ns
#    Time: 291975 ps  Iteration: 3  Instance:
/user_logic_tb/uut/slv_reg0_7
Is that just a slight difference as compared to the behavioral
simulation? I think that the simulator compares results, is that right?

To clarify what was meant by levels of logic, here is what the Xilinx
tech support engineer wrote:

-----------------------------
I looked at your code and I have some suggestions for you.  You have
registered your design, but you haven't pipelined the design which will
more or less fix the issue you are having.  What you did was place a
register on the output, but the output is not being optimized, the
combinational logic in-between is.  This is what needs to be
registered. In one example of your code you have 4 logic levels.

w2(31 downto 24) <= wsav0(31 downto 24) xor wsav2(31 downto 24) xor
wsav1(31 downto 24) xor subwordsav(31 downto 24) xor rconsav;

In a fully pipelined design, you would only have one logic level per
register.  Meaning you will xor two signals, register it and then xor
it with the next, register it and so on.  This should fix your problem.
Map is optimizing all your combinational logic in look-up tables (LUTs)
and its removing the duplicate XOR gates.  Placing the registers
between the logic levels will stop that.

In regards to your other questions, due to the tools behaving correctly
[THAT HAS NOT BEEN ESTABLISHED], this has become a design issue and no
longer a support issue. Unfortunately, the technical support team
doesn't have the resources to help you further with your case.  We do
have other options available though.  If you go to the Design and
Education Services page (linked below) there are a couple of options in
which you can get help.

http://www.xilinx.com/support/gsd/

We have the Titanium Engineering group as well as Xilinx Design
Services.  This is in addition to possible help from the local FAE.
I'm sorry I am no longer able to help you with your issues, but I hope
my information has pointed you in the right direction toward solving
your problem.

I will go ahead and close this case; if you have any other support
issues please open another Webcase and our team will be happy to assist
you.
-----------------------------

I did the above suggestion and my job of combining only pairs of
signals at a time at alternate clock edges was a work of art, but it
produced the exact same results.

I have produced screenshots of the simulations that show correct
operation in behavioral and the flaw in post-map and sent that to
Xilinx. The way I worded it was to ask for the correct VHDL coding
style to prevent that kind of optimization and I complained about
undocumented mapper coding requirements. So now the problem doesn't
look like VHDL coding style any more.

A while ago I removed my one boolean signal and replaced it with
std_logic that I can test in "if" statements just as well, so I haven't
had anything but std_logic in my design during the last couple of weeks
or so.

I'm getting back to Xilinx and I'll try your approach of getting them
to explain what is going on, use your wording, and try not to accept
anything less than working with me until the issue is solved.

What is that post-map design file that I can look at? I do have six
unconnected signals being reported as nets that have no load in the map
report, but the FAE (Field Application Engineer) says he never has any
problems with that type of thing. However, he agrees that it wouldn't
hurt to look at the "Technology Schematic", produced post-translate,
identify those nets that map is complaining about and see if they are
actually intended to have loads (I thought everything in my design is
connected up). That's what I'm going to do next, now that I've removed
a bunch of VHDL code that doesn't change anything and just adds
complexity.

Best regards,
-James

Handy link for this entire thread:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

Here are the ISE project settings that I changed from the defaults:

Synthesize properties: "Keep Hierarchy" on. (Left "Equivalent Register
Removal" on).
Translate properties: "Preserve Hierarchy on Sub Module" on.
Mapper: "Trim unconnected signals" off
  (left "Allow logic opt. across hierarchy" off).
  Opt. strategy: speed
  Generate detailed Map report
  By default, equivalent register removal is on, so I had to turn on
global
  optimization mode (-global_opt on) in order to turn it off.
  Trim unconnected signals (-u) - I had to turn it on, according to the
mapper
  output, as long as I use global optimization mode.
  (-u is known as "(Do Not Remove Unused Logic)" on pg 141 of dev.pdf
ver 8.2i.)

  -r map option (no register ordering)

Handy link for this entire thread:
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

Here are the definitions:
>From the installed help files at
C:\Xilinx\doc\usenglish\help\iseguide\mergedProjects\xsim\html\xs_hidd_initialize_timing_dialog.htm

The Input Setup Time is the minimum amount of time between the arrival
of an input pulse and a clock pulse for that input pulse to be
considered valid.

The Output Valid Delay is the maximum amount of time allowed for an
output to change states for it to be considered valid when used in a
self-checking test bench. The Test Bench Waveform Editor can write out
a self-checking test bench. For more information see Generating
Expected Simulation Results.  Time units are determined by the Time
Scale drop-down menu at the lower right.

<james7uw@yahoo.ca> wrote in message
news:1159245761.586819.18560@k70g2000cwa.googlegroups.com...
> Handy link for this entire thread:
> http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6
>
>
> "input setup/hold time" is the time required before a clock edge to
> setup and hold an input signal so that the receiving FF will
> successfully register it, is that right?
Yes, almost.  Setup time is the time for the signal to be stable prior to
the clock.  Hold time is the time for the signal to be stable after the
clock (many times, but not always hold time is 0).
>
> I am using the "Test Bench WaveForm" GUI feature (Xilinx ISE ver
> 8.2.03i, now) and in the clock timing input window that comes up
> automatically when I create a tbw file, there are settings for "Input
> setup time" and "output valid delay", that I have to fill in. "Input
> setup time" is the time duration that the testbench will place my input
> signal transitions before its clock edges, is that right?
Yes
> For example,
> I have a "load" pulse that I draw in the GUI and the testbench will
> make sure to activate its edges 1ns before the matching clock edges if
> I set "input setup time" to 1ns, is that right?
Yes
>  Does "output valid
> delay" mean the time duration after a clock edge at which output data
> becomes valid? If so, I don't understand what that tells the testbench
> to do. Since that seems to be dependent upon the device under test and
> yet it is a testbench entry parameter, I am confused as to the meaning
> of that and must be understanding it wrong.
Sort of.  What you're telling the testbench is how long it is before the
outputs of your design will become valid so that it doesn't bother to check
them prior to that time.  You're right that this is dependent on the device
under test but so is the input setup times that you're entering.  Generally
what you would put into the testbench for these are numbers that you 'can
live with' in your actual design.  By that I mean, the FPGA doesn't usually
live in isolation it is connected to outside devices that may have timing
requirements as well.

For example, if one of the inputs to the FPGA is connected to some device
that has Tco = 10 ns and that part and the FPGA both transmit/receive this 
signal with the same 10MHz clock (i.e.
T=100 ns).  Then as a first order approximation one could calculate the
input setup time requirement at the FPGA as being T-Tco = 90 ns.  A more 
accurate
approximation would be to realize that there is going to be clock skew
between the two devices and delay on the printed circuit board that will eat
into that timing margin and you should take those into consideration as you 
define what the FPGA input setup requirements are.  The point is you 
probably wouldn't want to put the
90ns in as the FPGA's requirement, get some estimates for those other two or
swag them as being less than 5 ns or so and enter 85 ns.  For a really
high speed design you'll be more careful about determining the things that
go into the timing budget for the simple reason that there is less time per 
clock cycle and you can't afford to not have better control over everything.

Anyway, whatever that input setup time requirement is that you determine 
should go two places:  as a constraint to the fitter that it needs to meet 
and into your testbench.  Also note that the requirement is determined 
without regard to any timing numbers from the FPGA itself.  It is a 
requirement that is determined by the outside world around the FPGA.  Most 
people do go through some form of this figuring out and enter the number 
into the fitter so that when the timing analysis is performed it clearly 
flags violations.  What most do not do is to enter that exact same 
requirement into the testbench.

Repeat this process for computing what the clock to output delay requirement 
of the FPGA is.  Here you would start with your clock period and subtract 
off the input setup time of whatever device is on the receiving end of the 
FPGA output, subtract off clock skew, subtract off PCB delay.  The basic 
process is the same.
>
> So I have to make sure that my "Input setup time" that I specify has
> got to satisfy all input setup/hold times required by the mapper timing
> report, is that right? What do I look at to specify the "output valid
> delay" (it must be some kind of data in the timing report. I'll take a
> look)? Does that mean I'm telling the testbench not to "look" at data
> before that time period after a clock pulse just for reporting and
> display purposes?
See above for the more detailed answer.

>
> I am synthesizing and translating and getting correct operation in
> simulation but then mapping and getting incorrect operation -- I have
> an initial load into a submodule of 128 bits and a simple subsequent
> output from the submodule of that separated into its four 32-bit words.
> In that, post-map, the lower three bytes of the second register are
> being duplicated into the third register, both in the signals used in
> the calling module and in the signals used in the submodule. It looks
> like logic is getting optimized away incorrectly, but could that really
> be happening by violating setup and hold times in the testbench?
>
Don't know.  Just as with real life, when you violate timing requirements 
pretty much anything might happen.  It would depend totally on the actual 
implementation.  If that's what it's doing, then that's what it's doing.

> I am getting seven warnings of the following type from ModelSim when it
> does post-map simulation:
> # ** Warning: /X_SFF SETUP High VIOLATION ON CE WITH RESPECT TO CLK;
> #   Expected := 0.74 ns; Observed := 0.583 ns; At : 291.975 ns
> #    Time: 291975 ps  Iteration: 3  Instance:
> /user_logic_tb/uut/slv_reg0_7
> Is that just a slight difference as compared to the behavioral
> simulation? I think that the simulator compares results, is that right?
The simulator calls it a warning but it really is a design error.  What 
exactly the simulation model does when this occurs is a function of how the 
simulation model is coded.  Best to investigate why the logic path is long 
and clean up those problems now.  If all of the timing violations are setup 
times, you can temporarily code around this simply by slowing down your 
clock for simulation.  Get the testbench to the point that it can run the 
original source and the post-map model with no reported timing errors.

The more thorough check though is to compare the timing requirements that 
you have in your testbench with what pops out of the timing analysis report. 
The reason it is more thorough is that your simulation might not happen to 
hit every input under just the right conditions.  Bottom line is that if 
you've determined that the input setup requirement is 15 ns then the timing 
report had better report something less than 15 ns in the actual 
implementation or you have a design issue to resolve.  Timing analysis does 
not require any simulation.  Do this for all inputs and outputs.

>
> To clarify what was meant by levels of logic, here is what the Xilinx
> tech support engineer wrote:
>
> -----------------------------
> I looked at your code and I have some suggestions for you.  You have
> registered your design, but you haven't pipelined the design which will
> more or less fix the issue you are having.  What you did was place a
> register on the output, but the output is not being optimized, the
> combinational logic in-between is.  This is what needs to be
> registered. In one example of your code you have 4 logic levels.
>
> w2(31 downto 24) <= wsav0(31 downto 24) xor wsav2(31 downto 24) xor
> wsav1(31 downto 24) xor subwordsav(31 downto 24) xor rconsav;
>
> In a fully pipelined design, you would only have one logic level per
> register.  Meaning you will xor two signals, register it and then xor
> it with the next, register it and so on.  This should fix your problem.
> Map is optimizing all your combinational logic in look-up tables (LUTs)
> and its removing the duplicate XOR gates.  Placing the registers
> between the logic levels will stop that.
>
> In regards to your other questions, due to the tools behaving correctly
> [THAT HAS NOT BEEN ESTABLISHED], this has become a design issue and no
> longer a support issue. Unfortunately, the technical support team
> doesn't have the resources to help you further with your case.  We do
> have other options available though.  If you go to the Design and
> Education Services page (linked below) there are a couple of options in
> which you can get help.
>
> http://www.xilinx.com/support/gsd/
>
> We have the Titanium Engineering group as well as Xilinx Design
> Services.  This is in addition to possible help from the local FAE.
> I'm sorry I am no longer able to help you with your issues, but I hope
> my information has pointed you in the right direction toward solving
> your problem.
>
> I will go ahead and close this case; if you have any other support
> issues please open another Webcase and our team will be happy to assist
> you.
> -----------------------------
The problem as I see it is that the original source and the post-map 
simulation models don't agree.  I don't see anything in the response from 
Xilinx to address this but maybe you didn't word it in exactly that manner. 
Once you get your timing errors cleaned up you should have a testbench that 
will provide the identical stimulus to both models.  If they still perform 
differently then open another service request to Xilinx (or your FAE) and 
have them explain why the two are different.  It has absolutely nothing to 
do with optomizations.  Original source and post-anything must be 
functionally identical...regardless of what the function actually is.  Stick 
to your guns on that and don't let them off the hook but also don't 
sidetrack them with optomization settings or any of that.  It is the 
software's job to translate your code into something functionally identical 
that they can actually implement inside a real device.

Just make sure you've cleaned up all timing problems before since that is on 
your side, not theirs.
>
> I did the above suggestion and my job of combining only pairs of
> signals at a time at alternate clock edges was a work of art, but it
> produced the exact same results.
>
> I have produced screenshots of the simulations that show correct
> operation in behavioral and the flaw in post-map and sent that to
> Xilinx. The way I worded it was to ask for the correct VHDL coding
> style to prevent that kind of optimization and I complained about
> undocumented mapper coding requirements. So now the problem doesn't
> look like VHDL coding style any more.
Other than things I've mentioned earlier in the thread about incorrectly 
using things other than std_logic/std_ulogic or latches or things like that 
it never is coding 'style' per se.  So do the timing analysis, verify that 
the testbench presents inputs and checks outputs at the appropriate time per 
your requirements then re-collect the screen shots and send it off and ask 
them to explain the difference since they are supposed to be functionally 
identical.

> A while ago I removed my one boolean signal and replaced it with
> std_logic that I can test in "if" statements just as well, so I haven't
> had anything but std_logic in my design during the last couple of weeks
> or so.
Good, one less thing to worry about right now.  The reason std_logic is such 
a good thing is simply because of the value 'X'.  Being able to get rid of 
all the unknowns in a simulation is a milestone of sorts and when you can't 
for whatever reason then that big 'X' is staring at you pointing you right 
to the place to investigate.  Anyway, you don't have that but just thought 
I'd toss out why using only std_logic is a 'good' thing until you've been 
doing this for a while and can move on with confidence to other types.

>
> I'm getting back to Xilinx and I'll try your approach of getting them
> to explain what is going on, use your wording, and try not to accept
> anything less than working with me until the issue is solved.
>
Good plan.

> What is that post-map design file that I can look at? I do have six
> unconnected signals being reported as nets that have no load in the map
> report, but the FAE (Field Application Engineer) says he never has any
> problems with that type of thing. However, he agrees that it wouldn't
> hurt to look at the "Technology Schematic", produced post-translate,
> identify those nets that map is complaining about and see if they are
> actually intended to have loads (I thought everything in my design is
> connected up). That's what I'm going to do next, now that I've removed
> a bunch of VHDL code that doesn't change anything and just adds
> complexity.
It shouldn't be a problem and if it is it's Xilinx's problem anyway. 
Remember your original source code is not the actual implementation it is an 
abstraction.  FPGAs do not implement 'a xor b' they translate that into a 
lookup table that has been programmed appropriately and enable pass 
transistors to get signals 'a' and 'b' to the proper inputs to that table. 
Sometimes warnings can point to problems but in this case I don't think it 
will but like the FAE said, it wouldn't hurt to look either.  I'm not 
exactly sure at what file you need to look at though.  Maybe try searching 
through all of the files for the net name that is being flagged and see what 
hits.

KJ 

Link to entire thread
http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/6d594b2ab04beb4b/e39055a323c18cd6#e39055a323c18cd6

Thanks for that, KJ. Meditating on timing issues, and looking at the
mapper timing report resulted in me setting the input setup times and
output valid delays in the testbench to exceed the maximum figures of
"Setup to clk (edge)" and "clk (edge) to pad" that were reported. I
took the additional conservative step of halving the clock frequency.
Now my post-map sim. is giving me correct results. It is odd that
improper timing would cause byte mixup like that, but I can certainly
contemplate types of interconnections that might behave that way. The
only other thing that I think helped was making my design synchronous
by registering all data in clocked registers. One thing I clued into is
that you can't, at least in Xilinx, set a signal in two or more
different processes, because that results in multiple sourcing and
unknown ('X') output. Also, if something like the following is written,
which is the correct way to write a register:

MY_PROC : process (clk, rst) is
begin
  if (rst = '0') then
    a <= '1';
  elsif (clk'event and (clk = '1')) then
    if (b = '0') then
      a <= '1';
    else
      a <= '0';
    end if;
  end if;
end process MY_PROC;

Whatever is put in for "rst" will be the reset, and if you try to put
other signals, that you use for something else elsewhere, in the place
of "rst" in the above, Xilinx will connect them to your input port's
reset signal and create all sorts of mess.

Best regards,
-James