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

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

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

Custom Search

Messages from 21900

Article: 21900
Subject: Power up set
From: Jamil Khatib <khatib@ieee.org>
Date: Thu, 06 Apr 2000 11:17:34 +0200
Links: << >>  << T >>  << A >>
Hi,
I'd like to ask about setting a register upon power up to 1.
Also I want that register to be reserve its value upon system reset.

How can I do this operation from the logic design point of view and how
to code it in VHDL

Thanks

Jamil Khatib

Article: 21901
Subject: Re: JBits
From: "Craig Slorach" <craigs@elec.gla.ac.uk>
Date: Thu, 6 Apr 2000 10:32:56 +0100
Links: << >>  << T >>  << A >>
If you e-mail JBits@xilinx.com then you should get more details.

"Anshuman Sharma" <gte600f@prism.gatech.edu> wrote in message
news:8cgmch$kd0@catapult.gatech.edu...
>
> does anyone know where I can get a copy of JBits?
>



Article: 21902
Subject: Warnings during mapping
From: "Tomasz Brychcy" <tbrychcy@sensor.ime.pz.zgora.pl>
Date: Thu, 6 Apr 2000 12:00:44 +0200
Links: << >>  << T >>  << A >>
Hello,

Is these warnings are valid:
WARNING:OldMap:78 - All of the external outputs in this design are using
   slew-rate-limited output drivers.  The delay on speed critical outputs
can be
   dramatically reduced by designating them as fast outputs in the original
   design.  Please see your vendor interface documentation for specific
   information on how to do this within your design-entry tool.
   Note: You should be careful not to designate too many outputs which
switch
   together as fast, because this can cause excessive ground bounce.  For
more
   information on this subject, please refer to the IOB switching
characteristic
   guidelines for the device you are using in the Programmable Logic Data
Book.
WARNING:OldMap:548 - All the logic for "HMAP symbol "HMAP_275" (output
   signal=syn15941)" has been removed!  This may be caused by key logic
being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_69" (output
   signal=syn1528)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_68" (output
   signal=syn1778)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_67" (output
   signal=C81_N3)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_66" (output
   signal=C82_N6)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_277" (output
   signal=syn15940)" has been removed!  This may be caused by key logic
being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_276" (output
   signal=syn16584)" has been removed!  This may be caused by key logic
being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_274" (output
   signal=cell59)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_254" (output
   signal=syn1508)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_225" (output
   signal=syn16245)" has been removed!  This may be caused by key logic
being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.
WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_153" (output
   signal=syn1553)" has been removed!  This may be caused by key logic being
   trimmed.  Please consult the Removed Logic section of this report to see
if
   this is the case.

And what mean this section:

Primitive reference count:
--------------------------
BUFG          1
CY4           9
CY4_25        7
CY4_27        1
CY4_42        1
DFF          23
FMAP        288
HMAP         41
IBUF         23
IFD           1
OFDX          1

With regards

Tomek

I request for reply on my e:mail:
----------------------------------
Tomasz Brychcy
tbrychcy@sensor.ime.pz.zgora.pl
----------------------------------




Article: 21903
Subject: Re: JTAG programming
From: "Jean-Paul GOGLIO" <goglio@getris.com>
Date: Thu, 6 Apr 2000 12:12:24 +0200
Links: << >>  << T >>  << A >>

rob_dickinson@my-deja.com wrote in message <8chjnj$6mu$1@nnrp1.deja.com>...

>I have to disagree completely with this.  The jtag spec was defined to
>allow anything to be put on the chain by anyone.  A decent tool
>(software) will find out how many devices are on the chain and their
>manufacturers id and how "long" each device is.  Its fairly
>straightforward to make a device on the chain transparent (via
>software), allowing debuggers (for instance) to get to one device
>without having to keep clocking data through an enormous shift register
>(the other devices).  I am fairly certain that the AD debugger turns
>off the other SHARCS in the chain to debug the SHARC of interest.
>
>I  "watched" a software engineer doing boundary scan with tcl about 3
>years ago and I simply remember a passing comment that AD had not quite
>kept to the letter of the JTAG spec in terms of the id it returns. I
>used the same JTAG path to just ISP the machs and the SHARCS ( and some
>JTAG quickswitches etc) got "out of the way" just fine.
>
>My original post said that the SHARC "hardware implementation is
>correct" as the original guy was questioning his hardware.  I expect
>that the XILINX jtag kit can't quite cope with the SHARC which has bent
>the JTAG rules, allthough MACHPRO (the mach JTAG ISP software) could.
>
>Rob



I just said that i "believed" that it was a software problem, in fact, i'm
not sure of this.
As we found a simple solution, (splitting the chain), and as it was
difficult to get a good support about this problem (for Xilinx the problem
is due to AD and for AD it's due to Xilinx ;-)) ) we didn't investigate too
far.



J-P GOGLIO
GETRIS S.A.
13 Chemin des Prés
38240 Meylan
Tel : (33) 4 76 18 52 10
E-mail : goglio@getris.com
Fax : (33) 4 76 18 52 01



Article: 21904
Subject: Re: JTAG programming
From: "Grzegorz" <g_lis@microtech.com.pl>
Date: Thu, 06 Apr 2000 10:18:23 GMT
Links: << >>  << T >>  << A >>
Spliting the chain worked in my case as well. Thanks.

G.


Article: 21905
Subject: Re: JTAG programming
From: Magnus Homann <d0asta@licia.dtek.chalmers.se>
Date: 06 Apr 2000 14:22:44 +0200
Links: << >>  << T >>  << A >>
rob_dickinson@my-deja.com writes:

> I have to disagree completely with this.  The jtag spec was defined to
> allow anything to be put on the chain by anyone.  A decent tool
> (software) will find out how many devices are on the chain and their
> manufacturers id and how "long" each device is.  Its fairly
> straightforward to make a device on the chain transparent (via
> software), allowing debuggers (for instance) to get to one device
> without having to keep clocking data through an enormous shift register
> (the other devices).  I am fairly certain that the AD debugger turns
> off the other SHARCS in the chain to debug the SHARC of interest.

The PowerPC debugger RiscWath requires the PowerPC to be alone in the
JTAG chain. Quite stupid.

Homann
-- 
Magnus Homann, M.Sc. CS & E
d0asta@dtek.chalmers.se
Article: 21906
Subject: Re: JTAG programming
From: Etienne Racine <etienne@cae.ca>
Date: Thu, 06 Apr 2000 08:37:40 -0400
Links: << >>  << T >>  << A >>
Hello Grzegorz,

Grzegorz wrote:

> I've got six devices in JTAG chain. 3 x Xilinx XLA 4000 series, AMD DSP
> proc, 2x Xilinx 9500 series.
> Everything looks OK, init is low, bsd files are correct and I get such an
> error:

<snip snip>

> Did anyone see such a problem? What it could be ?
> Another thing is:  what else could I do to narrow the problem down ?

I have used JTAG Programmer with other components than those from Xilinx, and I
haven't encountered problems yet. The key is to make sure the BSDL files are OK
(and often they're not) and will be understood correctly by the software. Before
executing any JTAG-related instruction, the software must parse the BSDL file
and find out how to place third-party devices in BYPASS.

I have no experience with the mentioned DSPs, but I took the liberty of looking
at the BSDL file of an ADSP-21160 and I found out that it lacks the "attribute
REGISTER_ACCESS of <component>" statement, because all its publicly-accessible
instructions are instructions that have target register *implicitly* defined by
the standard (and that's permitted).

Since all Xilinx components have the REGISTER_ACCESS statement in their BSDL
files and since they even define target registers for the standard instructions,
it is possible that JTAG Programmer expects to find this keyword.

I would thus suggest to add the following text at its appropriate location (that
is, just before the BOUNDARY_LENGTH attribute):

attribute REGISTER_ACCESS of <DSP_component_name_goes_here> : entity is
 "BYPASS (BYPASS)," &
 "BOUNDARY (SAMPLE,EXTEST,INTEST)";

Also, I am not sure that the following BSDL statement is valid:

attribute BOUNDARY_CELLS of ADSP_21160:  entity is
"BC_1, BC_2, BC_3, BC_4";
-- BC_1: output, control; BC_2: input; BC_3: internal; BC_4: clock;

Which may be present in *your* BSDL file (it is in the BSDL for the 21160);
since it may confuse the software, I would suggest to delete it. Then save the
modified BSDL under another name, tell JTAG Programmer to use it instead and see
if it loads/executes correctly.

Hope it helps,

Étienne.
--
      ______ ______
*****/ ____// _  \_\*************************************************
*   / /_/_ / /_/ / /       Etienne Racine, Hardware Designer        *
*  / ____// __  /_/           Visual Systems Engineering            *
* / /_/_ / / /\ \ \              CAE Electronics Ltd.               *
*/_____//_/_/**\_\_\*************************************************


Article: 21907
Subject: Re: Memory cores
From: Ray Andraka <randraka@ids.net>
Date: Thu, 06 Apr 2000 12:51:31 GMT
Links: << >>  << T >>  << A >>
You can parse and edit the INIT= strings in the EDIF file if you feel adventurous.  I
haven't done it thru the edif, but I had done that thru the old XNF format.  In that
case it was to initialize a bunch of LFSR counters with unique values.  They were
implemented in LUT RAM in a 4K device.  It wasn't that hard to do.  I think the EDIF
would be perhaps a little harder, but not much.  You could probably write a perl script
to do it.

Janos Ero wrote:

> Ray Andraka wrote:
> >
> > You need to get the data into the VHDL one way or another.
> <snip>
> > library ieee;
> > use ieee.std_logic_1164.all;
> > package parameters is
> >     type TABLE_TYPE is array (NATURAL range <>) of integer;
> >     constant EXP_LUT: TABLE_TYPE:= (
> >   5918491, 5721208, 5523925, 5326641, 5129358, 4932075, 4734792, 4537509,  --  0:7
>
> Hm, actually I wanted to avoid exactly this.
> This means I have to reformat all my LUTs
> and they are numerous :-(
>
> For me an ideal solution would be to open
> "empty" ROMs and fill them at fitting, as
> it happens when developing in the AHDL way.
>
> Thanks for the hints.
>
> Janos Ero

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21908
Subject: Re: JTAG programming
From: Ray Andraka <randraka@ids.net>
Date: Thu, 06 Apr 2000 12:53:30 GMT
Links: << >>  << T >>  << A >>
So does the Raven Wiggler.  We had to resort to separate chains on a recent
project as well.

Magnus Homann wrote:

> rob_dickinson@my-deja.com writes:
>
> > I have to disagree completely with this.  The jtag spec was defined to
> > allow anything to be put on the chain by anyone.  A decent tool
> > (software) will find out how many devices are on the chain and their
> > manufacturers id and how "long" each device is.  Its fairly
> > straightforward to make a device on the chain transparent (via
> > software), allowing debuggers (for instance) to get to one device
> > without having to keep clocking data through an enormous shift register
> > (the other devices).  I am fairly certain that the AD debugger turns
> > off the other SHARCS in the chain to debug the SHARC of interest.
>
> The PowerPC debugger RiscWath requires the PowerPC to be alone in the
> JTAG chain. Quite stupid.
>
> Homann
> --
> Magnus Homann, M.Sc. CS & E
> d0asta@dtek.chalmers.se

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21909
Subject: Re: Spartan on chip oscillator
From: Ray Andraka <randraka@ids.net>
Date: Thu, 06 Apr 2000 12:55:42 GMT
Links: << >>  << T >>  << A >>
Nope,  It's not only temp dependent, it is also process and voltage
dependant.  It's main function is to provide the internally generated
configuration clock.  They were just nice enough to make it available for a
cheap and dirty logic clock too.

bjorn_lindegren@my-deja.com wrote:

> Using Spartan XCS10-PC84, when I read the manual for this FPGA, I found
> that the on chip oscillator falls between 10 Mhz and 4 Mhz.
>
> I want to use this oscillator to determine a frequens, and I need a
> constant oscillator. Is it possible to use this on chip oscillator in a
> lower mode or do I have to use an extern oscillator.
>
> In other words, is it possible to do the on chip oscillator temperatur
> undependent?
>
> Thankful for help
>
> Björn Lindegren
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21910
Subject: Re: Warnings during mapping
From: Ray Andraka <randraka@ids.net>
Date: Thu, 06 Apr 2000 13:12:08 GMT
Links: << >>  << T >>  << A >>


Tomasz Brychcy wrote:

> Hello,
>
> Is these warnings are valid:
> WARNING:OldMap:78 - All of the external outputs in this design are using
>    slew-rate-limited output drivers.  The delay on speed critical outputs
> can be
>    dramatically reduced by designating them as fast outputs in the original
>    design.  Please see your vendor interface documentation for specific
>    information on how to do this within your design-entry tool.
>    Note: You should be careful not to designate too many outputs which
> switch
>    together as fast, because this can cause excessive ground bounce.  For
> more
>    information on this subject, please refer to the IOB switching
> characteristic
>    guidelines for the device you are using in the Programmable Logic Data
> Book.

This one just means that you used the default slow IO, which is often fine.
Depends on your application.


Part of your design got optimized out.  It looks like it is a floorplanned
design, and seeing that you are not familiar with the warning messages, I
guessing that these are not your floorplanning, rather it is part of a logic
core.  These warnings indicate that the mapper optimized out part of your
logic.  In this case, it looks like all that was removed are the floorplanning
components which tell how the design is to be mapped into LUTs.  Most likely,
one or more of the inputs to these LUTs was tied to VCC or GND in your design.
The mapper optimizes the design by removing unused outputs, combining CLBs that
are not FMAP'd, absorbing inverters and buffers and removing grounded/pulled up
inputs to logic.
THere is another section of the map report that will tell you what logic got
optimized, from there you can figure out what got stripped out.

>
> WARNING:OldMap:548 - All the logic for "HMAP symbol "HMAP_275" (output
>    signal=syn15941)" has been removed!  This may be caused by key logic
> being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_69" (output
>    signal=syn1528)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_68" (output
>    signal=syn1778)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_67" (output
>    signal=C81_N3)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_66" (output
>    signal=C82_N6)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_277" (output
>    signal=syn15940)" has been removed!  This may be caused by key logic
> being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_276" (output
>    signal=syn16584)" has been removed!  This may be caused by key logic
> being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_274" (output
>    signal=cell59)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_254" (output
>    signal=syn1508)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_225" (output
>    signal=syn16245)" has been removed!  This may be caused by key logic
> being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
> WARNING:OldMap:548 - All the logic for "FMAP symbol "FMAP_153" (output
>    signal=syn1553)" has been removed!  This may be caused by key logic being
>    trimmed.  Please consult the Removed Logic section of this report to see
> if
>    this is the case.
>
> And what mean this section:

This section tells you what logic is in the mapped design

>
>
> Primitive reference count:
> --------------------------
> BUFG          1            -1 global clock buffer
> CY4           9             -9 carry logic primitives
> CY4_25        7            -these are the carry logic control primitives, one
> per CY4.  42 is the msb "examine".
> CY4_27        1                i don't recall off the top of my head what 27
> and 25 are: I think they may be decrements.  27
> CY4_42        1                is the one for the lsb, and 25 is probably
> FG-CI meaning it is two bits with carry in
> DFF          23            --23 D flip-flops
> FMAP        288        -288  F/G  4 input generators
> HMAP         41        -41 H   3 input generators
> IBUF         23           -23 input pins (not registered)
> IFD           1            -1 registered input
> OFDX          1        -1 registered tristate output
>
> With regards
>
> Tomek
>
> I request for reply on my e:mail:
> ----------------------------------
> Tomasz Brychcy
> tbrychcy@sensor.ime.pz.zgora.pl
> ----------------------------------

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21911
Subject: Re: CoreGen incompatible with NT SP6 and Win2K?
From: "Amal Khailtash" <akhailtash@spacebridge.com>
Date: Thu, 06 Apr 2000 13:20:04 GMT
Links: << >>  << T >>  << A >>
I have Win/NT 4 with service pack 6a and have no problem running
CoreGen!

+------------------------------Disclaimer------------------------------+
|    This message is my personal opinion and does not represent        |
|        the position of SpaceBridge Networks Corporation.             |
+-----------------------------------+----------------------------------+
| Name:  Amal Khailtash             | Co.: SpaceBridge Networks Corp.  |
| Title: Hardware Developer         |    (A Com Dev/NewBridge Company) |
| Email: akhailtash@spacebridge.com | Tel: +1 (819) 776-5664 x.6183    |
| URL:   http://www.spacebridge.com |      +1 (819) 776-2848 x.6183    |
| Addr.: 115 Champlain Street       | Fax: +1 (819) 776-4179           |
|        Hull, PQ J8X 3R1, Canada   |                                  |
+-----------------------------------+----------------------------------+


Steve <reply.through.newsgroup@paranoid.com> wrote in message
news:pB8E4.41100$pA.126638@typhoon.mbnet.mb.ca...
> I have recently tried coregen for the first time, and keep getting
> java errors and internal errors.  I tried on 2 NT SP6 machines
> and one Windows 2000 machine.
>
> I've just been told that there might be a problem with SP6.
> Has anyone else seen this?
>
>
> Steve
>
>
>


Article: 21912
Subject: FPGA Openness/ Summary
From: seamang@westminster.ac.uk (Graham Seaman)
Date: 6 Apr 2000 14:29:40 GMT
Links: << >>  << T >>  << A >>
After the recent thread on FPGA openness (ie. the bitstream formats)
I decided to put together a more permanent summary before the
thread vanished from newservers.
You can see it at: http://collector.hscs.wmin.ac.uk/news/
It's a biased summary, in the sense that I agree with the
'bitstream should be open' side of the argument. But I've
tried to be careful not to quote the people on the other side
of the argument out of context. If anyone does feel I've misrepresented
them by taking statements out of context, let me know.

Graham
Article: 21913
Subject: Re: Power up set
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Thu, 6 Apr 2000 09:41:46 -0700
Links: << >>  << T >>  << A >>
Jamil Khatib wrote in message <38EC562E.92160F8F@ieee.org>...
>Hi,
>I'd like to ask about setting a register upon power up to 1.
>
>How can I do this operation from the logic design point of view and how
>to code it in VHDL

Power-on set? How about:

    reg : process (clk, reset) is
    begin
        if reset = '1' then
            q <= '1';
        elsif rising_edge(clk) then
            q <= d;
        end if;
    end process reg;

>Also I want that register to be reserve its value upon system reset.

I'm not sure what you mean by this ...


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

"Money is property; it is not speech."
            -- Justice John Paul Stevens



Article: 21914
Subject: Re: JTAG programming
From: "Joel Kolstad" <Joel.Kolstad@USA.Net>
Date: Thu, 6 Apr 2000 10:35:40 -0700
Links: << >>  << T >>  << A >>
Speaking of  JTAG problems...

We have a board with a Xilinx XCV400 and an Altera 7064.  The Altera JTAG
programming software is unable to program the '7064 unless a configuration
bitstream has already been loaded into the XCV400 (which we normally do
using serial configuration mode indirectly over a PCI bus).  The XCV400 sits
there with its TDO pin "stuck high," it appears, until it's configured.

This isn't really a problem for us, but I'm curious if anyone knows off-hand
what might be causing it.

We have another board that has a TI 'C549 DSP, Vantis Mach111SP, Altera
7032, and Cypress 37128 all in the same JTAG chain.  All the vendors'
software was able to successfully place every other vendor's part into
bypass mode.  I was impressed.

---Joel Kolstad


Article: 21915
Subject: Re: JTAG programming
From: Etienne Racine <etienne@cae.ca>
Date: Thu, 06 Apr 2000 13:57:25 -0400
Links: << >>  << T >>  << A >>
Hi Joel,

Joel Kolstad wrote:

> We have a board with a Xilinx XCV400 and an Altera 7064.  The Altera JTAG
> programming software is unable to program the '7064 unless a configuration
> bitstream has already been loaded into the XCV400 (which we normally do
> using serial configuration mode indirectly over a PCI bus).  The XCV400 sits
> there with its TDO pin "stuck high," it appears, until it's configured.

Could it be that the PROG* pin is left low until you're ready to program the
XCV400? In its Virtex BSDLs, Xilinx says:

-- The boundary scan test vectors must keep the PROGRAM_B pin
-- either 3-stated or driving high. If the PROGRAM_B pin is
-- driven low through any means, the TAP controller will reset.

And of course, you *don't* want to reset the TAP state machine (I suppose it's
asynchronous).

Étienne.
--
      ______ ______
*****/ ____// _  \_\*************************************************
*   / /_/_ / /_/ / /       Etienne Racine, Hardware Designer        *
*  / ____// __  /_/           Visual Systems Engineering            *
* / /_/_ / / /\ \ \              CAE Electronics Ltd.               *
*/_____//_/_/**\_\_\*************************************************


Article: 21916
Subject: SpartanII BSDL file/JTAG Pgmr
From: grantb@ecn.ab.ca ()
Date: 6 Apr 2000 11:01:36 -0700
Links: << >>  << T >>  << A >>
Hi,

I'm trying to take a completed .BIT file and, using JTAG Programmer,
create an .SVF file.  JTAG Programmer complains about no BSDL file for the
Spartan II device (I'm using an XC2S100PQ208).  Does anyone have a set of
BSDL files for these new devices???

Also, for the same reason, I cannot use JTAG programmer with the Parallel
III cable to program my part over JTAG.

My main objective is to create an SVF file and then a XSVF file so that I
can configure the SPartan II device as described in XAPP058 (via a
microcontroller).

All help appreciated,
GB

Article: 21917
Subject: Re: PCI Bridge to Xilinx XCV*E
From: "John L. Smith" <jsmith@visicom.com>
Date: Thu, 06 Apr 2000 11:42:50 -0700
Links: << >>  << T >>  << A >>
This is a multi-part message in MIME format.
--------------F78CED9B4A4390364724FAD9
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Keith R. Williams" wrote:
> 
> On Wed, 5 Apr 2000 14:20:49, Utku Ozcan <ozcan@netas.com.tr>
> wrote:
> 
> > Can you recommend any bridge through which Motorola's
> > 860 or 8240 processors can control XCV*E FPGAs? There
> > will be many Virtex-E devices on the board, like 10.
> > FPGA's CPU Interface will communicate to this Bridge.
> > Or is there any better newsgroup to direct this q?
> 
> I'm using the PLX PCI9054.  It is a full PCI master and quite
> cheap (well compared to a Virtex-E).  I think the boss paid about
> $30 for the BG256 part in small quantities.
[snip]
> I wouldn't bother using a PCI core on an expensive part like the
> Virtex-E.  I started down this road (not with Xilinx) and it was
> a huge mistake.

Agreed, the FPGA real-estate is too valuable to waste on PCI,
unless board space is even more valuable.

I don't know how well it plays with the PPC, but I'm using the
Intel i960VH I/O processor in my current design. The part is
~$6, but requires RAM as well. It is useful to have a medium
performance processor to handle control functions associated
with moving data over PCI bus, although must now write i960 code.
--------------F78CED9B4A4390364724FAD9
Content-Type: text/x-vcard; charset=us-ascii;
 name="jsmith.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for John L. Smith
Content-Disposition: attachment;
 filename="jsmith.vcf"

begin:vcard 
n:Smith;John L.
tel;work:858-320-4102
x-mozilla-html:FALSE
url:http://www.visicom.com
org:Visicom;Imaging Products
adr:;;10052 Mesa Ridge Court;San Diego;CA;92121;USA
version:2.1
email;internet:jsmith@visicom.com
title:Principal Engineer
x-mozilla-cpt:;30864
fn:John L. Smith
end:vcard

--------------F78CED9B4A4390364724FAD9--

Article: 21918
Subject: Re: FPGA Openness/ Summary
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Thu, 06 Apr 2000 16:36:00 -0700
Links: << >>  << T >>  << A >>
Nice job on the summary! Also on the rest of the site news
 - very good open tech coverage.

regards, tom 

Graham Seaman wrote:
> 
> After the recent thread on FPGA openness (ie. the bitstream formats)
> I decided to put together a more permanent summary before the
> thread vanished from newservers.
> You can see it at: http://collector.hscs.wmin.ac.uk/news/

-- 
Tom Burgess
-- 
Digital Engineer
Dominion Radio Astrophysical Observatory
P.O. Box 248, Penticton, B.C.
Canada V2A 6K3
Email:        tom.burgess@hia.nrc.ca
Article: 21919
Subject: Re: Altering Xilinx FPGA version/ID after PAR
From: Robert Binkley <robert.binkley@xilinx.com>
Date: Thu, 06 Apr 2000 17:20:14 -0700
Links: << >>  << T >>  << A >>
Hi Jaime,

Have you considered the userid register in the Virtex/Spartan-II devices?  It is
a dedicated 32 bit register accessible via the JTAG TAP and the value is set at
bitgen (the final step in implementation).  It would be possible to write a
script to automatically calculate a value to be placed in that register by
invoking bitgen with the request.

More information about this register can be found in xapp139.
http://support.xilinx.com/xapp/xapp139.pdf
or by typing bitgen -help virtex at the command line.

Robert Binkley
Xilinx Applications

Jamie Sanderson wrote:

> I just wanted to thank everyone for the helpful suggestions. What I'm
> hearing doesn't particularly fill me with hope, but they are good solutions
> nonetheless. My next move will be to contact Xilinx and see whether or not
> they wouldn't be willing to give the problem to one of their people. I'll be
> sure to post my progress here.
>
> Best regards,
> Jamie
>
> <eml@riverside-machines.com.NOSPAM> wrote in message
> news:38dc9056.269070770@news.dial.pipex.com...
> > I'd like to do this as well, so it would be interesting to hear how
> > you get on. I can't see that you'll get the GUI version/revision info
> > though, since this is just private to the GUI. Why don't you just
> > maintain a revision register in your device? Your problem then is just
> > identifying this register, or the serial number register, in the
> > bitfile.
> >
> > I haven't looked at Jbits but, if it doesn't do the job, this
> > procedure might work. Have a 16-bit revision number implemented as a
> > CLB ROM element, and locate this ROM at a known CLB location. Generate
> > an 'll' file from Bitgen ('-l' option). Search the ll file for lines
> > containing your known CLB location (the ll format is documented in the
> > file). This will give you the bit number, frame number, and frame
> > offset for all 16 bits in your ID. The trick now is to identify these
> > bits in your bitfile; see xapps 138 and/or 151.
> >
> > As an aside, this is what I do to get around the Xilinx GUI
> > revision/version structure. My rebuild makefile always builds in a
> > fixed directory (xproj/current in my setup), and you rely on a source
> > control system to retrieve the important files (only) from previous
> > builds. You then don't need multiple directories to keep a huge amount
> > of redundant information.
> >
> > Evan
> >

Article: 21920
Subject: Re: FPGA Openness/ Summary
From: Ray Andraka <randraka@ids.net>
Date: Fri, 07 Apr 2000 00:49:22 GMT
Links: << >>  << T >>  << A >>
Nice summary.

One nit on your conclusion though,  You mention that several tools generate
the XNF format, which is true enough.   What is implied though is that that
gets you closer to the bitstream.  XNF is the netlist that goes into the
front end of the tool- it is basically a textual netlist of your schematic
or HDL design.  In the M1 and M2 tools, EDIF format is preferred by xilinx,
and they've made noises about getting rid of XNF altogether (which us users
have asked them not to do).  As I mentioned fairly early in the thread, you
can get pretty detailed in your description of the design at the XNF level
in that you can direct placement as well as lock the pins on the CLBs to
force a particular routing.  The fact is though, that XNF is the file
format to get into the front end of the tools, not a shortcut to the
backend.

Graham Seaman wrote:

> After the recent thread on FPGA openness (ie. the bitstream formats)
> I decided to put together a more permanent summary before the
> thread vanished from newservers.
> You can see it at: http://collector.hscs.wmin.ac.uk/news/
> It's a biased summary, in the sense that I agree with the
> 'bitstream should be open' side of the argument. But I've
> tried to be careful not to quote the people on the other side
> of the argument out of context. If anyone does feel I've misrepresented
> them by taking statements out of context, let me know.
>
> Graham

--
-Ray Andraka, P.E.
President, the Andraka Consulting Group, Inc.
401/884-7930     Fax 401/884-7950
email randraka@ids.net
http://users.ids.net/~randraka


Article: 21921
Subject: Re: PCI Bridge to Xilinx XCV*E
From: krw@attglobal.net (Keith R. Williams)
Date: 7 Apr 2000 02:42:53 GMT
Links: << >>  << T >>  << A >>
On Thu, 6 Apr 2000 18:42:50, "John L. Smith" <jsmith@visicom.com>
wrote:

> This is a multi-part message in MIME format.
> "Keith R. Williams" wrote:

> > I'm using the PLX PCI9054.  It is a full PCI master and quite
> > cheap (well compared to a Virtex-E).  I think the boss paid about
> > $30 for the BG256 part in small quantities.
> [snip]
> > I wouldn't bother using a PCI core on an expensive part like the
> > Virtex-E.  I started down this road (not with Xilinx) and it was
> > a huge mistake.
> 
> Agreed, the FPGA real-estate is too valuable to waste on PCI,
> unless board space is even more valuable.
> 
> I don't know how well it plays with the PPC, but I'm using the
> Intel i960VH I/O processor in my current design. The part is
> ~$6, but requires RAM as well. It is useful to have a medium
> performance processor to handle control functions associated
> with moving data over PCI bus, although must now write i960 code.

Actually I have *SNAIL* running the card. The processor running 
the card is an *OLD* Intel 8051 variant (12MHz and 12 cycles per 
instruction).  The PPC is only there because it is the whole 
point of the project.  ;-)  Note that I'm not using a Virtex-E 
for an 8051.  There is also a bunch of 2.5ns DDR SRAM on the 
card.

Even though I'm not using the features, the PLX chips are very 
PPC friendly.  As I said, the IOP480 has a PPC 503(I think) built
in. The PCI9054 has a PPC860 mode.

In any case, I cannot see any reason to use prime Virtex space 
for PCI.  I went down this road and got burned big time.  BTW. 
the $30 price on the PLX chip was for one (ok, twenty) BGA256.  
Next to the grand+ the Virtex costs, I could care less.

----
  Keith 

Article: 21922
Subject: Re: PCI Bridge to Xilinx XCV*E
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Fri, 07 Apr 2000 08:35:52 +0300
Links: << >>  << T >>  << A >>
Sorry for the mistake in my very first mail. Actually on the
  board there will be BOTH the 860 and 8240 processors.

  The reason why we have chosen both of these is backward
  compatibility. That Virtex-E devices don't have PCI interfaces
  at a first glance is also because of backward compatibility.

  Keith, thank you very much for the site you have given me.

  But although the backward compatibility makes our mind busy,
  PCI core also seems to be attractive. We are paying attention
  to experiences around.

  Utku

-- 
I feel better than James Brown.
Article: 21923
Subject: EHW
From: Anshuman Sharma <gte600f@prism.gatech.edu>
Date: 7 Apr 2000 06:16:56 GMT
Links: << >>  << T >>  << A >>

can anyone guide me to the EHW conference website?

-- 
---------------------------------------------------
"time and space are modes by which we think...... |
they are not the conditions in which we live."    |
                                                  |
   ~~Einstein                                     |       
---------------------------------------------------


Anshuman Sharma
Georgia Institute of Technology, Atlanta Georgia, 30332
Email: gte600f@prism.gatech.edu
       anshu@abraxis.com

Article: 21924
Subject: Re: Power up set
From: Klaus Falser <kfalser@durst.it>
Date: Fri, 07 Apr 2000 07:07:43 GMT
Links: << >>  << T >>  << A >>
In article <38EC562E.92160F8F@ieee.org>,
  khatib@ieee.org wrote:
> Hi,
> I'd like to ask about setting a register upon power up to 1.
> Also I want that register to be reserve its value upon system reset.
>
> How can I do this operation from the logic design point of view and
how
> to code it in VHDL
>
> Thanks
>
> Jamil Khatib
>
>

If I understand you correctly you want a FF which on power on starts
with in a defined state, but is not affected by subsequent reset's.

This is not possible with every device.
One family where it will work is the XC9500 from Xilinx, since they
are FlashROM based and initialize at power on.

You can specify an initial value in the UCF file.
If you can do this from VHDL depends on your compiler.
Generally initial values are ignored by synthesis. You have to specify
an INIT attibute for the signal, and the compiler will pass this
information to the fitter.

To ignore the systems reset simply do not connect this to the FF.

In principle this should alos work for a SRAM based device, but it
depends if it is reinitialized (reloaded from PROM) on a reset.


Hope this helps

--
Klaus Falser
Durst Phototechnik AG
I-39042 Brixen


Sent via Deja.com http://www.deja.com/
Before you buy.


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

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

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

Custom Search