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 21425

Article: 21425
Subject: Re: Clock nets using non-dedicated resources
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Mar 2000 09:30:55 -0500
Links: << >>  << T >>  << A >>
boniolopez@my-deja.com wrote:
> 
> Thank you for good advice, yasui149
> I have found the strange message in the .mrp file section 2.
> 
> WARNING:xvkpu:22 - The function generator
>    inst_c68mx11/I_I_mpu0.s1[15].G_31.G_44 failed to merge with F5
> multiplexer
>    inst_c68mx11/mpu0/s_o[15].  There is a conflict for the FXMUX.  The
> design
>    will exhibit suboptimal
> 
> The net is situated inside the CPU core, I use.
> Do you think this net cause the non-dedicated clock?. Can you explain
> me why could be this conflict.
> 
> Thank you once more,
> Bonio
> remove_this_bonio.lopez@gmx.ch_remove_this
> 
> In article <8b9oog$bq3$1@lyra.eoa.telcom.oki.co.jp>,
> =?iso-2022-jp?B?GyRCMEIwZhsoQiAbJEI3chsoQg==?= <yasui149@oki.co.jp>
> wrote:
> > I think you should check the Map report file (.mrp) .
> > Section 2 describes gated clock name. and search that net in Section
> 8. load
> > and driver component of that net will be found.
> >
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.

I don't think this message is related to a clock problem. This message
is telling you that the F5 mux did not get placed in the same CLB as the
F or G that should be connected to the F5 mux input. I don't know all of
the limitations of using the F5 mux, but something was already being
used that prevented putting the F5 mux in this CLB. Try looking at it in
the chip editor. 

This error came from the placement tools. The clock net you are looking
for is coming from a synthesis tool and will appear earlier than
placement. Not that that will help you find it. But the message before
yours seems to indicate how to find the clock nets in the map report. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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

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

Internet URL http://www.arius.com
Article: 21426
Subject: constant error in VHDL code
From: e97bjli@thn.htu.se
Date: Wed, 22 Mar 2000 15:01:31 GMT
Links: << >>  << T >>  << A >>
Hi

Designing a butterworth filter in VHDL.
When I trie to scale a std_logic_vector I recive an error.

utsignal<=1.9425*utsignal1-0.9806*utsignal2+0.0097*insignal-
0.0097*insignal2;

Some thing is wrong with this row.



My code:

library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.std_logic_unsigned.all;
use IEEE.std_logic_arith.all;

library SYNOPSYS;						--
integer deklaration
use SYNOPSYS.attributes.all;

entity filter1 is
    port (
			clk:        in       STD_LOGIC;
			start:		in
std_logic;

			insignal:  in       STD_LOGIC_VECTOR(7 DOWNTO
0);

			utsignal: inout    STD_LOGIC_VECTOR(7 DOWNTO 0)
         );
end filter1;

--******************************************************
--*                                                    *
--*        ARCHITECTURE FILTER1.                       *
--*                                                    *
--******************************************************

architecture filter1_arch of filter1 is


--******************************************************
--* 				Signal deklaration
--******************************************************


signal utsignal1, utsignal2:		STD_LOGIC_VECTOR(7 DOWNTO 0);
signal insignal1, insignal2:		STD_LOGIC_VECTOR(7 DOWNTO 0);

begin

filter: process(clk)

begin

if clk='1' and clk'event then

	utsignal<=1.9425*utsignal1-0.9806*utsignal2+0.0097*insignal-
0.0097*insignal2;
	utsignal2<=utsignal1;
	utsignal1<=utsignal;
	insignal2<=insignal1;
	insignal1<=insignal;

end if; --clk='1'

end process; --filter;

end filter1_arch;

Thankful for help


Björn Lindegren


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21427
Subject: Re: Clock nets using non-dedicated resources
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Mar 2000 10:22:21 -0500
Links: << >>  << T >>  << A >>
boniolopez@my-deja.com wrote:
> 
> Hi Andy,
> Than you for replay.
> I have tried to find your thread, but you write so many messages, that
> it is impossiable without the subject name to find one. Could you write
> the exact subj. or date of thread you mean.
> regards,
> Bonio
> In article <8b8b8d$1t9b$1@noao.edu>,
> "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam> wrote:
> > boniolopez@my-deja.com wrote in message <8b5mrk$k76
> $1@nnrp1.deja.com>...
> > >Hi all,
> > >I'm not very new in FPGA design but I can't find the issue of
> following
> > >problem:
> > >
> > >
> > >WARNING:Timing:33 - Clock nets using non-dedicated resources were
> found
> > >in this
> > > design. Clock skew on these resources will not be automatically
> > >addressed
> > > during path analysis. To create a timing report that analyzes clock
> > >skew for
> > > these paths, run trce with the '-skew' option.
> > >
> > >
> > >
> > >I'm quite sure to use in my design the deducted clock resources only
> > >(and connected to BufG or Buf GP). I think the syntheses tool can'
> > >recognise some part in my design and form it so, that clock some FF
> > >with the gated signal. But I cant find where.
> > >
> > >THE QUESTION: How I can find out where the Alliance 2.1i found the
> non-
> > >dedicated resources(which signal is such clock)?
> >
> > Wow. I had the exact same problem. (scroll down in your newsreader;
> maybe
> > the articles haven't expired yet). turns out that it had to do with
> crossing
> > clock domains and such. One of the Xilinx apps guys sent me a note
> with a
> > shell script that parses ncdread's output so you can find out if there
> > really is a problem.
> >
> > In FPGA Editor, you can highlight your clock nets and print out the
> chip. I
> > plotted mine onto E-size paper. Unfortunately, FPGA Editor only
> prints out
> > in gray-scale, so that fancy-shmancy HP DesignJet wasn't all that
> helpful.
> >
> > --
> > -----------------------------------------
> > 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
> >
> >
> 
> Sent via Deja.com http://www.deja.com/
> Before you buy.


I nosed around on Deja.com searching the discussion groups and found the
thread under "Spartan and timing analyzer: clock nets using
non-dedicated resources". You have to use the Past rather than Recent
selection. A lot of this thread is devoted to signals across clock
domains rather than finding the signal that is showing up as using a
non-dedicated resource. 


-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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

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

Internet URL http://www.arius.com
Article: 21428
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 22 Mar 2000 15:37:54 GMT
Links: << >>  << T >>  << A >>
In article <38D878EA.CB904ED7@xilinx.com>, Hobson Frater wrote:
>I'm not familiar with your level of knowledge about Xilinx and our products,
>so please forgive me if the following is not what you're looking for.
>
>The bitstream specs for Xilinx devices, indeed most programmable devices from
>most companies, are proprietary.  This is done to ensure that our customers'
>designs aren't copied or reverse-engineered (well at least not without a lot
>of trouble) by our customers' competitors.

That's quite a pity.  Every single time I"ve purchased hardware tied to
proprietary software the proprietary software, no matter how good, sucked
ass in the end and never ever did what I really wanted.  No matter how
good, bug free, and featureful your proprietary software is and how naive,
buggy, and underfeatured the software I write will be, I ALWAYS prefer my
own.
	Could you please have that info posted on xilinx's page?  The
whole "we're a stupid secretive company who doesn't want people to
actually use our hardware" part isn't anywhere on their page -- I've
looked a lot.  Have any of you hardware types ever seriously lived a Linux
hacker life?  From our side, the hardware world is tremendously secretive
and it's glaringly obvious how you guys get hurt with this stupidity (see
a recent thread about soldering BGA, for example).  It makes you look very
immature even though the hardware world has, in some ways, accomplished a
lot more than the software world.
	Do you know of any exceptions?  If there aren't any, I declare the
PLD market fundamentally stupid (would Intel design chips whose process
they didn't understand?  come on), and I will move on.  I want a
programmable logic device -- programmable not by you or by your software,
but by me and my software.  I want the device, not the software.  I cannot
express strongly enough my intolerance for proprietary software.  You're
cutting off a whole market there.

>Now, I can read what you've said about the software in two different ways.
>Again, I apologize if I've misunderstood you.
>
>The first way I could read it is that you believe that you need to have
>windows as well as our software running in the system in which your Xilinx
>device will operate.  That is, you need to have the software on the board you
>are designing.  This is not the case.  The software is used purely in the
>development of the design, not for interfacing with the device.  Once the
>design is finished and the bitstream has been generated, there is no need for
>the software to be present in order for the device to work the way you've
>designed it to work.

It's teh second way.

>The other way I could read your comments is that you understand that the
>software is for design development purposes only and that you just don't want
>to have to use it.  As the above information may indicate, since the spec is
>proprietary, there is really no other way to generate a bitstream than to use
>the software.  I would mention, too, that our devices have many complex
>features and can get quite large.  Designing something like this by hand
>rather than using archetecture-specific mapping and placement & routing
>software would be extremely difficult.  The bitstreams themselves range from
>~54K bits to the tens of millions of bits.

Putting up with software that sucks is much more difficult for me.  I know
what I'm asking for.

>Now, that said, there *is* a tool available for quickly modifying bitstreams
>(not creating them from scratch).  It is called JBits, and you can read more
>about it at http://www.xilinx.com/xilinxonline/jbits.htm

I'll look into that, thanks.
Article: 21429
Subject: Re: Clock nets using non-dedicated resources
From: boniolopez@my-deja.com
Date: Wed, 22 Mar 2000 16:42:51 GMT
Links: << >>  << T >>  << A >>


So I have tried to find this clock as you write, but all clock from
section 8 are using bufG or bufGP.

I have in my design following construction
Clock2<=clock1 and enable_clock2
PIN_probe1<=clock1;
PIN_probe2<=clock1;

Clok2 uses BufG, clock1 uses bufGP


My last question: Do you think that this could be a cause of warnings,
we are speaking about? (if yes why even this warning)
regards,
bonio

In article <8b5mrk$k76$1@nnrp1.deja.com>,
boniolopez@my-deja.com wrote:
> Hi all,
> I'm not very new in FPGA design but I can't find the issue of
following
> problem:
>
> WARNING:Timing:33 - Clock nets using non-dedicated resources were
found
> in this
> design. Clock skew on these resources will not be automatically
> addressed
> during path analysis. To create a timing report that analyzes clock
> skew for
> these paths, run trce with the '-skew' option.
>
> I'm quite sure to use in my design the deducted clock resources only
> (and connected to BufG or Buf GP). I think the syntheses tool can'
> recognise some part in my design and form it so, that clock some FF
> with the gated signal. But I cant find where.
>
> THE QUESTION: How I can find out where the Alliance 2.1i found the
non-
> dedicated resources(which signal is such clock)?
>
> Any help will be appreciated,
> Bonio
> Remove_this_Bonio.lopez@gmx.ch_remove_this
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21430
Subject: Re: Clock nets using non-dedicated resources
From: boniolopez@my-deja.com
Date: Wed, 22 Mar 2000 16:43:02 GMT
Links: << >>  << T >>  << A >>


So I have tried to find this clock as you write, but all clock from
section 8 are using bufG or bufGP.

I have in my design following construction
Clock2<=clock1 and enable_clock2
PIN_probe1<=clock1;
PIN_probe2<=clock1;

Clok2 uses BufG, clock1 uses bufGP


My last question: Do you think that this could be a cause of warnings,
we are speaking about? (if yes why even this warning)
regards,
bonio

In article <8b5mrk$k76$1@nnrp1.deja.com>,
boniolopez@my-deja.com wrote:
> Hi all,
> I'm not very new in FPGA design but I can't find the issue of
following
> problem:
>
> WARNING:Timing:33 - Clock nets using non-dedicated resources were
found
> in this
> design. Clock skew on these resources will not be automatically
> addressed
> during path analysis. To create a timing report that analyzes clock
> skew for
> these paths, run trce with the '-skew' option.
>
> I'm quite sure to use in my design the deducted clock resources only
> (and connected to BufG or Buf GP). I think the syntheses tool can'
> recognise some part in my design and form it so, that clock some FF
> with the gated signal. But I cant find where.
>
> THE QUESTION: How I can find out where the Alliance 2.1i found the
non-
> dedicated resources(which signal is such clock)?
>
> Any help will be appreciated,
> Bonio
> Remove_this_Bonio.lopez@gmx.ch_remove_this
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21431
Subject: Re: Clock disabling
From: boniolopez@my-deja.com
Date: Wed, 22 Mar 2000 16:54:51 GMT
Links: << >>  << T >>  << A >>


Hi Nicolas,
Im not sure if it would good solution and would be glad if Mr. Peter
Alfke and other expert comments following:
Why not make 2 clock domains one with clk1 and one with clk2.
Clk2<=clk1 and enable_from_external_pin;
If you make ASIC this should not cause problem, in FPGA place clk2 on
secondary buffer (BufG).
Correct me, if I am wrong.

remove_this_bonio.lopez@gmx.ch_remove_this
In article <38D63858.2A94786B@dotcom.fr>,
Nicolas Matringe <nicolas@dotcom.fr> wrote:
> Hi all
> I am working on a design which may be used in two products, one of
which
> won't need some functions of the design. I don't want to have 2
designs
> (we won't make 2 ASICs).
> I was wondering if it was possible to have 2 clock domains (same
> frequency) with the possibility to turn one of them off to reduce
power
> consumption (this would be done by pulling a pin high or low for
> example)
> --
> Nicolas MATRINGE DotCom S.A.
> Conception electronique 16 rue du Moulin des Bruyeres
> Tel 00 33 1 46 67 51 11 92400 COURBEVOIE
> Fax 00 33 1 46 67 51 01 FRANCE
>


Sent via Deja.com http://www.deja.com/
Before you buy.
Article: 21432
Subject: Re: FPGA openness
From: gordon@dcs.ed.ac.uk (Gordon Brebner)
Date: 22 Mar 2000 16:58:42 GMT
Links: << >>  << T >>  << A >>
In article <8bapci$i0h$1@jetsam.uits.indiana.edu>,
 galexand@sietch.bloomington.in.us (Greg Alexander) wrote:
>	Do you know of any exceptions?  If there aren't any, I declare the
>PLD market fundamentally stupid (would Intel design chips whose process
>they didn't understand?  come on), and I will move on.  I want a
>programmable logic device -- programmable not by you or by your software,
>but by me and my software.  I want the device, not the software.  I cannot
>express strongly enough my intolerance for proprietary software.  You're
>cutting off a whole market there.

Welcome to the FPGA world, Greg.  This is a sad fact of life for people
who actually want to do interesting "soft" things with the technology,
rather than just pretend that it's a dumb ASIC.

The most recent commendable exception to the secrecy rule was the Xilinx
6200 (and its ancestor the Algotronix CAL1024).  As a result, just about
all of the innovative work on exploring the capabilities of reconfigurable
circuitry as a novel computing paradigm has been done using this part.
For example, I have written all of my own programming tools over the
past ten years.  Unfortunately, this part was chopped a couple of years
ago because the bulk buyers of FPGAs don't want anything more than a
straight hardware ASIC substitute.

I know that various people have reverse engineered bitstream formats,
e.g. the Xilinx XC4000 series, so that some knowledge is out there, but
gained by inordinate wastage of people's time.

The only redeeming feature at Xilinx at the moment is that the efforts
of the JBits people are currently being tolerated.  Apart from that, it's
a sad fact that the major providers just don't want to move on from
being simple logic array providers.

Gordon.

Article: 21433
Subject: Re: Foundation 2.1: Prevent Optimizing away of open Signals/Pins ?
From: John Larkin <jjlarkin@highlandSnipSniptechnology.com>
Date: Wed, 22 Mar 2000 09:08:18 -0800
Links: << >>  << T >>  << A >>
On Wed, 22 Mar 2000 10:21:04 +0100, "Holger Kleinert"
<Kleinert@ibpmt.com> wrote:

|Hello All !
|
|Actually I create a design with a Xilinx XCS20XL and Foundation Express V2.1
|Software.
|The design is VHDL only.
|
|I have a problem concerning optimization of the design.
|As the design does not use all signals on the bus,
|I want some pins to be high impedance 'Z' all the time.
|
|So, if I attach just a 'Z' in the architecture body to the signals they are
|optimized away.
|(See part of the listing below)
|1) The pins then can not be places using the constraint file.
|2) The pins get an pull up resistor attached.
|Due to optimisation they are declares as 'not used', and all not used pins
|get a pull up attached.
|
|So my question :
|What must I do to prevent the "pin away optimisation" for one signal.
|Is it some directive like "-- don't touch " ???
|
|Thank you for help
|
|Holger
|
|--***************
|
|entity pci_target is
|[....]
|
| nPERR    : out   std_logic;
| nSERR    : out   std_logic;
|
|architecture pci_target_arch of pci_target is
|[....]
|      nPERR    <= 'Z';
|      nSERR    <= 'Z';
|
|--********************

Holger,

this is terrible, but it works: drive your pins with tristate buffers.
Enable each tristate from a state generator that always generates a '0',
but is too complex for the compiler to understand and optimize out.

We've done this a couple of times, rather than fighting the tools.

John


Article: 21434
Subject: FPGA Part Selection Advice
From: "David Neely" <deletemeaoe_londonfog@hotmail.com>
Date: Wed, 22 Mar 2000 17:14:16 GMT
Links: << >>  << T >>  << A >>
Hey all,

Just wanted to ask the newsgroup for a little help. I need to select a part
for a very small FPGA (or CPLD as the case may be) with about 20-25 pins
max.

The big gimmick is speed - The part needs to be able to handle ~200 MHz on
the pins and internally. So far, the GAL22V10 from Lattice seems to be a
good choice....can anyone make any further recommendations?
Altera/Xilinx/Alcatel for example??

I wonder if I am forgetting something :Þ

Thanks,
David Neely
Junior Engineer


Article: 21435
Subject: Re: constant error in VHDL code
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 22 Mar 2000 10:16:05 -0700
Links: << >>  << T >>  << A >>
e97bjli@thn.htu.se wrote in message <8ban81$vm1$1@nnrp1.deja.com>...
>Hi
>
>Designing a butterworth filter in VHDL.
>When I trie to scale a std_logic_vector I recive an error.
>
>utsignal<=1.9425*utsignal1-0.9806*utsignal2+0.0097*insignal-
>0.0097*insignal2;
>
>Some thing is wrong with this row.


you've declared utsignal as a std_logic_vector but you're attempting to do
real math with it.  utsignal (and utsignal1 and utsignal2) must be declared
to be a type real, and you'll have problems (truncation, etc) trying to get
it to/from an eight-bit SLV.  And it won't synthesize.

There ARE integer (fixed-point) filter implementations; you should probably
consider those if you need to actually make a chip.

-- a
-----------------------------------------
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: 21436
Subject: No- FPGA openness
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 22 Mar 2000 10:23:23 -0700
Links: << >>  << T >>  << A >>
Hobson Frater wrote:
> 
> Greg,
> 
> I'm not familiar with your level of knowledge about Xilinx and our products,
> so please forgive me if the following is not what you're looking for.
> 
> The bitstream specs for Xilinx devices, indeed most programmable devices from
> most companies, are proprietary.  This is done to ensure that our customers'
> designs aren't copied or reverse-engineered (well at least not without a lot
> of trouble) by our customers' competitors.
>
I still can see how it would prevent reverse engineering, but I am lost
on how that prevents designs from being copied if a simple Rom is being
used to hold the bit stream. The disadvantage of the closed information
is that one is tied to the manufacturer to provide the ONLY source of
software for programing the device. A better idea would have standard
bit stream format, and have the manufactures supply a conversion program
to their encrypted format. This would provide hopefully more FPGA
software
and more people using FPGA's



-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
Article: 21437
Subject: Re: How to implement STARTBUF / GSR with SpartanXL and VHDL on FNDTN
From: Jaroslaw Kubica <jkubica@sigma.krakow.pl>
Date: Wed, 22 Mar 2000 17:25:46 GMT
Links: << >>  << T >>  << A >>
Hi,

library IEEE;
use IEEE.std_logic_1164.all;

entity example is
port (
    rst: in std_logic;
    input: in std_logic;
    output: std_logic
    );
end example;

architecture example_arch of example is
component STARTUP
        port (
                GSR:    in      STD_LOGIC
                );
end component;
begin

        U1: STARTUP
        port map (
                GSR     =>      rst
                );

end example_arch;

It works with Xilinx Spartan series and Synopsys FPGA Express :-)

Regards
Jarek

Holger Kleinert wrote:

> Hello All !
>
> I actually make a design with a Xilinx Spartan 20XL device.
> I use Foundation Express V2.1i.
> The entire design is VHDL.
>
> I want to implement the Global Set/Reset feature in VHDL
> and referred to "Systhesis and Simulation Design Guide"  from Xilinx.
> (downloadable from Xilinx WebSite)
>
> Page 4-17 gives an example of implementig such a feature,
> but this don't work with my tool.
>
> At first I do not have the library "UNISIM" and
> at second the STARTBUF component is not recognized..
>
> If anyone has implemented GSR feature successfully in VHDL
> please eMail me !!!!
>
> Thank you !
>
> Holger
>
> Here is my listing:
>
> -----------------------------------------------------
> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.STD_LOGIC_UNSIGNED.all;
>
> library UNISIM;        -- This library can not be found and is not delivered
> use UNISIM.all;
>
> entity pci_target is
>     port (
>     [.....]
>     nRST     : in    std_logic;
>     [.....]
>     );
> end pci_target;
>
> architecture pci_target_arch of pci_target is
>   signal nRESET     : std_logic;
>
>   component INV
>     port (I: in  std_logic;
>           O: out std_logic);
>   end component;
>
>   component STARTBUF
>     port (GSRIN:  in  std_logic;
>           GSROUT: out std_logic);
>   end component;
>
> begin
>   U1 : INV       port map (I => nRST, O => nRESET);
>   U2 : STARTBUF  port map (GSRIN =>nRESET, GSROUT =>RESET_INT);
> end architecture;
>
> ----------------------------------------------------------------------------
> ---------
> --
> Holger Kleinert
> Development / Support
>
> IBP Instruments GmbH
> Sutelstrasse 7a
> D-30659 Hannover, Germany
>
> http://www.ibpmt.com
> Fon : +49-511-652286
> Fax : +49-511-652283

Article: 21438
Subject: Re: How to implement STARTBUF / GSR with SpartanXL and VHDL on FNDTN 2.1i ?
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 22 Mar 2000 10:26:27 -0700
Links: << >>  << T >>  << A >>
Holger Kleinert wrote in message <8bajgi$4cd40$1@fu-berlin.de>...
>Hello All !
>
>I actually make a design with a Xilinx Spartan 20XL device.
>I use Foundation Express V2.1i.
>The entire design is VHDL.
>
>I want to implement the Global Set/Reset feature in VHDL
>and referred to "Systhesis and Simulation Design Guide"  from Xilinx.
>(downloadable from Xilinx WebSite)
>
>Page 4-17 gives an example of implementig such a feature,
>but this don't work with my tool.

I think that the design guide needs an update.


don't instantiate GSR - just let the synthesis tool infer it, which it will
do if you're careful and run the same reset signal to all of your flops.  if
you instantiate a "black box" such as a CORE memory or something, you'll
have to tell your synthesis tool to ignore black boxes when inferring GSR.
Also, you needn't worry about GSR polarity.  It should "do the right thing."

>At first I do not have the library "UNISIM" and
>at second the STARTBUF component is not recognized..

> library IEEE;
> use IEEE.std_logic_1164.all;
> use IEEE.STD_LOGIC_UNSIGNED.all;

> library UNISIM;        -- This library can not be found and is not
delivered
> use UNISIM.all;

Those libraries are only needed for simulation, so things can be confusing.

1) If you want to simulate code with instantiated components, there's an
app-note somewhere on the Xilinx Web site that tells you how to build the
simulation libraries for use with ModelSim.  You'll need to do that.  It's
straightforward.

2) Here's the non-obvious part - the synthesis tools do NOT need the

    library unisim;
    use unisim.all;

clause.  when you synthesize WITH that clause, the tool fails.  However, you
can't simulate WITHOUT that clause, because then your simulation tool will
fail!  You'll need to use a synopsys pragma to tell the synthesis tool to
ignore certain lines:

-- synopsys translate_off
library unisim;
use unisim.all;
-- synopsys translate_on

Now, the simulator will NOT ignore those lines and will know what library to
search for your instantiated components.  And the synthesis tool WILL ignore
those lines and not look for a simulation library it doesn't need.

Gotcha: there's a comment in the docs that say that the synopsys
translate_off/on pragma is no longer preferred and recommends a replacement.
Which doesn't work.

have fun,
a
-----------------------------------------
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: 21439
Subject: Re: FPGA openness
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 22 Mar 2000 17:26:30 GMT
Links: << >>  << T >>  << A >>
In article <8bau42$dsf$8@rairidh.dcs.ed.ac.uk>, Gordon Brebner wrote:
>I know that various people have reverse engineered bitstream formats,
>e.g. the Xilinx XC4000 series, so that some knowledge is out there, but
>gained by inordinate wastage of people's time.

Do you know where I could find any of this information?  I don't have the
time/resources to reverse engineer any of it myself, but if the
information can be obtained without planting me firmly on the defendant
side of a case with Xilinx, I might just buy one of their chips.

>The only redeeming feature at Xilinx at the moment is that the efforts
>of the JBits people are currently being tolerated.  Apart from that, it's
>a sad fact that the major providers just don't want to move on from
>being simple logic array providers.

JBits looks a little bit promising.  I'll look into that more.

Thanks.
Article: 21440
Subject: Re: Foundation 2.1: Prevent Optimizing away of open Signals/Pins ?
From: "Tim" <tim@tile.demon.co.uk.notreally>
Date: Wed, 22 Mar 2000 11:15:23 -0700
Links: << >>  << T >>  << A >>
Since the state of an unconfigured pin is 'Z' with a 50K pullup,
why is this behaviour of the synthesiser a problem?  The weak
pullup would seem to be quite a good idea in a CMOS design.

Holger Kleinert <Kleinert@ibpmt.com> wrote in message
news:8ba38e$4p8tj$1@fu-berlin.de...
> Hello All !
>
> Actually I create a design with a Xilinx XCS20XL and Foundation
Express V2.1
> Software.
> The design is VHDL only.
>
> I have a problem concerning optimization of the design.
> As the design does not use all signals on the bus,
> I want some pins to be high impedance 'Z' all the time.
>
> So, if I attach just a 'Z' in the architecture body to the signals
they are
> optimized away.
> (See part of the listing below)
> 1) The pins then can not be places using the constraint file.
> 2) The pins get an pull up resistor attached.
> Due to optimisation they are declares as 'not used', and all not used
pins
> get a pull up attached.
>



Article: 21441
Subject: Re: FPGA openness
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 22 Mar 2000 12:07:25 -0700
Links: << >>  << T >>  << A >>
Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>...
>That's quite a pity.  Every single time I"ve purchased hardware tied to
>proprietary software the proprietary software, no matter how good, sucked
>ass in the end and never ever did what I really wanted.  No matter how
>good, bug free, and featureful your proprietary software is and how naive,
>buggy, and underfeatured the software I write will be, I ALWAYS prefer my
>own.

So, let me get this straight.  You're a software guy - a Linux hacker, as
you say - and you think that you're just going to be able to, in your spare
time, write a synthesis tool, a placement engine, a router, and a timing
analyzer?  Is your background in writing code for synthesis tools?  Logic
minimization?  All the other stuff that's under the hood of these tools?
And do you think that your stuff, starting from scratch, will somehow be
"better" than, say, Xilinx', who've had a ten-year head start on you (and a
lot more resources to throw at the problem)?

I would imagine that most of us who design with FPGAs for a living would
much rather have the silicon vendors do the hard stuff -- the design
software -- so we can get on with our jobs, which is building hardware.


> Have any of you hardware types ever seriously lived a Linux hacker life?

No.  Should I?  And why?  Some of us prefer to be paid for our work.

Have you gone on tour and mixed live rock bands?  Should you?

-- a
-----------------------------------------
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: 21442
Subject: Windowed Altera 1810s?
From: James Horn <jimhorn@svn.net>
Date: Wed, 22 Mar 2000 19:09:41 GMT
Links: << >>  << T >>  << A >>
Hello all -

Does anyone have any (old) Altera 1810s in the windowed J-lead PLCC
package around that they don't need?  Altera no longer sells them (the
7000 family is much more flexible and less expensive), but we need to
slightly modify undocumented 1810s here and, at nearly US$100 each, the
windowless OTP parts are very risky(!).  Speed isn't critical - the
existing design uses 45ns parts.  Even one would be terrific as a
development tool.

Many thanks in advance!

Jim Horn, WB9SYN/6
Wescam Corp.   1-707-473-1100
Healdsburg, California, USA
Article: 21443
Subject: Re: Clock nets using non-dedicated resources
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 22 Mar 2000 12:14:11 -0700
Links: << >>  << T >>  << A >>
Rickman wrote in message <38D8E52D.FA32C4D7@yahoo.com>...
>I nosed around on Deja.com searching the discussion groups and found the
>thread under "Spartan and timing analyzer: clock nets using
>non-dedicated resources". You have to use the Past rather than Recent
>selection. A lot of this thread is devoted to signals across clock
>domains rather than finding the signal that is showing up as using a
>non-dedicated resource.

That's because the chip had a circuit that divided an 80 MHz clock down to
40 MHz that was used with the majority of the logic, and there was
discussion about the skew between the clcock domains.

I remember why I did that.  I was using a CORE FIFO in the chip (a Spartan)
and didn't think it would work at 80 MHz.  Turns out that I just built a
16-deep by 32-bit-wide dual-port FIFO in an XLA part; runs fine at 80 MHz.
The trick, of course, was to do it in four eight-bit wide slices.  It eases
placement, among other things.   Deeper FIFOs are a problem that I haven't
had time to solve.

-- a
-----------------------------------------
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: 21444
Subject: Re: Clock nets using non-dedicated resources
From: "Andy Peters" <apeters.Nospam@nospam.noao.edu.nospam>
Date: Wed, 22 Mar 2000 12:16:54 -0700
Links: << >>  << T >>  << A >>
boniolopez@my-deja.com wrote in message <8bat66$71l$1@nnrp1.deja.com>...

>So I have tried to find this clock as you write, but all clock from
>section 8 are using bufG or bufGP.
>
>I have in my design following construction
>Clock2<=clock1 and enable_clock2
>PIN_probe1<=clock1;
>PIN_probe2<=clock1;
>
>Clok2 uses BufG, clock1 uses bufGP


>My last question: Do you think that this could be a cause of warnings,
>we are speaking about? (if yes why even this warning)

that's most certainly the problem.  why not use enable_clock2 as the clock
enable for the flops that need to be clocked by clock2?

It's a warning because there was nothing to prevent the chip from placing
and routing, but it may not function properly.


-- a
-----------------------------------------
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: 21445
Subject: Re: Virtex DLL inoperability
From: galexand@sietch.bloomington.in.us (Greg Alexander)
Date: 22 Mar 2000 19:20:40 GMT
Links: << >>  << T >>  << A >>
In article <38D8CECD.9CCA9A3D@ids.net>, Ray Andraka wrote:
>Did you try the hotline?  The support engineers on the hotline may not be able to
>find a solution, but at least they call you back and the problem gets on record
>(eventually it even gets added to the on-line answers database).  To be fair, I
>think Xilinx is quite a bit more forthcoming than most in the industry.  Who else
>has such an extensive problems and solutions database posted on line for the
>whole world to see?

When I find something that I suspect to be a compiler (or synthesis or R&P
...) bug, I will spend a good day making certain that it really is a
compiler bug before telling anyone about it because I consider it rude and
embarrassing to inform someone else that their software is buggy when it
might not be.  I come from the open source generation and I'm thus used to
solving problems on my own.  Anyone who makes/sells buggy closed-source
compilers and don't have an easy to find and comprehensive bug list on
their page has completely lost my respect because I could lose an
arbitrary number of days tracking down bugs in the compiler that probably
wouldn't be there in an open source version and would definitely be much
easier to track.
Article: 21446
Subject: Re: FPGA openness
From: Ben Franchuk <bfranchuk@jetnet.ab.ca>
Date: Wed, 22 Mar 2000 13:31:27 -0700
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> Greg Alexander wrote in message <8bapci$i0h$1@jetsam.uits.indiana.edu>...
> >That's quite a pity.  Every single time I"ve purchased hardware tied to
> >proprietary software the proprietary software, no matter how good, sucked
> >ass in the end and never ever did what I really wanted.  No matter how
> >good, bug free, and featureful your proprietary software is and how naive,
> >buggy, and underfeatured the software I write will be, I ALWAYS prefer my
> >own.
> 
> So, let me get this straight.  You're a software guy - a Linux hacker, as
> you say - and you think that you're just going to be able to, in your spare
> time, write a synthesis tool, a placement engine, a router, and a timing
> analyzer?  Is your background in writing code for synthesis tools?  Logic
> minimization?  All the other stuff that's under the hood of these tools?
> And do you think that your stuff, starting from scratch, will somehow be
> "better" than, say, Xilinx', who've had a ten-year head start on you (and a
> lot more resources to throw at the problem)?

True they have had more resources, and time to develop the code,but you 
can bet marketing pressure to get the product out the door. This is a PC
vs Mac
type problem we have here. Both people have valid view points, but OPEN
is generaly a lot better than closed, look at LINUX vs WINDOWS.

> 
> I would imagine that most of us who design with FPGAs for a living would
> much rather have the silicon vendors do the hard stuff -- the design
> software -- so we can get on with our jobs, which is building hardware.
> 
  I agree let the COMPUTER grid away at the problems,but lets not
hide information. Well software XYZ has a bug that generates the wrong
routing table in the final output format. How can you find such a bug
if nobody but the vender can read the format and they don't time to
modify
the software? 

-- 
"We do not inherit our time on this planet from our parents...
 We borrow it from our children."
The Lagging edge of technology:
http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html
Article: 21447
Subject: 4000XLA bitgen problem?
From: Tom Burgess <tom.burgess@hia.nrc.ca>
Date: Wed, 22 Mar 2000 12:50:06 -0800
Links: << >>  << T >>  << A >>
Just wondered if anyone else has seen the same problem
- namely that when I run bitgen with tie enabled it seems to bog
down toward the end tying down single nodes. When it finally completes, the
bitgen report says that some nodes are still untied - I've seen as many as
1023 untied nodes on a 70% utilized 4013XLA. I don't remember
makebits being this bad with 90% utilized plain old 4000 parts. The -u option
makes no difference, since no nets are flagged critical. I'm running
Fndtn 2.1i SP5 (128M RAM). The support database and hotline were not particularly
helpful on this issue.

Is the untied nodes number bogus, and if not, should I be concerned? 

 
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: 21448
Subject: Re: Virtex DLL inoperability
From: Ray Andraka <randraka@ids.net>
Date: Wed, 22 Mar 2000 21:28:15 GMT
Links: << >>  << T >>  << A >>
I agree here.  I wish I could charge someone for all the time I've spent in the past 6
months tracking problems that turned out to be bugs in the tools.

Greg Alexander wrote:

> When I find something that I suspect to be a compiler (or synthesis or R&P
> ...) bug, I will spend a good day making certain that it really is a
> compiler bug before telling anyone about it because I consider it rude and
> embarrassing to inform someone else that their software is buggy when it
> might not be.  I come from the open source generation and I'm thus used to
> solving problems on my own.  Anyone who makes/sells buggy closed-source
> compilers and don't have an easy to find and comprehensive bug list on
> their page has completely lost my respect because I could lose an
> arbitrary number of days tracking down bugs in the compiler that probably
> wouldn't be there in an open source version and would definitely be much
> easier to track.

--
-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: 21449
Subject: Re: No- FPGA openness
From: Rickman <spamgoeshere4@yahoo.com>
Date: Wed, 22 Mar 2000 16:31:34 -0500
Links: << >>  << T >>  << A >>
Ben Franchuk wrote:
> 
> Hobson Frater wrote:
> >
> > Greg,
> >
> > I'm not familiar with your level of knowledge about Xilinx and our products,
> > so please forgive me if the following is not what you're looking for.
> >
> > The bitstream specs for Xilinx devices, indeed most programmable devices from
> > most companies, are proprietary.  This is done to ensure that our customers'
> > designs aren't copied or reverse-engineered (well at least not without a lot
> > of trouble) by our customers' competitors.
> >
> I still can see how it would prevent reverse engineering, but I am lost
> on how that prevents designs from being copied if a simple Rom is being
> used to hold the bit stream. The disadvantage of the closed information
> is that one is tied to the manufacturer to provide the ONLY source of
> software for programing the device. A better idea would have standard
> bit stream format, and have the manufactures supply a conversion program
> to their encrypted format. This would provide hopefully more FPGA
> software
> and more people using FPGA's
> 
> --
> "We do not inherit our time on this planet from our parents...
>  We borrow it from our children."
> The Lagging edge of technology:
> http://www.jetnet.ab.ca/users/bfranchuk/woodelf/index.html

There are a lot of reasons for not giving out the bit stream format
details. Some have to do with preventing reverse engineering, but most
have to do with the interests of the company making the hardware. But
they are valid reasons nonetheless. 

One big reason is that the software can give an FPGA vendor a
competitive edge. For quite a while Altera was touted as having much
more user friendly software as compared to Xilinx. I can't say if this
was really true since I am not an Altera user. But I know people who
chose them as their FPGA vendor for this reason. I also don't think that
users perceive such a significance in the tools today.

The existance of third party tools can be seen as a threat to an FPGA
vendor for this reason. About 10 years ago a third party FPGA tools
vendor, Neocad, came out with a set of tools that was not targeted to
any one vendor. One big selling advantage was that they would allow you
to port your designs between different vendors if you decided to change.
Combine that with the improved operation of the place and route portion
of the tools and now the FPGA vendors were looking at reduced software
sales. In fact more than one FPGA vendor dropped their own tools and
offered Neocad as their sole source of tools. 

Xilinx decided that they needed the Neocad as an inhouse product and
bought the company. After a couple of years, they came out with a new
set of Xilinx tools based on the old Neocad tools. I can't say exactly
why Xilinx did this, but it did take the Neocad tools off the market. 

I won't say that I miss the Neocad tools. They were written by a group
of Unix hackers that understood little about hardware design. The user
interface on the tools was case sensitive so that users had to mix case
on nearly every command typed. The tools were written to control what
you did instead of helping. For example, if after placement, the tools
guestimated incorrectly that your paths would not meet your timing
constrains with routing delays added, you would not be allowed to try to
route the design. This did not work well for tristate busses where the
guestimated delays were about twice the actual delays. 

So all in all, I feel that the Unix hackers did a very poor job of
writing an FPGA tool set. I think the only part that was better than the
proprietary tools was the router which could be run on a network of Sun
workstations overnight or the weekend to give you a lot more compute
time to solve the routing problem. 

In any event, if you feel you can produce better FPGA tools than can the
vendors, why don't you feel that you can produce better chips? There are
projects which will allow you to share a wafer and produce a very small
quantity of chips at a reasonable price. Likely the cost of the chips
are less than the cost of the designer to lay them out. Why not go for
it and do an open source FPGA?

BTW, Neocad initially met with resistance from Xilinx, but after they
persisted and started shipping tools in spite of the Xilinx policy,
Xilinx changed course and assisted them with detailed internal
information on even the new chips. Maybe you will get this kind of
support once you have reached a point of credibility in the FPGA
community.

-- 

Rick Collins

rick.collins@XYarius.com

remove the XY to email me.



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

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

Internet URL http://www.arius.com


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