1. Home
  2. Field-Programmable Gate Arrays
  3. alternatives to xst-map

alternatives to xst-map

Hallo,

I'm a bit unsatisfied with the "xst 5.2"-design flow for xilinx.

For example, when targeting for SpartanII, "map" isn't able to implement the ROM64x1 primitive, although the device has F5mux and F6mux, so one could code a ROM64X1 äquivalent macro by hand. A more important example is the SRL16 and RAM16X1S primitives. Again, it's "map" reporting, that SRL16 + RAM16X1S aren't supported on F-LUT of a slice on SpartanII, although the SpartanII Data Sheet unmistakeable states: | In addition to operating as a function generator, each LUT can | provide a 16 x 1-bit synchronous RAM. [...] | The Spartan-II LUT can also provide a 16-bit shift register | that is ideal for capturing high-speed or burst-mode data.

I plan to design using mostly self-made tools, and upto now, my plan was to feed completly mapped (but only relativly placed and only partially routed) CLB-lists through HDL into the xst-flow.

Any suggestions on alternative ways to do this?

Furthermore, I'm still searching for exact documentation (hopefully in machine-readable form) of xilinx-device resources. What about these ".spd",".nph",".pkg",".dll",".acd",".usg",".bsd",".lib"-files?

Gruss

Jan Bruns

Reply to
Jan Bruns
Loading thread data ...

"Jan Bruns":

Ok, I've just found the "xdl" tool, wich will do. Nice.

Gruss

Jan Bruns

Reply to
Jan Bruns

[ snip ]

[ snip ]

Jan,

A LUT RAM can be implemented in the F LUT of a SLICE as long as there is also a LUT RAM in the G LUT of the same SLICE. The F LUT RAM hardware is dependent on the G LUT RAM and can not independently support a LUT RAM. This is true for shift registers as well.

-Davis

Reply to
Davis Moore

Ok, that's what "map" seems to be trying to tell us (I'll append it's words below). But isn't that far away from what one could expect to be a hardwired limitation? Say there is a Slice-internal routing resource, that connects F1-4 with G1-4, just to safe global routing resources, when in RAM32X1-mode. Let's further assume, these 4 connects are enabled by only one configuration bit. What might be a practical reason to share this bit with "RAM-F used" (wich might not even exist), instead of sharing it with "MUX5 used"?

After having read the xdl output (not parsed throughly, of course), it seems to me, that there simply isn't even such a "safe global routing resources when using ram32x1"-feature of that kind.

Gruss

Jan Bruns

________________________________________

ERROR:Pack:1118 - The symbol luf_1 was unable to be implemented in a Slice containing no other symbols. RAM cannot be placed in F in RAM 16x1 or 1SHIFT mode. Check that the constraints on this symbol make sense in isolation.

ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=hset, RLOC=R0C0.S0) which require the combination of the following symbols into a single SLICE component: RAM symbol "luf_1" (Output Signal = o1_OBUF) LUT symbol "lug_1" (Output Signal = o2_OBUF) RAM cannot be placed in F in RAM 16x1 or 1SHIFT mode. Please correct the design constraints accordingly.

ERROR:Pack:679 - Unable to obey design constraints (MACRONAME=hset, RLOC=R0C0.S0) which require the combination of the following symbols into a single SLICE component: RAM symbol "luf_1" (Output Signal = o1_OBUF) RAM symbol "lug_1" (Output Signal = o2_OBUF) The address signals must match exactly when using both F and G in RAM mode. Please correct the design constraints accordingly.

Reply to
Jan Bruns

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.