Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 24075

Article: 24075
Subject: Re: Xilinx Core Generators.
From: "K.Orthner" <nospam@ihatespam.com>
Date: Wed, 26 Jul 2000 15:43:20 +0900
Links: << >>  << T >>  << A >>
Okay.

Thanks to both of you for your answers. (Felix & Nicholas)

I used Felix's Perl script, and it worked wonders.  But it created another
couple of entities and instantiatons whixh, it seem, need to be included in
the synthesis for them to be passed to the PnR tools.  (The extra entities
are nothing more than wrappers that include the "for all .. use"
statements.)

So I've gone and ripped the pertinent stuff out of the new dummy files,
de-included (unincluded?) them in the synthesis, and gone from there.

Now, when I simulate (In Aldec), I get something strange . . . if I call the
coregenerated entity in some files, it works, in different files, it
doesn't.

I sent a request to Aldec's website, and I'll stick it here, too.  If anyone
has any suggestions, I'd appreciate it.  If Aldec gets back to me first,
I'll let you know their solution.

-Kent.

--[ Begin message to Aldec. ]-----

Note: I downloaded the newest Xilinx Libraries yesterday or the day before.

I have two file, both of which are trying to use the same Xilinx CoreGen
part.  I am instantiating both parts in exactly the same way.  The one files
compiles happily.  In the other file, I get the mesage "Warning: ELAB1_0026:
cntndr.vhd : (372, 0): There is no default binding for component
"fifo_sr_5x15".(No entity named "fifo_sr_5x15" was found).".

I also have a third file, which once gain uses this CoreGen FIFO, as well as
another CoreGen module.  In this case,the FIFO works fine, but the second
instantiation doesn't.  (Same error message.)



This is the first file (with some parts omitted.), which works fine:

------------xpif_sif.vhd-----------
library IEEE;
use IEEE.std_logic_1164.all;

-- synopsys translate_off
Library XilinxCoreLib;
-- synopsys translate_on

entity XPIF_SIF is

--<snip>--

architecture XPIF_SIF_BLOCKRAM_ARCH of XPIF_SIF is

 component fifo_sr_5x15
  port (
  din: IN std_logic_VECTOR(4 downto 0);
  wr_en: IN std_logic;
  wr_clk: IN std_logic;
  rd_en: IN std_logic;
  rd_clk: IN std_logic;
  ainit: IN std_logic;
  dout: OUT std_logic_VECTOR(4 downto 0);
  full: OUT std_logic;
  empty: OUT std_logic;
  rd_ack: OUT std_logic);
 end component;

-- synopsys translate_off

 for all : fifo_sr_5x15 use entity XilinxCoreLib.async_fifo_v1_0(behavioral)
  generic map(
   c_wr_err_low => 0,
   c_has_rd_count => 0,
   c_has_rd_ack => 1,
   c_wr_ack_low => 0,
   c_has_wr_count => 0,
   c_has_wr_ack => 0,
   c_has_almost_full => 0,
   c_has_almost_empty => 0,
   c_wr_count_width => 2,
   c_rd_count_width => 2,
   c_has_rd_err => 0,
   c_data_width => 5,
   c_has_wr_err => 1,
   c_rd_ack_low => 0,
   c_rd_err_low => 0,
   c_fifo_depth => 15,
   c_enable_rlocs => 1,
   c_use_blockmem => 0);

-- synopsys translate_on

--<snip>--

 begin

 ------------------------------
 --
 --  FIFO's
 --

 PFastFIFO: fifo_sr_5x15
  port map (
   din => PFast_SEM,
   wr_en => PFast_PUSH,
   wr_clk => ALT_CLK,
   rd_en => PFast_POP,
   rd_clk => CLK,
   ainit => RST,
   dout => PFast_OUT,
   full => open,
   empty => PFast_EMPTY,
   rd_ack => PFast_ACK
  );

 PMidFIFO: fifo_sr_5x15
  port map (
   din => PMid_SEM,
   wr_en => PMid_PUSH,
   wr_clk => ALT_CLK,
   rd_en => PMid_POP,
   rd_clk => CLK,
   ainit => RST,
   dout => PMid_OUT,
   full => open,
   empty => PMid_EMPTY,
   rd_ack => PMid_ACK
  );

 P0FIFO: fifo_sr_5x15
  port map (
   din => P0_SEM,
   wr_en => P0_PUSH,
   wr_clk => CLK,
   rd_en => P0_POP,
   rd_clk => CLK,
   ainit => RST,
   dout => P0_OUT,
   full => open,
   empty => P0_EMPTY,
   rd_ack => P0_ACK
  );

 P1FIFO: fifo_sr_5x15
  port map (
   din => P1_SEM,
   wr_en => P1_PUSH,
   wr_clk => CLK,
   rd_en => P1_POP,
   rd_clk => CLK,
   ainit => RST,
   dout => P1_OUT,
   full => open,
   empty => P1_EMPTY,
   rd_ack => P1_ACK
  );

--<snip>--

----------End of Working File.------------------


And here is the second file, wiht which I get the warning:
(Note: I get a warning for BOTH instantiaions.)

----------------cntndr.vhd----------------------

-- synopsys translate_off
Library XilinxCoreLib;
-- synopsys translate_on

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use work.dxc_const.all;

entity CONTENDER is

--<snip>--

architecture CONTENDER_ARCH of CONTENDER is

 component fifo_sr_5x15
  port (
  din: IN std_logic_VECTOR(4 downto 0);
  wr_en: IN std_logic;
  wr_clk: IN std_logic;
  rd_en: IN std_logic;
  rd_clk: IN std_logic;
  ainit: IN std_logic;
  dout: OUT std_logic_VECTOR(4 downto 0);
  full: OUT std_logic;
  empty: OUT std_logic;
  rd_ack: OUT std_logic);
 end component;

-- synopsys translate_off

 for all : fifo_sr_5x15 use entity XilinxCoreLib.async_fifo_v1_0(behavioral)
  generic map(
   c_wr_err_low => 0,
   c_has_rd_count => 0,
   c_has_rd_ack => 1,
   c_wr_ack_low => 0,
   c_has_wr_count => 0,
   c_has_wr_ack => 0,
   c_has_almost_full => 0,
   c_has_almost_empty => 0,
   c_wr_count_width => 2,
   c_rd_count_width => 2,
   c_has_rd_err => 0,
   c_data_width => 5,
   c_has_wr_err => 1,
   c_rd_ack_low => 0,
   c_rd_err_low => 0,
   c_fifo_depth => 15,
   c_enable_rlocs => 1,
   c_use_blockmem => 0);

-- synopsys translate_on

--<snip>--

 begin

--<snip>--

----------------------------------------------------
  --
  -- Search Results FIFO
  --
  -- FIFO only contains the tasks that have been queued.

  SR_FIFO: fifo_sr_5x15
  port map (
   din => SR_FIFO_IN,
   wr_en => SR_FIFO_PUSH,
   wr_clk => CLK,
   rd_en => CAM_SR_WE,
   rd_clk => CLK,
   ainit => RST,
   dout => SR_FIFO_OUT,
   full => open,
   empty => open,
   rd_ack => SR_FIFO_ACK
  );

--<snip>--
  ----------------------------------------------------
  --
  -- Read Results
  --
  -- FIFO only contains the tasks that have been queued.

  RR_FIFO: fifo_sr_5x15
  port map (
   din => RR_FIFO_IN,
   wr_en => RR_FIFO_PUSH,
   wr_clk => CLK,
   rd_en => CAM_RR_WE,
   rd_clk => CLK,
   ainit => RST,
   dout => RR_FIFO_OUT,
   full => open,
   empty => open,
   rd_ack => RR_FIFO_ACK
  );

------------------- End of not working file -------------------

Thanks for the help.
-Kent

--[ End message to Aldec ]----



Article: 24076
Subject: Re: Power PC with Xilinx - what do you think?
From: Andreas Doering <doering@iti.mu-luebeck.de>
Date: Wed, 26 Jul 2000 10:30:26 +0200
Links: << >>  << T >>  << A >>
> Does anyone have a strong opinion about the IBM/Xilinx alliance to put
> Virtex II logic on the same die with an IBM PPC core? Are a lot of you guys
> putting high performance microcontrollers on the same board as big fpga
> designs? Just curious.

1) Congratulations to XILINX that they got IBM with the PowerPC.
2) It is a consequent step on the way to Systems on Silicon
3) In some way it is a gesture of resign towards the "reconfigurable
computing"
   paradigm: if FPGA logic was so cost effective and performant 
   by tailoring to a problem one would not need a standard uP. 
   But if people want absolutely a httpd in every system that has
electronics, 
   give it to them.
4) In some way designing a system meant: choosing the parts, and
sticking them
   together. Later the porgramming/configuring was added. 
   The first step is/was the way towards a cost-effective system.
   If you need a timer/memory/uP just take the most cost effective
   best-fitting device. 
   Manufacturers could specialize parts to be especially good for a
limited 
   purpose. But a Virtex-PowerPC device would be only fit (as you
already said) 
   only at those designs where a high-end FPGA and a powerful uP is
needed 
   anyway. And there are those restrictions, like SW, staff skill, firm
politics,
   etc. that determine the choice of the FPGA and the uP.
   Furthermore you could update your devices individually with
new/cheaper products.
5) Pin-Count. for a lot of designs the device count is determined by the
pins
   required. It remians to discuss whether a one-chip solution is more
effective 
   on pin-count (save the pins for connecting the FPGA to the uP) than a
two-chip 
   solution. 

Andreas

-----------------------------------------------------------------
                        Andreas C. Doering
                        Medizinische Universitaet zu Luebeck
                        Institut fuer Technische Informatik
                        Ratzeburger Allee 160
                        D-23538 Luebeck Germany
		        Email: doering@iti.mu-luebeck.de
                        Home: http://www.iti.mu-luebeck.de/~doering 
"The fear of the LORD is the beginning of ... science" (Proverbs 1.7)
----------------------------------------------------------------
Article: 24077
Subject: ANNOUNCE: Workshop on Embedded Systems & Hardware/Software co-design
From: Tim Forcer <tmf@ecs.soton.ac.uk.nojunk>
Date: Wed, 26 Jul 2000 09:32:18 +0100
Links: << >>  << T >>  << A >>
The UK's Educational ECAD User Group is running a workshop as
usual in September.  This 24th EEUG Workshop will be hosted at
Sheffield University, UK on the 6th and 7th of September 2000.
The topic for the workshop is "Embedded Systems and
Hardware/Software co-design" and it will discuss
recent and future developments in this area.

Full information, including a registration form, is available at
<http://www.eeug.org.uk/sep00/>.

-- 
Tim Forcer               tmf@ecs.soton.ac.uk
Department of Electronics & Computer Science
The University of Southampton, UK

Posted on behalf of the EEUG committee
Article: 24078
Subject: Arithmetic Operators
From: Jamil Khatib <Khatib@opencores.org>
Date: Wed, 26 Jul 2000 11:17:03 +0200
Links: << >>  << T >>  << A >>
Hi,

I use the ieee.std_logic_signed
in order to perform synthesizable arithmetic functions using the
operators +,-,*,/
but I do not know which representation do they use (sign magnitude, 1's
complement or so). I want to use sign magnitude representation

What can I do if some of the operations in the same module are signed
and the others are not? I am trying to append '0' on the left of the
std_logic_vector signals and perform the operation.

Thanks in advance
Jamil Khatib

Article: 24079
Subject: Re: Xilinx "MUX_OP not inferred" error.
From: "K.Orthner" <nospam@ihatespam.com>
Date: Wed, 26 Jul 2000 18:26:25 +0900
Links: << >>  << T >>  << A >>
> Any chance that you are using one-hot encoding? I found that Express
> will use all of your FF outputs to decode each state even when you tell
> it you are one-hot encoded. I forget how I got around the problem, but
> it generated a huge amount of logic in my FSM.

I *am* using one-hot encoding.

> Pick a simple state, like one of the ones where you are just waiting one
> clock cycle and moving on. In the EDIF file, analyze the logic feeding
> this FF. I bet you find an N input AND function being implemented where
> N is the number of states in your one-hot FSM. In one case I got N-1 FFs
> as it used the all zeros case as a state!!!

I've gone through the EDIF file a little bit  (Anybody have a tool to make
reading EDIF files easier?), and it seems to me that for the simple states
that are only there to consume a clock cycle, the .Q of the previous state
flip-flop is connected direcly to the .D of the new one.  So that seems
okay.

Looking at some of my more complicated states, there is a lot more FF's, but
I don't think it's too unreasonable.  But EDIF not being my native tongue,
I'm not sure that I've explored all possibilities.

It seems to me that maybe it'd be smarter to re-write the satae machine, and
instead of using a 'CASE' statement, maybe redefine my state values
explicitly as logic vectors.

> If you look at one of your more complex states with multiple transtions
> into it, that you get such a mess of logic that you have a hard time
> analyzing it!

*I* have a hard time analyzing even the easy states.

> I seem to remember that I had to separate the FFs generated from the
> logic by putting them in separate processes. But this was a year ago and
> I am not sure.

That's what I've done to begin with.
I have one process that does nothing but assign NEXT_STATE to PRESENT_STATE
"as the clock rises", and another one that looks at all the stuff, including
PRESENT_STATE, to determine NEXT_STATE.

Renaming my state variables would make my EDIF file easier to radi, I'm
sure!

Thanks!

-kent

------------
Kent Orthner
korthner at hotmail dot com

Article: 24080
Subject: Pad trireg in XLA FPGA
From: "Isidro Urriza" <urriza@posta.unizar.es>
Date: Wed, 26 Jul 2000 11:42:19 +0200
Links: << >>  << T >>  << A >>
Hello All,

Does any one knows how to use trireg registers in an XLA FPGA?

XLA pads include a flip-flop to register  the control signal of tristate
output buffer
I 've modeled this register in VHDL, synthesised with FPGA express, and
mapped with
 "-pr b" option, but the register is allways placced in an internal CLB not
in trireg pad register.

thanks in advance
----

Isidro Urriza Parroque     PH. 34 976 762379
Dpto. Ing. Electrónica y Comunicaciones  Fax 34 976 762111
C.P.S. Universidad de Zaragoza
c/ M. de Luna, 3
50015 Zaragoza (SPAIN)



Article: 24081
Subject: F3.1 in Great Britain
From: erika_uk@my-deja.com
Date: Wed, 26 Jul 2000 12:50:17 GMT
Links: << >>  << T >>  << A >>
hey,

why all the time the Foundation reaches GREAT BRITAIN months after the
states ???


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24082
Subject: tutorial on configurable system-on-chip design is available
From: Dave Vanden Bout <devb@xess.com>
Date: Wed, 26 Jul 2000 09:28:00 -0400
Links: << >>  << T >>  << A >>
XESS Corp. is releasing the fifthsection of its "myCSoC" tutorial for free downloading at http://www.xess.com/myCSoC-CDROM.html.  We will release a new section each week.

Each section describes a design example for the Triscend configurable system-on-chip device (CSoC).  The Triscend TE505 CSoC integrates an 8051 microcontroller core with a programmable logic array to create a chip whose software and hardware are both reprogrammable.  The tutorial examples show how the Triscend FastChip development software is used to configure the TE505's programmable logic into peripheral functions that cooperate with the microcontroller core.

--
|| Dr. Dave Van den Bout   XESS Corp.               (919) 387-0076 ||
|| devb@xess.com           2608 Sweetgum Dr.        (800) 549-9377 ||
|| http://www.xess.com     Apex, NC 27502 USA   FAX:(919) 387-1302 ||
Article: 24083
Subject: Re: tutorial on configurable system-on-chip design is available
From: "Lewin A.R.W. Edwards" <crazydomainowner@yesthisisavalidreplydomainthoughyouwouldntthinkitwouldyounow.com>
Date: Wed, 26 Jul 2000 13:32:00 GMT
Links: << >>  << T >>  << A >>
> Each section describes a design example for the Triscend configurable
system-on-chip device (CSoC).

*sigh* now if only Triscend would hurry up and release their ARM-core
CSoC... hurry up, guys!

--

-- Lewin A.R.W. Edwards
Embedded Engineer
This message is not posted in any official capacity
and does not represent my employer's opinion or policy
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/



Article: 24084
Subject: Variable shifting
From: Jamil Khatib <Khatib@opencores.org>
Date: Wed, 26 Jul 2000 15:39:40 +0200
Links: << >>  << T >>  << A >>
Hi,

How can I do a shifter shifts the register contents by an amount that is
resulted from another operation.

For example

Shift right (A, by b+c)
shift contents of register 'A' b+c bits to the right in a single clock.


Regards
Jamil Khatib


Article: 24085
Subject: Re: Xilinx Core Generators.
From: felix_bertram@my-deja.com
Date: Wed, 26 Jul 2000 13:55:38 GMT
Links: << >>  << T >>  << A >>
Kent,
my Perl script creates two entitys:
* one with the name you specified in CoreGenerator
* one with an appended "ii" for internal purposes

furthermore it helps you to do the right thing with Active-HDL, as it
automatically adds the created files to your project.

Just to clarify, do one of the following things within Active-HDL to
use it:
* Add the script to your project, right click it and chose 'Execute'
* Add the script to your tools via "Tools" > "Preferences" > "Tools"

This construct frees you from the requirement of defining a tree of
configurations from your top-level all the way down to your
CoreGenerator entity. If you don't do this, you'll get those 'no
default binding' problems. The entitys should be included in your
*simulation* only (as they reference the XilinxCoreLib which is a
simulation library), they will neither synthesize nor implement!

The other thing CoreGenerator creates is an EDIF netlist which should
be included in your *synthesis* and especially your *implementation*. I
feel that it is not a good idea to use the EDIF netlists for functional
simulation.

Hope this helped,
kind regards

Felix Bertram

In article <8lm159$n3c@inf-gw.inf.furukawa.co.jp>,
  "K.Orthner" <nospam@ihatespam.com> wrote:
> Okay.
>
> Thanks to both of you for your answers. (Felix & Nicholas)
>
> I used Felix's Perl script, and it worked wonders.  But it created
another
> couple of entities and instantiatons whixh, it seem, need to be
included in
> the synthesis for them to be passed to the PnR tools.  (The extra
entities
> are nothing more than wrappers that include the "for all .. use"
> statements.)
>
> So I've gone and ripped the pertinent stuff out of the new dummy
files,
> de-included (unincluded?) them in the synthesis, and gone from there.
>
> Now, when I simulate (In Aldec), I get something strange . . . if I
call the
> coregenerated entity in some files, it works, in different files, it
> doesn't.
>
> I sent a request to Aldec's website, and I'll stick it here, too.  If
anyone
> has any suggestions, I'd appreciate it.  If Aldec gets back to me
first,
> I'll let you know their solution.
>
> -Kent.
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 24086
Subject: Re: F3.1 in Great Britain
From: "Henryk Cieslak" <hcentry@poczta.onet.pl>
Date: Wed, 26 Jul 2000 14:28:36 GMT
Links: << >>  << T >>  << A >>
Surely they need some time to translate docs 8-)

HC

erika_uk@my-deja.com napisa³(a) w wiadomo¶ci:
<8lmmq8$fkt$1@nnrp1.deja.com>...
>hey,
>
>why all the time the Foundation reaches GREAT BRITAIN months after the
>states ???
>
>
>Sent via Deja.com http://www.deja.com/
>Before you buy.

Article: 24087
Subject: Re: Xilinx "MUX_OP not inferred" error.
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 Jul 2000 10:54:02 -0400
Links: << >>  << T >>  << A >>
"K.Orthner" wrote:
> I've gone through the EDIF file a little bit  (Anybody have a tool to make
> reading EDIF files easier?), and it seems to me that for the simple states
> that are only there to consume a clock cycle, the .Q of the previous state
> flip-flop is connected direcly to the .D of the new one.  So that seems
> okay.
> 
> Looking at some of my more complicated states, there is a lot more FF's, but
> I don't think it's too unreasonable.  But EDIF not being my native tongue,
> I'm not sure that I've explored all possibilities.
> 
> It seems to me that maybe it'd be smarter to re-write the satae machine, and
> instead of using a 'CASE' statement, maybe redefine my state values
> explicitly as logic vectors.

I expect that this is not the problem. If it is working correctly for
one state, then it is likely working correctly for all the states. 

 
> > If you look at one of your more complex states with multiple transtions
> > into it, that you get such a mess of logic that you have a hard time
> > analyzing it!
> 
> *I* have a hard time analyzing even the easy states.

I would start at the D input to the FF and work backward from there
drawing a schematic of what I found. Basicially the gates in the design
don't need to be drawn on the schematic, but only the LUTs. This will
give you enough information so that you can figure out the logic
dependancies. If you see that every state FF is being used as an input
to the next state logic, then you have a problem. But it sounds like you
don't. 

 
> > I seem to remember that I had to separate the FFs generated from the
> > logic by putting them in separate processes. But this was a year ago and
> > I am not sure.
> 
> That's what I've done to begin with.
> I have one process that does nothing but assign NEXT_STATE to PRESENT_STATE
> "as the clock rises", and another one that looks at all the stuff, including
> PRESENT_STATE, to determine NEXT_STATE.
> 
> Renaming my state variables would make my EDIF file easier to radi, I'm
> sure!

I checked my code and I did explicit state encoding. Here is a code
fragment...

    --                   1         2         4         8
    type StateType is (IDLE,     MEMREQ,   MEMXFER,  CNTLREQ,  -- 1
                       CNTLXFER, STATREQ,  STATXFER, FREQREQ,  -- 10
                       FREQHOLD, FREQXFER, TESTREQ,  TESTRD,   -- 100
                       TESTWR,   PREIDLE);                     -- 1000

    attribute enum_encoding : string;
--	attribute enum_encoding of StateType: type is "one hot";
    attribute enum_encoding of StateType : type is 
    "00000000000001 00000000000010 00000000000100 00000000001000 " &
    "00000000010000 00000000100000 00000001000000 00000010000000 " &
    "00000100000000 00001000000000 00010000000000 00100000000000 " &
    "01000000000000 10000000000000" ;

In the other two compilers that I had tried the "one hot" encoding
attribute, but this did not work well with Express. They may have an app
note on this at the Xilinx web site. 


-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24088
Subject: Retiming for Virtex with FC2
From: Steven Derrien <sderrien@irisa.fr>
Date: Wed, 26 Jul 2000 17:43:27 +0200
Links: << >>  << T >>  << A >>
Hello,

I've been playing around with the retiming capabilities provided with
the latest FC2 version. However, i'm a little bit deceived by the
quality of results  I get from FC2, even when I provide several
registers to allow a deep pipeline of a combinatorial function (up to 10
stage for a 28 logic level comb funtion) I cannot get get less than 20
ns for the critical path.

Does anyone here knows where this limitation could come from ?

Thanks,
Steven


Article: 24089
Subject: Re: Variable shifting
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 Jul 2000 12:13:17 -0400
Links: << >>  << T >>  << A >>
This is called a barrel shifter and requires that you implement a
max(b+c) input mux for each bit of A. Obviously b+c will need to be run
through an adder to get d=b+c. Then d can be used as the control input
to the mux. 

To do this in an FPGA with wide busses and a large range of shift amount
requires an awful lot of resources. Each 4 input LUT can implement a 2
input mux. I believe the newer Xilinx parts can do a 4 input mux in a
slice. But you can see that the slices go pretty quickly if you are
working with wide data busses and you want to shift by any amount from 0
to N. 


Jamil Khatib wrote:
> 
> Hi,
> 
> How can I do a shifter shifts the register contents by an amount that is
> resulted from another operation.
> 
> For example
> 
> Shift right (A, by b+c)
> shift contents of register 'A' b+c bits to the right in a single clock.
> 
> Regards
> Jamil Khatib

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24090
Subject: Re: Variable shifting
From: nullandvoid <mjenkinsNOmjSPAM@iastate.edu.invalid>
Date: Wed, 26 Jul 2000 10:04:40 -0700
Links: << >>  << T >>  << A >>
Jamil Khatib <Khatib@opencores.org> wrote:
>Hi,
>
>How can I do a shifter shifts the register contents by an amount
that is
>resulted from another operation.
>
>For example
>
>Shift right (A, by b+c)
>shift contents of register 'A' b+c bits to the right in a single
clock.
>
>
>Regards
>Jamil Khatib
>

if your register is of type bit_vector and you're using
VHDL'93, you can use the srl (shift-right logical) command like
so:

register_name := register_name srl (b + c);


or you could try a function similar to the following:

function shift_right (
    A : std_logic_vector;
    num_shift : natural) return std_logic_vector is
begin
    for i in num_shift downto 0 loop
        A := '0' & A(A'left downto (A'right + 1));
    end loop;
    return A;
end function shift_right;

you might also want to add a check for num_shift being less than
0 which would mess up the loop.

anyway, FWIW.


ciao,

NaV




-----------------------------------------------------------

Got questions?  Get answers over the phone at Keen.com.
Up to 100 minutes free!
http://www.keen.com

Article: 24091
Subject: Re: Power PC with Xilinx - what do you think?
From: "Steve Casselman" <sc@vcc.com>
Date: Wed, 26 Jul 2000 10:29:45 -0700
Links: << >>  << T >>  << A >>
This is the beginning of the reconfigurable era.  By having two giants like
IBM and Xilinx together you'll create a device that, I predict, will be 10
times faster than the best Microprocessor based systems in whatever area
they go into. This will drive C, C++, and Java based hardware compilers to
better and better performance levels.  If Xilinx can build a very efficient
interface into the configuration store and the system can access it as fast
as L2 cache nothing will stop from knocking out Intel. I predict 2-3 years
after they produce the device in volume everyone will recognize that
reconfigurable computing is the future.

Steve Casselman, President
Virtual Computer Corporation


Article: 24092
Subject: Re: Variable shifting
From: Ray Andraka <ray@andraka.com>
Date: Wed, 26 Jul 2000 17:40:04 GMT
Links: << >>  << T >>  << A >>
There's a better way, rickman!

Do the barrel shift as an optimal merged tree.  You wind up with log2(N)
layers of 2:1 muxes, and if you arrange them right it is not to congestive for
the routing even in 4KE parts even for 32 bit barrel shifts.  Nice thing too
is you can put pipeline registers between layers if you want to trade latency
for data rate.  There's no savings using 4 input muxes in this architecture,
BTW.

rickman wrote:

> This is called a barrel shifter and requires that you implement a
> max(b+c) input mux for each bit of A. Obviously b+c will need to be run
> through an adder to get d=b+c. Then d can be used as the control input
> to the mux.
>
> To do this in an FPGA with wide busses and a large range of shift amount
> requires an awful lot of resources. Each 4 input LUT can implement a 2
> input mux. I believe the newer Xilinx parts can do a 4 input mux in a
> slice. But you can see that the slices go pretty quickly if you are
> working with wide data busses and you want to shift by any amount from 0
> to N.
>
> Jamil Khatib wrote:
> >
> > Hi,
> >
> > How can I do a shifter shifts the register contents by an amount that is
> > resulted from another operation.
> >
> > For example
> >
> > Shift right (A, by b+c)
> > shift contents of register 'A' b+c bits to the right in a single clock.
> >
> > Regards
> > Jamil Khatib
>
> --
>
> Rick Collins
>
> rick.collins@XYarius.com
>
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design
>
> Arius
> 4 King Ave
> Frederick, MD 21701-3110
> 301-682-7772 Voice
> 301-682-7666 FAX
>
> Internet URL http://www.arius.com

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email ray@andraka.com
http://www.andraka.com  or http://www.fpga-guru.com


Article: 24093
Subject: Re: Power PC with Xilinx - what do you think?
From: nweaver@boom.CS.Berkeley.EDU (Nicholas C. Weaver)
Date: 26 Jul 2000 17:46:09 GMT
Links: << >>  << T >>  << A >>
	Although I'm doing research in reconfigurable computing, I am
NOT a big fan of the notion of "reconfigurable, general purpose", but
then again, the Xilinx/IBM part probably is not.  It mostly comes down
to programmability & applications.  

	For those applications in the general purpose world which
conventional processors fall down on and reconfigurable processors do
very well, most also run very well on vector processors, which are
finding their way increasingly into the general purpose ISAs, with
vector machines being easier to program.

	But I AM a big believer in the embedded accelerator and custom
market, and an FPGA & high performance uP combination is an incredably
powerful piece of silicon, because it eliminates the need for a lot of
glue to hold a system together, as well as allowing custom hardware
acceleration for the uP, depending on task.

	Does anyone have much information on what the array looks like
(is it basically a Virtex) and what the processor/array interfare and
the array/IO interface is proposed to be like?
-- 
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu
Article: 24094
Subject: Re: Variable shifting
From: Jerry English <jenglish@planetc.com>
Date: Wed, 26 Jul 2000 15:12:31 -0400
Links: << >>  << T >>  << A >>
A single clock execution requirement brings to my mind a barrel shifter
implementation approach.

regards
Jerry

Jamil Khatib wrote:

> Hi,
>
> How can I do a shifter shifts the register contents by an amount that is
> resulted from another operation.
>
> For example
>
> Shift right (A, by b+c)
> shift contents of register 'A' b+c bits to the right in a single clock.
>
> Regards
> Jamil Khatib

Article: 24095
Subject: Re: Variable shifting
From: asuihkon@beta.hut.fi (Aki M Suihkonen)
Date: 26 Jul 2000 19:42:24 GMT
Links: << >>  << T >>  << A >>
In article <397F20FE.8C6325D1@andraka.com>,
Ray Andraka  <ray@andraka.com> wrote:
>There's a better way, rickman!
>
>Do the barrel shift as an optimal merged tree.  You wind up with log2(N)
>layers of 2:1 muxes, and if you arrange them right it is not to congestive for
>the routing even in 4KE parts even for 32 bit barrel shifts.  Nice thing too
>is you can put pipeline registers between layers if you want to trade latency
>for data rate.  There's no savings using 4 input muxes in this architecture,
>BTW.

except maybe higher throughput with smaller or equal area.
log4(N) layers of 4:1 muxes, each implemented by
2 cascaded logic elements in Altera's FLEX series, perhaps?
-- 
Problems      1) do NOT write a virus or a worm program
"A.K.Dewdney, The New Turing Omnibus; Chapter 60: Computer viruses"
Article: 24096
Subject: Re: Variable shifting
From: murray@pa.dec.com (Hal Murray)
Date: 26 Jul 2000 20:11:05 GMT
Links: << >>  << T >>  << A >>

> This is called a barrel shifter and requires that you implement a
> max(b+c) input mux for each bit of A. Obviously b+c will need to be run
> through an adder to get d=b+c. Then d can be used as the control input
> to the mux. 

Just nit picking, but the adder may not be necessary.  You could
use 2 barrel shifters chained together.

-- 
These are my opinions, not necessarily my employers.  I hate spam.
Article: 24097
Subject: Re: Variable shifting
From: rickman <spamgoeshere4@yahoo.com>
Date: Wed, 26 Jul 2000 17:05:30 -0400
Links: << >>  << T >>  << A >>
I can't say that I know what you mean when you say "an optimal merged
tree." Certainly you would want to connect the muxes in a tree, but what
further optimizations can you do unless you can restrict the range of
the select inputs? 

I would take exception to the statement "There's no savings using 4
input muxes in this architecture". To implement a 4 input mux using 2
input muxes in 4 input LUTs requires 3 LUTs. By using the F5 mux you can
save one LUT. Similarly (after looking at the data sheet) I see that
there is a F6 mux which will allow you to implement an 8 input mux using
just 4 LUTs vs. 7 LUTs by your method. 

Hmmmm... why do I feel like I am missing something important? 



Ray Andraka wrote:
> 
> There's a better way, rickman!
> 
> Do the barrel shift as an optimal merged tree.  You wind up with log2(N)
> layers of 2:1 muxes, and if you arrange them right it is not to congestive for
> the routing even in 4KE parts even for 32 bit barrel shifts.  Nice thing too
> is you can put pipeline registers between layers if you want to trade latency
> for data rate.  There's no savings using 4 input muxes in this architecture,
> BTW.
> 
> rickman wrote:
> 
> > This is called a barrel shifter and requires that you implement a
> > max(b+c) input mux for each bit of A. Obviously b+c will need to be run
> > through an adder to get d=b+c. Then d can be used as the control input
> > to the mux.
> >
> > To do this in an FPGA with wide busses and a large range of shift amount
> > requires an awful lot of resources. Each 4 input LUT can implement a 2
> > input mux. I believe the newer Xilinx parts can do a 4 input mux in a
> > slice. But you can see that the slices go pretty quickly if you are
> > working with wide data busses and you want to shift by any amount from 0
> > to N.
> >
> > Jamil Khatib wrote:
> > >
> > > Hi,
> > >
> > > How can I do a shifter shifts the register contents by an amount that is
> > > resulted from another operation.
> > >
> > > For example
> > >
> > > Shift right (A, by b+c)
> > > shift contents of register 'A' b+c bits to the right in a single clock.
> > >
> > > Regards
> > > Jamil Khatib
> >
> > --
> >
> > Rick Collins
> >
> > rick.collins@XYarius.com
> >
> > Ignore the reply address. To email me use the above address with the XY
> > removed.
> >
> > Arius - A Signal Processing Solutions Company
> > Specializing in DSP and FPGA design
> >
> > Arius
> > 4 King Ave
> > Frederick, MD 21701-3110
> > 301-682-7772 Voice
> > 301-682-7666 FAX
> >
> > Internet URL http://www.arius.com
> 
> --
> -Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com  or http://www.fpga-guru.com

-- 

Rick Collins

rick.collins@XYarius.com

Ignore the reply address. To email me use the above address with the XY
removed.



Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design

Arius
4 King Ave
Frederick, MD 21701-3110
301-682-7772 Voice
301-682-7666 FAX

Internet URL http://www.arius.com
Article: 24098
Subject: Re: Pad trireg in XLA FPGA
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 26 Jul 2000 14:21:25 -0700
Links: << >>  << T >>  << A >>
Isidro Urriza wrote in message <8lmcib$dcn$1@news.unizar.es>...
>Hello All,
>
>Does any one knows how to use trireg registers in an XLA FPGA?
>
>XLA pads include a flip-flop to register  the control signal of tristate
>output buffer
>I 've modeled this register in VHDL, synthesised with FPGA express, and
>mapped with
> "-pr b" option, but the register is allways placced in an internal CLB not
>in trireg pad register.

That's a known issue.  You need to follow the instructions in XAPP123:

http://www.xilinx.com/xapp/xapp123.pdf

Unfortunately, this process is convoluted.  One would hope that the P+R
software would be to handle this nifty feature, but it doesn't.  And the
word I got from one of the Xilinx apps engineers is that this issue will
never be fixed.


-- a
-----------------------------------------
Andy Peters
Sr Electrical Engineer
National Optical Astronomy Observatories
950 N Cherry Ave
Tucson, AZ 85719
apeters (at) noao \dot\ edu

"A sufficiently advanced technology is indistinguishable from magic"
     --Arthur C. Clarke



Article: 24099
Subject: Re: Variable shifting
From: "Gilbert H. Herbeck" <gilherbeck@home.com>
Date: Wed, 26 Jul 2000 22:13:02 GMT
Links: << >>  << T >>  << A >>
rickman wrote:

> I can't say that I know what you mean when you say "an optimal merged
> tree." Certainly you would want to connect the muxes in a tree, but what
> further optimizations can you do unless you can restrict the range of
> the select inputs?
>
> I would take exception to the statement "There's no savings using 4
> input muxes in this architecture". To implement a 4 input mux using 2
> input muxes in 4 input LUTs requires 3 LUTs. By using the F5 mux you can
> save one LUT. Similarly (after looking at the data sheet) I see that
> there is a F6 mux which will allow you to implement an 8 input mux using
> just 4 LUTs vs. 7 LUTs by your method.
>
> Hmmmm... why do I feel like I am missing something important?

Rickman, you and Aki just haven't come across a barrel shifter before.
It's not that complicated, but if you don't know what it is you can make
some bad assumptions.  I would make Ray's statement much more
strongly.  Not only do 4-1 muxes not save you anything, they *COST*
you.

Take an 8 bit shifter as an example.  The proper implementation
is 3 banks of 2-1 muxes.  That makes 3 2-1 muxes per bit (log2(8)=3).
If you choose to use 4-1 muxes, the best you can do is 1 4-1 mux +
1 2-1 mux per bit.

Compare a 4-1 mux -vs- 2 2-1 muxes for your technology.
8-1 muxes make things even worse.  And as the shifter gets
larger, the % penalty gets even worse.

Lastly, the stages of the shifter can be ordered to exploit the
delay skew in the shift amount.  In this case the original poster
said that the shift signal was coming from an adder.  Therefore
use the shift bits from LSB to MSB and the adder delay will be
mostly in parallel with the shifter itself.

Gil




Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarApr2017

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search