Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
On Sep 2, 1:43=A0pm, Thomas Womack <twom...@chiark.greenend.org.uk> wrote: > In article <134260ba-aafa-4926-862f-38398b410...@f20g2000prn.googlegroups= .com>, > Weng Tianxiang =A0<wtx...@gmail.com> wrote: > > >Hi, > >I am designing a circuit to calculate GF(233) multiplication. > > >Where can I find a correct digital example or a GF calculator to check > >if my GF(233) multiplication is correct? > > Are you actually working modulo the integer 233, or in the field with > 2^33 elements, or in the field with 2^233 elements? > > It's probably the last of those three cases, in which case: what is > the polynomial defining your field? =A0Let's say it's x^233+x^97+x+1 > > Get hold of a Linux machine and install the 'pari-gp' package, define > > e=3DMod(1,2) > f=3De*(x^233+x^97+x+1) > X=3DMod(x,ff) > > then you can multiply polynomials in X and check that you get the > answer you expect. > > Tom Hi Tom, You are right. GF(2^233) and to ckeck its multiplications. Irreducible polynomical can be anything. What is the 'pari-gp' website address? 'pari-gp' problem is I don't have Linix machine and related liberaries. I will try any of those softwares using Windos system: http://orms.mfo.de/search?terms=3Dfinite%20fields Here is another topics: Recently I read the following paper: FPGA DESIGNS OF PARALLEL HIGH PERFORMANCE GF(2^233) MULTIPLIERS published in 2003, it claims that it was the fastest system in FPGA to calculate GF(2^233) multiplications. Its irreducible polynominal is x^233+x^74+1. Multiplier LUT/FF equivalent gate count clock period (Frequency) Classical(estmd.) 37296 / 37552 528427 =BB13.00ns (=BB77 MHz) HybridKaratsuba 11746 / 13941 182007 11.07ns (90.33Mhz) MasseyOmura 36857 / 8543 289489 15.91ns (62.85MHz) SunarKoc=B8 45435 / 41942 608149 10.73ns (93.20MHz) Any comments? Thank you. WengArticle: 142826
> > With a lot of money for some high-dollar tools, it is possible to > synthesize an FPGA design from a description written in the C > language. Then you place and route that synthesized netlist using the > FPGA vendor's tools (some available for free). > It's perhaps interesting to note that Altera's C2H compiler is available in their web-edition software; not a true C to hardware compiler, nor really free (OpenCore plus), but impressive none-the- less. I've been meaning to spend some time with it for a while now. Andy.Article: 142827
On Sep 2, 11:49=A0am, 2G <soar2mor...@yahoo.com> wrote: > On Sep 2, 11:10=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > > > > On Wed, 2 Sep 2009 10:43:27 -0700 (PDT), 2G <soar2mor...@yahoo.com> > > wrote: > > > >I have a TI TLK2501 SERDES connected to a Virtex-5 on an ML507. The V5 > > >is loading the recovered clock signal with an apparent impedance of 50 > > >ohms (measured by the voltage drop across a series resistor). This is > > >dropping the voltage swing of the signal in half. We have tried a > > >different input pin with no change. We then added a buffer with no > > >change. The ucf for that input is: > > > >NET "RX_CLK" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25; > > > >This is not happening to any of the other inputs from the SERDES. > > > >Any ideas as to what is going on? > > > Did you check the board schematics? This signal seems to be connected > > to the CPLD also which might be causing the issue you see. > > > -- > > Muzaffer Kal > > > DSPIA INC. > > ASIC/FPGA Design Services > > >http://www.dspia.com > > Yes, we are aware of that. We previously used AJ32 and had the same > problem. We used it because it was the only global clock input > available (ISE kept complaining about using that input for a clock > source). If need be, we can isolate the CPLD and LED from that line > (we removed the LED and got no change). > > We just tried rerouting that signal to the USER_CLK after removing the > oscillator (X1). This greatly improved the signal quality, but > requires a flying wire off of our mezzanine board to make the > connection.- Hide quoted text - > > - Show quoted text - How are you physically connecting the TLK2501 to the ML507? Ed McGettigan -- Xilinx Inc.Article: 142828
On 9=D4=C23=C8=D5, =C9=CF=CE=E73=CA=B105=B7=D6, "Antti.Luk...@googlemail.co=
m"
<antti.luk...@googlemail.com> wrote:
> On Sep 2, 9:35 pm, kclo4 <alexis.ga...@gmail.com> wrote:
>
>
>
>
>
> > On Sep 2, 8:20 am, "Antti.Luk...@googlemail.com"
>
> > <antti.luk...@googlemail.com> wrote:
> > > On Sep 2, 4:21 am, "murl...@gmail.com" <water9...@yahoo.com> wrote:
>
> > > > On 9=D4=C21=C8=D5, =CF=C2=CE=E71=CA=B125=B7=D6, "Antti.Luk...@googl=
email.com"
>
> > > > <antti.luk...@googlemail.com> wrote:
> > > > > On Sep 1, 6:56 am, "murl...@gmail.com" <water9...@yahoo.com> wrot=
e:
>
> > > > > > On 8=D4=C231=C8=D5, =CF=C2=CE=E73=CA=B122=B7=D6, "Antti.Luk...@=
googlemail.com"
>
> > > > > > <antti.luk...@googlemail.com> wrote:
> > > > > > > On Aug 31, 3:55 am, "murl...@gmail.com" <water9...@yahoo.com>=
wrote:
>
> > > > > > > > On 8=D4=C230=C8=D5, =CF=C2=CE=E72=CA=B102=B7=D6, "Antti.Luk=
...@googlemail.com"
>
> > > > > > > > <antti.luk...@googlemail.com> wrote:
> > > > > > > > > On Aug 30, 8:32 am, "murl...@gmail.com" <water9...@yahoo.=
com> wrote:
>
> > > > > > > > > > On 8=D4=C228=C8=D5, =CF=C2=CE=E76=CA=B127=B7=D6, "Antti=
.Luk...@googlemail.com"
>
> > > > > > > > > > <antti.luk...@googlemail.com> wrote:
> > > > > > > > > > > On Aug 28, 11:01 am, water <water9...@yahoo.com> wrot=
e:
>
> > > > > > > > > > > > who have the available wrapper?
>
> > > > > > > > > > > wau do you think its only the wrapper you need?
> > > > > > > > > > > ask PLDA what their USB 3.0 IP cores costs
> > > > > > > > > > > then think how likely is to get a free IP
>
> > > > > > > > > > > Antti
> > > > > > > > > > > asics.ws also has usb 3.0 solutions i think
>
> > > > > > > > > > i only need this wrapper.
>
> > > > > > > > > 1) contact PLDA
> > > > > > > > > 2) contact asics.ws
> > > > > > > > > 3) write yourself
>
> > > > > > > > > Antti
> > > > > > > > > PS look at your rating:
> > > > > > > > > you have been rated 20 times, and the rating score is 1 o=
ut 5,
> > > > > > > > > means that.. [insert here....]
>
> > > > > > > > > there is no need for wrapper if you dont have the USB 3.0=
IP
> > > > > > > > > but if you have the IP, you would also have the wrapper..
>
> > > > > > > > I have designed usb3.0 host controller sucessfully. but i n=
eed verify
> > > > > > > > it at V5/V6 device.I need the usb3.0 PHY wrapper for V5/V6 =
device.- Hide quoted text -
>
> > > > > > > > - Show quoted text -
>
> > > > > > > try using 1GbE setting for MGT wrapper, if you test with your=
own test
> > > > > > > IP it should work already
>
> > > > > > > Antti- =D2=FE=B2=D8=B1=BB=D2=FD=D3=C3=CE=C4=D7=D6 -
>
> > > > > > > - =CF=D4=CA=BE=D2=FD=D3=C3=B5=C4=CE=C4=D7=D6 -
>
> > > > > > it doesn't work with PCIE GEN2 template.
>
> > > > > > Can it work with 1GbE template? why?
>
> > > > > writing a IP core is 10% of the work
> > > > > sim testbench, verification ,FPGA testing,
> > > > > test software, compliance testing, documentation
>
> > > > > make up the 90%
>
> > > > > are you asking i do that 90% for you?
> > > > > for 50% share of your potential profits, I might..:)
> > > > > or if you plan to open-source it, i also would help you
> > > > > but if you want to cash-in i will not do your work
>
> > > > > hm.. but u are welcome to contact me in private, still
>
> > > > > Antti- =D2=FE=B2=D8=B1=BB=D2=FD=D3=C3=CE=C4=D7=D6 -
>
> > > > > - =CF=D4=CA=BE=D2=FD=D3=C3=B5=C4=CE=C4=D7=D6 -
>
> > > > it is very easy for me write the wrapper.
>
> > > > i only want to know if the 1GbE template works for usb3.0 pipe PHY=
.
>
> > > if it very easy why dont you do it?
>
> > > Antti
>
> > because it is too easy to do it, so he prefer to help some lower level
> > engineer to train himself by doing something for free for him...
>
> not all things that look easy are
> ..well at least until you have done them
> and even then when done (easily) the way to them may not be as easy
>
> (and this is true in the case of the wrapper in question too..:)
>
> Antti- =D2=FE=B2=D8=B1=BB=D2=FD=D3=C3=CE=C4=D7=D6 -
>
> - =CF=D4=CA=BE=D2=FD=D3=C3=B5=C4=CE=C4=D7=D6 -
unfortunately,it doesn't work. the following is the tile file
according to GbE template.my part number is V6LX240T.
thanks
module usb3phy_gtx #
(
// Simulation attributes
parameter GTX_SIM_GTXRESET_SPEEDUP =3D 0, // Set to 1 to
speed up sim reset
// Share RX PLL parameter
parameter GTX_TX_CLK_SOURCE =3D "TXPLL",
// Save power parameter
parameter GTX_POWER_SAVE =3D 10'b0000000000
)
(
//---------------------- Loopback and Powerdown Ports
----------------------
input [1:0] RXPOWERDOWN_IN,
input [1:0] TXPOWERDOWN_IN,
//--------------------- Receive Ports - 8b10b Decoder
----------------------
output [3:0] RXCHARISK_OUT,
output [3:0] RXDISPERR_OUT,
output [3:0] RXNOTINTABLE_OUT,
//----------------- Receive Ports - Clock Correction Ports
-----------------
output [2:0] RXCLKCORCNT_OUT,
//------------- Receive Ports - Comma Detection and Alignment
--------------
output RXBYTEISALIGNED_OUT,
output RXBYTEREALIGN_OUT,
output RXCOMMADET_OUT,
input RXENMCOMMAALIGN_IN,
input RXENPCOMMAALIGN_IN,
//----------------- Receive Ports - RX Data Path interface
-----------------
output [31:0] RXDATA_OUT,
input RXRESET_IN,
input RXUSRCLK_IN,
input RXUSRCLK2_IN,
//----- Receive Ports - RX Driver,OOB signalling,Coupling and
Eq.,CDR ------
input RXCDRRESET_IN,
output RXELECIDLE_OUT,
input RXN_IN,
input RXP_IN,
//------ Receive Ports - RX Elastic Buffer and Phase Alignment
Ports -------
input RXBUFRESET_IN,
output [2:0] RXBUFSTATUS_OUT,
output [2:0] RXSTATUS_OUT,
//---------------------- Receive Ports - RX PLL Ports
----------------------
input GTXRXRESET_IN,
input [1:0] MGTREFCLKRX_IN,
input PLLRXRESET_IN,
output RXPLLLKDET_OUT,
input [1:0] RXRATE_IN,
output RXRATEDONE_OUT,
output RXRESETDONE_OUT,
//------------ Receive Ports - RX Pipe Control for PCI Express
-------------
output PHYSTATUS_OUT,
output RXVALID_OUT,
//--------------- Receive Ports - RX Polarity Control Ports
----------------
input RXPOLARITY_IN,
//-------------- Transmit Ports - 8b10b Encoder Control Ports
--------------
input [3:0] TXCHARISK_IN,
//---------------- Transmit Ports - TX Data Path interface
-----------------
input [31:0] TXDATA_IN,
output TXOUTCLK_OUT,
input TXRESET_IN,
input TXUSRCLK_IN,
input TXUSRCLK2_IN,
//-------------- Transmit Ports - TX Driver and OOB signaling
--------------
output TXN_OUT,
output TXP_OUT,
//--------------------- Transmit Ports - TX PLL Ports
----------------------
input GTXTXRESET_IN,
input [1:0] MGTREFCLKTX_IN,
input PLLTXRESET_IN,
output TXPLLLKDET_OUT,
input [1:0] TXRATE_IN,
output TXRATEDONE_OUT,
output TXRESETDONE_OUT,
//--------------- Transmit Ports - TX Ports for PCI Express
----------------
input TXDEEMPH_IN,
input TXDETECTRX_IN,
input TXELECIDLE_IN,
input [2:0] TXMARGIN_IN,
input TXPDOWNASYNCH_IN,
input TXSWING_IN
);
// synthesis attribute X_CORE_INFO of USB3PHY_GTX is
"v6_gtxwizard_v1_2, Coregen v11.2";
//***************************** Wire Declarations
*****************************
// ground and vcc signals
wire tied_to_ground_i;
wire [63:0] tied_to_ground_vec_i;
wire tied_to_vcc_i;
wire [63:0] tied_to_vcc_vec_i;
//RX Datapath signals
wire [31:0] rxdata_i;
//TX Datapath signals
wire [31:0] txdata_i;
//
//********************************* Main Body of
Code**************************
//------------------------- Static signal Assigments
---------------------
assign tied_to_ground_i =3D 1'b0;
assign tied_to_ground_vec_i =3D 64'h0000000000000000;
assign tied_to_vcc_i =3D 1'b1;
assign tied_to_vcc_vec_i =3D 64'hffffffffffffffff;
//------------------- GTX Datapath byte mapping
-----------------
// The GTX provides little endian data (first byte received on
RXDATA[7:0])
assign RXDATA_OUT =3D rxdata_i;
// The GTX transmits little endian data (TXDATA[7:0] transmitted
first)
assign txdata_i =3D TXDATA_IN;
//------------------------- GTX Instantiations
--------------------------
GTXE1 #
(
//_______________________ Simulation-Only Attributes
__________________
.SIM_RECEIVER_DETECT_PASS ("TRUE"),
.SIM_TX_ELEC_IDLE_LEVEL ("X"),
.SIM_GTXRESET_SPEEDUP (GTX_SIM_GTXRESET_SPEEDUP),
.SIM_VERSION ("1.0"),
.SIM_TXREFCLK_SOURCE (3'b000),
.SIM_RXREFCLK_SOURCE (3'b000),
//--------------------------TX
PLL----------------------------
.TX_CLK_SOURCE
(GTX_TX_CLK_SOURCE),
.TX_OVERSAMPLE_MODE ("FALSE"),
.TXPLL_COM_CFG (24'h21680a),
.TXPLL_CP_CFG (8'h00),
.TXPLL_DIVSEL_FB (2),
.TXPLL_DIVSEL_OUT (1),
.TXPLL_DIVSEL_REF (1),
.TXPLL_DIVSEL45_FB (5),
.TXPLL_LKDET_CFG (3'b111),
.TX_CLK25_DIVIDER (10),
.TXPLL_SATA (2'b00),
.TX_TDCC_CFG (2'b11),
.PMA_CAS_CLK_EN ("FALSE"),
.POWER_SAVE (GTX_POWER_SAVE),
//-----------------------TX
Interface-------------------------
.GEN_TXUSRCLK ("FALSE"),
.TX_DATA_WIDTH (40),
.TX_USRCLK_CFG (6'h00),
.TXOUTCLK_CTRL
("TXOUTCLKPMA_DIV2"),
.TXOUTCLK_DLY (10'b0000000000),
//------------TX Buffering and Phase
Alignment----------------
.TX_PMADATA_OPT (1'b0),
.PMA_TX_CFG (20'h00082),
.TX_BUFFER_USE ("TRUE"),
.TX_BYTECLK_CFG (6'h00),
.TX_EN_RATE_RESET_BUF ("TRUE"),
.TX_XCLK_SEL ("TXOUT"),
.TX_DLYALIGN_CTRINC (4'b0100),
.TX_DLYALIGN_LPFINC (4'b0110),
.TX_DLYALIGN_MONSEL (3'b000),
.TX_DLYALIGN_OVRDSETTING (8'b10000000),
//-----------------------TX
Gearbox---------------------------
.GEARBOX_ENDEC (3'b000),
.TXGEARBOX_USE ("FALSE"),
//--------------TX Driver and OOB
Signalling------------------
.TX_DRIVE_MODE ("PIPE"),
.TX_IDLE_ASSERT_DELAY (3'b100),
.TX_IDLE_DEASSERT_DELAY (3'b010),
.TXDRIVE_LOOPBACK_HIZ ("FALSE"),
.TXDRIVE_LOOPBACK_PD ("FALSE"),
//------------TX Pipe Control for PCI Express/
SATA------------
.COM_BURST_VAL (4'b1111),
//----------------TX Attributes for PCI
Express---------------
.TX_DEEMPH_0 (5'b11010),
.TX_DEEMPH_1 (5'b10000),
.TX_MARGIN_FULL_0 (7'b1001110),
.TX_MARGIN_FULL_1 (7'b1001001),
.TX_MARGIN_FULL_2 (7'b1000101),
.TX_MARGIN_FULL_3 (7'b1000010),
.TX_MARGIN_FULL_4 (7'b1000000),
.TX_MARGIN_LOW_0 (7'b1000110),
.TX_MARGIN_LOW_1 (7'b1000100),
.TX_MARGIN_LOW_2 (7'b1000010),
.TX_MARGIN_LOW_3 (7'b1000000),
.TX_MARGIN_LOW_4 (7'b1000000),
//--------------------------RX
PLL----------------------------
.RX_OVERSAMPLE_MODE ("FALSE"),
.RXPLL_COM_CFG (24'h21680a),
.RXPLL_CP_CFG (8'h00),
.RXPLL_DIVSEL_FB (2),
.RXPLL_DIVSEL_OUT (1),
.RXPLL_DIVSEL_REF (1),
.RXPLL_DIVSEL45_FB (5),
.RXPLL_LKDET_CFG (3'b111),
.RX_CLK25_DIVIDER (10),
//-----------------------RX
Interface-------------------------
.GEN_RXUSRCLK ("FALSE"),
.RX_DATA_WIDTH (40),
.RXRECCLK_CTRL
("RXRECCLKPMA_DIV2"),
.RXRECCLK_DLY (10'b0000000000),
.RXUSRCLK_DLY (16'h0000),
//--------RX Driver,OOB signalling,Coupling and
Eq.,CDR-------
.AC_CAP_DIS ("TRUE"),
.CDR_PH_ADJ_TIME (5'b10100),
.OOBDETECT_THRESHOLD (3'b011),
.PMA_CDR_SCAN (27'h640404C),
.PMA_RX_CFG (25'h05ce048),
.RCV_TERM_GND ("TRUE"),
.RCV_TERM_VTTRX ("FALSE"),
.RX_EN_IDLE_HOLD_CDR ("FALSE"),
.RX_EN_IDLE_RESET_FR ("TRUE"),
.RX_EN_IDLE_RESET_PH ("TRUE"),
.TX_DETECT_RX_CFG (14'h1832),
.TERMINATION_CTRL (5'b10100),
.TERMINATION_OVRD ("FALSE"),
.CM_TRIM (2'b01),
.PMA_RXSYNC_CFG (7'h00),
.PMA_CFG
(76'h0000000000000000000),
.BGTEST_CFG (2'b00),
.BIAS_CFG (17'h00000),
//------------RX Decision Feedback Equalizer
(DFE)-------------
.DFE_CAL_TIME (5'b01100),
.DFE_CFG (8'b00011011),
.RX_EN_IDLE_HOLD_DFE ("TRUE"),
.RX_EYE_OFFSET (8'h4C),
.RX_EYE_SCANMODE (2'b00),
//-----------------------PRBS
Detection-----------------------
//----------------Comma Detection and
Alignment---------------
.ALIGN_COMMA_WORD (1),
.COMMA_10B_ENABLE (10'b0011111111),
.COMMA_DOUBLE ("FALSE"),
.DEC_MCOMMA_DETECT ("FALSE"),
.DEC_PCOMMA_DETECT ("FALSE"),
.DEC_VALID_COMMA_ONLY ("TRUE"),
.MCOMMA_10B_VALUE (10'b1010000011),
.MCOMMA_DETECT ("TRUE"),
.PCOMMA_10B_VALUE (10'b0101111100),
.PCOMMA_DETECT ("TRUE"),
.RX_DECODE_SEQ_MATCH ("TRUE"),
.RX_SLIDE_AUTO_WAIT (5),
.RX_SLIDE_MODE ("AUTO"),
.SHOW_REALIGN_COMMA ("FALSE"),
//---------------RX Loss-of-sync State
Machine----------------
.RX_LOS_INVALID_INCR (8),
.RX_LOS_THRESHOLD (128),
.RX_LOSS_OF_SYNC_FSM ("FALSE"),
//-----------------------RX
Gearbox---------------------------
.RXGEARBOX_USE ("FALSE"),
//-----------RX Elastic Buffer and Phase
alignment------------
.RX_BUFFER_USE ("TRUE"),
.RX_EN_IDLE_RESET_BUF ("TRUE"),
.RX_EN_MODE_RESET_BUF ("TRUE"),
.RX_EN_RATE_RESET_BUF ("TRUE"),
.RX_EN_REALIGN_RESET_BUF ("TRUE"),
.RX_EN_REALIGN_RESET_BUF2 ("FALSE"),
.RX_FIFO_ADDR_MODE ("FULL"),
.RX_IDLE_HI_CNT (4'b1000),
.RX_IDLE_LO_CNT (4'b0000),
.RX_XCLK_SEL ("RXREC"),
.RX_DLYALIGN_CTRINC (4'b0100),
.RX_DLYALIGN_EDGESET (5'b00010),
.RX_DLYALIGN_LPFINC (4'b0110),
.RX_DLYALIGN_MONSEL (3'b000),
.RX_DLYALIGN_OVRDSETTING (8'b10000000),
//----------------------Clock
Correction----------------------
.CLK_COR_ADJ_LEN (2),
.CLK_COR_DET_LEN (2),
.CLK_COR_INSERT_IDLE_FLAG ("FALSE"),
.CLK_COR_KEEP_IDLE ("FALSE"),
.CLK_COR_MAX_LAT (18),
.CLK_COR_MIN_LAT (14),
.CLK_COR_PRECEDENCE ("TRUE"),
.CLK_COR_REPEAT_WAIT (0),
.CLK_COR_SEQ_1_1 (10'b0110111100),
.CLK_COR_SEQ_1_2 (10'b0001010000),
.CLK_COR_SEQ_1_3 (10'b0000000000),
.CLK_COR_SEQ_1_4 (10'b0000000000),
.CLK_COR_SEQ_1_ENABLE (4'b1111),
.CLK_COR_SEQ_2_1 (10'b0110111100),
.CLK_COR_SEQ_2_2 (10'b0010110101),
.CLK_COR_SEQ_2_3 (10'b0000000000),
.CLK_COR_SEQ_2_4 (10'b0000000000),
.CLK_COR_SEQ_2_ENABLE (4'b1111),
.CLK_COR_SEQ_2_USE ("TRUE"),
.CLK_CORRECT_USE ("TRUE"),
//----------------------Channel
Bonding----------------------
.CHAN_BOND_1_MAX_SKEW (1),
.CHAN_BOND_2_MAX_SKEW (1),
.CHAN_BOND_KEEP_ALIGN ("TRUE"),
.CHAN_BOND_SEQ_1_1 (10'b0001001010),
.CHAN_BOND_SEQ_1_2 (10'b0001001010),
.CHAN_BOND_SEQ_1_3 (10'b0001001010),
.CHAN_BOND_SEQ_1_4 (10'b0110111100),
.CHAN_BOND_SEQ_1_ENABLE (4'b1111),
.CHAN_BOND_SEQ_2_1 (10'b0100111100),
.CHAN_BOND_SEQ_2_2 (10'b0100111100),
.CHAN_BOND_SEQ_2_3 (10'b0110111100),
.CHAN_BOND_SEQ_2_4 (10'b0100011100),
.CHAN_BOND_SEQ_2_CFG (5'b11111),
.CHAN_BOND_SEQ_2_ENABLE (4'b1111),
.CHAN_BOND_SEQ_2_USE ("FALSE"),
.CHAN_BOND_SEQ_LEN (1),
.PCI_EXPRESS_MODE ("TRUE"),
//-----------RX Attributes for PCI Express/SATA/
SAS----------
.SAS_MAX_COMSAS (52),
.SAS_MIN_COMSAS (40),
.SATA_BURST_VAL (3'b100),
.SATA_IDLE_VAL (3'b011),
.SATA_MAX_BURST (7),
.SATA_MAX_INIT (22),
.SATA_MAX_WAKE (7),
.SATA_MIN_BURST (4),
.SATA_MIN_INIT (12),
.SATA_MIN_WAKE (4),
.TRANS_TIME_FROM_P2 (12'h03c),
.TRANS_TIME_NON_P2 (8'h19),
.TRANS_TIME_RATE (8'h0e),
.TRANS_TIME_TO_P2 (10'h064)
)
gtxe1_i
(
//---------------------- Loopback and Powerdown Ports
----------------------
.LOOPBACK (tied_to_ground_vec_i[2:0]),
.RXPOWERDOWN (RXPOWERDOWN_IN),
.TXPOWERDOWN (TXPOWERDOWN_IN),
//------------ Receive Ports - 64b66b and 64b67b Gearbox Ports
-------------
.RXDATAVALID (),
.RXGEARBOXSLIP (tied_to_ground_i),
.RXHEADER (),
.RXHEADERVALID (),
.RXSTARTOFSEQ (),
//--------------------- Receive Ports - 8b10b Decoder
----------------------
.RXCHARISCOMMA (),
.RXCHARISK (RXCHARISK_OUT),
.RXDEC8B10BUSE (tied_to_vcc_i),
.RXDISPERR (RXDISPERR_OUT),
.RXNOTINTABLE (RXNOTINTABLE_OUT),
.RXRUNDISP (),
.USRCODEERR (tied_to_ground_i),
//----------------- Receive Ports - Channel Bonding Ports
------------------
.RXCHANBONDSEQ (),
.RXCHBONDI (tied_to_ground_vec_i[3:0]),
.RXCHBONDLEVEL (tied_to_ground_vec_i[2:0]),
.RXCHBONDMASTER (tied_to_ground_i),
.RXCHBONDO (),
.RXCHBONDSLAVE (tied_to_ground_i),
.RXENCHANSYNC (tied_to_ground_i),
//----------------- Receive Ports - Clock Correction Ports
-----------------
.RXCLKCORCNT (RXCLKCORCNT_OUT),
//------------- Receive Ports - Comma Detection and Alignment
--------------
.RXBYTEISALIGNED (RXBYTEISALIGNED_OUT),
.RXBYTEREALIGN (RXBYTEREALIGN_OUT),
.RXCOMMADET (RXCOMMADET_OUT),
.RXCOMMADETUSE (tied_to_vcc_i),
.RXENMCOMMAALIGN (RXENMCOMMAALIGN_IN),
.RXENPCOMMAALIGN (RXENPCOMMAALIGN_IN),
.RXSLIDE (tied_to_ground_i),
//--------------------- Receive Ports - PRBS Detection
---------------------
.PRBSCNTRESET (tied_to_ground_i),
.RXENPRBSTST (tied_to_ground_vec_i[2:0]),
.RXPRBSERR (),
//----------------- Receive Ports - RX Data Path interface
-----------------
.RXDATA (rxdata_i),
.RXRECCLK (),
.RXRECCLKPCS (),
.RXRESET (RXRESET_IN),
.RXUSRCLK (RXUSRCLK_IN),
.RXUSRCLK2 (RXUSRCLK2_IN),
//---------- Receive Ports - RX Decision Feedback Equalizer
(DFE) -----------
.DFECLKDLYADJ (tied_to_ground_vec_i[5:0]),
.DFECLKDLYADJMON (),
.DFEDLYOVRD (tied_to_vcc_i),
.DFEEYEDACMON (),
.DFESENSCAL (),
.DFETAP1 (tied_to_ground_vec_i[4:0]),
.DFETAP1MONITOR (),
.DFETAP2 (tied_to_ground_vec_i[4:0]),
.DFETAP2MONITOR (),
.DFETAP3 (tied_to_ground_vec_i[3:0]),
.DFETAP3MONITOR (),
.DFETAP4 (tied_to_ground_vec_i[3:0]),
.DFETAP4MONITOR (),
.DFETAPOVRD (tied_to_vcc_i),
//----- Receive Ports - RX Driver,OOB signalling,Coupling and
Eq.,CDR ------
.GATERXELECIDLE (tied_to_ground_i),
.IGNORESIGDET (tied_to_ground_i),
.RXCDRRESET (RXCDRRESET_IN),
.RXELECIDLE (RXELECIDLE_OUT),
.RXEQMIX (10'b0000000111),
.RXN (RXN_IN),
.RXP (RXP_IN),
//------ Receive Ports - RX Elastic Buffer and Phase Alignment
Ports -------
.RXBUFRESET (RXBUFRESET_IN),
.RXBUFSTATUS (RXBUFSTATUS_OUT),
.RXCHANISALIGNED (),
.RXCHANREALIGN (),
.RXDLYALIGNDISABLE (tied_to_vcc_i),
.RXDLYALIGNMONITOR (),
.RXDLYALIGNOVERRIDE (tied_to_ground_i),
.RXDLYALIGNRESET (tied_to_ground_i),
.RXDLYALIGNSWPPRECURB (tied_to_vcc_i),
.RXDLYALIGNUPDSW (tied_to_ground_i),
.RXENPMAPHASEALIGN (tied_to_ground_i),
.RXPMASETPHASE (tied_to_ground_i),
.RXSTATUS (RXSTATUS_OUT),
//------------- Receive Ports - RX Loss-of-sync State Machine
--------------
.RXLOSSOFSYNC (),
//-------------------- Receive Ports - RX Oversampling
---------------------
.RXENSAMPLEALIGN (tied_to_ground_i),
.RXOVERSAMPLEERR (),
//---------------------- Receive Ports - RX PLL Ports
----------------------
.GREFCLKRX (tied_to_ground_i),
.GTXRXRESET (GTXRXRESET_IN),
.MGTREFCLKRX (MGTREFCLKRX_IN),
.NORTHREFCLKRX (tied_to_ground_vec_i[1:0]),
.PERFCLKRX (tied_to_ground_i),
.PLLRXRESET (PLLRXRESET_IN),
.RXPLLLKDET (RXPLLLKDET_OUT),
.RXPLLLKDETEN (tied_to_vcc_i),
.RXPLLPOWERDOWN (tied_to_ground_i),
.RXPLLREFSELDY (tied_to_ground_vec_i[2:0]),
.RXRATE (RXRATE_IN),
.RXRATEDONE (RXRATEDONE_OUT),
.RXRESETDONE (RXRESETDONE_OUT),
.SOUTHREFCLKRX (tied_to_ground_vec_i[1:0]),
//------------ Receive Ports - RX Pipe Control for PCI Express
-------------
.PHYSTATUS (PHYSTATUS_OUT),
.RXVALID (RXVALID_OUT),
//--------------- Receive Ports - RX Polarity Control Ports
----------------
.RXPOLARITY (RXPOLARITY_IN),
//------------------- Receive Ports - RX Ports for SATA
--------------------
.COMINITDET (),
.COMSASDET (),
.COMWAKEDET (),
//----------- Shared Ports - Dynamic Reconfiguration Port
(DRP) ------------
.DADDR (tied_to_ground_vec_i[7:0]),
.DCLK (tied_to_ground_i),
.DEN (tied_to_ground_i),
.DI (tied_to_ground_vec_i[15:0]),
.DRDY (),
.DRPDO (),
.DWE (tied_to_ground_i),
//------------ Transmit Ports - 64b66b and 64b67b Gearbox
Ports ------------
.TXGEARBOXREADY (),
.TXHEADER (tied_to_ground_vec_i[2:0]),
.TXSEQUENCE (tied_to_ground_vec_i[6:0]),
.TXSTARTSEQ (tied_to_ground_i),
//-------------- Transmit Ports - 8b10b Encoder Control Ports
--------------
.TXBYPASS8B10B (tied_to_ground_vec_i[3:0]),
.TXCHARDISPMODE (tied_to_ground_vec_i[3:0]),
.TXCHARDISPVAL (tied_to_ground_vec_i[3:0]),
.TXCHARISK (TXCHARISK_IN),
.TXENC8B10BUSE (tied_to_vcc_i),
.TXKERR (),
.TXRUNDISP (),
//----------------------- Transmit Ports - GTX Ports
-----------------------
.GTXTEST (13'b1000000000000),
.MGTREFCLKFAB (),
.TSTCLK0 (tied_to_ground_i),
.TSTCLK1 (tied_to_ground_i),
.TSTIN (20'b11111111111111111111),
.TSTOUT (),
//---------------- Transmit Ports - TX Data Path interface
-----------------
.TXDATA (txdata_i),
.TXOUTCLK (TXOUTCLK_OUT),
.TXOUTCLKPCS (),
.TXRESET (TXRESET_IN),
.TXUSRCLK (TXUSRCLK_IN),
.TXUSRCLK2 (TXUSRCLK2_IN),
//-------------- Transmit Ports - TX Driver and OOB signaling
--------------
.TXBUFDIFFCTRL (3'b100),
.TXDIFFCTRL (4'b0000),
.TXINHIBIT (tied_to_ground_i),
.TXN (TXN_OUT),
.TXP (TXP_OUT),
.TXPOSTEMPHASIS (5'b00000),
//------------- Transmit Ports - TX Driver and OOB signalling
--------------
.TXPREEMPHASIS (4'b0000),
//--------- Transmit Ports - TX Elastic Buffer and Phase
Alignment ---------
.TXBUFSTATUS (),
//------ Transmit Ports - TX Elastic Buffer and Phase
Alignment Ports ------
.TXDLYALIGNDISABLE (tied_to_vcc_i),
.TXDLYALIGNMONITOR (),
.TXDLYALIGNOVERRIDE (tied_to_ground_i),
.TXDLYALIGNRESET (tied_to_ground_i),
.TXDLYALIGNUPDSW (tied_to_vcc_i),
.TXENPMAPHASEALIGN (tied_to_ground_i),
.TXPMASETPHASE (tied_to_ground_i),
//--------------------- Transmit Ports - TX PLL Ports
----------------------
.GREFCLKTX (tied_to_ground_i),
.GTXTXRESET (GTXTXRESET_IN),
.MGTREFCLKTX (MGTREFCLKTX_IN),
.NORTHREFCLKTX (tied_to_ground_vec_i[1:0]),
.PERFCLKTX (tied_to_ground_i),
.PLLTXRESET (PLLTXRESET_IN),
.SOUTHREFCLKTX (tied_to_ground_vec_i[1:0]),
.TXPLLLKDET (TXPLLLKDET_OUT),
.TXPLLLKDETEN (tied_to_vcc_i),
.TXPLLPOWERDOWN (tied_to_ground_i),
.TXPLLREFSELDY (tied_to_ground_vec_i[2:0]),
.TXRATE (TXRATE_IN),
.TXRATEDONE (TXRATEDONE_OUT),
.TXRESETDONE (TXRESETDONE_OUT),
//------------------- Transmit Ports - TX PRBS Generator
-------------------
.TXENPRBSTST (tied_to_ground_vec_i[2:0]),
.TXPRBSFORCEERR (tied_to_ground_i),
//------------------ Transmit Ports - TX Polarity Control
------------------
.TXPOLARITY (tied_to_ground_i),
//--------------- Transmit Ports - TX Ports for PCI Express
----------------
.TXDEEMPH (TXDEEMPH_IN),
.TXDETECTRX (TXDETECTRX_IN),
.TXELECIDLE (TXELECIDLE_IN),
.TXMARGIN (TXMARGIN_IN),
.TXPDOWNASYNCH (TXPDOWNASYNCH_IN),
.TXSWING (TXSWING_IN),
//------------------- Transmit Ports - TX Ports for SATA
-------------------
.COMFINISH (),
.TXCOMINIT (tied_to_ground_i),
.TXCOMSAS (tied_to_ground_i),
.TXCOMWAKE (tied_to_ground_i)
);
endmodule
Article: 142829On Aug 30, 1:38=A0am, "HT-Lab" <han...@ht-lab.com> wrote: > "Phil Jessop" <p...@noname.org> wrote in message > > news:wdKdneMv5MtIqAfXnZ2dnUVZ8kmdnZ2d@brightview.co.uk... > > > > > > > "Amit" <amit.ko...@gmail.com> wrote in message > >news:fd878c01-f12c-48d3-997e-7fe570fbc111@u38g2000pro.googlegroups.com..= . > > >> Hello group, > > >> I'm about to do some study and work on lower power FPGA but totally > >> new to this topic. I am told that this topic is an architecture base > >> concept (I'm not sure yet) but what matters to me now is just finding > >> a source and learning about it. > > >> Your help will be appreciated, > > >> Regards, > >> amit > > > look at z series > > >http://www.altera.com/products/devices/cpld/max2/overview/mx2-overvie... > > or > > http://www.actel.com/products/solutions/power/comparison.aspxhttp://www.s= iliconbluetech.com/ > > Hanswww.ht-lab.com Thank you! Regards, amitArticle: 142830
Hi David Brown,
> Are you able to post the function and its coefficients, or perhaps the
> original function that the polynomial approximates? =A0Where did the
> polynomial come from in the first place? =A0If it is an approximation mad=
e
> to fit existing data, then it would be better to use the raw data as the
> basis for your lookup table.
I post all coefficient:
a(0) =3D -0.01041564;
a(1) =3D 2.08313;
a(2) =3D -41.2012;
a(3) =3D 765.618;
a(4) =3D -7827.338;
a(5) =3D 46821.47;
a(6) =3D -167680.0;
a(7) =3D 358579.2;
a(8) =3D -428275.6;
a(9) =3D 223217.1;
Other sequence :
a(0) =3D 0.005544933;
a(1) =3D -0.4688876;
a(2) =3D 12.60572;
a(3) =3D -91.4666;
a(4) =3D 288.0148;
a(5) =3D -453.7018;
a(6) =3D 329.3296;
a(7) =3D -25.9895;
a(8) =3D -97.95346;
a(9) =3D 39.52787;
Kappa.
Article: 142831Hi Jonathan, > OK, so here's an example. =A0Suppose I have 5-bit input data, > and I want to calculate X^2. =A0But I don't have enough space > for a 32-entry lookup table. =A0So I split my 5-bit data > into 3+2 bits, and I use the upper 3 bits to index this > table, in which each entry contains two values - the > function of the index, and its first difference. The > first difference value is scaled by 4; we'll look at > that later. > > =A0 index =A0 function =A0 first difference scaled by /4 > =A0 =A0 0 =A0 =A0 0^2 =3D 0 =A0 =A0 ( 4^2 - =A00^2)/4 =3D =A04 > =A0 =A0 1 =A0 =A0 4^2 =3D 16 =A0 =A0( 8^2 - =A04^2)/4 =3D 12 > =A0 =A0 2 =A0 =A0 8^2 =3D 64 =A0 =A0(12^2 - =A08^2)/4 =3D 20 > =A0 =A0 3 =A0 =A012^2 =3D 144 =A0 (16^2 - 12^2)/4 =3D 28 > =A0 =A0 etc, etc, etc > > OK, now let's suppose I want to use this to compute > 11^2. =A0So I take the value 11 in 5-bit binary: 01011. > The top 3 bits are 010. =A0The lower 2 bits are 11. > Use the top 3 bits to look up in the table: > > =A0 function =3D 64, first difference =3D 20 > > Next, I take the lower 2 bits (11 binary) and multiply them > by the first difference (20), giving 60. =A0Now add together > the function value from the table, and the value I just > calculated: 64+60=3D124. =A0The correct answer is 121. =A0Not > a very large error. Thnaks very much for details ... it's more clear ... > So the transfer function will be fairly smooth, and therefore > an interpolation technique will probably be OK. > > What's more, as Andy said, it probably makes more sense to > describe the function as a lookup table rather than as > a polynomial. Certainly approach a table is easier to use. Thanks a lot. Kappa.Article: 142832
In article <93835a4b-0094-4faf-b11e-92f6ebf5a47b@r24g2000prf.googlegroups.com>, Weng Tianxiang <wtxwtx@gmail.com> wrote: >Hi Tom, >You are right. GF(2^233) and to ckeck its multiplications. Irreducible >polynomical can be anything. Really? I can't see why you would work in GF(2^233) except to do elliptic-curve cryptography, and in that case I thought the standards documents told you which irreducible polynomial to use. >What is the 'pari-gp' website address? 'pari-gp' problem is I don't >have Linix machine and related liberaries. >From the page http://pari.math.u-bordeaux.fr/download.html there is a link to http://pari.math.u-bordeaux.fr/pub/pari/windows/Pari-2-3-4.exe which is pari-gp compiled for Windows. >Recently I read the following paper: >FPGA DESIGNS OF PARALLEL HIGH PERFORMANCE GF(2^233) MULTIPLIERS >published in 2003, it claims that it was the fastest system in FPGA to >calculate GF(2^233) multiplications. I don't know enough about FPGAs to have a good idea of what has changed since 2003 that might make their algorithms less useful, so they're probably doing something sensible; quadrupling the LUT count to get from 11.1ns to 10.7ns clock rate seems a rather odd trade-off. If you don't know Karatsuba multiplication already, implementing the naive multiply and the Karatsuba multiply is probably a good start. Emmanuel Thome at LORIA is very interested in GF(2) multiplication, though generally of polynomials with degrees in the millions; there's a technique called Toom-Cook which is somewhat described in http://www.loria.fr/~thome/php/dl.php/publis/papers/mulgf2.pdf (it's basically Karatsuba but cutting the polynomials into three rather than two) but it might not be faster for degrees as small as 233. TomArticle: 142833
On Wed, 2 Sep 2009 15:25:01 -0700 (PDT), James Harris <james.harris.1@googlemail.com> wrote: >On 2 Sep, 15:34, Andy <jonesa...@comcast.net> wrote: > >... > >> But for starters, I would strongly recommend using an HDL like verilog >> or vhdl, and of those two, I recommend vhdl. Both are supported by the >> FPGA vendors' free design tools. > >Verilog is closer to C and may thus be a little easier for the OP to >learn. ..although as writing HDL is so different from programming, perhaps a _more_ different language would help reinforce the differences....Article: 142834
http://shop.trenz-electronic.de/catalog/product_info.php?products_id=631&osCsid=395233e427c820700bb8cbb3207e7c00 first S6 boards arrived today, so its finally there(here)! well well well the DIP modules from OHO are also orderable now! I had them reviewed in the brain a few month ago, nice to see them released and online http://shop.trenz-electronic.de/catalog/default.php Antti brain issue August is out too :) http://groups.google.com/group/antti-brain/files?hl=enArticle: 142835
Kappa wrote: > Hi David Brown, > >> Are you able to post the function and its coefficients, or perhaps the >> original function that the polynomial approximates? Where did the >> polynomial come from in the first place? If it is an approximation made >> to fit existing data, then it would be better to use the raw data as the >> basis for your lookup table. > > I post all coefficient: > > a(0) = -0.01041564; > a(1) = 2.08313; > a(2) = -41.2012; > a(3) = 765.618; > a(4) = -7827.338; > a(5) = 46821.47; > a(6) = -167680.0; > a(7) = 358579.2; > a(8) = -428275.6; > a(9) = 223217.1; > If you change the scale you use for x here, you will be able to reduce the range for the coefficients considerably. However, you are still going to need very wide ranges for your intermediate calculations, especially if x has a big range. Lookup tables are likely to be your best bet. > Other sequence : > > a(0) = 0.005544933; > a(1) = -0.4688876; > a(2) = 12.60572; > a(3) = -91.4666; > a(4) = 288.0148; > a(5) = -453.7018; > a(6) = 329.3296; > a(7) = -25.9895; > a(8) = -97.95346; > a(9) = 39.52787; >Article: 142836
>On Wed, 2 Sep 2009 15:25:01 -0700 (PDT), James Harris <james.harris.1@googlemail.com> wrote: > >>On 2 Sep, 15:34, Andy <jonesa...@comcast.net> wrote: >> >>... >> >>> But for starters, I would strongly recommend using an HDL like verilog >>> or vhdl, and of those two, I recommend vhdl. Both are supported by the >>> FPGA vendors' free design tools. >> >>Verilog is closer to C and may thus be a little easier for the OP to >>learn. > >..although as writing HDL is so different from programming, perhaps a _more_ different language >would help reinforce the differences.... > > Thank you all for the suggestions. --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.comArticle: 142837
Hi David Brown, > If you change the scale you use for x here, you will be able to reduce > the range for the coefficients considerably. However, you are still > going to need very wide ranges for your intermediate calculations, > especially if x has a big range. x can take up to 1.000. > Lookup tables are likely to be your best bet. in fact I'm gearing up to develop the system with "Lookup tables" Thanks for help. Kappa.Article: 142838
>Hello FPGA Gurus! >I have just bought Xilinx ML507 board in order to learn Xilinx FPGAs and ISE >tools. Latest experience with XC3130 FPGAs was 13 years ago, but those chips >and tools were very easy to use. >I was able to run all demos, I have downloaded all possible docs and >refernce designs from Xilinx site for ML505 and ML507 boards. However, all >these demos include precompiled .ACE and .BIT (some of them) files already, >and there is no source where I can start and learn from, otherwise the board >is of no use for me. >Can you help me and advise where I can get a source for a least HELLO WORLD >demo &!!! > >Many thanks, >Regards, >Pavel > > > Did you ever find any?Article: 142839
Hi all ! I need your help and assistance for the configuration of Multiple Microblaze on FSL link. Does anyone has any document regarding this problem? Or can anyone guide me using example how multiple microblaze are communicated on FSL link? Waiting for your help and assistance. Regards HussnainArticle: 142840
On Sep 3, 4:22=A0am, "ganeshstha" <ganesh_s...@hotmail.com> wrote: > >On Wed, 2 Sep 2009 15:25:01 -0700 (PDT), James Harris > <james.harri...@googlemail.com> wrote: > > >>On 2 Sep, 15:34, Andy <jonesa...@comcast.net> wrote: > > >>... > > >>> But for starters, I would strongly recommend using an HDL like > verilog > >>> or vhdl, and of those two, I recommend vhdl. Both are supported by > the > >>> FPGA vendors' free design tools. > > >>Verilog is closer to C and may thus be a little easier for the OP to > >>learn. > > >..although as writing HDL is so different from programming, perhaps a > > _more_ different language > > >would help reinforce the differences.... > > Thank you all for the suggestions. =A0 =A0 =A0 =A0 > > --------------------------------------- =A0 =A0 =A0 =A0 > This message was sent using the comp.arch.fpga web interface onhttp://www= .FPGARelated.com My personal opinion is for Verilog. It's a much tighter language. Maybe it's just bad luck, but I've seen lots of bad design and coding in VHDL, Verilog designs I've seen seem to be better quality. Maybe that's just a coincidence. BUT... the real issue is that designing for an FPGA is different from programming. The parallelism, timing issues, clock crossing, input/output timing, etc are flat out different concepts that most programmers don't appreciate. It's not the language that's the hurdle, it's all the h/w design practices that lead to problems. John ProvidenzaArticle: 142841
On Sep 2, 6:55=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > On Sep 2, 11:49=A0am, 2G <soar2mor...@yahoo.com> wrote: > > > > > > > On Sep 2, 11:10=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > On Wed, 2 Sep 2009 10:43:27 -0700 (PDT), 2G <soar2mor...@yahoo.com> > > > wrote: > > > > >I have a TI TLK2501 SERDES connected to a Virtex-5 on an ML507. The = V5 > > > >is loading the recovered clock signal with an apparent impedance of = 50 > > > >ohms (measured by the voltage drop across a series resistor). This i= s > > > >dropping the voltage swing of the signal in half. We have tried a > > > >different input pin with no change. We then added a buffer with no > > > >change. The ucf for that input is: > > > > >NET "RX_CLK" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25; > > > > >This is not happening to any of the other inputs from the SERDES. > > > > >Any ideas as to what is going on? > > > > Did you check the board schematics? This signal seems to be connected > > > to the CPLD also which might be causing the issue you see. > > > > -- > > > Muzaffer Kal > > > > DSPIA INC. > > > ASIC/FPGA Design Services > > > >http://www.dspia.com > > > Yes, we are aware of that. We previously used AJ32 and had the same > > problem. We used it because it was the only global clock input > > available (ISE kept complaining about using that input for a clock > > source). If need be, we can isolate the CPLD and LED from that line > > (we removed the LED and got no change). > > > We just tried rerouting that signal to the USER_CLK after removing the > > oscillator (X1). This greatly improved the signal quality, but > > requires a flying wire off of our mezzanine board to make the > > connection.- Hide quoted text - > > > - Show quoted text - > > How are you physically connecting the TLK2501 to the ML507? > > Ed McGettigan > -- > Xilinx Inc.- Hide quoted text - > > - Show quoted text - The TLK2501 is on a mezzanine board that interconnects thru the expansion headers (J4-7).Article: 142842
On Sep 2, 1:19=A0pm, austin <aus...@xilinx.com> wrote: > Well, > > Every input has to go from somewhere to get to where it needs to be, > and the pcb traces, and the FPGA package are 50 ohm transmission > lines. > > Once the signal gets to the IO pin, the receiver is ~ 8pF of > capacitance, with respect to ground. > > I have no idea what the drive capability of the driver is. > > Have you simulated the signal integrity using the driver chip IBIS > models, the trace lengths, and the termination chip IBIS models? > > I suspect that if you do that, you will see immediately that the ML507 > doesn't violate the rules of physics, and may provide you with some > insight why the signal amplitude is reduced. > > Austin I can do that, but why is this excessive loading appearing on just the clock input and none of the others? TomArticle: 142843
On Sep 3, 12:53=A0am, Thomas Womack <twom...@chiark.greenend.org.uk> wrote: > In article <93835a4b-0094-4faf-b11e-92f6ebf5a...@r24g2000prf.googlegroups= .com>, > Weng Tianxiang =A0<wtx...@gmail.com> wrote: > > >Hi Tom, > >You are right. GF(2^233) and to ckeck its multiplications. Irreducible > >polynomical can be anything. > > Really? =A0I can't see why you would work in GF(2^233) except to do > elliptic-curve cryptography, and in that case I thought the standards > documents told you which irreducible polynomial to use. > > >What is the 'pari-gp' website address? 'pari-gp' problem is I don't > >have Linix machine and related liberaries. > > From the pagehttp://pari.math.u-bordeaux.fr/download.html > there is a link tohttp://pari.math.u-bordeaux.fr/pub/pari/windows/Pari-2-= 3-4.exe > which is pari-gp compiled for Windows. > > >Recently I read the following paper: > >FPGA DESIGNS OF PARALLEL HIGH PERFORMANCE GF(2^233) MULTIPLIERS > >published in 2003, it claims that it was the fastest system in FPGA to > >calculate GF(2^233) multiplications. > > I don't know enough about FPGAs to have a good idea of what has > changed since 2003 that might make their algorithms less useful, so > they're probably doing something sensible; quadrupling the LUT count > to get from 11.1ns to 10.7ns clock rate seems a rather odd trade-off. > If you don't know Karatsuba multiplication already, implementing the > naive multiply and the Karatsuba multiply is probably a good start. > > Emmanuel Thome at LORIA is very interested in GF(2) multiplication, > though generally of polynomials with degrees in the millions; there's > a technique called Toom-Cook which is somewhat described in > > http://www.loria.fr/~thome/php/dl.php/publis/papers/mulgf2.pdf > > (it's basically Karatsuba but cutting the polynomials into three > rather than two) but it might not be faster for degrees as small as > 233. > > Tom Hi Tom, While doing some other circuit inventions for FPGA, I found my new circuits can do GF(2, m) very efficiently. For example, GF(2, 233), my circuit is expected to do it in 400-500 MHz with no more than 1K LUT6, including multiplication reduction, a big leap over 2003 paper. If m in GF(2, m) is within range of millions, that is great. The longer the m is, the better with my inventions. The reason I listed GF(2, 233) is the only paper I can find from Internet which has a real FPGA implementation. I am not interested in software algorithms to resolve the problem most efficiently, but in FPGA implementations which may expand FPGA applications into fields like Reed-Solomen encoding and decoding, cryptographic applications, digital signature authentication, public key applications, which FPGAs have no power to do it. I don't know if there are other applications in the direction. Thank you for your useful information. WengArticle: 142844
On Sep 3, 8:47=A0am, 2G <soar2mor...@yahoo.com> wrote: > On Sep 2, 6:55=A0pm, Ed McGettigan <ed.mcgetti...@xilinx.com> wrote: > > > > > > > On Sep 2, 11:49=A0am, 2G <soar2mor...@yahoo.com> wrote: > > > > On Sep 2, 11:10=A0am, Muzaffer Kal <k...@dspia.com> wrote: > > > > > On Wed, 2 Sep 2009 10:43:27 -0700 (PDT), 2G <soar2mor...@yahoo.com> > > > > wrote: > > > > > >I have a TI TLK2501 SERDES connected to a Virtex-5 on an ML507. Th= e V5 > > > > >is loading the recovered clock signal with an apparent impedance o= f 50 > > > > >ohms (measured by the voltage drop across a series resistor). This= is > > > > >dropping the voltage swing of the signal in half. We have tried a > > > > >different input pin with no change. We then added a buffer with no > > > > >change. The ucf for that input is: > > > > > >NET "RX_CLK" LOC =3D "G15" | IOSTANDARD =3D LVCMOS25; > > > > > >This is not happening to any of the other inputs from the SERDES. > > > > > >Any ideas as to what is going on? > > > > > Did you check the board schematics? This signal seems to be connect= ed > > > > to the CPLD also which might be causing the issue you see. > > > > > -- > > > > Muzaffer Kal > > > > > DSPIA INC. > > > > ASIC/FPGA Design Services > > > > >http://www.dspia.com > > > > Yes, we are aware of that. We previously used AJ32 and had the same > > > problem. We used it because it was the only global clock input > > > available (ISE kept complaining about using that input for a clock > > > source). If need be, we can isolate the CPLD and LED from that line > > > (we removed the LED and got no change). > > > > We just tried rerouting that signal to the USER_CLK after removing th= e > > > oscillator (X1). This greatly improved the signal quality, but > > > requires a flying wire off of our mezzanine board to make the > > > connection.- Hide quoted text - > > > > - Show quoted text - > > > How are you physically connecting the TLK2501 to the ML507? > > > Ed McGettigan > > -- > > Xilinx Inc.- Hide quoted text - > > > - Show quoted text - > > The TLK2501 is on a mezzanine board that interconnects thru the > expansion headers (J4-7).- Hide quoted text - > > - Show quoted text - Looking back at your posts you started out using AJ32, HDR1_46, and then switched to G15, GPIO_LED_2, and both of these have an issue with "dropping the voltage in half" for the RX_CLK output from the TLK2501. AJ32 is in Bank 13 and is connected to the VCCO_EXP supply and is not GC or CC clock input pin. Did you set the VCCO_EXP supply to 2.5V using the J20 jumpers? Is AK32, HDR1_48, used on the TLK2501 board? G15 is in Bank 1 is connected to VCC2V5 this is a GC clock input, but it is also connected to the input of the CPLD and the signal integrity will be reduced. Is G16, GPIO_LED_3 used on the TLK2501 board? Have you verified that the problem isn't on the TLK2501 board?Article: 142845
On Sep 2, 5:25=A0pm, James Harris <james.harri...@googlemail.com> wrote: > On 2 Sep, 15:34, Andy <jonesa...@comcast.net> wrote: > > ... > > > But for starters, I would strongly recommend using an HDL like verilog > > or vhdl, and of those two, I recommend vhdl. Both are supported by the > > FPGA vendors' free design tools. > > Verilog is closer to C and may thus be a little easier for the OP to > learn. > > It's probably been covered many times but as a beginner myself it > would be interesting to know why you recommend VHDL. Care to > elucidate? > > James (Other than my personal bias) : Given the differences between coding for SW and coding for HW, VHDL is better at keeping a new user from making some ignorant mistakes. A new designer with a SW background is more likely to make typical "SW" mistakes in a language that looks more like the SW he is used to. Sometimes keeping the syntax apart helps in this regard. On the other hand, if one's SW background is in ada, you could make exactly the same argument in favor of verilog ;^) That said, VHDL lets you use non-shared variables (blocking assignments) to get "SW-style" update semantics, without the potential for race conditions that verilog has, to create HW that will behave just like the code simulates (on a clock-cycle basis). With effort and skill obtained through experience, this can be accomplished in verilog too, but we're not talking about an experienced HW designer. If one's background in SW is more advanced (e.g. a seasoned SW engineer), then the applicable principles of good SW design (appropriate abstraction, information hiding, testing, etc.) are more easily applied in VHDL than in verilog. AndyArticle: 142846
On Sep 3, 8:58=A0am, Weng Tianxiang <wtx...@gmail.com> wrote: > On Sep 3, 12:53=A0am, Thomas Womack <twom...@chiark.greenend.org.uk> > wrote: > > > > > > > In article <93835a4b-0094-4faf-b11e-92f6ebf5a...@r24g2000prf.googlegrou= ps.com>, > > Weng Tianxiang =A0<wtx...@gmail.com> wrote: > > > >Hi Tom, > > >You are right. GF(2^233) and to ckeck its multiplications. Irreducible > > >polynomical can be anything. > > > Really? =A0I can't see why you would work in GF(2^233) except to do > > elliptic-curve cryptography, and in that case I thought the standards > > documents told you which irreducible polynomial to use. > > > >What is the 'pari-gp' website address? 'pari-gp' problem is I don't > > >have Linix machine and related liberaries. > > > From the pagehttp://pari.math.u-bordeaux.fr/download.html > > there is a link tohttp://pari.math.u-bordeaux.fr/pub/pari/windows/Pari-= 2-3-4.exe > > which is pari-gp compiled for Windows. > > > >Recently I read the following paper: > > >FPGA DESIGNS OF PARALLEL HIGH PERFORMANCE GF(2^233) MULTIPLIERS > > >published in 2003, it claims that it was the fastest system in FPGA to > > >calculate GF(2^233) multiplications. > > > I don't know enough about FPGAs to have a good idea of what has > > changed since 2003 that might make their algorithms less useful, so > > they're probably doing something sensible; quadrupling the LUT count > > to get from 11.1ns to 10.7ns clock rate seems a rather odd trade-off. > > If you don't know Karatsuba multiplication already, implementing the > > naive multiply and the Karatsuba multiply is probably a good start. > > > Emmanuel Thome at LORIA is very interested in GF(2) multiplication, > > though generally of polynomials with degrees in the millions; there's > > a technique called Toom-Cook which is somewhat described in > > >http://www.loria.fr/~thome/php/dl.php/publis/papers/mulgf2.pdf > > > (it's basically Karatsuba but cutting the polynomials into three > > rather than two) but it might not be faster for degrees as small as > > 233. > > > Tom > > Hi Tom, > While doing some other circuit inventions for FPGA, I found my new > circuits can do GF(2, m) very efficiently. > > For example, GF(2, 233), my circuit is expected to do it in 400-500 > MHz with no more than 1K LUT6, including multiplication reduction, a > big leap over 2003 paper. > > If m in GF(2, m) is within range of millions, that is great. The > longer the m is, the better with my inventions. > > The reason I listed GF(2, 233) is the only paper I can find from > Internet which has a real FPGA implementation. > > I am not interested in software algorithms to resolve the problem most > efficiently, but in FPGA implementations which may expand FPGA > applications into fields like > Reed-Solomen encoding and decoding, cryptographic applications, > digital signature authentication, public key applications, which FPGAs > have no power to do it. > > I don't know if there are other applications in the direction. > > Thank you for your useful information. > > Weng- Hide quoted text - > > - Show quoted text - Hi Tom, I have difficulty using pari-gp system. I printed all 49 pages of pari-gp tutorial and still couldn't find what I want. Please let me know how to do the following functions: 1. Set FG(2, m) module with m parameter in hex in FG(2, m); 2. Set irreducible polynominal with data in hexdecimal; 3. Set p1 =3D xxxxxxxx, 233 bits with data in hexdecimal; 4. Set p2 =3D yyyyyyyy, 233 bits with data in hexdecimal; 5. Get p =3D p1*p2, 233 bits with data in hexdecimal. Thank you. WengArticle: 142847
Andy <jonesandy@comcast.net> writes: > for SW and coding for HW, VHDL is better at keeping a new user from > making some ignorant mistakes. A new designer with a SW background is So you would never recommend VHDL to an Ada programmer would you? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 142848
Andy <jonesandy@comcast.net> wrote: (snip on verilog and VHDL) < (Other than my personal bias) : Given the differences between coding < for SW and coding for HW, VHDL is better at keeping a new user from < making some ignorant mistakes. A new designer with a SW background is < more likely to make typical "SW" mistakes in a language that looks < more like the SW he is used to. Sometimes keeping the syntax apart < helps in this regard. On the other hand, if one's SW background is in < ada, you could make exactly the same argument in favor of verilog ;^) I don't agree, but I believe it could be personal preference. For one, I did some logic design with TTL gates before learning verilog, so I know how to think in terms of logic. Verilog isn't really that much like C. There are people using C as an HDL, and I completely agree that is a bad idea. < That said, VHDL lets you use non-shared variables (blocking < assignments) to get "SW-style" update semantics, without the potential < for race conditions that verilog has, to create HW that will behave < just like the code simulates (on a clock-cycle basis). With effort and < skill obtained through experience, this can be accomplished in verilog < too, but we're not talking about an experienced HW designer. Oh, also, my verilog uses very little behavioral mode, one big exception being flip-flops. Also case blocks for state machines. < If one's background in SW is more advanced (e.g. a seasoned SW < engineer), then the applicable principles of good SW design < (appropriate abstraction, information hiding, testing, etc.) are more < easily applied in VHDL than in verilog. Maybe. But then again, C wasn't my first language. I can think in a variety of software languages, ADA not being one. -- glenArticle: 142849
Mark McDougall wrote: > Johnson wrote: > >> Could anybody please show me a list of popular FPGA development >> IDE/toolchains and their approximate costs? > > Your choice of silicon more-or-less dictates the development tools you'll > be using. Yes, there are 3rd party synthesis tools but for "entry level > development" you're most likely looking at standard silicon vendor packages. > > As for choosing silicon, unless you have an application that can take > advantage of a specific feature, the decision is to some degree a > "religious" one. Sometimes the choice is even based on the development > tools rather than the actual silicon. > > So your questions are, to a large degree, "not applicable". For > entry-level, mainstream development you choose your silicon and you're > stuck with the vendor tools as supplied. > > Regards, > Good and thanks. So what is the most "religious" FPGA silicon for now? I guess Zarlink, right? And what is the most popular development tools of Zarlink products to entry-level developers?
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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