Design is too large for the device! xc3s400

Is your design giving you registers for your shift elements? The SRL16 primitives can cut that utilization by a significant amount. You can also use BlockRAM to perform a shift register function.

There are many solutions at your disposal but no true idea of what your overall constraits are.

Is the shift register the only thing in the design? Are you using a reset for those shift elements? Is it serial-in, serial-out? Are there frequency constraints? Is the shift register fixed in length or variable?

Nopes I have my design doing a whole lot of things...but its only when I changed the length of the shift register that I came across the Mapping error.

I am not using any reset...It takes in a clock...and shifts a bit for every rising edge of the clock...

Yes its serial_in and serial_out

No.

Its a variable shift register....the length is determined by an input variable called "right".

The code is as follows: entity shifting_two is Port ( shiftin : in std_logic; clock_in : in std_logic; right : in integer; shiftout : out std_logic); end shifting_two;

architecture Behavioral of shifting_two is

signal shift_register : std_logic_vector ( 3454 downto 0 ):= (others =>

'0');

begin

process(clock_in) begin if rising_edge(clock_in) then shift_register

Methi,

You can use a circular buffer implemented by BRAM.

What are you doing with this shift register afterwards?

Vladislav

Methi, when you say "wide", I believe you mean "long" or "deep". With SRL16s you can cut the size by a factor 16, but you do not have parallel access to all the bits in your shift register. Even more compact is a BlockRAM, where you can pack >16000 bits into one BlockRAM. So it all depends on how you use your shift register, and how you have o control it... Peter Alfke

Thankyou Peter

Its a 3454 bit shift register.....By saying "wide" ,I am talking about the depth...

What I am trying to do is...depending on the value of the variable "right"...for eg: if right=2300, then the output would be the 2200th bit of the shift register.

This would be mean that I need access to all the bits in the shift register...

Does this mean that I would get access only to the MSB and not the individual bits like how it does in my code at present?

How do I use this BlockRAM....to work as shift register...

I am just using the output of my shift register...which is the MSB (this keeps changing depending on the value of the variable "right")...as input to another component....its a pulse...

I've come across this core in Xilinx which is a RAM-based shift register....It takes in clock:rising edge clock signal, serial input, address input(for variable length) and gives out a serial out...

Would using this core instead of the code I have save any resources...

Am wondering if anybody has worked with this before..

Otherwise the options I have so far is to go for:

2) Cicular buffer with RAM

Thanks,

Methi

For that, you want to use a block RAM, which will give you up to 18K bits length. You can either use two address counters, one for the read side of the memory and one for the write side, and offset the address of the write counter so that the read count trails it by N where N is the shift register length, or you can use a single counter set up as a modulo N count (use a loadable downcount for that, thereby keeping it to one level of logic. If you were using an older Xilinx fpga, you'd need to delay the read by a clock relative to the write for this second scheme because they didn't support read before write operation. With the spartan3, you can set the attribute on the bram for read first, which allows you to apply the same address to both the read and the write ports. It is easier if you instantiate the BRAM rather than trying to let the software figure it out.

Hi Ray,

Are you talking about a BRAM core available in Xilinx?

Ive only come across the RAM based shift reg which goes upto 1024 bits (xilinx 6.3i)

Or Should I be working on a BRAM code in vhdl...

Thanks,

Methi

I was talking about a VHDL module with an instantiated RAMB16 primitive in it. Something like this should do the trick for you:

nxt_addr

If you are delaying a single pulse/edge for 3454 ticks, there are easier ways to do it than with a shift register.

-- Mike Treseler

Methi, Take a BlockRAM, with both ports configured as 16K x 1. Make one port Write and the other one Read. Clock both ports with your data clock. Drive the Write address with a counter that you increment with the data clock. Drive the Read address from a subtractor circuit that subtracts the length N of your shift register from the Write address. Now you have a programmable-length shift register from the D input of the write port to the Q output of the Read port. And you get up to 16K bit length in a single BRAM plus four CLBs (14 bit counter plus 14-bit subtractor). Peter Alfke

Exactly. He should use a counter that's initialized to required delay and enabled when he sees his input pulse. It counts down, and when it hits zero, an output pulse is generated and the counter is preset back to his initial value.

There's nothing like getting set on one solution and stubbornly pursuing it to the point where you're blind to other, simpler, solutions.

-a

Peter, with SPartan3, he can do it with one port of the BRAM if he uses a modulo-N count instead of a straight 14 bit binary count. I showed this in the code I posted earlier. The modulo N count is easy if you do it as a loadable down-count that reloads itself when it goes negative.

Mike, I assumed this was more like a line buffer where he needed to delay a sequence of bits by the 3454 clocks. If it is indeed just a delay from a single pulse and you can guarantee that another pulse does not occur until the first one has propagated out, then it can be done with just a counter.

I am trying to delay a pulse by N ticks where N takes a maximum value of 3454...N is a variable here....

Ray, pretty clever. But more difficult to understand, or to modify. And what do I do with the unused port?

But nevertheless, hats off to a smart solution... Peter

methi schrieb:

methi schrieb:

Yes, but a single pulse, or many pulses? That was Rays question. Can you guarantee that there at most M pulses within 3454 clock cycles? (with a small value of M)

Kolja Sulimma