Timing issue.

[hamster_nz]

I have a timing issue I would like some input on, I just can't see the wood for the trees!

Using Xilinx Vivado, I have a small true dual port memory, 64x32 bits that sits between two clock domains.

The A port is read-only, with 0 latency, for a very quick lookup, in a fast clock domain.

The B port is read/write, with 1 latency, in slow clock domain, use to set the contents.

Both ports are guarded with an 'enable' signal, ensuring that only one port is being used at a time.

The idea being that the slower domain writes the contents of the memory, enables the data path in the faster domain, and the values get used like it is table in a ROM.

My timing issue is that the slow clock's constraints are leaking though to the fast port and breaking timing. This is correct, because if both ports were active at the same time and accessing the same address bad things could happen with data being corrupted and so on.

However, I can't find the right constraint to say "the two ports still need to meet their own clock domain's constraints, but there is no cross-domain dependency from the read/write port to the read port". I don't what to flag it as the start of a false path, because I need timing analysis on the read port's d_out signals.

It's not that it can't close timing - if I give both clocks the same period, or the slow one half that of the fast domain I get timing closure with slack.

I also don't want to put a blanket "ignore timing between these two clock domains" because there are other clock crossings that need to be analyzed and reported on.

I'm using an XPM dual-port macro, which I thought would have sorted this all for me.... 

[AndyC_772]

I'm familiar with Altera and not Xilinx; sadly this isn't a problem I've come across. The memory wizard in Quartus allows the relationship between the clocks to be defined, and if you select the option for independent read and write clocks, it seems to work out just fine.

It sounds as though there should be a false path from the slow clock to some register in the fast domain. When it fails timing, can you get a report as to exactly which path has negative slack? Can you, for example, set a false path between the slow clock and the output of the RAM block?

As a workaround, maybe try setting up a wide (but shallow) dual clock FIFO, with a slow write port and a fast read port. When data is to be written, instead of writing into DPRAM directly, push the address and data into the FIFO. Then, in the fast domain, create a piece of logic that reads address/data pairs from the FIFO and writes them into DPRAM. Instantiate your DPRAM so it's entirely within the fast clock domain.

It's more complex, of course, but logically valid, and simply different from a timing point of view. Whatever specific constraint is breaking your current design might simply no longer exist, which in turn lets you get on with the job.

[hamster_nz]

Found it! Switched form xpm_memory_tdpram to xpm_memory_dpdistram, which has the "USE_EMBEDDED_CONSTRAINT" parameter/generic that is needed.

Spent/wasted hours looking and experimenting. Sigh!

[hamster_nz]

I'm familiar with Altera and not Xilinx; sadly this isn't a problem I've come across. The memory wizard in Quartus allows the relationship between the clocks to be defined, and if you select the option for independent read and write clocks, it seems to work out just fine.

It sounds as though there should be a false path from the slow clock to some register in the fast domain. When it fails timing, can you get a report as to exactly which path has negative slack? Can you, for example, set a false path between the slow clock and the output of the RAM block?

As a workaround, maybe try setting up a wide (but shallow) dual clock FIFO, with a slow write port and a fast read port. When data is to be written, instead of writing into DPRAM directly, push the address and data into the FIFO. Then, in the fast domain, create a piece of logic that reads address/data pairs from the FIFO and writes them into DPRAM. Instantiate your DPRAM so it's entirely within the fast clock domain.

It's more complex, of course, but logically valid, and simply different from a timing point of view. Whatever specific constraint is breaking your current design might simply no longer exist, which in turn lets you get on with the job.

The timing report had the issue from the data out pin on the memory (on the fast port) to a register in the fast design's logic, but was showing the source clock as being the slow clock - the one connected to the other port.

But seems to be sorted now.

I'm actually becoming a big fan of the XPM macros... very much like Altera 'megafunctions' - are they still a thing on the other side of the fence? I especially like the clock domain crossing stuff, as doing it with attributes is fraught with gotchas and is largely non-portable anyway...

[AndyC_772]

Since the acquisition by Intel, Altera has been going off in the wrong direction, apparently quite disinterested in the small (Cyclone E) devices that are essential to my business but clearly not to theirs.

Right now the entire family is on allocation, meaning they're totally irrelevant vapourware. I actually wonder if they'll ever make them - at least for general sale - ever again.

I've stuck with Quartus 17.1 in which the megafunction wizard exists, but it's not as good as it used to be. It keeps wanting to automatically upgrade my designs any time I change Quartus version, but the upgrade process doesn't work properly, and I have better ways to waste my life.

I'm learning Efinix right now. So far, so good.

[hamster_nz]

I've stuck with Quartus 17.1 in which the megafunction wizard exists, but it's not as good as it used to be. It keeps wanting to automatically upgrade my designs any time I change Quartus version, but the upgrade process doesn't work properly, and I have better ways to waste my life.

XPM macros should be far more friendly... they are just instances in your code, so you don't have an upgrade process. But you have to read the fine print for the paramters

It's sort of a happy half way between inference and using primitives. Here's an example of a 64x32-bit word memory:

Code: [Select]

Library xpm;
use xpm.vcomponents.all;

xpm_memory_dpdistram_inst : xpm_memory_dpdistram
   generic map (
      ADDR_WIDTH_A            => 6,
      BYTE_WRITE_WIDTH_A      => 32,
      READ_DATA_WIDTH_A       => 32,
      READ_LATENCY_A          => 2,
      READ_RESET_VALUE_A      => "0",
      RST_MODE_A              => "SYNC",
      WRITE_DATA_WIDTH_A      => 32

      ADDR_WIDTH_B            => 6,
      READ_DATA_WIDTH_B       => 32,
      READ_LATENCY_B          => 2,
      READ_RESET_VALUE_B      => "0",
      RST_MODE_B              => "SYNC",

      CLOCKING_MODE           => "independant_clock",
      MEMORY_INIT_FILE        => "none",
      MEMORY_INIT_PARAM       => "0",
      MEMORY_OPTIMIZATION     => "true",
      MEMORY_SIZE             => 64*32,
      MESSAGE_CONTROL         => 0,
      SIM_ASSERT_CHK          => 0,
      USE_EMBEDDED_CONSTRAINT => 1,
      USE_MEM_INIT            => 1,
      USE_MEM_INIT_MMI        => 0,
   ) port map (
      douta  => douta,
      doutb  => doutb,
      addra  => addra,
      addrb  => addrb,
      clka   => clka,
      clkb   => clkb,
      dina   => dina,
      ena    => ena,
      enb    => enb,
      regcea => regcea,
      regceb => regceb,
      rsta   => rsta,
      rstb   => rstb,
      wea    => wea
   );


I'm learning Efinix right now. So far, so good.

Nice 

[Bassman59]

I'm learning Efinix right now. So far, so good.

Their dev tools aren't free, and I can't find a price -- any idea?

Though you get a free year license with the $35 dev kit.

Digikey seems to have a lot of their parts in stock.

[AndyC_772]

All you need to do is buy one of the dev boards. The little Xyloni board from Digi-key is fine.

Once you have a board, register its serial number with Efinix through their web site, and you can download the software.

The software itself doesn't 'expire', you just don't get updates after a year.