UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply

RAM Routing problems

Highlighted
Participant
Posts: 58
Registered: ‎10-13-2015

RAM Routing problems

 

Hi,

 

I have a routing problem with RAM. Verilog code is a bit complicated and Schematic is also too big, so I provide description of problem as a block diagram.

 

1) After Synthesis a have hold timing violoation between FDRE and RAM. -0.046

Clock is described in XDC file

create_clock -period 2.700 -name CLK -waveform {0.000 1.350} [get_ports -filter { NAME =~  "*clk*" && DIRECTION == "IN" }]

2) After P&R in Virtex 7 (50% LUTs/50% Latches/70% DSP) there's Setup routing problem at the same place

 

 

What may be the problem? Add even more triggers, limit fanout to 20? Add some place constraints?
RamProblems.png

Mentor
Posts: 417
Registered: ‎12-03-2007

Re: RAM Routing problems

@vinogradov_rus , 

 

It'd make it easier to analyze source of the problem if you generate detailed timing report of this failing path. 360MHz means you have 2.77ns budget, and detailed report will tell how it's being used. For example, logic and routing ratio, and where each component of the path is placed.

 

Another thing is to try different synthesis and p&r strategies, and see if this problem goes away.

 

Thanks,

Evgeni

Instructor
Posts: 3,546
Registered: ‎01-23-2009

Re: RAM Routing problems

A hold violation after synthesis doesn't mean anything. Hold time fixing is done during the routing stage, so any hold violation prior to that doesn't mean anything.

 

The setup violation, on the other hand, is a real problem. If I understand correctly, you are trying to fan out a single value to 40 block RAMs at 360MHz. Basically, the tool is telling you that this can't be done, and it is pretty likely true.

 

The block RAMs are big blocks. Even assuming these are all RAMB18 (and not RAMB36), this means you need 20 RAMB36 blocks. A clock region only contains 10 per column, and the columns are quite far apart, so by definition, you are asking this one source to drive loads across at least two clock regions, or far apart in the same clock region (or a combination of the two) - and it can't - not at this clock rate.

 

Placement constraints probably won't help - there is likely no organization of the 40 RAMs with the source that will get everything to be within 2.7ns from the source.

 

You will have to be more direct with the tools. You will have to replicate the flip-flops driving the 40 loads, and have 2 sets each driving 20 or, even better, 4 driving 10 each (that should probably be enough). But it isn't easy to get the tools to do this for you. Turning on register replication (which normally is done by default) only sometimes does the "right" thing. So I recommend you do it manually.

 

But it's tricky to get the tools to keep what it sees as redundant registers - simply having 4 copies of the flip-flops in your RTL code, each driving 10 of the 40 RAMs probably won't be enough, since the tool will recognize that the 4 sets are redundant and merge them back into one. You may be able to prevent this with judicious use of the DONT_TOUCH attribute, but I prefer to be more heavy handed...

 

What I would do is write a module that has one set of flip-flops and 10 RAMs in it (with the FFs fanning out to the 10 RAMs). Then instantiate this 4 times. Make sure that "flatten_hierarchy" is set to "none" in synthesis, which will prevent the tool from doing any sharing/merging of cells within the 4 instances.

 

Avrum

Participant
Posts: 58
Registered: ‎10-13-2015

Re: RAM Routing problems

Hi evgenis1,

 

I've tried different synthesis and P&R strategies and reduced problem from 0.6ns to 0.1ns, but it still takes a place

Participant
Posts: 58
Registered: ‎10-13-2015

Re: RAM Routing problems

 Hi avrumw,

Thank you for detailed response

 

Could you help please, may I set any contraint or option so not to see this violation? I prefer to fix all warning :)

Got you about RAM, I'll try. Thank you!

 

Where can I get more information about placement resourses in FPGA? For example how many DSP block may a cascase in a single region? Or how deep RAM can I do?

 

Instructor
Posts: 3,546
Registered: ‎01-23-2009

Re: RAM Routing problems

Could you help please, may I set any contraint or option so not to see this violation?

 

I don't know of a "safe" way to do this. There is a command (set_false_path -hold) that can disable the timing on these paths, but it would be essential to ensure that this is done only during synthesis. In theory these could be put in an XDC file used in synthesis only... But - this is dangerous and not standard practice. I would rather leave the warnings in the synthesis report rather than start mucking with unusual constraints...

 

Where can I get more information about placement resourses in FPGA? For example how many DSP block may a cascase in a single region? Or how deep RAM can I do?

 

You know, you would think these would be easy to find - I went looking (quickly) and they are not immediately obvious in the documentation.

 

The easiest thing to do is to open any design in Vivado and look at the die view. With a little looking (or some interesting Tcl commands - i.e. "select_objects [get_sites -filter {NAME =~ *DSP*}]") you can locate all the resources, and the clock regions are also visible.

 

But in a nutshell, a single column within a clock region contains (for 7 series)

  - 1 CMT (so one MMCM and one PLL)

  - 20 DSP48

  - 10 RAMB36 (or 20 RAMB18 or a combination of the two)

  - 50 CLBs (thus 50 slices - each CLB is 2 side-by-side slices)

  - 50 IOBs or one GT quad (4 GT transceivers)

  - 4 BUFIO, 4 BUFR, 4 CCIO (2 SRCC and 2 MRCC)

 

Avrum

Participant
Posts: 58
Registered: ‎10-13-2015

Re: RAM Routing problems

@avrumw Thank you so much for your help