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

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

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

Custom Search

Messages from 41500

Article: 41500
Subject: VirtexII : Any limitation on using LVDS?
From: Ken <kenneth.lee@terapower.com.hk>
Date: Sat, 30 Mar 2002 17:16:03 -0800
Links: << >>  << T >>  << A >>
Dear all,

I want to ask if there is any limitation or restriction on using the LVDS I/O on Virtex II FPGA?  For example, the maximum number of LVDS I/O used at the same time?

I can find similar information for the signle ended I/O from the User Guide but not for LVDS.  

Anyone has idea about it?  Or know how to search such information?  Thanks in advance.

Regards,
Kenneth

Article: 41501
Subject: Compiler library ...
From: "Yves Petinot" <ypetinot@hotmail.com>
Date: Sat, 30 Mar 2002 18:00:31 -0800
Links: << >>  << T >>  << A >>
Hi,

does any of you know where to find a C-library handling the compilation from
VHDL to the bitstream format ? Any target FPGA will do ...

Thanks in advance for your help :-)

-Yves.



Article: 41502
Subject: Memory design for processor
From: teenamalik@hotmail.com (Tina)
Date: 30 Mar 2002 18:40:49 -0800
Links: << >>  << T >>  << A >>
I'm working on development of Intel 8051 microcontroller architecture
using VHDL on FPGA. I want to write code for its memory architecture
ie RAM and ROM. Can anyone please suggest me how to proceed for the
same.


Thanks,
Tina

Article: 41503
Subject: Re: I2C Slave sampling edge
From: hmurray-nospam@megapathdsl.net (Hal Murray)
Date: Sun, 31 Mar 2002 03:04:39 -0000
Links: << >>  << T >>  << A >>
[delays on feedback path for hyteresis]

>It is positive feedback, so unless your signals are toggling very fast, the
>delay is of no consequence.  If you are toggling fast enough for it to be an
>issue, you probably don't need the hysteresis in the first place.

Thanks.  I think that's the general answer I was fishing for.

Can we add some numbers to this discussion?  How can I compute
(or estimate) if I need hyteresis and/or if the feedback will
get back in time?

For example, it probably won't work as well if the feedback
path goes accross a large chip, say because that's where a pin
was free.

How much extra delay is added to an input pad when the rise time
is slow?  Will the feedback be fast enough if the feedback delay
is less than the extra delay from the slow rise time?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 41504
Subject: Re: VirtexII : Any limitation on using LVDS?
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 31 Mar 2002 15:42:33 GMT
Links: << >>  << T >>  << A >>
There are no limitations.
LVDS is  differential standard, therefore its outputs do not generate ground bounce.

Peter Alfke
==================================
Ken wrote:

> Dear all,
>
> I want to ask if there is any limitation or restriction on using the LVDS I/O on Virtex II FPGA?  For example, the maximum number of LVDS I/O used at the same time?
>
> I can find similar information for the signle ended I/O from the User Guide but not for LVDS.
>
> Anyone has idea about it?  Or know how to search such information?  Thanks in advance.
>
> Regards,
> Kenneth


Article: 41505
Subject: Re: Memory design for processor
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 31 Mar 2002 15:47:19 GMT
Links: << >>  << T >>  << A >>
Do you really want to rehash a 30-year old architecture ?  Why? Homework
?
Peter Alfke

Tina wrote:

> I'm working on development of Intel 8051 microcontroller architecture
> using VHDL on FPGA. I want to write code for its memory architecture
> ie RAM and ROM. Can anyone please suggest me how to proceed for the
> same.
>
> Thanks,
> Tina


Article: 41506
Subject: Re: Compiler library ...
From: Peter Alfke <palfke@earthlink.net>
Date: Sun, 31 Mar 2002 15:49:52 GMT
Links: << >>  << T >>  << A >>


Yves Petinot wrote:

> Hi,
>
> does any of you know where to find a C-library handling the compilation from
> VHDL to the bitstream format ? Any target FPGA will do ...

Give up on this idea. You will not find such a library, for a variety of
reasons that have been thoroughly discussed in this newsgroup...
Peter Alfke



Article: 41507
Subject: Orcad Sch f/Xilinx Spartan II
From: "Digital EE" <eedigital.nomorespam@hotmail.com>
Date: Sun, 31 Mar 2002 18:30:55 GMT
Links: << >>  << T >>  << A >>
Thanks for looking -

According to Xilinx's web site, Xilinx does not provide schematic symbols
for their FPGAs.  Instead, they recommend going through some of the
'alternative' support channels, such as the comp.arch.fpga newsgroup.

I am looking for the schematic symbol for a Xilinx Spartan IIE 50 in the 208
QFP package (XC2S50E PQ208).   I would really appreciate getting this
symbol.

If you reply by email, remove the '.nomorespam' from my email address.

Thanks!



Article: 41508
Subject: Re: Orcad Sch f/Xilinx Spartan II
From: Keith R. Williams <krw@attglobal.net>
Date: Sun, 31 Mar 2002 14:14:43 -0500
Links: << >>  << T >>  << A >>
In article <zBIp8.15888$Eb5.1425881@bgtnsc05-
news.ops.worldnet.att.net>, eedigital.nomorespam@hotmail.com 
says...
> Thanks for looking -
> 
> According to Xilinx's web site, Xilinx does not provide schematic symbols
> for their FPGAs.  Instead, they recommend going through some of the
> 'alternative' support channels, such as the comp.arch.fpga newsgroup.
> 
> I am looking for the schematic symbol for a Xilinx Spartan IIE 50 in the 208
> QFP package (XC2S50E PQ208).   I would really appreciate getting this
> symbol.

IMO, you're much better off creating meaningful symbols for your 
application. For larger devices (I found 680 pins a bit much for 
a page ;-) I break the symbols up according to function using 
heterogeneous blocks.  It makes the schematic much easier to 
read.

----
  Keith

Article: 41509
Subject: Re: Orcad Sch f/Xilinx Spartan II
From: engr <engr@none.com>
Date: Sun, 31 Mar 2002 13:03:43 -0800
Links: << >>  << T >>  << A >>
Digital EE wrote:
> 
> Thanks for looking -
> 
> According to Xilinx's web site, Xilinx does not provide schematic symbols
> for their FPGAs.  Instead, they recommend going through some of the
> 'alternative' support channels, such as the comp.arch.fpga newsgroup.
> 
> I am looking for the schematic symbol for a Xilinx Spartan IIE 50 in the 208
> QFP package (XC2S50E PQ208).   I would really appreciate getting this
> symbol.
> 

I just went through this.  I followed the advice of a message I found
in the Google usenet archives.   

This was for a Spartan II 50, in the 256 pin BGA package. XC2S50-6FG256

I made 11 parts:

Parts 1-8 each contain the i/o pins for Banks 0-7, respectively.
  Each part also has the two Vcco pins associated with the bank.
  Some of the i/o pins in a bank can also be used for Vref.
  These pins also go on the part.
  There are some pins that are dual purpose, either config or i/o.
  For these, I put them on Part 9, (the Config part) below. 

Part 9 is the clocks, GCK0-3.
Part 10 is the config pins:  M0-2, JTAG, and the Serial pins.
Part 11 is power -- Vccint, all the GNDS, and two NC pins.

The parts are all long, slim rectangles, with the pins only
on the left side, except for the Power part, which has pins
on both sides.

If you print out the actual chip footprint from Xilinx's web
page, you can mark off which pins go with each bank.  I did this
with colored pencils.  The bank pins are grouped together in
little clumps.  So it makes sense to make a symbol for each bank.
Also, of course, it makes electrical sense because you can change
the Vcco and Vref on a per-bank basis in Xilinx chips.

The library part (this is for Protel) has everything dumped on
one large square, which takes up an entire A-size sheet.
But I used it to speed up the part-making process.  It had its
pins arranged in banks.  So I just copied and pasted them onto
my single-bank parts.   That way, I didn't have to type in all
the pins myself.  It saved a lot of time.

The advantage of making single-bank parts is they take up a
lot less space on the page, and they are a lot more flexible.


-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----==  Over 80,000 Newsgroups - 16 Different Servers! =-----

Article: 41510
Subject: Re: Homebuilt Altera-programmer totally dead...
From: spam_vanishes_here@yahoo.de (Joachim Schueth)
Date: 31 Mar 2002 13:55:23 -0800
Links: << >>  << T >>  << A >>
Hi,

one thing I noticed while getting my homebuilt ByteBlasterMV compatible
cable to run is that you must connect pin 7 of the JTAG port to Vcc
(e.g. via a pullup resistor) although the documentation says that
pin 7 is not used in JTAG mode. If pin 7 is tied to ground the
programmer software always complains that it does not recognize the
chip. This means that the programmer does not ignore the state of the
corresponding input pin of the parallel port (although it should,
probably).

Cheers,
Joachim

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

Article: 41511
Subject: Update: A petition for Synplify's new fature (FPGA synthesis tool)
From: synp_petition@usa.net (Aki Niimura)
Date: 31 Mar 2002 17:44:08 -0800
Links: << >>  << T >>  << A >>
Hi,

I have posted the attached message almost two weeks ago.
I have received responses (12 opinions) and stimulated discussions.

The responses I got seem equally divided. I have learned several things
which I have overlooked. You can view those opinions in the following 
Web site: http://petition-synplify.0catch.com

I still would like to have more responses from FPGA/ASIC designers.
With few more responses, I will wrap up this petition and present to Synplicity.
(However, developers in Synplicity are already following this petition.)

The more I hear others' opinions, the more I feel that this is something
Verilog standard didn't do a good job. I can find both "for" and "against"
reasons in the standard.

My goal was not to force my opinion to Synplicity. My goal was to examine what
the logic mapping should be for such RTL design. We are "engineer", aren't we?

Hope my posting has provided something constructive to the FPGA/ASIC/synthesis
community.

Best regards,
Aki Niimura

// My posting (Date: Mon, 18 Mar 2002)

Dear Fellow FPGA designers,

I would like to have your feedbacks / supports.

Synplicity has released Synplify 7.0.x with lots of enhancements
last November. One of the enhancements is called "Tri-state push thru"
feature.

The following are excerpts from e-mails from Synplicity
explaining how the feature works:

> For example in the verilog code
>
> assign data = en ? data_in : 1'bz;
> always @(posedge clk)
> begin
> q_out = data;
> end
>
> will be implemented with tristate after the q_out flipflop currently ( 7.02
> ) to match simulation. The tristate will be implemented
> before the q_out flip flop with the switch ( 6.2.4 behavior).

> In 6.2.4 we didn't perform Tri-state push through across boundaries
> as like every other Synthesis tool on the market.  We (and many
> of our customers) deemed this logically incorrect.  We enabled
> Tri-state push thru in 7.0, but some of our customers requested
> a 'compatibility' switch so that our results matched our competition,
> hence the switch in 7.1.
> This switch fixes what we consider to be bad logic and was a
> definite requirement from our customers.
 
Simply saying, Synplify 7.x will implement the logic differently from
the RTL code you have specified to prevent simulation from causing
a mismatch.
 
I have noticed this new feature because my design becomes 30% larger
and yet slower when I resynthesized my existing design using Synplify
7.0.2.
 
With this feature:  1086LUTs (30.2MHz)  <<-- default in Synplify 7.x
W/o this feature :   833LUTs (31.8MHz)
 
My design uses tri-state gates to implement a multiplexer with
a large number of inputs efficiently which is a widely used
FPGA technique. I hand-crafted the multiplexer such that speed
and logic size are both satisfied.
Synplify 7.x will implement the multiplexer using LUTs and put
a tri-state gate after the LUTs. (tri-state gate is pushed-thru)
 
I thought this feature was creating more harms than goods.
Not only because I'm getting inferior results but also I feel
the synthesis tool should deliver the exact logic which the input
RTL code specified. (Otherwise, FPGA designers can not control
how the logic is laid out.)
 
Note: Synplify 7.1 has a switch to select this feature. However
this feature is always turned on by default.
 
However, the response I got from Synplicity is quite different
from what I had imagined. After many e-mail exchanges,
Synplicity has notified me their conclusion:
 
> We still strongly feel that disabling the Tri-state push thru by
> default would hurt too many of our customers - who specifically
> demanded this feature.  We have accommodated for those customers
> who prefer the legacy implementation by adding the switch.
> 
> We have several test designs with test-benches which clearly
> show RTL / simulation mismatches with this switch disabled.
> 
> Our senior management strongly believes this decision is correct
> and in-line with our policy of correct logic implementation.

Unfortunately, their conclusion is completely opposite to my
understanding.  I'm still not convinced that such logic mapping
is correct.

Since Synplify is #1 in the FPGA synthesis market, a huge number
of engineers in the world are using Synplify to design FPGAs.

I would like to ask everyone about this new feature of
Synplify 7.x. If you feel this feature is incorrect and
dangerous (or support Synplicity's arguments), please
send me an e-mail. I will present all e-mails I receive
to Synplicity (both for and against).

Feedback / support to : synp_petition@usa.net

I will post the update when I have something to report.

Thank you for your attention.
Hope I can hear from many of you. 
You can forward this to any other newsgroups or your friends
to get more feedbacks.

Sincerely yours,
Aki Niimura - being a Synplify user since 1999

P/S I have created a Web site to list feedbacks I receive.
http://www.petition-synplify.0catch.com

Article: 41512
Subject: Web pack (how to) ?
From: leotran@_*worldnet.att.net (Loi Tran)
Date: Mon, 01 Apr 2002 02:31:17 GMT
Links: << >>  << T >>  << A >>
Hey all,

I use Foundation (Xilinx) at work and I recently started working with the 
Webpack software and the way the schematic handles a bus tap is confusing.  
How do I take a tap off of a buss for one single signal?  Example:  DATA(7:0). 
I added the buss tap symbol on the bus, and pull a single net off the bus tap 
symbol and name the net A(7).  When I use the check on the schematic editor 
for errors, I get a silly message saying that one side of the bus tap is a bus 
and the other is a single net.  Please don't tell me that Xilinx went from 
idiotic (Foundation) to completely moronic with Webpack.  Anyway, I just need 
to know how to tap off a bus in Webpack.

Thanks for taking the time to read my ranting.

LT


Article: 41513
Subject: Re: Any Virtex II pro development board on market?
From: "Peter Ormsby" <faepete.deletethis@attbi.com>
Date: Mon, 01 Apr 2002 04:33:59 GMT
Links: << >>  << T >>  << A >>
Are there even any V2 Pro parts available yet?   I'd image development
boards should be available soon after the parts themselves start shipping,
but I'm not sure the parts are out there yet.

-Pete-

Unit Manager <antipattern@hotmail.com> wrote in message
news:e1f38cc5.0203290119.6aeecfb2@posting.google.com...
> Do you aware of any Virtex II pro development board on market?
>
> and
>
> Which high density FPGA board you would suggest?
>
> Thanks,
> ~pat!



Article: 41514
Subject: ALTERA Apex Device
From: "I. Servan Uzun" <isu@btae.mam.gov.tr>
Date: Mon, 1 Apr 2002 10:48:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi all,

I am generating a pulse (the pulsewith is 66.6ns) according to a look-up
table. The maximum PRF is 80kHz.
Let say the original signal name is X, then I also drive this signal off
the chip at 3 different pins with different signal names. In fact all 3
signals are the same only names differ.
I observed glitches on X but not on Y and Z. My question is what can I
do in the FPGA in order to prevent glitches.
I am using Altera Apex20K400E-1X device.

Thanks in advance.




-- 
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Article: 41515
Subject: Re: A petition for Synplify's new fature (FPGA synthesis tool)
From: "sweir" <weirsp@yahoo.com>
Date: Mon, 01 Apr 2002 11:21:01 GMT
Links: << >>  << T >>  << A >>
Brian,

While to_X01(ts_mux) may not work, I have confirmed that writing your own
resolution function does for both 7.03, and 7.1 beta:

signal    res_01 ;
function res_01( a : std_logic ) return std_logic is
begin if( a = '0') then return( '0' ) else return ('1') end if ;

That function is completely portable.

The thing that grates me about this whole debate is that Synplicity doesn't
infer the tri-state drivers on the combinatorial side when this default
"feature" is in the code.  And this includes 7.1 beta.  How can they claim
to infer propagation of a 'Z' that they first eliminate?  It was the loss of
the tri-state on the LHS that first got Aki's attention.

Simulation of the combinatorial net does not match Synplify 7.03, or 7.1
default output, period.  Take the various cases, simulate and display the
states on both sides of the FF, and then take the output from 7.03, or 7.1
and compare.  Depending on version and settings, either the LHS, or the RHS
pre-synthesis and post-synthesis will not match.  Worse, the behavior in 7.1
with the default push-through enabled produces different results in response
to different, but exactly equivalent coding styles.

If you code a tri-state into a function, and invoke that function in-line,
then 7.1 performs with push-through as discussed on this thread.  However,
merely encapsulating the function in a component, magically returns 7.1 with
push-through turned on to the coded behavior, tri-state on the LHS, and a
straight FF.

On the matter of whether the push-through should be done at all, I would
like any advocate of the Z push-through to explain how it is that in either
VHDL or Verilog we can have store a result without first declaring a Verilog
reg, or VHDL signal to hold that result?  Nowhere in any of the code
examples I have seen is there a declaration of that stored result that
Synplify dutifully produces.  Do these advocates recognize that their
position dictates a discrete 'Z' state register for every address location
in a memory array where the data input is a tri-state bus?

Simulation is a fantasy that we do our best to make useful.  Part of that
task is construction of a reasonable model for the tool, and sane
interpretation of the results.  Whether the simulator chooses to acknowledge
it or not, a voltage storage device has no means to propagate the impedance
condition present at its input.  If we want to be thorough, we can overcome
the simulator limitation with a resolution function.  Overcoming reality
with the synthesis tool seems a poor choice.  I want to see the poor devil
who thinks a semiconductor manufacturer will change the design of their
parts because the way they work on his board isn't the same as in his SPICE
simulation.

This is one of the few times that Synplicity screwed-up, and they need to
fix it sooner rather than later.  The first step is to restore the correct
synthesis of tri-states on the combinatorial side where the code has
explicitly placed them.

Then, if they still find that loopy customers expect magic FF's, and want
them, let those users put the tool in Timothy Leary mode.  But IMO, by no
means should simulation aberrations drive default synthesis behavior.

Regards,

Steve

"Brian Davis" <brimdavis@aol.com> wrote in message
news:a528ffe0.0203241856.35a17d34@posting.google.com...
> Allan wrote:
>
> >
> >I would add to this:
> >
> >       sig3 <= to_X01(ts_mux);
> >
> >This should *never* allow a tristate to propagate through
> > a flip flop, regardless of any tool settings.
> >
>
>  Thanks, I added that one to my test-case-in-progress.
>
>       sig1 <= ts_mux;
>       sig2 <= ts_mux AND '1';
>       sig3 <= to_X01(ts_mux);
>
>   Although both sig2 and sig3 resolve to 'X' in pre-synthesis
>  simulation, Synplify 7.0.3 builds a tristate on all three outputs
>  instead of just on sig1.
>
>   That is completely incorrect from any perspective, whether you
>  believe in Z-transport DFFs or not.
>
>
> Test Case notes ( see code below):
>
>    Sig5 shows the tristate pushthough in action across a big shift
>   register, which requires pipelining the phantom enable to match.
>
>    Also see sig7, which shows the tristate pushthough affecting
>  some combinatorial logic described with a conditional assignment.
>
>   For a real chuckle:
>    - synthesize the test case below
>    - look at the synthesis results in the HDL Analyst RTL viewer
>    - uncomment the fourth driver on the tristate bus & resynthesize
>    - look at the synthesis results again
>
>
> Improved workaround:
>
>   Although "to_X01" doesn't work in Synplify 7.0.3, you could write
>  the following and still be fairly portable if you always use this
>  resolved signal as the input to registers or other logic:
>
>    attribute syn_keep : boolean;
>    attribute syn_keep of ts_mux_resolved : signal is true;
>      .
>      .
>    ts_mux_resolved <= to_X01(ts_mux)
>
>
> Other Notes:
>
>    I was going to try this test case with Synplify 7.1, but it doesn't
>  seem to be available on the website.
>
>    I spent a while last night searching for this switch in 7.0.3;
>  there seems to be no mention of this tristate pushthrough feature
>  in the 7.0.3 release notes or documentation.
>
>
> thanks,
> Brian
>
>
> --
> -- tt2.vhd
> --
> -- - demonstrates nasty side effects of tristate pushthrough,
> --   which will unpredictably create tristates at output pins
> --
> -- - demonstrates improper implementation of the pushthrough feature
> --    - signals that have 'X's in pre-synth RTL sim also incorrectly
> --       suffer from tristate pushthrough
> --
> -- - tested with Synplicity 7.0.3, targeting Spartan-2
> --
> --
> library ieee;
> use ieee.std_logic_1164.all;
>
> entity tt2 is
>   port
>     (
>       clk   : in  std_logic;
>
>       sel   : in  std_logic_vector( 1 downto 0 );
>
>       a_in  : in  std_logic;
>       b_in  : in  std_logic;
>       c_in  : in  std_logic;
>       d_in  : in  std_logic;
>
>       dummy : in  std_logic;
>
>       sig1 : out std_logic;
>       sig2 : out std_logic;
>       sig3 : out std_logic;
>       sig4 : out std_logic;
>       sig5 : out std_logic;
>       sig6 : out std_logic;
>       sig7 : out std_logic;
>       sig8 : out std_logic
>     );
> end tt2;
>
> architecture arch1 of tt2 is
>
>   signal   ts_mux   : std_logic;
>
>   constant PIPE_MSB : natural := 17;
>   signal   pipe     : std_logic_vector(PIPE_MSB downto 0);
>
> begin
>
>  --
>  -- build an not-fully-populated internal tristate mux
>  --
>  ts_mux <= a_in  when sel = "00" else  'Z';
>  ts_mux <= b_in  when sel = "01" else  'Z';
>  ts_mux <= c_in  when sel = "10" else  'Z';
>
>  --
>  -- Need to comment out the last driver so tristate pushthrough
>  -- behavior appears. If the tristate mux is fully populated,
>  -- some of the output tristates vanish, as Synplify's analysis
>  -- of the enables concludes that the bus is always being driven
>  --
>  -- ts_mux <= d_in  when sel = "11" else  'Z';
>
>  --
>  -- register the mux several ways
>  --
>  --
>  out_reg: process(clk)
>   begin
>
>     if rising_edge(clk)  then
>
>       --
>       -- results w/7.0.3 : sig1 has a tristate output
>       -- MATCH
>       --
>       sig1 <= ts_mux;
>
>       --
>       -- results w/7.0.3 : sig2 has a tristate output
>       -- MISMATCH
>       --   AND is optimized away, although it should resolve signal
>       --
>       sig2 <= ts_mux AND '1';
>
>       --
>       -- results w/7.0.3 : sig3 has a tristate output
>       -- MISMATCH
>       -- resolution function is apparently ignored
>       --
>       sig3 <= to_X01(ts_mux);
>
>       --
>       -- results w/7.0.3 : sig4 has a normal output
>       -- MATCH
>       -- Synplify can't optimize this AND away, so it works
>       --
>       sig4 <= ts_mux AND dummy;
>
>
>       --
>       -- create a big shift register for the next two signals
>       --
>       pipe <= pipe(PIPE_MSB-1 downto 0) & ts_mux;
>
>       --
>       -- results w/7.0.3 : sig5 has a tristate output
>       -- MATCH
>       -- lots of enable pipelining
>       --
>       sig5 <= pipe(PIPE_MSB);
>
>       --
>       -- results w/7.0.3 : sig6 has a normal output
>       -- MATCH
>       --
>       sig6 <= pipe(PIPE_MSB) XOR pipe(7);
>
>     end if;
>
>     --
>     -- try a FF with reset
>     --
>     if dummy = '0' then
>       sig7 <= '0';
>
>     elsif rising_edge(clk)  then
>       --
>       -- results w/7.0.3 : sig7 has a tristate output
>       -- MATCH
>       --
>       sig7 <= ts_mux;
>
>     end if;
>
>   end process;
>
>
>  --
>  -- this pushthrough feature also affects combinatorial logic
>  --
>   sig8 <=  ts_mux when dummy = '0' else NOT ts_mux;
>
> end arch1;



Article: 41516
Subject: Re: FPGA config without boot PROM???
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 1 Apr 2002 14:19:47 +0200
Links: << >>  << T >>  << A >>
"Pete Dudley" <pete.dudley@comcast.net> schrieb im Newsbeitrag
news:Wacp8.128139$7b.11591039@bin7.nnrp.aus1.giganews.com...
> Quicklogic has a new family called Eclipse that is antifuse and goes up to
> "500K" gates. They claim 600MHz internal clock frequency is possible. That
> sounds competitive at a glance anyway.

Does this really mean 600 MHz or "just" maximum FlipFlop toggle frequency?

--
MfG
Falk





Article: 41517
Subject: Re: ALTERA Apex Device
From: "Falk Brunner" <Falk.Brunner@gmx.de>
Date: Mon, 1 Apr 2002 14:21:44 +0200
Links: << >>  << T >>  << A >>


--
MfG
Falk

"I. Servan Uzun" <isu@btae.mam.gov.tr> schrieb im Newsbeitrag
news:4f1f439498d164bee248303833255002.10234@mygate.mailgate.org...
> Hi all,
>
> I am generating a pulse (the pulsewith is 66.6ns) according to a look-up
> table. The maximum PRF is 80kHz.
> Let say the original signal name is X, then I also drive this signal off
> the chip at 3 different pins with different signal names. In fact all 3
> signals are the same only names differ.
> I observed glitches on X but not on Y and Z. My question is what can I
> do in the FPGA in order to prevent glitches.
> I am using Altera Apex20K400E-1X device.

Just use a FlipFlop after the decoder, this will avoid any glitches (as long
as setup/hold times are met). Almost all decoders inhibit glitches.

--
MfG
Falk





Article: 41518
Subject: Re: ALTERA Apex Device
From: "Paul Baxter" <pauljnospambaxter@hotnospammail.com>
Date: Mon, 1 Apr 2002 13:33:08 +0100
Links: << >>  << T >>  << A >>
"I. Servan Uzun" <isu@btae.mam.gov.tr> wrote in message
news:4f1f439498d164bee248303833255002.10234@mygate.mailgate.org...
> Hi all,
>
> I am generating a pulse (the pulsewith is 66.6ns) according to a look-up
> table. The maximum PRF is 80kHz.
> Let say the original signal name is X, then I also drive this signal off
> the chip at 3 different pins with different signal names. In fact all 3
> signals are the same only names differ.
> I observed glitches on X but not on Y and Z. My question is what can I
> do in the FPGA in order to prevent glitches.
> I am using Altera Apex20K400E-1X device.

Could you adjust the slew rate on all three outputs or other outputs around
them to limit current spikes?
You can adjust output slew rates on just a portion of the outputs from the
chip to reduce such current surges.
Are there other switching outputs around the glitching pin? Maybe its a
power supply decoupling issue?





Article: 41519
Subject: Re: powerpc in virtex2pro
From: Utku Ozcan <ozcan@netas.com.tr>
Date: Mon, 01 Apr 2002 17:00:10 +0300
Links: << >>  << T >>  << A >>
"Cyrille de Br=E9bisson" wrote:

> Hello,
>
> Actually, I have a related question.
> In our design we are using an ARM CPU. My question is:
> Can we put an ARM in the virtex 2 pro?
> Were can I find/buy an ARM cpu core source (or precompiled) file to pro=
gram
> in my FPGA?
>
> Regards, Cyrille

AFAIK Altera devices support ARM.

Utku



Article: 41520
Subject: Re: powerpc in virtex2pro
From: Ron Huizen <rhuizen@bittware.com>
Date: Mon, 01 Apr 2002 09:18:40 -0500
Links: << >>  << T >>  << A >>
Peter,

Are you saying that putting an ARM core into a Virtex II is not doable,
or just not practical?  Or are you only talking about the V2 Pro?  

---------
Ron Huizen
BittWare

Peter Alfke wrote:
> 
> "Cyrille de Brébisson" wrote:
> 
> > In our design we are using an ARM CPU. My question is:
> > Can we put an ARM in the virtex 2 pro?
> > Were can I find/buy an ARM cpu core source (or precompiled) file to program
> > in my FPGA?
> >
> 
> Cyrille,
> the answer to both your questions is: No.
> The PowerPC in Virtex-II Pro is a "hard" implementation, packing the
> microprocessor with its caches and MMU into the smallest possible silicon
> area, <4 square millimeters.
> What you seem to be looking for is a "soft" implementation, using the
> programmable logic "fabric".
> That solution is impractical for something as complex as PowerPC or even ARM.
> It would take up an unreasonable portion of a large chip, and achieve mediocre
> performance at best.
> Xilinx offers a soft microprocessor, called MicroBlaze, especially tuned for
> efficient implementation in the Virtex architecture. It is not as fast and
> capable as PowerPC, but uses only ~900 slices.
> "Half the size and twice the speed of NIOS" is the Xilinx slogan. Please, no
> flames...
> 
> Peter Alfke, Xilinx Applications

Article: 41521
Subject: Re: PCI Compliance..
From: "Austin Franklin" <austin@dar55kroom.com>
Date: Mon, 1 Apr 2002 10:35:26 -0500
Links: << >>  << T >>  << A >>
> Note also that there is a substantial difference between 5V- and 3.3V PCI.

Aside from the I/O standard (which is merely an attribute on the pin), what
else?  The core logic is the same...the I/O timing is the same...  May be my
little doggie mind isn't out of the fog yet, and I haven't had enough DC yet
(Diet Coke) this morning, but I wouldn't call the difference "substantial"
by any stretch of the word, as far as implementation goes...

> The general rule is: try to keep the voltage as low as you can. 5V has
less, if
> any, future...

Yeah, except that almost NO PC systems, except server boards, have 3.3V
slots (much less universal slots).  There are millions and millions of 5V
PCI compliant computers out there...that beckon to not be ignored ;-)

If anyone is making a new PCI card, and their market is for more than two
years, I'd suggest a universal (5V and 3.3V) card.  I believe there is (or
at least was) a "slight" problem with Xilinx (and probably other FPGA
manufacturers parts too) and universal PCI I/O...  I'm not sure if that's
been solved yet...I know of all the dozen or so Xilinx based PCI cards I've
designed, with everything but the latest Xilinx technology, it required two
different bit streams...  Again, may be my LDM isn't quite engaged yet...

Austin




Article: 41522
Subject: Re: Filter design problem
From: vt313@comsys.ntu-kpi.kiev.ua
Date: Mon, 01 Apr 2002 17:41:07 +0200
Links: << >>  << T >>  << A >>

> 
> This is more of a signal processing problem which I am implementing on FPGA
> (Spartan II 200k). I have two 40 tap FIR filters for a complex signal. The
> imaginary filter is a normal low pass filter which has been convolved with a
> hilbert transform. The real filter is just a normal low pass filter.
> 
> My question is this: I want to add a dc blocker into the real filter to
> attempt to get my passbands in the imaginary and real filters the same. The
> imaginary filter has one automatically due to the nature of the hilbert
> transform, which makes the roll-off to DC very large. As the filters were
> designed using a hamming window, my first attempt was to subtract a 40 unit
> hamming window from the real coefficients such that the DC gain of the
> coefficients was 0. This is effectively a DC block. However, due to the
> nature of the infinite negative spike I have put in the pass band, the
> roll-off to DC is not as large as the imaginary filter => pass bands do not
> match.
> 
> Does anyone have any other ideas on how to implement a DC block and still
> have the same roll-off to DC as that in a hilbert transform. It seems this
> won't be possible, since the "negative spike" in a hilbert transform is
> finite, but the DC block is infinite.
> 

Try to use the DC suppressor using the allpass filter.
It has rather accurate phase characteristic,
small group delay,
and 100% DC suppression.

Anatoli Sergyienko.

Article: 41523
Subject: Re: VirtexII : Any limitation on using LVDS?
From: Austin Lesea <austin.lesea@xilinx.com>
Date: Mon, 01 Apr 2002 07:50:31 -0800
Links: << >>  << T >>  << A >>
Peter is right, but....

The pre-drivers do generate a small amount of ground bounce.

We have recommended that the same SSO entry for LVTTL 2 mA FAST be used for maximum number of LVDS pairs (one pair = one single LVTTL 2mA FAST IOB).

Now there may not be more than 40 LVDS pairs per power/ground pin pair (for ff packages per the table for 80 IOBs) in a bank, but the generation of a bounce is real, and
bypassing can not be ignored.

Austin



Peter Alfke wrote:

> There are no limitations.
> LVDS is  differential standard, therefore its outputs do not generate ground bounce.
>
> Peter Alfke
> ==================================
> Ken wrote:
>
> > Dear all,
> >
> > I want to ask if there is any limitation or restriction on using the LVDS I/O on Virtex II FPGA?  For example, the maximum number of LVDS I/O used at the same time?
> >
> > I can find similar information for the signle ended I/O from the User Guide but not for LVDS.
> >
> > Anyone has idea about it?  Or know how to search such information?  Thanks in advance.
> >
> > Regards,
> > Kenneth


Article: 41524
Subject: Data Compression in FPGAs
From: lucky_hero@yahoo.com (VP)
Date: 1 Apr 2002 07:59:09 -0800
Links: << >>  << T >>  << A >>
Hi all,

I am trying to find best general purpose data (text, audio, video and
other types) compression algorithm suitable for FPGA implementation. 
On doing some research LZW compression and variations of LZ (LZ-77,
LZS etc) compression seems to be a good fit. Can someone point me to
other hardware based loss less data compression algorithms? Did anyone
implement data compressors in FPGAs? Any pointers/references would be
greatly appreciated.


Thanks



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

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

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

Custom Search