CPLDs

[trossin2]

Hi,

I attached the start of a little logic analyzer design which uses SPI to connect to a PIC.  When I leave theRamData port at 7 bits it compiles and fits just fine with the following results using ISE 13.4:

Macrocells Used	Pterms Used	Registers Used	Pins Used	Function Block Inputs Used
60/72  (84%)	168/360  (47%)	50/72  (70%)	24/34  (71%)	125/216  (58%)

So it is not on the edge of disaster.  If I change the port RamData to be 8 bits wide (and change the equation to assign RamData = (DriveRamData) ? In[7:0] : 8'bzzzzzzzz;)  then I get the error below.  I looked at the suggestions and none of them seem to apply or help.   These are the ports so I would expect to use just one more pin when restoring the width to 8:

`define WIDTH 8

module LA1(
    input Clk,
    input Reset,
    input [`WIDTH-1:0] In,
    //inout [`WIDTH-1:0] RamData,
    inout [6:0] RamData,
    output reg IncAddr,
    output reg nOE,
    output nWE,
    input Done,
 // SPI interface
    input SpiClk,
    input Sdi,
    output Sdo
);

Any help would be great. 

Mapping a total of 61 equations into 4 function blocks..............................................

Design LA1 has been optimized and fit into device XC9572XL-10-PC44.
ERROR:ProjectMgmt:387 - TOE: ITclInterp::ExecuteCmd gave Tcl result 'can't read "iFileType": no such variable'.
Tcl_ErrnoId: unknown error
Tcl_ErrnoMsg: No error
_cmd: ::xilinx::Dpm::dpm_chTransformExecute dpm_fitterRun $piThisInterface
errorInfo: can't read "iFileType": no such variable
    while executing
"if { $iFileType eq "UNKNOWN" } {
                continue ; # unknown is just ignored, its probably .txt
              }"
    ("foreach" body line 3)
    invoked from within
"foreach sItem $lOutputFileList {
            if { ![dpm_parseOutputFile $sItem $iDesign sFile iFileType fileOrigination] } {
              if { $iFile..."
    (procedure "dpm_chTransformOutput" line 15)
    invoked from within
"dpm_chTransformOutput $iTranInst $lOutputFileList"
    (procedure "dpm_fitterRun" line 477)
    invoked from within
"$sCmd $iTransformInstance $sCmdArgs"
    (procedure "dpm_chTransformExecuteEngine" line 100)
    invoked from within
"dpm_chTransformExecuteEngine $sFlowProc $iInterface $bRunTransformWithEmptyInputSet "
    (procedure "::xilinx::Dpm::dpm_chTransformExecute" line 3)
    invoked from within
"::xilinx::Dpm::dpm_chTransformExecute dpm_fitterRun $piThisInterface"

[gszakacs]

You might want to try "cleanup project files" and if that doesn't help, start a new project

and just add the same code, to see if this error comes from some retained data within

the ISE project.  It doesn't look like a fitting error, especially because this like seems

to show that the project fits your device:

Design LA1 has been optimized and fit into device XC9572XL-10-PC44.

-- Gabor

[trossin2]

The failure is very repeatable.  I can create a new project and copy the source to that directory and get it to come back.

I have found a work-around which is to select Process Properties when I have FIT selected and turn off Global Clocks.  Then there is no problem except the design does not use the GCLK pin.  I can turn the failure on and off with this switch.  Global OE and global Reset have no affect on the failure.

I have a very old version of ISE (2003 vintage) on my old computer.  I'll give it a try on that code and see if I get a real error message.  Either way, it seems that I should file a bug on ISE 13.4

I attached a zip of the little project that shows the bug.  I think I got a reply to one of my other complaints about how to file a bug.  I'll look back at that and go through the process.

[trossin2]

I went through proper channels to get this looked into by Xilinx and the bottom line is that CPLD develepment is about done and that this bug would get at best low priority.  All they could do is suggest some work-arounds which did not work.  My work-around of turnning off global clocks worked for this case.  I made other changes to the source as I added more features and the problem went away.

Now I have a problem where the device is at most 70% used and I can't add a 2-bit counter.  The Fitter tools says it ran out of resources.  If this was an FPGA I might believe it but since it is a CPLD, there is enough space.  The software is just on the edge of death for some reason.

I'll say that I'm not real impressed with the tool suite and it seems that it will not get better so the only solution is to shop elsewhere.

[ole2]

I confirm. Just by adding the following module for baud clock generation I've got the same nonsense error.

unfortunately in my case, disabling use of global clocks resolved no issue.

-----------------------------------------------------------------------------------------
-- baud rate generator for uart  
--
-- this module has been changed to receive the baud rate dividing counter from registers.
-- the two registers should be calculated as follows:
-- first register:
--              baud_freq = 16*baud_rate / gcd(global_clock_freq, 16*baud_rate)
-- second register:
--              baud_limit = (global_clock_freq / gcd(global_clock_freq, 16*baud_rate)) - baud_freq  
--
-----------------------------------------------------------------------------------------
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
 
entity baudGen is
  port ( clr       : in  std_logic;                     -- global reset input
         clk       : in  std_logic;                     -- global clock input
         -- baudFreq = 16 * baudRate / gcd(clkFreq, 16 * baudRate)
         baudFreq  : in  std_logic_vector(11 downto 0); -- baud rate setting registers - see header description
         -- baudLimit = clkFreq / gcd(clkFreq, 16 * baudRate) - baudFreq
         baudLimit : in  std_logic_vector(15 downto 0); -- baud rate setting registers - see header description
         ce16      : out std_logic);                    -- baud rate multiplyed by 16
end baudGen;
 
architecture Behavioral of baudGen is
 
  signal counter : std_logic_vector(15 downto 0);
 
  begin
    -- baud divider counter
    -- clock divider output
    process (clr, clk)
    begin
      if (clr = '1') then
        counter <= (others => '0');
        ce16 <= '0';
      elsif (rising_edge(clk)) then
        if (counter >= baudLimit) then
          counter <= counter - baudLimit;
          ce16 <= '1';
        else
          counter <= counter + baudFreq;
          ce16 <= '0';
        end if;
      end if;
    end process;
  end Behavioral;

[ole2]

and build under windows resulted in cpldfit.exe [776] caused unhandled win32 exception.

[osamutakeuchi]

I encountered the same problem. The direct source of the error ":ProjectMgmt:387" is that the project manager does not handle a segmentation fault of cpldfit. The segmentation fault of cpldfit occurs after fitting the circuit before writing the html report.

I finally found that, at least in my case, setting "-ofmt" option in the Process Properties of the Fit process from "VHDL" to "ABEL" got rid of the trouble. I hope it works in other cases.

[lionshaka]

I confirm. It works in my case. I set "-ofmt" in the Proccess Properies of the Fit process from "source" to "ABEL" got rid of the trouble.

[trossin2]

I can confirm that this worked for me as well.  I reran a case that just failed and switched the Fit Process Properties category Reports from -ofmt Source to ABEL and it now finishes just fine!

Thanks for the secret!