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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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 93625

Article: 93625
Subject: Re: Patents and (possible) Plagiarism, Anyone ever been in a similar situation?
From: mr_reznat@yahoo.com
Date: 26 Dec 2005 18:55:09 -0800
Links: << >>  << T >>  << A >>
U.S. patent law is complex.  Simply referring to the U.S. system as
"first to invent" rather than "first to file" probably adds
more confusion than elucidation to the discussion.

Assuming that a U.S. patent application satisfies all the other
requirements for a patent, section 102 of the patent code states that a
"person shall be entitled to a patent unless ...." Section 102 has
six subsections, each giving a different reason that a person should
NOT get a patent.  Subsections (a), (b), (f) and (g) are most relevant
to this discussion.

102(a) blocks the applicant from getting a patent if the invention was
publicly known* before the applicant invented it.  So if I invented
something on July 7, 2003, any publication, public use, etc. before
July 7, 2003 should stop me from getting a patent.  Note that since I
didn't develop the invention before July 7, 2003, there is no way I
could have publicly disclosed the invention before July 7, 2003.  So
there is nothing the inventor can do that will block there patent based
on 102(a).

102(b) focuses on the date of the patent application** rather than the
date of invention.  If my invention was publicly known* more than one
year before I applied for the patent, then I should not get a patent.
So if I applied for a patent on September 1, 2005, but anyone -
including me - publicly disclosed the invention before September 1,
2004, that should block my patent application.

102(f) is easy: "he did not himself invent the subject matter sought
to be patented"

102(g) relates to the situation where two different people apply for a
patent on the same subject matter; in certain situations an
"interference" proceeding may be held.  In the interference the
person that first applied** for the patent is generally assumed to be
the first inventor and entitled to the patent.  But if the second
person that applied for a patent can prove that he invented first and
meets certain other requirements, the second applicant may get the
patent rather than the first applicant.

   * publicly known - is defined somewhat differently for (a) and
(b).
   ** application date is the earlier of the actual application date or
the date of the U.S. priority application.  A provisional application
may provide a priority date; but a document disclosure does not.

I hope this clarified more than it confused


Richard Tanzer
Patent Agent


Article: 93626
Subject: Re: Looking for 64 bit IEEE802.3 Verilog code or tips for code
From: Philip Freidin <philip@fliptronics.com>
Date: Tue, 27 Dec 2005 03:25:16 GMT
Links: << >>  << T >>  << A >>

Maybe the foillowing from the archive will help:

   http://www.fpga-faq.org/archives/90900.html#90901

Philip Freidin

On 25 Dec 2005 15:47:52 -0800, "Vik" <vdevdas@yahoo.com> wrote:
>Hi
>I am looking for verilog code for a 64 bit wide datapath.
>I used the function generated by EASICS but did not
>get the correct results.
>
>If someone could post the code on how to use the
>EASICS function or give me the psedo code or just the steps I need to
>perform
>to make it work, I would really appreciate it.
>
>I would also appreciate a sample good packet with the correct CRC
>appended to it for verifying the code.
>
>thanks 
>
>Vikram

Philip Freidin
Fliptronics

Article: 93627
Subject: Re: Xilinx V4 LVDS
From: "avishay" <avishorp@yahoo.com>
Date: 26 Dec 2005 22:15:59 -0800
Links: << >>  << T >>  << A >>
Hi Brad
Are you sure you're decoding Camera Link correctly? Both Channel Link
and Camera Link mangle the bit order on the stream, so make sure you'r
looking at the correct bit.

Avishay

Brad Smallridge wrote:
> Hello,
>
> Having trouble with some LVDS signals coming from a Camera Link interface.
> I expect to see from steady signals coming from this line camera. DVAL=1.
> But it's not there. And the LVAL, line valid, only comes on for maybe one
> clock, and I expect it to come on for 2K clocks.
>
> I am using IBUFDS as inputs.  The UCF file loc the pins but that is all. Do
> I need something more to drop the 100 ohm termination resitance?
> 
> Brad Smallridge
> aivision.com


Article: 93628
Subject: Re: XILINX I2C controller core in FPGA and multisource problem.
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 27 Dec 2005 07:27:51 +0100
Links: << >>  << T >>  << A >>
<wtxwtx@gmail.com> schrieb im Newsbeitrag 
news:1135640060.426695.311280@g44g2000cwa.googlegroups.com...
> Hi Antti,
> I don't have his source code and made a judgement based on the
> following warnings:
> Unit i2c_tb: 8 multi-source signals are replaced by
> logic (pull-up yes): data_bus<0>, data_bus<1>, data_bus<2>,
> data_bus<3>, data_bus<4>, data_bus<5>, data_bus<6>, data_bus<7>.
>
> 1. data_bus are multi-source signals;
> 2. data_bus is in the module: i2c_tb. It may be in his test bench code
> to make the multi-source error.
>
> I never claimed that it was the IP code error. Any IP code never makes
> such basic and fundamental error.
>
> Weng
>
no problems - I just checked the original - form without doing that your 
guess was 'close'

antti 



Article: 93629
Subject: Re: Xilinx V4 LVDS
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Mon, 26 Dec 2005 23:50:55 -0800
Links: << >>  << T >>  << A >>
Hi Rob,

Thanks for the moral support.

There is a jumper to make these bank 7 inputs 2.5V instead of 3.3V which I 
switched. No effect.

I ran the inputs into a second camera jack available on my daughter board, 
to see if I had some solder problems on the first jack. That resulted in the 
same issues.

My scope is old so I am just looking at the tiniest wiggles but again they 
seem to be OK. In fact I can see the LVAL in the original signal making it 
wiggle higher than the rest of the signal.

Are you using IDELAY to control the timing?

Brad


"Rob" <robnstef@frontiernet.net> wrote in message 
news:1Y_rf.430$qg.31@news02.roc.ny...
>I know on Altera parts you have to tell the tool to turn on the on-chip 
>termination resistors: it may be the same with Xilinx.  Also, I know on 
>V2PRO parts the banks running differenital I/O must be operated with a 2.5V 
>VCCIO.
>
> Also, I would look at the inputs at the connector to make sure that they 
> are acting as expected.  If you don't have a differential probe you can 
> get a reasonable look with a single ended one.  This is just to make sure 
> that you're not chasing the wrong problem.
>
> I've done many designs with Camera Link so let me know if you need 
> anything else.
>
> Let us know what you find.
>
>
> "Brad Smallridge" <bradsmallridge@dslextreme.com> wrote in message 
> news:11r0jedsghr3me0@corp.supernews.com...
>> Hello,
>>
>> Having trouble with some LVDS signals coming from a Camera Link 
>> interface. I expect to see from steady signals coming from this line 
>> camera. DVAL=1. But it's not there. And the LVAL, line valid, only comes 
>> on for maybe one clock, and I expect it to come on for 2K clocks.
>>
>> I am using IBUFDS as inputs.  The UCF file loc the pins but that is all. 
>> Do I need something more to drop the 100 ohm termination resitance?
>>
>> Brad Smallridge
>> aivision.com
>>
>>
>>
>>
>
> 



Article: 93630
Subject: Re: Xilinx V4 LVDS
From: "Brad Smallridge" <bradsmallridge@dslextreme.com>
Date: Tue, 27 Dec 2005 00:53:14 -0800
Links: << >>  << T >>  << A >>
"avishay" <avishorp@yahoo.com> wrote in message 
news:1135664159.180738.57490@g44g2000cwa.googlegroups.com...
> Hi Brad
> Are you sure you're decoding Camera Link correctly? Both Channel Link
> and Camera Link mangle the bit order on the stream, so make sure you'r
> looking at the correct bit.
>
> Avishay

I hope so. I have a counter and a mux routing all the signals in turn to an 
LED that I scope. There is nothing that indicates to me that a DVAL=1 or an 
LVAL exist on the X2 stream.  I have checked the operation of the camera 
with another board that has National LVDS chips and the camera seems to be 
operating OK in base configuration, 12 bit, one tap mode.

Channel X0
Bit 0   ChanLink   0     CamLink 0
Bit 1   ChanLink   1     CamLink 1
Bit 2   ChanLink   2     CamLink 2
Bit 3   ChanLink   3     CamLink 3
Bit 4   ChanLink   4     CamLink 4
Bit 5   ChanLink   6     CamLink 5
Bit 6   ChanLink   7     CamLink 8

Channel X1
Bit 0   ChanLink    8    CamLink 9
Bit 1   ChanLink    9    CamLink 10
Bit 2   ChanLink  12    CamLink 11
Bit 3   ChanLink  13
Bit 4   ChanLink  14
Bit 5   ChanLink  15
Bit 6   ChanLink  18

Channel X2
Bit 0   ChanLink  19
Bit 1   ChanLink  20
Bit 2   ChanLink  21
Bit 3   ChanLink  22
Bit 4   ChanLink  24    CamLink LVAL
Bit 5   ChanLink  25
Bit 6   ChanLink  26    CamLink DVAL

Channel X3
Bit 0   ChanLink  27  CamLink 6
Bit 1   ChanLink   5   CamLink 7
Bit 2   ChanLink  10
Bit 3   ChanLink  11
Bit 4   ChanLink  16
Bit 5   ChanLink  17
Bit 6   ChanLink  23

By adding about 50 delay taps to the 140_280 dcm and 4 clock cycles to the 
xclk clkdiv signal, I have been able to get a video looking signal, 
simultaneously, into all the camlink data positions, except the DVAL and 
LVAL.  I must admit however that the first and second bits look very similar 
on the scope as if they were the same value.   All the unmarked signals are 
zero.

I have put some of the code below.  This is work in progress because I have 
begun to play around by fixed IDELAY to the X0 ISERDES. I don't know what is 
better, to delay the signals coming into the ISERDESs or delay the clkdiv 
strobe.


 reset1  <= not sys_rst_in;

 cam1_dcmfx: cam1_40_140
 port map(
  clkin_n_in   => cam1_in(6),  -- 40 MHz
  clkin_p_in   => cam1_in(7),  -- Differential pair
  rst_in       => reset1,
  clkfx_out    => cam1_clk7xdiv2,  -- 140MHz
  clkin_ibufgds_out  => open,
  clk0_out     => cam1_xclk_0, -- 40 MHz
  locked_out   => cam1_lock7xdiv2 );

 reset_delay_SRL16 : SRL16
 generic map (
  INIT => X"0000")
 port map (
  Q   => reset2,
  A0  => '1', -- 16 clock delays
  A1  => '1',
  A2  => '1',
  A3  => '1',
  CLK => cam1_clk7xdiv2,
  D   => cam1_lock7xdiv2 );

 reset3 <= not( cam1_lock7xdiv2 and reset2 );

 -- added 20 units of phase delay
 cam1_dcm2x: cam1_140_280
 port map(
   clkin_in   => cam1_clk7xdiv2, -- 140 MHz
   rst_in     => reset3, -- from SRL16
   clk0_out   => open,
   clk2x_out  => cam1_clk7x, -- 280 MHz
   locked_out => cam1_lock7x );

 xclk_delay_process: process(cam1_clk7x)
 begin
 if( cam1_clk7x'event and cam1_clk7x='1' ) then
   cam1_xclk_1 <= cam1_xclk_0;
   cam1_xclk_2 <= cam1_xclk_1;
   cam1_xclk_3 <= cam1_xclk_2;
   cam1_xclk_4 <= cam1_xclk_3;
   end if;
 end process;

 xclk_bufg: BUFG
 port map(
   O => cam1_xclk,
   I => cam1_xclk_4 );

   IDELAYCTRL_inst : IDELAYCTRL
   port map (
      RDY => open,       -- 1-bit output indicates validity of the REFCLK
      REFCLK => cam1_clk7x, -- 1-bit reference clock input
      RST => reset3   );     -- 1-bit reset input

 --------------------------------------------------------------------------
 -- Camera Link Deserializers
 --
 -- Each of the four serial streams X0 X1 X2 and X3
 -- have a pair of differential inputs _n and _p
 -- attached to the gpio_exp_hdr2 (General Purpose Input Output Header 2 )
 -- that must be reconciled with an IBUFDS (Input BUFfer Differential Swing)
 -- The resulting signal is fed to a pair of Master and Slave
 -- ISERDES (Input SERializer DESerializer).


   cam1_x0_ibufd_inst : IBUFDS
 port map (
   O  => cam1_x0,
   I  => cam1_in(1),
   IB => cam1_in(0) );

   x0_iserdes_master : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- DDR SDR
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
--      IOBDELAY       => "NONE",    -- delay chain 
"NONE","IBUF","IFD","BOTH"
--      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
--      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      IOBDELAY       => "BOTH",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "FIXED", -- tap delay "DEFAULT", "FIXED","VARIABLE"
      IOBDELAY_VALUE =>  61,        -- initial tap delay 0 to 63
      NUM_CE         =>  1,        -- clock enables 1,2
      SERDES_MODE    => "MASTER",  -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => cam1_x0_bit(0),
      Q2        => cam1_x0_bit(1),
      Q3        => cam1_x0_bit(2),
      Q4        => cam1_x0_bit(3),
      Q5        => cam1_x0_bit(4),
      Q6        => cam1_x0_bit(5),
      SHIFTOUT1 => cam1_x0_shift1,
      SHIFTOUT2 => cam1_x0_shift2,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => cam1_x0,
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => '0',
      SHIFTIN2  => '0',
      SR        => reset3 );

   x0_iserdes_slave : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- "DDR" "SDR"
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
--      IOBDELAY       => "NONE",    -- delay chain 
"NONE","IBUF","IFD","BOTH"
--      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
--      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      IOBDELAY       => "BOTH",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "FIXED", -- tap delay "DEFAULT", "FIXED","VARIABLE"
      IOBDELAY_VALUE =>  61,        -- initial tap delay 0 to 63
      NUM_CE         =>  2,        -- clock enables 1,2
      SERDES_MODE    => "SLAVE",   -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => open,
      Q2        => open,
      Q3        => cam1_x0_bit(6),
      Q4        => open,
      Q5        => open,
      Q6        => open,
      SHIFTOUT1 => open,
      SHIFTOUT2 => open,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => '0',
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => cam1_x0_shift1,
      SHIFTIN2  => cam1_x0_shift2,
      SR        => reset3 );

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

   cam1_x1_ibufd_inst : IBUFDS
 port map (
   O  => cam1_x1,
   I  => cam1_in(3),
   IB => cam1_in(2) );

   x1_iserdes_master : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- DDR SDR
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "NONE",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      NUM_CE         =>  1,        -- clock enables 1,2
      SERDES_MODE    => "MASTER",  -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => cam1_x1_bit(0),
      Q2        => cam1_x1_bit(1),
      Q3        => cam1_x1_bit(2),
      Q4        => cam1_x1_bit(3),
      Q5        => cam1_x1_bit(4),
      Q6        => cam1_x1_bit(5),
      SHIFTOUT1 => cam1_x1_shift1,
      SHIFTOUT2 => cam1_x1_shift2,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => cam1_x1,
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => '0',
      SHIFTIN2  => '0',
      SR        => reset3 );

   x1_iserdes_slave : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- "DDR" "SDR"
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "NONE",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      NUM_CE         =>  2,        -- clock enables 1,2
      SERDES_MODE    => "SLAVE",   -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => open,
      Q2        => open,
      Q3        => cam1_x1_bit(6),
      Q4        => open,
      Q5        => open,
      Q6        => open,
      SHIFTOUT1 => open,
      SHIFTOUT2 => open,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => '0',
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => cam1_x1_shift1,
      SHIFTIN2  => cam1_x1_shift2,
      SR        => reset3 );


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

   cam1_x2_ibufd_inst : IBUFDS
 port map (
   O  => cam1_x2,
   I  => cam1_in(5),
   IB => cam1_in(4) );

   x2_iserdes_master : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- DDR SDR
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "NONE",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      NUM_CE         =>  1,        -- clock enables 1,2
      SERDES_MODE    => "MASTER",  -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => cam1_x2_bit(0),
      Q2        => cam1_x2_bit(1),
      Q3        => cam1_x2_bit(2),
      Q4        => cam1_x2_bit(3),
      Q5        => cam1_x2_bit(4),
      Q6        => cam1_x2_bit(5),
      SHIFTOUT1 => cam1_x2_shift1,
      SHIFTOUT2 => cam1_x2_shift2,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => cam1_x2,
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => '0',
      SHIFTIN2  => '0',
      SR        => reset3 );

   x2_iserdes_slave : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- "DDR" "SDR"
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "NONE",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      NUM_CE         =>  2,        -- clock enables 1,2
      SERDES_MODE    => "SLAVE",   -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => open,
      Q2        => open,
      Q3        => cam1_x2_bit(6),
      Q4        => open,
      Q5        => open,
      Q6        => open,
      SHIFTOUT1 => open,
      SHIFTOUT2 => open,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => '0',
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => cam1_x2_shift1,
      SHIFTIN2  => cam1_x2_shift2,
      SR        => reset3 );

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

   cam1_x3_ibufd_inst : IBUFDS
 port map (
   O  => cam1_x3,
   I  => cam1_in(9),
   IB => cam1_in(8) );

   x3_iserdes_master : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- DDR SDR
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
    IOBDELAY       => "NONE",    -- delay chain "NONE","IBUF","IFD","BOTH"
    IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", "FIXED","VARIABLE"
    IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      NUM_CE         =>  1,        -- clock enables 1,2
      SERDES_MODE    => "MASTER",  -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => cam1_x3_bit(0),
      Q2        => cam1_x3_bit(1),
      Q3        => cam1_x3_bit(2),
      Q4        => cam1_x3_bit(3),
      Q5        => cam1_x3_bit(4),
      Q6        => cam1_x3_bit(5),
      SHIFTOUT1 => cam1_x3_shift1,
      SHIFTOUT2 => cam1_x3_shift2,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => cam1_x3,
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => '0',
      SHIFTIN2  => '0',
      SR        => reset3 );

   x3_iserdes_slave : ISERDES
   generic map (
      BITSLIP_ENABLE => FALSE,   -- TRUE FALSE
      DATA_RATE      => "SDR",   -- "DDR" "SDR"
      DATA_WIDTH     =>  7,      -- DDR 4,6,8,10  SDR 2,3,4,5,6,7,8
      INIT_Q1        => '0',
      INIT_Q2        => '0',
      INIT_Q3        => '0',
      INIT_Q4        => '0',
      INTERFACE_TYPE => "MEMORY",  -- model - "MEMORY" or "NETWORKING"
      IOBDELAY       => "NONE",    -- delay chain "NONE","IBUF","IFD","BOTH"
      IOBDELAY_TYPE  => "DEFAULT", -- tap delay "DEFAULT", 
"FIXED","VARIABLE"
      IOBDELAY_VALUE =>  0,        -- initial tap delay 0 to 63
      NUM_CE         =>  2,        -- clock enables 1,2
      SERDES_MODE    => "SLAVE",   -- "MASTER" or "SLAVE"
      SRVAL_Q1       => '0',
      SRVAL_Q2       => '0',
      SRVAL_Q3       => '0',
      SRVAL_Q4       => '0')
   port map (
      O         => open,
      Q1        => open,
      Q2        => open,
      Q3        => cam1_x3_bit(6),
      Q4        => open,
      Q5        => open,
      Q6        => open,
      SHIFTOUT1 => open,
      SHIFTOUT2 => open,
      BITSLIP   => '0',
      CE1       => '1',
      CE2       => '1',
      CLK       => cam1_clk7x,
      CLKDIV    => cam1_xclk,
      D         => '0',
      DLYCE     => '0',
      DLYINC    => '0',
      DLYRST    => '0',
      OCLK      => cam1_clk7x,
      REV       => '0',
      SHIFTIN1  => cam1_x3_shift1,
      SHIFTIN2  => cam1_x3_shift2,
      SR        => reset3 );

   cam1_bit( 0)  <= cam1_x0_bit(0);
   cam1_bit( 1)  <= cam1_x0_bit(1);
   cam1_bit( 2)  <= cam1_x0_bit(2);
   cam1_bit( 3)  <= cam1_x0_bit(3);
   cam1_bit( 4)  <= cam1_x0_bit(4);
   cam1_bit( 5)  <= cam1_x0_bit(5);
   cam1_bit( 6)  <= cam1_x0_bit(6);

   cam1_bit( 7)  <= cam1_x1_bit(0);
   cam1_bit( 8)  <= cam1_x1_bit(1);
   cam1_bit( 9)  <= cam1_x1_bit(2);
   cam1_bit(10)  <= cam1_x1_bit(3);
   cam1_bit(11)  <= cam1_x1_bit(4);
   cam1_bit(12)  <= cam1_x1_bit(5);
   cam1_bit(13)  <= cam1_x1_bit(6);

   cam1_bit(14)  <= cam1_x2_bit(0);
   cam1_bit(15)  <= cam1_x2_bit(1);
   cam1_bit(16)  <= cam1_x2_bit(2);
   cam1_bit(17)  <= cam1_x2_bit(3);
   cam1_bit(18)  <= cam1_x2_bit(4);
   cam1_bit(19)  <= cam1_x2_bit(5);
   cam1_bit(20)  <= cam1_x2_bit(6);

   cam1_bit(21)  <= cam1_x3_bit(0);
   cam1_bit(22)  <= cam1_x3_bit(1);
   cam1_bit(23)  <= cam1_x3_bit(2);
   cam1_bit(24)  <= cam1_x3_bit(3);
   cam1_bit(25)  <= cam1_x3_bit(4);
   cam1_bit(26)  <= cam1_x3_bit(5);
   cam1_bit(27)  <= cam1_x3_bit(6);


   -- Cameral Link is a special subset of the 28 lines above


 led_test_counter_3_process:process(cam1_xclk)
 begin
 if( cam1_xclk'event and cam1_xclk='1') then
   if( reset3='1' ) then
     test_counter_3 <= (others=>'0');
     test_counter_4 <= (others=>'0');
   elsif( test_counter_3 = (test_counter_3'range => '1')  ) then
     test_counter_3 <= (others=>'0');
   test_counter_4 <= test_counter_4+1;
   else
     test_counter_3 <= test_counter_3+1;
   end if;
 end if;
 end process;

 led_test0_process:process(cam1_xclk)
 begin
 if( cam1_xclk'event and cam1_xclk='1') then
   if( reset3='1' ) then
     gpio(0)<='0';
   else
     gpio(0)<=test_counter_4( 6);
   end if;
 end if;
 end process;

 led_test_counter_5_process:process(cam1_xclk)
 begin
 if( cam1_xclk'event and cam1_xclk='1') then
   if( (test_counter_4(6)='1') and test_5='0' ) then
     test_counter_5<= test_counter_5 +1;
   elsif( test_counter_5 = 28 ) then
     test_counter_5<= (others=>'0');
   end if;
   test_5 <= test_counter_4(6);
 end if;
 end process;

 led1_out_process:process(test_counter_5)
 begin
 case test_counter_5 is
   when "000000" => gpio(1) <= cam1_bit( 0);
   when "000001" => gpio(1) <= cam1_bit( 1);
   when "000010" => gpio(1) <= cam1_bit( 2);
   when "000011" => gpio(1) <= cam1_bit( 3);
   when "000100" => gpio(1) <= cam1_bit( 4);
   when "000101" => gpio(1) <= cam1_bit( 5);
   when "000110" => gpio(1) <= cam1_bit( 6);
   when "000111" => gpio(1) <= cam1_bit( 7);
   when "001000" => gpio(1) <= cam1_bit( 8);
   when "001001" => gpio(1) <= cam1_bit( 9);
   when "001010" => gpio(1) <= cam1_bit(10);
   when "001011" => gpio(1) <= cam1_bit(11);
   when "001100" => gpio(1) <= cam1_bit(12);
   when "001101" => gpio(1) <= cam1_bit(13);
   when "001110" => gpio(1) <= cam1_bit(14);
   when "001111" => gpio(1) <= cam1_bit(15);
   when "010000" => gpio(1) <= cam1_bit(16);
   when "010001" => gpio(1) <= cam1_bit(17);
   when "010010" => gpio(1) <= cam1_bit(18);
   when "010011" => gpio(1) <= cam1_bit(19);
   when "010100" => gpio(1) <= cam1_bit(20);
   when "010101" => gpio(1) <= cam1_bit(21);
   when "010110" => gpio(1) <= cam1_bit(22);
   when "010111" => gpio(1) <= cam1_bit(23);
   when "011000" => gpio(1) <= cam1_bit(24);
   when "011001" => gpio(1) <= cam1_bit(25);
   when "011010" => gpio(1) <= cam1_bit(26);
   when "011011" => gpio(1) <= cam1_bit(27);
   when others => gpio(1) <= '1';
 end case;
 end process;

 gpio(2) <= cam1_bit(0);
 gpio(3) <= cam1_bit(1);


> Brad Smallridge wrote:
>> Hello,
>>
>> Having trouble with some LVDS signals coming from a Camera Link 
>> interface.
>> I expect to see from steady signals coming from this line camera. DVAL=1.
>> But it's not there. And the LVAL, line valid, only comes on for maybe one
>> clock, and I expect it to come on for 2K clocks.
>>
>> I am using IBUFDS as inputs.  The UCF file loc the pins but that is all. 
>> Do
>> I need something more to drop the 100 ohm termination resitance?
>>
>> Brad Smallridge
>> aivision.com
> 



Article: 93631
Subject: Microblaze in a EDK pcore
From: =?ISO-8859-1?Q?C=E9dric_Jeanneret?= <cedric.jeanneret@epfl.ch>
Date: Tue, 27 Dec 2005 10:50:51 +0100
Links: << >>  << T >>  << A >>
Well,

I've a XPS project with a MicroBlaze and BRAMs on the hardware side, and
a C program on the software side. I'm able to synthesize it (with
synplify for example), and put this submodule as netlist in a EDK pcore.

Then I can use it as "peripheral" for another XPS project, which
describes my complete system (with PPC and so...).

But I've a problem. How to initialize Microblaze's BRAM without
generating the bitstream of my submodule ?

I've seen a commercial Core with a microblaze inside. They give the
memory .bmm with it, to be able to update the software. I've tried to 
"init_bram" after the bitstream generation from the main xps project. 
But it seems that this bmm file, without the "par" informations is useless.

Thanks in advance.

Best regards.



Article: 93632
Subject: Re: Microblaze in a EDK pcore
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 27 Dec 2005 10:52:50 +0100
Links: << >>  << T >>  << A >>
"CÚdric Jeanneret" <cedric.jeanneret@epfl.ch> schrieb im Newsbeitrag 
news:43b10e7c$1@epflnews.epfl.ch...
> Well,
>
> I've a XPS project with a MicroBlaze and BRAMs on the hardware side, and
> a C program on the software side. I'm able to synthesize it (with
> synplify for example), and put this submodule as netlist in a EDK pcore.
>
> Then I can use it as "peripheral" for another XPS project, which
> describes my complete system (with PPC and so...).
>
> But I've a problem. How to initialize Microblaze's BRAM without
> generating the bitstream of my submodule ?
>
> I've seen a commercial Core with a microblaze inside. They give the
> memory .bmm with it, to be able to update the software. I've tried to 
> "init_bram" after the bitstream generation from the main xps project. But 
> it seems that this bmm file, without the "par" informations is useless.
>
> Thanks in advance.
>
> Best regards.
>
>

correct. you can update existing .BIT with the SW only if you have the 
proper .BMM with the location information in it, otherwise its no use

Antti 



Article: 93633
Subject: Re: Download to board with RS232
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 27 Dec 2005 11:00:05 +0100
Links: << >>  << T >>  << A >>
"Frank Schreiber" <frankschr@googlemail.com> schrieb im Newsbeitrag 
news:dopoa5$mlo$1@anderson.hrz.tu-chemnitz.de...
> Hello
> I am starting FPGA with a V4MB, without any download cable, but a RS-232
> cable. I am wondering how to download my bit stream file to my board.
> Could anyone help me ?
> Frank
>
>
there are almost no boards that can be configured over RS232

and not so many that can over USB

1 digilent XUP board - Platform USB Cable embedded on board
2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board
3 Cesys USB boards custom USB downloader
4 Avnet S3e100 eval board custom USB downloader
5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option
6 www.fpga4fun.com custom USB downloader
7 opalkelly custom USB downloader
8 ???

to my knowledge there are no V4 boards with onboard rs232/usb configuration 
(unless you have scuh board ?)

so the only help for you is to get an JTAG cable

Antti



Article: 93634
Subject: Re: Patents and (possible) Plagiarism, Anyone ever been in a similar situation?
From: wtxwtx@gmail.com
Date: 27 Dec 2005 02:02:17 -0800
Links: << >>  << T >>  << A >>
Hi Richard,
Thank you for your excellent advice.

After reading this post, I finally understand what you have said in
your previous several postings.

Weng


Article: 93635
Subject: DDR2 support for EDK
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 27 Dec 2005 11:32:54 +0100
Links: << >>  << T >>  << A >>
Hi

can anyone share a EDK wrap for the DDR2 IP-Core?

It is scheduled for upcoming EDK releases but maybe someone has internal 
version of the PLB-DDR2 wrap for MIG DDR2 core?
We have a board to bring up and I do not like the idea of re-inventing 
something that is already done.

Antti 



Article: 93636
Subject: Re: IEEE package VHDL reference manual
From: allanherriman@hotmail.com
Date: 27 Dec 2005 03:21:19 -0800
Links: << >>  << T >>  << A >>
Binary wrote:
> Hi all,
>
> I wander how to find the IEEE package VHDL reference manual in
> Internet, can you pls give me a link?

There are a lot of IEEE packages.  Did you mean 1164?
Here's a quick reference guide for 1164.
http://www.eda.org/rassp/vhdl/guidelines/1164qrc.pdf

Regards,
Allan


Article: 93637
Subject: Re: Microblaze in a EDK pcore
From: Petter Gustad <newsmailcomp6@gustad.com>
Date: 27 Dec 2005 13:45:27 +0100
Links: << >>  << T >>  << A >>
CÚdric Jeanneret <cedric.jeanneret@epfl.ch> writes:

> But I've a problem. How to initialize Microblaze's BRAM without
> generating the bitstream of my submodule ?

You can do this with the "bitinit" program. Here's an extract from the
makefile I've made for this purpose (under Linux with PPC rather than
MB):

$(CHIP)-fpga-ppc.bit:   $(CHIP)-fpga.bit ../system/TestApp/executable.elf
        bitinit ../system/system.mhs  -bm ../system/implementation/system_stub_bd.bmm \
    -pe ppc405_0 ../system/TestApp/executable.elf -bt $< -o $@

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: 93638
Subject: Re: Microblaze in a EDK pcore
From: Paul Hartke <phartke@Stanford.EDU>
Date: Tue, 27 Dec 2005 05:10:10 -0800
Links: << >>  << T >>  << A >>
Here's how I've done it in the past.

data2mem can generate a ucf file which can then be used by ngcbuild to
add the elf info directly to the subproject netlist.  This augmented
netlist will then be passed through the rest of the implementation flow
resulting in the BRAMs being properly programmed in the final bit
file.   

Note that
http://toolbox.xilinx.com/docsan/xilinx7/books/data/docs/dev/dev0203_29.html
indicates that this is a "legacy" data2mem option.  Not sure how I'd do
it if xilinx removes this option.  

Hope this helps.
Paul

CÚdric Jeanneret wrote:
> 
> Well,
> 
> I've a XPS project with a MicroBlaze and BRAMs on the hardware side, and
> a C program on the software side. I'm able to synthesize it (with
> synplify for example), and put this submodule as netlist in a EDK pcore.
> 
> Then I can use it as "peripheral" for another XPS project, which
> describes my complete system (with PPC and so...).
> 
> But I've a problem. How to initialize Microblaze's BRAM without
> generating the bitstream of my submodule ?
> 
> I've seen a commercial Core with a microblaze inside. They give the
> memory .bmm with it, to be able to update the software. I've tried to
> "init_bram" after the bitstream generation from the main xps project.
> But it seems that this bmm file, without the "par" informations is useless.
> 
> Thanks in advance.
> 
> Best regards.

Article: 93639
Subject: Re: Download to board with RS232
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Tue, 27 Dec 2005 16:21:34 +0100
Links: << >>  << T >>  << A >>
> there are almost no boards that can be configured over RS232
>
> and not so many that can over USB
>
> 1 digilent XUP board - Platform USB Cable embedded on board
> 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board
> 3 Cesys USB boards custom USB downloader
> 4 Avnet S3e100 eval board custom USB downloader
> 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option
> 6 www.fpga4fun.com custom USB downloader
> 7 opalkelly custom USB downloader


> 8 ???
The dspio extension for a Cyclone board:
http://www.soc.tuwien.ac.at/courses/projects/dspio

It uses the FTDI2232 chip. The board is open-source and
a small C program for configuration is available from the
website. Could be a starting point when you want to make
your own USB download cable.

Martin



Article: 93640
Subject: Re: Download to board with RS232
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 27 Dec 2005 17:11:56 +0100
Links: << >>  << T >>  << A >>
"Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag 
news:43b15c03$0$12126$3b214f66@tunews.univie.ac.at...
>> there are almost no boards that can be configured over RS232
>>
>> and not so many that can over USB
>>
>> 1 digilent XUP board - Platform USB Cable embedded on board
>> 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board
>> 3 Cesys USB boards custom USB downloader
>> 4 Avnet S3e100 eval board custom USB downloader
>> 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option
>> 6 www.fpga4fun.com custom USB downloader
>> 7 opalkelly custom USB downloader
>
>
>> 8 ???
> The dspio extension for a Cyclone board:
> http://www.soc.tuwien.ac.at/courses/projects/dspio
>
> It uses the FTDI2232 chip. The board is open-source and
> a small C program for configuration is available from the
> website. Could be a starting point when you want to make
> your own USB download cable.
>
> Martin
>
>
hi Martin,

last time I checked the dspio the usb loader was not available
now it is - so that another USB config enable solution

too bad the dspio PCB is not available for purchase :(
I actually would like some PCB with FT2232 and AC97 on it
so the dspio board would be ok, but hence it is not available
I need to look other solutions

Antti












Article: 93641
Subject: Xilinx Stepping Methodology
From: "Engine" <packetswitching@sina.com>
Date: Wed, 28 Dec 2005 00:17:05 +0800
Links: << >>  << T >>  << A >>
A friend send me a document link.
http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf

He suggest we do not select Virtex4 in our projects.

I am not sure the real meaning of this document.

Does it mean that there are three bugs in the step 1 Virtex4 LX/SX?
Why do not call the Step 2 LX/SX as the mass production LX/SX?
Are there still bugs in step 2 LX/SX?
Whether step 3 LX/SX will be relased later?
Why FX is in step 0 now, what's the defination of step 0?

Please help me!

If it is ture, I would like to use the old VirtexII or Stratix on my
projects.

Thanks,
Engine






Article: 93642
Subject: Re: Xilinx Stepping Methodology
From: Ray Andraka <ray@andraka.com>
Date: Tue, 27 Dec 2005 11:41:04 -0500
Links: << >>  << T >>  << A >>
Engine wrote:

> A friend send me a document link.
> http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf
> 
> He suggest we do not select Virtex4 in our projects.
> 
> I am not sure the real meaning of this document.
> 
> Does it mean that there are three bugs in the step 1 Virtex4 LX/SX?
> Why do not call the Step 2 LX/SX as the mass production LX/SX?
> Are there still bugs in step 2 LX/SX?
> Whether step 3 LX/SX will be relased later?
> Why FX is in step 0 now, what's the defination of step 0?
> 
> Please help me!
> 
> If it is ture, I would like to use the old VirtexII or Stratix on my
> projects.
> 
> Thanks,
> Engine
> 
> 
> 
> 
> 

Think of the stepping number as service packs for the silicon.  The 
higher stepping numbers generally reflect silicon revisions to correct 
deficiencies in earlier silicon.  There aren't really any show-stopper 
bugs in the V4 silicon, so I wouldn't discard a V4 solution jsut because 
someone suggested you didn't use the parts.

Step 0 is the first silicon, which is/was sold as the engineering samples.

The NBTI problem mentioned in the link you posted turns out to be a 
non-problem for real world designs.  It does degrade DCM performance if 
the DCMs are not operated according to the constraints listed, but the 
DCM is so much faster than what is required to support the fabric, that 
the degradation does not slow them enough to affect real-world designs. 
  IMHO, Xilinx did the right thing with regards to disseminating info 
about the NBTI problem so that customers could work with all the info 
known at the time rather than leaving the customer to potentially 
discovering a problem on their own later (unlike the handling of the 
FIFO16 issue).

The Virtex4 does have significant advantages over the earlier families. 
As with most silicon rollouts of this complexity, there are some fairly 
minor bugs in the design that will be worked out over time. The only one 
I am aware of that is a show stopper is the MGT's in the FX line.  If 
that doesn't affect your design plans, there is no reason I can see to 
avoid the V4 line.  I've got a couple major V4SX55 designs working 
satisfactorly  in the lab now, and overall I am happy with the device.

Article: 93643
Subject: Re: Xilinx Stepping Methodology
From: Austin Lesea <austin@xilinx.com>
Date: Tue, 27 Dec 2005 08:55:54 -0800
Links: << >>  << T >>  << A >>
Engine,

Well, we did not invent stepping, Intel did.

Stepping is just another way to keep track of what you are shipping.

Let me give you an example:

We go to production, even perhaps with errata:

http://www.xilinx.com/xlnx/xil_ans_display.jsp?iLanguageID=1&iCountryID=1&getPagePath=14052

which is an example of an errata for Virtex 2 Pro.

Errata are items that are presently not working as they are described in 
the documentation.

Errata can be cleared by: manual work-arounds with technical answers, or 
product notices; changes to the silicon (very rare); changes to the 
software (so that the problem is worked around automatically; and 
everything works as documented); or changes to the data sheet (so that 
the issue is described properly).

The stepping system ensures "backward compatibility" which means that 
any future chips MUST work with older bitstreams, in older designs. 
This means that the customer does not have to worry that a new mask 
revision will cause all of your previous IP to suddenly be "broken" and 
need to be regenerated!

Some other manufacturers are on their n-th revision of silicon, and have 
no "stepping" system at all, nor any policy about what they are doing 
(to you).

If anything, I would require a properly documented stepping policy for 
approval of any component, so that I would be sure that I would not be 
"surprised" in any future shipment.

To this end, Virtex 4 was one of the first products to have the fully 
implemented stepping system in place.  Eventually all products will use 
the system.

As always, if your company has its own policies, with their own 
requirements, Xilinx is more than willing to work with you to establish 
your own required flow to meet those needs.  Some examples are customers 
who require samples of the new stepping, and need 90 days before the new 
stepping is allowed to be shipped to them as production.  These 
requirements are quite common with automotive suppliers, for example.

If you have any other concerns or questions on stepping, please consult 
your Xilinx FAE.  As well, if you have any questions or concerns about 
errata, also consult your FAE.

Austin


Engine wrote:

> A friend send me a document link.
> http://direct.xilinx.com/bvdocs/notifications/xcn05025.pdf
> 
> He suggest we do not select Virtex4 in our projects.
> 
> I am not sure the real meaning of this document.
> 
> Does it mean that there are three bugs in the step 1 Virtex4 LX/SX?
> Why do not call the Step 2 LX/SX as the mass production LX/SX?
> Are there still bugs in step 2 LX/SX?
> Whether step 3 LX/SX will be relased later?
> Why FX is in step 0 now, what's the defination of step 0?
> 
> Please help me!
> 
> If it is ture, I would like to use the old VirtexII or Stratix on my
> projects.
> 
> Thanks,
> Engine
> 
> 
> 
> 
> 

Article: 93644
Subject: Re: Download to board with RS232
From: "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at>
Date: Tue, 27 Dec 2005 18:01:44 +0100
Links: << >>  << T >>  << A >>

"Antti Lukats" <antti@openchip.org> schrieb im Newsbeitrag news:dorp4a$1da$1@online.de...
> "Martin Schoeberl" <mschoebe@mail.tuwien.ac.at> schrieb im Newsbeitrag news:43b15c03$0$12126$3b214f66@tunews.univie.ac.at...
>>> there are almost no boards that can be configured over RS232
>>>
>>> and not so many that can over USB
>>>
>>> 1 digilent XUP board - Platform USB Cable embedded on board
>>> 2 digilent Spartan 3E starterkit - Platform USB Cable embedded on board
>>> 3 Cesys USB boards custom USB downloader
>>> 4 Avnet S3e100 eval board custom USB downloader
>>> 5 Avnet Virtex 4 boards, USB downloader DISABLED by board assembly option
>>> 6 www.fpga4fun.com custom USB downloader
>>> 7 opalkelly custom USB downloader
>>
>>
>>> 8 ???
>> The dspio extension for a Cyclone board:
>> http://www.soc.tuwien.ac.at/courses/projects/dspio
>>
>> It uses the FTDI2232 chip. The board is open-source and
>> a small C program for configuration is available from the
>> website. Could be a starting point when you want to make
>> your own USB download cable.
>>
>> Martin
>>
>>
> hi Martin,
>
> last time I checked the dspio the usb loader was not available
> now it is - so that another USB config enable solution
>
> too bad the dspio PCB is not available for purchase :(
> I actually would like some PCB with FT2232 and AC97 on it
> so the dspio board would be ok, but hence it is not available
> I need to look other solutions
>
> Antti

Hi Antti,

I have produced several of them at the university. I can
arrange it that the University will sell you one. The price
is about EUR 100,-

Martin



Article: 93645
Subject: USB 2.0 testbench available?
From: "johnp" <johnp3+nospam@probo.com>
Date: 27 Dec 2005 09:16:28 -0800
Links: << >>  << T >>  << A >>
Does anyone know of a testbench for driving the Opencores USB 2.0
function core?

I'm starting to play with the core and I'd haate to duplicate any work
that's already been done.


Thanks!

John Providenza


Article: 93646
Subject: Re: USB 2.0 testbench available?
From: "Antti Lukats" <antti@openchip.org>
Date: Tue, 27 Dec 2005 18:29:55 +0100
Links: << >>  << T >>  << A >>
"johnp" <johnp3+nospam@probo.com> schrieb im Newsbeitrag 
news:1135703787.884273.241050@g47g2000cwa.googlegroups.com...
> Does anyone know of a testbench for driving the Opencores USB 2.0
> function core?
>
> I'm starting to play with the core and I'd haate to duplicate any work
> that's already been done.
>
>
> Thanks!
>
> John Providenza
>
no, there is not, and most likely will not be. the usb 2.0 core at opencores 
has several bugs and is not directly useable.

Antti 



Article: 93647
Subject: Re: Place and Route Algorithms
From: "Piotr Wyderski" <wyderski@mothers.against.spam-ii.uni.wroc.pl>
Date: Tue, 27 Dec 2005 18:37:34 +0100
Links: << >>  << T >>  << A >>
marco wrote:

> Does anyone know where I can find information about the place and
> route algorithms used for FPGAs

Globally optimal placement and routing is an NP-hard problem even for
multilayer PCBs, so all you can expect is only a set of approximations, if
you want to receive that placement in a reasonable time.

    Best regards
    Piotr Wyderski

-- 
"If you were plowing a field, which would you rather use?
Two strong oxen or 1024 chickens?" -- Seymour Cray


Article: 93648
Subject: Re: RTL for Z8000 series CPU?
From: "Peter Alfke" <peter@xilinx.com>
Date: 27 Dec 2005 10:10:29 -0800
Links: << >>  << T >>  << A >>
AMD received the transistor diagrams as part of the second-source
agreement, and they then reverse-engineered a logic diagram. (I know,
for I was involved).
AMD is a bigger, and perhaps more organized company.
But this is all some 27 years ago...
Peter Alfke
=============
Monte Dalrymple wrote:
>
> > >> Oh, the documentation existed, and it was in the control of Shima, the
> designer. But once he left the company I don't know who, if anyone,
> inherited his filing cabinet. It wasn't until much later that such design
> materials were kept in a centralized location with a control number
> and access/revision control. Even then, sometimes things went in to
> DC never to be found again, so designers hated to give the original
> stuff up to DC.
> 
> Monte


Article: 93649
Subject: Re: More beginner's verilog questions
From: Chris F Clark <cfc@shell01.TheWorld.com>
Date: 27 Dec 2005 16:39:01 -0500
Links: << >>  << T >>  << A >>
I seem to have missed some articles in this thread, as there are some
things being reference that I can't having seen.  However, I would
like to respond to some of the last comments I've seen.

Reza Naima wrote:
> It seems my biggest problem was that I though that HDL would give me
> the ability to write behavioral code and the software would be able
> to make it work...

Yes, that is always the hitch--in every area where we have automated
tools: synthesizers, parser generators (my area of expertise), 4GL
lanugages, natural language translators, et al.  There is some level
of behavioral code that tools will be able translate.  However, they
will never reach the "holy grail".  This is no "dwim" (do what I mean)
instruction and cannot be.  What we have are idioms that tools can
understand and paraphrase.  If you learn the idioms (dialect) the tool
can speak, you can make it do quite a bit.  

Here is some very specific advice about what idioms that synthesizers
understand.

Jan Decaluwe wrote:
> My advice: for implementation-oriented modeling, you only need 2
> templates: the synchronous always block (sensitive to a clock
> edge and possibly a reset edge), and the combinatorial always
> block (sensitive to the input signal levels).

This is the essence of a digital design course.  Laying down
combinatorial logic that is fed into (or driven by) a set of
flip-flops that are clocked at an appropriate time.  At some very deep
level all synchronous digital design is about designing an FSM (finite
state machine) which is merely a collection of gates around
flip-flops.

J> To a large extent, you can concentrate on getting the behavior
> right (hard enough), and rely on the synthesis tool to give you a good
> implementation.

This is true.  If you build everything, out of the two blocks
described, you will have designed a circuit that a synthesizer can
build.  There are still timing issues and other things to worry about.
However, the synthesizer will be able to lay down a set of gates that
does what your model does.  This is the technology that the
syntehsizer writers' have, a way of translating those two idioms into
circuitry.  Those are probably about the only two universal idioms,
because they represent things that are present in all forms
(implementations) of Boolean logic.

Things like tri-state drivers are not universal, because they are not
purely parts of Boolean logic and some implementations will have them
and others may not.  Moreover, they may work "differently" in varying
implementations, because the underlying mechanism may work
"differently", and that may require specifying them differently at the
source level, to give a better interpretation of the semantics of the
implementation.

J> In contrast to what many people will tell you (and sometimes shout
> at you), there's no need to try to visualize the exact hardware that
> will come out. Believe me, they can't either.

Here I will disagree to some extent.  Jan is correct in that I can't
predict exactly what gates will be infered by a synchronous always
block I write.  However, I do have a reasonable expectation, that it
will be some combinatorial logic feeding some flip-flops and some
combinatorial logic leading away from the flip-flops.  Moreover, when
I've written a synchronous always block, I have a pretty code idea
what signal is going to be driving the clock pins of the flip-flops in
that block.  Now, if I want something different, say a tri-state bus
with some keeper that has a specific decay on it, I will write
different Verilog code.  I will be really surprised if a synthesizer
writes out a tri-state bus when I've written a synchronous always
block--the synchronous always block is not the idiom used to create a
tri-state bus.

This is what I mean, by think hardware.  Learn the idioms and what
they translate to.  There aren't many of them.  I think I know about
5: combinatorial code, synchronous (clocked) always block, tri-state
driver, priority encoder, and mux.  Once you've learned the idioms,
then you know when you want something that works like x, you pick the
idiom that generates an x.  Now, you may not know all the hardware the
synthesizer will generate to lay down an x (and the synthesizer may
even be more clever than you are and know that a y will work in the
given context and substitute a y), but you'll have basic concepts of
what the synthesizer can do for you and you will design circuits which
the synthesizer can lay down.  When I want to design something, I
think how I can build it using those basic concepts, and once I know
that I can build it out of those things, then I have a rough design.
If I want something that I can't map to those concepts, then I don't
know how to build it (and I don't know what to tell the synthesizer
either).

Not to beat a dead horse, but I have one final comment on the topic
of "thinking in hardware".  It has to do with for-loops.  There are
some for loops that can be synthesized, but many (most) cannot.  In
general for-loops that search cannot by synthesized.  Nor can ones
that do sorting.  For-loops that simply iterate over each bit of a
resigter can.  If one lays down an unsynthesizable for-loop in an
otherwise synthesizable always block, the result is unsynthesizable.
The whole point of "thinking in terms of hardware" is avoiding writing
that kind of code.

Finally, I don't have a good answer to:

R> -  There have been several replies indicating that the order of the
> statment has to do with priorities, and an async reset has a higher
> priority.  Why is this?  Is this just how flipflops are physically
> built?

It's probably more likely an artifact of the synthesizer.  As I said
previoiusly, the synthesizer works by matching your code to its
templates.  Those templates have some assumptions built into them.
Now, there are some variations in the templates the synthesizer can
handle (and better synthesizers generally can handle more variation).
However, at some level, when you've strayed too far from the
templates, the synthesizer writer cannot legitimately infer what you
"meant" and the writer chooses instead to give you an error telling
you to change your code into something that better matches the
templates (rather than instantiating something that is wrong).

Hope this helps,
-Chris

*****************************************************************************
Chris Clark                    Internet   :  compres@world.std.com
Compiler Resources, Inc.       Web Site   :  http://world.std.com/~compres  
23 Bailey Rd                   voice      :  (508) 435-5016
Berlin, MA  01503  USA         fax        :  (978) 838-0263  (24 hours)
------------------------------------------------------------------------------



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
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

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