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 11250

Article: 11250
Subject: Re: low power FPGAs
From: z80@ds2.com (Peter)
Date: Thu, 30 Jul 1998 14:48:41 GMT
Links: << >>  << T >>  << A >>

>Does anybody know of a particular type of FPGA that comes close in power 
>consumption to Philips CoolRunner CPLDs??

The P5Z22V10 etc draws some 100uA quiescent, increasing with clock
speed of course. Most SRAM-based full-CMOS FPGAs should be in the same
area at DC, and the dynamic Icc will also of course increase according
to design complexity.

If you are comparing the P5Z22V10 running at say 50MHz with an FPGA
(containing the same 22V10 design, and using a global clock net) also
running at 50MHz, I would think the FPGA will draw a lot more power
simply because you are driving a huge global clock net at 50MHz.


--
Peter.

Return address is invalid to help stop junk mail.
E-mail replies to zX80@digiYserve.com but
remove the X and the Y.
Article: 11251
Subject: On how to protect your IP
From: "H. Ploog" <hp@e-technik.uni-rostock.de>
Date: Thu, 30 Jul 1998 18:39:54 +0200
Links: << >>  << T >>  << A >>
For some good reasons your customer wants to evaluate your design in
it's real surroundings.
We found some nice solution to avoid that your customer
does copy that bitstream (suppose you were using XILINX-FPGA's).
It's very easy to switch the clock-signal on and off. 
If you are interested in that module please feel free to look at

 
http://www-md.e-technik.uni-rostock.de/lehre/vlsi_i/tutor/protect_ip.htm

There is a more detailed description on that module even with some
downloadable VHDL-source (for free).
We used that design for some month and it's working pretty fine.
We do wellcome *any* comment on that module.

 Hagen
Article: 11252
Subject: Re: How to connect my reset with GSR at Xilinx-FPGAs - response and Additional questions!
From: ems@nospam.riverside-machines.com (ems)
Date: Thu, 30 Jul 1998 19:09:29 GMT
Links: << >>  << T >>  << A >>
On 29 Jul 1998 22:47:32 GMT, "Andy Peters" <apeters@noao.edu.NOSPAM>
wrote:

>As Rick points out, see Xilinx tech note:
>http://www.xilinx.com/techdocs/1376.htm .  Essentially, you'll have
>to instantiate a STARTUP component in your top-level VHDL source
>file.  And while they say that STARTUP is not simulatable, that's not
>true - Xilinx has recently released VHDL (and Verilog) simulation
>libraries for such components.

Are you sure about this? I use STARTBUF/etc. for VHDL. STARTUP has a
unisim model,but it doesn't do anything (STARTBUF doesn't do much
either, for that matter, but at least it propagates GSRIN to GSROUT
with a timing delay). There's some internal magic here, but I guess
that the only difference is that STARTBUF gives you a timing delay
from a device pin through to GSR, and STARTUP doesn't.

>Now, as I read through the tech notes, I started to become suspicious
>about all of this, and I kept thinking that I was doing something
>wrong.  Specifically, this tech note mentions:
>
>"It is not necessary to include your set/reset signal in the
>behavioral descriptions of the flip-flops in the design.  Any signal
>that is used to behaviorally set/reset a flip-flop will not use the
>dedicated Global Reset network, and that set/reset signal will be
>OR'ed with the Global Reset signal to asynchronously set/reset that
>flip-flop."
>
>If I read this correctly, this means that:
> <snip>

This paragraph is badly written. How about:

"There is one situation in which it is not necessary to explicitly
include your set/reset signal in the behavioural description of your
flip-flops. This occurs when all the flip-flops in the design share
the same set/reset condition, in which case this signal can be routed
on the GSR net. A given flip-flop may also have additional set/reset
conditions, which will be OR'ed with the GSR signal to asynchronously
set/reset that flip-flop'.

> <snip>
>Now, when I read this, I sent an e-note to Xilinx Tech Support that
>asked the following question:
>
>"Given the example of USE_GSR above, does this mean that I have to
>declare the attribute Xilinx_GSR in EVERY module that's not the top
>level?"
>
>The answer that came back was:
>
>"Xilinx Answer 1376 refers to the GSR (or power up reset) i.e. if the
>GSR is triggered every thing is reset not just the Flip Flop.
>
>In this case it depends if you want to be able to control when the
>flip flop is reset or only have it reset at power up.  If you only
>want the ff to be reset at power up, then yes remove the reset
>signal. If you want to be able to control when the ff is reset (i.e.
>reset just that flip flop) then you need to keep the reset signal in
>your code.

This isn't a particularly clear answer. The issue isn't power-up, but
whether all the F/Fs have the same reset. If you have a reset which
goes to all F/Fs (from a pin or an internal signal) then you can route
it on the GSR net (which also happens to be active at power-up), and,
if you want, you don't have to explicitly code it in your VHDL (though
I personally can't see any reason to remove it from the code). If your
own reset only goes to 99 out of 100 F/Fs, then it can't use the GSR
net, and so *must* be explicitly coded and routed.

>>In response to your second question no you do not need to declare the
>>Xilinx_GSR attribute in every lower level module.  Having it declared
>>once at the top level is enough."

>Note the last sentence: "Having it declared once at the top level is
>enough."  This, of course, contradicts the tech note.  Or maybe it
>doesn't.  Perhaps what the tech note should have said was that the
>attribute needs to be placed in the top-level entity.

The attribute is placed on the reset *signal*, which is why it only
needs to be done at one point - the signal only occurs once in the
netlist.

The other issue here is, as Rick points out, whether you actually need
the attribute at all (you don't). If the mapper detects that all the
flip-flops in your design have the same set/reset condition then it
will automatically use GSR.

Evan

Article: 11253
Subject: Re: How to connect my reset with GSR at Xilinx-FPGAs - response and Additional questions!
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: 30 Jul 1998 20:23:27 GMT
Links: << >>  << T >>  << A >>
ems <ems@nospam.riverside-machines.com> wrote in article
<35c0c468.14100720@news.dial.pipex.com>...
> On 29 Jul 1998 22:47:32 GMT, "Andy Peters"
<apeters@noao.edu.NOSPAM>
> wrote:
> 
re: STARTUP...
> 
> Are you sure about this? I use STARTBUF/etc. for VHDL. STARTUP has
a
> unisim model,but it doesn't do anything (STARTBUF doesn't do much
> either, for that matter, but at least it propagates GSRIN to GSROUT
> with a timing delay). There's some internal magic here, but I guess
> that the only difference is that STARTBUF gives you a timing delay
> from a device pin through to GSR, and STARTUP doesn't.

The Synopsys design guide mentions using STARTBUF instead of STARTUP.
 STARTBUF does sound like the thing to use.  I just wish Xilinx was
more clear about it.
 
> 
> This paragraph is badly written. How about:
> 
> "There is one situation in which it is not necessary to explicitly
> include your set/reset signal in the behavioural description of
your
> flip-flops. This occurs when all the flip-flops in the design share
> the same set/reset condition, in which case this signal can be
routed
> on the GSR net. A given flip-flop may also have additional
set/reset
> conditions, which will be OR'ed with the GSR signal to
asynchronously
> set/reset that flip-flop'.

That makes more sense, yes.
 
> >The answer that came back was:
> >
> >"Xilinx Answer 1376 refers to the GSR (or power up reset) i.e. if
the
> >GSR is triggered every thing is reset not just the Flip Flop.
> >
> >In this case it depends if you want to be able to control when the
> >flip flop is reset or only have it reset at power up.  If you only
> >want the ff to be reset at power up, then yes remove the reset
> >signal. If you want to be able to control when the ff is reset
(i.e.
> >reset just that flip flop) then you need to keep the reset signal
in
> >your code.
> 
> This isn't a particularly clear answer. The issue isn't power-up,
but
> whether all the F/Fs have the same reset. If you have a reset which
> goes to all F/Fs (from a pin or an internal signal) then you can
route
> it on the GSR net (which also happens to be active at power-up),
and,
> if you want, you don't have to explicitly code it in your VHDL
(though
> I personally can't see any reason to remove it from the code). If
your
> own reset only goes to 99 out of 100 F/Fs, then it can't use the
GSR
> net, and so *must* be explicitly coded and routed.

Since all of my flipflops have the same reset, then GSR does get
used, and I guess what happens then is that the "reset" in my
description gets absorbed into the GSR net.

> >Note the last sentence: "Having it declared once at the top level
is
> >enough."  This, of course, contradicts the tech note.  Or maybe it
> >doesn't.  Perhaps what the tech note should have said was that the
> >attribute needs to be placed in the top-level entity.
> 
> The attribute is placed on the reset *signal*, which is why it only
> needs to be done at one point - the signal only occurs once in the
> netlist.
> The other issue here is, as Rick points out, whether you actually
need
> the attribute at all (you don't). If the mapper detects that all
the
> flip-flops in your design have the same set/reset condition then it
> will automatically use GSR.

OK, I see...the attribute is placed on the signal, and when the
*mapper* puts it all together, it realizes that this signal goes to
all of the ffs and GSR gets used.

-andy

-- 
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
apeters@noao.edu.NOSPAM


Article: 11254
Subject: Re: How to connect my reset with GSR at Xilinx-FPGAs - response and Additional questions!
From: "Andy Peters" <apeters@noao.edu.NOSPAM>
Date: 30 Jul 1998 20:27:09 GMT
Links: << >>  << T >>  << A >>
Rickman <spamgoeshere4@yahoo.com> wrote in article
<35BFF5C9.F58D3166@yahoo.com>...

> I don't remember reading this, and this is not what I do. I make
sure
> that I DO include an asynchronous reset in my code for all FFs so
that I
> can control the Reset state as either a 1 or a 0. If you want all
of
> your FFs to go to '0' on Reset, you don't need to do anything other
than
> add the Startup component and wire a pin to it. The GSR path is
ALWAYS
> present and by default Resets all FFs to '0'. 

All of my code has an async reset for all FFs.  Some FFs are
initialized to 0 and some go to 1, so having the reset code makes
that happen.
 
<snip>

> > Note the last sentence: "Having it declared once at the top level
is
> > enough."  This, of course, contradicts the tech note.  Or maybe
it
> > doesn't.  Perhaps what the tech note should have said was that
the
> > attribute needs to be placed in the top-level entity.
> 
> This is especially confusing to me, since I was told that you don't
need
> that attribute at all. The backend tools supposedly recognize the
> duplication of the signal and remove the routed net. I do put the
> attribute in all of my VHDL code however. "Trust, but Verify". 

I didn't realize that the attribute even existed until I read the app
note.  That's what got me started on all of this: I assumed that the
GSR was mapping properly, and reading about this attribute made me
question whether that was happening or not.  I just wish the app and
tech notes were consistent.  And regularly updated.

-andy
-- 
Andy Peters
Sr. Electrical Engineer
National Optical Astronomy Observatories
apeters@noao.edu.NOSPAM


Article: 11255
Subject: Re: How to connect my reset with GSR at Xilinx-FPGAs - response and Additional questions!
From: Rickman <spamgoeshere4@yahoo.com>
Date: Thu, 30 Jul 1998 22:32:20 -0400
Links: << >>  << T >>  << A >>
ems wrote:
...snip...
> The other issue here is, as Rick points out, whether you actually need
> the attribute at all (you don't). If the mapper detects that all the
> flip-flops in your design have the same set/reset condition then it
> will automatically use GSR.
> 
> Evan

I am not clear on exactly what is the indicator that the user Reset
signal should be removed due to duplication with the GSR. I was told
that it was because it was connected to the GSR input on the Startup
component. I don't know that I have connected "every" FF in my design to
my user Reset, so by your info, my circuit might not work right. Does
anyone know for sure what the indicator is?

This is the kind of essential info that is very hard to get out of
Xilinx. If you don't know how it works, you can't guarantee that you
have designed it right! I need to be able to do it right the first time.

-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.


Article: 11256
Subject: Re: TRISTATE in FPGA
From: leslie.yip@asmpt.com
Date: Fri, 31 Jul 1998 08:39:16 GMT
Links: << >>  << T >>  << A >>
It's easy. You use the Xlinix's Schematic drwing tool to declare a Tri-state
component(I forget the name of the component)and double click the component,
then you can define the pin's attributes. You can have the pins of this
tri-state buffer connected to your VHDL files' I/O pins.

But if your design needs the tri-state buffer not in the IOBs, there may be
problems for XC4025.

To define tri-sate in VHDL:

process(en,a)
begin
 if e='1' then
   y <= a;
 else
   y <= 'Z';
 end if;
end process;


In article <IMAN.98Jul29193329@mercury.news.pacific.net.sg>,
  iman@mercury.news.pacific.net.sg ( Imanuddin Amril Account) wrote:
>
> Hi all,
>
> Currently I am using ASIC library to synthesis my design (vhdl). I have
> succeed until gate-level with timing simulation (synopsys synthesizer +
> leapfrog simulator).
>
> Now the problem is :
> - I need to download my design into XC4025 FPGA in order to simulate it
> in the real world before we send it to fab.
> - In some part of my design, i am using tri-state buffers to read/write
> data onto data bus. If the target
> library is ASICs then NO Problems. Anyhow if I  synthesize using FPGA
> library then my tristates become unsynthesizable since XC4025 *only* has
> tristates in its IOBs. Moreover since IOBs are located on periphery then
> the interconnection may become not realistic anymore (longer than needed)
>
> I am trying to replace tristate with mux2-1 style such that : if enable = 1
> then dataout <= datain, else dataout <= (others => X). All signals is
> std_logic type. X is strong unknown (from std_logic table).
>
> As you might guess, it CAN NOT work, even just simulate its functionality.
>
> Hope anybody could help me how to replace this tristate.
>
> TIA
> -iman
> --
> -iman
> ==================================================
> = Watch or be a part in Indonesia transformation =
> ==================================================
>

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum
Article: 11257
Subject: How to use fpga do a programmable clock generator(50hz to 50k )
From: lck@tainet.com.tw (richard lee)
Date: Fri, 31 Jul 1998 09:26:05 GMT
Links: << >>  << T >>  << A >>

dear sir:

How to use fpga doing a programmable clock gengrator
frequence 50hz to 50k 1hz resolution .
         best regards  7/31
		richard lee lck@tainet.com.tw
Article: 11258
Subject: Re: Schematic Symbol Generation
From: "Austin Franklin" <dark9room@ix.netcom.com>
Date: 31 Jul 1998 13:07:46 GMT
Links: << >>  << T >>  << A >>
> Welcome to the real world!!

Do you mean in the 'real world' lots of people want to waste my time? 
Well, that's certainly true these days....I must get 10 sales calls a day. 
Just because some sales person wants to try to take up my time doesn't mean
I have to let 'em.   Click....bzzzzz.

> If you want to know, you've got to ask.....

A LOT of compaines DO post their prices.  Personally, I think it is good
business to be up front with pricing.  I believe a company should try to
have as much information as I might 'need' to determine if the product is,
for the most part, right for me.  Pricing is critical in that decision. 
Doing that would possibly avoid wasting my, and their, time.

Austin Franklin
darkroom@ix.netcom.com



> >> Along with being sort-of-SPAM, isn't it funny how so many EDA
companies
> >> fail to post pricing...either in posts or even on their web sites.  I
> >> really don't want to talk to some sales person (who usually just wants
to
> >> get all my particulars and add me to some SPAM data base so they can
> call,
> >> mail or e-mail me) before they will give me any pricing information. 
All
> I
> >> just want to know if the product is economically feasable.  It really
> >> amazes me.
> >
> >Excellent point. As a student, I want to know whether a product is
> >shall we say "enterprise-priced" or whether it is in the reach of
> >students. I recently went through the whole email + phone call from
sales
> >rep etc just to get a quote on an X Windows server, only to find out
> >that it was over $1000 (still a good product, mind you).

Article: 11259
Subject: Re: How to connect my reset with GSR at Xilinx-FPGAs - response and Additional questions!
From: Thomas Reinemann <thomas.reinemann@mb.uni-magdeburg.de>
Date: Fri, 31 Jul 1998 15:17:55 +0200
Links: << >>  << T >>  << A >>
Hi Andy,

thank you for your hints.

Andy Peters wrote:

> Thomas Reinemann <thomas.reinemann@mb.uni-magdeburg.de> wrote in
> article <35BD8727.65B40E8@mb.uni-magdeburg.de>...
> > I am uisng Xilinx-FPGAs (with M1) with ViewLogic's WorkView Office
> (WVO)
> > design entry is VHDL.
> >
> > Now I looked at the schematics automatically generated by WVO and I
> > discovered that my reset is not connected to CLR of the FF.
> >
> > Is there a possibility to connect my reset with GSR and when yes,
> how
> > can I do this?
>
>
> "It is not necessary to include your set/reset signal in the
> behavioral descriptions of the flip-flops in the design.  Any signal
> that is used to behaviorally set/reset a flip-flop will not use the
> dedicated Global Reset network, and that set/reset signal will be
> OR'ed with the Global Reset signal to asynchronously set/reset that
> flip-flop."
>
> If I read this correctly, this means that:
>
> 1) When writing code, for example, for a flip-flop, you *don't* have
> to include a reset.  This is because the chip automagically resets
> all flipflops after configuration.  Which means that one can
> eliminate the reset term in the usual:
>
>         flipflop: process (clock, reset) is
>         begin
>                 if (reset = '1') then
>                         q <= '0';
>                 elsif (rising_edge(clock)) then
>                         q <= d;
>                 end if;
>         end process flipflop;
>
> Which of course means, then, that the functional simulation won't
> match the chip!

And is it not possible perhaps, because there is no initialization.


> Make sure you synthesize your top-level module as "Chip" and not
> "Macro."  Your project file list (in the Project Manager) should only
> have ONE VHDL file included.  When that file is open in the HDL
> editor, choose "Synthesis -> Options" and make sure that "Chip" is
> selected under compile.  This will automagically insert the clock
> buffers when you choose "Synthesis -> Synthesize."
>

That may be, but I'm not using Xilinx Project Manager unfortunately. I
wrote it.


Article: 11260
Subject: [****] VHDL Compile Error ( +, & Operator )
From: "iccra" <iccra@netsgo.com>
Date: Fri, 31 Jul 1998 22:50:09 +0900
Links: << >>  << T >>  << A >>

i have some problem. " + ", " & " operator for different type
i'm using ALDEC VHDL.

====================================================
LIBRARY IEEE;
USE IEEE.STD_LOGIC_1164.ALL;
USE IEEE.STD_LOGIC_ARITH.ALL;

----------------------------------------------------
SIGNAL pc  : STD_LOGIC_VECTOR (8 DOWNTO 0);
pc <= pc + "1";
----------------------------------------------------
Error: Operator "+" is not defined for such operands.
Error: Undefined type of expression.
----------------------------------------------------
SIGNAL a          : STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL temp_b     : STD_LOGIC_VECTOR(7 DOWNTO 0);
SIGNAL temp_carry : STD_LOGIC;

result <= ("0" & a) + temp_b + temp_carry
----------------------------------------------------
Error: Operator "&" is not defined for such operands.
Error: Undefined type of expression.
====================================================

thanks in advance...


Article: 11261
Subject: Symbols, design changes, pin changes
From: Mark <mam@kodak.com>
Date: Fri, 31 Jul 1998 10:50:00 -0400
Links: << >>  << T >>  << A >>
I am currently addressing a problem which I'm interested in finding out
if anyone else has.
We use the Mentor Graphics tools for doing board level simulation.
During the stages of development,
an FPGA may be placed at board level and simulated for verification.
Once the FPGA has been placed
and wired, the pins have a physical location on the symbol.  The problem
occurs when design changes
may cause pin locations to change for optimization purposes.  To
reinstantiate the FPGA at board level
now requires a complete rewiring due to the physical pin location
changes on the "new" symbol.  This
can become very tedious, and multiple iterations are painful.

If you are aware of a process, person, or company which has addressed
this problem before, I would
sincerely appreciate that contact information.

Best Regards,
Mark Mazza


Article: 11262
Subject: register for IEEE memory workshop
From: fmeyer@cs.tamu.edu (Jackie Meyer)
Date: 31 Jul 1998 16:01:55 GMT
Links: << >>  << T >>  << A >>

The hotel reservation deadline is approaching:  AUGUST 3



                     1998 IEEE International Workshop on

                   MEMORY Technology, Design, and Testing

August 24-25, 1998

Fairmont Hotel
San Jose, California

Web Page:  www.cs.tamu.edu/faculty/fmeyer/mtdt98.html

For general information contact:

Hank Walker / Jackie Meyer
Computer Science MS 3112
Texas A&M University
College Station TX 77843
+1-409-862-4389 / +1-409-845-1014
fax +1-409-847-8578
walker@cs.tamu.edu / fjmeyer@computer.org

Hotel reservation by: August 3, 1998
Advance registration by: August 10, 1998

                               Session Topics

Embedded DRAM
Embedded Memory Design Aids
Memory Repair
Content Addressable Memories
Algorithms and Testing Techniques
Unique Fault Models

                          Special Tutorial Sessions

DRAM Fault Modeling
SRAM Acceptance Testing
Article: 11263
Subject: Re: How to use fpga do a programmable clock generator(50hz to 50k )
From: Leon Heller <leon@lfheller.demon.co.uk>
Date: Fri, 31 Jul 1998 17:39:35 +0100
Links: << >>  << T >>  << A >>
In article <35c18c7b.28012511@news.seed.net.tw>, richard lee
<lck@tainet.com.tw> writes
>
>dear sir:
>
>How to use fpga doing a programmable clock gengrator
>frequence 50hz to 50k 1hz resolution .

Implement a direct digital synthesiser. It should be quite easy at those
frequencies.

Leon
-- 
Leon Heller: leon@lfheller.demon.co.uk http://www.lfheller.demon.co.uk
Amateur Radio Callsign G1HSM    Tel: +44 (0) 118 947 1424
See http://www.lfheller.demon.co.uk/dds.htm for details of a simple AD9850
DDS system. See " "/diy_dsp.htm for a simple DIY DSP ADSP-2104 system.
Article: 11264
Subject: Re: leapfrog wavform
From: Loek Frederiks <frederik@nym.sc.philips.com>
Date: Fri, 31 Jul 1998 18:40:01 +0200
Links: << >>  << T >>  << A >>
On Tue, 28 Jul 1998 bonics@my-dejanews.com wrote:

> Hello ,I am having a problem with the display of the simulation results using
> the Leapfrog simulator (version 2.3) Is there any setting option I have
> missed ? Thank you very much in advanced Benjamin
> 
> -----== Posted via Deja News, The Leader in Internet Discussion ==-----
> http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Could you be more specific ? There were/are plenty of problems
with cwaves (in the Cadence distribution until 4.3.4). We now
use 4.4.1 here with contains SimWave, which is quite a relief ;-)

Loek.

----------------------------------------------------------------
Loek Frederiks                            Bldg M2.002
Projectleader Channel Decoding US DTV     Gerstweg 2
Philips Semiconductors                    6534 AE Nijmegen
Consumer Systems Development              The Netherlands
mailto:Loek.Frederiks@nym.sc.philips.com  phone: +31 24 353 4677
seri: frederik@nyhp03                     fax: +31 24 353 4638

http://www.semiconductors.philips.com (Internet)
http://www.sc.philips.com/CS/blvweb/  (Intranet)
----------------------------------------------------------------

Article: 11265
Subject: Re: Symbols, design changes, pin changes
From: Ed Peterson <p27000@email.mot.com>
Date: Fri, 31 Jul 1998 11:38:16 -0700
Links: << >>  << T >>  << A >>
Put a location constraint on the pad symbol.  For ViewLogic the syntax looks
like this:

     LOC = Pin#

Mark wrote:

> I am currently addressing a problem which I'm interested in finding out
> if anyone else has.
> We use the Mentor Graphics tools for doing board level simulation.
> During the stages of development,
> an FPGA may be placed at board level and simulated for verification.
> Once the FPGA has been placed
> and wired, the pins have a physical location on the symbol.  The problem
> occurs when design changes
> may cause pin locations to change for optimization purposes.  To
> reinstantiate the FPGA at board level
> now requires a complete rewiring due to the physical pin location
> changes on the "new" symbol.  This
> can become very tedious, and multiple iterations are painful.
>
> If you are aware of a process, person, or company which has addressed
> this problem before, I would
> sincerely appreciate that contact information.
>
> Best Regards,
> Mark Mazza



Article: 11266
Subject: Re: Symbols, design changes, pin changes
From: Ed Peterson <p27000@email.mot.com>
Date: Fri, 31 Jul 1998 11:40:06 -0700
Links: << >>  << T >>  << A >>
Put a location constraint on the pad symbol.  For ViewLogic, the syntax
looks like this:

     LOC = pin#

That will keep the pin numbers from changing when you re-compile changes.

Hope this helps,

Ed Peterson

- - - - - - - -

Mark wrote:

> I am currently addressing a problem which I'm interested in finding out
> if anyone else has.
> We use the Mentor Graphics tools for doing board level simulation.
> During the stages of development,
> an FPGA may be placed at board level and simulated for verification.
> Once the FPGA has been placed
> and wired, the pins have a physical location on the symbol.  The problem
> occurs when design changes
> may cause pin locations to change for optimization purposes.  To
> reinstantiate the FPGA at board level
> now requires a complete rewiring due to the physical pin location
> changes on the "new" symbol.  This
> can become very tedious, and multiple iterations are painful.
>
> If you are aware of a process, person, or company which has addressed
> this problem before, I would
> sincerely appreciate that contact information.
>
> Best Regards,
> Mark Mazza



Article: 11267
Subject: Re: Symbols, design changes, pin changes
From: Ed Peterson <p27000@email.mot.com>
Date: Fri, 31 Jul 1998 11:41:19 -0700
Links: << >>  << T >>  << A >>
Put a location constraint on the pad symbol.  For ViewLogic, the syntax
looks like this:

     LOC = pin#

That will keep the pin numbers from changing when you re-compile changes.

Hope this helps,

Ed Peterson

- - - - - - - -

Mark wrote:

> I am currently addressing a problem which I'm interested in finding out
> if anyone else has.
> We use the Mentor Graphics tools for doing board level simulation.
> During the stages of development,
> an FPGA may be placed at board level and simulated for verification.
> Once the FPGA has been placed
> and wired, the pins have a physical location on the symbol.  The problem
> occurs when design changes
> may cause pin locations to change for optimization purposes.  To
> reinstantiate the FPGA at board level
> now requires a complete rewiring due to the physical pin location
> changes on the "new" symbol.  This
> can become very tedious, and multiple iterations are painful.
>
> If you are aware of a process, person, or company which has addressed
> this problem before, I would
> sincerely appreciate that contact information.
>
> Best Regards,
> Mark Mazza



Article: 11268
Subject: Delay Element in XC4000XL (was Re: Delay Element for async design.)
From: "Bruce Nepple" <brucen@imagenation.extra.com>
Date: Fri, 31 Jul 1998 13:06:07 -0700
Links: << >>  << T >>  << A >>
What do you know about using the XC4000XL IOB delay as a pure delay element.
Its not *directly* accessible, but I suppose you could program the IOB as a
latch and keep the clock active.  What is the range of the delay in ns. over
various parts?  Is this really supported?  Anyone have any experience with
this?

Bruce Nepple



Article: 11269
Subject: Re: Schematic Symbol Generation
From: Jamie Lokier <spamfilter.aug1998@tantalophile.demon.co.uk>
Date: 31 Jul 1998 21:08:44 +0100
Links: << >>  << T >>  << A >>
hamish@moffatt.nu (Hamish Moffatt) writes:
> Excellent point. As a student, I want to know whether a product is
> shall we say "enterprise-priced" or whether it is in the reach of
> students. I recently went through the whole email + phone call from sales
> rep etc just to get a quote on an X Windows server, only to find out
> that it was over $1000 (still a good product, mind you).

Don't forget to tell them you are a student, up front.  Some companies
will vary the price according to how much they think you will pay.
Generally they'll vary the conditions or options too, so those who pay a
lot more have a reason to, or so you have something to pay for if you go
professional with the software.

I think that's why some companies are so reticent.  If they charged a
large price, few would buy.  If they charged a small price, they
wouldn't make enough revenue to stay in business.  It doesn't
necessarily follow that there's a middle price that works, and even if
there is sometimes the only way to find it is to speak to potential
customers.

For companies that aren't all that well established, and I'm guessing
most aren't despite the glossy web sites, setting prices on this sort of
software is difficult and a gamble.  The costs and expected returns are
very difficult to estimate.

-- Jamie
Article: 11270
Subject: Re: TRISTATE in FPGA
From: Jamie Lokier <spamfilter.aug1998@tantalophile.demon.co.uk>
Date: 31 Jul 1998 21:11:04 +0100
Links: << >>  << T >>  << A >>
iman@mercury.news.pacific.net.sg ( Imanuddin Amril Account) writes:
> - I need to download my design into XC4025 FPGA in order to simulate it 
> in the real world before we send it to fab.
> - In some part of my design, i am using tri-state buffers to read/write 
> data onto data bus. If the target 
> library is ASICs then NO Problems. Anyhow if I  synthesize using FPGA 
> library then my tristates become unsynthesizable since XC4025 *only* has 
> tristates in its IOBs. Moreover since IOBs are located on periphery then 
> the interconnection may become not realistic anymore (longer than needed)

Wouldn't be nice of the synthesis tools could map this into working
non-tristate logic when there aren't enough tristate resources, or when
use of tristate impedes routing?

-- Jamie
Article: 11271
Subject: Altera tools on Linux
From: Jamie Lokier <spamfilter.aug1998@tantalophile.demon.co.uk>
Date: 31 Jul 1998 21:24:31 +0100
Links: << >>  << T >>  << A >>
I wonder, has anyone managed to get the Altera Max+Plus II FPGA
synthesis tools working in Linux, using Wine?  Or if there is a Linux
edition around that I don't know about?

So far it's worked fine for me, except the dongle protection doesn't
read the dongle.  Everything that doesn't require the dongle works
except the fonts are a bit wrong-sized in the floorplan editor, and some
of the stats in the floorplan editor are wrong.  Compiling works, as
long as I stick to non-dongle features and chips.  Not having any of
those chips I haven't been able to test a synthesised design.

Unfortunately my work requires the dongled features.

I've tried various ways to get it to work which I'm not going to
describe here.  I just wonder, has anyone else tried this with any
success?

Ta,
-- Jamie
Article: 11272
Subject: PCI Core In FPGA
From: "Simon Ramirez" <s_ramirez@email.msn.com>
Date: Fri, 31 Jul 1998 17:53:22 -0400
Links: << >>  << T >>  << A >>
To the Newgroup:
   I am doing a board level design that uses four FPGAs, two of which
implement PCI interfaces.  I am still doing the block diagram of the whole
board and have not started my FPGA designs yet.
   In order to expedite my designs, I have decided to look into PCI cores
from various vendors, including the FPGA vendors themselves.  They all claim
that their designs are the best and that the competitors' designs have flaws
in either the cores or the silicon.  I attribute most of the bad-mouthing to
just plain and simple sales hype, since I have asked some of the FAEs/Sales
Reps for proof to back up their bad-mouthing claims about the competitors,
and none of them can come up with any.
   I am favoring cores from FPGA vendors as oppsed to non-aligned vendors
for several reasons, which I won't get into here but will if you ask.  I
also favor VHDL and Verilog based designs, although I will not exclude
schematic based or mixed designs if there are good reasons to pick such a
design.
   But I am wondering if any of you have had any experience, good and/or bad
with PCI Initiator and Target cores (and silicon) from any of the FPGA
vendors.  If you have, please respond back to this group or better yet,
respond back to me personally at:
Simon Ramirez
Consultant/Contractor
770-752-5109
simon.ramirez@l-3com.com (work)
s_ramirez@msn.com (home)
   Thank you very much.
-Simon



Article: 11273
Subject: Re: Altera tools on Linux
From: Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
Date: 31 Jul 1998 23:08:42 GMT
Links: << >>  << T >>  << A >>
Jamie Lokier <spamfilter.aug1998@tantalophile.demon.co.uk> wrote:
: I wonder, has anyone managed to get the Altera Max+Plus II FPGA
: synthesis tools working in Linux, using Wine?  Or if there is a Linux
: edition around that I don't know about?

: So far it's worked fine for me, except the dongle protection doesn't
: read the dongle.  Everything that doesn't require the dongle works
: except the fonts are a bit wrong-sized in the floorplan editor, and some
: of the stats in the floorplan editor are wrong.  Compiling works, as
: long as I stick to non-dongle features and chips.  Not having any of
: those chips I haven't been able to test a synthesised design.

: Unfortunately my work requires the dongled features.

: I've tried various ways to get it to work which I'm not going to
: describe here.  I just wonder, has anyone else tried this with any
: success?

Hallo,

recent versions of Wine may access the dongle. However this implies running
Wine as Root or suid root. Consider if you want to take that risk. You need
to allow port acces in wine.conf. I have

[ports]
read=0x378-0x37f
write=0x378-0x37f

in wine.conf and had Autocad start up, recognising the dongle, but crashing
soon therafter as display.dll is not implemented in Wine.

Please report success/Failure to comp.emulators.ms-windows.wine and perhaps
to www.winehq.com.

Bye
-- 
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Article: 11274
Subject: Re: How to connect my reset with GSR at Xilinx-FPGAs - response and Additional questions!
From: Rickman <spamgoeshere4@yahoo.com>
Date: Fri, 31 Jul 1998 21:26:21 -0400
Links: << >>  << T >>  << A >>
Andy Peters wrote:
> 
> All of my code has an async reset for all FFs.  Some FFs are
> initialized to 0 and some go to 1, so having the reset code makes
> that happen.

I'm not clear what you mean by this. Are you saying that in ADDITION to
the GSR, you have an async control to each of the FFs in your design? I
realize that you can control the async condition to be a '0' or a '1'.
My point was that even if you do nothing in your design, the GSR is set
to clear all FFs to a '0' at power on. 

When I wanted to control the power on state of all of the FFs, I found
that you needed some fairly special code which is how I got into all
this in the first place. 


> I didn't realize that the attribute even existed until I read the app
> note.  That's what got me started on all of this: I assumed that the
> GSR was mapping properly, and reading about this attribute made me
> question whether that was happening or not.  I just wish the app and
> tech notes were consistent.  And regularly updated.

Yes, consistency is not a strong point of Xilinx. They are a company
with somewhat loose reigns. It would be nice if someone in control TOOK
control of the documentation and made it more concise, clear and put
everything on a topic in ONE PLACE! But then their products move forward
at a pretty good clip. I am sure that it is a full time job (or a lot of
them) trying to keep up with the documentation. 

You might also remember that the fact that it is not real easy keeps the
weinies out! ;-)


-- 

Rick Collins

rickman@XYwriteme.com

remove the XY to email me.


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