BYTE shifter

I wanted to perform a byte shifting of a 24bit vector . the resultant vector is a 48 bit vector . the following is the functinality needed

signal BV : std_logic_vector(23 downto 0); signal BYTE_SEL : std_logic_Vector(1 downto 0); signal BVOUT : std_logic_Vector(47 downto 0);

method 1 BVOUT BYTE_SEL, qout => MUL) BV_d1 MUL, M2 => BV_d1 , clock => clock, BVOUT);

I would like to know if the above method 1 of the behavioural statement is a good way of programming when I am implementing on the FPGa or should I implement it using a ROM where I store a multiplier constant and use the byte_sel as an address to select it and then multiply with the pipelined BV to generate the output. Or is there any other better way to implement it other than the above two methods.

Thanks, D

Reply to
ni
Loading thread data ...

This will likely get implemented something like a 3 bit 'and for each bit (i.e. bit 0 out = bit 0 in when byte_sel=00) , so basically 1 logic cell per bit...not too bad.

Yes it is.

Now you're obscuring your real design intent in the hopes of improving either logic resource or performance (not sure which). Unless your targetted part has 32 bit hardware multipliers, the resulting implementation may consist of two smaller multipliers plus some logic to combine the outputs into the final result or some logic on the front end into the multiplier, a single multiplier and then some additional logic on the output side. Possibly a better approach would be to break it down into two independent 16 bit multipliers where one of the multipliers would end up multiplying by 0, the other by either 1 or 256.

In any case, I'm guessing that any solution along those lines would probably have a hard time being better than the single level of logic per bit required for method 1.

Possibly. But the best way to explore implementation ideas is with synthesis software which allows you to implement the idea and get pretty immediate feedback via their RTL and technology map viewers as well as logic resource and timing performance so you can get a feel for which methods are 'better' than others for how you intend to use it.

One important thing you've done is tried to see the problem from different perspectives. Method 1 is a view that is basically a 4>1 multiplexer view whereas method 2 views the problem from an arithmetic view. It got a bit convoluted by thinking of using a ROM lookup table when the multipliers are a fairly trivial function of the input byte_sel.

If you have ISE, Quartus, Synplify, etc. try out your ideas and you'll get quicker turn around then the newsgroup approach.

Kevin Jennings

Reply to
KJ

Thanks Kevin.

-D

Reply to
ni

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.