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 41450

Article: 41450
Subject: Re: I need an advice regarding a switch to a Digital Design Career
From: Mike Treseler <mike.treseler@flukenetworks.com>
Date: Thu, 28 Mar 2002 13:32:24 -0800
Links: << >>  << T >>  << A >>
BAM wrote:

>  do u think that i am very late to persue a careeer in Digital design,
> i mean which company would recruit a 28 year old guy with no previous
> exp...

Age is irrelevant. 
What matters is your interest level and
projects that you have done.
You may have to do some on your own to
get started and demonstate your abilities.

>  i need an advice, since  i think this field is somewhat special 

To start with, you  need to 
learn an HDL and a simulator.

   -- Mike Treseler

Article: 41451
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 28 Mar 2002 21:51:26 GMT
Links: << >>  << T >>  << A >>
In the case where just the innards of the CLBs are getting reconfigured, I find
it is a whole lot easier just to use SRL16's and do a 'poor-mans' reconfiguration
by shifting new data into the SRL16.  There are several benefits, all tool
related:

1) The pins to the SRL16 are not permuted like they are for a LUT, so there is no
having to figure out what the LUT pin assignments are
2) You can simulate the entire design with existing tools, including the
reconfiguration
3) The SRL16 reload can be faster: 16 clocks of your system clock to reload vs
many CCLK clocks to clock in a new frame
4) The SRL16's are supported by mainstream tools flow vs. a hacking approach
using jbits
5) no need to mess with the select map interface and potentially reconfiguring
wrong.

Some day, the tools might be there for partial reconfig, but right now, it is not
for the faint of heart nor for those who for whatever reason MUST use the
mainstream tools.

Peter Alfke wrote:

> Tim wrote:
>
> > Can you give us any insight into a realistic scenario for
> > tool support over the next few years?  Or is it there already
> > if we just knew where to look?
>
> Tool support for partial reconfiguration was the question.
>
> I do not have a ready answer. Will try to research this.
> I have looked  (very seriously) at designs where the course inter-CLB routing
> structure is constant, but the innards of the CLBs and DCMs are being
> re-configured. That is not too difficult.
> I will get involved more in J-Bits, maybe that is the (partial) answer...
> Peter Alfke

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41452
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: Ray Andraka <ray@andraka.com>
Date: Thu, 28 Mar 2002 22:04:32 GMT
Links: << >>  << T >>  << A >>

Modular design and partial reconfiguration are two very different things.  Modular
design is a capability in the software that should let you do place and route on
sections of a design separately, while partial reconfig lets you load pieces of the
design without (re)programming the whole enchilada. While the bitstreams between
spartanII and virtex (not virtexE) are identical, the silicon is not.  SpartanII
and Virtex 2.5v have the same device features from a bitstream standpoint, thus the
ability for identical bitstreams.  Nevertheless there are a few differences between
the spartanII and the 2.5v Virtex: One of those differences is that the spartanII
does not support the select map programming mode, which is the mechanism needed for
partial reconfiguration, ergo no partial reconfig in the spartanII devices.

rickman wrote:

> I am confused.  I thought the web site clearly says that partial
> reconfiguration is currently supported in the tools for the VirtexE and
> VirtexII devices?  Of course, this is clearly a marketing page with
> little technical detail, but they do make this claim without caveats.
>
> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=partial_reconfig
>
> and
>
> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design
>
> Am I reading something into this that is not there?
>
> It is also not clear to me if (or moreso why-not?) this is available for
> the Spartan-IIE chips.  They are supposed to be the same as the VirtexE
> and I have heard they even support the same bit streams, even though
> they don't have as much BRAM.  The modular design page says SpartanII is
> supported, but the Partial Reconfig page does not.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41453
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 28 Mar 2002 14:35:38 -0800
Links: << >>  << T >>  << A >>
I obviously have to do more homework here...
Peter Alfke

rickman wrote:

> Peter Alfke wrote:
> >
> > Tim wrote:
> >
> > > Can you give us any insight into a realistic scenario for
> > > tool support over the next few years?  Or is it there already
> > > if we just knew where to look?
> >
> > Tool support for partial reconfiguration was the question.
> >
> > I do not have a ready answer. Will try to research this.
> > I have looked  (very seriously) at designs where the course inter-CLB routing
> > structure is constant, but the innards of the CLBs and DCMs are being
> > re-configured. That is not too difficult.
> > I will get involved more in J-Bits, maybe that is the (partial) answer...
> > Peter Alfke
>
> I am confused.  I thought the web site clearly says that partial
> reconfiguration is currently supported in the tools for the VirtexE and
> VirtexII devices?  Of course, this is clearly a marketing page with
> little technical detail, but they do make this claim without caveats.
>
> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=partial_reconfig
>
> and
>
> http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design
>
> Am I reading something into this that is not there?
>
> It is also not clear to me if (or moreso why-not?) this is available for
> the Spartan-IIE chips.  They are supposed to be the same as the VirtexE
> and I have heard they even support the same bit streams, even though
> they don't have as much BRAM.  The modular design page says SpartanII is
> supported, but the Partial Reconfig page does not.
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
>
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX


Article: 41454
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Thu, 28 Mar 2002 22:35:43 GMT
Links: << >>  << T >>  << A >>
Ray you can partially reconfigure the Spartan II.  The Spartan II has no
master parallel mode. All the virtex (as far as I know) support partial
reconfiguration.

From xapp 176

Spartan-II FPGAs have the ability to be only partially re-configure or
readback; however, this
topic is beyond the scope of this note. For more information on partial
configuration,

Steve

>One of those differences is that the spartanII
> does not support the select map programming mode, which is the mechanism
needed for
> partial reconfiguration, ergo no partial reconfig in the spartanII
devices.



Article: 41455
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: Peter Alfke <peter.alfke@xilinx.com>
Date: Thu, 28 Mar 2002 14:39:00 -0800
Links: << >>  << T >>  << A >>
Ray, I wrote "innards of the CLB" for a reason. I am not changing the LUTs, but
rather the intra-CLB routing structure.
For changing LUTs, your suggestion of using SRL16 is 100% right.
Peter Alfke

Ray Andraka wrote:

> In the case where just the innards of the CLBs are getting reconfigured, I find
> it is a whole lot easier just to use SRL16's and do a 'poor-mans' reconfiguration
> by shifting new data into the SRL16.  There are several benefits, all tool
> related:
>
> 1) The pins to the SRL16 are not permuted like they are for a LUT, so there is no
> having to figure out what the LUT pin assignments are
> 2) You can simulate the entire design with existing tools, including the
> reconfiguration
> 3) The SRL16 reload can be faster: 16 clocks of your system clock to reload vs
> many CCLK clocks to clock in a new frame
> 4) The SRL16's are supported by mainstream tools flow vs. a hacking approach
> using jbits
> 5) no need to mess with the select map interface and potentially reconfiguring
> wrong.
>
> Some day, the tools might be there for partial reconfig, but right now, it is not
> for the faint of heart nor for those who for whatever reason MUST use the
> mainstream tools.
>
> Peter Alfke wrote:
>
> > Tim wrote:
> >
> > > Can you give us any insight into a realistic scenario for
> > > tool support over the next few years?  Or is it there already
> > > if we just knew where to look?
> >
> > Tool support for partial reconfiguration was the question.
> >
> > I do not have a ready answer. Will try to research this.
> > I have looked  (very seriously) at designs where the course inter-CLB routing
> > structure is constant, but the innards of the CLBs and DCMs are being
> > re-configured. That is not too difficult.
> > I will get involved more in J-Bits, maybe that is the (partial) answer...
> > Peter Alfke
>
> --
> --Ray Andraka, P.E.
> President, the Andraka Consulting Group, Inc.
> 401/884-7930     Fax 401/884-7950
> email ray@andraka.com
> http://www.andraka.com
>
>  "They that give up essential liberty to obtain a little
>   temporary safety deserve neither liberty nor safety."
>                                           -Benjamin Franklin, 1759


Article: 41456
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: rickman <spamgoeshere4@yahoo.com>
Date: Thu, 28 Mar 2002 18:24:49 -0500
Links: << >>  << T >>  << A >>
Yes, Partial Reconfiguration is not the same thing as Modular Design,
but the first web page I referenced says that Modular Design is required
to implement Partial Reconfiguration.  The Modular Design web page
includes Spartan-II&E while the Partial Reconfiguration web page only
lists the Virtex & Virtex-II families.  

The SpartanII data sheet does not describe the Selectmap mode of
configuraion, but it does describe Slave Parallel Mode which seems to be
the same thing.  The SpartanIIE data sheet uses both names together.  So
I doubt that the modes are different between the two chips.  


Ray Andraka wrote:
> 
> Modular design and partial reconfiguration are two very different things.  Modular
> design is a capability in the software that should let you do place and route on
> sections of a design separately, while partial reconfig lets you load pieces of the
> design without (re)programming the whole enchilada. While the bitstreams between
> spartanII and virtex (not virtexE) are identical, the silicon is not.  SpartanII
> and Virtex 2.5v have the same device features from a bitstream standpoint, thus the
> ability for identical bitstreams.  Nevertheless there are a few differences between
> the spartanII and the 2.5v Virtex: One of those differences is that the spartanII
> does not support the select map programming mode, which is the mechanism needed for
> partial reconfiguration, ergo no partial reconfig in the spartanII devices.
> 
> rickman wrote:
> 
> > I am confused.  I thought the web site clearly says that partial
> > reconfiguration is currently supported in the tools for the VirtexE and
> > VirtexII devices?  Of course, this is clearly a marketing page with
> > little technical detail, but they do make this claim without caveats.
> >
> > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=partial_reconfig
> >
> > and
> >
> > http://www.xilinx.com/xlnx/xil_prodcat_product.jsp?title=modular_design
> >
> > Am I reading something into this that is not there?
> >
> > It is also not clear to me if (or moreso why-not?) this is available for
> > the Spartan-IIE chips.  They are supposed to be the same as the VirtexE
> > and I have heard they even support the same bit streams, even though
> > they don't have as much BRAM.  The modular design page says SpartanII is
> > supported, but the Partial Reconfig page does not.


-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Article: 41457
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: "Steve Casselman" <sc.nospam@vcc.com>
Date: Thu, 28 Mar 2002 23:49:21 GMT
Links: << >>  << T >>  << A >>
That page says partial reconfiguration can be
"Enabled through the Modular Design software option,"

I'm sure you can "Enable" partial reconfiguration just by setting the
persist option to yes. Of course the 3.xi software had no way to set this in
the GUI so maybe that is what they are talking about.

Steve


"rickman" <spamgoeshere4@yahoo.com> wrote in message
news:3CA3A641.55E9CA1E@yahoo.com...
> Yes, Partial Reconfiguration is not the same thing as Modular Design,
> but the first web page I referenced says that Modular Design is required
> to implement Partial Reconfiguration.  The Modular Design web page
> includes Spartan-II&E while the Partial Reconfiguration web page only
> lists the Virtex & Virtex-II families.




Article: 41458
Subject: Re: Partial Reconfiguration (was: GREAT availability on Coolrunner)
From: Ray Andraka <ray@andraka.com>
Date: Fri, 29 Mar 2002 00:15:05 GMT
Links: << >>  << T >>  << A >>
Hmm,

I was under the impression that partial reconfig was not supported by
SpartanII.  The flurry of handbooks and documents is starting to make the tax
code look like a child's bedtime story.  Peter, perhaps you can answer this
definitively: Is partial configuration supported in the SpartanII line, or is
that one of the features that got dropped out in the cost reducing die
shrink?  Inquiring minds want to know!

Steve Casselman wrote:

> Ray you can partially reconfigure the Spartan II.  The Spartan II has no
> master parallel mode. All the virtex (as far as I know) support partial
> reconfiguration.
>
> From xapp 176
>
> Spartan-II FPGAs have the ability to be only partially re-configure or
> readback; however, this
> topic is beyond the scope of this note. For more information on partial
> configuration,
>
> Steve
>
> >One of those differences is that the spartanII
> > does not support the select map programming mode, which is the mechanism
> needed for
> > partial reconfiguration, ergo no partial reconfig in the spartanII
> devices.

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

 "They that give up essential liberty to obtain a little
  temporary safety deserve neither liberty nor safety."
                                          -Benjamin Franklin, 1759



Article: 41459
Subject: strange RAM timing problem (VirtexE)
From: Tullio Grassi <tullio@physics.umd.edu>
Date: Thu, 28 Mar 2002 19:27:41 -0500
Links: << >>  << T >>  << A >>
Hi,

 in a fpga design for our research project we have differencies
between functional simulation and timing simulation.
Our verilog design :
-  use ActiveHDL in the foreground
-  use a lot of VirtexE block RAM, logical simulation is ok.
-  infer RAM like that:

 /********************************************************************************

This module is a Dual Port Synchronous RAM.
The Xilinx sythesiser XST infers actual RAM from it.
Do not change it, but instatiate it in higher level modules.
*/
`timescale 1ns / 1ns
module DP_Syn_RAM
   (   clk,    we,   wr_addr,   rd_addr,   din,   dout );
parameter
    RAM_ADDR_WIDTH = 8,
    DATA_WIDTH = 8,
    RAM_DEPTH = 256;

    input                                 clk;
    input                                 we;
    input    [RAM_ADDR_WIDTH - 1:0]       wr_addr;
    input    [RAM_ADDR_WIDTH - 1:0]       rd_addr;
    input    [DATA_WIDTH - 1:0]           din;
    output   [DATA_WIDTH - 1:0]           dout;

    reg      [DATA_WIDTH - 1:0]           ram [RAM_DEPTH - 1:0];
    reg      [RAM_ADDR_WIDTH - 1:0]       read_addrb;

always @(posedge clk) begin
     if (we)
            ram[wr_addr] <= din;
            read_addrb  <= rd_addr;
      end
assign dout = ram[read_addrb];
endmodule
//******************************************************************************

- higher level modules are fully synchronous [always @(posedge clk)...]
,
   make sure that rd_addr is different from wr_addr at any time; but the
signal
  interfacing the RAM are NOT latched as the VirtexE data sheet states:
  "All inputs are registered with the port clock and have a
   set-up to clock timing specification."
- asyncronous report is fine (max delay path ~9ns, while Tck=25ns)
- syntesis and implementation with XST
- from timing simulation we get a lot of errors like:
   # : C:\Program Files\Aldec\Active-HDL
5.1\vlib\OVI_Simprim/./src/x_ramb4_s16_s16.v, 0:
  Timing violation in
/daqpath/\ram_derandomizer/drnd13/Mram_ram_inst_ramb_7 \
   # : $recovery(CLKB:13987,CLKA:13997,2328)
  They happen at every clk edge, for most of the block rams.
- Some output waveforms are wrong: the dout from a few rams are wrong
  and data seem to come from a location different from the location
  actually addressed. These RAMs are part of o group of 24 parallel RAMs

  (that is sharing the same address lines). Is a fanout problem ?

Thanks in advance for any help,

Tullio Grassi

======================================
Univ. of Maryland - Dept. of Physics
College Park, MD 20742 - US
Tel +1 301 405 5970
Fax +1 301 699 9195
======================================


Article: 41460
Subject: Re: strange RAM timing problem (VirtexE)
From: spam_hater_7@email.com (Spam Hater)
Date: Fri, 29 Mar 2002 02:12:55 GMT
Links: << >>  << T >>  << A >>
Change:
>assign dout = ram[read_addrb];
To:
    dout <= ram(read_addrb);



On Thu, 28 Mar 2002 19:27:41 -0500, Tullio Grassi
<tullio@physics.umd.edu> wrote:

>Hi,
>
> in a fpga design for our research project we have differencies
>between functional simulation and timing simulation.
>Our verilog design :
>-  use ActiveHDL in the foreground
>-  use a lot of VirtexE block RAM, logical simulation is ok.
>-  infer RAM like that:
>
> /********************************************************************************
>
>This module is a Dual Port Synchronous RAM.
>The Xilinx sythesiser XST infers actual RAM from it.
>Do not change it, but instatiate it in higher level modules.
>*/
>`timescale 1ns / 1ns
>module DP_Syn_RAM
>   (   clk,    we,   wr_addr,   rd_addr,   din,   dout );
>parameter
>    RAM_ADDR_WIDTH = 8,
>    DATA_WIDTH = 8,
>    RAM_DEPTH = 256;
>
>    input                                 clk;
>    input                                 we;
>    input    [RAM_ADDR_WIDTH - 1:0]       wr_addr;
>    input    [RAM_ADDR_WIDTH - 1:0]       rd_addr;
>    input    [DATA_WIDTH - 1:0]           din;
>    output   [DATA_WIDTH - 1:0]           dout;
>
>    reg      [DATA_WIDTH - 1:0]           ram [RAM_DEPTH - 1:0];
>    reg      [RAM_ADDR_WIDTH - 1:0]       read_addrb;
>
>always @(posedge clk) begin
>     if (we)
>            ram[wr_addr] <= din;
>            read_addrb  <= rd_addr;
>      end
>assign dout = ram[read_addrb];
>endmodule
>//******************************************************************************
>
>- higher level modules are fully synchronous [always @(posedge clk)...]
>,
>   make sure that rd_addr is different from wr_addr at any time; but the
>signal
>  interfacing the RAM are NOT latched as the VirtexE data sheet states:
>  "All inputs are registered with the port clock and have a
>   set-up to clock timing specification."
>- asyncronous report is fine (max delay path ~9ns, while Tck=25ns)
>- syntesis and implementation with XST
>- from timing simulation we get a lot of errors like:
>   # : C:\Program Files\Aldec\Active-HDL
>5.1\vlib\OVI_Simprim/./src/x_ramb4_s16_s16.v, 0:
>  Timing violation in
>/daqpath/\ram_derandomizer/drnd13/Mram_ram_inst_ramb_7 \
>   # : $recovery(CLKB:13987,CLKA:13997,2328)
>  They happen at every clk edge, for most of the block rams.
>- Some output waveforms are wrong: the dout from a few rams are wrong
>  and data seem to come from a location different from the location
>  actually addressed. These RAMs are part of o group of 24 parallel RAMs
>
>  (that is sharing the same address lines). Is a fanout problem ?
>
>Thanks in advance for any help,
>
>Tullio Grassi
>
>======================================
>Univ. of Maryland - Dept. of Physics
>College Park, MD 20742 - US
>Tel +1 301 405 5970
>Fax +1 301 699 9195
>======================================
>


Article: 41461
Subject: Homebuilt Altera-programmer totally dead...
From: "Alexander Miks" <monstrum@tiscali.se>
Date: Fri, 29 Mar 2002 03:46:07 +0100
Links: << >>  << T >>  << A >>
I have built an Altera downloading-cable based on the ByteBlasterMV
datasheet. The problem is that it won't work. So where do I start
troubleshooting? I've checked all connections, so that shouldn't be the
problem. And is the cable supposed to be able to detect without being
connected to the target board (only power-supply)?
Please help me out, I'm a very poor student and I can't afford to spend $150
(or more likely twice of that over here in Sweden).



Article: 41462
Subject: Re: HELP me, about chipscope analyzer
From: "William L Hunter Jr" <wlhunterjr@attbi.com>
Date: Fri, 29 Mar 2002 03:08:43 GMT
Links: << >>  << T >>  << A >>
Changchun

Core version 0.0 is not valid means that you have not inserted a ILA core
using the ILA core inserter or by instaniating one in VHDL.

When you install MULTILINX it will install the appropriate driver.  I am
using WIN 2000 and it works fine except for the ocassional "Internal Error:
Failed to execute api function."  Ignore this error.

Bill


"Changchun WAN" <ccwan@phys.sinica.edu.tw> wrote in message
news:a7dgrg$2suo$1@news1.sinica.edu.tw...
> Hi
>
> When I opened the serial MultiLINX port in chipscope I got an error
message
> "Internal Error: Failed to execute api function."
>
> Then it initialized the the port and reported success. I can setup the
> boundary scan chain and got correct device information, but when I
> downloaded the .bit to the device another error message appeared:
>
> "Core version 0.0 is not valid or not supported. Please verify that all
> instruction register lengths in the JTAG chain are properly specified."
>
> But in fact the instruction register length is right and got by JTAG chain
> automatically. (only XILINX device in the chain)
>
> The device can work after download, but I can not setup trig signal etc.
The
> error message is also "Core version 0.0 is ... "
>
> Who can give me some suggestion? Thanks!
>
> By the way, my MultiLINX had never worked successfully with USB cable.
Does
> Win2000 need install some driver?
>
> Changchun
>
>



Article: 41463
Subject: Re: Clock termination affecting JTAG interface
From: Eddy <eddyvk@yahoo.com>
Date: Fri, 29 Mar 2002 05:51:31 GMT
Links: << >>  << T >>  << A >>
>> Hi All,
>> 
>> I have encountered a strange problem on a board we have designed. The 
>> board contains a Xilinx Spartan II XC2S200, two Xilinx XC95288XL CPLDs, 
>> and one Xilinx XC95144XL CPLD.
>> 
>> There are three power supply voltages on the board: 2.5V for the Spartan 
>> II core, 3.3V for the CPLDs and the Spartan II I/O, and 5V for some RAM 
>> and ROM.
>> 
>> There is a 19.6608MHz Crystal Oscillator Module running on the 5V rail, 
>> which provides a clock to the four Xilinx chips. This clock rings more 
>> than I would like, so I wish to terminate it using pads included in the 
>> design for this reason.

So if I understand this correctly, you're clocking chips on 2.5V and 3.3V supplies from an oscillator that runs on 5V and 
therefor produces a signal of 5Vpp. What might happen here is that when the oscillator pulse is high (+5V), it lifts the clock 
input of the chips on 2.5V and 3.3V above their rails. The protection diodes on those inputs will go in forward and dump the 
excess pulse power in the VDD rail on the chip! Worst case this triggers a latch up but you only seem to suffer from 
interference ("unreliability").

>> Using information from the manufacturer I have established that the 
>> impedance of the clock trace is around 90 Ohms, so I terminated it to 5V 
>> and to ground, each with 180 Ohm resistors.

What happens now is that the clock has a more difficult time to swing rail-to-rail. Maybe it now only swings 1V to 4V instead of 
the usual 'almost' 0V to 5V.

>> When I do this, however, the JTAG test access port on the Spartan II 
>> appears to become unreliable - I am not able to configure the Spartan II 
>> via JTAG.

Maybe you get in trouble with the low level requirement. Suppose you've squeezed the clock so much that it swings 1.5V to 3.5V. 
I expect the input trigger of the chip on 2.5V to be at 1.25V and the clock doesn't reach down to 1.25V anymore.
In case of ringing you might get 'double clocks' when the low level approaches the trigger.

>> I tried terminating just to Ground (ie. removing the resistor from the 
>> clock net to 5V). This seemed to make things better, but did not fix the 
>> problem completely.

Now the clock has trouble reaching up to 5V but down to 0V is no problem. This supports the theory that you're feeding the poor 
chips at 2.5V and 3.3V with a much to large clock signal.

What you could try is a resistor divider to reduce the clock pulse down to levels that stay within the supply of the receiving 
chips.
To reduce 5V down to 3.3V, you could use 50 Ohm in series with the output and then 100 Ohm to ground.
To reduce 5V down to 2.5V, you could use 75 Ohm in series with the output and another 75 Ohm to ground.

Hope this helps.

Best regards,
Eddy van Keulen
Fremont California




Article: 41464
Subject: Unusually Large Routing Delay From a FF To a Pin in FLEX10KE
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Fri, 29 Mar 2002 00:45:21 -0600
Links: << >>  << T >>  << A >>
Okay, here is a continuation of "Unrecognized LUTs Inserted in A
FLEX10KE/ACEX1K Design" posting I made.
I just did another P&R in Quartus II 2.0 Web Edition targeting
FLEX10K100E-1, and got very strange results for one of the pin's Tco.
The pin in question is Pin W9, and PCI's FRAME# signal is connected to
this pin.



1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. = LC1_L18; REG Node
= 'FRAME_n_OE_n~reg0'

2: + IC(6.700 ns) + CELL(3.500 ns) = 10.200 ns; Loc. = Pin_W9; PIN Node
= 'FRAME_n'


1: + IC(0.000 ns) + CELL(0.000 ns) = 0.000 ns; Loc. = LC8_L18; REG Node
= 'FRAME_n_Port~reg0'


2: + IC(0.200 ns) + CELL(4.900 ns) = 5.100 ns; Loc. = Pin_W9; PIN Node =
'FRAME_n'



        This FRAME_n pin is a bidirectional pin, so there is a tri-state
buffer before the pin.
Both FRAME_n_OE_n~reg0 (An Output Enable FF) and FRAME_n_Port~reg0 (An
output FF) are located in LAB L18 which is located right above pin W9.
Even though they are from the same LAB, the routing delay for
FRAME_n_Port~reg0 is 0.2ns, which is very good, but for some reason
FRAME_n_OE_n~reg0's routing delay is staggering 6.700 ns, which I don't
understand why can it be that bad considering the physical location of
the FF.
Did FLEX10KE somehow ran out of routing channels, and the routing for
FRAME_n_OE_n~reg0 got diverted?
Or is the automatic P&R tool that bad in QII?
I didn't use an IOE FF for FRAME_n_Port~reg0 because of FLEX10KE's IOE
doesn't seem to support asynchronous preset.
For synthesis, I used QII's native Verilog synthesis (Altera in-house
synthesis tool) instead of LeonardoSpectrum-Altera because I didn't feel
like using LS-Altera for this experiment. (I will try to use it later.)



Thanks,



Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41465
Subject: Re: FPGA config without boot PROM???
From: Kevin Brace <ihatespam99kevinbraceusenet@ihatespam99hotmail.com>
Date: Fri, 29 Mar 2002 01:31:30 -0600
Links: << >>  << T >>  << A >>
Peter Alfke wrote:
> 
> 
> We have looked at this several times. Here is my -somewhat personal- opinion:
> 
> The standard CMOS process without any exotic additions ( like EEPROM or
> antifuse) is always better ( smaller, faster, higher-yielding, and earlier
> available) than a mixed process. We prefer the most aggressive
> microprocessor-oriented process.
> 


        Although, I don't know much about it, but it seemed like
anti-fuse FPGAs used to be more competitive in the '90s compared to
SRAM-based FPGAs, but now they seem to have gotten quite behind in terms
of performance or density.
Were the anti-fuse camp more competitive in terms of process technology
in the early to mid '90s?
        Will MRAM or some other non-volatile storage technology replace
SRAM at some point because of soft error concern at some process
technology? (I do realize that MRAM is nowhere near being a high volume
commercial product like flash.)



> The benefit of a EEPROM-based FPGA are really limited to very small designs,
> (where single-chip is seen as an advantage) and to certain high-security
> applications, which we already cover with triple-DES encrypted bitstreams.
> 
> The market niche is small, and we prefer our present, very successful approach.
> 
> Peter Alfke


        Then how come CPLDs remain almost all EEPROM?
Also, why doesn't CPLD's density almost never seem to go above 512 or
1,024 macrocells? (Except Cypress' Delta 39K which is SRAM-based.)




Kevin Brace (In general, don't respond to me directly, and respond
within the newsgroup.)

Article: 41466
Subject: Re: Homebuilt Altera-programmer totally dead...
From: Russell Shaw <rjshaw@iprimus.com.au>
Date: Fri, 29 Mar 2002 09:10:48 GMT
Links: << >>  << T >>  << A >>


Alexander Miks wrote:
> 
> I have built an Altera downloading-cable based on the ByteBlasterMV
> datasheet. The problem is that it won't work. So where do I start
> troubleshooting? I've checked all connections, so that shouldn't be the
> problem. And is the cable supposed to be able to detect without being
> connected to the target board (only power-supply)?
> Please help me out, I'm a very poor student and I can't afford to spend $150
> (or more likely twice of that over here in Sweden).

Have you got a 100nF cap across the 74HC244?

Article: 41467
Subject: Q: Any Virtex II pro development board on market?
From: antipattern@hotmail.com (Unit Manager)
Date: 29 Mar 2002 01:19:39 -0800
Links: << >>  << T >>  << A >>
Do you aware of any Virtex II pro development board on market?

and

Which high density FPGA board you would suggest?

Thanks,
~pat!

Article: 41468
Subject: Re: Homebuilt Altera-programmer totally dead...
From: "Tuomo Auer" <tuomo.auer@removethis.hut.fi>
Date: Fri, 29 Mar 2002 13:48:20 +0200
Links: << >>  << T >>  << A >>
Power your home-build ByteBlaster using 5V or 3V3 power supply (not
connected to computer or FPGA). Then feed to inputs (both computer side and
FPGA side) GND and VCC and check with multimeter that the other side of
74HC244 responds properly.

If possible, test also with genuine ByteBlasterMV that settings of your
software are correct and test that you don't have a dead FPGA (they are
static sensitive devices. Have separate ground wire connected between
computer and FPGA-ground when using ByteBlaster).

--
Tuomo Auer



Article: 41469
Subject: position
From: xcvjb <avbd@lk.zkxclv>
Date: Fri, 29 Mar 2002 04:06:50 -0800
Links: << >>  << T >>  << A >>
There is a 32bit data in a register.how do i know the bit "1"'s position? 
for example:
01010000110011001101010001100010

the bit "1"'s position is :
1/5/6/10/12/14/15/18/19/22/23/28/30.
how do implemention it with verilog code?

Article: 41470
Subject: Re: how to prevent infer of Mult18x18 in VirtexII
From: ospyng@yahoo.com (spyng)
Date: 29 Mar 2002 05:03:54 -0800
Links: << >>  << T >>  << A >>
hi thanks all,
you are right ken.
I just read the manual and find out that the wild card "*" does not
match ".", so I still have to give the corrected no of "."

thanks
pyng

Ken McElvain <ken@synplicity.com> wrote in message news:<3CA34C5B.4090207@synplicity.com>...
> You need
> 
> define_attribute {<entityname>|I_1*} syn_multstyle {logic}
> 
> The syntax  {<entityname>|<objectname>}  finds object <objectname>
> relative to <entityname>.  <entityname> is not a path, it is
> simply the VHDL entityname or verilog module name.
> 
> I imagine that you have multiple instantiations of the entity/module
> containing the multipler.
> 
> 
> spyng wrote:
> 
> > hi,
> > I have try syn_multstyle both in the verilog code and in the sdc
> > constraint file.
> > 
> > although, in the *.srr log file it did show that property is added,
> > but both in the gate level netlist *.srm and the edf the mult18*18 is
> > still there. any one know is there a bug with the syn_multstyle?
> > 
> > in the *.sdc
> > define_attribute          {*mult_26bitx4bit_3.I_1*} syn_multstyle
> > {logic}
> > 
> > in the *.srr
> > Adding property syn_multstyle, value "logic", to instance
> > mult_26bitx4bit_3.I_1
> > 
> > in the *.edf
> > (instance (rename mult_26bitx4bit_3_I_1 "mult_26bitx4bit_3.I_1")
> > (viewRef PRIM (cellRef MULT18X18 (libraryRef VIRTEX)))
> > 
> > any help?
> > spyng
> > thanks
> > 
> > 
> > 
> > 
> > 
> > 
> > sunny <sunshine@sunrise.at> wrote in message news:<ee75cf4.0@WebX.sUN8CHnE>...
> > 
> >>u could use the synplify attribute
> >>syn_multstyle = logic. This would prevent Synplify of using the 18x18 multiplier. Information will be forward annotated to ISE thru the ncf.
> >>

Article: 41471
Subject: Re: Homebuilt Altera-programmer totally dead...
From: "Alexander Miks" <monstrum@tiscali.se>
Date: Fri, 29 Mar 2002 14:36:40 +0100
Links: << >>  << T >>  << A >>
Thanks for the answear,
I found out that the error was a glitch in the DSUB and a broken pin on the
PLCC socket (bad luck that this pin was one of the JTAG-pins).
But I think I fried my EPM7064S when testing. I hooked it up as a simple
T-flip-flop, with one input and one output. The output connected to a LED
(through a resistor), and the input to a cable floating in the air (I know
that's NOT the way to go...). I then powered it up and toggled the
input-cable between ground and vcc. Wow, it worked... But I almost got a
chock when touching the chip, it was smoking hot! After that the chip
"works" but programmer gets no contact... Do you need a current-limiting
resistor on the input or what did I do wrong?

"Tuomo Auer" <tuomo.auer@removethis.hut.fi> skrev i meddelandet
news:a81k8m$pnr$1@tron.sci.fi...
> Power your home-build ByteBlaster using 5V or 3V3 power supply (not
> connected to computer or FPGA). Then feed to inputs (both computer side
and
> FPGA side) GND and VCC and check with multimeter that the other side of
> 74HC244 responds properly.
>
> If possible, test also with genuine ByteBlasterMV that settings of your
> software are correct and test that you don't have a dead FPGA (they are
> static sensitive devices. Have separate ground wire connected between
> computer and FPGA-ground when using ByteBlaster).
>
> --
> Tuomo Auer
>
>



Article: 41472
Subject: Where to get MAX7000S
From: "Alexander Miks" <monstrum@tiscali.se>
Date: Fri, 29 Mar 2002 14:42:45 +0100
Links: << >>  << T >>  << A >>
Where can I get the MAX7000S-series of chips in Sweden. Do you know of any
place shipping devices over here. I know a place here in Sweden, but they
only have the 7064S.



Article: 41473
Subject: Re: Homebuilt Altera-programmer totally dead...
From: "Tuomo Auer" <tuomo.auer@removethis.hut.fi>
Date: Fri, 29 Mar 2002 16:37:05 +0200
Links: << >>  << T >>  << A >>
Check unused pins. As a default these pins are configures as outputs, so
they must not be connected to GND or VCC but must be left open. You can
check yhis out from the report file. Dedicated inputs instead mus be
connected to known logic state (not to be left floating).

--
Tuomo Auer



Article: 41474
Subject: Re: Homebuilt Altera-programmer totally dead...
From: c_oflynn@yahoo.com (Colin O'Flynn)
Date: 29 Mar 2002 06:55:39 -0800
Links: << >>  << T >>  << A >>
Hi,

Also check that the computer's parallel port is okay! It could be
misconfigured, try the cable on a different computer. Also I think
that the cable is dumb. It doesn't have a micrcontroller on it, so the
software has no way of checking if the cable is working without being
connected to the target.
     
    -Colin

"Tuomo Auer" <tuomo.auer@removethis.hut.fi> wrote in message news:<a81k8m$pnr$1@tron.sci.fi>...
> Power your home-build ByteBlaster using 5V or 3V3 power supply (not
> connected to computer or FPGA). Then feed to inputs (both computer side and
> FPGA side) GND and VCC and check with multimeter that the other side of
> 74HC244 responds properly.
> 
> If possible, test also with genuine ByteBlasterMV that settings of your
> software are correct and test that you don't have a dead FPGA (they are
> static sensitive devices. Have separate ground wire connected between
> computer and FPGA-ground when using ByteBlaster).



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