🚀 go-pugleaf

> A few of points:
> 
> 1. One of the improvements to Par/v1.5 is that ram blocks are recognised
> as such, and are supposedly placed in a sensible manner. This should
> remove the need for RLOC'ing.

  This is right. We have installed Service Pack and we haven't met
  any such problems now.
 
> 2. It sounds like Xilinx have suggested the -ir map option to get round
> some mapping bug's in version 1.5. However, if the -ir option is used
> relative placement information is lost, so RLOC'ing wouldn't get you
> anywhere.  I suggest getting the M1.5 service pack anyway.

  So, if I don't meed those errors, then I don't need to use RLOC'ing,
  do I?
 
> 3. If the clb's with rams are intended to also have flip-flops, it might
> be worth while checking in EPIC that they are both going in the same
> clb.

  The FF's in CLB's are not used in RAM implementations, as far as I
  have understood Xilinx Data Book 1998. In EPIC Editor, when I have
  looked inside CLB's, it seems that edge-triggering has been implemented
  either in F-G Generators or somewhere on chip.

> 4. Contrary to popular belief, structured hierarchical relative
> placement is possible with VHDL too. In fact it's easier and quicker.

  Frankly speaking, I am not interested in VHDL-Verilog difference.

  The problem is, if my big amount of RAM can be a drawback for routing
  (we have core, which consists of a logic of 600-650 CLB's and internal
  RAM's of 1000-1200 CLB's; so the amount of RAM is ca. %55 of core but
  not any device resources).

  Now my question is, is such an amount of RAM is really a drawback for
  placement&routing? One engineer from Canada told me that such a big
  amount of internal RAM is beyond the limits of Xilinx internal resource
  capabilities, since it needs astronomical resources. But we have never
  met some information on RAM concept for Xilinx technology. If you know
  any good information occasionally, that we seem to have missed it,
  would you please inform me?

  The 1000-1200 CLB's is not a single block RAM but is made up of
  several 32x8, 128x1, 128x3, 128x7 and 128x8 dual-port RAM's and 64x8
  synchronous single-port RAM's. It was not necessary to implement internal
  RAM's in this way. One of the internal RAM structure had to be implemented
  as 128x40 storage structure but we thought it would be a good way to
  partition it by instantiating 5 times 128x8 dual-port RAM modules.
  It is not so easy to redesign RAM organization. If possible, I want
  to have your experiences about RAM organizations and those effects on
  placement&routing. Since a placement&routing efforts take at least 3-4
  days on Ultra-10/300 MHz/128 Mb, your experiences will be invaluable.
  Would you please share your RAM organization concepts and their influences
  on placement&routing?

  What we have learned are: Design Manager is smart enough to place internal
  RAM's according to minimal routing requirements. We have observed that
  128x1 dual-port RAM structures have been placed as much "square-based"
  as possible (we have seen it at EPIC Editor).

  We have mapped our chip (600-650 CLB's for logic, 1000-1200 CLB's for internal
  RAM's) into several devices and here are the results (it took several
  weeks to get these results):

Device          Speed   Packet  Total CLB's     Mapped  Amount  Unrouted 
		Grade		of device	CLB's		connections
========================================================================
XC4062XL        -3      HQ304   2304 (48x48)    2570    %111    2-2000 
XC4085XLA       -09     HQ304   3136 (56x56)    2580    %85     2-1000
XC40110XV       -09     BG352   4096 (64x64)    2580    %63     2
XC40150XV       -09     BG352   5184 (72x72)    2580    %50     2
XC40200XV       -09     BG432   7056 (84x84)    2590    %37     2
XC40250XV       -09     BG432   8464 (92x92)    2600    %30     2

  Some people also recommended to use Floorplanner. How can we place 128x1?
  Is the tool smart enough to "recognize" our placement? Does it really improve
  the performance significantly? We must expert to use Floorplaner, I think,
  and even for such a complicated chip.

  Utku