General Technical Discussion

[matthew180]

I have three circuits, one of them being a sort of mux that controls access to a block RAM.  In the circuit that produces the address and needs the data, I have a registered address output:

port (

  addr_out : out std_logic_vector()

. . .

begin

  signal addr_reg : std_logic_vector()

. . .

addr_out <= addr_reg;

The addr_reg is developed via the FSM over a few clock cycles.

I also have a basic single port block RAM set up by the MIB tool.  Finally I have the RAM mux:

port (

  cpu_addr_in : in std_logic_vector(); -- in from the cpu circuit

  ram_addr_out : out std_logic_vector(); -- out to the RAM circuit

 . . .

begin

  signal cpu_addr_reg : std_logic_vector(); -- cpu address register

  signal ram_addr_reg : std_logic_vector(); -- RAM address register

 . . .

  ram_addr_out <= ram_addr_reg;  -- derived address to the RAM

Now, if I synthesize this everything is fine and the timing shows 113MHz, which is what I would expect.  I need the timing to be at least 100MHz.  Of course this does not do what I need since the input address requests are not going to the RAM, so at the very least I need this:

  ram_addr_reg <= cpu_addr_reg;  -- test, bypass FSM and just direct assing input cpu address to RAM addr reg

Normally ram_addr_reg would be set via some conditions determined by the FSM, but for now I just want to get my timing back up to over 100MHz.  So, with that assignment added in, my timing falls to 95MHz!

Can someone please give me some clues as to how to resolve this?  I have tried everything I can.  All my inputs and outputs are registered and I just don't understand how that one assignement can cause such a drastic change in the timing.

I'll gladly post more code or whatever, I just try to keep these as short as possible and still relay the necessary parts.  I'm pulling my hair out over this, so any feedback would be greatly appreciated!

Thanks,

Matthew

[drjohnsmith]

Hi

Is it because in one situation you have the signals internal to the FPGA, in the other they go external ?

try double registering, see if the time goes up ?

[matthew180]

All the signals that the RAM mux deals with are within the FPGA.  The actual data coming from the host computer comes in to the CPU I/O module, which will then form the address as necessary, and pass that to the RAM mux.  I'll try double registering though to see it that helps.

Will transfering from one register to another via the clock do any good?  Something like:

process (clk)

begin

if rising_edge(clk) then

  ram_addr_reg <= cpu_addr_reg;

end if;

end process;

Just grasping at this point.  I suppose I can try that easy enough, but I have little hope.

Matthew

[drjohnsmith]

Hi

Have you looked in the timing report file, to see what the slow nets are ?

[matthew180]

No I have not.  Which report would that be exactly?  In looking at the Summary, I see 3 reports that appear to deal with timing:

Timing Constraints

Clock Report

Timing Messages

The first two don't tell me anything specific to any circuit.  The last has 4 messages associated with it:

Timing:2752 - To get complete path coverage, use the unconstrained paths option. All paths that are not constrained will be reported in the unconstrained paths section(s) of the report.

Timing:3339 - The clock-to-out numbers in this timing report are based on a 50 Ohm transmission line loading model.  For the details of this model, and for more information on accounting for different loading conditions, please see the device datasheet.

Timing:3390 - This architecture does not support a default System Jitter value, please add SYSTEM_JITTER constraint to the UCF to modify the Clock Uncertainty calculation.

Timing:3389 - This architecture does not support 'Discrete Jitter' and 'Phase Error' calculations, these terms will be zero in the Clock Uncertainty calculation.  Please make appropriate modification to SYSTEM_JITTER to account for the unsupported Discrete Jitter and Phase Error.

Otherwise, where else should I be looking?

Thanks,

Matthew

[bassman59]

---

matthew180 wrote:

No I have not.  Which report would that be exactly? 

---

Run the timing analyzer from the GUI; it's in the place-and-route section.

[matthew180]

Cool, thanks, I'll check that out.  I'm learning to use these reports more and more.  While waiting for your reply I noticed that the bottom of the Summary->Detailed Reports->Synthesis Report is a Timing Detail section that seems to show the 3 slowest paths.  I fixed the slowest one and my timing is back up to 113MHz!  Now if I could just get rid of my async signal, I'd be really happy.

Matthew